Cisco Cisco ASR 5000

Page of 640
  SGSN Pooling 
How it Works  ▀   
SGSN Administration Guide, StarOS Release 18  ▄  
 
   
off-loaded in the same manner. The move operation will not overload the network, as throttling is supported for both 
Attach and Inter SGSN RAU procedures.  
Target-NRI based offloading
 
Target NRI based offloading was primarily introduced so that subscribers can be offloaded to a chosen SGSN. In the 
case of NULL-NRI based offloading there is no control on which SGSN the subscribers are offloaded to. SGSN 
offloads subscribers by assigning NB-RAI, stamping Target-NRI in PTMSI and reducing periodic routing area update 
timer during Attach/RAU accept messages. 
IMSI-based offloading is carried in the following three phases: 
IMSI based offloading 
 
With Target-NRI based method of offloading though there is control on the SGSN to which the subscribers are 
offloaded, there is no control on the subscribers being offloaded to the SGSN. IMSI-based offloading enhancement 
allows the operator to choose the subscribers to be offloaded to a particular SGSN.  
Phase -1
 
When a Attach accept or a RAU accept is issued, the offloading configuration is verified and if offloading is enabled, 
the corresponding NRI is issued (if it is not issued earlier). In case the specific IMSI based offloading configuration is 
configured, the configured target-nri is used. When offloading is enabled, if ptmsi allocation configuration is absent, a 
ptmsi is allocated to the subscriber in Attach/RAU accept. 
Phase -2
 
On receiving an activation trigger from the MS, the subscriber is detached and the re-attach required is set to true. The 
MS will return an attach in due time, after which the MS is offloaded to another SGSN by setting the Target-NRI and 
NB-RAI appropriately.  
Phase -3
 
The subscriber is cleared unconditionally and a detach is sent by setting the re-attach required to true. The subscriber is 
lost at this stage. In the next attach, the subscriber is offloaded to the configured SGSN. 
For information on the procedure to configure MS-Offloading, refer to the section “Configuration of SGSN Pooling - 
Procedure to configure MS-Offloading”.
 
Iu/Gb Flex support over S16/S3 interface 
SGSN Pooling support has been extended to S16/S3 interface. The enhancement also includes support for default SGSN 
functionality for S16/S3 interface as in the case of Gn interface. The peer SGSN in this case is a S4-SGSN. The 
incoming message (EGTP_CONTEXT_REQ/IDENTIFICATION_REQ) is received from a non-pooled SGSN, it is 
forwarded to the old-SGSN if the SGSN is configured as default SGSN. The SGSN in a pool is identified on the basis 
on NRI value and OLD- RAI value. The NRI value is extracted from PTMSI. 
Backward compatibility and default SGSN functionality
 
If a default SGSN that is serving a pool-area receives EGTP signaling it resolves the ambiguity of the multiple SGSNs 
per RAI by deriving the NRI from the P-TMSI. The SGSN relays the EGTP signaling to the old SGSN identified by the 
NRI in the old P-TMSI unless the default SGSN itself is the old SGSN. For default-SGSN functionality to work, static 
IP address entries are mandatory in the call-control profile. 
Messages are relayed by the Default-SGSN (Default SGSN functionality and pooling are enabled) in following cases: 
 
Pooled local RAI and non-local NRI 
 
Non-local RAI and Null-NRI