> New In This 8.0 Release
> This chapter provides information on the major features and functionality added to the software with the 8.x release.
> Common Features
> Configurable Transmit Timing Source
> It is now possible to configure the transmit clock source, as either Building Integrated Timing Supply (BITS) or line-timing, for application services using SDH or SONET over the Optical line card or the Channelized line card.
> BITS-timing provides the transmit timing source, using Stratum 3 compliant BITS modules resident on either the SPIO with a BITS BNC interface or the SPIO with a BITS 3-pin interface. Line-timing recovers the receive timing from an external clock source via a port on an Optical or Channelized line card. It is possible to configure both clock sources, so that one timing source backs up the other.
> Configuration of this clock source is explained in Configuring Transmit Timing Source in the System Administration Guide.
> Domain-based L2TP Tunnel Support
> Benefits
> This feature enables initiation of new L2TP create tunnel request to same LNS address based on the value of attribute “Tunnel-Server-Auth-ID” in Access-Accept message received from AAA server. This value is treated as a key to identify tunnel. Thus, effectively, this result in multiple L2TP tunnels based on the value of attribute received from AAA server by a LAC. This value of attribute is treated as a key to identify tunnel.
> Description
> In earlier implementation, LAC chooses to create a new tunnel between LAC and LNS pair only when existing tunnel has reached its full capacity of allowed L2TP sessions per tunnel. There was no provision to the further segregation of the traffic between LAC and LNS.
> New CLI command tunnel selection-key { tunnel-server-auth-id | none } is added in LAC service configuration mode to support this feature. This command will provide facility to create new tunnel on the basis of domain name irrespective of the current capacity of existing tunnels established for different domains.
> The domain name (key to tunnel) is taken from the “Tunnel-Server-Auth-ID” attribute received from AAA server and when the LAC service needs to establish a new L2TP session, it will first check, if there is already an existing L2TP tunnel with the peer LNS based on the value of key “Tunnel-Server-Auth-ID” attribute value. If no such tunnel exists for the key, it will create a new tunnel with the LNS. Limit for maximum number of 32000 tunnels per LAC service is still valid.
> Default configuration have selection-key as none. Hence, LAC will not make use of key to choose a tunnel with LNS, in default setup.
> Maximum number of session as configured with max-sessions-per-tunnel command will be applicable for each tunnel created through this command. By default each tunnel supports 512 sessions.
> If LAC service needs to establish a new tunnel for new L2TP session with LNS and the tunnel create request fails because maximum tunnel creation limit is reached, LAC will try other LNS addresses received from AAA server in Access-Accept message for the APN/subscriber. If all available peer-LNS are exhausted, LAC service will reject the call.
> Important: Currently this support is available for GGSN only.
> ESS Features
> This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
> GGSN Features
> Multimedia Broadcast Multicast Service (MBMS)
> TP PR = 3915, ST16 PR = 23415
> Benefits
> MBMS is an IP datacast type of service in GSM and UMTS cellular network. It eliminates unnecessary replication of data on UMTS wireless networks by transmitting a single stream of data to multiple users. By delivering a single, unidirectional data stream to many subscribers, MBMS makes more efficient use of wireless network resources than traditional point to point connections.
> MBMS is a solution for transferring light video and audio clips and also a suitable method for mass communications. MBMS functionality on the system is provided by an existing GGSN and/or SGSN service license. In the absence of a valid license, the system functions as a standard unicast GGSN. When a GGSN is functioning in a MBMS environment, it supports Gmb protocol interface with Broadcast/Multicast Service Center (BM-SC) for messaging.
> Description
> This is an enhanced feature and provides two mode of operations:

> • | MBMS Broadcast Mode

> • | MBMS Multicast Mode

> A broadcast mode is a unidirectional point-to-multipoint service in which data is transmitted from a single source to multiple terminals (UE/MS) in the associated broadcast service area/cell area. The transmitted data can be text to light multimedia services (Audio, Video etc). On the other hand multicast mode is a unidirectional point-to-multipoint service in which data is transmitted from a single source to a pre-defined multicast group of users that are subscribed to the specific multicast service and have joined the multicast group in the associated multicast service area.
> The following figure shows the reference architecture of MBMS service in UMTS network.
> MBMS Reference Architecture in UMTS network.
> ../../../GRAPHICS/Production/System_Enhanced_Feature/MBMS_Reference_v1.wmf
> MBMS is able to use NPU assisted MBMS data flow processing on ASR 5000s so that system can relieve the Session Manager to provide better performance and processing. Currently with NPU assisted data processing ASR 5000 can support 225 SGSNs per MBMS Bearer Service for downlink of MBMS data.
> This enhancement is not applicable to ST16 platforms and a maximum of 15 downlink SGSNs per MBMS Bearer service are supported.
> For details about this new enhancement, refer MBMS Service Configuration chapter of the System Enhanced Feature Configuration Guide.
> License Keys
> No separate license key required.
> Traffic Shaping
> Benefits
> The bandwidth enforcement can be done in the downlink and the uplink direction independently. If there is no more buffer space available for subscriber data system can be configured to either drop the packets or kept for the next scheduled traffic session.
> Description
> This is an enhanced feature and is a traffic rate limiting method similar to the Traffic Policing, but it provides a buffer facility for packets exceeded the configured limit. Once the packet exceeds the data-rate, the packet queued inside the buffer to be delivered at a later time.
> License Keys
> Requires separate feature license key.
> Benefits
> The ASN Gateway provides following benefits and features

> • | Proven solutions deployed in many of the world’s largest Tier 1 production networks

> • | Unsurpassed subscriber and network intelligence with unique DPI technology and service steering capabilities

> • | High-capacity system meets and exceeds network requirements without changing or adding hardware

> • | Platform flexibility provides multi-service integration of multiple access gateway functions on same hardware platform

> • | Stateful transaction information, such as charging records, Quality of Service (QoS) and compression contexts, is seamlessly transferred on handoffs without the need for call re-registrations

> • | High value In-line Services enhance subscriber revenue generation opportunities and network efficiency

> Description
> ASN Gateway is the ideal subscriber mobility access gateway for IEEE 802.16e Mobile WiMAX radio access networks.
> The ASN Gateway is designed to support connection management and mobility across cell sites and inter-service provider network boundaries through processing of subscriber control and bearer data traffic. The ASN Gateway serves as the Extensible Authentication Protocol (EAP) authenticator for subscriber identity and acts as a RADIUS client to the operator’s AAA servers.
> ASN Gateway is a high capacity platform with the flexibility for small and large networks and can scale without changing or adding additional chassis. The system simplifies the network by reducing the required number of devices under management and minimizes connection set-up latency by reducing the number of call hand-offs in the network.
> The ASN Gateway can be integrated with a Home Agent (HA), Gateway GPRS Support Node (GGSN), or WiFi Packet Data Interworking Function (PDIF) for seamless mobility between Mobile WiMAX, 1xEV-DO, W-CDMA/UMTS, and WiFi networks. The integration of multiple access gateway functions promotes network simplification, streamlines network management, provides service ubiquity with no impact on the access network being utilized, and reduces capital and operational expenses.
> The ASN Gateway also provides the benefits of network-based mobility to non-Mobile IP-capable user access devices.
> License Keys
> Requires separate license key.
> Benefits
> The ASN Paging Controller and Location Registry provides following benefits and features

> • | Proven solutions deployed in many of the world’s largest Tier 1 production networks

> • | Unsurpassed subscriber and network intelligence with unique DPI technology and service steering capabilities

> • | High-capacity system meets and exceeds network requirements without changing or adding hardware

> • | Platform flexibility provides multi-service integration of multiple access gateway functions on same hardware platform

> • | Stateful transaction information, such as charging records, Quality of Service (QoS) and compression contexts, is seamlessly transferred on handoffs without the need for call re-registrations

> Description
> ASN Paging Controller and Location Registry (PC/LR) provides the paging and location update to WiMAX subscriber in IEEE 802.16 Mobile WiMAX radio access networks. This service can be used as a standalone product or in combination with ASN GW as co-located services on same chassis.
> Paging and Idle Mode Operation is responsible to maintain a track and alert for MS when it is in idle mode for battery power saving reasons. Paging is executed to alert MS when there is an incoming message. The following figure illustrates the paging operation along with paging and idle mode elements in the system.
> ASN Paging Controller and Location Registry (PC/LR) supports connection management and mobility across cell sites and inter-service provider network boundaries through processing of subscriber control and bearer data traffic.
> ASN Paging Controller and Location Registry Reference Model
> ../../../GRAPHICS/Production/ASN_GW/Paging_network_reference_model_v1.wmf
> In WiMAX networks, MS is tracked when it is in the idle mode and information is stored to a Location Register (LR). Paging Controller (PG) in retrieves the location from LR and alerts the Paging agent (PA) in BS to signal to MS.
> Location information for idle mode subscribers is maintained in a Location Register central database that is co-located on an anchor paging controller. Idle mode can be initiated by the mobile device or the network.
> The ASN PC/LR either run as a stand-alone function in a separate chassis or as an integrated service running on same chassis as the Anchor Authenticator (A-PC)/Anchor Datapath (A-DP) ASN GW. The current implementation is based on a topologically unaware paging scheme where the A-PC does not have global awareness of all member base stations in a paging group. The A-PC uses a single step paging operation where paging notifications are sent to the last reported serving paging controller or directly attached base station.
> License Keys
> Requires separate product license key.
> Network Controlled QoS
> Benefits
> This feature provides control of QoS for subscriber from network element side; i.e. GGSN. It uses bearer control mode and Active Charging Services parameters to provide packet filtering and other quality class identifier related configurations.
> Description
> Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN through Network Requested Update PDP Context (NRUPC) message. It can also activate a new secondary PDP context on Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
> License Keys
> Requires separate license key.
> Benefits
> Direct tunnel improves the user experience (e.g. expedited web page delivery, reduced round trip delay for conversational services, etc.) by eliminating SGSN tunnel ‘switching’ latency from the user plane. An additional advantage of Direct Tunnel from an operational and capital expenditure perspective is that direct tunnel optimizes the usage of user plane resources by removing the requirement for user plane processing on the SGSN.
> Description
> The Direct Tunnel architecture allows the establishment of a direct user plane tunnel between the RAN and the GGSN, bypassing the SGSN. The SGSN continues to handle the control plane signalling and typical makes the decision to establish Direct Tunnel at PDP Context Activation. A Direct Tunnel is achieved at PDP context activation by the SGSN establishing a user plane (GTP-U) tunnel directly between RNC and GGSN (using an Update PDP Context Request towards the GGSN).
> The following figure illustrates the working of direct Tunnel between RNC and GGSN.
> Direct Tunnel Support in GGSN
> ../../../GRAPHICS/Production/SGSN/SGSN-Direct-Tunnel_v2.wmf
> A major consequence of deploying Direct Tunnel is that it produces a significant increase in control plane load on both the SGSN and GGSN components of the packet core. It is therefore of paramount importance to a wireless operator to ensure that the deployed GGSNs are capable of handling the additional control plane loads introduced of part of Direct Tunnel deployment. The GGSN and SGSN offers massive control plane transaction capabilities, ensuring system control plane capacity will not be a capacity limiting factor once Direct Tunnel is deployed.
> Direct Tunnel Support
> TP PR = 4218, ST16 PR = 47324
> License Keys
> Requires separate license key.
> Hard Disk Storage for CDR Files
> A hard disk has been introduced in the ASR 5000 to add storage capability.
> When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see .

> • | Use the new command gtpp storage-server local file {local | remote } command in GTPP Group Configuration Mode to configure and enable hard disk usage.

> • | Use the new show/clear commands { show | clear } gtpp storage-server local file { counter | statistics } in the Exec Mode to monitor/clear the file counters and statistics on the hard disk.

> • | Use the new gtpp ram-disk-limit and gtpp compression-process commands in the Global Configuration Mode to allocate RAM for files and the number of compression process to support the hard disk functionality.

> GRE Protocol Interface
> Benefits
> GRE protocol functionality adds one additional protocol the ASR 5000 to support mobile users to connect to their enterprise networks through Generic Routing Encapsulation (GRE).
> GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
> The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiator.
> Description
> GRE Tunneling is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSEC offers, for example).
> GRE Tunneling consists of three main components:

> • | Passenger protocol-protocol being encapsulated. For example: CLNS, IPv4 and IPv6.

> • | Carrier protocol-protocol that does the encapsulating. For example: GRE, IP-in-IP, L2TP, MPLS and IPSEC.

> • | Transport protocol-protocol used to carry the encapsulated protocol. The main transport protocol is IP.

> The most simplified form of the deployment scenario is shown in the following figure, in which GGSN has two APNs talking to two corporate networks over GRE tunnels.
> GRE Deployment Scenario
> ../../../GRAPHICS/Production/System_Enhanced_Feature/GRE_deployment_scenario_v1.wmf
> For more information on functioning and configuration of this interface, refer GRE Protocol Interface chapter in System Enhanced Feature Configuration Guide.
> License Keys
> Requires separate license key.
> Overcharging Protection on Loss of Radio Coverage
> Benefits
> This solution provides the ability to configure mobile carriers to maximize their network solutions and balancing the requirements to accurately bill their customer.
> Description
> Consider scenario where a mobile is streaming or downloading very large files from external sources and the mobile goes out of radio coverage. If this download is happening on Background/Interactive traffic class then the GGSN is unaware of such loss of connectivity as SGSN does not perform the Update PDP Context procedure to set QoS to 0kbps (this is done when traffic class is either Streaming or Conversational only). The GGSN continues to forward the downlink packets to SGSN. In the loss of radio coverage, the SGSN will do paging request and find out that the mobile is not responding; SGSN will then drops the packets. In such cases, the G-CDR will have increased counts but S-CDR will not. This means that when operators charge the subscribers based on G-CDR the subscribers may be overcharged. This feature is implemented to avoid the overcharging in such cases.
> This implementation is based on Cisco-specific private extension to GTP messages and/or any co-relation of G-CDRs and S-CDRs. It also does not modify any RANAP messages.
> For more information of this feature, refer Subscriber Overcharging Protection chapter in System Enhanced Feature Configuration Guide.
> License Keys
> Requires separate license key.
> GSS Features
> This section in development.
> HA Features
> This section in development.
> Session Continuity Support for 3GPP2 and WiMAX Handoffs
> Benefits
> This capability brings the following benefits:

> • | common billing and subscriber management

> • | accessing home 3GPP2 service through Wimax network and vice versa

> • | better user experience with seamless session continuity

> Description
> This feature provides the session continuity capability to HA that enables a dual mode device (a multi radio device) to continue its active data session as it changes its active network attachment from 3GPP2 to Wimax and vice versa with no perceived user impacts from a user experience perspective.
> License Keys
> Requires separate license key.
> Enterprise HA
> Description
> The Enterprise Home Agent is designed to offer an operator hosted VPN and private networking service for a high number of enterprise-based subscribers with specialized networking applications. The requirements for this platform include provisioning of WAN connectivity between the E-HA and enterprise routers on the egress side using various tunneling protocols such as IPSEC, L2TP LAC and Ethernet VLANs. In this release the E-HA now provides the ability to provision multiple attached enterprises to the same egress context and use BGP4 route advertisement to dynamically advertise private overlapping addresses to downstream enterprise CPE routers. When IPSEC tunnels are used there is also a tighter inter-working between IPSEC tunnel and BGP peering state to insure consistency of state information between multiple protocol layers.
> Benefits
> Provides a highly secure network hosted private networking service for large enterprises that have data roaming users that seek remote connectivity solutions to enterprise managed applications. The enterprise HA also provides a cost effective solution for telemetry applications such as remote meter reading.
> Mobile IPv6
> Benefits
> Enables use of single mobility core network for provisioning of IPv6 and IPv4 Mobile IP access services. Mitigates IPv4 address depletion concerns for address intensive always-on applications and interactive applications such as VoIP, video telephony and Push-to-Talk (PTT).
> Description
> MIPv6 allows a user to maintain a persistent IPv6 address even when handing off between Access Service Networks (ASNs) connected to different ASN GWs and allows the access device to be reachable via the same MIPv6 Home of Address (HoA) irrespective of the current point of attachment. A Mobile IPv6 Node (MN) uses two IPv6 addresses:

> • | Care of Address (CoA) derived from Interface-ID assigned by DHCP Proxy component on ASN GW after verification of user or device credentials during network access

> • | Home of Address (HoA) assigned by HA during the Mobile IP registration with home network. The MN registers its current point of attachment by providing its CoA.

> The MN can operate in two modes:

> • | Bidirectional tunnel - In this mode, all data traffic originating from or destined to the MNs MIPv6 HoA is tunneled via the HA.

> • | Route optimization - In this mode, the MN informs its correspondent node of its current point of attachment, allowing the correspondent node to directly route packets destined to the MN's HoA through its CoA. Route optimization will not be supported in this release.

> Supported Features

> • | MIPv6 message authentication mobility options in binding updates as per RFC 4285

> • | MN-NAI mobility option in binding messages as per RFC 4283. The MN-NAI option must be included in all Binding messages (Eg initial registration and subsequent updates).

> • | Native 6-in-6 tunneling between ASR 5000 ASN GW and HA's

> • | Session-based 6TO4 tunneling between ASR 5000 HA and ST16 ASN GW

> • | Platform-based 6TO4 tunneling between ASR 5000 HA and adjacent 6BONE gateway routers

> IP Services Gateway Features
> This section in development.
> PDIF/FA Features
> Congestion Control and Overload Disconnect Support
> Beginning with the 8.1 release of 01/01/09, PDIF supports congestion control and overload disconnect.
> Refer to the “Congestion Control” chapter in the PDIF Administration Guide, and to the Command Line Interface Reference Guide for more configuration information
> Custom DNS Handling
> New CLI added to Crypto Template Config Mode: dns-handling { normal | custom }
> During IKEv2 session setup, MS may or may not include INTERNAL_IP4_DNS in the Config Payload (CP). PDIF may obtain one or more DNS addresses for the subscriber in DNS NVSE from a proxy-MIP Registration Reply message. If Multiple Authentication is used, these DNS addresses may be also received in Diameter AVPs during the first authentication phase, or in RADIUS attributes in the Access Accept messages during the second authentication phase.
> In normal mode, by default PDIF always returns the DNS address in the config payload in the second authentication phase if one is received from either the configuration or the HA.
> Custom mode is a new feature added to the CLI for this release to provide an alternative to the default operation. In custom mode, depending on the number of INTERNAL_IP4_DNS, PDIF supports the variety of behaviors described in the custom-dns handling section in the “Crypto Template Configuration Mode Commands” chapter of the CLI Reference Guide.
> DELETE Payload Default Action Change
> The IKEv2 stack currently always inserts a DELETE Payload in an INFORMATIONAL DELETE Response from both the PDIF and the MN (WMN).
> This default behavior has been updated to not insert a DELETE Payload when the response is from the PDIF.
> Note that this behavior is supported by clarifications in RFC 4718.
> IPMS Support
> IPMS is a licensed feature for PDIF. It provides access to more saved reporting and analysis information.
> It supports MIBs as they are developed and bulkstats. It must be configured in its own context.
> IPMS is described in detail in its own documentation suite, including online help files.
> Multiple Authentication
> Multiple Authentication is used when setting up a Proxy-Mobile-IP call with PDIF. In Stage One the device is authenticated with an HSS server.
> In Stage Two, the subscriber is authenticated with a AAA server over a RADIUS interface.
> In Stage One, the authentication method must be EAP-AKA. In Stage Two, the authentication must be either MD5 or GTC. If neither MD5 nor GTC is supported, the PDIF can convert these authentication messages and use standard PAP/CHAP authentication instead.
> This is fully described in the “PDIF Overview” chapter in the PDIF Administration Guide.
> Online Upgrade
> PDIF is now using an online upgrade model called Active-Standby. This requires a license to activate.
> Two chassis are connected by a redundancy link and Service Redundancy Protocol (SRP) is used over the link to monitor and control chassis state. Both active and standby chassis have SRP-Activated resources defined. Loopback interfaces are used in the example in the Admin Guide.
> “SRP-Activated” means that the resource is configured with srp-activate to make the protocol work between the two chassis. These resources are the same between the Active and Standby PDIF. Loop-back IP addresses in Ingress and Egress contexts and IP pools in egress contexts are usually SRP-Activated resources. Only the active chassis enables the SRP-Activated resources.
> Online upgrade is discussed in the PDIF Administration Guide.
> SRP and other required commands are documented in the Command Line Interface Reference.
> Public and Private Key Mismatch Check
> PDIF supports x.509 certificates. Every certificate has a public key of its own and configuration on a PDIF is done with the public key and a private key. A mechanism has now been added to verify the AUTH payload from PDIF using PDIF’s public key.
> If there is a mis-match in the keys, you now see the following warning:
> Failure: Public and Private key given for certificate does not match!
> Session Recovery
> Session Recovery is now a licensed feature for PDIF. It is described in the “PDIF Session Recovery” chapter of the Enhanced Features Guide and is also described in the PDIF Admin Guide.
> It is activated by the CLI require session recovery in the Global Config mode.
> Mobile WiMAX Access Service Network (ASN) Gateway Support
> Our ASN GW compliments our other core networks products to expand our carrier support for WiMAX network services.
> The new ASN GW functionality is fully IEEE 802.16e Mobile WiMAX standards compliant and readily handles the usual tasks, such as: mobility management, GRE tunneling, intra-ASN and inter-ASN handoffs, and session continuity support at HA for 3GPP2 and WiMAX subscriber session.
> ASN GW supports following WiMAX components as stand-alone or combined services:

> • | ASN Gateway

> • | WiMAX/4G HA Services

> • | Hybrid HA Service for 3GPP2 and WiMAX dual technology mobile node.

> Mobile WiMAX ASN Paging Controller and Location Registry Service Support
> This service compliments our WiMAX ASN Gateway to expand the WiMAX network services.
> The new ASN PC/LR functionality is fully IEEE 802.16e Mobile WiMAX standards compliant and readily handles the usual tasks, such as: paging controller, idle mode management, and location registry update for WiMAX subscriber session.
> ASN GW supports following WiMAX components as stand-alone or combined services:

> • | ASN Gateway

> • | Paging Controller and Location Registry

> • | WiMAX/4G HA Services

> • | Hybrid HA Service for 3GPP2 and WiMAX dual technology mobile node.

> SGSN Features
> The system provides wireless carriers with an unusually flexible form of Serving GPRS Support Node (SGSN) services. Functioning as an SGSN, the system readily handles wireless data services within 2.5G General Packet Radio Service (GPRS) and 3G Universal Mobile Telecommunications System (UMTS) data networks.
> The following documents have been created or modified to support the SGSN:

> • | Product Overview

> • | SGSN Administration Guide

> • | System Administration Guide

> • | System Enhanced Features Configuration Guide

> • | Command Line Interface Reference

> • | Statistics and Counters Reference

> • | SNMP MIB Reference

> • | CLI Reference Guide

> • | AAA Reference Guide

> • | Thresholding Configuration Guide

> • | ASR 5000 Hardware Installation and Administration Guide

> In a GPRS/UMTS network, the SGSN works in conjunction with Radio Access Networks (RANs or UTRANs), Home Location Registers (HLRs), and Gateway GPRS Support Nodes (GGSNs) to:

> • | Attach/detach subscriber sessions.

> • | Communicate with an HLR to register a subscriber’s User Equipment (UE), or to authenticate, retrieve or update subscriber profile information.

> • | Provide Short Message Service (SMS) and other text-based network services for attached subscribers.

> • | Activate and manage IPv4, IPv6, or Point-to-Point Protocol (PPP) -type Packet Data Protocol (PDP) contexts for a subscriber session.

> • | Setup and manage the data plane between the RNCs and the GGSN.

> • | Provide mobility management, location management, and session management for the duration of a call to ensure smooth handover.

> • | Provide various types of Charging Data Records (CDRs) to the Charging Gateway Function (CGF).

> The remainder of this section contains information on new SGSN features (listed alphabetically) being launched in release 8.0. Additional information on these features can be found in the Product Overview, SGSN Overview section, the SGSN Administration Guide, and in the CLI Reference Guide.
> 2.5G/3G Dual Access
> Within the same chassis, the SGSN can simultaneously operate as both a 2.5G SGSN and a 3G SGSN. This co-location has been done without proprietary protocols thus avoiding problems with mobility and handoff. Dual access provides a range of benefits, such as: use of the same hardware, load sharing, and the need for fewer IP addresses.
> Attach Rate Throttle
> It is unlikely that the SGSN would become a bottleneck because of the SGSN’s high signaling rates. However, other nodes in the network may not scale commensurately. To provide network overload protection, the SGSN provides a mechanism to control the number of attaches occurring through it on a per second basis.
> Direct Tunnel Support
> Fractional E1/DS1 Support
> The SGSN, using the Channelized Line Cards, now supports standard fractional E1/DS1 with up to 8 configurable groupings of time slots per port. This feature is configured with a combination of the commands in the Card Configuration Mode and Channelized Port Configuration Mode chapters of the CLI Reference Guide.
> Ga Interface to the CGF/GSS
> The SGSN now supports the Ga interface to the CGF or GSS for accounting purposes.
> The SGSN uses the Ga interface to communicate with the Charging Gateway Function (CGF) or GTPP Storage Server (GSS) using GTP Prime (GTPP). The charging gateway is responsible for buffering and pre-processing billing records. One or more Ga interfaces can be configured per system context. This interface is supported through the following commands in the Context configuration mode:

> • | gtpp charging-agent address

> • | gtpp duplicate-hold-time minutes

> • | gtpp echo-interval

> • | gtpp max-cdrs

> • | gtpp max-pdu-size

> • | gtpp max-retries

> • | gtpp redirection-allowed

> • | gtpp server

> • | gtpp storage-server

> • | gtpp timeout

> Gb-Flex - SGSN Pooling
> 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 functionary even without deploying SGSN pooling.
> As defined by 3GPP TS 23.236, the SGSN implements Gb-Flex functionality to ensure SGSN pooling for 2.5G accesses as both separate pools and as dual-access pools. SGSN pooling enables the following:

> • | Eliminates the single point of failure 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.

> Gs Interface to the MSC/VLR
> In Release 8.0, the SGSN now supports the Gs interface to the MSC/VLR.
> This interface is vital in the call-setup process as these databases provide authentication information about MS/UEs attempting to attach.
> The Gs Service Configuration Mode has been added to configure and manage the Gs interface between the SGSN and the MSC/VLR. This new mode includes the following commands:

> • | associate-sccp-network

> • | bssap+

> • | default

> • | end

> • | exit

> • | max-retransmission

> • | non-pool-area

> • | pool-area

> • | timeout

> • | vlr

> The new commands will be found the chapter titled Gs Service Configuration Mode Commands in the Command Line Interface Reference.
> Hard Disk Storage for CDR Files
> A hard disk has been introduced in the ASR 5000 to add storage capability.
> When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see .

> • | Use the new command gtpp storage-server local file {local | remote } command in GTPP Group Configuration Mode to configure and enable hard disk usage.

> • | Use the new show/clear commands { show | clear } gtpp storage-server local file { counter | statistics } in the Exec Mode to monitor/clear the file counters and statistics on the hard disk.

> • | Use the new gtpp ram-disk-limit and gtpp compression-process commands in the Global Configuration Mode to allocate RAM for files and the number of compression process to support the hard disk functionality.

> IuFlex / SGSN Pooling
> The SGSN supports 2G Gb Flex with SGSN Pooling and now 3G Iu Flex with SGSN Pooling as an orderable feature.
> Iu Flex and SGSN Pooling functionality has been implemented according to 3GPP TS23.236. The SGSN supports pooling for both 3G and 2G accesses, both as separate pools and as dual-access pools.
> IuFlex works by defining NRIs in the SGSN service and configuring RNCs as pooled. Pooled RNCs will be able to co-exist with RNCs that are connected to only one SGSN.
> Iu Flex offloading is also enabled via configuration. This implementation allows carriers to load balance sessions among pooled SGSNs; where Iu Flex provides carriers deterministic failure recovery.
> Additional benefits of Iu Flex include:

> • | Enables geographical redundancy, as a pool can be distributed across sites.

> • | Increases overall capacity, as load sharing across the SGSNs in a pool is possible.

> • | Reduces signaling load as well as data transfer due to conversion of inter-SGSN RAUs to intra-SGSN RAUs for moves between RAs controlled by the same pool.

> • | Simplifies introduction of new nodes and replacement of old nodes as subscribers can be moved in a planned manner to new nodes.

> • | Eliminates single point of failure between an RNC/BSS and SGSN.

> • | Enables service downtime for maintenance scheduling.

> Multiple PLMN Support (2.5G only)
> With this new feature, the 2.5G SGSN supports cell-sites with more than one PLMN-ID.
> Operators can now assign a different PLMN-ID to each cell in the network (typically, there are no more than 3 or 4 PLMN-IDs in a single network). This multiple PLMN support also enables an operator to 'hire out' their infrastructure to other operators who wish to use their own PLMN-IDs. Each cell can be part of only one PLMN (one GRPS service). By configuring the GPRS service for each PLMN-ID, this feature allows the 2.5G SGSN to perform handovers between the service instances.
> Configuring Multiple PLMN Support:
> The 2.5G SGSN supports MS handover from one PLMN to another PLMN by configuring multiple instances of the GPRS service, each with a different PLMN-ID, in the same context.
> Each of the GPRS services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context. For command details, refer to the GPRS Service Configuration Mode and MAP, SGTP, and GS Service Configuration Mode chapters in the Command Line Interface Reference.
> To enable appropriate S-CDR generation in a multiple PLMN-ID scenario, use the plmn-id-change keyword for the gtpp trigger command in the GTPP Group Configuration Mode also documented in the CLI Reference.
> CLI

> • | SMS is enabled with the short-message-service command in the MAP Service configuration mode. Entering this command accesses the SMS Service configuration mode with the commands to define the SMS service operational configuration:

> [cntxt_name]st40(config-map-service-serv_name)# short-message-service
> [cntxt_name]st40(config-map-service-serv_name-sms-service)#
> Network-Initiated PDP Context Activation
> SGSN now supports standards-compliant network-initiated PDP context activation. The network, or actually the GGSN, is not actually initiating the PDP context activation - it is requesting the MS/UE to activate the PDP context.
> Network Sharing
> PR6545
> The SGSN enables two or more network operators to share common network infrastructure. In accordance with 3GPP TS 23.251, the SGSN supports two different configurations for network sharing based on the resources being shared: gateway core network (GWCN) and multi-operator core network (MOCN).
> With GWCN, the complete RAN and partial core network are shared among different operators. Each operator will have its own network node for GGSN/HLR, etc., while sharing SGSN/MSC and the remaining radio network.
> ../../../GRAPHICS/Production/SGSN/NetShare_GWCN_v1.wmf
> With MOCN, the complete radio network is shared among different operators, while each operator maintains its own separate core network.
> ../../../GRAPHICS/Production/SGSN/NetShare_MOCN_v1.wmf
> With these two configurations, the SGSN supports multiple scenarios such as MOCN with non-supporting UE, MOCN with supporting UE, GWCN with supporting UE, and GWCN with non-supporting UE.
> NPU FastPath
> TP6514
> The NPU FastPath feature is proprietary and only available on the ASR 5000 SGSN systems. The purpose of this type of internal direct tunnel is to optimize resource usage and reduce latency when processing GTP-U packets. Incoming traffic passes through the switch fabric and the routing headers are changed to re-route traffic from the incoming Network Processing Unit (NPU) of the ingress PSC directly to the outgoing NPU of the egress PSC. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.
> SGSN NPU FastPath
> ../../../GRAPHICS/Production/SGSN/SGSN-FastPath_v3.wmf
> Fast path is established when both ends of a tunnel are available. Two fast path flows are established, one for the uplink and one for the downlink direction for a given PDP context.
> 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.
> The following situations will not have packets moved through FastPath:

> • | Traffic Policing & Shaping

> • | Subscriber Monitoring

> • | Lawful Intercept (LI)

> • | IP Source Violation Checks

> • | Intra-SGSN RAU

> • | Iu-connection release

> QoS Traffic Policing per Subscriber
> The SGSN now offers QoS traffic policing which enables the operator to configure and enforce bandwidth limitations on individual PDP contexts of a particular traffic class. Traffic policing typically deals with eliminating bursts of traffic and managing a traffic flow 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 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.
> For more information, see the SGSN Overview in the Product Overview and the Traffic Policing and Shaping and Dynamic QoS Renegotiation chapter in System Enhanced Feature Configuration Guide.
> Session Recovery Support
> The session recovery feature, now available for both 2G and 3G SGSNs, handles SGSN services for all attached and/or activated subscribers.
> When enabled, session recovery provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.�
> This is an enhanced feature and requires a separate license key to be enabled with the SGSN service. For more information on session recovery, refer to the System Enhanced Feature Configuration Guide.
> Short Message Service - SMS
> The SGSN implements a configurable Short Message Service (SMS) to send and receive 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).
> 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 both charging for SMS messages (MO - mobile originating and MT - mobile terminating) and lawful intercept of SMS-MO and SMS-MT messages.
> Configuration for the service is explained in the SGSN Administration Guide. The various CLI used to enable and configure the SMS service are defined in the Command Line Interface Reference.
> Traffic Handling - QoS Provisioning with ARP
> The SGSN now enables setting the priority of service via the configuration of the Allocation/Retention Priority (ARP) IE. By including this IE in the RANAP message during the RAB assignment procedure it is possible to specify the relative importance of the radio access bearers for the allocation and retention of traffic. When there is a resource crunch, the IE is used by the RNC to allocate or deallocate resources according to the defined priority. This IE also tells whether queuing of packets is allowed or not.
> Although the HLR subscription record only provides a single priority parameter (values 0 to 3), the RNC needs additional information, which our configuration command maps to the subscription priority. Additional information needed:

> • | Priority Level: 1..15

> • | Pre-emption Capability Indicator (PCI): shall-not-trigger-pre-emption, may-trigger-pre-emption

> • | Pre-emption Vulnerability Indicator (PVI): pre-emptable, not-pre-emptable

> • | Queuing Allowed: queuing-not-allowed, queuing-allowed

> For configuration details, see SGSN APN Configuration Mode in the CLI Reference Guide.
> Data Rate Management per RNC
> Configurable control of data rates on a per RNC basis enables operators to 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 established on 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 during the QoS renegotiation to a lower value.
> This data rate management per RNC functionality is enabled, in the RNC configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rate or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode chapter in the Command Line Interface Reference (version 8.x).
> CLC2 - Channelized Line Card 2
> New in release 8.1, the SGSN supports the Channelized Line Card 2 (CLC2), the next-generation SONET/SDH channelized line card for Frame Relay signaling on the ASR 5000.
> In North America, the card supplies ANSI SONET STS-3 (optical OC-3) signaling. In Europe, the card supplies SDH STM-1 (optical OC-3). The transmission rate for the card is 155.52 Mb/s with 336 SONET channels supplying T1 and 252 SDH channels supplying E1. The CLC2 is RoHs 6/6 compliant. Each CLC2 provides four optical fiber physical interfaces (ports). For more information about this card, refer to the ASR 5000 Hardware Installation and Administration Guide.
> OLC2 - Optical Line Card 2
> New in release 8.1, the SGSN supports, the SGSN supports the Optical Line Card 2 (CLC2), the next-generation SONET/SDH optical line card for ATM signaling on the ASR 5000.
> The OLC2 supports all features, including 4 ports, available on the original OLC but now includes RoHs 6/6 compliance. For more information about this card, refer to the ASR 5000 Hardware Installation and Administration Guide.
> PSC2 - Packet Services Card 2
> New in release 9.0, the SGSN supports the Packet Services Card 2 (PSC2), the next-generation packet forwarding card for the ASR 5000. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions. For more information about this card, refer to the ASR 5000 Hardware Installation and Administration Guide.
> Web Element Manager Features
> Configuration Audit
> The Web Element Manager now supports the ability to audit configuration parameters (attributes) for each managed chassis.
> Audits are performed based on user-specified audit attributes either on-demand or at regularly scheduled intervals. When an audit is performed, the Web Element Manager executes scripts to pull configuration information from managed chassis via SSH and parse the configuration for the specified audit attributes. Once gathered, the attribute information is stored in a database. Attribute information can be viewed through the Web Element Manager application or in PDF or CSV-formatted reports.

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