SGSN is a StarOS application that runs on Cisco® ASR 5500 and virtualized platforms. For additional platform information, refer to the appropriate System Administration Guide and/or contact your Cisco account representative.

The SGSN is a licensed Cisco product and requires the purchase and installation of the SGSN Software License. Separate feature licenses may be required. 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.

SGSNs and GGSNs work in conjunction within the GPRS/UMTS network. As indicated earlier in the section on System Configuration Options, the flexible architecture of StarOS enables a single chassis to reduce hardware requirements by supporting integrated co-location of a variety of the SGSN services.

A chassis can be devoted solely to SGSN services or the SGSN system can include any co-location combination, such as multiple instances of 2.5G SGSNs (configured as GPRS services); or multiple instances of 3G SGSNs (configured as SGSN services); or a combination of 2.5G and 3G SGSN to comprise a dual access SGSN.

Important

The following illustrates the GPRS/UMTS Dual Access architecture with a display of all the interfaces supported as of Release 14.0. The SGSN Logical Network Interfaces section below lists the interfaces available for the release applicable to the version of this manual.

The co-location of the SGSN and the GGSN in the same chassis facilitates handover. A variety of GSN combos is possible, 2.5G or 3G SGSN with the GGSN.

An S4-SGSN is an SGSN that is configured for S4 interface support to enable the soft handover of 2G and 3G subscribers to the EPC S-GW via the EPC S4 interface. Comprehensive S4-SGSN support includes interfaces to the following network elements and gateways:

The S4, S13' and S6d interfaces are license-enabled features. Support for the S16 and S3 interfaces are included as part of the S4 license.

The SGSN provides IP-based transport on all RAN and core network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-PS). This means enhanced performance, future-proof scaling and reduction of inter-connectivity complexity. The all-IP functionality is key to facilitating evolution to the next generation technology requirements.

The SGSN provides the following functions over the logical network interfaces illustrated above:

AIPN provides enhanced performance, future-proof scaling and reduction of inter-connectivity complexity.

In accordance with 3GPP, the SGSN provides IP-based transport on all RAN and core network interfaces, in addition to the standard IP-based interfaces (Ga, Gn, Gp, Iu-Data). The all-IP functionality is key to facilitating Iu and Gb Flex (SGSN pooling) functionality as well as evolution to the next generation technology requirements.

The following IP-based protocols are supported on the SGSN:

StarOS SGSN implements SS7 functionality to communicate with the various SS7 network elements, such as HLRs and VLRs.

The SGSN employs standard Signaling System 7 (SS7) addressing (point codes) and global title translation. SS7 feature support includes:

Support for subscriber primary and secondary Packet Data Protocol (PDP) contexts in compliance with 3GPP standards ensure complete end-to-end GPRS connectivity.

The SGSN supports a total of 11 PDP contexts per subscriber. Of the 11 PDP context, all can be primaries, or 1 primary and 10 secondaries or any combination of primary and secondary. Note that there must be at least one primary PDP context in order for secondaries to establish.

PDP context processing supports the following types and functions:

The SGSN supports mobility management (MM) in compliance with applicable 3GPP standards and procedures to deliver the full range of services to the mobile device. Some of the procedures are highlighted below:

The SGSN's 3GPP compliance for location management ensures efficient call handling for mobile users.

The SGSN supports routing area updates (RAU) for location management. The SGSN implements standards based support for:

The design of the SGSN allows for very high scalability of RAUs. In addition, the high capacity of the SGSN and Flex functionality provides a great opportunity to convert high impact Inter-SGSN RAUs to lower impact Intra-SGSN RAUs. The SGSN provides functionality to enforce the following RAU restrictions:

The SGSN also provides functionality to optionally supply the following information to the MN:

Session management ensures proper PDP context setup and handling.

For session management, the SGSN supports four 3GPP-compliant procedures for processing PDP contexts:

Charging functionality for the SGSN varies depending upon the type of network in which it is deployed.

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.

Important

The "Location reporting in connected mode" license is required to enable this functionality.

The SGSN supports the below parameters added in the Update Location Request/Answer and Insert Subscriber Data Request/Answer messages on S6d interface:

• SGSN advertises the DCNR feature support by setting the 'NR as Secondary RAT feature bit' in Supported Features list 2 towards HSS if the DCNR feature is configured at SGSN and UE advertises DCNR capability in NAS

• SGSN also handles the new bit 'NR as Secondary RAT Not Allowed' in the Access-Restriction-Data bitmask sent by HSS to control if the subscriber is allowed to access NR via dual connectivity

• SGSN handles the Extended Bandwidth UL/DL parameters under AMBR sent by HSS

Gateway selection is improved to avoid SGSN from falling back and triggering an "A" query to get the normal GGSN information.

When no collocated PGW/GGSN with "+nc-nr" capability is found in DNS response, the SGSN will select the next collocated PGW/GGSN node. If “3gpp-pgw:x-gn+nc-nr/ x-3gpp-pgw:x-gp+nc-nr” is not present in DNS response, the SGSN will select “3gpp-pgw:x-gn / x-3gpp-pgw:x-gp” instead of triggering another to "A" query to get the GGSN information. "UP Function Selection Indication Flags" IE in Create PDP Context Request message will be set to "1" only when “+nc-nr” capable gateway is selected.

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.

The Location Services (LCS) feature in SGSN provides the mechanism to support mobile location services for operators, subscribers and third party service providers. AAA changes have been made to support the LCS feature. A new CDR type Mobile Originated Location Request CDRs (LCS-MO-CDR) is introduced. LCS-MO-CDRs support the standard dictionaries.

For detailed information on LCS-MO-CDRs, refer to the GTPP Interface Administration and Reference.

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:

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.

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.

The reception, storage, and transfer of APN Restriction values is used to determine whether a UE is allowed to establish PDP Context or EPS bearers with other APNs. This feature is supported by both the Gn/Gp-SGSN and the S4-SGSN.

During default bearer activation, the SGSN sends the current maximum APN restriction value for the UE to the GGSN/P-GW in a Create Session Request (CSR). The GGSN/P-GW retains an APN restriction value for each APN. The UE's APN Restriction value determines the type of application data the subscriber is allowed to send. If the maximum APN restriction of the UE (received in the CSR) and the APN Restriction value of the APN (for which activation is being request) do not concur, then the GGSN/P-GW rejects activation. The maximum APN restriction for a UE is the most restrictive based on all already active default EPS bearers.

This feature provides the operator with increased control to restrict certain APNs to UEs based on the type of APN. This feature requires no special license.

APN Restriction for SGSN is enabled/disabled in the call-control-profile configuration mode using the apn-restriction command. Refer to the Command Line Interface Reference for usage details.

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 Gn/Gp-SGSN supports the following APS/MSP parameters:

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.

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

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:

There are situations in which authentication will be performed unconditionally:

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

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.

This feature allows the backup of a small set of KPI counters for recovery of the counter values after a session manager crash.

Using the feature-specific CLI statistics-backup sgsn backup-interval command, in the Global configuration mode, the operator can enable the feature and define the frequency of the backup; range 1-60 minutes.

In support of this functionality, four schemas (gprs-bk, iups-bk, map-bk, sgtp-bk) have been defined with stats, derived from the SGSN and SGTP schemas, that will be backed up for recovery of their counter values.

For more information about the schema, refer to the Statistics and Counters Reference. For more information about this functionality and configuration for this feature, refer to the Backup and Recovery of Key KPI Statistics feature chapter in this Guide.

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:

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.

An APN Remap Table associated with an IMEI profile overrides a remap table associated with an operator policy. This means activation will be rejected if a local default APN configured, in an APN Remap Table associated with an IMEI profile, cannot be used. This will occur even if a valid local default APN is available in an APN Remap Table associated with an operator policy.

Important

To achieve the previous default behavior, customers already using an APN Remap Table that is associated with an IMEI profile will have to change the existing configuration to achieve the previous behavior. For details and sample configurations, see the Release 16 specific information for apn-selection-default in the APN Remap Table Configuration Mode Commands section of the Command Line Interface Reference for a Release 16 or higher.

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

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.

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

The SGSN selects the value based on the symmetry of negotiated maximum bit rates as follows:

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.

With Release 17, the SGSN supports several of the 3GPP TS23.060 R10 machine type communications (MTC) overload control mechanisms to be used in the handling of signaling bursts from machine-to-machine (M2M) devices:

For more information about the congestion control functionality and configuration, refer to the MTC Congestion Control section in this Guide.

The SGSN adds support for configuring different NRIs for pooled and non-pooled areas in order to load-balance subscribers coming from non-pooled RNCs to pooled RNCs.

Consider a scenario when two SGSNs support pooling and a RNC/BSC controlled by a SGSN is in pool but not the other, and both RNCs/BSCs are given same NRI(s), this leads to imbalance in subscriber distribution between the SGSNs. With this enhancement if an NRI is configured for both pooled and non-pooled, then the SGSN reuses the same NRI when moving from pooled to non-pooled areas and vice versa.

A new keyword non-pooled-nri-value is introduced in the NRI configuration for GPRS and SGSN services to configure set of NRI which should be used for non-pooled RNCs/BSCs. The NRIs configured under the existing keyword nri-value will be used for pooled RNCs/BSCs. If the new keyword non-pooled-nri-value is not configured, then NRIs configured under the keyword nri-value will be used for both pooled and non-pooled RNCs/BSCs.

If the new keyword non-pooled-nri-value is configured without pooling enabled at SGSN(null-nri-value is not configured), then SGSN will use NRIs under non-pooled-nri-value irrespective of BSC/RNCs being pooled or non-pooled, till pooling is enabled at SGSN. After pooling is enabled, NRIs under keyword nri-value will be for pooled RNC/BSCs and non-pooled-nri-value will be for non-pooled RNC/BSCs. This is applicable for both SGSN and GPRS service.

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.

Direct tunnelling of user plane data between the RNC and the S-GW can be employed to scale UMTS system architecture to support higher traffic rates. The direct tunnel (DT) approach optimizes core architecture without impact to UEs and can be deployed independently of the LTE/SAE architecture.

Now, DT support is added to the S4-SGSN to enable the establishment of a direct tunnel over the S12 interface between an RNC and an S-GW in a PS domain under a range of scenarios, such as (but not limited to):

The Direct Tunnel Support on the S4-SGSN feature is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

For a complete description of this feature and its configuration requirements, refer to the S4-SGSN Direct Tunnel Solution session in the Serving GPRS Support Node Administration Guide.

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.

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.

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.

Iu Redundancy is the 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.

A new event-logging handle has been introduced. The EDR module was used for event logging purpose, CDR_MODULE_EVENT_RECORD is used instead of CDR_MODULE_EDR. The CLI options present under the EDR Module are also present under the Session Event Module.

In Release 21.3, the following EDR enhancements are implemented:

• New fields for Activation EDR:

  A new field - NSAPI, is added as a part of the Activation EDR. The location of this field is added at the end of the Activation EDR.

• New fields for ISRAU EDR:

  A new field - PDN-Info, which consists of nsapi, ggsn-address, ipv4-pdp-address, ipv6-pdp-address, is added as a part of the ISRAU EDR and the location of this field is added at the end of the ISRAU EDR.

  The PDN-Info field is optional and will be sent only if there are PDP contexts handled by the SGSN.

• EDR for Service Request parameter:

  An EDR is now generated for a Service Request parameter. This EDR has the following fields listed in order:

  • 1: Time-Stamp

  • 2: Event-ID

  • 3: Event-Result

  • 4: RAT

  • 5: Service-Request-Trigger

  • 6: Service-Type

  • 7: Paging-Attempts

  • 8: Request-Retries

  • Cause-Prot-Types

  • Cause-Code

  • Disconnect Reason

  • Location (MCC+MNC+LAC+RAC+SAC)

  • Subscriber's MSISDN, IMSI, PTMSI, IMEISV, HLR's MSISDN

EIR selelction for roaming subscribers functionality makes it possible for the SGSN to select an EIR based on the PLMN into which the subscriber has roamed and reduce signalling back to home PLMNs for roamers.

The Equipment Identity Register (EIR), used for authentication and authorization during an Attach, is the carrier's IMEI(SV) database of the unique numbers allocated to each subscriber's mobile station equipment (IMEI) and the manufacturer's software version (SV). An IMEI(SV) can be in one of three lists in the EIR:

As part of this function, the operator can create and use an EIR profile to define the parameters to:

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.

In releases prior to 21.5, on failure of DNS query with APN name and LAC-RAC extension, no more DNS queries were sent.

In release 21.5, SGSN sends DNS query with only APN name on failure of DNS query with APN name and LAC-RAC extension. The dns-extn lac-rac fallback command in the APN Profile Configuration mode can be configured to enable or disable fallback on DNS failure.

Important

This enhancement is applicable only for Gn-SGSN.

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.

In order to provide effective control on DNS queries for particular type of procedures, existing CLI commands in GPRS and SGSN services have been deprecated and replaced with new enhanced commands. The command dns israu-mcc-mnc-encoding [hexadecimal | decimal] has been deprecated and a new CLI command dns mcc-mnc-encoding { rai-fqdn | apn-fqdn | rnc-fqdn| mmec-fqdn| tai-fqdn}* {a-query | snaptr-query }* { decimal | hexadecimal } . New keyword options snaptr-query and a-Query are provided to control different types of queries.

To ensure backward compatibility:

For more information see, Command Line Interface Reference.

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

The SGSN can now limit data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot support higher data rates - such as those enabled by HSPA+ (theoretically, up to 256 Mbps both downlink and uplink). Being able to specify the QoS individually for each RNC makes it possible for operators to allow their subscribers to move in-and-out of coverage areas with different QoS levels, such as those based on 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+).

For example, when a PDP context established from an RNC with 21 Mbps is handed off to an RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated to 16 Mbps. Note that an MS/UE may choose to drop the PDP context during the QoS renegotiation to a lower value.

This data rate management per RNC functionality is enabled, in the radio network controller (RNC) configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rates or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode section in the Command Line Interface Reference.

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 Command Line Interface Reference.

The SGSN selects S6d/Gr interface based on whether hss-peer-service or map service is associated with the SGSN or GPRS service. If both the services are associated, then the selection is made based on configuration of the CLI command prefer subscription-interface under the Call Control Profile mode. With this feature enhancement, the SGSN now allows selection of S6d/ Gr interface only if the UE is EPC capable. A new CLI option epc-ue is added to the command prefer subscription-interface under the Call Control Profile mode for this enhancement. If this keyword is configured the S6d/Gr interface is selected only if UE is EPC capable. If this keyword is not configured the SGSN selects the S6d/Gr interface based on whether hss-peer-service or map service is associated with the SGSN or GPRS service (this is also the default behavior). The interface selection based on UE capability is done only at the time of Attach / new SGSN RAU / SRNS. Interface selected during Attach / new SGSN RAU / SRNS may change while doing inter PLMN RAU (intra SGSN) procedures.

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.

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. SGSN supports use of IP Security (a separate license-enabled, standards-based feature) for the LI interface; for additional information on IPSec, refer to the Cisco StarOS IP Security (IPSec) Reference. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

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.

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.

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 .

The operator can configure a cap or limit for the QoS bit rate.

The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.

Depending upon the keywords included in the command, the SGSN can:

Refer to the APN Profile Configuration Mode section of the Command Line Interface Reference for the qos command.

3G/2G Location Change Reporting on the SGSN facilitates location-based charging on the P-GW by providing the UE's location information when the UE is in connected mode.

The Gn-SGSN supports 2G and 3G location change reporting via user location information (ULI) reporting to the GGSN. For details, see the feature section 3G-2G Location Change Reporting.

With Release 16.0, the S4-SGSN also supports 2G and 3G location change reporting per 3GPP 29.274 release 11.b, if the P-GW requests it. With this feature enhancement configured, the S4-SGSN is ready to perform ULI reporting per PDN connection via GTPv2. Reporting only begins after the S4-SGSN receives a reporting request from the P-GW. The P-GW generates a request based on charging enforcement and policy enforcement from the policy and charging rules function PCRF. Location Change Reporting is configured and enabled/disabled per APN.

The S4-SGSN's version of Location Change Reporting has been further enhanced with a network sharing option. If the network sharing license is installed and if the network sharing feature is enabled, then the operator can configure which PLMN information the SGSN sends to the P-GW in the ULI or Serving Network IEs.

Important

The S3/S4 license is required to enable S4 functionality. The new "Location-reporting in connected-mode" license is required to enable Location Change Reporting functionality for the S4-SGSN. This new license is now required for Location Change Reporting on the Gn-SGSN.

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. This functionality is supported on the 2G and 3G SGSN.

For details about basic location services and its configuration, refer to the Location Services section of the SGSN Administration Guide.

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:

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 Command Line Interface Reference.

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.

In accordance with 3GPP TS 23.251, the 2G and 3G 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).

The SGSN now supports use of NRI-RAI based address resolution which includes both local lookup as well as DNS Query for non-local RAIs when selection of the call control profile is based on the old-RAI and the PLMN Id of the BSC where the subscriber originally attached. This feature was formerly supported only for 3G subscribers and is now extended to 2G subscribers. The command enables the SGSN to perform address resolution for peer SGSN with an NRI when an unknown PTMSI (Attach or RAU) comes from an SGSN outside the pool. The SGSN uses NRI-RAI based address resolution for the non-local RAIs for 2G subscribers in place of RAI based address resolution.

This functionality is applicable in situations for either inter- or intra-PLMN when the SGSN has not chosen a local NRI value (configured with SGSN Service commands) other than local-pool-rai or nb-rai . This means the RAI (outside pool but intra-PLMN) NRI length configured here will be applicable even for intra-PLMN with differently configured NRI lengths (different from the local pool). This functionality is not applicable to call control profiles with an associated MSIN range as ccprofile selection is not IMSI-based.

The SGSN's DNS lookup for SGSN pooling is supported in the call control profile. Previously, the SGSN's complete Gn DNS database had to be configured in the call control profile. If there was more than one SGSN in the local pool, then there would be multiple instances for every SGSN in the pool.

By using just the NRI value, this enhancement facilitates lookup for a peer SGSN in the local pool.

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. For command details, see the Command Line Interface Reference

NRSPCA allows the network to initiate Secondary PDP context activation if the network determines that the service requested by the user requires activation of an additional secondary PDP context. Network requested bearer control makes use of the NRSPCA procedure.

Network requested bearer control functionality is mandatory in EPC networks, requiring use of NRSPCA. The P-GW supports only the NRSPCA procedure. With this release, now the S4-SGSN supports network requested bearer control.

For a complete description of this feature and its configuration requirements, refer to the Network Requested Secondary PDP Context Activation chapter in the Serving GPRS Support Node Administration Guide

This non-standard feature is unique to the StarOS. This feature empowers the carrier with unusual and flexible control to manage functions that are not 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

All configurations for SGSNs must be converted to enable them to operate with an SGSN. Your Cisco Representative can accomplish this conversion for you.

Overcharging Protection enables the Gn-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.

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.

The traditional proprietary Cisco ASR 5500 hardware platform provides carrier class hardware redundancy and have limited scalability. The VPC-SI model separates the StarOS from the proprietary hardware. It consists of the StarOS software running within a single VM. This provides the end user with low entry cost (software licenses and commodity hardware), simplified setup, and well-defined interfaces. The VPC-SI is ideally suited for small carriers, remote locations, lab testing, trials, demos, and other models where full functionality is needed. The Cisco VPC-Distributed Instance (VPC-DI) platform allows multiple VMs to act as a single StarOS instance with shared interfaces, shared service addresses, load balancing, redundancy, and a single point of management. The VPC-DI offers enhanced hardware capabilities and the SGSN is enhanced to support the VPC-DI platform.

Important

For more information on the VPC-DI platform, see the VPC-DI System Administration Guide.

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.

RAN information is transferred from a source RAN node to a destination RAN node in a RIM container. This is a mechanism for the exchange of information between applications belonging to RAN nodes, for example two BSCs. The RIM container is transparent to the SGSN.

Support for RIM procedures is optional for both the SGSN and other RAN nodes (e.g., RNC). When the SGSN supports RIM procedures, the SGSN provides addressing, routing and relay functions. All RIM messages are routed independently by the SGSN. The SGSN performs relaying of RIM messages between BSSGP, RANAP, and GTP in accordance with 3GPP TS 48.018, TS25.413, and TS29.060 respectively.

On the Gb (BSSGP) interface, RIM procedures are negotiated at the start/restart of a Gb link as part of the signaling BVC reset procedure. On the Iu (RANAP) interface, there is no negotiation for using RIM procedures. Support for RIM procedures enhances the subscriber's user experience by minimizing the service outage during cell re-selection.

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:

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.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processor cards to ensure task recovery.

When session recovery occurs, the system reconstructs the following subscriber information:

For more information on session recovery use and session recovery configuration, refer to the Session Recovery section in the System Administration Guide.

The details on the configurable values for SCTP parameters are provided in the table given below:

The details on the default values for SCTP parameters are provided in the table given below:

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:

The SGSN Pooling and Iu-Flex / Gb-Flex feature is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

The IMSI range supported has been enhanced to "2500" from "1000". The IMSI ranges configured must be unique; the SGSN selects the appropriate operator policy based on the IMSI range of the UE. The operator can verify the configured IMSI ranges and the associated operator policy by issuing the command "show config". The length of the description field in the imsi-range command under the SGSN Global Configuration mode has been reduced from a maximum of "100" alphanumeric characters to "50" alphanumeric characters. Reduction of the supported string size results in improvement of the boot up time.

The SGSN now supports a RAI based query when NRI based query fails. A new CLI option rai-fqdn-fallback is provided in the peer-nri-length CLI under the Call Control Profile Configuration, which allows the operator to configure the SGSN's support to fallback on RAI based query when NRI based query fails.

This feature is not supported in the following scenarios:

The SGSN now supports sending extended bitrates in both uplink and downlink directions. Extended bitrates are included in both uplink and downlink direction when the negotiated birate indicates that extended birates should be included in one direction. A new CLI ranap bidirectional-always ext-mbr-ie is added under the RNC Configuration mode to enable sending extended bitrates bi-directionally.

The SGSN supports options to configure PDP Data Inactivity detection duration and actions to be performed on timeout under the APN-Profile. The following configurable actions are supported under APN-Profile in case of PDP Data Inactivity detection in the PDP context:

On the Detection of the PDP Data Inactivity, depending on the configuration option the SGSN either de-activates the PDP or detaches the subscriber.

A new CLI ignore-pdp-data-inactivity is added to provide an option under the IMEI-Profile to ignore PDP Data Inactivity configuration for one or more IMEIs. On configuring this CLI, the SGSN ignores the application of in-activity configuration (configured in the APN-Profile) for a specified set of IMEI's.

Important

The IMEI range or set of IMEI's are mapped to specific IMEI-Profile using the CLI configuration option under Operator-policy. For more information on the command see. Command Line Interface Reference.

The SGSN implements a configurable Short Message Service (SMS) to support sending and receiving text messages up to 140 octets in length. The SGSN handles multiple, simultaneous messages of both types: those sent from the MS/UE (SMS-MO: mobile originating) and those sent to the MS/UE (SMS-MT: mobile terminating). Short Message Service is disabled by default.

After verifying a subscription for the PLMN's SMS service, the SGSN connects with the SMSC (short message service center), via a Gd interface, to relay received messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward.

In the reverse, the SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and checks the subscriber state before relaying them to the target MS/UE.

The SGSN will employ both the Page procedure and MNRG (mobile not reachable for GPRS) flags in an attempt to deliver messages to subscribers that are absent.

The SGSN supports

For information on configuring and managing the SMS, refer to the SMS Service Configuration Mode section in the Command Line Interface Reference.

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.

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.

During MMGR recovery due to memory overload or demux migration leads to missing status updates for RNC.As the result RNC status remains unavailable even when links towards RNC are up. The Session Controller allows the Standby Session Managers along with Active Session Managers to fetch the status updates.

This enhancement is a 3GPP TS (29.274 and 29.060) release compliance enhancement. As per 3GPP TS 29.274 and TS 29.060,the source-serving node (MME/SGSN) is allowed to reject SGSN Context Request (GTPv1) and Context Request (GTPv2) mobility management messages with "Target Access Restricted for the subscriber" cause if target access is restricted for the subscriber based on the Access-Restriction-Data in the subscription profile. The target node (MME/SGSN) is allowed to reject RAU/TAU with anyone one of the following NAS Causes:

New statistics have been introduced under "show egtpc statistics verbose" and "show sgtpc statistics verbose" to reflect the context response sent and received with the new reject cause "Target Access Restricted for the subscriber".

Rejecting RAU/TAU much early in call cycle results in reduced signaling.

Important

No new CLI is provided for GTP cause code mapping to EMM/NAS cause. RAU Reject will always be sent with NAS cause "No suitable cells in location area" and TAU Reject will always be sent with EMM cause "No suitable cells in Tracking Area".

For more information refer to the 3GPP TS 29.274 (section 7.3.6), TS 29.060 (section 7.5.4), TS 29.060 Annex B (Table B.5: Mapping from Gn/Gp to NAS Cause values Rejection indication from SGSN) and TS 29.274 Annex C ( Table C.5: Mapping from S3/S16 to NAS Cause values Rejection indication from MME/S4-SGSN)

Topology-based gateway selection is a mechanism defined by 3GPP to choose a gateway based on the geographical (topological) proximity of the GGSN to the SGSN or the P-GW to the S-GW. The two being co-located would have the highest priority. Topology-based selection is not allowed for roamers connected to HPLMN access points (Home Routed Scenario).

DNS S-NAPTR returns a candidate list of GW nodes for each of the DNS queries. 3GPP TS 29.303 provides an algorithm to feed these candidate lists and choose the topologically closer nodes among them. S-NAPTR DNS query is supported by default on the S4-SGSN and, with Release 16, can be enabled for the Gn/Gp-SGSN.

The SGSN's Topology-based GW Selection feature supports two levels of sorting, first level is degree and second level is order/priority, where order is for NAPTR records and priority is for SRV Records. Degree has the highest preference.

For details on the use and configuration of this feature, refer to the Topology-based Gateway Selection section in the SGSN Administration Guide.

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:

Thresholding reports conditions using one of the following mechanisms:

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 are supported in both the Alert and the Alarm models.

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.

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.

This feature is developed to comply with 3GPP TS 24.008. As per 3GPP TS 24.008, in some abnormal instances the MCC stored in the Mobile Station (MS) contains elements which do not belong to the set {0, 1 ... 9}. In such cases the Mobile Station should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network should treat the RAI as deleted. In some instances it is possible that the MNC stored in the Mobile Station has the following:

In such cases the MS should transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network should treat the RAI as deleted. The same handling is applicable for a network where a 3-digit MNC is sent by the mobile station to a network using only a 2-digit MNC.

A validation check has been introduced to verify the MCC and MNC fields received in the old RAI IE in Attach/RAU requests. When the MCC and MNC fields received in the RAU request (inter-SGSN) and are invalid, the RAU request is rejected by SGSN. When the MCC and MNC fields received in the Attach Request and are invalid, the identity of the MS is retrieved directly from the MS instead of sending identity request to the peer node where peer SGSN identity is derived from the old-RAI.

Important

These feature is applicable for both 2G and 3G networks.

A new CLI command [no] rai-skip-validation has been introduced under both IuPS service and GPRS service configuration modes. This new command enables/disables rejection of RAU requests with invalid MCC/MNC values in the old RAI field. By default the old RAI MCC/MNC fields are validated. This command also impacts the PTMSI attaches where the old RAI field is invalid. If the OLD RAI field is invalid and if the validation is enabled through the new CLI command, the identity of the MS is requested directly from the MS instead of the peer SGSN.

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.

For commands to configure the VLR and pooling, refer to the "Gs Service Configuration Mode" section in the Command Line Interface Reference.

The crash log is unique to each of the management cards, so if a crash occurs when card the "8" is active it will be logged on card "8". A subsequent switch-over would no longer display the crash in the log. To retrieve this crash, a switch back over to card "8" has to be done. The crash event log and dumps are unique to active and standby management cards, so if a crash occurs on an active card then the crash event log and related dumps will be stored on an active card only. This crash information is not available on the standby card. Whenever the cards switchover due to a crash in the active card, and crash information is no longer displayed on the card which takes over. Crash information can be retrieved only from the current active card. To retrieve the crash list of the other card a switch-over is required again. To avoid this switch-over and to obtain the crash information from the standby card, synchronization between two management cards and maintaining latest crash information is required.

The arriving crash event will be sent over to the standby SMC/MMIO and saved in the standby's crashlog file in the similar manner. Minicore, NPU or kernel dumps on flash of active SMC/MMIO needs to be synchronized to standby SMC/MMIO using the 'rsync' command. When a crash log entry or the whole list is deleted through the CLI command, it should be erased on both active and standby SMCs/MMIOs. There is no impact on memory. All the crash related synchronization activity will be done by the evlogd of standby SMC/MIO card, as the standby evlogd is less loaded and the standby card has enough room for synchronization activity. Therefore the performance of the system will not be affected.

This feature is developed to suppress the CDRs with zero byte data count, so that the OCG node is not overloaded with a flood of CDRs. The CDRs can be categorized as follows:

The customers can select the CDRs they want to suppress. A new CLI command [no] [default] gtpp suppress-cdrs zero-volume { external-trigger-cdr | final-cdr | internal-trigger-cdr } is developed to enable this feature. This feature is disabled by default to ensure backward compatibility. For more information see, Command Line Interface Reference and Statistics and Counters Reference.

Important

This is a license controlled feature.

The following outlines the setup procedure for a UE that is making an initial attach.

If the MS/UE initiates a second call, the procedure is more complex and involves information exchanges and validations between "old" and "new" SGSNs and "old" and "new" MSC/VLRs. The details of this combined GPRS/IMSI attach procedure can be found in 3GPP TS23.060.

The following figure provides a high-level view of the PDP Context Activation procedure performed by the SGSN to establish PDP contexts for the MS with a BSS-Gb interface connection or a UE with a UTRAN-Iu interface connection.

The following table provides detailed explanations for each step indicated in the figure above.

In some cases, the GGSN receives information that requires it to request the MS/UE to activate a PDP context. The network, or the GGSN in this case, is not actually initiating the PDP context activation -- it is requesting the MS/UE to activate the PDP context in the following procedure:

The table below provides details describing the steps indicated in the graphic above.

This process is initiated by the MS/UE for a range of reasons and results in the MS/UE becoming inactive as far as the network is concerned.

The following table provides details for the activity involved in each step noted in the diagram above.