Cisco Cisco Packet Data Gateway (PDG)

 

Congestion Control monitors the system for conditions that could potentially degrade performance when the system is 
under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are 
quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an 
impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes 
policies for addressing the situation. 

Congestion control operation is based on configuring the following: 



 

Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled 

and establishes limits for defining the state of the system (congested or clear). These thresholds function in a 
way similar to operation thresholds that are configured for the system as described in the Thresholding 
Configuration Guide. The primary difference is that when congestion thresholds are reached, a service 
congestion policy and an SNMP trap, starCongestion, are generated. 

A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for 
the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered. 



 

Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all 

ports in the system reaches the specified threshold, congestion control is enabled. 



 

Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific 

threshold is reached, congestion control is enabled system-wide. 



 

Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how 

services respond when the system detects that a congestion condition threshold has been crossed. 

  For more information on Congestion Control support, refer Congestion Control chapter in System 

Administration Guide. 

DHCP interface support at HNB-GW is provided to allocate IP address to HNB using DHCP procedure. Without this 
support IP address is allocated using locally configured IP pool. HNB connects to HNB Security Gateway (Se-GW) via 
IPSec tunnel. During IPSec tunnel establishment, HNB Se-GW allocates IP address to HNB. Femtocell provisioning 
system needs HNB IP address. This is achieved by co-locating this system with DHCP server. HNB Se-GW then uses 
DHCP procedure to allocate IP address to HNB. 

Following is a typical message flow when HNB-GW performs as DHCP proxy: 

1.  HNB initiates IKE transaction by sending IKE SA INIT message to share encryption parameters. 
2.  Se-GW on HNB-GW responds with IKE SA INIT to confirm encryption parameters and the nonce. 
3.  HNB sends IKE Auth Request and includes IDi, IDr and configuration payload to request the IP address. IDi is 

the IKE ID of HNB-GW. 

4.  HNB-GW initiates Authentication with AAA Server. HNB and AAA server exchange EAP messages. 
5.  Finally AAA server confirms successful authentication of HNB to HNB-GW and Subscriber template is selected 

and aaa-data is returned to SessMGR by AAAMGR which contains necessary configuration and AAA returned 
values. 

6.  HNB-GW, as with previous EAP messages, relays EAP success over IKE Auth to HNB. Steps 4, 5 and 6 are not 

performed in case of certificate based authentication. 

7.  HNB then initiates IKE Auth request to authenticate the SA. HNB-GW selects the IP address allocation method 

using the configuration from AAA-data. Method is configured to be DHCP-proxy in subscriber template. To