Serving GPRS Support Node (SGSN) Overview

Features and Functionality

It is impossible to list all of the features supported by the ASR 5000 2.5G and/or 3G SGSN.

Those features listed below are only a few of the features that enable the operator to control the SGSN and their network. All of these features are either proprietary or comply with relevant 3GPP specifications.

Some of the proprietary features may require a separate license. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations section in the System Administration Guide.

The following is an alphabetical list of the features described in this overview:

3G-2G Location Change Reporting

With Location Change Reporting enabled, the SGSN facilitates location-based charging on the GGSN by providing the UE’s geographical location information when the UE is in connected mode.

Location-based charging is a values-added function that ensures subscribers pay a premium for location-based services, such as service in a congested areas. With the required feature license installed, the operator uses the CLI to enable the reporting independently for each network access type: GPRS (2G) or UMTS (3G).

For more information about how the feature works and how to configure it, refer to the 3G-2G Location Change Reporting feature section.

Accounting Path Framework, New for 14.0

As of Release 14.0, the SGSN uses a new accounting path framework to support PSC3 numbers of 8 million attached subs and 16 million PDP contexts. In the old accounting path framework, there was one AAA session per sub-session in the Session manager and one archive session per sub-session in AAA manager. As part of the new accounting path framework there is only one AAA session per call in the Session manager and one archive session per call in the AAA manager. Also, there is an additional accounting session in the Session manager and the AAA manager per sub-session. The new accounting path framework improves memory and CPU utilization and prevents tariff or time limit delay. There are no changes in the CLI syntax to support the new accounting path and the existing accounting behavior of SGSN is not modified.

APN Aliasing

In many situations, the APN provided in the Activation Request is unacceptable – perhaps it does not match with any of the subscribed APNs or it is misspelled – and would result in the SGSN rejecting the Activation Request. The APN Aliasing feature enables the operator to override an incoming APN – specified by a subscriber or provided during the APN selection procedure (TS 23.060) – or replace a missing APN with an operator-preferred APN.

The APN Aliasing feature provides a set of override functions: Default APN, Blank APN, APN Remapping, and Wildcard APN to facilitate such actions as:

overriding a mismatched APN with a default APN.
overriding a missing APN (blank APN) with a default or preferred APN.
overriding an APN on the basis of charging characteristics.
overriding an APN by replacing part or all of the network or operator identifier with information defined by the operator, for example, MNC123.MCC456.GPRS could be replaced by MNC222.MCC333.GPRS.
overriding an APN for specific subscribers (based on IMSI) or for specific devices (based on IMEI).

Default APN

Operators can configure a “default APN” for subscribers not provisioned in the HLR. 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 APN remap table, a default APN can be configured for the SGSN to:

override a requested APN when the HLR does not have the requested APN in the subscription profile.
provide a viable APN if APN selection fails because there was no “requested APN” and wildcard subscription was not an option.

In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.

Recently, the SGSN’s default APN functionality was enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a webpage informing the user of the error and prompting to subscribe for services.

APN Redirection per APN with Lowest Context-ID

The APN Redirection per APN with Lowest Context-ID feature adds the flexibility to select the subscription APN with the least context ID when the APN is not found in the subscription. SGSN already provides sophisticated APN replacement with support for first-in-subscription, default APN, blank APN, and wildcard APN. This latest feature works along similar lines providing further flexibility to the operator in allowing activations when the MS requested APN is incorrect, misspelled, or not present in the subscription.

The SGSN's APN selection procedure is based on 3GPP 23.060 Annex A, which this feature extends based on CLI controls under the APN Remap Table configuration mode.

APN Resolution with SCHAR or RNC-ID

It is now possible to append charging characteristic information to the DNS string. The SGSN includes the profile index value portion of the CC as binary/decimal/hexadecimal digits (type based on the configuration) after the APN network identification. The charging characteristic value is taken from the subscription record selected for the subscriber during APN selection. This enables the SGSN to select a GGSN based on the charging characteristics information.

After appending the charging characteristic the DNS string will take the following form: <apn_network_id>.<profile_index>.<apn_operator_id >. The profile index in the following example has a value 10: quicknet.com.uk.1010.mnc234.mcc027.gprs.

If the RNC_ID information is configured to be a part of the APN name, and if inclusion of the profile index of the charging characteristics information is enabled before the DNS query is sent, then the profile index is included after the included RNC_ID and the DNS APN name will appear in the following form: <apn_network_id>.<rnc_id>.<profile_index>.<apn_operator_id>. In the following example, the DNS query for a subscriber using RNC 0321 with the profile index of value 8 would appear as: quicknet.com.uk.0321.1000.mnc234.mcc027.gprs.

Automatic Protection Switching (APS)

Automatic protection switching (APS is now available on an inter-card basis for SONET configured CLC2 (Frame Relay) and OLC2 (ATM) optical line cards. Multiple switching protection (MSP) version of is also available for SDH configured for the CLC2 and OLC2 (ATM) line cards.

APS/MSP offers superior redundancy for SONET/SDH equipment and supports recovery from card failures and fiber cuts. APS allows an operator to configure a pair of SONET/SDH lines for line redundancy. In the event of a line problem, the active line switches automatically to the standby line within 60 milliseconds (10 millisecond initiation and 50 millisecond switchover).

At this time, the ASR 5000 APS/MSP supports the following parameters:

1+1 - Each redundant line pair consists of a working line and a protection line.
uni-directional - Protection on one end of the connection.
non-revertive - Upon restoration of service, this parameter prevents the network from automatically reverting to the original working line.

The protection mechanism used for the APS/MSP uses a linear 1+1 architecture, as described in the ITU-T G.841 standard and the Bellcore publication GR-253-CORE, SONET Transport Systems; Common Generic Criteria, Section 5.3. The connection is unidirectional.

With APS/MSP 1+1, each redundant line pair consists of a working line and a protection line. Once a signal fail condition or a signal degrade condition is detected, the hardware switches from the working line to the protection line.

With the non-revertive option, if a signal fail condition is detected, the hardware switches to the protection line and does not automatically revert back to the working line.

Since traffic is carried simultaneously by the working and protection lines, the receiver that terminates the APS/MSP 1+1 must select cells from either line and continue to forward one consistent traffic stream. The receiving ends can switch from working to protection line without coordinating at the transmit end since both lines transmit the same information.

Figure 4. SONET APS 1+1

Refer to the section on Configuring APS/MSP Redundancy in the SGSN Service Configuration Procedures section for configuration details.

Authentications and Reallocations -- Selective

Subscriber event authentication, P-TMSI reallocation, and P-TMSI signature reallocation are now selective rather than enabled by default.

The operator can enable and configure them to occur according to network requirements:

every instance or every nth instance;
on the basis of UMTS, GPRS or both;
on the basis of elapsed time intervals between events.

There are situations in which authentication will be performed unconditionally:

IMSI Attach – all IMSI attaches will be authenticated
When the subscriber has not been authenticated before and the SGSN does not have a vector
When there is a P-TMSI signature mismatch
When there is a CKSN mismatch

There are situation in which P-TMSI will be reallocated unconditionally:

Inter SGSN Attach/RAU
Inter-RAT Attach/RAU in 2G
IMSI Attach

Avoiding PDP Context Deactivations

The SGSN can be configured to avoid increased network traffic resulting from bursts of service deactivations/activations resulting from erroneous restart counter change values in received messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request). Be default, the SGSN has the responsibility to verify 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 SGSN begin deactivation of PDP contexts.

Bulk Statistics Support

System support for bulk statistics allows operators to choose which statistics to view and to configure the format in which the statistics are presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. The following is the list of schemas supported for use by the SGSN:

System: Provides system-level statistics
Card: Provides card-level statistics
Port: Provides port-level statistics
DLCI-Util: Provides statistics specific to DLCIs utilization for CLC-type line cards
EGTPC: Provides statistics specific to the configured ETPC service on the S4-SGSN
GPRS: Provides statistics for LLC, BSSGP, SNDCP, and NS layers
SCCP: Provides SCCP network layer statistics
SGTP: Provides SGSN-specific GPRS Tunneling Protocol (GTP) statistics
SGSN: Provides statistics for: mobility management (MM) and session management (SM) procedures; as well, MAP, TCAP, and SMS counters are captured in this schema. SGSN Schema statistic availability is per service (one of: SGSN, GPRS, MAP) and per routing area (RA)
SS7Link: Provides SS7 link and linkset statistics
SS7RD: Provides statistics specific to the proprietary SS7 routing domains

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the chassis or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, chassis host name, chassis uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

CAMEL Service Phase 3, Ge Interface

The ASR 5000 SGSN provides PDP session support as defined by Customized Applications for Mobile network Enhanced Logic (CAMEL) phase 3.

CAMEL Service

CAMEL service enables operators of 2.5G/3G networks to provide operator-specific services (such as prepaid GPRS service and prepaid SMS service) to subscribers, even when the subscribers are roaming outside their HPLMN.

CAMEL Support

ASR 5000 SGSN support for CAMEL phase 3 services expands with each SGSN application release. Current support enables operators of 2.5G/3G networks to provide operator-specific services (such as prepaid GPRS service and prepaid SMS service) to subscribers, even when the subscribers are roaming outside their HPLMN.

For this release the SGSN has expanded its support for CAMEL Scenario 1 adding:

Implementation of Scenario1 triggers (TDP-Attach, TDP-Attach-ChangeofPosition)
Implementation of Scenario1 Dynamic triggers (DP-Detach, DP-ChangeofPosition)
Expanded conformance to 3GPP spec 23.078 (Release 4)

The ASR 5000 SGSN supports the following GPRS-related functionality in CAMEL phase 3:

Control of GPRS PDP contexts

Functional support for CAMEL interaction includes:

PDP Context procedures per 3GPP TS 29.002
- GPRS TDP (trigger detection point) functions
- Default handling codes, if no response received from SCP
- GPRS EDP (event detection points) associated with SCP
- Charging Procedures: Handle Apply Charging GPRS & Handle Apply Charging Report GPRS
“GPRS Dialogue scenario 2" for CAMEL control with SCP
CAMEL-related data items in an S-CDR:
- SCF Address
- Service Key
- Default Transaction Handling
- Level of CAMEL service (phase 3)
Session Recovery for all calls have an ESTABLISHED CAMEL association.

Ge Interface

The ASR 5000 implementation of CAMEL uses standard CAP protocol over a Ge interface between the SGSN and the SCP. This interface can be deployed over SS7 or SIGTAN.

The SGSN's Ge support includes use of the gprsSSF CAMEL component with the SGSN and the gsmSCF component with the SCP.

CAMEL Configuration

To provide the CAMEL interface on the SGSN, a new service configuration mode, called “CAMEL Service”, has been introduced on the SGSN.

An SCCP Network configuration must be created or exist already.
A CAMEL Service instance must be created.
The CAMEL Service instance must be associated with either the SGSN Service configuration or the GPRS Service configuration in order to enable use of the CAMEL interface.
The CAMEL Service must be associated with the SCCP Network configuration.

Until a CAMEL Service is properly configured, the SGSN will not process any TDP for pdp-context or mo-sms.

Commandguard

Operators can accidentally enter configuration mode via CLI or file replay. To protect against this, SGSN supports commandguard CLI command. Commandguard, which is disabled by default, can only be enabled or disabled from the Global Configuration mode. When Commandguard is enabled it affects the configure and autoconfirm CLI commands by causing them to prompt (Y/N) for confirmation. When autoconfirm is enabled Commandguard has no affect. The commandguard state is preserved in the SCT and, when enabled, is output by the various variants of the show config CLI.

Configurable RAB Asymmetry Indicator in RAB Assignment Request

The SGSN sets the value for the RAB Asymmetry Indicator that is included in the RAB Assignment Request.

In releases prior to R12.0, the SGSN set the RAB asymmetry indicator to "Symmetric-Bidirectional" when downlink and uplink bit rates were equal. Now, the SGSN selects the value based on the symmetry of negotiated maximum bit rates as follows:

If the uplink and downlink bit rates are equal then it is set to “Symmetric-Bidirectional”,
If uplink bit rate is set to 0 kbps, then it is set to “Asymmetric-Unidirectional-Downlink”,
If downlink bit rate is set to 0 kbps, then it is set to “Asymmetric-Unidirectional-Uplink”,
If the uplink and downlink bit rates are non-zero and different, then it is set to “Asymmetric-Bidirectional”.

A change in CLI configuration allows the SGSN to override the above functionality and set the RAB Asymmetry Indicator to “Asymmetric-Bidirectional” when uplink and downlink bit rates are equal. As a result, two sets of bit rates - one for downlink and one for uplink - will be included in the RAB Assignment Requests as mandated in 3GPP TS 25.413.

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. Feature details and configuration procedures are provided in the Direct Tunnel feature section in this guide.

Downlink Data Lockout Timer

Currently, if paging fails after maximum number of retries, the page proceed flag (PPF) is cleared and further downlink data is dropped. The PPF is set to ‘true’ if there is any uplink activity from the UE.

The Downlink Data Lockout Timer is a new, configurable timer added for both GPRS and SGSN services to reduce the frequency of mobile-initiated keep alive messages. If enabled, this timer starts whenever the paging procedure fails after the maximum number of retransmissions and the Page Proceed Flag (PPF) is cleared. If there is any downlink activity when the lockout timer is running, the packets are dropped and the drop cause is set as Page Failed. When the lockout timer expires, the PPF is set to true and further downlink packets are queued and paging is re-initiated. In order to avoid endless paging activity when there is no page response or uplink activity from the UE, an optional configurable repeat count value is used. If the repeat value is configured as 'y' then the lockout timer is started 'y' number of times after page failure. The implementation of the lockout timer is different for 2G/3G subscribers, but the behavior is the same.

DSCP Templates for Control and Data Packets - Iu or Gb over IP

The SGSN supports a mechanism for differentiated services code point (DSCP) marking of control packets and signaling messages for the SGSN’s M3UA level on the Iu interface and for LLC messages for the Gb interface.

This DSCP marking feature enables the SGSN to perform classifying and managing of network traffic and to determine quality of service (QoS) for the interfaces to an IP network.

Implementation of this feature requires the use of several CLIs commands to create one or more reusable templates. These templates set DSCP parameter configuration for downlink control packets and data packets that can be associated with one or more configurations for at the GPRS service level, the peer-NSEI level, the IuPS service level, and the PSP instance level.

Dual PDP Addresses for Gn/Gp

In accordance with 3GPP Release 9.0 specifications, it is now possible to configure SGSN support for dual stack PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix when requested by the MS/UE.

ECMP over ATM

Iu Redundancy is the ASR 5000's implementation of equal-cost multi-path routing (ECMP) over ATM.

Iu Redundancy is based on the standard ECMP multi-path principle of providing multiple next-hop-routes of equal cost to a single destination for packet transmission. ECMP works with most routing protocols and can provide increased bandwidth when traffic load-balancing is implemented over multiple paths.

ECMP over ATM will create an ATM ECMP group when multiple routes with different destination ATM interfaces are defined for the same destination IP address. When transmitting a packet with ECMP, the NPU performs a hash on the packet header being transmitted and uses the result of the hash to index into a table of next hops. The NPU looks up the ARP index in the ARP table (the ARP table contains the next-hop and egress interfaces) to determine the next-hop and interface for sending packets.

Equivalent PLMN

This feature is useful when an operator deploys both GPRS and 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.

First Vector Configurable Start for MS Authentication

Previously, the SGSN would begin authentication towards the MS only after the SGSN received all requested vectors. This could result in a radio network traffic problem when the end devices timed out and needed to re-send attach requests.

Now, the SGSN can be configured to start MS authentication as soon as it receives the first vector from the AuC/HLR while the SAI continues in parallel. After an initial attach request, some end devices restart themselves after waiting for the PDP to be established. In such cases, the SGSN restarts and a large number of end devices repeat their attempts to attach. The attach requests flood the radio network, and if the devices timeout before the PDP is established then they continue to retry, thus even more traffic is generated. This feature reduces the time needed to retrieve vectors over the GR interface to avoid the high traffic levels during PDP establishment and to facilitate increased attach rates.

Gb Manager

A new SGSN proclet has been developed. Now, all the link level procedures related to Gb -

protocol (GPRS-NS and BSSGP) hosting, handling, administration, message distribution,
keeping the other managers informed about the link/remote-node status,
handling functionality of the Gb interface (all 2G signaling)

are removed from the Link Manager and moved to the SGSN's new Gb Manager proclet.

The new Gb Manager provides increased flexibility in handling link level procedures for each access type independently and ensures scalability. The consequence of relieving the Link Manager, of a large amount of message handling, is to decrease delays in sending sscop STAT messages resulting in the detection of link failure at the remote end. Use of this separate new proclet to handle 2G signaling messages means there will not be any MTP link fluctuation towards the RNS, which is seen during the BSC restart or extension activity in the network. As well, this improves the fluctuation towards the 3G connectivity.

GMM-SM Event Logging

To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server.

This feature logs the following events:

Attaches
Activation of PDP Context
RAU
ISRAU
Deactivation of PDP Context
Detaches
Authentications
PDP Modifications

The new SGSN event logging feature is enabled/disabled per service via CLI commands. For more information on this feature, refer to the section GMM/SM Event Logging in this guide.

Gn/Gp Delay Monitoring

The SGSN measures the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN.

If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.

A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.

A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.

This functionality can assist with network maintenance, troubleshooting, and early fault discovery.

GTP-C Path Failure Detection and Management

The SGSN now provides the ability to manage GTP-C path failures detected as a result of spurious restart counter change messages received from the GGSN.

Previous Behavior: The old default behavior was to have the Session Manager (SessMgr) detect GTP-C path failure based upon receiving restart counter changes in messages (Create PDP Context Response or Update PDP Context 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.

Handling Multiple MS Attaches All with the Same Random TLLI

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.

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.

Ignore Context-ID During 4G/3G Handovers

HSS and HLR, when operating as separate network nodes, are required to use the same context-ID for a given APN-configuration of a subscriber. During inter-RAT cell reselections and handovers between 2G/3G and 4G, if the SGSN does not find a matching APN-configuration for the given context-ID learnt from the peer node, then the PDP does not get established. This could result in SRNS relocation failures when none of the PDP's learnt from the SGSN has a matching context-ID in the HLR.

New commands have been added to enable the operator to configure the SGSN to ignore the context-ID provided by the peer and to use the PDP- type and address information to search through HLR subscription and to update the context-ID information within the PDP. For details, refer to the description for the rau-inter command under the Call-Control Profile Configuration Mode Commands section of the Cisco ASR 5x00 GPRS / UMTS Command Line Interface Reference.

Intra- or Inter-SGSN Serving Radio Network Subsystem (SRNS) 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 Call-Control Profile Configuration Mode which is part of the feature set.

Lawful Intercept

The Cisco Lawful Intercept feature is supported on the SGSN. Lawful Intercept is a license-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

Link Aggregation - Horizontal

The SGSN supports enhanced link aggregation (LAG) within ports on different XGLCs. Ports can be from multiple XGLCs. LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs. The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down.

Local DNS

Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.

The SGSN now supports configuration of multiple pools of GGSNs; a primary pool and a secondary. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN, with the primary GGSN pool used first and the secondary used if no primary GGSNs are available.

The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.

Local Mapping of MBR

The SGSN provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value.

The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.

This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN.

IMPORTANT:

To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.

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:

take the QoS parameter configuration from the HLR configuration.
take the QoS parameter configuration from the local settings for use in the APN profile.
during session establishment, apply the lower of either the HLR subscription or the locally configured values.

Location Services

LoCation Services (LCS) on the SGSN is a 3GPP standards-compliant feature that enables the SGSN to collect and use or share location (geographical position) information for connected UEs in support of a variety of location services, such as location-based charging and positioning services. The SGSN uses the Lg interface to the gateway mobile location center (GMLC), which provides the mechanisms to support specialized mobile location services for operators, subscribers, and third party service providers. Use of this feature and the Lg interface is license controlled.

For details about this feature and its configuration, refer to the Location Services section of the SGSN Administration Guide.

Lock/Shutdown the BSC from the SGSN

When the SGSN returns to Active state, after scenarios such as rebooting or reloading, all the BSCs that had been connected to the SGSN would attempt to re-establish connections. This could result in two serious problems for operators:

high CPU usage in the SGSN where too many BSC/RNCs were connected.
network overload when other network nodes cannot match the SGSN's capacity.

The SGSN now supports a Lock/Shutdown feature that provides a two prong solution. CPU Usage Solution: Staggering the BSC auto-learning procedures when the SGSN re-loads will help to reduce the high CPU usage. This can be achieved by the operator locking the NSE/BSCs from the SGSN before reboot/reload and then unlocking them one-by-one to avoid high CPU usage.

Network Overload Solution: A new timer, SNS-GUARD, has been added to clean-up resources if the SNS procedure does not complete properly, whether or not the BSC is administratively locked. Now the SGSN starts this timer after sending SNS-SIZE-ACK and the BSC information will be removed, if the auto-learning clean-up procedure does not complete before the timer expires.

A series of new commands and keywords has been added to enable the operator to configure this new administrative Lock/Shutdown the BSC functionality as part of 'interface management' configuration. For details, refer to the SGSN Global Interface Management section of the Cisco ASR 5x00 GPRS / UMTS Command Line Interface Reference.

Management System Overview

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

The Operation and Maintenance module of the system offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.

These include:

Using the command line interface (CLI)
Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces
Local login through the Console port on SPIO card using an RS-232 serial connection
Using the Web Element Manager (WEM) application (requires a separate license)
Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000
Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO
Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)
Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management
Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities
Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.

Figure 5. Element Management Methods

IMPORTANT:

By default, SGSN management functionality is enabled for console-based access.

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 support also 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.

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:

Enables two or more network operators to share expensive common network infrastructure.
A single operator with multiple MCC-MNC Ids can utilize a single physical access infrastructure and provide a single HPLMN view to the UEs.
Facilitates implementation of MVNOs.

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).

Figure 6. GWCN-type Network Sharing

With the GWCN configuration, the SGSN supports two scenarios:

GWCN with non-supporting UE
GWCN with supporting UE

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.

Figure 7. MOCN-type Network Sharing

With the MOCN configuration, the SGSN supports the following scenarios:

MOCN with non-supporting UE
MOCN with supporting UE

Implementation

To facilitate network sharing, the SGSN implements the following key features:

Multiple virtual SGSN services in a single physical node.
Sharing operators can implement independent policies, such as roaming agreements.
Equivalent PLMN configuration.
RNC identity configuration allows RNC-ID + MCC-MNC instead of just RNC-ID.

Configuration for network sharing is accomplished by defining:

NRI in the SGSN service configuration mode
PLMN IDs and RNC IDs in the IuPS configuration mode
Equivalent PLMN IDs and configured in the Call-Control Profile configuration mode.
IMSI ranges are defined in the SGSN-Global configuration mode
The Call-Control Profile and IMSI ranges are associated in the configuration mode.

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 packet processing card directly to the outgoing NPU of the egress packet processing card. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.

Figure 8. 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:

Traffic Policing and Shaping is enabled.
Subscriber Monitoring is enabled.
Lawful Intercept (LI) is enabled,
IP Source Violation Checks are enabled.
GTP-v0 tunnel is established with an GGSN.

For NPU fast path configuration, refer to Enabling NPU Fast Path for GTP-U Processing section of “Service Configuration Procedures” section of Cisco ASR 5000 Series Serving GPRS Support Node Administration Guide.

NRPCA - 3G

The SGSN supports the Network Requested Primary PDP Context Activation (NRPCA) procedure for 3G attachments.

There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call control profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode.

Operator Policy

The non-standard 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: to groups of incoming calls or to simply one single incoming call. For details about the feature, its components, and how to configure it, refer to the Operator Policy section in this guide.

IMPORTANT:

SGSN configurations created prior to Release 11.0 are not forward compatible. All configurations for SGSNs, with -related configurations that were generated with software releases prior to Release 11.0, must be converted to enable them to operate with an SGSN running Release 11.0 or higher. Your Cisco Representative can accomplish this conversion for you.

Some Features Managed by Operator Policies

The following is a list of some of the features and functions that can be controlled via configuration of Operator Policies:

APN Aliasing
Authentication
Direct Tunnel - for feature description and configuration details, refer to the Direct Tunnel section in this guide
Equivalent PLMN
IMEI Override
Intra- or Inter-SGSN Serving Radio Network Subsystem (SRNS) Relocation (3G only)
Network Sharing
QoS Traffic Policing per Subscriber
SGSN Pooling - Gb/Iu Flex
SuperCharger
Subscriber Overcharging Protection - for feature description and configuration details, refer to the Subscriber Overcharging Protection section in this guide.

Overcharging Protection

Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs in a UMTS network. For details and configuration information, refer to the Subscriber Overcharging Protection section in this book.

QoS Traffic Policing per Subscriber

Traffic policing enables the operator to configure and enforce bandwidth limitations on individual PDP contexts 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:

Conversational
Streaming
Interactive
Background

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 configuration.
MS requested QoS - The QoS requested by the UE on pdp-context activation.

DSCP Marking

The SGSN performs diffserv code point (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.

The SGSN also supports DSCP marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.

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 TCM algorithm:

Figure 9. TCM Algorithm Logic for Traffic Policing

Reordering of SNDCP N-PDU Segments

The SGSN fully supports reordering of out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.

S4 Support on the SGSN

The SGSN can provide an interface between UMTS (3G) and/or GPRS (2.5G) networks and the evolved packet core (EPC) network. This functionality requires a special S4 feature license. Throughout the documentation the SGSN with this additional functionality is referred to as an S4-SGSN.

To facilitate communication with GPRS, UMTS, and EPC networks, the SGSN is configured with standard 2.5G SGSN, 3G SGSN or dual access SGSN services, and then configured with additional enhancements to enable communication with the EPC network.

The S4-SGSN communicates with other UMTS and GPRS core networks elements via the GTPv1 protocol, and communicates with EPC network elements and peer S4-SGSNs via the GTPv2 protocol. The S4-SGSN communicates with the UMTS (3G) / GPRS (2.5G) radio access network elements in the same manner as an SGSN.

Depending on the configured SGSN service type, the S4-SGSN can interface with some or all of the following UMTS/GPRS and EPC network elements:

Serving Gateway (S-GW)
Mobility Management Entity (MME)
Peer S4-SGSN (2.5G or 3G with S4 support)
Peer dual access S4-SGSN
Peer SGSN (2.5G or 3G)
Peer dual access SGSN
GGSN

The S4-SGSN includes the following S4-SGSN specific functionality and features:

S3 and S4 Interface Support

S3 and S4 interface support is a license-enabled feature that enables 2G and 3G networks to interface with the 4G evolved packet core (EPC) network. The S3/S4 functionality ensures session continuity on handovers between 2G/3G subscribers and 4G LTE subscribers. S3/S4 functionality simplifies core network operations the following ways:

Replaces the GGSN in the network with the P-GW
Replaces the need for an HLR by providing connectivity to the HSS
Optimized idle mode signaling during 3G/2G to 4G handovers (when the ISR feature is enabled)

The S3 and S4 interfaces provide control and bearer separation, and offload the backward compatibility requirement from the mobility management entity (MME) and serving gateway (S-GW) EPC elements to the UMTS core.

S3 Interface: Provides a GTPv2-C signaling path connection between the MME and the SGSN (MPC). The S4-SGSN to MME RAU/TAU context handovers are supported via the S3 interface.
S4 Interface: Provides a data and signaling interface between the S-GW and the S4-SGSN (MPC) for bearer plane transport (GTPv2-U). The S4-SGSN communicates with the P-GW via the S-GW.

With support for S3/S4 interface, soft-handoffs between 2G/3G and the EPC networks are possible for multi-mode UEs. Without this functionality, the Gn/Gp SGSN can still inter-work with the EPC core using GTPv1, but soft-handoffs cannot be achieved. Note that GTPv2 to GTPv1 conversions (for QoS and Context IDs) are lossy data conversions, so a subscriber doesn’t encounter a similar type of network behavior while in 2G/3G and 4G networks.

S6d and Gr Interface Support

The S4-SGSN supports the Diameter based S6d interface to the HSS, in addition to the legacy Gr interface to the HLR (used by an SGSN configured to use the Gn/Gp interfaces). This is a license-enabled feature.

The S6d / Gr interface enhancements allow operators to consolidate the HLR/HSS functions into a single node, which improves operational efficiency and other overhead. With the deployment of the EPC core, many operators may consolidate the HLR/HSS functions into a single node. Until then, the S4-SGSN still supports the MAP-based Gr and the Diameter based S6d interfaces.

The SGSN selects the Gr interface / S6d interface based on the MAP or HSS service associated with the configured SGSN and/or GPRS services. If both the services are associated, then SGSN will use the following order of selection:

Select the appropriate interface based on any operator policy preference for S6d / Gr.
If no operator policy is present, then by use the Gr interface by default.

The S4-SGSN sets the following initiate UGL messages on a change of HSS service:

Initial attach indicator bit in Update GPRS Location message, ISR information IE, if the UGL is sent for an initial attach or for a inbound routing area update without ISR activation and the selected interface is Gr.
Initial attach indicator bit in Update Location Request message, ULR flags, if the ULR is sent for an initial attach or for a inbound routing area update without ISR activation and the selected interface is S6d.

DNS SNAPTR Support

By default, the S4-SGSN supports the initiation of a DNS query after APN selection using a S-NAPTR query. The SGSN resolves a P-GW by sending an APN-FQDN query to the DNS client. Similarly, the SGSN resolves the S-GW by sending a RAI-FQDN query to the DNS client. The DNS Client then sends a query to the DNS server to retrieve NAPTR/SRV/A records and return the S-GW or P-GW IP address to the SGSN.

On the S4-SGSN, an additional configurable is available that identifies the context where DNS lookup for EPC-capable UEs must occur. This is accomplished by creating a call control profile that directs the system’s DNS client to perform the lookup in the context where the SGSN’s DNS client is configured.

If the CLI configurable is not used, or removed, the S4-SGSN chooses the DNS client from the context where the EGTP service is configured for performing P-GW DNS resolution, if the EGTP service is associated for a EPC capable UE.

If the EGTP service is not present and the UE is EPC-capable, and if apn-resolve-dns-query snaptr is configured in an APN profile, then the S4-SGSN uses the DNS client in the context where the SGTP service is present for resolving a co-located P-GW/GGSN and selects the Gn interface.

S4-SGSN Statistics Support

Statistics have been added to provide information on S4-SGSN functionality.

The statistics added track information related to:

SGW Relocations
ISR Deactivations
Number of active PDPs using the S4 interface in 3G
S3 Interface Selection Statistics
Procedure Abort Statistics
GTPU Statistics
IDFT Statistics

In addition, support for EGTPC schema bulk statistics is implemented to provide information on communication between the S4-SGSN and the EPC S-GW over the S4 interface.

S13’ Interface Support

In addition to the MAP-based Gf interface, the S4-SGSN supports the Diameter-based S13’ (S13 prime) interface towards the equipment identify registry. The S13’ interface support enables operators to consolidate the EIR functions into a single node, which increases operational efficiency. S13’ interface support is a license-enabled feature.

The S13’ interface enables the S4-SGSN to perform the ME Identity Check procedure to validate the IMEI with the EIR. The S4-SGSN selects Gf or S13’ interface based on which interface is configured and the type of service (MAP or HSS) is associated with the SGSN and/or the GPRS service. If both services are associated, then the S4-SGSN will select the appropriate interface based on the following sequence:

An operator policy preference is configured for Gf or S13’
If no operator policy preference is set, then by default the S4-SGSN uses the Gf interface

By default, the IMSI is sent to the EIR as part of the IMEI Check procedure over the S13’ interface.

Idle Mode Signaling Reduction

The Idle Mode Signaling Reduction (ISR) feature enables a UE to be registered in both UMTS and GPRS networks at the same time it is registered in the E-UTRAN network. To activate the ISR feature, for a UE, ISR functionality must be supported in both the UE and the SGSN, MME, S-GW and HSS. In this release, ISR support is restricted to 3G network access only. ISR is a license-enabled feature.

The ISR feature allows the UE to roam between LTE and 3G networks while reducing the frequency of TAU and RAU procedures due to a UE selecting E-UTRAN or UMTS networks. It reduces the signaling between the UE and network, and also reduces the signaling between the E-UTRAN and UMTS networks.

When ISR is activated on the S4-SGSN, the UE is registered with both the MME and SGSN. Both the SGSN and the MME have a control connection with the S-GW. The MME and SGSN are both registered at the HSS.

The UE stores MM parameters from the SGSN (e.g., P-TMSI and RA) and from the MME (e.g. GUTI and TA(s)) and the UE stores session management (bearer) contexts that are common for access to the E-UTRAN and GPRS/UMTS networks. In an idle state, the UE can re-select between E-UTRAN and GPRS/UMTS networks (within the registered RA and TAs) without being required to perform TAU or RAU procedures with the network.

The network can activate ISR on a per UE basis.

The SGSN and MME store each other's address when ISR is activated.

ISR Deactivation Procedure

If the S4-SGSN has activated ISR for an MS and the MS is in ECM-CONNECTED state through the MME, and if in both the MME and the MS, ISR was deactivated due to any of the following conditions, the S4-SGSN will become aware that ISR is deactivated when the next RAU from the MS is received with P-TMSI mapped from GUTI.

MS has a control connection with the MME and creates a new EPS bearer after ISR is activated. In this case, the UE will deactivate ISR when it initiates RAU to SGSN and sees that there is difference between current bearers, and beaters at the time of ISR activation.
A periodic TAU is missed
There is an HSS initiated EPS bearer deactivation at the MME

If the S4-SGSN receives a RAU request with P-TMSI mapped from GUTI, it will locally clear the MM and PDP contexts of the MS and shall send a Context Request to the MME. The S4-SGSN will then build the MM and PDP contexts based on the Context Response received from MME.

ISD / DSD Message Handling and HSS Initiated Bearer Modification

The Home Subscriber Server (HSS) / Home Location Register (HLR) maintains the subscriber database. Insert Subscriber Data (ISD) and Delete Subscriber Data (DSD) messages are generated by the HSS/HLR. These messages are used to communicate the subscribers current subscription data to the S4-SGSN. The subscription data for a subscriber can include one of the following:

GPRS subscription data.
EPS subscription data.
Both GPRS and EPS subscription data.

The PDP is either modified or deleted based on the subscription data received by the S4-SGSN.

The S4-SGSN deletes the PDP context if any form of barring is detected or if the APN-name or PDP-type of the PDP address is changed. The S4-SGSN modifies the PDP if QoS is changed or APN-AMBR is changed (in case of EPS subscription).

If a PDP modification is required based on the subscription data received but the associated UE is disconnected or in an inactive state, such PDP contexts are deleted by the S4-SGSN.

Note:

The S4-SGSN does not delete the PDP contexts if Idle Mode Signalling Reduction (ISR) is activated or PDP is preserved. In such cases the S4-SGSN initiates a PDP modify only after UE activity is detected.

If the UE is connected or in a ready state, the S4-SGSN sends an updated bearer command (with subscribed QoS) to the S-SGW or P-GW and the P-GW initiates a PDP modify procedure.

HSS initiated bearer modification

The Modify bearer command is a notification sent to the S-GW/P-GW which notifies a change in the subscribed QoS. The message is sent to S-GW/P-GW if the UE is in ready or connected state. Modify Bearer command is not sent when the PDP is in preserved state and when ISR is active, in such cases the S4-SGSN initiated modify request using Modify Bearer Request updates the QoS to the S-GW/P-GW after the PDP is active or UE activity is detected on S4-SGSN respectively.

UMTS-GSM AKA Support on the S4-SGSN

The S4-SGSN provides support for the following UMTS/GSM Authentication and Key Agreement (AKA) procedures:

SRNS relocation
Attach
PTMSI attach (foreign/local)
Service Request
Inter SGSN RAU
Timers Handling
Re-use of Vectors
Using the Peer SGSN/MME vectors (ISRAU/PTMSI attach) in the same or different PLMN

3G and 2G SGSN Routing Area Update

The S4-SGSN supports outbound Routing Area Update (RAU) procedures for a subscriber already attached on that SGSN (that have PDP contexts anchored through S4 interface) and inbound RAU procedures for an EPC capable UE. The RAU procedures are required to enable mobility across the UMTS and EPC core network coverage areas using the S3 interface for context transfers.

The S4-SGSN determines if the old peer node is an MME or SGSN based on the most significant bit of the LAC. If the most significant bit of the LAC is set then the old peer node is an MME (and the RAI is mapped from GUTI). If the bit is not set then the old RAI represents an SGSN.

However, some operators have already used LAC values greater than 32768 (most significant bit set) for their existing UMTS / GPRS networks. For such operators identification of a peer node through MSB bit of LAC will not work. In these cases, operators can use the Configurable GUTI to RAI Conversion Mapping feature.

The following RAU procedures are supported for both 2G and 3G services:

2G and 3G Intra-SGSN RAU with and without S-GW relocation
2G and 3G Inter-SGSN/SGSN-MME RAU with and without S-GW relocation across S16 and S3 interfaces
Intra-SGSN Inter-RAT RAU with and without S-GW relocation

2G and 3G Intra RAU with and without S-GW Relocation

The S4-SGSN supports the intra-SGSN routing area update (ISRAU), which can occur in the following scenarios:

The MS changes its routing area
The periodic RAU timer expires for the MS
The MS changes its network capability

The S4-SGSN also supports intra SGSN, inter PLMN RAU requests. However, if the new PLMN’s operator policy is configured to use the Gn interface, the PDP contexts are not transferred from the S4 interface to the Gn interface.

IMPORTANT:

The S4-SGSN currently does not support the association of a different EGTP service for each PLMN.

2G and 3G Inter-SGSN and Inter SGSN-MME RAU with and without S-GW Relocation Across S16 and S3 Interfaces

The S4-SGSN supports both Inter-SGSN RAU and SGSN-MME RAU, which will be triggered when a UE sends Routing Area Update (RAU) request to a new SGSN in the following scenarios:

The serving RAI changes from one SGSN coverage area to another SGSN coverage area
During a handover from a E-UTRAN coverage area to a UMTS coverage area

Intra-SGSN Inter-RAT RAU with and without S-GW Relocation

The S4-SGSN supports intra-SGSN 3G to 2G routing area updates (RAU) and supports the handover of MM and PDP contexts from the SGSN service to the GPRS service. Similarly, it supports intra-SGSN 2G to 3G RAUs and supports the handover of MM and PDP contexts from the GPRS service to the SGSN service.

IMPORTANT:

Currently, the S4-SGSN expects that both the SGSN and GPRS services will be associated with the same EGTP service for successful intra-SGSN inter-RAT handovers.

IPv4 and IPv6 PDP Type Override

The S4-SGSN supports the override of the IPv4/IPv6 PDP type by either IPv4 or IPv6 when the dual PDP feature is enabled. This is controlled via a call control profile, and is configured independently for 2G GPRS and 3G UMTS access.

Statistics are maintained to track successes and failures for IPv4 and IPv6 PDP activations with override.

P-GW Initiated PDP Bearer Deactivation

The S4-SGSN supports the P-GW initiated PDP deactivation procedure in addition to the legacy MS initiated deactivation procedure.

The S4-SGSN processes Delete Bearer Requests received from the S-GW (sent by the P-GW) and deactivates the requested bearers (PDP contexts) by sending a Deactivate PDP Context Request to the UE and then deactivates the PDP context. If the S4-SGSN receives a Delete Bearer Request from the S-GW and the subscriber is in the PMM-IDLE / GPRS-STANDBY state, it pages the UE before deactivating the PDP context request.

In the case of 3G, the S4-SGSN will initiate RAB release procedures for the deactivated bearers. For 2G there is no RAB release procedure.

S-GW and P-GW Tunnel and EPS Subscription Recovery

The S4-SGSN supports session recovery procedures and recovers the S4 tunnel created for each subscriber assigned PDP contexts through S4 interface. This functionality is part of session recovery procedures and allows sessions to be reconstructed when the system recovers from a card-level software fault.

The SGSN side TEID and the S-GW side TEID for the S4 tunnel are check-pointed and recovered during session recovery. The S4-SGSN also recovers every PDN connection and their corresponding P-GW-side TEID.

The S4-SGSN session recovery procedures have been enhanced to support recovery of EPS subscription data received from the HLR / HSS. The EPS subscription information may contain a maximum of 50 APN profiles and each APN profile contains an APN name string and a PDN GW FQDN string, which is check-pointed and recovered as part of the enhanced session recovery procedures.

Local Configuration of S-GW and S4-SGSN per RAI

The SGSN already supports selection of the S-GW using DNS SNAPTR queries for the RAI FQDN. The S4-SGSN now provides the option to configure a local S-GW address for a RAI (LAC, RAC MCC and MNC). This functionality enhances the S-GW selection logic to allow the call to continue even if DNS lookup fails for any reason.

The S4-SGSN will select this local S-GW address based on the configured local policy. The local policy also can be configured to allow the selection of the locally configured S-GW address when the DNS lookup fails.

Local selection of the S-GW address applies in the following scenarios:

First PDP context activation for a subscriber
Intra SGSN routing area update
New SGSN routing area update
Intra SGSN inter RAT handover

Currently local selection of the S-GW address is not supported in the following scenarios:

Intra SGSN SRNS relocation
New SGSN SRNS relocation

Configurable GUTI to RAI Conversion Mapping

The S4-SGSN allows operators to configure mapping to an EPC MME for networks that already use LAC ranges between 32768 and 65535.

LAC ranges between 32768 to 65535 are currently being used in some UMTS/GPRS deployments although 3GPP TS 23.003 indicates that a UMTS / GPRS network should not use LACs in that range. This range is reserved for the MME group code.

In an LTE network, the MME group code is mapped to the LAC and therefore the LAC and MME group code should be separate. The S4-SGSN provides a customized solution for this problem by identifying the valid MME group codes, which it uses to identify whether the received LAC is a native LAC or a LAC mapped from GUTI (i.e., an MME group code part of GUTI).

S4-SGSN Support for Mobility Management Procedures

To support the S6d/Gr interface, the S4-SGSN supports the following mobility management procedures over the those (HSS/HLR) interfaces:

Attach
Service request
Detach
Iu-Release procedures
Operator policy override for the Gn/S4 interface for EPC subscribers
Zone code
ARD
ADD
Operator policy-based Mobility Management context handling

QoS Mapping Support

The S4-SGSN supports the configuration of QoS parameters to ensure proper QoS parameter mapping between the S4-SGSN and EPC S-GWs, P-GWs, and UEs.

The S4-SGSN communicates QoS parameters towards the S-GW and P-GW in EPC QoS. However, it sends QoS towards the UE in the QoS format defined in the GMM/SM specification (TS 24.008). 3GPP defines a mapping for EPS QoS to pre-release 8 QoS in TS 23.401, Annex E. On the S4-SGSN, operators can configure the quality of service (QoS) parameters as call-control-profiles that will ensure proper QoS mapping between the S4-SGSN and the EPC gateways (P-GW and S-GW) and UEs.

The configured call-control-profiles will be used if the S4 interface is chosen for PDP activation, but the subscription does not have an EPS subscription. Therefore, GPRS subscription data (which uses QoS in pre-release 8 format), will be mapped to EPS QoS behavior. The Allocation and Retention policy will be mapped to EPS ARP using the configured call control profiles.

If the QoS mapping configuration is not used, the following default mappings are used:

Default ARP high-priority value = 5
Default ARP medium-priority value = 10
Default pre-emption capability = shall-not-trigger-pre-emption
Default pre-emption vulnerability = not pre-emptable

MS Initiated Primary and Secondary Activation

The S4-SGSN supports default and dedicated bearer activation for:

Default and dedicated activation - secondary PDP procedure trigger from MS).
Lawful Intercept for activation rejects and failures
Dual stack PDP handling
APN-selection as per annex A.2/Spec 23.060 rel-9

Deactivation Procedure Support

The S4-SGSN supports the following deactivation procedures:

3G / 2G MS initiated bundle deactivation
3G / 2G MS initiated dedicated bearer deactivation
3G / 2G P-GW initiated dedicated bearer deactivation
3G / 2G P-GW initiated PDN deactivation

MS, PGW and HSS Initiated PDP Modification Procedure Support

The S4-SGSN supports the following packet data protocol (PDP) modification procedures:

2G and 3G MS initiated PDP modification procedures
2G and 3G P-GW Initiated PDP modification procedures
2G and 3G HSS initiated PDP modification procedures

The PDP context modification procedures are invoked by the network or by the MS to modify the parameters that were negotiated under the following conditions:

During the PDP context activation procedure
During the secondary PDP context activation procedure
At a previously performed PDP context modification procedure

Depending on the selected Bearer Control Mode, the MS or the network may also create and delete a traffic flow template (TFT) in an active PDP context. The procedure can be initiated by the network or the MS at any time when a PDP context is active. Only the network may modify or delete a TFT packet filter that the network has created. Conversely, only the MS may modify or delete a TFT packet filter that the MS has created.

MS-Initiated PDP Context Modification

The Mobile Station (MS) initiated PDP context modification procedure MS allows for a change in negotiated QoS, the radio priority level, or the TFT negotiated during the PDP context activation procedure.

E-UTRAN capable MSs will not modify the QoS of the first PDP context that was established within the PDN connection.

The MS initiates the Modification procedure by sending a MODIFY PDP CONTEXT REQUEST message to the SGSN. The SGSN validates the received message and sends out a BEARER RESOURCE COMMAND message to the S-GW with a valid PTI value which is then sent to the PGW. On accepting the modification, the P-GW sends out an Update Bearer Request with the PTI copied from the received BEARER RESOURCE COMMAND message. Upon successful completion of the modification, the SGSN replies with the MODIFY PDP CONTEXT ACCEPT message.

P-GW-Initiated PDP Context Modification

The Packet Data Node Gateway (P-GW) initiated PDP context modification procedure is used in cases when:

One or several of the EPS Bearer QoS parameters are to be modified
To add/modify/delete the TFT related to the PDP Context or BCM-Mode change

The P-GW can request the modification procedure by sending an UPDATE BEARER REQUEST message without a PTI field to the S-GW, and the S-GW will forward the request to SGSN. The SGSN validates the request and initiates a MODIFY PDP CONTEXT REQUEST message to the MS. On successful completion of the procedure, the SGSN will send an UPDATE BEARER RESPONSE with an appropriate cause value.

HSS Initiated PDP Context Modification

The Home Subscriber Server (HSS) initiated PDP context modification procedure is used when the HSS decides to modify the subscribed QoS, where typically QoS related parameters are changed. The parameters that may be modified are UE-AMBR, APN-AMBR QCI and Allocation/Retention Policy.

The HSS initiates the modification by sending an Insert Subscriber Data (IMSI, Subscription Data) message to the SGSN. The Subscription Data includes EPS subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN AMBR.

The S4-SGSN then updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by returning an Insert Subscriber Data Ack (IMSI) message to the HSS and sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the S-GW. The S-GW forwards the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the P-GW. Note that the EPS Bearer QoS sent in the Modify Bearer Command does not modify the per bearer bit-rate. It is sent to carry only a change in the ARP / QCI received from subscription. Also, the Modify Bearer Command can be sent only for the default bearer (primary PDP) in a PDN connection.

The P-GW modifies the default bearer of each PDN connection corresponding to the APN for which subscribed QoS has been modified. If the subscribed ARP parameter has been changed, the P-GW shall also modify all dedicated EPS bearers having the previously subscribed ARP value unless superseded by PCRF decision. The P-GW then sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS [if QoS is changed], TFT, APN AMBR) message to the S-GW.

The S-GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS [if QoS is changed] APN-AMBR, TFT) message to the SGSN. On completion of modification S4-SGSN acknowledges the bearer modification by sending the "Update Bearer Response (EPS Bearer Identity)" message to P-GW via S-GW. If the bearer modification fails, the P-GW deletes the concerned EPS Bearer.

Fallback from the S4 Interface to the Gn Interface

The S4-SGSN supports fallback the S4 interface and selects the Gn interface for the 1st PDP context activation if the APN DNS-SNAPTR resolution returns only a Gn address. This functionality allows the PDP context request to be completed when DNS resolution returns a GGSN address instead of a P-GW address.

This mechanism is applicable in the following cases:

The UE is EPC-capable
The UE’s subscription has a GPRS subscription only (and not an EPS subscription)

If the subscription has an EPS subscription for an APN, then it is assumed that the P-GW addresses are configured in the DNS for that APN.

Operator Policy Selection of S4 or Gn Interface

The S4-SGSN supports Operator Policy selection of either the S4 or the Gn interface for PDP context operations. This feature allows flexible operator control over interface selection for operational or administrative reasons.

This functionality overrides any other criteria for selection of the P-GW or the GGSN for PDP contexts. This feature is applicable only for EPC-capable UEs.

IDFT Support During Connected Mode Handovers

The S4-SGSN supports the setup of indirect data forwarding tunnels (IDFT) between the eNodeB and the RNC via the SGW during connected mode handovers. This allows the S4-SGSN to support connected mode handovers between the UTRAN and E-UTRAN networks across the S3 interface.

Once enabled, IDFT is employed under the following conditions:

If the SGSN is the old node participating in the connected mode handover, then indirect data forwarding tunnels is used if:
- The target node to which the connected mode handover is initiated should be an eNodeB (i.e., the SGSN performs the handover to the MME).
- The enb-direct-data-forward CLI setting is not configured as the source RNC configuration (in RNC Configuration Mode).
If the SGSN is the new node participating in the connected mode handover, then indirect data forwarding tunnels is employed if:
- The source node from which connected mode handover is initiated is an eNodeB (i.e., the MME is performing a handover to the SGSN).
- The enb-direct-data-forward setting is not configured in the source RNC configuration (in RNC Configuration Mode).
- The source MME indicated that it does not support direct forwarding via a Forward Relocation Request.

IMPORTANT:

If the target SGSN did not relocate to a new SGW, IDFT does not apply. The target SGSN sets up an indirect data forwarding tunnel with SGW only if the SGW is relocated. If the SGW is not relocated, then it is the source MME that sets up the indirect data forwarding tunnel between source the eNodeB and target RNC through the SGW.

Disassociated DSR Support

The S4-SGSN supports the disassociation of the SGSN and EGTP applications for a Delete Session Request in a certain scenario. In this scenario, the SGSN application instructs the EGTP facility to send the Delete Session Request to the SGW and not respond back to the SGSN application to confirm the action. In effect, the SGSN application disassociates itself from the EGTP facility. Since the SGSN application is no longer waiting for a response from the EGTP facility, there will be reduced internal communication between the SGSN and EGTP. The the EGTP facility will handle retransmissions of the DSR request, thereby eliminating the possibility of hanging sessions at the SGSN.

The behavior of the disassociated DSR feature for each of the applicable scenarios follows:

The SGSN / MME wants to send a DSR with OI=0 and SI=1 to an old SGW during SGW relocation.
The SGSN application instructs the EGTP facility to inform the old SGW of the DSR and the SGSN doesn't expect any response from EGTP.
The EGTP facility handles retransmissions of this DSR request.

SGSN Serving Radio Network Subsystem (SRNS) Relocation Support

SRNS relocation is the method defined in 3GPP TS 23.401 for connected mode inter-RAT handovers from E-UTRAN to UTRAN or UTRAN to E-UTRAN networks. The SGSN already supports SRNS relocation across the Gn interface. The SGSN now also supports SRNS relocation with the following cases across the S3 (S4-SGSN to MME) and S16 (S4-SGSN to S4-SGSN) interfaces:

Intra-SGSN SRNS relocation
Inter-SGSN SRNS relocation over the S16 interface
UTRAN-to-E-UTRAN connected mode Inter-RAT handover over the S3 interface
UTRAN-to-E-UTRAN connected mode Inter-RAT handover over the S3 interface

The relocation feature is triggered by subscribers (MS/UE) moving between an eNodeB and an RNC. If the originating and destination nodes are connected to the same S4-SGSN but are in different routing areas, the behavior triggers an intra-SGSN Routing Area Update (RAU). If the nodes are connected to different S4-SGSNs, the relocation is followed by an inter-SGSN RAU.

As part of the SRNS relocation feature implementation on the S4-SGSN, the SGSN application also supports the gtpv2 (egtp) protocol for:

Inter-SGSN SRNS relocations over the S16 interface
MME - SGSN SRNS relocations over the S3 interface

Configuration and Maintenance

The existing srns-inter and srns-intra commands in Call Control Profile Configuration Mode are used to enable this feature.

In addition, the enb-direct-data forward command in RNC Configuration Mode can be used to enable the S4-SGSN to apply direct forwarding tunnels or indirect data forwarding tunnels (IDFT) between a particular eNodeB and RNC.

Statistics are also available with the show s4-sgsn statistics all command that enable operators to track SGW relocations and SRNS procedure aborts.

E-UTRAN Service Handover Support

The SGSN supports configuration-based enabling of the E-UTRAN Service Handover Information Element, which is optional in the following RANAP messages used during SRNS relocation:

RAB Assignment Request
Relocation Request

This feature is useful in the following scenarios:

A UE is E-UTRAN capable, the PLMN is E-UTRAN capable, but the UE has not subscribed to EPS services (no 4G subscription available).
The VPLMN is E-UTRAN-capable, and the UE of an inbound roamer is E-UTRAN capable, but the UE has only a UTRAN/GERAN roaming agreement in place.

The feature ensures that an SRNS relocation handover to E-UTRAN is not allowed for E-UTRAN capable UEs that have only a UTRAN/GERAN roaming agreement. This results in an elimination of potential service denial or disruption issues, and unnecessary signaling.

To implement this feature, CLI commands have been implemented so that the SGSN can be configured to:

Override the "eutran-not-allowed" flag received from the HLR/HSS in the ISD/ULA request for the Access Restriction Data (ARD) parameter (for scenario #2 above).
Enable the inclusion of the E-UTRAN Service Handover IE in RAB Assignment Request and Relocation Request RANAP messages for scenarios #1 and #2 above).

IMPORTANT:

SRNS relocation must be configured via the srns-inter and/or srns-intra commands in Call Control Profile Configuration Mode before configuring E-UTRAN Service Handover Support.

Support for Gn Handoff from S4-SGSN to 2G/3G Gn SGSN

The S4-SGSN supports handoffs from the S4-SGSN to a 2G/3G peer Gn/Gp SGSN as follows:

An EPC capable UE is attached to an S4-SGSN and has PDP contexts towards the EPC core using the S4 interface.
When the UE hands off to a Gn/Gp SGSN, the S4-SGSN transfers the PDP contexts to the peer SGSN using the GTPv1 protocol.

No CLI commands are require to implement this functionality.

Summary of Functional Differences between an S4-SGSN and an SGSN (Gn/Gp)

Since the S4-SGSN is configured with 2G, 3G, and/or dual access SGSN services before being configured with enhancements to enable communication with the EPC network, it shares similarities with a Gn/Gp SGSN. But, the S4-SGSN also contains a number of functional differences. The following table summarizes these differences.

Table 1. Summary of Functional Differences between SGSN and S4-SGSN

Procedure	Gn/Gp SGSN	S4-SGSN
MS Initiated First Primary PDP Context Activation	The requested QoS is negotiated with the subscribed QoS. The negotiated QoS is sent in the Create PDP Context Request.	The requested QoS is ignored. Always uses the subscribed EPS QoS to send in the Create Session Request. If there is no EPS subscription but the UE is still granted access to the S4 interface, then the system negotiates the requested QoS with the subscribed GPRS QoS. The S4-SGSN maps the negotiated QoS and sends the Create Session Request. If the requested traffic class is conversational / streaming, then the system maps it to the interactive class as a primary PDP context. The Primary PDP context cannot be a GBR Bearer. Two primary PDP contexts are for the same APN must be selected for the same P-GW.
MS Initiated Secondary PDP Context Activation	Secondary PDP context’s requested QoS will be capped to the subscribed QoS. Since the Create PDP Context is the message also used for creating the Secondary PDP context, ARP also is sent for secondary PDP context.	Secondary PDP context’s requested QoS is not capped to any subscribed QoS. The S4-SGSN sends the requested QoS to the P-GW and then the P-GW decides what QoS to assign. ARP is not sent in the Bearer Resource command. But it is sent by the P-GW in the Create Bearer Request.
MS Initiated PDP Context Deactivation	Both single and bundle deactivation is allowed.	If a primary PDP context must be deactivated, only bundle deactivation is allowed.
GGSN/P-GW Initiated PDP Context Deactivation	The GGSN can deactivate the primary PDP context alone without initiating a bundle deactivation.	If the P-GW deactivates the primary PDP context (default bearer), it is treated as a bundle deactivation.
PDP Context Preservation for conversational/streaming class.	The SGSN sends the Update PDP Context Request to the GGSN with 0kbps as the Maximum Bit Rate value.	The S4-SGSN deactivates the PDP contexts that are with a QoS class of conversational/streaming if there is a RAB release/Iu release. PDP Context Preservation for conversational/streaming class is not currently supported. At this time, only the PDP without deactivation is retained.
PDP Context Preservation for interactive/background class.	The SGSN preserves the PDP context as it is.	The S4-SGSN preserves the PDP context as it is. If a direct tunnel was established, or if ISR is active, then the S4-SGSN sends a Release Access Bearer Request to the S-GW.
RNC Initiated QoS Modification	The SGSN initiates the PDP Context Modification procedure.	The S4-SGSN ignores the RAB Modify Request received from the RNC.
Intra-SGSN Routing Area Update in PMM-Idle Mode	The SGSN sends the Update PDP Context Request to the GGSN if the PLMN changes.	An intra-SGSN RAU may involve a change of S-GW. An S4-SGSN sends a Modify Bearer Request to the S-GW/P-GW if the RAU involves a change of PLMN and if the S-GW doesn’t change.
Intra SGSN RAU in PMM-CONNECTED Mode	The SGSN sends the Update PDP Context Request to the GGSN if the PLMN changes or if QoS changed due to an RNC release change.	An intra-SGSN RAU may involve a change of the S-GW. Change of QoS due to RNC release cannot be supported in the S4-SGSN as there is no way to trigger SGSN-initiated guaranteed bit rate bearer modification (Conversational/Streaming class) defined in the standard. However, in an S4-SGSN, the SGSN initiated modification procedure is defined only for changing of APN-AMBR. A change of RNC release will initiate a per bearer QoS change. There is no way to communicate this to the S-GW / P-GW.
Old - Inter-SGSN RAU with no change in interface type across SGSNs.	Where both “old” and “new” refer to SGSNs (Gn/Gp): The old SGSN orders the PDP contexts as per priority in the SGSN Context Response message. If the UE is PMM-CONNECTED in the old SGSN, then the old SGSN initiates an SRNS Context Transfer before sending the SGSN context response. In addition, the old SGSN initiates an SRNS Data Forward Command to the SRNS to transfer the unsent data from the old SRNS to the old SGSN.	Where both “old” and “new” refer to S4-SGSNs. If the new S4-SGSN indicated that the S-GW has changed in the Context Ack message, then the old S4-SGSN has to initiate a Delete Session Request to the old S-GW. The S4-SGSN does not support lossless PDCP for inter-SGSN handovers. If the UE was PMM-CONNECTED in the old S4-SGSN, then it will not initiate an SRNS Context Transfer before sending the Context Response. The assumption is that the SRNS relocation procedure had occurred prior to the inter-SGSN RAU for CONNECTED subscribers. For inter S4-SGSN context transfers the Context Ack message doesn’t carry any data TEID. That is, the GTPv2 protocol doesn’t define any inter-SGSN data tunnel. Therefore, during connected mode, a RAU between two S4-SGSN without an SRNS relocation will result in packet losses. It is assumed that SRNS relocation is enabled in the UTRAN.
Old - Inter-SGSN RAU with no change in interface type across SGSNs. (Continued)	.	Where both “old” and “new” refer to S4-SGSNs. (Continued) However, the ASR 5000 S4-SGSN does not currently support the SRNS relocation procedure at this time. Support is under development and will be available in a future release.
Old - Inter SGSN RAU with change in interface across SGSN	Where “old” is SGSN (Gn/Gp) and “new” is S4-SGSN: The old SGSN sends a SGSN context response with PDP contexts in prioritized order. If the MS is in PMM-CONNECTED state in the old SGSN, it will initiate an SRNS Context Transfer towards the old SRNS and will initiate SRNS Data Forward Command to transfer unsent packets from old SRNS back to old SGSN.	Where “old” is S4-SGSN and “new” is SGSN (Gn/Gp): The old S4-SGSN receives a GTPv1 SGSN Context Request and it converts the EPS bearer information to PDP contexts and responds with a SGSN Context Response towards the new SGSN. The old S4-SGSN prioritizes the PDP contexts as per ARP.
New Inter SGSN RAU for a PMM-IDLE subscriber without a change of interface	Uses the PDP context prioritized order in the SGSN Context Response to select high priority PDP contexts in the case of resource limitations at the new SGSN. The SGSN ends the UPCQ to GGSN.	Performs the S-GW selection procedure. Uses ARP to prioritize EPS bearers. In GTPv1 the PDP contexts sent in SGSN context response will be in prioritized order. But such an order is not defined for sending EPS bearers in Context Response. The idea is to use to ARP for prioritization. The new S4-SGSN alerts of any change in S-GW through the Context Ack to the old S4-SGSN. The PMM module will wait until the S-GW selection procedure is complete at the new S4-SGSN to alert of the context ack.
New Inter SGSN RAU for a PMM-CONNECTED subscriber	Where “old” is S4-SGSN and “new” is SGSN (Gn/Gp): The new SGSN receives PDP contexts in the SGSN Context Response in prioritized order. RABs will be established at the new SGSN based on the ASI bit value for each PDP.	Where “new” is S4-SGSN and “old” is SGSN (Gn/Gp): The new S4-SGSN receives PDP contexts in the Context Response. There is no prioritized order. ARP is used to prioritize. New S4-SGSN performs S-GW selection. The new S4-SGSN cannot establish RAB as there is no ASI bit in the GTPv2 Context Response. The assumption is that the Context Req / Response is used only for IDLE mode handover, and that for connected mode handover, the SRNS relocation procedure should be used.
New – SGSN PMM-CONNECTED / PMM-IDLE subscriber handover with interface change	Where “old” is S4-SGSN and “new” is SGSN (Gn/Gp): The new S4-SGSN sends a GTPv1 SGSN Context Request and receives the PDP contexts mapped from EPS bearers in the SGSN context response. The old SGSN will establish an inter-SGSN tunnel for transferring queued packets.	Where “old” is SGSN (Gn/Gp) and “new” is S4-SGSN: The new S4-SGSN sends a GTPv1 SGSN context request, after learning that the old SGSN is an SGSN (Gn/Gp) based on a DNS S-NAPTR response. The new S4-SGSN will continue to use the Gn interface for the PDPs. Conversion of PDPs to S4-SGSN is not supported at this time.
APN Selection Logic	No concept of subscribed default APN.	One among the subscribed APN will be indicated as a default APN by the HSS. That APN will be used under the following cases: 1) No requested APN, 2) The requested APN is not in the subscription but the requested PDP type matches with default APN’s PDP type.
DNS Queries	APN FQDN, RAI FQDN and RNC-ID FQDN are formed with a .gprs extension. DNS A/AAAA records are queried. Optionally, also uses S-NAPTR queries for EPC-capable UEs to select a co-located P-GW/GGSN	APN FQDN, RAI FQDN, RNC-ID FQDN are formed with a .3gppnetwork.org extension. DNS S-NAPTR records are queried
Path Failure Detection	Can be echo-based or non-echo-based.	Echo-based only.
Charging	Applicable.	Charging for PDP contexts applicable only if CAMEL is used. However, the S4-SGSN will continue to generate M-CDRs.
Intra SGSN Inter System Handover (2G to 3G or 3G to 2G Inter RAT handovers)	For 2G to 3G handovers, the RABs are not established in 3G after handover. It is the function of the UE to initiate Service Request procedure to setup RAB. For 3G to 2G handovers, the QoS is capped to 472 Kbps in 2G and the Update PDP Context Request initiated from 2G will carry the capped QoS to GGSN.	For 2G to 3G handovers, the RABs are not established in 3G after the handover. The S4-SGSN preserves the PDP without deactivation. For 3G to 2G handover, the QoS is not capped to 472 Kbps in 2G. The reason is that in GTPv2 the Modify Bearer Request initiated from S4-SGSN upon 3G to 2G RAU is defined only for informing S-GW / P-GW of a switch in tunnel IDs and change in RAT type. This message doesn’t carry QoS. The S4-SGSN relies on the P-GW + PCRF to decide the best QoS for the informed RAT type and lets the P-GW initiate a separate modification procedure to set the right QoS.

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 processing card 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 packet processing card 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 processing card.

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 processing card recovery mode: Used when a packet processing card 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:

Data and control state information required to maintain correct call behavior
Subscriber data statistics that are required to ensure that accounting information is maintained
A best-effort attempt to recover various timer values such as call duration, absolute time, and others

For more information on session recovery use and session recovery configuration, refer to the Session Recovery section in the Cisco ASR 5000 Series System Administration 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:

Eliminates the single point of failure between an RNC and an SGSN or between a BSS and an SGSN.
Ensures geographical redundancy, as a pool can be distributed across sites.
Minimizes subscriber impact during service, maintenance, or node additions or replacements.
Increases overall capacity via load sharing across the SGSNs in a pool.
Reduces the need/frequency for inter-SGSN RAUs. This substantially reduces signaling load and data transfer delays.
Supports load redistribution with the SGSN offloading procedure.

Gb/Iu Flex Offloading

The SGSN supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool.

In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to offload to the Target. This can be used to provide load balancing, or to offload a single node in pool, take it out of service for whatever reason (e.g., maintenance).

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

charging for SMS messages, and
lawful intercept of SMS messages

SMS Authentication Repetition Rate

The SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.

Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.

SMSC Address Denial

Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.

Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.

Threshold Crossing Alerts (TCA) Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

The following thresholding models are supported by the system:

Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

Logs are supported in both the Alert and the Alarm models.

Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

The Alarm System is used only in conjunction with the Alarm model.

IMPORTANT:

For more information on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.

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.

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 available 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.

Step	Description
1	The MS/UE sends an Attach Request message to the SGSN. Included in the message is information, such as: Routing area and location area information Mobile network identity Attach type
2	Authentication is mandatory if no MM context exists for the MS/UE: The SGSN gets a random value (RAND) from the HLR to use as a challenge to the MS/UE. The SGSN sends a Authentication Request message to the UE containing the random RAND. The MS/UE contains a SIM that contains a secret key (Ki) shared between it and the HLR called a Individual Subscriber Key. The UE uses an algorithm to process the RAND and Ki to get the session key (Kc) and the signed response (SRES). The MS/UE sends a Authentication Response to the SGSN containing the SRES.
3	The SGSN updates location information for the MS/UE: a) The SGSN sends an Update Location message, to the HLR, containing the SGSN number, SGSN address, and IMSI. b) The HLR sends an Insert Subscriber Data message to the “new” SGSN. It contains subscriber information such as IMSI and GPRS subscription data. c) The “New” SGSN validates the MS/UE in new routing area: If invalid: The SGSN rejects the Attach Request with the appropriate cause code. If valid: The SGSN creates a new MM context for the MS/UE and sends a Insert Subscriber Data Ack back to the HLR. d) The HLR sends a Update Location Ack to the SGSN after it successfully clears the old MM context and creates new one
4	The SGSN sends an Attach Accept message to the MS/UE containing the P-TMSI (included if it is new), VLR TMSI, P-TMSI Signature, and Radio Priority SMS. At this point the GPRS Attach is complete and the SGSN begins generating M-CDRs.

Step	Description
1	The MS/UE sends a PDP Activation Request message to the SGSN containing an Access Point Name (APN).
2	The SGSN sends a DNS query to resolve the APN provided by the MS/UE to a GGSN address. The DNS server provides a response containing the IP address of a GGSN.
3	The SGSN sends a Create PDP Context Request message to the GGSN containing the information needed to authenticate the subscriber and establish a PDP context.
4	If required, the GGSN performs authentication of the subscriber.
5	If the MS/UE requires an IP address, the GGSN may allocate one dynamically via DHCP.
6	The GGSN sends a Create PDP Context Response message back to the SGSN containing the IP Address assigned to the MS/UE.
7	The SGSN sends a Activate PDP Context Accept message to the MS/UE along with the IP Address. Upon PDP Context Activation, the SGSN begins generating S-CDRs. The S-CDRs are updated periodically based on Charging Characteristics and trigger conditions. A GTP-U tunnel is now established and the MS/UE can send and receive data.

Step	Description
1	The GGSN receives a PDU with a static PDP address that the GGSN ‘knows’ is for an MS/UE in its PLMN.
2	The GGSN uses the IMSI in place of the PDP address and sends an SRI (send routing information for GPRS) to the HLR. The HLR sends an SRI response back to the GGSN. The response may include the access of the target SGSN and it may also indicate it the MS/UE is not reachable, in which case it will include the reason in the response message.
3	The GGSN sends a PDU Notification Request to the SGSN (if the address was received). If the address was not received or if the MS/UE continues to be unreachable, the GGSN sets a flag marking that the MS/UE was unreachable. The notified SGSN sends a PDU Notification Response to the GGSN.
4	The SGSN determines the MS/UE’s location and sets up a NAS connection with the MS/UE. The SGSN then sends a Request PDP Context Activation message to the MS/UE.
5	If the MS/UE accepts the invitation to setup a PDP context, the MS/UE then begins the PDP context activation process indicated in the preceding procedure.

Step	Description
1	The UE sends a Detach Request message to the SGSN containing the Detach Type, P-TMSI, P-TMSI Signature, and Switch off indicator (i.e. if UE is detaching because of a power off).
2	The SGSN sends Delete PDP Context Request message to the GGSN containing the TEID. The GGSN sends a Delete PDP Context Response back to the SGSN. The SGSN stops generating S-CDR info at the end of the PDP context.
3	The SGSN sends a IMSI Detach Indication message to the MSC/VLR.
4	The SGSN sends a GPRS Detach Indication message to the MSC/VLR. The SGSN stops generating M-CDR upon GPRS Detach.
5	If the detach is not due to a UE switch off, the SGSN sends a Detach Accept message to the UE.
6	Since the UE GPRS Detached, the SGSN releases the Packet Switched Signaling Connection.

Supported Standards

The SGSN services comply with the following standards for GPRS/UMTS and EPC 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

3GPP Release 6 and higher is supported for all specifications unless otherwise noted. Support for higher releases is indicated below, in relation to current and planned development, including support for IEs and messages determined by supported functionality. Product development is aiming ultimately towards full compliance with the releases listed below:

Table 6. 3GPP Standards Supported

3GPP Standard	R12.0/ R12.2	R14.0
3GPP TS 9.60, 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (R98).	v7.10.0 (2002-12)	v7.10.0 (2002-12)
3GPP TS 22.041, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB)	v7.0.0 (2007-2003)	v9.0.0 (2009-12)
3GPP TS 22.042, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Identity and Timezone (NITZ); Service description, Stage 1	v7.0.0 (2007-2006)	v9.0.0 (2009-12)
3GPP TS 23.003, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification	v7.11.0 (2012-2003)	v9.9.0 (2011-12)
3GPP TS 23.007, 3rd Generation Partnership Project; Technical Specification Group Core Network; Restoration procedures	v7.0.0 (2006-06)	v9.10.0 (2011-12)
3GPP TS 23.015, 3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB)	v7.0.0 (2007-03)	v9.0.0 (2009-12)
3GPP TS 23.016, 3rd Generation Partnership Project; Technical Specification Group Core Network; Subscriber data management; Stage 2	v7.0.0 (2007-06)	v9.1.0 (2010-03)
3GPP TS 23.040, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS)	v7.2.0 (2009-03)	v9.3.0 (2010-09)
3GPP TS 23.060, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2	v7.11.0 (2011-2012)	V9.11.0 (2011-12)
3GPP TS 23.078, 3rd Generation Partnership Project; Technical Specification Group Core Network; Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 - Stage 2 (Release 4)	v4.11.1 (2004-04)	v4.11.1 (2004-04)
3GPP TS 23.107, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture	v7.1.0 (2007-06)	v9.3.0 (2011-12)
3GPP TS 23.236, 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	v7.0.0 (2006-12)	v9.0.0 (2009-12)
3GPP TS 23.251, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description	v7.0.0 (2007-06)	v9.4.0 (2011-03)
3GPP TS 23.271, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stage 2 description of Location Services (LCS) (Release 9)	N/A	v9.6.0 (2011-03)
3GPP TS 23.401, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9)	N/A	v9.12.0 (2012-03)
3GPP TS 24.007, 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface signalling layer 3; General aspects	v7.0.0 (2005-2009)	v10.0.0 (2011-03)
3GPP TS 24.008, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3	v7.15.0 (2010-2003)	v9.10.0 (2012-03)
3GPP TS 24.011, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface (Release 7)	v7.1.0 (2009-2006)	v7.1.0 (2009-2006)
3GPP TS 24.030, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Location Services (LCS); Supplementary service operations; Stage 3 (Release 9)	N/A	V9.0.0 (2009-12)
3GPP TS 24.080, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface layer 3 supplementary services specification; Formats and coding (Release 9)	N/A	V9.2.0 (2010-06)
3GPP TS 25.410, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: general aspects and principles	v7.0.0 (2006-03)	v9.0.1 (2011-03)
3GPP TS 25.411, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface layer 1	v7.1.0 (2007-2009)	v9.0.1 (2011-03)
3GPP TS 25.412, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signaling transport	v7.1.0 (2006-06)	v9.0.1 (2011-03)
3GPP TS 25.413, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 9)	v9.8.0 (2011 - 12) (sections 8.19.2 and 8.20.2)	v9.8.0 (2011 - 12) (sections 8.19.2 and 8.20.2)
3GPP TS 25.414, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signaling	v7.1.0 (2006-06)	v9.0.1 (2011-03)
3GPP TS 25.415, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols	v7.3.0 (2006-2012)	v9.0.1 (2011-03)
3GPP TS 29.002, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification	v7.15.0 (2010-06)	v9.8.0 (2012-03)
3GPP TS 29.016, 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface network service specification	v7.0.0 (2007-2006)	v8.0.0 (2008-12)
3GPP TS 29.018, 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	v7.3.0 (2006-2012)	v9.1.0 (2010-12)
3GPP TS 29.060,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	v7.17.0 (2011-2009)	v9.9.0 (2011-12)
3GPP TS 29.078, 3rd Generation Partnership Project; Technical Specification Group Core Network; Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification (Release 4)	v4.9.0 (2009-2009)	v4.9.0 (2009-2009)
3GPP TS 29.202, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; SS7 Signalling Transport in Core Network; Stage 3	v7.0.0 (2007-2006)	v8.0.0 (2007-06)
3GPP TS 29.272, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 9)	N/A	v9.7.0 (2011-2006)
3GPP TS 29.274, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 9)	N/A	v9.9.0 (2011-12)
3GPP TS 29.303, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Domain Name System Procedures; Stage 3 (Release 9)	N/A	v9.4.0 (2011-2006)
3GPP TS 32.215, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain	v5.9.0 (2007-10)	v5.9.0 (2007-10)
3GPP TS 32.251, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging	v7.8.0 (2010-10)	v9.8.0
3GPP TS 32.298, 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging Data Record (CDR) parameter description	v7.5.0 (2008-2012)	v9.10.0 (2011-12)
3GPP TS 32.406, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Performance Management (PM); Performance measurements Core Network (CN) Packet Switched (PS) domain	v7.1.0 (2006-06)	v9.0.0 (2009-12)
3GPP TS 32.410, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Key Performance Indicators (KPI) for UMTS and GSM	v8.0.0 (2009-2003)	v9.0.0 (2009-09)
3GPP TS 33.102, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture	v7.1.0 (2006-2012)	v9.4.0 (2010-12)
3GPP TS 33.106, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful Interception requirements	v7.0.1 (2006-2001)	v9.0.0 (2009-12)
3GPP TS 33.107, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful interception architecture and functions	v7.7.0 (2007-2009)	v9.4.0 (2011-03)
3GPP TS 33.108, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Handover interface for Lawful Interception (LI) (Release 7)	v7.10.0 (2010-2012)	v7.10.0 (2010-2012)
3GPP TS 44.064, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) layer specification	v7.4.0 (2011-2012)	v9.1.0 (2011-12)
3GPP TS 44.065, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP)	v7.0.0 (2006-09)	v9.0.0 (2009-12)
3GPP TS 48.014, 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 Layer 1	v7.0.0 (2007-2009)	v9.0.0 (2009-12)
3GPP TS 48.016, 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	v7.4.0 (2008-2003)	v9.0.0 (2009-12)
3GPP TS 48.018, 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) (Release 7)	v7.13.0 (2009-2012)	v7.13.0 (2009-2012)

3GPP Standard

R12.0/ R12.2

R14.0

3GPP TS 9.60, 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (R98).

v7.10.0 (2002-12)

3GPP TS 22.041, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB)

v7.0.0 (2007-2003)

v9.0.0 (2009-12)

3GPP TS 22.042, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Identity and Timezone (NITZ); Service description, Stage 1

v7.0.0 (2007-2006)

v9.0.0 (2009-12)

3GPP TS 23.003, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification

v7.11.0 (2012-2003)

v9.9.0 (2011-12)

3GPP TS 23.007, 3rd Generation Partnership Project; Technical Specification Group Core Network; Restoration procedures

v7.0.0 (2006-06)

v9.10.0 (2011-12)

3GPP TS 23.015, 3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB)

v7.0.0 (2007-03)

v9.0.0 (2009-12)

3GPP TS 23.016, 3rd Generation Partnership Project; Technical Specification Group Core Network; Subscriber data management; Stage 2

v7.0.0 (2007-06)

v9.1.0 (2010-03)

3GPP TS 23.040, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS)

v7.2.0 (2009-03)

v9.3.0 (2010-09)

3GPP TS 23.060, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2

v7.11.0 (2011-2012)

V9.11.0 (2011-12)

3GPP TS 23.078, 3rd Generation Partnership Project; Technical Specification Group Core Network; Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 - Stage 2 (Release 4)

v4.11.1 (2004-04)

3GPP TS 23.107, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture

v7.1.0 (2007-06)

v9.3.0 (2011-12)

3GPP TS 23.236, 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

v7.0.0 (2006-12)

v9.0.0 (2009-12)

3GPP TS 23.251, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description

v7.0.0 (2007-06)

v9.4.0 (2011-03)

3GPP TS 23.271, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stage 2 description of Location Services (LCS) (Release 9)

N/A

v9.6.0 (2011-03)

3GPP TS 23.401, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9)

N/A

v9.12.0 (2012-03)

3GPP TS 24.007, 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface signalling layer 3; General aspects

v7.0.0 (2005-2009)

v10.0.0 (2011-03)

3GPP TS 24.008, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3

v7.15.0 (2010-2003)

v9.10.0 (2012-03)

3GPP TS 24.011, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface (Release 7)

v7.1.0 (2009-2006)

3GPP TS 24.030, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Location Services (LCS); Supplementary service operations; Stage 3 (Release 9)

N/A

V9.0.0 (2009-12)

3GPP TS 24.080, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface layer 3 supplementary services specification; Formats and coding (Release 9)

N/A

V9.2.0 (2010-06)

3GPP TS 25.410, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: general aspects and principles

v7.0.0 (2006-03)

v9.0.1 (2011-03)

3GPP TS 25.411, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface layer 1

v7.1.0 (2007-2009)

v9.0.1 (2011-03)

3GPP TS 25.412, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface signaling transport

v7.1.0 (2006-06)

v9.0.1 (2011-03)

3GPP TS 25.413, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling (Release 9)

v9.8.0 (2011 - 12) (sections 8.19.2 and 8.20.2)

3GPP TS 25.414, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface data transport and transport signaling

v7.1.0 (2006-06)

v9.0.1 (2011-03)

3GPP TS 25.415, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface user plane protocols

v7.3.0 (2006-2012)

v9.0.1 (2011-03)

3GPP TS 29.002, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification

v7.15.0 (2010-06)

v9.8.0 (2012-03)

3GPP TS 29.016, 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface network service specification

v7.0.0 (2007-2006)

v8.0.0 (2008-12)

3GPP TS 29.018, 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

v7.3.0 (2006-2012)

v9.1.0 (2010-12)

3GPP TS 29.060,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

v7.17.0 (2011-2009)

v9.9.0 (2011-12)

3GPP TS 29.078, 3rd Generation Partnership Project; Technical Specification Group Core Network; Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification (Release 4)

v4.9.0 (2009-2009)

3GPP TS 29.202, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; SS7 Signalling Transport in Core Network; Stage 3

v7.0.0 (2007-2006)

v8.0.0 (2007-06)

3GPP TS 29.272, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 9)

N/A

v9.7.0 (2011-2006)

3GPP TS 29.274, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 9)

N/A

v9.9.0 (2011-12)

3GPP TS 29.303, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Domain Name System Procedures; Stage 3 (Release 9)

N/A

v9.4.0 (2011-2006)

3GPP TS 32.215, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain

v5.9.0 (2007-10)

3GPP TS 32.251, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Packet Switched (PS) domain charging

v7.8.0 (2010-10)

v9.8.0

3GPP TS 32.298, 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging Data Record (CDR) parameter description

v7.5.0 (2008-2012)

v9.10.0 (2011-12)

3GPP TS 32.406, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Performance Management (PM); Performance measurements Core Network (CN) Packet Switched (PS) domain

v7.1.0 (2006-06)

v9.0.0 (2009-12)

3GPP TS 32.410, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Key Performance Indicators (KPI) for UMTS and GSM

v8.0.0 (2009-2003)

v9.0.0 (2009-09)

3GPP TS 33.102, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture

v7.1.0 (2006-2012)

v9.4.0 (2010-12)

3GPP TS 33.106, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful Interception requirements

v7.0.1 (2006-2001)

v9.0.0 (2009-12)

3GPP TS 33.107, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful interception architecture and functions

v7.7.0 (2007-2009)

v9.4.0 (2011-03)

3GPP TS 33.108, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Handover interface for Lawful Interception (LI) (Release 7)

v7.10.0 (2010-2012)

3GPP TS 44.064, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) layer specification

v7.4.0 (2011-2012)

v9.1.0 (2011-12)

3GPP TS 44.065, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP)

v7.0.0 (2006-09)

v9.0.0 (2009-12)

3GPP TS 48.014, 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 Layer 1

v7.0.0 (2007-2009)

v9.0.0 (2009-12)

3GPP TS 48.016, 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

v7.4.0 (2008-2003)

v9.0.0 (2009-12)

3GPP TS 48.018, 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) (Release 7)

v7.13.0 (2009-2012)

ITU Standards

Q711; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q712; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q713; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q714; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q715; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q716; 3GPP TS 29.002 v7.15.0 (2006-2010), 3GPP TS 29.016 v7.0.0 (2007-08), and 3GPP TS 25.410 v7.0.0 (2006-03)
Q771; 3GPP TS 29.002 v7.15.0 (2006-2010)
Q772; 3GPP TS 29.002 v7.15.0 (2006-2010)
Q773; 3GPP TS 29.002 v7.15.0 (2006-2010)
Q774; 3GPP TS 29.002 v7.15.0 (2006-2010)
Q775; 3GPP TS 29.002 v7.15.0 (2006-2010)

Object Management Group (OMG) Standards

CORBA 2.6 Specification 01-09-35, Object Management Group