> New Feature Summary
> This chapter identifies features and functionality added to or modified for the following products in one or more releases.
> Topics covered in this chapter are:

> l | Related Documents

> l | Common Features in Release 12.0

> l | ADC Features in Release 12.0

> l | ASN GW Features in Release 12.0

> l | Content Filtering Features in Release 12.0

> l | ECS Features in Release 12.0

> l | ESS Features in Release 12.0

> l | Firewall Features in Release 12.0

> l | FNG Features in Release 12.0

> l | GGSN Features in Release 12.0

> l | HA Features in Release 12.0

> l | HNB-Gateway Features in Release 12.1

> l | HSGW Features in Release 12.0

> l | IP Services Gateway Features in Release 12.0

> l | Mobility Management Entity Features in Release 12.0

> l | MUR Features in Release 12.0

> l | MVG Features in Release 12.0

> l | NAT Features in Release 12.0

> l | PDG/TTG Features in Release 12.0

> l | PDIF Features in Release 12.0

> l | PDSN Features in Release 12.0

> l | P-GW Features in Release 12.0

> l | SCM Features in Release 12.0

> l | Serving Gateway Features in Release 12.0

> l | SGSN Features in Release 12.0

> l | SGSN Features in Release 12.1

> l | Web Element Manager Features in Release 12.0

> Related Documents
> Additional information on the items listed in this chapter is available in the documentation listed in the table below.

> Released Documentation
> Document
> Cisco ASR 5000 Series Product Overview Guide
> Cisco ASR 5000 Series Packet Data Serving Node Administration Guide
> Cisco ASR 5000 Series SNMP MIB Reference
> Cisco ASR 5000 Series Gateway GPRS Support Node Administration Guide
> Cisco Web Element Manager Installation and Administration Guide
> Cisco ASR 5000 Series Command Line Interface Reference
> Cisco ASR 5000 Series GTPP Storage Server Installation and Administration Guide
> Cisco ASR 5000 Series Enhanced Charging Services Administration Guide
> Cisco ASR 5000 Series Session Control Manager Administration Guide
> Cisco ASR 5000 Series Access Service Network Gateway Administration Guide
> Cisco ASR 5000 Series AAA and GTP Interface Administration and Reference
> Cisco ASR 5000 Series Release 11.0 to Release 12.x Change Reference
> Cisco ASR 5000 Series Content Filtering Services Administration Guide
> Cisco ASR 5000 Series Application Detection and Control Administration Guide
> Cisco ASR 5000 Series IP Services Gateway Administration Guide
> Cisco ASR 5000 Series Packet Data Interworking Function Administration Guide
> Cisco ASR 5000 Series Personal Stateful Firewall Administration Guide
> Cisco ASR 5000 Series Thresholding Configuration Guide
> Cisco ASR 5000 Series Serving GPRS Support Node Administration Guide
> Cisco ASR 5000 Series System Administration Guide
> Cisco ASR 5000 Series Home Agent Administration Guide
> Cisco ASR 5000 Series InTracer Installation and Administration Guide
> Cisco ASR 5000 Series HRPD Serving Gateway Administration Guide
> Cisco ASR 5000 Series Packet Data Network Gateway Administration Guide
> Cisco ASR 5000 Series Serving Gateway Administration Guide
> Cisco ASR 5000 Series Mobility Management Entity Administration Guide
> Cisco ASR 5000 Series Lawful Intercept Configuration Guide
> Cisco ASR 5000 Series Statistics and Counters Reference
> Cisco ASR 5000 Series Network Address Translation Administration Guide
> Cisco ASR 5000 Series Mobility Unified Reporting System Installation and Administration Guide
> Cisco ASR 5000 Series Aggregation Services Router Hardware Installation and Administration Guide
> Cisco ASR 5000 Series Femto Network Gateway Administration Guide
> Cisco ASR 5000 Series 3G Home NodeB Gateway Administration Guide
> Cisco ASR 5000 Series Packet Data Gateway/Tunnel Termination Gateway Administration Guide
> Cisco ASR 5000 Series Intelligent Policy Control Function Administration Guide
> Cisco ASR 5000 Series Subscriber Service Controller Installation and Configuration Guide
> Cisco ASR 5000 Series Policy Provisioning Tool Installation and Configuration Guide
> Cisco ASR 5000 Series MCRDBS Installation and Administration Guide
> Cisco ASR 5000 Traffic Performance Optimization Administration Guide
> Cisco ASR 5000 Evolved Packet Data Gateway Administration Guide
> Cisco ASR 5000 Home Evolved Node B Gateway Administration Guide
> Cisco ASR 5000 Mobile Services Edge Gateway - 3G Administration Guide
> Cisco ASR 5000 Series Mobile Video Gateway Administration Guide
> Open Source Software Licenses for Cisco ASR 5000 Series Multimedia Network Core Platform
> Open Source Software Licenses for Cisco GTPP Storage Server
> Open Source Software Licenses for Cisco Mobility Unified Reporting System
> Open Source Software Licenses for Cisco Local External Storage Server
> Open Source Software Licenses for Cisco Policy Provisioning Tool
> Open Source Software Licenses for Cisco Subscriber Service Controller
> Open Source Software Licenses for Cisco Web Element Manager
> Open Source Software Licenses for Cisco InTracer

> The latest versions of the documentation are available on Cisco.com:
> http://www.cisco.com/en/US/products/ps11072/tsd_products_support_series_home.html
> Common Features in Release 12.0
> This section provides information on new features that are common to products in Release 12.0.
> Bearer-Usage AVP Value for Primary/Secondary Contexts - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gy interface.
> In the earlier releases, the Bearer-Usage AVP was encoded with the value GENERAL(0) irrespective of whether the context is primary or secondary in the Diameter Gy CCR message.
> In the current release, the Bearer-Usage AVP will be encoded with the value GENERAL(0) for Primary-PDP context/default bearer and with the value DEDICATED(2) for all secondary-PDPs/dedicated bearers.
> Call Termination for CCA-I with Error-result Code - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, when there were no static rules configured in the chassis and if the PCRF returns a error-result code in CCA-I with CCFH action as continue, then the call was not terminated.
> In the current release, P-GW terminates the call even if the static rules are not configured and an error-result code is returned in CCA-I with CCFH action set as continue.
> Call Termination Without CCR-T During Failure - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, CCR-T was sent when a permanent failure result code (5xxx result codes) was received and the Disconnect reason was "ims_auth_decision_invalid".
> In the current release, the call is dropped without sending CCR-T when the permanent failure result code (5xxx result codes) is received and the Disconnect reason will be "ims-authorization-failed".
> Case Insensitive Configuration of Diameter Nodes - Behavioral Change
> This Diameter-related behavioral change is applicable to all products.
> In the earlier releases, the configuration of Diameter nodes and host strings like endpoint name, peer name, host name, realm name, and fqdn were case-sensitive. Hence, it was difficult to handshake with an external node with the name specified in a different case. That is, if a peer is configured as peer.cisco.com, it failed to open connections from a peer identifying as PEER.cisco.com. Also, configuring endpoints with different cases duplicate the configuration. For example, when configuring endpoints ep1 and EP1, it will assume it to be different and add these separately in the configuration.
> In the current release, all the Diameter related node IDs are considered case insensitive. This change applies to both the local configuration and communication with external nodes. When configuring endpoints s6a-endpoint-mme, S6A-endpoint-MME, S6A-ENDPOINT-MME, all these three will be considered the same.
> Diameter Server Selection for Load-balancing
> Diameter load balancing implementation maintains a fixed number of servers active at all times for load balancing in case of failures. This can be done by selecting a server with lower weight and adding it to the set of active servers.
> Consider the following requirements in the Diameter Endpoint configuration for load balancing:

> l | Endpoint configuration is needed to specify the minimum number of servers that needs to be active for the service.

> l | If any one of the servers in the current active group fails, one of the idle servers needs to be selected for servicing the new requests.

> l | New sessions should be assigned to idle servers with higher weight.

> l | New session should be assigned to idle servers with lower weight only if

> l | The number of active servers are less than the minimum number of servers required for the service

> l | Idle servers with higher priority are not available

> For more information, refer to the ASR 5000 Series Co mmand Line Interface Reference.
> eG-CDR in Delimiter Separated ASCII Format
> This release supports generating eG-CDRs in delimiter separated ASCII format.
> eG-CDRs can be in ASN.1 format or in delimiter-separated ASCII format. Configuring the eG-CDR encoding type is a CLI-configurable parameter. The default encoding type is ASN.1. When configuring the eG-CDR encoding type as ASCII, the delimiter character can be specified as either “:” (colon), “,” (comma), or “|” (pipe). The default delimiter character is “|” (pipe).
> Encoding of Bearer-Usage AVP in CCR Messages - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the Bearer-Usage AVP was sent in session level CCR-U and CCR-T messages.
> In the current releases, the Bearer-Usage AVP is sent only during the establishment of bearers in CCR-I and CCR-U with bearer operation as “Establishment”. This condition is imposed because the session level CCR-U is intended for the entire session and not for a particular bearer.
> Encoding of Destination-Host AVP in Initial-Request Messages - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the S6a interface.
> In the earlier releases, the Destination-Host AVP was not sent in session-setup/initial request (first message sent on that interface for that subscriber. This message will vary with different interfaces. For example, CCR-Initial for Gy, ACR-start for Rf, and so on). Also, Destination-Host AVP was not sent in retried requests. For example, CCR-Update failed to be responded by server. The message was retransmitted to alternate server.
> In both these scenarios, it is not known which server will respond to the initial/retried message, so the Destination-Realm is encoded but not the Destination-Host. Only after a response for this message is received from one of the hosts present in that realm, the session is considered to be BOUND with that server. Any message sent after this binding will have the Destination-Host AVP encoded.
> In the current release, with the CLI command "destination-host avp session binding … ", if the application has selected one of the servers using application-level commands like peer-select command in case of credit-control or diameter authentication/accounting server command in AAA group, encoding of this AVP in initial/retried request is configurable.
> Encoding of Network-Request-Support AVP in CCR Messages - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the Network-Request-Support AVP was sent in CCR-T and session level CCR-U messages.
> In the current release, if the network-initiated bearer establishment request procedures are not applicable during IP-CAN session establishment, this AVP will not be encoded in CCR-I and in the subsequent messages unless the AVP value is toggled from 1 to 0 and vice-versa.
> If the network-initiated procedures are applicable during IP-CAN session establishment, this AVP will be encoded only in the CCR-I and not in the subsequent messages including session level CCRs unless the AVP value is toggled.
> Encoding of QoS-Upgrade and QoS-Negotiation AVPs in CCR Messages - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the QoS-Upgrade and QoS-Negotiation AVPs were sent in session level updates and in CCR-T message.
> In the current release, as the QoS-Upgrade and QoS-Negotiation AVPs are applicable to bearer, these AVPs will no longer be sent in the CCR-U and CCR-T messages.
> Failure Handling Configuration in IMSA Service - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, in the case of failure handling, if the CLI command “failure-handling cc-request-type …“ is configured twice under ims-auth-service then the following error message "Failure: Apply config error" is displayed. For example, if the failure-handling configured is "X" and if the same failure-handling "X" is applied again then the error message "Failure: Apply config error" is displayed.
> In the current release, if the same failure-handling configuration is applied under IMSA service then the configuration is accepted as valid and it does not throw any error message.
> Fire-and-Forget Feature
> This release supports the RADIUS Fire-and-Forget feature in conjunction with GGSN for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the APN is supported.
> This release also supports the No-ACK RADIUS Targets feature in conjunction with PDSN and HA for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting the acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the subscriber template is supported.
> For more information, refer to the ASR 5000 Series Command Line Interface Reference.
> Handling of Vendor-specific Application IDs - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, when the Diameter proxy was not configured, the grouped AVP “Vendor-Specific-Application-Id” in CER/CEA messages contained all the Vendor IDs present in the dictionary file. Hence, if the Gx application used a Customer Specific AVP, this Vendor ID was also added in the Vendor-Id of Vendor-Specific-Application-Id AVP.
> In the current releases, if use-proxy is not configured in the Diameter endpoint, the Vendor-Specific-Application-Id AVP in CER/CEA messages will contain only the 3GPP Vendor ID (10415) in the Vendor-Id of the Vendor-Specific-Application-Id AVP.
> Multiple-Services-Indicator AVP in Diameter CC Requests - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gy interface.
> In the earlier releases, Multiple-Services-Indicator AVP was sent in all diameter CC request messages - CCR(I/U/T).
> In the current release, Multiple-Services-Indicator AVP will be sent in CCR-Initial message only. This AVP will not be sent in update/terminate requests. This is applicable for all Gy dictionaries.
> Notification of Bearer Session Termination During Failover - Behavioral Change
> This Diameter-related behavioral change is applicable to GGSN.
> In the earlier releases, if in a scenario where there are multiple network initiated bearers and one UE initiated bearer and if only UE initiated bearer is down,

> l | the PCRF was not notified about the bearer deletion i.e., a CCR-U with bearer operation termination was not sent to the PCRF.

> l | Also, the “show ims-authorization sessions full all" CLI command displayed one IMSA session after the deletion of UE initiated bearer.

> In the current release, if UE initiated bearer is down,

> l | PCRF will be intimated about this bearer deletion i.e., a CCR-U with bearer operation termination will be sent to PCRF. Subsequently, a new IMSA session will be created for one of the existing network initiated bearers (Normally IMSA session will be created ONLY for UE initiated bearers).

> l | Before receiving the answer (CCA) from PCRF, the "show ims-authorization sessions full all" CLI command will show two IMSA sessions.

> l | After receiving the answer (CCA) from PCRF the "show ims-authorization sessions full all" CLI command will show one IMSA session.

> Post-processing of Blacklisted Content
> Whenever RADIUS/Diameter prepay server blacklists content the packets are generally discarded. To enable redirection of such content, post-processing on blacklisted content is required. With this change, RADIUS/Diameter Credit-Control application will decide on whether to allow post-processing to be enabled or not for the blacklisted content.
> In release 12.0, in the ACS Rulebase Configuration Mode, the following configuration is available to enable post-processing priority based rules for content in blacklisted state.
> post-processing policy { always | not-for-dynamic-discard }
> default post-processing policy
> Release 12.0 onwards “cca quota-state ...” and “cca redirect-indicator ...” ACS ruledef commands should be used as a post-processing rule. And, “post-processing policy always” command should be configured in the ACS Rulebase Configuration Mode for these post-processing rules to be enabled for blacklisted content.
> IMPORTANT: In existing deployments, this requires changes to configurations with quota-limit rules for certain features to work.
> The following is a sample configuration from existing deployments before this change:
> configure
> active-charging service service1
> ruledef http_low
> http any-match = TRUE
> cca quota-state = limit-reached
> #exit
> ruledef httpany
> http any-match = TRUE
> #exit
> charging-action standard1
> content-id 1
> cca charging credit
> #exit
> charging-action redirect
> flow action redirect-url http://aoc.com
> #exit
> rulebase base1
> action priority 10 ruledef http_low charging-action redirect
> action priority 30 ruledef httpany charging-action standard1
> #exit
> end
> The following is a sample configuration after this change:
> configure
> active-charging service service1
> ruledef http_low
> http any-match = TRUE
> cca quota-state = limit-reached
> rule-application post-processing
> #exit
> ruledef httpany
> http any-match = TRUE
> #exit
> charging-action standard1
> content-id 1
> cca charging credit
> #exit
> charging-action redirect
> flow action redirect-url http://aoc.com
> #exit
> rulebase base1
> action priority 30 ruledef httpany charging-action standard1
> post-processing policy always
> post-processing priority 1 ruledef http_low charging-action redirect
> #exit
> end
> If this configuration change is not undertaken, when the content is blacklisted and for any packet that can be redirected and that matches this blacklisted content, then redirection will not happen based on “flow action redirect-url” command.
> Realm-based Routing
> In the current release, the Diameter routing logic has been modified to enable routing to destination hosts that are not directly connected to the Diameter clients like GGSN, MME, PGW, and that does not have a route entry configured. Message routing to the host is based on the realm of the host.
> For a given session towards a Destination Host, all the messages belonging to the session will be routed through the same peer until the peer is down. If the peer goes down, for the subsequent messages failure handling mechanism will be triggered and the message will be sent using other available peers connected to the destination host.
> Sanity Checks for Revalidation-Time AVP - Behavior Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, if Revalidation-Time AVP sent in CCA-I message by PCRF fails sanity checks, call is terminated with the Termination-Cause AVP set to the value DIAMETER_BAD_ANSWER (3).
> In the current release, the call will continue irrespective of the sanity failure status of Revalidation-Time AVP in the CCA-I message.
> Smart Call Home
> This release of StarOS incorporates the initial hooks required to support Cisco Smart Call Home (SCM). Smart Call Home is a powerful service capability of Cisco SMARTnet® Service that offers real-time alerts, remediation, and personalized web-based reports on select Cisco devices. Customers and the Technical Assistance Center (TAC) get the information they need to quickly identify and resolve network issues rapidly.
> Cisco Smart Call Home enables faster issue resolution and higher network availability by:

> l | Providing a continuous connection to Cisco that provides monitoring, real-time troubleshooting, alerts, and remediation on select Cisco “call home” enabled devices.

> l | Automatically generating a Cisco Service Request for severity 1 problems and is sent to the appropriate engineer at TAC.

> l | Giving the customer greater visibility into network performances through Call Home messages, recommendations, inventory, field notices, security advisories, and End-of-Life notices for select Cisco devices through a Web-based portal.

> Full support for Call Home functionality will be introduced later this year. Smart Call Home will be available as part of a Cisco SMARTnet Service contract.
> TACACS+ AAA Service Support for Administrative Users
> This release supports TACACS+ authentication, authorization and accounting services for ASR 5000 administrative users.
> For more information on TACACS+ configuration and maintenance, refer to the ASR 5000 Series System Administration Guide, the ASR 5000 Command Line Interface Reference, and the ASR 5000 Statistics and Counters Reference.
> Upgrade Support for 3GPP Release based Dictionary - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In release 12.0, in the Policy Control Configuration mode, the following configuration is available to upgrade any 3GPP release based dictionary to higher version.
> [default | no] diameter update-dictionary-avps {3gpp-r8 | 3gpp-r9}
> Release 12.0 onwards, if a Rel. 7 based dictionary is already configured with diameter dictionary dpca-custom4 command, and then if the diameter update-dictionary-avps 3gpp-r9 command is applied, the Supported-Features AVP with feature bit 1 being set will be sent in the CCR-I to indicate that 3GPP Rel. 9 AVPs are also supported.
> This CLI command when configured results in behavioral changes as indicated in the following table.

> Possible Upgrade Scenarios | Behavior
> 3GPP Rel. 7 based dictionary upgraded to 3GPP Rel. 9 For example: diameter dictionary dpca-custom4 diameter update-dictionary-avps 3gpp-r9 | In the CCR-I, Supported-Features AVP will be encoded with value 2 for the Feature-List AVP. [V] [M] Supported-Features: [M] Vendor-Id: 10415 [V] [M] Feature-List-ID: 1 [V] [M] Feature-List: 2 The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9. In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in the 3GPP Rel. 9 will be supported.
> 3GPP Rel. 7 based dictionary upgraded to 3GPP Rel. 8 For example: diameter dictionary dpca-custom4 diameter update-dictionary-avps 3gpp-r8 | In the CCR-I, Supported-Features AVP will be encoded with value 1 for the Feature-List AVP. [V] [M] Supported-Features: [M] Vendor-Id: 10415 [V] [M] Feature-List-ID: 1 [V] [M] Feature-List: 1 The Feature-List AVP value suggest that it is 3GPP Rel. 8 compliant. But, it is not fully complaint to 3GPP Rel. 8. In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 8), none of the features mentioned in 3GPP Rel. 8 will be supported.
> 3GPP Rel. 8 based dictionary upgraded to 3GPP Rel. 9 For example: diameter dictionary r8-gx-standard diameter update-dictionary-avps 3gpp-r9 | In the CCR-I, value for the Feature-List AVP in the Supported-Features AVP will be 2. [V] [M] Supported-Features: [M] Vendor-Id: 10415 [V] [M] Feature-List-ID: 1 [V] [M] Feature-List: 2 The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9. Currently for this upgrade scenario (3GPP Rel. 8 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in 3GPP Rel. 9 will be supported.

> Validation of QCI for Default-EPS-Bearer-QoS AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to P-GW Rel. 8 Gx interface support.
> In the earlier releases, for Default-EPS-Bearer-QoS AVP, the IMSA validation for Quality of service Class Identifier (QCI) range was performed based on standard specifications. The ranges 1–9 and 128–254 were considered valid.
> In the current release, the range 1–32 is valid. This change has been implemented to align with the configurable QCI range that the CLI supports.
> Vendor-IDs in CER/CEA for STa and S6b Applications - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the STa and S6b application interfaces.
> In the earlier releases, CER/CEA for STa and S6b applications included all the vendor-ids supported by the dictionary in Vendor-ID AVP under Vendor-Specific-Application-ID Grouped AVP. However, per the specification, it should include only 3GPP Vendor-ID (10415) as these are 3GPP specific applications.
> In the current release, for the STa and S6b applications, the CER/CEA will have only 10415 (3GPP Vendor-ID) as Vendor-ID AVP value under Vendor-Specific-Application-ID AVP.
> Volume Reporting over Gx - Behavioral Changes
> The following behavioral changes relate to the Volume Reporting over Gx feature:

> l | Total threshold level along with uplink/downlink threshold level is treated as an error and only total threshold level is now accepted.

> l | Enabling and disabling session usage in a single message from PCRF is now supported. This is only if the monitoring key is associated at session level.

> l | If no new threshold is provided in response for the usage report, monitoring is stopped. Earlier workaround to stop monitoring by providing the Usage-Monitoring-Information AVP but without threshold is now not applicable.

> l | Monitoring usage based on input/output octet threshold levels is now supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).

> l | Volume or rule information obtained from PCRF is discarded when the subscriber is going down.

> l | Usage reporting on last rule deactivation using rule deactivation time set by PCRF is now supported.

> For more information on Volume Reporting over Gx feature, refer to the Gx Interface Support appendix in the core network service administration guide.
> ADC Features in Release 12.0
> This section provides information on new Application Detection and Control (ADC) features in Release 12.0.
> P2P Protocols Detection Support
> This release now supports the detection of the following P2P protocols:

> l | Blackberry

> l | Gmail

> l | iTunes

> l | MySpace

> l | TeamViewer

> l | Twitter

> l | Viber

> For more information, please refer the Application and Detection Control Administration Guide.
> Video Detection Support
> The system now supports video detection for the following P2P protocols:

> l | Gtalk

> l | Oscar

> l | Yahoo

> For more information, please refer the Application and Detection Control Administration Guide.
> ASN GW Features in Release 12.0
> This section provides information for new features in the ASN GW Service in Release12.0
> WiMAX HA and ASN-GW have been enhanced to support profile-based hotlining as per WiMAX Forum™ Network Architecture, NGW 1.5 specification. See Interface Changes for additional information.
> Support for 802.1P Marking
> 802.1p marking is now supported on ASN-GW with or without Ethernet CS support. See Interface Changes for additional information.
> Support for IP 5-Tuple Flow-Based Pre-Paid Accounting
> Support has been added for IP 5-tuple flow-based prepaid accounting using ECSv2 rulebase configuration support for WiMAX, ASN-GW and HA calls.
> Also added Hotlining support for IP 5-tuple flow-based prepaid call sand postpaid sessions on WiMAX, HA and ASN-GW.
> Single DCCA Session Support
> ASN-GW now supports a single DCCA session for all the bearers in an IP-CAN Session. See Interface Changes for additional information.
> Device ID (MAC Address) Support for WiMAX HA MIPv4 Calls
> Device ID extension support has been implemented the following items:

> l | Device ID extension support for MAC address in PMIPv4

> l | Hold timer functionality based on MAC address.

> l | Callgen-FA support for MAC address (device id) extension

> l | MAC address inclusion in log messages

> l | Session recovery related changes for MAC address

> l | show/clear commands with mac-address option

> See Interface Changes for additional information.
> Payload Header Suppression Support Feature
> Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.
> WiMAX HA: Accept MIP Call Without FA-HA AE
> Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.Feature
> Added a CLI command option for fa-ha spi config on HA to address the following requirements:

> l | FA-HA AE is configured as “enabled” with specific range of FA addresses.

> l | FA-HA AE is configured as “disabled” with specific range of FA addresses

> The following CLI command configures these options:
> fa-ha-spi remote-address <ip_address> spi-number <spinumber> secret <secret > [allow-fa-ha-auth-extension | disallow-fa-ha-auth-extension]
> See Interface Changes for additional information.
> New Dictionary for Specific Set of AAA Attributes
> A new, HA-specific dictionary has been added as “custom53”. This dictionary contains a specific set of UQ Communications (UQC) AAA attributes.
> RADIUS Test Frame Sent According to UQC AAA Dictionary
> The ASN-GW can now send the RADIUS test frame (Auth Req and Acct Req) with the exact attribute set identified for the UQC dictionary.
> WiMAX Hotlining for Post Paid Sessions
> The following features have been added in this release to support WiMAX hotlining:

> l | IP 5-tuple [Source IP, Destination IP, Source Port, Destination Port, Protocol] flow-based prepaid accounting using ECSv2 rulebase configuration for WiMAX ASN-GW and HA calls.

> l | Hotlining support for the IP 5-tuple flow-based prepaid calls.

> l | Hotlining support for postpaid sessions on WiMAX HA and ASN-GW. A session can be hotlined either at the beginning or middle of the session.

> Location Based Services Support
> For reporting BS-ID based on event triggers such as handover, idle mode entry and exit only
> The following changes were done to implement this functionality:

> l | Idle Mode Entry – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as "Idle".

> l | Idle Mode Exit – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as "Not Idle".

> l | Location Update – If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as "Location-Update".

> l | Handoff –If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as "Active-Handoff".

> l | Interim when the call is Idle – During the Idle-Mode Entry, the Interim will not be sent until the Idle-Mode Exit or Location Update.

> MPLS VRF Support
> MPLS VRF Support for ASNGW service has been implemented.
> Content Filtering Features in Release 12.0
> None for this release.
> ECS Features in Release 12.0
> None for this release.
> ESS Features in Release 12.0
> None for this release.
> Firewall Features in Release 12.0
> This section provides information on new Stateful Firewall features in Release 12.0.
> IPv6 and ICMPv6 Firewall Support
> This release provides support for IPv6 and ICMPv6 Firewall. IPv6 Firewall supports the following features:

> l | Enabling/Disabling IPv6 Firewall: The configuration can be used to enable or disable IPv6 Firewall for subscribers. IPv4 and IPv6 Firewall can be enabled or disabled separately.

> l | IPv6 Header checks: Firewall performs the following header checks to ensure the integrity of an IPv6 packet. IPv6 packets with unknown extension headers will not be dropped by Firewall; such packets will be allowed by Firewall.

> l | Limiting extension headers

> l | Hop-by-hop Options filtering: The Hop-by-Hop options will be parsed only if any of the Hop-by-Hop dos protections is enabled.

> l | Destination Options filtering

> l | Router Header filtering

> l | Fragment Header filtering

> l | IPv6 Host Pool: Host pools are enhanced to support IPv6 addresses and address ranges.

> l | IPv6 Rule-match: Stateful Firewall access ruledefs are enhanced to support IPv6 addresses and other parameters like IP version and ICMPv6 protocol.

> l | IPv6 Recovery: Stateful Firewall supports IPv6 flow recovery similar to IPv4 flows with the existing flow-recovery CLI being applicable to IPv6 flows also.

> l | ALG support: Firewall supports IPv6 traffic for ALGs - FTP, RTSP, PPTP, and TFTP.

> l | Existing DOS protection features enabled for IPv6.

> l | Malformity check enhanced for IPv6.

> l | TCP Stateful processing enhanced for IPv6 packets.

> For more information, please refer the Personal Stateful Firewall Administration Guide and CLI Reference Guide.
> FNG Features in Release 12.0
> The Femto Network Gateway is a new product in Release 12.0.
> For information about the Femto Network Gateway, see the Femto Network Gateway Administration Guide.
> GGSN Features in Release 12.0
> This section provides information on new GGSN features in Release 12.0.
> QoS Parameter ARP Setting via Gx Interface
> GGSN controls the assignment of different radio interface QoS priorities (gold/silver/bronze) via the PCRF Gx interface during PDP context setup (CCR/CCA-I). This is performed using the Allocation Retention Priority (ARP) parameter (AVP code 1034) as specified in 3GPP TS 29.212, with values = 0-3; ARP values from the PCRF other than 0-3 are ignored. During PDP context setup the PCRF returns the ARP value in CCA-I and this ARP is then assigned/negotiated with the SGSN and RNC.
> HA Features in Release 12.0
> HNB-Gateway Features in Release 12.1
> This section provides information on new features supported on HNB-Gateway (HNB-GW) in Release 12.1.
> Multiple MSC Selection without Iu-Flex
> In this release multiple MSC selection without Iu-Flex functionality for HNB-GW service is supported.
> Support for multiple MSC selection in a CS core network is provided with this feature support.
> HNBGW can connect to multiple MSC and SGSN through Iu-Flex or LAC mapping. This feature implements the multiple MSC selection using LAC.
> For this support the HNB-GW uses HNB's LAC, received during registration procedure in HNB_REGISTER_REQUEST message, to distribute RANAP-Initial UE message to an MSC. It maps the LAC with MSC point code and a set of LACs configured for each MSC, connected to the HNB-GW.
> In the HNBGW, to select an MSC based on the LAC the following algorithm is used:

> l | If both Iu-Flex and LACs are configured for a MSC, then Iu-Flex is used to select a MSC.

> l | If only Iu-Flex is configured then Iu-Flex is used for selecting MSC.

> l | If only LACs are configured then MSC is selected using LAC from HNB.

> l | If both Iu-Flex and LACs are not configured in the HNBGW, it selects default MSC.

> For more information on HNB-GW, refer the 3G Home NodeB Gateway Administration Guide.
> HSGW Features in Release 12.0
> None for this release.
> IP Services Gateway Features in Release 12.0
> This section provides information on new IP Services Gateway (IPSG) features in Release 12.0. For more information on IPSG, refer the IP Services Gateway Administration Guide.
> Volume Reporting over Gx
> In this release, IPSG supports the Volume Reporting over Gx feature.
> Mobility Management Entity Features in Release 12.0
> This section provides information on new Mobility Management Entity (MME) features in Release 12.0.
> Handover Support for Release 8 SGSNs
> The S3 interface facilitates user mobility between an MME and a Release 8 SGSN providing for the transfer of the UE context between the MME and the SGSN.
> Circuit Switched Fall Back - Voice Support Over SGs
> Circuit Switched Fall Back enables a UE to camp on an E-UTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain.
> IKEv2 IP Security Support on S1-MME
> IP Security (IPSec) on the S1-MME interface is a node-to-node IKEv2 tunnel that can be configured to assume the characteristics of either a pre-configured tunnel or a dynamic tunnel.
> Pre-configured node tunnels are fully qualified IPSec tunnels. Each IPSec tunnel is configured with parameters including pre-shared key, local and remote IP addresses, crypto hashes, groups, algorithms and the access control list (ACL).
> Node-to-node dynamic tunnels are generated dynamically as the connections are initiated by different nodes in the LTE network. Each IPSec tunnel does not need to be pre-configured for each required parameter, instead it uses a common template for some parameters, like crypto algorithms, hashes, and groups. Other parameters are fetched dynamically from the tunnel requests like IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
> Typically, the eNodeB initiates an IPSec tunnel to the MME. The MME service is responsible to verify the configuration and use an IPSec API to make the MME listen on the service address for IKE requests.
> The S1-MME Interface carries SCTP signaling traffic that flows through an IPSec tunnel if it is configured. When a UE needs to connect to the Internet, it initiates a connection to an eNodeB which then tunnels its traffic to an MME using an SCTP connection. Any further UEs using the same eNodeB to communicate to the same MME will subsequently use the same SCTP and hence the same IPSec Tunnel according to the LTE standard.
> S6a Multi-Homing
> The MME service supports up to four SCTP bind end point IPv4 or IPv6 addresses for the S6a interface.
> PSC3 Hardware Support
> The MME service supports the use of the Packet Service Card 3 in this release.
> Dynamic Discovery of HSS Realm
> The MME now supports behavior that allows the peer realm of the HSS to be determined by the MCC and MNC in the subscriber’s IMSI. Prior behavior was that the HSS must be statically configured in the MME.
> Lawful Intercept
> TCP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
> MUR Features in Release 12.0
> DSL Reports
> The current release of MUR provides the following details for DSL reports:

> l | Traffic analysis — uplink DSL, downlink DSL and total DSL traffic including daily weekly, and monthly aggregation/distribution.

> l | DSL traffic categorization — total P2P traffic over DSL, IP traffic, web traffic, etc.

> l | Top N% DSL subscribers.

> l | Comparison of total DSL traffic versus total UMTS traffic.

> IMPORTANT: The DSL reports can be generated only when DSL is configured as an APN group during MUR software installation/upgrade.
> Except the TopN% DSL subscribers, all other DSL reports can be viewed under the DPI tab by selecting appropriate dimensional filters.
> IMPORTANT: The discrimination between DSL and UMTS traffic will be based on the APN Name attribute in the EDR file.
> Enabling PUSH model for MUR Reporting
> In the earlier releases, L-ESS was used to pull the EDRs from the chassis for reporting purpose.
> Release 12.0 onwards, for all new deployments of MUR that use either Sun Netra X4270 or UCS C460 M2 server and run Red Hat Linux, L-ESS is NOT required as the ASR 5K EDR module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR 5K is the Cisco recommended deployment model. Currently, L-ESS is supported only on Solaris platforms. Existing deployments where L-ESS is installed, to pull EDRs from ASR 5K, may continue with their deployment model in the 12.0 version of MUR Software Release and later.
> Exporting Reports in CSV Format
> MUR has the capability of exporting reports in Comma Separated Value (CSV) format in addition to PDF and Excel formats. This can be accomplished through the GUI by clicking the csv icon available in the tabular representation of all the reports in the HOME and DPI tabs.
> Extended Support for Multiple BS Counter/Index Selections
> From Release 12.0 onwards, MUR no longer supports the limitation of selecting only 15 bulkstats counters/indices at a time. Now, there is no defined limit as such; users are allowed to select any number of counters and indices simultaneously.
> Charts will not be displayed if more than 15 indexes or 4 counters are selected. However, the data will be displayed in the Table tab of the BS/KPI reporting page.
> HTTP User Agent Reports
> MUR generates HTTP User Agent (UA) reports and/or UA group reports that are primarily used for ASR 5000 based Modem tethering detection.
> In this release, MUR supports the following reports:

> l | Daily/weekly/monthly TopN User Agent Group report

> l | Daily/weekly/monthly TopN individual User Agent Group report - per APN

> l | Daily/weekly/monthly TopN individual User Agent Group report - per TAC

> l | Daily/weekly/monthly TopN individual User Agent report

> l | Daily/weekly/monthly TopN individual User Agent report - per APN

> l | Daily/weekly/monthly TopN individual User Agent report - per TAC

> The MUR solution also provides a utility to export Top N User-Agent list to a text file based on the given level of tethered traffic. This text file contains pre-formatted CLI file with the configured ruledefs and group-of-ruledefs that need to be applied to the ASR 5K system.
> IMPORTANT: Currently, MUR does not support UA report generation for historical data as the data tables does not contain User Agent, APN, and TAC. Also, note that any changes made to the APN/TAC/UA group configurations will not be applied to the old data.
> Modifying Mandatory EDR Settings
> The reporting EDR file contains multiple attribute fields like sn-start-time and sn-end-time; some of them are considered mandatory depending on the gateway and reporting types.
> Currently, MUR mandates sn-start-time and sn-end-time fields in the flow EDR. If the EDR contains the fields sn-flow-start-time and sn-flow-end-time then MUR will pick values from these fields. However, the sn-flow-start-time and sn-flow-end-time fields are not mandatory.
> In a particular deployment, if the EDR receives only sn-flow-start-time and sn-flow-end-time fields, then the mandatory settings for sn-start-time and sn-end-time should be disabled through the System menu on the GUI.
> MUR User Administrative Limitations
> In the current release, the following limitations were imposed with respect to user permissions and privileges:

> l | All MUR administrators have access to USERS and GROUPS menu in the Admin tab available on the MUR GUI.

> l | Administrator with admin user name will have the rights to modify and delete all the MUR users’ accounts. Only users with admin user name can modify its own password. Only admin user will be able to delete any administrator or operator user accounts.

> l | Administrator other than users with admin user name will have rights to delete the MUR users except admin user and modify user accounts except their passwords.

> l | After modifying user role from Administrator to Operator and vice-versa, the user should alter the configuration on the GUI to lock/unlock the user account accordingly.

> MUR with Support for UCS/RHEL 5.5
> In this release, a custom Red Hat Enterprise Linux OS (Cisco MITG RHEL v5.5) has been introduced to support MUR running on the Cisco UCS platforms.
> Release 12.0 onwards, MUR recommends using UCS C460 M2 server running MITG Customized RHEL 5.5. For information on the complete hardware recommendations and file system supported, refer to the Mobility Unified Reporting System Overview chapter in the Cisco Mobility Unified Reporting System Installation and Administration Guide. For the OS installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
> IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
> Scheduling Offline BS/KPI Reports
> On selecting multiple counters/indices or a huge data range on the Bulkstats and KPI reporting pages, the MUR server may experience some delay in fetching the report information. If the time taken for this activity is beyond the expected threshold, then these tasks are automatically scheduled to be reported offline at a later period.
> An automated offline script at the server side runs every 1 minute to check if the requested report information is available. When it is ready, the server makes it available on Background Task Manager tab present on the GUI. These offline reports are generated in Excel format and provided to users as a zip file.
> Search Facility for BS Counters
> The current release of MUR allows users to search the bulkstats (BS) counters using the Counters text box newly added in the Bulkstats reporting page, and also find the CLI-equivalent counter names by selecting by CLI Name check box.
> With the auto-complete feature available in the Counter text box, you can just key in a few characters and search the counters easily.
> Support for Configuring Multiple SGSN Groups
> MUR users have been provided the flexibility to configure multiple SGSN IP addresses under one SGSN group using “ *”. The SGSN group configuration can be performed on the GUI through System > Reports > SGSN groups menu.
> Users can now add explicit IP address expressions similar to the example shown here:
> 10.4.1.*
> 1*.4.1.74
> 10.4.*.74
> *.1.*.74
> 10.4.1.7*
> 10.4.1.*4
> etc.
> Support for Enabling KPI Parser
> MUR architecture is redesigned so that KPI parser and Bulkstats (BS) parser does not coexist and they function independently from release 12.0 onwards.
> The KPI parser now calculates only the values of KPIs for which the alarms are configured through the GUI. This parser uses the information stored by BS parser in the database (DB) for KPI calculations and for sending alarms. This avoids reparsing of the same file and redundant connections to the DB.
> KPI parser generates alarms only when the alarm functionality is enabled through the SNMP Configurations option available on the GUI under the System menu.
> MVG Features in Release 12.0
> The Mobile Video Gateway is a new product in Release 12.0.
> None for this release.
> NAT Features in Release 12.0
> This section provides information on new Network Address Translation (NAT) features in Release 12.0.
> Support for H323 ALG
> This release provides support for H323 ALG that is designed to traverse NAT by inspecting and altering information contained in existing H323 messages as they pass through the NAT. It can alter address and port information in registration, call signaling and automatically opening pinholes in the NAT to allow media flow.
> H323 ALG performs the following functions:

> l | Communicates with the core for binding management

> l | Uses H323 stack for parsing and encoding the H323 messages

> l | Communicates with NAT for signaling messages

> l | Performs protocol specific processing if required

> Supplementary Services
> The following supplementary services are currently supported in H323 ALG:

> l | Call Transfer: The Call Transfer supplementary service enables the served user (User A) to transform an existing call with a User B (primary call) into a new call between current User B and a new User C (transferred-to user) selected by served user A.

> l | Call Hold: The Call Hold supplementary service allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e. retrieve) communications with the held user.

> l | Call Diversion: Call Diversion supplementary service permits a served user to have incoming calls addressed to the served user's number redirected to another number; on busy service, it enables a served user to have calls redirected to another endpoint; on No Answer, it enables a served user to have calls addressed to the served endpoint's number and redirected to another endpoint if the connection is not established within a defined period of time.

> l | Call Waiting: The Call Waiting supplementary service permits a busy user to be informed of an incoming call while being engaged with one or more other calls.

> l | Call Offering: The Call Offering supplementary service on request from the calling user, enables a call to be offered to a busy user and to wait for that called user to accept the call, after the necessary resources have become available.

> NAT Aware H323 Clients
> An application layer gateway, at the Firewall/NAT, examines all the H323 packets and modifies the packet such that all the private addresses are replaced by public addresses. It also opens all the pinholes required for successful call establishment. A NAT aware endpoint establishes end-to-end media session through FW/NAT without the need of ALG. Any TCP connection or UDP packet sent from the internal network through the firewall opens a pinhole dynamically in the firewall. This pinhole allows incoming messages to be sent from the destination of the TCP connection or the UDP packet. The pinhole stays open as long as the network sends information through the pinhole to the same destination.
> If an end point supports NAT traversal, H323 ALG disables itself so that end point directly opens required pinhole and establishes media path between them. The ALG will not manage any pinhole for media traversal across Firewall/NAT for NAT aware clients. By default, the ALG will bypass all the clients that support H460.18/19 and H460.23/24.
> PDG/TTG Features in Release 12.0
> This section provides information on new PDG/TTG features in Release 12.0.
> Lawful Intercept
> TCP Proxy support is now available for Lawful Intercept on the PDG/TTG. Contact your local sales representative for detailed information.
> PDIF Features in Release 12.0
> None for this release.
> PDSN Features in Release 12.0
> None for this release.
> P-GW Features in Release 12.0
> This section provides information on new Packet Data Network Gateway (P-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Packet Data Network Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
> Direct Tunnel Support
> When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality.
> EPC Combination Gateway Supports LTE requirements
> The SGSN/GGSN, when co-residing with the S-GW/P-GW, supports all product-level requirements of the S-GW/P-GW for availability, performance, capacity, security, and O+M.
> EPC Gateways Support for eHRPD Non-optimized Handoffs
> This functionality has been implemented.
> Generic APN Based on Routing Mechanism – IPSec Connection Method
> This functionality has been implemented.
> Gn/Gp Handover Behavior Change
> In case of P-GW with GnGp access, after a P-GW mode to GGSN mode handover, SGSN_CHANGE(0) Event trigger and 3GPP-SGSN-Address needs to be sent. The system shall send AN_GW_CHANGE (21) Event-Trigger and IPv4 SGSN address in the AN-GW-Address AVP. This is because SGSN-Address would not have been valid in the case of P-GW with S5/S8 and, hence, SGSN_CHANGE(0) would not be meaningful after a P-GW mode to GGSN mode handover.
> GRE Protocol Interface Support
> The P-GW supports GRE generic tunnel interfaces in accordance with RFC-2784, Generic Routing Encapsulation (GRE). The GRE protocol allows mobile users to connect to their enterprise networks through GRE tunnels.
> 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 differentiation.
> 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:

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

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

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

> IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.
> GTP-U Data Forwarding Changes for IPSec
> Sessmgrs are now informed of IPSec tunnels to peers.
> GTP-U IPSec Peer Updates to sessmgr
> gtpumgr now receives IPSec tunnel notifications from IPSec. gtpumgr now updates all sessmgrs with NPU flow information for the tunnel that is received from IPSec.
> gtpumgr also notifies all sessmgrs of peer info. so that when any bearer setups for that peer, corresponding IPSec tunnel info. is used for data forwarding.
> GTP-U IPSec Tunnel Create and Status Handling
> If IPSec is enabled and a new peer is detected, a new IPSec tunnel is now initiated.
> GTP-U Echoes Sent through IPSec Tunnel for a Peer Once the IPSec Tunnel to the Peer is Set Up
> This functionality has been implemented.
> Gtpumgr Restart Handling
> With IPSec tunnels, if gtpumgr restarts, the IPSec tunnel info is now synced up with the IPSec subsystem and sessmgr.
> Gy: Added CHANGE_IN_SERVING_NODE Trigger Type
> CHANGE_IN_SERVING_NODE trigger is an extension to the CHANGE_IN_SGSN trigger. However, for the purpose of backward compatibility, both triggers are retained. The P-GW sends them in the following manner.

> l | If OCS does not provide any trigger:

> l | SERVING_NODE AND SGSN is configured on the CLI, system sends SERVING_NODE_CHANGE.

> l | If one of them is configured, that one will be sent.

> l | If OCS provides SERVING_NODE and SGSN, then CHANGE_IN_SERVING_NODE would be sent.

> l | If OCS provides:

> l | SGSN alone (older OCS), then the current behavior of sending CHANGE_IN_SGSN_IP_ADDRESS trigger is retained.

> l | SERVING_NODE alone (newer OCS), then the new trigger CHANGE_IN_SERVING_NODE would be sent.

> Gy: [GTP] Support for Generating SERVING_ NODE_CHANGE Trigger
> This functionality has been implemented.
> Gy: [PMIP] Support for Generating SERVING_ NODE_CHANGE Trigger
> This functionality has been implemented.
> ICSR Checkpointing
> MSCC (quota) checkpointing is now handled as part of normal session recovery. MSCC checkpointing occurs randomly (~ 1-2 times within every 60 seconds) on every MSCC update. The MSCC checkpoint will be sent to the peer chassis only if there is a change in MSCC information.
> IPSec Tunnel Deletion for a Peer If No Bearers are Present for That Peer
> IPSec tunnels are now deleted for a peer if no bearers are present for that peer.
> Local QoS Policy
> Local QoS policies can be used to control different aspects of a session, such as QoS, Data Usage, Subscription profiles, or Server Usage, by means of locally defined policies.
> Local QoS policies are triggered when certain events occur and the associated conditions are satisfied. For example, when a new call is initiated, the QoS to be applied for the call could be decided based on the IMSI, MSISDN, and APN.
> IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.
> LTE IPSec Scaling Support
> This functionality has been implemented.
> LTE IPSec Single Tunnel Set Up for Both Initiator and Responder
> S-GW acts as Initiator and Responder toward eNodeB.
> Toward P-GW, there is collision scenario when S-GW and P-GW both initiate a tunnel at the same time; however, one of them will terminate.
> NEMO Service Supported
> The P-GW may be configured to enable or disable Network Mobility (NEMO) service.
> When enabled through a feature license key, the system includes NEMO support for a Mobile IPv4 Network Mobility (NEMO-HA) on the P-GW platform to terminate Mobile IPv4 based NEMO connections from Mobile Routers (MRs) that attach to an Enterprise PDN. The NEMO functionality allows bi-directional communication that is application-agnostic between users behind the MR and users or resources on Fixed Network sites.
> The same NEMO4G-HA service and its bound Loopback IP address supports NEMO connections whose underlying PDN connection comes through GTP S5 (4G access) or PMIPv6 S2a (eHRPD access).
> IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.
> On sessmgr Restart/Start, GTP-U Peer Info Fetched from gtpumgr
> This functionality has been implemented.
> P-GW Supports Average Throughput Per Active User of 10 Kbps on Uplink and 50 Kbps on Downlink
> The P-GW service now supports average throughput per active user of 10 Kbps on uplink and 50 Kbps on downlink.
> P-GW Supports DHCP Relay Over SGi Per-APN IPSec Tunnel
> The P-GW service now supports DHCP relay over SGi per-APN IPSec tunnel.
> P-GW Supports Throughput Per Active Video Streaming User Device of 256Kbps on Uplink and 1Mbps on Downlink.
> The P-GW service now supports throughput per active video streaming user device of 256Kbps on uplink and 1Mbps on downlink.
> PSC3 Hardware Support
> The P-GW service supports the use of the Packet Service Card 3 in this release.
> QCI Range Changed
> Previously, for Default-EPS-Bearer QoS, IMSA validation for QCI ranges 1-9 and 128-254 were considered valid (as per spec).
> Now, the valid QCI range has been changed to 1-32 to align with the CLI configurable range.
> S-GW and P-GW Support Secure User Plane Interfaces Using IPSec
> IKEv2 has been implemented for Node-to-Node IPSec Tunnels in the LTE network for GTP-U traffic.
> The IPSec implementation for LTE is only node-to-node. Any IPSec tunnel will handle multiple subscriber GTPU traffic. The IPSec tunnel is generated dynamically as the connection is initiated by nodes in the LTE network. Each IPSec tunnel uses a common template for parameters, such as crypto algorithms, hashes, groups, etc. Other parameters are fetched dynamically from the tunnel requests, such as IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
> For LTE nodes, IPSec tunnels can be setup for control and data traffic carried over S1-MME, S1-U, S11, and S5.
> SNMP Notification on Configuration Change
> The configuration monitor utility will perform a show configuration command every 15 minutes and compare the subsequent output to determine whether the information has changed. The configuration is defined as having changed when the current configuration differs from the previous snapshot. If a configuration change is indicated, then an SNMP trap is sent.
> Support for Event Trigger UE_IP_ADDRESS_ ALLOCATE and UE_IP_ADDRESS_RELEASE
> Added support for displaying event-masks and statistics for Event-Triggers UE-IP-Address-Allocate and UE-IP-Address-Release.
> SCM Features in Release 12.0
> This section provides information on new Session Control Manager (SCM) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Session Control Manager Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
> Advanced Congestion Control in CSCF Socket Layer
> CSCF performs congestion control based on the memory usage inside every sessmgr at two levels.
> Level 1: For every new call/event received, the system checks if sessmgr memory-usage is above a threshold value (such as 95 percent). If it is, memory-congestion is triggered and new call messages are rejected with 500 SIP response. Memory congestion is disabled when memory usage drops by a tolerance value (default is 10 percent). This functionality has not been tested.
> Level 2: If the sessmgr usage reaches 100 percent, all newly received SIP messages are dropped at the socket layer in that sessmgr except for the BYE message. The new SIP messages are not processed until the memory reaches the threshold value (95 percent).
> A trap is also generated whenever sessmgr is in congestion state.
> Bridge Mode: CSCF Session and Performance Counters Incremented for VoIP Calls.
> When P-CSCF acts in a bridging mode between two services, the show cscf session counters calls <filter criteria> name <service_name> command now displays separate counters for access and core P-CSCF.
> Cscfmgr Does Not Drop Register Requests for which Retries Exceeded When Congestion is Turned On in sessmgr
> When cscfmgr (demuxmgr) receives REGISTER request from Network, it fetches a suitable sessmgr for processing REGISTER. If that sessmgr rejects the REGISTER since it is overloaded, cscfmgr will retry another sessmgr. If the system is congested, cscfmgr will retry three times to find a sessmgr. If it fails, then cscfmgr will reject the request with a “503 service unavailable” error response with Retry-after header.
> CSCF Recovers All IMPUs Registered from Same Contact
> CSCF now recovers all IMPUs registered from same contact.
> CSCF Supports application/vnd.etsi.aoc+xml MIME Type
> CSCF now supports application/vnd.etsi.aoc+xml MIME type as per spec TS 24.647 and proxies the message without parsing the message body.
> CSCF Supports drop/reject/redirect Actions on Exceeding License Limits
> The SCM now supports redirection on overload (exceeding session/license limit). Overload conditions arise when the maximum session limit per sessmgr is reached or the license is exceeded.
> When the CSCF becomes overloaded, an overload policy can be configured to handle it. When the overload condition is hit, the new registrations (SIP REGISTER messages) reaching the cscfmgr are dropped/rejected/redirected based on the configuration.
> CSCF Supports Multimedia Priority Service as per 3GPP TS 22.153
> CSCF now supports multimedia priority service, as per 3GPP TS 22.153.
> CSCF Supports “Retry-After” Header in 500 Response During Congestion
> When CSCF identifies congestion, it originates UMM_RESPONSE with response code set as 500. Sipapp while forming the response SIP_IPS fills the Retry-after header with a random value between 0 to 10 seconds as per RFC 3261.
> CSCF Supports RFC 5621 Message Body Handling in the Session Initiation Protocol (SIP)
> CSCF has supported “multipart/mixed” message body parsing. It now also supports “multipart/alternative” and “multipart/related” message body parsing.
> DSCP Marking
> Provides support for more granular configuration of DSCP marking.
> For Interactive Traffic class, the P-CSCF/A-BG supports per-service configurable DSCP marking for Uplink and Downlink direction based on Allocation/Retention Priority in addition to the current priorities.
> I-CSCF Supports the Ma Reference Point for Interfacing to AS to Support Public Service Identity (PSI) Procedures
> I-CSCF, upon receiving the terminating request, checks the subdomain-route list for matches. If a match is found the routing will happen based on it. Otherwise, I-CSCF will do a User Location Query (Location-Information-Request) and proceed normally.
> P-CSCF Determines the Type of Authentication Based on the Rules in Annex P.3, 33.203 (860)
> This functionality has been implemented, with the exception that NBA is not supported.
> P-CSCF Provides Outbound Support with IPSec
> P-CSCF now provides Outbound support with IPSec.
> P-CSCF Rejects Emergency Calls Based on Local-policy/UE-location-network/SDP
> P-CSCF will reject an emergency-call with 380 response based on the following local-policies (only if user is not emergency-registered):

> l | User is unregistered and makes an emergency-call (existing-option).

> l | User is non-emergency-registered and makes an emergency-call (existing-option).

> l | User is a visited-ue and makes an emergency-call. Here, visited-ue is determined based on matching of PANI in INVITE with MCC/MNC configured (new-option).

> l | User includes SDP with CS-Media in the INVITE of an emergency-call (new-option).

> P-CSCF will reject an emergency-registration based on the following local-policies (new-options):

> l | Reject any new emergency-registration.

> l | Reject emergency-registration from a visited-ue. visited-ue is determined based on the existing functionality of PANI/default-aor-domain match.

> P-CSCF Support for IPv6 with IPSec
> Platform support for IPSec on IPv6 is available only on PSC2.
> P-CSCF Support for Rx- 3gpp 29.214 v8.9.1
> The following functions have been implemented in accordance with 3GPP 29.214 v8.8.0:

> l | Supported Features AVP:(Sec 5.6) is removed from RAR, RAA, ASR and ASA messages

> l | Supported Features AVP bit definitions have been modified (Sec 5.4.1)

> l | Flag definitions for Rx-reused AVPS have been changed (Sec 5.4)

> l | RAT change notification is now done along with IPCAN change notification (Sec 5.3.13,Sec 4.4.6.4)

> l | Specific Action AVP -CHARGING_ CORRELATION_EXCHANGE is now used for correlation exchange. Previously it was made obsolete.(Sec 4.4.6.5)

> l | STR send only after receiving AAA (Sec 4.4.4)

> P-CSCF Supports Bridging and NAT functionality together
> Added support for UEs from behind NAT in bridging setup.
> P-CSCF Supports Interworking Between IPv4 UEs and an IPv6 IMS Core Network
> P-CSCF now provides IPv4-IPv6 interworking functionality between IPv4-only UEs and IPv6-only core network elements (I/S-CSCF) by acting as dual-stack.
> To achieve the dual-stack behavior, P-CSCF is configured in two services. The first service (V6-SVC) listens on an IPv6 address. The second service (V4-SVC) listens on an IPv4 address. SIP messages coming from IPv4 UEs will come to V4-SVC and be forwarded to the IPv6 core network through V6-SVC. Similarly, messages from IPv6 core network that come to V6-SVC can be forwarded to IPv4 UEs via V4-SVC.
> P-CSCF Supports New IP-CANs
> P-CSCF supports new IP-CANs, as per section 7.2A.5 of 24.229 (880).
> P-CSCF Supports Special Handling for “Text” Media Type for Rx Interface
> To meet regulatory requirements that deaf/hearing impaired people must be able to perform text-based communication to other users and government offices, the P-CSCF now supports Global Text Telephony.
> Media type is set as “text” during media authorization with PCRF.
> Global Text Telephony/Teletype messages must use ITU-T Recommendation T.140 for real-time text according to the rules and procedures specified in 3GPP TS 26.114 with the following clarifications:

> l | The UE must offer AVP for all media streams containing real-time text.

> l | For real-time text, RTCP reporting is turned off by setting the SDP bandwidth modifiers “RS” and “RR” to zero.

> l | Redundant transmission of real-time text characters is not to be used.

> l | The sampling time used is 300 ms.

> PSC3 Hardware Support
> The SCM supports the use of the Packet Service Card 3 in this release.
> S-CSCF: Implemented an Internal Session-timer in B2BUA Mode
> S-CSCF now runs a session timer in B2BUA mode for default of 1 hour.
> S-CSCF Supports P-Served-User for SUBSCRIBE Requests
> S-CSCF now supports P-Served-User for SUBSCRIBE requests.
> Sequential Forking Functionality Working in B2BUA Mode
> For a forking proxy server, the type of directive indicates whether the caller would like the proxy server to proxy the request to all known addresses at once (parallel), or go through them sequentially (serial) by contacting the next address only after it has received a non-2xx or non-6xx final response for the previous one.
> Session Priority Support in Diameter RF interface
> The Session-Priority AVP is now sent in Rf charging messages based on the SIP Resource-Priority header.
> TLS Support in P-CSCF
> Transport Layer Security (TLS) provides confidentiality and integrity protection for SIP signaling messages between the UE and P-CSCF/A-BG. TLS is a layered protocol that runs upon reliable transport protocols like TCP and SCTP.
> The SCM supports the following two scenarios:

> l | TLS as a transport between UE and P-CSCF/A-BG, as per RFC 3261

> l | Use of TLS by Security Mechanism agreement between UE and P-CSCF/A-BG, as per RC 3329 and TS 33.203

> Serving Gateway Features in Release 12.0
> This section provides information on new Serving Gateway (S-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Serving Gateway Administration Guide.
> Operator Policy
> The operator policy provides mechanisms to fine tune the behavior of subsets of subscribers above and beyond the behaviors described in the user profile. It also can be used to control the behavior of visiting subscribers in roaming scenarios, enforcing roaming agreements and providing a measure of local protection against foreign subscribers.
> Circuit Switched Fallback Support
> Circuit Switched Fall Back (CSFB) enables the UE to camp on an EUTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain or other CS-domain services (e.g., Location Services (LCS) or supplementary services). Additionally, SMS delivery via the CS core network is realized without CSFB. Since LTE EPC networks were not meant to directly anchor CS connections, when any CS voice services are initiated, any PS based data activities on the EUTRAN network will be temporarily suspended (either the data transfer is suspended or the packet switched connection is handed over to the 2G/3G network).
> While the primary responsibility of supporting CSFB fall to the MME, the S-GW supports CSFB messaging over the S11 interface.
> SGSN Features in Release 12.0
> This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.0. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
> Max Number of LACs Configurable for Gs Service Increased
> The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
> Max Number of LACs / Zone Code List - Behavioral Change
> Maximum number of LACs per allowed zone code list has increased from 10 to 100.
> 3GPP 23.008 Regional Subscription Information (RSZI)
> The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
> 3G NRPCA
> The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. 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.
> APN Handling / Default APN - Enhanced
> For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
> Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
> APN Override Enhancements
> The SGSN now provides the ability to configure default APN to be used in several different scenarios:
> • Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
> • Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
> • Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
> APN resolution with SCHAR and Optionally RNC-ID
> It is now possible to append subscriber charging characteristic (SCHAR) 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 (per this enhancement) 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_op erator_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.
> APN Selection for Nearest GGSN
> With this feature the operator can include the RNC_ID information with the name of the APN before the query is sent to the DNS. This feature makes it possible to select a GGSN based on the RNC_ID. Name format example: <apn_name>.<rnc_id>.<mncxxx>.<mccyyy>.gprs
> With the RNC_ID inclusion enabled, the operator can also include the SCHAR (charging characteristic information) so that both the SCHAR and the RNC_ID information would be added to the name of the APN before the query is sent to the DNS. Name format example: <apn_name>.<rnc_id>.<schar>.<mncxxx>.<mccyyy>.gprs.
> Avoiding PDP Context Deactivations - Behavioral Change
> Default behavior has been changed to avoid PDP context deactivations resulting from GTP-C path failure detection due to messages containing erroneous restart counter change values.
> Previous Behavior: The old default behavior was to have the SGSN 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 begin PDP deactivation with a reactivation message. If the values in the messages are spurious, then this behavior could result in undesirable increases in network traffic due to bursts of deactivations/activations.
> New Behavior: The new default behavior has the SGSN receive a restart counter change value and then the SGSN 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 SGSN begin deactivation of PDP contexts.
> Ciphering Algorithm Negotiation Failure - Actions Configurable - Behavioral Change
> Previously, if there was no match between the ciphering algorithm from the MS and the ciphering algorithm configured in either the call control profile or the GPRS service configuration, then the SGSN performed Attach or RAU without ciphering.
> Now, the SGSN can be configured to either:

> l | Allow the call without ciphering (geo0)

> l | Reject an incoming Attach / RAU when there is not a match between the MS and SGSN configured ciphering algorithms. The call Attach/RAU Rejection message can include a configurable GMM failure code.

> Controlling THP and ARP via Operator Policy
> The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
> This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
> custom33 Dictionary - New
> A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
> • Proprietary PLMN-ID field is present.
> • It is a SEQUENCE and not a SET.
> • Diagnostics and SGSN-Change fields are not supported.
> • Indefinite length encoding is used.
> • Booleans are encoded as 0x01(3GPP it is 0xff).
> • IMEISV shall be sent if available else IMEI should be sent.
> • Record Sequence Number is Mandatory.
> • APN OI and NI part is length encoded.
> • Cause for Record closure should be “RAT Change” instead of “intra-SGSN inter-system”.
> Disabling ARD Checking
> Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
> With this release, it is now possible to disable the default behavior (ARD checking).
> DSCP Marking for GTP-C Messages
> The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
> DSCP Template for Gb/IP
> New configuration commands were added to create or remove a DSCP template which provides configuration of DSCP values for both control packets and data packets of different classes for traffic on Gb over IP.
> The CLI commands which create or remove the DSCP templates are done at an SGSN-global level under the SGSN Global configuration mode; which also provides access to the new DSCP Template configuration mode.
> These templates are associated with any of the configured GPRS services which allows that service to apply the configured DSCP values for all downlink packets sent out from the SGSN. If there is no profile associated with the GPRS service, the SGSN uses the default “Best Effort” DSCP values for both control and data packets.
> Full Channelization Support for NB-SS7
> The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
> Gb/Iu Flex Offloading Enhancements - Behavioral Change
> Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
> The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
> Gn/Gp Delay Monitoring
> The SGSN can now measure 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.
> Horizontal Link Aggregation
> The SGSN now supports enhanced link aggregation (LAG) within ports on different side-by-side XGLCs. Ports can be from multiple XGLCs with some cards in L2 (side-by-side) redundancy.
> 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. With side-by-side redundancy on the XGLC, link aggregation supports horizontal ports from both XGLC cards.
> Incorrect APN Handling / Default APN - Enhanced - Behavioral Change
> For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
> Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
> Lawful Intercept Buffering, Phase 2
> The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, refer to the ASR 5000 Series Lawful Intercept Configuration Guide.
> Local DNS --- Behavioral Change
> 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. 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 multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
> The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
> Local Mapping of MBR
> The SGSN now 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. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
> NOTE: 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.
> Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
> Managing Path Failure Detection due to Restart Counter Change - Behavioral Change
> 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.
> When the SGSN detects GTP-C path failure between the SGSN and the GGSN, the SGSN now assumes PDP sessions at the GGSN are lost and the SGSN deactivates those PDP sessions towards the UE with an indication that the UE should activate the PDP session again. Detection is based on receipt of restart counter change values in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) which can be spurious. Potentially, this scenario can increase traffic within the operator’s network.
> Various enhancements have been made to manage the resulting service deactivations and activations which would cause needlessly large bursts of network traffic if the restart counter change messages from the GGSN are erroneous:

> l | New default behavior defined for handling GTP-C path failures detected as a result of erroneous restart counter changes received from the GGSN. See details in the Operator Notes.

> l | New command sets the variance allowed between values for received restart counter changes.

> l | New command sets the rate of PDP deactivations due to GTP-C path failures.

> l | New command disables the new default verification behavior.

> MTP2 Parameters - Behavioral Change
> Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for lowspeed:

> l | mtp2-eim-decrement

> l | mtp2-eim-increment

> l | mtp2-eim-threshold

> Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for highspeed:

> l | mtp2-aerm-emergency-threshold

> l | mtp2-aerm-normal-threshold

> l | mtp2-suerm-threshold

> In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for highspeed and AERM/SUERM parameters are only available when SS7 link is configured for lowspeed.
> Multiple Access 2G/3G/MME/S-GW - Limited Demo Only
> The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
> MTP2 T2 Timer - Enhanced Range for HSL
> The maximum limit for the high-speed link MTP2 T2 timer has been enhanced to 150 seconds.
> Nearest GGSN Selection on APN Resolution
> It is now possible to configure the SGSN to append LAC and RAC info to an APN DNS query for GGSN selection. It is expected that the DNS will use this information to determine the GGSN to route the APN.
> For example, roaming subscribers using a specific APN may want to be directed to the closest GGSN. This can be achieved by having an operator policy for roaming subscribers associated with an APN profile that includes a configuration specifying that geographical information from the LAC/RAC be appended to the APN. This is then used as the DNS query string but does not modify the APN string being sent to the GGSN.
> PSC3 Card Qualified for SGSN
> The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
> PSCA Supported
> The SGSN now supports the PSCA. No special configuration is required.
> P-TMSI Signature Reallocation - Behavioral Change
> Previously, the SGSN default behavior was to allocate the P-TMSI signature.
> The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
> The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
> You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
> qos class “all-values” - Behavioral Change
> The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
> Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
> New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
> RAI IE in CPCQ/UPCQ Configurable - Behavior Change
> RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:

> l | 3G new SGSN RAU (change in behavior)

> l | 3G primary and secondary PDP activation (change in

> behavior)

> l | 2G primary and secondary PDP activation (change in

> l | behavior)

> l | 2G new SGSN RAU

> l | 3G new SGSN SRNS

> l | 2G -> 3G HO (only if PLMN Id has changed)

> l | 3G -> 2G HO (only if PLMN Id has changed)

> l | Multiple IUPS service RAU (only if PLMN Id has

> l | changed)

> l | Multiple GPRS service RAU (only if PLMN Id has

> l | changed)

> Reordering of SNDCP N-PDU Segments - Behavioral Change
> In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
> Now, the SGSN fully supports reordering 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.
> S6d DIAMETER Interface Support - Limited Demo Only
> The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
> SCTP Timing Granularity Enhanced
> The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:

> l | Minimum SCTP Retransmission Timeout (sctp-rto-min)

> l | Selective ACK Period (sctp-sack-period)

> This can improve interoperability with certain RAN equipment.
> For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
> SMS Authentication Repetition Rate - Behavioral Change
> Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
> Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
> SMSC Address Denial - Behavioral Change
> 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.
> SONET APS and SDH MSP (1+1) Inter-Card Support on OLC2
> Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
> The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
> SGSN Features in Release 12.1
> This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.1. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
> Max Number of LACs Configurable for Gs Service Increased
> The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
> Max Number of LACs / Zone Code List - Behavioral Change
> Maximum number of LACs per allowed zone code list has increased from 10 to 100.
> 3GPP 23.008 Regional Subscription Information (RSZI)
> The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
> 3G NRPCA
> The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. 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.
> APN Handling / Default APN - Enhanced
> For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
> Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
> APN Override Enhancements
> The SGSN now provides the ability to configure default APN to be used in several different scenarios:
> • Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
> • Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
> • Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
> Controlling THP and ARP via Operator Policy
> The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
> This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
> custom33 Dictionary - New
> A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
> • Proprietary PLMN-ID field is present.
> • It is a SEQUENCE and not a SET.
> • Diagnostics and SGSN-Change fields are not supported.
> • Indefinite length encoding is used.
> • Booleans are encoded as 0x01(3GPP it is 0xff).
> • IMEISV shall be sent if available else IMEI should be sent.
> • Record Sequence Number is Mandatory.
> • APN OI and NI part is length encoded.
> • Cause for Record closure should be “RAT Change” instead of “intra-SGSN inter-system”.
> Disabling ARD Checking
> Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
> With this release, it is now possible to disable the default behavior (ARD checking).
> DSCP Marking for GTP-C Messages
> The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
> Full Channelization Support for NB-SS7
> The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
> Gb/Iu Flex Offloading Enhancements - Behavioral Change
> Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
> The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
> Gn/Gp Delay Monitoring
> The SGSN can now measure 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.
> Horizontal Link Aggregation
> The SGSN now supports enhanced link aggregation (LAG) within ports on different side-by-side XGLCs. Ports can be from multiple XGLCs with some cards in L2 (side-by-side) redundancy.
> 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. With side-by-side redundancy on the XGLC, link aggregation supports horizontal ports from both XGLC cards.
> Incorrect APN Handling / Default APN - Enhanced - Behavioral Change
> For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
> Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
> Lawful Intercept Buffering, Phase 2
> The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, refer to the ASR 5000 Series Lawful Intercept Configuration Guide.
> Local DNS --- Behavioral Change
> 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. 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 multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
> The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
> Local Mapping of MBR
> The SGSN now 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. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
> NOTE: 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.
> Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
> MTP2 Parameters - Behavioral Change
> Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for lowspeed:

> l | mtp2-eim-decrement

> l | mtp2-eim-increment

> l | mtp2-eim-threshold

> Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for highspeed:

> l | mtp2-aerm-emergency-threshold

> l | mtp2-aerm-normal-threshold

> l | mtp2-suerm-threshold

> In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for highspeed and AERM/SUERM parameters are only available when SS7 link is configured for lowspeed.
> Multiple Access 2G/3G/MME/S-GW - Limited Demo Only
> The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
> MTP2 T2 Timer - Enhanced Range for HSL
> The maximum limit for the high-speed link MTP2 T2 timer has been enhanced to 150 seconds.
> PSC3 Card Qualified for SGSN
> The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
> PSCA Supported
> The SGSN now supports the PSCA. No special configuration is required.
> P-TMSI Signature Reallocation - Behavioral Change
> Previously, the SGSN default behavior was to allocate the P-TMSI signature.
> The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
> The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
> You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
> qos class “all-values” - Behavioral Change
> The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
> Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
> New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
> RAI IE in CPCQ/UPCQ Configurable - Behavior Change
> RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:

> l | 3G new SGSN RAU (change in behavior)

> l | 3G primary and secondary PDP activation (change in

> behavior)

> l | 2G primary and secondary PDP activation (change in

> l | behavior)

> l | 2G new SGSN RAU

> l | 3G new SGSN SRNS

> l | 2G -> 3G HO (only if PLMN Id has changed)

> l | 3G -> 2G HO (only if PLMN Id has changed)

> l | Multiple IUPS service RAU (only if PLMN Id has

> l | changed)

> l | Multiple GPRS service RAU (only if PLMN Id has

> l | changed)

> Reordering of SNDCP N-PDU Segments - Behavioral Change
> In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
> Now, the SGSN fully supports reordering 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.
> S6d DIAMETER Interface Support - Limited Demo Only
> The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
> SCTP Timing Granularity Enhanced
> The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:

> l | Minimum SCTP Retransmission Timeout (sctp-rto-min)

> l | Selective ACK Period (sctp-sack-period)

> This can improve interoperability with certain RAN equipment.
> For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
> SMS Authentication Repetition Rate - Behavioral Change
> Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
> Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
> SMSC Address Denial - Behavioral Change
> 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.
> SONET APS and SDH MSP (1+1) Inter-Card Support on OLC2
> Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
> The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
> Web Element Manager Features in Release 12.0
> This section provides information for new features for the Web Element Manager (WEM) application in Release 12.0.
> Cisco MITG RHEL v5.5 OS Support for WEM
> The Web Element Manager is now supported on selected Cisco UCS servers running the custom Cisco MITG Red Hat Enterprise Linux (RHEL) v5.5 operating system (OS).
> For detailed hardware platform and hard disk drive partition requirements, refer to the Web Element Manager Overview chapter of the Cisco Web Element Manager Installation and Configuration Guide. For installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
> IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
> Redundant Server Support using Oracle Cluster Software
> Multiple WEM servers can now be configured as part of a High Availability failover cluster via the use of Oracle Cluster software. Refer to Appendix A in the Cisco Web Element Manager Installation and Administration Guide for detailed information.

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