Cisco Cisco Packet Data Gateway (PDG) Guida Alla Risoluzione Dei Problemi

Pagina di 338
ASN Keep Alive BS Monitoring   
▀  Keep Alive Request and Response Overview 
 
▄  Cisco ASR 5000 Series Access Service Network Gateway Administration Guide 
OL-22953-01   
Keep Alive Request and Response Overview 
The mechanism for detecting a base station restart is as following:  
 
 
In the initial keep alive interrogation with its peer, the ASN GW stores the LRT value of its peer nodes. The 
ASN GW that supports the keep alive functionality, generates the LRT and caches it internally. The ASN GW 
sends the LRT value in the keep alive Request or Response message. This value is interpreted by the keep alive 
receiver to detect the peer’s restart. 
 
In subsequent keep alive interrogations, the ASN GW compares the received LRT value with the stored value. If 
the received LRT value does not match the stored value for the peer node, the ASN GW considers that the peer 
node has passed restart during the time interval from the last keep alive interrogation. The ASN GW takes an 
appropriate action. The action may be implementation-specific, such as purging the corresponding MS 
contexts, or triggering MS Network Exit for the affected MSs. 
 
If the restart preserves the MS contexts that were stored before the reboot, the ASN GW does not change its LRT 
value after the reboot. Otherwise, the ASN GW does change its LRT value to inform the peer node of its 
reboot. The ASNGW that detects the peer node restart stores the new LRT value for this peer node. 
The ASN GW monitors the base stations that are directly connected to it. The ASN GW does not monitor the base 
station that is connected to the non-anchor. 
If a keep alive request or response is received from the legacy base station, it is dropped. 
 
Keep Alive Request Sender 
If you enable the keep alive-based base station monitoring feature for a particular ASN GW service, that ASNGW 
service starts monitoring the list of base stations from which it has received any R4/R6 traffic from previous sessions, 
including non-active sessions.  
The monitoring occurs in the following stages: 
Step 1 
When a base station entry is created through call setup (the initial network entry), or a successful data path is created 
during a handoff, the ASN GW starts sending keep alive Request messages and waits for keep alive responses. The keep 
alive request messages are addressed to the base station’s R6 address endpoint. The source address of the keep alive 
Request messages are the ASN GW service’s IP address. The base station receives keep alive requests from the ASN 
GW only when there are sessions established with that base station. The ASN GW stops monitoring base station when 
there are no active sessions as a result of a handoff to another base station or session termination from this base station. 
No peer base station configuration is needed for the base station list. 
Step 2 
If the ASN GW does not receive a keep alive response messages after timeout (T), the ASN GW retransmits the keep 
alive request message as many times as is configured (num-retry (N)) times. If the ASN GW receives no response after 
N retries, the base station is considered out of service. 
Step 3 
When the maximum number of retransmissions specified in num-retry (N), for a given base station have been 
exhausted, the ASN GW Manager sends a clear subscriber message to all the session manager tasks in the system. The 
session managers delete the sessions that correspond to the non-responsive base station and generate Accounting Stop 
records for The de-registration, network exit, and Accounting-Stop messages are sent in a paced manner.