An SGSN pool is a collection of SGSNs configured to serve a common geographical area for a radio network. This common part is referred to as the SGSN pool service. SGSN Pooling is also referred to as Iu/Gb flex support based on if the access is 3G or GPRS respectively.
An SGSN pool provides a flexible and resource-efficient architecture with built-in network redundancy for the GPRS/UMTS packet core network. Each BSC/RNC has the ability to connect to all SGSNs in the pool. If any SGSN becomes unavailable, any terminal attached to that SGSN will be automatically re-routed to another SGSN in the pool by the BSC/RNC. This implies that the SGSN pool provides network level redundancy. SGSN failure is discovered by the BSCs/RNCs and the uplink traffic from the terminal is routed to another SGSN in the pool. The substituting SGSN orders the terminal to re-attach and re-activate any PDP contexts. Therefore service availability is maintained. Please note that all SGSNs in a pool are required to have the same capacity, feature sets and scalability and hence the same vendor, failing which might lead to varying subscriber experience across SGSNs.
In a pooled network, Inter-SGSN routing area updates (RAUs) are avoided and this provides a faster response time, compared to non-pooled networks. With SGSN pool for GPRS/UMTS, Inter-SGSN RAU is replaced by Intra-SGSN RAU, for terminals moving within the pool area. Intra-SGSN RAU provides reduced interruption time for data transfer, compared to Inter-SGSN RAU. Furthermore, due to the fewer Inter-SGSN RAUs, there is less signaling generated on the Gr interface.
When an UE connects to an SGSN in the pool, by Attach or Inter-SGSN RAU (ISRAU) procedures, the UE is allocated a Packet Temporary Mobile Subscriber Identity (P-TMSI) containing a Network Resource Identifier (NRI) identifying the SGSN. The BSC/RNC then identifies the SGSN from the NRI, and routes the user data to the correct SGSN. Load-sharing between the SGSN pool members is thus based on the NRI routing algorithm in the BSC/RNC. UEs that have not yet been assigned a P-TMSI, and MSs without matching NRI, are distributed among the pool members by the BSC/RNC according to the traffic distribution procedure. Once a UE has been allocated a P-TMSI, it stays connected to the same SGSN as long as it remains in the pool area. This period can be quite long, since MSs normally keep the P-TMSI even after power off.
A valid license key is required to enable the SGSN Pooling feature. Contact your Cisco Account or Support representative for information on how to obtain a license.
A Basic Pool Structure
A basic SGSN pool structure is depicted in the diagram below:
- Multiple SGSNs form a single logical entity called SGSN pool.
- SGSN pools service areas larger than stand-alone SGSN service areas.
- This set up is compatible with non-pool aware nodes and is transparent to the end-user.
Benefits of SGSN Pooling
- Increased Availability: If one SGSN fails, another SGSN from the pool can substitute it. Any node can be taken out of a pool during maintenance.
- Increased Scalability: More number of SGSN nodes can be added to the pool.
- Reduced Signaling: Number of inter-SGSN routing area updates is reduced.
Listed below are the requirements to support pooling:
- The SGSN should support configuration of NRI and use that NRI in all the PTMSI issued.
- If the SGSN is configured as a default SGSN, it should relay SGSN Context Request / Identification request received from peer SGSN (outside of pool) to SGSN (in pool) anchoring that subscriber anchoring SGSN in pool.
- Support of non-broadcast RAI, null-NRI configurations to allow off-loading of self-SGSN and handle the off-loading of a peer SGSN.