Serving GPRS Support Node (SGSN) Overview

Serving GPRS Support Node (SGSN) Overview
 
 
This chapter contains general overview information about the Serving GPRS Support Node (SGSN), including sections for:
 
 
Product Description
The ASR 5000 provides a highly flexible and efficient Serving GPRS Support Node (SGSN) service to the wireless carriers. Functioning as an SGSN, the system readily handles wireless data services within 2.5G General Packet Radio Service (GPRS) and 3G Universal Mobile Telecommunications System (UMTS) data networks.
 
Important: Throughout this chapter the designation for the subscriber equipment is referred to in various ways: UE for user equipment (common to 3G/4G scenarios), MS or mobile station (common to 2G/2.5G scenarios), and MN or mobile node (common to 2G/2.5G scenarios involving IP-level functions). Unless noted, these terms are equivalent and the term used usually complies with usage in the relevant standards.
In a GPRS/UMTS network, the SGSN works in conjunction with radio access networks (RANs) and Gateway GPRS Support Nodes (GGSNs) to:
This chapter catalogs many of the SGSN key components and features for data services within the GPRS/UMTS environment. Also, a range of SGSN operational and compliance information is summarized with pointers to other information sources.
 
Product Specifications
The following information is located in this section:
 
 
Licenses
The SGSN is a licensed product. A session use license key must be acquired and installed to use the SGSN service. As well, the SGSN supports several special features that also require license keys be acquired and installed for their use.
The following feature licenses are available for use with the SGSN:
 
Hardware Requirements
Information in this section describes the hardware required to support SGSN services.
 
Platforms
The SGSN operates on an ASR 5000.
 
ASR 5000 System Hardware Components
The following application and line cards are required to support GPRS/UMTS wireless data services on the SGSN:
 
System Management Cards (SMCs): Provides full system control and management of all cards within the ASR 5000. Up to two SMCs can be installed; one active, one redundant.
Packet Services Cards (PSCs): Within the chassis, PSCs (either PSC or PSC2) provide high-speed, multi-threaded PDP context processing capabilities for 2.5G SGSN, 3G SGSN, and GGSN services. Up to 14 PSCs can be installed, allowing for multiple active and/or redundant cards.
Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SMCs, SPIOs provide connectivity for local and remote management, central office (CO) alarms, and BITS timing. Up to 2 SPIOs can be installed: 1 active, 1 redundant.
Line Cards: Installed directly behind PSCs, these cards provide the physical interfaces from the SGSN to various elements in the GPRS/UMTS data network. Up to 26 line cards can be installed for a fully loaded system with 13 active PSCs, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs do not require line cards.
Depending on the SGSN network environment, the system supports multiple types of line cards, simultaneously if needed:
Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100 or Ethernet 1000 line cards/QGLCs and every PSC in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSCs.
Additional information, for each of the application and line cards required to support GPRS/UMTS wireless data services, is located in the ASR 5000 Hardware Installation and Administration Guide.
 
Operating System Requirements
The SGSN is available for all ASR 5000s running StarOS 8.0 or higher.
 
System Configuration Options
An ASR 5000 SGSN system supports multiple GPRS Support Node (GSN) service applications, in any combination, co-located within a single chassis, for example:
 
 
Benefits of Co-Located GSNs
Integrated co-location is done without introducing proprietary protocols, thus avoiding mobility and handoff issues. Multiple network element applications, integrated as a single application within a single chassis, benefit carriers for the following reasons:
 
 
 
Network Deployments and Interfaces
The following logical connections maps indicate the SGSN’s ability to connect to both 2G (GSM BSS) and 3G (UMTS RAN) radio access networks, a mobile service center (MSC) and visitor location register (VLR), a home location register (HLR), a charging gateway (CG - sometimes referred to as a charging gateway function (CGF)), a GTPP storage server (GSS), a standalone GGSN, network devices in another PLMN, an SMS server center, and a standalone SGSN.
 
SGSN and Dual Access SGSN Deployments
SGSNs and GGSNs work in conjunction within the GPRS/UMTS network. As indicated earlier in the section on System Configuration Options, the flexible architecture of the ASR 5000 enables a single chassis to reduce hardware requirements by supporting integrated co-location of a variety of the GPRS/UMTS services.
A chassis can be devoted solely to SGSN services or the SGSN system can include any co-location combination, such as multiple instances of 2.5G SGSNs; or multiple instances of 3G SGSNs; or a combination of 2.5G and 3G SGSN to comprise a dual access SGSN.
 
Dual Access 2.5G/3G SGSNs
 
SGSN/GGSN Deployments
The co-location of the SGSN and the GGSN in the same chassis facilitates handover. Again, it can be any type of SGSN, 2.5G or 3G, with the GGSN.
 
Co-located SGSN and GGSN
 
SGSN Logical Network Interfaces
The SGSN provides IP-based transport on all RAN and Core Network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-PS). This means enhanced performance, future-proof scaling and reduction of inter-connectivity complexity. The all-IP functionality is key to facilitating evolution to the next generation technology requirements.
The SGSN provides the following functions over the logical network interfaces illustrated above:
IuPS: The SGSN provides an IP over ATM (IP over AAL5 over ATM) interface between the SGSN and the RNCs in the 3G UMTS Radio Access Network (UTRAN). RANAP is the control protocol that sets up the data plane (GTP-U) between these nodes. SIGTRAN (M3UA/SCTP) or QSAAL (MTP3B/QSAAL) handle IuPS-C (control) for the RNCs.
Some of the procedures supported across this interface are:
Gb: This is the SGSN’s interface to the base station system (BSS) in a 2G radio access network (RAN). It connects the SGSN via UDP/IP (via an Ethernet interface) or Frame Relay (via a Channelized SDH or SONET interface). Gb-IP is the preferred interface as it improves control plane scaling as well as facilitates the deployment of SGSN Pools.
Some of the procedures supported across this interface are:
Gn/Gp: The Gn/Gp interfaces, comprised of GTP/UDP/IP-based protocol stacks, connect the SGSNs and GGSNs to other SGSNs and GGSNs within the same PLMN (the Gn) or to GGSNs in other PLMNs (the Gp).
This implementation supports:
As well, the SGSN can support the following IEs from later version standards:
Gr: This is the interface to the HLR. It supports SIGTRAN (M3UA/SCTP/IP) over Ethernet.
Some of the procedures supported by the SGSN on this interface are:
Ga: The SGSN uses the Ga interface with GTP Prime (GTPP) to communicate with the charging gateway (CG, also known as CGF) and/or the GTPP Storage Server (GSS). The interface transport layer is typically UDP over IP but can be configured as TCP over IP for:
The charging gateway handles buffering and pre-processing of billing records and the GSS provides storage for Charging Data Records (CDRs). For additional information regarding SGSN charging, refer to the Charging section.
Gd: This is the interface between the SGSN and the SMS Gateway (SMS-GMSC / SMS-IWMSC) for both 2G and 3G technologies through multiple interface mediums. Implementation of the Gd interface requires purchase of an additional license.
Gs: This is the interface used by the SGSN to communicate with the visitor location register (VLR) or mobile switching center (MSC) to support circuit switching (CS) paging initiated by the MSC. This interface uses Signaling Connection Control Part (SCCP) connectionless service and BSSAP+ application protocols.
Gf: Interface is used by the SGSN to communicate with the equipment identity register (EIR) which keeps a listing of UE (specifically mobile phones) being monitored. The SGSN’s Gf interface implementation supports functions such as:
 
Features and Functionality - Basic
The 2.5G and 3G SGSNs support a broad range of features and functionality - all fully compliant with 3GPP standards. The following is a list of some of the basic features supported by the SGSN:
 
 
All-IP Network (AIPN)
AIPN provides enhanced performance, future-proof scaling and reduction of inter-connectivity complexity.
In accordance with 3GPP, the SGSN provides IP-based transport on all RAN and core network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-Data). The all-IP functionality is key to facilitating Iu and Gb Flex (SGSN pooling) functionality as well as evolution to the next generation technology requirements.
 
SS7 Support
The ASR 5000 SGSN implements SS7 functionality to communicate with the various SS7 network elements, such as HLRs and VLRs.
The SGSN employs standard SS7 addressing (point codes) and global title translation. SS7 feature support includes:
 
PDP Context Support
Support for subscriber primary and secondary Packet Data Protocol (PDP) contexts in compliance with 3GPP standards ensure complete end-to-end GPRS connectivity.
The SGSN supports a total of 11 PDP contexts per subscriber. Of the 11 PDP context, all can be primaries, or 1 primary and 10 secondaries or any combination of primary and secondary. Note that there must be at least one primary PDP context in order for secondaries to establish.
PDP context processing supports the following types and functions:
 
Mobility Management
The SGSN supports mobility management (MM) in compliance with applicable 3GPP standards and procedures to deliver the full range of services to the mobile device. Some of the procedures are highlighted below:
 
GPRS Attach
The SGSN is designed to accommodate a very high rate of simultaneous attaches. The actual attach rate depends on the latencies introduced by the network and scaling of peers. In order to optimize the entire signaling chain, the SGSN eliminates or minimizes bottlenecks caused by large scale control signaling. For this purpose, the SGSN implements features such as an in-memory data-VLR and SuperCharger. Both IMSI and P-TMSI based attaches are supported.
The SGSN provides the following mechanisms to control MN attaches:
Attached Idle Timeout - When enabled, if an MN has not attempted to setup a PDP context since attaching, this timer forces the MN to detach with a cause indicating that the MN need not re-attach. This timer is particularly useful for reducing the number of attached subscribers, especially those that automatically attach at power-on.
Detach Prohibit - When enabled, this mechanism disables the Attached Idle Timeout functionality for selected MNs which aggressively re-attach when detached by the network.
Prohibit Reattach Timer - When enabled, this timer mechanism prevents MNs, that were detached due to inactivity, from re-attaching for a configured period of time. Such MNs are remembered by the in-memory data-VLR until the record needs to be purged.
Attach Rate Throttle - It is unlikely that the SGSN would become a bottleneck because of the SGSN’s high signaling rates. However, other nodes in the network may not scale commensurately. To provide network overload protection, the SGSN provides a mechanism to control the number of attaches occurring through it on a per second basis.
Beside configuring the rate, it is possible to configure the action to be taken when the overload limit is reached. See the network-overload-protection command in the “Global Configuration Mode” chapter in the Command Line Interface Reference. Note, this is a soft control and the actual attach rate may not match exactly the configured value depending on the load conditions.
 
GPRS Detach
The SGSN is designed to accommodate a very high rate of simultaneous detaches. However, the actual detach rate is dependent on the latencies introduced by the network and scaling of peers. A GPRS detach results in the deactivation of all established PDP contexts.
There are a variety of detaches defined in the standards and the SGSN supports the following detaches:
MN Initiated Detach - The MN requests to be detached.
SGSN Initiated Detach - The SGSN requests the MN to detach due to expiry of a timer or due to administrative action.
HLR Initiated Detach - The detach initiated by the receipt of a cancel location from the HLR.
Mass detaches triggered by administrative commands are paced in order to avoid flooding the network and peer nodes with control traffic.
 
Paging
CS-Paging is initiated by a peer node - such as the MSC - when there is data to be sent to an idle or unavailable UE. CS-paging requires the Gs interface. This type of paging is intended to trigger a service request from the UE. If necessary, the SGSN can use PS-Paging to notify the UE to switch channels. Once the UE reaches the connected state, the data is forwarded to it.
Paging frequency can be controlled by configuring a paging-timer.
 
Service Request
The Service Request procedure is used by the MN in the PMM Idle state to establish a secure connection to the SGSN as well as request resource reservation for active contexts.
The SGSN allows configuration of the following restrictions:
 
Authentication
The SGSN authenticates the subscriber via the authentication procedure. This procedure is invoked on attaches, PDP activations, inter-SGSN routing Area Updates (RAUs), and optionally on configurable periodic RAUs. The procedure requires the SGSN to retrieve authentication quintets/triplets from the HLR (AuC) and issuing an authentication and ciphering request to the MN. The SGSN implements an in-memory data-VLR functionality to pre-fetch and store authentication vectors from the HLR. This decreases latency of the control procedures.
Additional configuration at the SGSN allows for the following:
 
P-TMSI Reallocation
The SGSN supports standard Packet-Temporary Mobile Identity (P-TMSI) Reallocation procedures to provide identity confidentiality for the subscriber.
The SGSN can be configured to allow or prohibit P-TMSI reallocation on the following events:
The SGSN reallocates P-TMSI only when necessary.
 
Identity Request
This procedure is used to retrieve IMSI and IMEI-SV from the MN. The SGSN executes this procedure only when the MN does not provide the IMSI and the MM context for the subscriber is not present in the SGSN’s data-VLR.
 
Location Management
The SGSN’s 3GPP compliance for location management ensures efficient call handling for mobile users.
The SGSN supports routing area updates (RAU) for location management. The SGSN implements standards based support for:
The design of the SGSN allows for very high scalability of RAUs. In addition, the high capacity of the SGSN and Flex functionality provides a great opportunity to convert high impact Inter-SGSN RAUs to lower impact Intra-SGSN RAUs. The SGSN provides functionality to enforce the following RAU restrictions:
The SGSN also provides functionality to optionally supply the following information to the MN:
 
Multiple PLMN Support
With this feature, the 2.5G and 3G SGSNs now support more than one PLMN ID per SGSN. Multiple PLMN support facilitates MS handover from one PLMN to another PLMN.
Multiple PLMN supportalso means an operator can 'hire out' their infrastructure to other operators who may wish to use their own PLMN IDs. As well, multiple PLMN support enables an operator to assign more than one PLMN ID to a cell-site or an operator can assign each cell-site a single PLMN ID in a multi-cell network (typically, there are no more than 3 or 4 PLMN IDs in a single network).
This feature is enabled by configuring, within a single context, multiple instances of either an IuPS service for a single 3G SGSN service or multiple GPRS services for a 2.G SGSN. Each IuPS service or GPRS service is configured with a unique PLMN ID. Each of the SGSN and/or GPRS services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context.
 
Intra/Inter SGSN Serving Radio Network Subsystem (RNS) Relocation (3G only)
Implemented according to 3GPP standard, the SGSN supports both inter- and intra-SGSN RNS relocation (SRNS) to enable handover of an MS from one RNC to another RNC.
The relocation feature is triggered by subscribers (MS/UE) moving from one RNS to another. If the originating RNS and destination RNS are connected to the same SGSN but are in different routing areas, the behavior triggers an intra-SGSN Routing Area Update (RAU). If the RNS are connected to different SGSNs, the relocation is followed by an inter-SGSN RAU. This feature is configured through the Operator Policy Configuration Mode.
 
Equivalent PLMN
This feature is useful when an operator deploys both GPRS & UMTS access in the same radio area and each radio system broadcasts different PLMN codes. It is also useful when operators have different PLMN codes in different geographical areas, and the operators’ networks in the various geographical areas need to be treated as a single HPLMN.
This feature allows the operator to consider multiple PLMN codes for a single subscriber belonging to a single home PLMN (HPLMN). This feature also allows operators to share infrastructure and it enables a UE with a subscription with one operator to access the network of another operator.
 
Network Sharing
In accordance with 3GPP TS 23.251, the SGSN provides an operator the ability to share the RAN and/or the core network with other operators. Depending upon the resources to be shared, there are 2 network sharing modes of operation: the Gateway Core Network (GWCN) and the Multi-Operator Core Network (MOCN).
 
Benefits of Network Sharing
Network sharing provides operators with a range of logistical and operational benefits:
 
GWCN Configuration
With a gateway core network configuration, the complete radio access network and part of the core network are shared (for example, MSC/SGSN) among different operators, while each operator maintains its own separate network nodes (for example, GGSN/HLR).
 
GWCN-type Network Sharing
With the GWCN configuration, the SGSN supports two scenarios:
 
MOCN Configuration
In the multi-operator core network configuration, the complete radio network is shared among different operators, while each operators maintains its own separate core network.
 
MOCN-type Network Sharing
With the MOCN configuration, the SGSN supports the following scenarios:
 
Implementation
To facilitate network sharing, the SGSN implements the following key features:
Configuration for network sharing is accomplished by defining:
For commands and information on network sharing configuration, refer to the Service Configuration Procedures section in the SGSN Administration Guide and the command details in the Command Line Interface Reference.
 
Session Management
Session management ensures proper PDP context setup and handling.
For session management, the SGSN supports four 3GPP-compliant procedures for processing PDP contexts:
 
PDP Context Activation
The PDP context activation procedure establishes a PDP context with the required QoS from the MN to the GGSN. These can be either primary or secondary contexts. The SGSN supports a minimum of 1 PDP primary context per attached subscriber, and up to a maximum of 11 PDP contexts per attached subscriber.
The PDP context types supported are:
Both dynamic and static addresses for the PDP contexts are supported.
The SGSN provides configuration to control the duration of active and inactive PDP contexts.
When activating a PDP context the SGSN can establish the GTP-U data plane from the RNC through the SGSN to the GGSN or directly between the RNC and the GGSN (one tunnel).
The SGSN is capable of interrogating the DNS infrastructure to resolve the specified APN to the appropriate GGSN. The SGSN also provides default and override configuration of QoS and APN.
 
PDP Context Modification
This procedure is used to update the MN and the GGSN. The SGSN is capable of initiating the context modification or negotiating a PDP context modification initiated by either the MN or the GGSN.
 
PDP Context Deactivation
This procedure is used to deactivate PDP contexts. The procedure can be initiated by the MN or the SGSN. The SGSN provides configurable timers to initiate PDP deactivation of idle contexts as well as active contexts.
 
PDP Context Preservation
The SGSN provides this functionality to facilitate efficient radio resource utilization. This functionality comes into play on the following triggers:
 
This is issued by the RAN to request the release of RABs associated with specific PDP contexts. The SGSN responds with a RAB assignment request, waits for the RAB assignment response and marks the RAB as having been released. The retention of the PDP contexts is controlled by configuration at the SGSN. If the PDP contexts are retained the SGSN is capable of receiving downlink packets on them.
The RAN issues an Iu release request to release all RABs of an MN and the Iu connection. The retention of the PDP contexts is controlled by configuration at the SGSN. When PDP contexts are retained the SGSN is capable of receiving downlink packets on them.
When PDP contexts are preserved, the RABs can be restored on a service request from the MN without having to go through the PDP context establishment process again. The service request is issued by the MN either when it has some data to send or in response to a paging request, on downlink data, from the SGSN.
 
Charging
To provide efficient and accurate billing for calls and SMS passing through the SGSN, the system:
 
 
SGSN Call Detail Records (S-CDRs)
These charging records are generated for PDP contexts established by the SGSN. They contain attributes as defined in TS 32.251 v7.2.0.
 
Mobility Call Detail Records (M-CDRs)
These charging records are generated by the SGSN’s mobility management (MM) component and correspond to the mobility states. They contain attributes as defined in 3GPP TS 32.251 v7.2.0.
 
Short Message Service CDRs
SGSN supports following CDRs for SMS related charging:
 
These charging records are generated by the SGSN’s Short Message Service component. They contain attributes as defined in 3GPP TS 32.215 v5.9.0.
 
Overcharging Protection
In releases 9.0 and higher, Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs.
When a mobile is streaming or downloading files from external sources (for example, via a background or interactive traffic class) and the mobile goes out of radio coverage, the GGSN is unaware of such loss of connectivity and continues to forward the downlink packets to the SGSN.
Previously, upon loss of radio coverage (LORC), the SGSN did not perform the UPC procedure to set QoS to 0kbps, as it does when the traffic class is either streaming or conversational. Therefore, when the SGSN did a Paging Request, if the mobile did not respond the SGSN would simply drop the packets without notifying the GGSN; the G-CDR would have increased counts but the S-CDR would not, causing overcharges when operators charged the subscribers based on the G-CDR.
Now operators can accommodate this situation, they can configure the SGSN to set QoS to 0kbps upon detecting the loss of radio coverage. The overcharging protection feature relies upon a proprietary private extension to GTP LORC Intimation IE messages. This LORC Intimation IE is included in UPCQ, DPCQ, DPCR and SGSN Context Response GTP messages. One of the functions of these messages, notify the GGSN to prevent overcharging.
The following table summarizes the SGSN's actions when radio coverage is lost or regained and LORC overcharging protection is enabled.
Overcharging Protection - SGSN Actions
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the command to configure the GTPC private extension and refer to the IuPS Service Configuratioin Mode chapter of the Command Line Interface Reference to configure the LORC Cause IE.
 
NPU FastPath
NPU FastPath’s proprietary internal direct tunnel optimizes resource usage and reduces latency when processing GTP-U packets. This proprietary feature is only available on the ASR 5000 SGSN.
Incoming traffic passes through the switch fabric and the routing headers are changed to re-route traffic from the incoming network processing unit (NPU) of the ingress PSC directly to the outgoing NPU of the egress PSC. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.
 
SGSN NPU FastPath
FastPath is established when both ends of a tunnel are available. Two FastPath flows are established, one for the uplink and one for the downlink direction for a given PDP context. FastPath will temporarily go down or be disengaged so that packets temporarily do not move through FastPath when either an Intra-SGSN RAU or an Iu-Connection Release occurs.
If FastPath cannot be established, the NPU forwards the GTP-U packets to a CPU for processing and they are processed like all other packets.
FastPath can not be established for subscriber PDP sessions if:
For NPU fast path configuration, refer to Enabling NPU Fast Path for GTP-U Processing section of “Service Configuration Procedures” chapter of SGSN Administration Guide.
 
Operator Policy
The non-standard operator policy feature is unique to the ASR 5000 SGSN. This feature empowers the carrier with unusual and flexible control to manage functions that aren’t typically used in all applications and to determine the granularity of the implementation of any operator policy: to groups of incoming calls or to simply one single incoming call.
 
What an Operator Policy Can Do
An SGSN operator policy enables the operator to define a policy with rules governing the services, facilities and privileges available to subscribers depending on factors such as:
 
These policies can override standard behaviors and provide mechanisms for an operator to circumvent the limitations of other infrastructure elements such as DNS servers and HLRs. By configuring an operator policy, the operator fine-tunes any desired restrictions or limitations needed to control call handling and this can be done for a group of callers within a defined IMSI range or per subscriber.
For example, on APN resolution, DNS servers can be configured to return a list of IP addresses of GGSNs. However, this only allows the implementation of an equal-weight round-robin scheme for distribution of load. The operator policy configuration can provide finer control.
In another example, it is not unusual for a blanket configuration to be implemented for all subscriber profiles stored in the HLR. This results in a waste of resources, such as the allocation of the default highest QoS setting for all subscribers. The operator policy provides the opportunity to address such issues by allowing fine-tuning of certain aspects of profiles fetched from HLRs and if desired overwrite QoS settings received from HLR.
 
How the Operator Policies Work
The specific operator policy that is applied is selected on the basis of the subscribers IMSI at attach time, and optionally the PLMN ID selected by the subscriber or the RAN node’s PLMN ID.
The following flow diagram maps out the logic for applying operator policies.
 
Logic Diagram for Policy Selection
Unique, non-overlapping, IMSI + PLMN-ID ranges create call filters that are used to distinguish between the configured operator-policies. These filtering ranges are defined using the mcc command documented in the “SGSN Operator Policy Configuration Mode” chapter of the Command Line Interface Reference
The system supports up to 1000 operator policies, including the operator policy named default. All operator policies must be configured by the user to define limitations to be applied but for the default policy there is no mcc-command defined IMSI range filter to determine implementation - the default policy applies to any IMSIs that are not covered by any other defined operator policy.
 
Some Configurable Features for Operator Policies
The following is a list of some of the features and functions that can be controlled via configuration of SGSN Operator Policies:
 
Default APN
Operators can configure a “default APN” for subscribers not provisioned in the HLR. This feature is available in releases 8.1 and higher.
The Default APN feature will be used in error situations when the SGSN cannot select a valid APN via the normal APN selection process. Within an operator policy, a default APN can be configured for the SGSN to:
In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.
Refer to the SGSN Operator Policy Configuration Mode in the Command Line Interface Reference for the command to configure this feature.
 
VLR Pooling via the Gs Interface
VLR Pooling, also known as Gs Pooling, helps to reduce call delays and call dropping, when the MS/UE is in motion, by routing a service request to a core network (CN) node with availbale resources.
VLR pools are configured in the Gs Service, which supports the Gs interface configuration for communication with VLRs and MSCs.
A pool area is a geographical area within which an MS/UE can roam without the need to change the serving CN node. A pool area is served by one or more CN nodes in parallel. All the cells, controlled by an RNC or a BSC belong to the same one (or more) pool area(s).
VLR hash is used when a pool of VLRs is serving a particular LAC (or list of LACs). The selection of VLR from this pool is based on the IMSI digits. From the IMSI, the SGSN derives a hash value (V) using the algorithm: [(IMSI div 10) modulo 1000]. Every hash value (V) from the range 0 to 999 corresponds to a single MSC/VLR node. Typically many values of (V) may point to the same MSC/VLR node.
For commands and information for VLR pooling configuration, refer to the “Gs Service Configuration Mode” chapter in the Command Line Interface Reference and the VLR Pooling in Service Configuration Procedure section in the SGSN Administration Guide.
 
HSPA Fallback
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.
The SGSN can now limit data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot support higher data rates - such as those enabled by HSPA+ (theoretically, up to 256 Mbps both downlink and uplink). Being able to specify the QoS individually for each RNC makes it possible for operators to allow their subscribers to move in-and-out of coverage areas with different QoS levels, such as those based on 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+).
For example, when a PDP context established from an RNC with 21 Mbps is handed off to an RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated to 16 Mbps. Note that an MS/UE may choose to drop the PDP context during the QoS renegotiation to a lower value.
This data rate management per RNC functionality is enabled, in the radio network controller (RNC) configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rates or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode chapter in the Command Line Interface Reference.
 
Local QoS Capping
The operator can configure a cap or limit for the QoS bit rate.
The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
Depending upon the keywords included in the command, the SGSN can:
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
 
Tracking Usage of GEA Encryption Algorithms
GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity based on the GEAx level used - GEA1, GEA2, or GEA3.
Operators would like to be able to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool can also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity.
New fields and counters have been added to the output generated by the show subscribers gprs-only|sgsn-only summary command. This new information enables the operator to track the number of subscribers capable of GEA0-GEO3 and to easily see the number of subscribers with negotiated GEAx levels.
 
Features and Functionality - Enhanced and Licensed
Enhanced features add or expand the capabitilies of the SGSN beyond basic levels of operation. All of these features comply with relevant 3GPP specifications. All of these features require the purchase of an additional license to implement the functionality on the SGSN.
The following is an alphabetical list of the enhanced features:
 
Direct Tunnel
In accordance with standards, one tunnel functionality enables the SGSN to establish a direct tunnel at the user plane level - a GTP-U tunnel, directly between the RAN and the GGSN.
 
GTP-U with Direct Tunnel
In effect, a direct tunnel reduces data plane latency as the tunnel functionality acts to remove the SGSN from the data plane and limit the SGSN to the control plane for processing. This improves the user experience (e.g., expedites web page delivery, reduces round trip delay for conversational services). Additionally, direct tunnel functionality implements the standard “SGSN optimization” to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN to handle the user plane processing.
Typically, the SGSN establishes a direct tunnel at PDP context activation using an Update PDP Context Request towards the GGSN. This means a significant increase in control plane load on both the SGSN and GGSN components of the packet core. Hence, deployment requires highly scalable GGSNs since the volume and frequency of Update PDP Context messages to the GGSN will increase substantially. The system’s platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
For more information on Direct Tunnel configuration, refer to the SGSN Direct Tunnel Configuration chapter in the System Enhanced Feature Configuration Guide.
 
Lawful Intercept
The SGSN supports lawful interception (LI) of subscriber session information to provide telecommunication service providers (TSPs) with a mechanism to assist law enforcement agencies (LEAs) in the monitoring of suspicious individuals (referred to as targets) for potential criminal activity.
 
How LI Works
Law enforcement agencies (LEAs) provide one or more telecommunication service providers (TSPs) with court orders or warrants requesting the monitoring of a particular target. The targets are identified by information such as their mobile station Integrated Services Digital Network (MSISDN) number, or their International Mobile Subscriber Identification (IMSI) number, or their International Mobile Equipment Identity (IMEI-SV).
Once the target has been identified, the SGSN serves as an access function (AF) and performs monitoring for either new PDP contexts (“camp-on”) or PDP contexts that are already in progress. While monitoring, the system intercepts and duplicates Content of Communication (CC) and/or Intercept Related Information (IRI) and forwards it to a Delivery Function (DF) over an extensible, proprietary interface.
So, when a target establishes multiple, simultaneous PDP contexts, the system intercepts CC and IRI for each of them. The DF, in turn, delivers the intercepted content to one or more Collection Functions (CFs).
Some commands for lawful intercept configuration and operations are described in the Command Line Interface Reference. For detailed information, please contact your account representative.
 
QoS Traffic Policing per Subscriber
Traffic policing enables the operator to configure and enforce bandwidth limitations on individual PDP contextsf for a particular traffic class.
Traffic policing typically deals with eliminating bursts of traffic and managing traffic flows in order to comply with a traffic contract.
The SGSN conforms to the DiffServ model for QoS by handling the 3GPP defined classes of traffic, QoS negotiation, DSCP marking, traffic policing, and support for HSDPA/HSUPA.
 
QoS Classes
The 3GPP QoS classes supported by the SGSN are:
The SGSN is capable of translating between R99 and R97/98 QoS attributes.
 
QoS Negotiation
On PDP context activation, the SGSN calculates the QoS allowed, based upon:
Subscribed QoS - This is a per-APN configuration, obtained from the HLR on an Attach. It specifies the highest QoS allowed to the subscriber for that APN.
Configured QoS - The SGSN can be configured with default and highest QoS profiles in the Operator Policy configuration.
MS requested QoS - The QoS requested by the UE on pdp-context activation.
 
DSCP Marking
The SGSN can perform DSCP marking of the GTP-U packets according to allowed-QoS to PHB mapping. The default mapping matches that of the UMTS to IP QoS mapping defined in 3GPP TS 29.208.
 
Traffic Policing
The SGSN can police uplink and downlink traffic according to predefined QoS negotiated limits fixed on the basis of individual contexts - either primary or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698) algorithm for traffic policing. The algorithm meters an IP packet stream and marks its packets either green, yellow, or red depending upon the following variables:
PIR - Peak Information Rate (measured in bytes/second)
CIR - Committed Information Rate (measured in bytes/second)
PBS - Peak Burst Size (measured in bytes)
CBS - Committed Burst Size (measured in bytes)
The following figure depicts the working of the trTCM algorithm:
 
trTCM Algorithm Logic for Traffic Policing
For commands and information on traffic policing configuration, refer to the Traffic Policing and Shaping and Dynamic QoS Renegotiation chapter in the System Enhanced Feature Configuration Guide.
 
Session Recovery
Session recovery provides a seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault that prevents a fully attached user session from having the PDP contexts removed or the attachments torn down.
Session recovery is performed by mirroring key software processes (e.g., session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode) until they may be needed in the case of a software failure (e.g., a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active control processor (CP) being used.
As well, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processor card (PSC or PSC2) to ensure that a double software fault (e.g., session manager and VPN manager fail at the same time on the same card) cannot occur. The PSC used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.
The additional hardware resources required for session recovery include a standby System Management Card and a standby packet processor card (PSC/PSC2).
There are two modes for Session Recovery.
Task recovery mode: One or more session manager failures occur and are recovered without the need to use resources on a standby packet processor card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processor cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
Full packet processor card recovery mode: Used when a PSC/PSC2 hardware failure occurs, or when a packet processor card migration failure happens. In this mode, the standby packet processor card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processor card perform session recovery.
Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processor cards to ensure task recovery.
When session recovery occurs, the system reconstructs the following subscriber information:
For more information on session recovery use and session recovery configuration, refer to the Session Recovery chapter in the System Enhanced Feature Configuration Guide.
 
SGSN Pooling and Iu-Flex / Gb-Flex
This implementation allows carriers to load balance sessions among pooled SGSNs, to improve reliability and efficiency of call handling, and to use Iu-Flex / Gb-Flex to provide carriers with deterministic failure recovery.
The SGSN, with its high capacity, signaling performance, and peering capabilities, combined with its level of fault tolerance, delivers many of the benefits of Flex functionality even without deploying SGSN pooling.
As defined by 3GPP TS 23.236, the SGSN implements Iu-Flex and Gb-Flex functionality to facilitate network sharing and to ensure SGSN pooling for 2.5G and 3G accesses as both separate pools and as dual-access pools.
SGSN pooling enables the following:
 
Short Message Service (SMS over Gd)
The SGSN implements a configurable Short Message Service (SMS) to support sending and receiving text messages up to 140 octets in length. The SGSN handles multiple, simultaneous messages of both types: those sent from the MS/UE (SMS-MO: mobile originating) and those sent to the MS/UE (SMS-MT: mobile terminating). Short Message Service is disabled by default.
After verifying a subscription for the PLMN’s SMS service, the SGSN connects with the SMSC (short message service center), via a Gd interface, to relay received messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward.
In the reverse, the SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and checks the subscriber state before relaying them to the target MS/UE.
The SGSN will employ both the Page procedure and MNRG (mobile not reachable for GPRS) flags in an attempt to deliver messages to subscribers that are absent.
The SGSN supports
.
For information on configuring and managing the SMS, refer to the SMS Service Configuration Mode chapter in the Command Line Interface Reference.
 
How the SGSN Works
This section illustrates some of the GPRS mobility management (GMM) and session management (SM) procedures the SGSN implements as part of the call handling process. All SGSN call flows are compliant with those defined by 3GPP TS 23.060.
 
First-Time GPRS Attach
The following outlines the setup procedure for a UE that is making an initial attach.
 
 
imple First-Time GPRS Attach
This simple attach procedure can connect an MS via a BSS through the Gb interface (2.5G setup) or it can connect a UE via a UTRAN through the Iu interface in a 3G network with the following process:
First-Time GPRS Attach Procedure
If the MS/UE initiates a second call, the procedure is more complex and involves information exchanges and validations between “old” and “new” SGSNs and “old” and “new” MSC/VLRs. The details of this combined GPRS/IMSI attach procedure can be found in 3GPP TS23.060.
 
PDP Context Activation Procedures
The following figure provides a high-level view of the PDP Context Activation procedure performed by the SGSN to establish PDP contexts for the MS with a BSS-Gb interface connection or a UE with a UTRAN-Iu interface connection.
 
 
Call Flow for PDP Context Activation
The following table provides detailed explanations for each step indicated in the figure above.
 
PDP Context Activation Procedure
 
Network-Initiated PDP Context Activation Process
In some cases, the GGSN receives information that requires it to request the MS/UE to activate a PDP context. The network, or the GGSN in this case, is not actually initiating the PDP context activation -- it is requesting the MS/UE to activate the PDP context in the following procedure:
 
 
Network-Initiated PDP Context Activation
The table below provides details describing the steps indicated in the graphic above.
Network Invites MS/UE to Activate PDP Context
 
MS-Initiated Detach Procedure
This process is initiated by the MS/UE for a range of reasons and results in the MS/UE becoming inactive as far as the network is concerned.
 
 
MS-Initiated Combined GPRS/IMSI Detach
The following table provides details for the activity involved in each step noted in the diagram above.
MS-Initiated Combined GPRS/IMSI Detach Procedure
 
Supported Standards
The SGSN services comply with the following standards for GPRS/UMTS wireless data services.
 
IETF Requests for Comments (RFCs)
 
RFC-1034, Domain Names - Concepts and Facilities, November 1987; 3GPP TS 24.008 v7.8.0 (2007-06)
RFC-1035, Domain Names - Implementation and Specification, November 1987; 3GPP TS 23.003 v7.4.0 (2007-06)
RFC-2960, Stream Control Transmission Protocol (SCTP), October 2000; 3GPP TS 29.202 v6.0.0 (2004-12)
RFC-3332, MTP3 User Adaptation Layer (M3UA), September 2002; 3GPP TS 29.202 v6.0.0 (2004-12)
RFC-4187, Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), January 2006
RFC-4666, signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA), September 2006; 3GPP TS 29.202 v6.0.0 (2004-12)
 
3GPP Standards
Release 6 and higher is supported for all specifications unless otherwise noted.
 
3GPP TS 22.041 v8.1.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB) (Release 8)
3GPP TS 23.060 v7.4.0 (2007-03), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2
3GPP TS 23.107 v7.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture
3GPP TS 23.236 v7.0.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes (Release 7)
3GPP TS 23.251 v7.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description
3GPP TS 24.008 v6.16.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3; some features support v7.8.0 (2007-06) and v7.12.0 (2007-06)
3GPP TS 25.410 v6.5.0 (2006-03) and v7.0.0 (2006-03), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: general aspects and principles
3GPP TS 25.411 v7.0.0 (2006-03) and (2007-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface layer 1
3GPP TS 25.412 v7.1.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signaling transport
3GPP TS 25.413 v6.14.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signaling; some features support v7.6.0 (2007-06)
3GPP TS 25.414 v7.1.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport & transport signaling
3GPP TS 25.415 v6.3.0 (2006-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols
3GPP TS 29.002 v6.15.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification
3GPP TS 29.016 v6.0.0 (2004-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Serving GPRS Support Node SGSN - Visitors Location Register (VLR); Gs Interface Network Service Specification
3GPP TS 29.018 v6.5.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR) Gs interface layer 3 specification
3GPP TS 29.060 v6.17.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface
3GPP TS 29.202 v8.0.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group Core Network; SS7 signaling Transport in Core Network; Stage 3
3GPP TS 32.215 v5.9.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain
3GPP TS 32.251 v7.4.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging
3GPP TS 32.298 v7.4.0 (2007-10), 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging Data Record (CDR) parameter description
3GPP TS 33.102 v6.5.0 (2005-12), Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;3G Security; Security architecture
3GPP TS 33.107 v6.4.0 (2004-12), 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful interception architecture and functions
3GPP TS 44.064 v7.1.0 (2007-03), 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) layer specification
3GPP TS 48.014 v7.3.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gb Interface
3GPP TS 48.016 v7.3.0 (2006-12), 3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Network Service
3GPP TS 48.018 v7.10.0 (2007-06), 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)
 
ITU Standards
 
Q711; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q712; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q713; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q714; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q715; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q716; 3GPP TS 29.002 v6.15.0 (2007-12), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q771; 3GPP TS 29.002 v6.15.0 (2007-12)
Q772; 3GPP TS 29.002 v6.15.0 (2007-12)
Q773; 3GPP TS 29.002 v6.15.0 (2007-12)
Q774; 3GPP TS 29.002 v6.15.0 (2007-12)
Q775; 3GPP TS 29.002 v6.15.0 (2007-12)
 
Object Management Group (OMG) Standards
 
 
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883