Cisco Cisco ASR 5000

 

▄  SGSN Administration Guide, StarOS Release 18 

Response or Update PDP Context Request) from the GGSN and immediately inform the SGTPC Manager (SGTPCMgr) 
to pass the path failure detection to all other SessMgrs so that PDP deactivation would begin. 

New Behavior: The new default behavior has the SessMgr inform the SGTPCMgr of the changed restart counter value. 
The SGTPCMgr now has the responsibility to verify a possible GTP-C path failure by issuing an Echo Request/Echo 
Response to the GGSN. Path failure will only be confirmed if the Echo Response contains a new restart counter value. 
Only after this confirmation of the path failure does the SGTPCMgr inform all SessMgrs so that deactivation of PDP 
contexts begins.  

GTPv0 fallback can cause unnecessary signaling on the Gn/Gp interface in networks where all the GGSNs support 
GTPv1. 

By default, the SGSN supports GTPv0 fallback and uses either GTPv1 or GTPv0. After exhausting all configured retry 
attempts for GTPv1, the SGSN retries the GTP-C Request using GTPv0. This fallback is conditional and is done only 
when the GTP version of a GGSN is unknown during the first attempt at activating a PDP context with the GGSN. 

It is possible for the operator to disable the GTPv0 fallback for requests to GGSNs of specific APNs. Disabling the 
fallback function is configured under the APN profile and is applicable for GGSNs corresponding to that APN. If 
GTPv1 only is enabled in the APN profile, then the SGSN does not attempt fallback to GTPv0 (towards GGSNs 
corresponding to that APN) after all GTPv1 retries have been attempted. If more than one GGSN address is returned by 
the DNS server during activation, then the SGSN attempts activation with the next GGSN after exhausting all the 
GTPv1 retry attempts. If only one GGSN address is returned, then the SGSN rejects the activation after exhausting all 
the configured GTPv1 retries. 

This change enables the operator to prevent unnecessary signaling on the Gn/Gp interface in networks where all the 
GGSNs support GTPv1. For example, if all the home GGSNs in an operator’s network support GTPv1, then the 
unnecessary GTPv0 fallabck can be avoided by enabling this feature for the APNs associated with home GGSNs. 

Some machine-to-machine (M2M) devices from the same manufacturer will all attempt PS Attaches using the same 
fixed random Temporary Logical Link Identifier (TLLI). 

The SGSN cannot distinguish between multiple M2M devices trying to attach simultaneously using the same random 
TLLI and routing area ID (RAI). As a result, during the attach process of an M2M device, if a second device tries to 
attach with the same random TLLI, the SGSN interprets that as an indication that the original subscriber moved during 
the Attach process and the SGSN starts communicating with the second device and drops the first device. 

The SGSN can be configured to allow only one subscriber at a time to attach using a fixed random TLLI. While an 
Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other 
attaches sent to the SGSN with the same random TLLI using a different IMSI will be dropped by the SGSN’s Linkmgr. 

To limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to 
control which subscribers will be provided this functionality. 

Besides enabling configurable support for either 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+) to match 
whatever the RNCs support, this feature enables configurable control of data rates on a per RNC basis. This means that 
operators can allow subscribers to roam in and out of coverages areas with different QoS levels.