> New Feature Summary
> This chapter identifies features and functionality added to or modified in Releases 12.0, 12.1, and 12.2.
> Topics covered in this chapter are:

> l | Related Documents

> l | Common Features in Release 12.0

> l | Common Features in Release 12.2

> l | ADC Features in Release 12.0

> l | ADC Features in Release 12.2

> l | ASN GW Features in Release 12.0

> l | ECS Features in Release 12.2

> l | ECS Features in Release 12.2

> l | Firewall Features in Release 12.0

> l | Firewall Features in Release 12.0

> l | GGSN Features in Release 12.0

> l | GGSN Features in Release 12.2

> l | HNB-Gateway Features in Release 12.1

> l | HNB-Gateway Features in Release 12.1

> l | HSGW Features in Release 12.2

> l | HSGW Features in Release 12.2

> l | InTracer Features in Release 12.2

> l | IP Services Gateway Features in Release 12.0

> l | Mobility Management Entity Features in Release 12.0

> l | Mobility Management Entity Features in Release 12.2

> l | MUR Features in Release 12.0

> l | MUR Features in Release 12.2

> l | MVG Features in Release 12.0

> l | NAT Features in Release 12.0

> l | NAT Features in Release 12.2

> l | PDG/TTG Features in Release 12.2

> l | PDSN Features in Release 12.2

> l | PDSN Features in Release 12.2

> l | P-GW Features in Release 12.0

> l | P-GW Features in Release 12.2

> l | Policy and Charging Control (PCC) Support in Release 12.1

> l | SCM Features in Release 12.0

> l | SCM Features in Release 12.2

> l | Serving Gateway Features in Release 12.0

> l | Serving Gateway Features in Release 12.2

> l | SGSN Features in Release 12.0

> l | SGSN Features in Release 12.1

> l | SGSN Features in Release 12.2

> l | Web Element Manager Features in Release 12.0

> l | Web Element Manager Features in Release 12.2

> 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 Command Line Interface Reference
> Cisco ASR 5000 Series Enhanced Charging Services 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 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 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 Installation Guide
> Cisco ASR 5000 Series Femto Network Gateway Administration Guide
> Cisco ASR 5000 Series 3G Home NodeB Gateway Administration Guide
> Cisco ASR 5000 Traffic Performance Optimization Administration Guide
> Cisco ASR 5000 Mobile Services Edge Gateway - 3G Administration Guide
> Cisco ASR 5000 Series Mobile Video 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 LTE Doc Set
> Cisco ASR 5000 Series PDSN Doc Set
> Cisco ASR 5000 Series UMTS Doc Set
> 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.
> Charging Rulebase Name Length in LOSDVs of eG-CDRs and P-GW-CDRs
> The maximum character length of Charging Rulebase Name field in LOSDVs of eG-CDRs and P-GW-CDRs is now configurable. This change is now available in 12.0 and later releases.
> In earlier releases, in case of Custom5 or Custom40 dictionaries, the rulebase name used to get trimmed to 16 characters. In other dictionaries the complete rulebase name used to appear in the LOSDVs.
> A new CLI command now enables to configure maximum length of the rulebase name between 1 through 63 characters. If configured as 0 (zero), the rulebase name is not trimmed. This new CLI command is available at the context and GTPP group levels.
> 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 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 Offline 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 Offline AVP in Gx CCR-I was sent based on the presence of “billing-action egcdr” OR “billing-action rf” configuration within the charging-action of the ECSv2 rulebase chosen for the Diameter Gx session.
> In the current release, the Offline AVP in Gx CCR-I is sent based on the mapping of the Charging-Characteristics-Profile (received in the GTPC Create-PDP-Context-Request) to the Offline AVP (the mapping is CLI configurable in the Policy Control Configuration mode).
> 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.
> Encoding of Supported-Features AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, when Supported-Features AVP was encoded for the following dictionaries, the Vendor-Id AVP under the grouped AVP Supported-Features was sent with “M” bit cleared.

> l | dpca-custom14

> l | dpca-custom2

> l | dpca-custom5

> l | dpca-custom4

> l | dpca-custom13

> l | dpca-custom12

> l | dpca-custom10

> In the current release, when the Supported-Features AVP is encoded for the above mentioned dictionaries, the Vendor-Id AVP under Supported-Features AVP is sent with “M” bit set.
> 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.
> Failure Result-Code 4010 - Behavioral Change
> This Diameter-related behavioral change is applicable to all products.
> In the earlier releases, on reception of transient failure result-code 4010 at message/root level by DCCA client, CCR-T was not sent to the OCS server when the DCCA session is terminated.
> In the current release, when the failure result-code 4010 is received at message/root level and if CCFH is set to terminate/retry-and-terminate action, then the DCCA session is terminated with CCR-T.
> More specifically, for the result-code 4010 received in CCA-U, it is expected to send CCR-T and wait for a response before terminating the DCCA session. For the result-code 4010 in CCA-I, the subscriber session is rejected and CCR-T is sent.
> 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.
> G-CDR Bucket Closure - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use DCCA.
> Old behavior: The G-CDR buckets are closed on receiving 4010/4012 message level from the OCS when failure-handling is configured as terminate or retry-and-terminate. The final CDR will have Normal closure as the causeForRecordClosing.
> New behavior: The G-CDR buckets are not closed immediately on reception of 4010/4012 at the message level when ccfh is configured as terminate or retry-and-terminate. Instead, some flags are set for the CDRs and when the final CDR is being released due to session termination (initiated by DCCA) the containers will be closed and casueForRecordClosing will be an abnormal release with the appropriate change condition.
> 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 release, 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.
> ICSR Compatibility Between StarOS Versions
> The interchassis session recovery (ICSR) feature has been modified to support a greater number of subscribers more efficiently.
> Before Release 11.0, the ASR 5000 allocated a AAA session and sub-session for every bearer. Allocating AAA sessions per bearer required great amounts of memory and CPU.
> In Release 11.0 and beyond, AAA session handling has been moved from bearer level to call line level. A call-id can have a single AAA session, regardless of the number of bearers; this change allows significant savings in memory when more bearers are activated.
> The AAA session handling changes resulted in subsequent changes in the way in which recovery and ICSR work. Therefore, ICSR from StarOS 10.0 or lesser versions will not work when ICSR is attempted to StarOS 11.0 and above. The following table gives a brief overview of different StarOS versions and whether ICSR is supported or not.

> ICSR Compatibility in StarOS Versions
> StarOS Version (Active) | StarOS Version (Standby) | ICSR Supported
> 9.0 | 9.0 | Yes
> 9.0 | 10.0 | Yes
> 9.0 | 11.0 | No
> 9.0 | 12.0 | No
> 10.0 | 9.0 | Yes
> 10.0 | 10.0 | Yes
> 10.0 | 11.0 | No
> 10.0 | 12.0 | No
> 11.0 | 9.0 | No
> 11.0 | 10.0 | No
> 11.0 | 11.0 | Yes
> 11.0 | 12.0 | Yes
> 12.0 | 9.0 | No
> 12.0 | 10.0 | No
> 12.0 | 11.0 | Yes
> 12.0 | 12.0 | Yes

> For more information on ICSR, refer to the Cisco ASR 5000 Series System Administration Guide.
> Increased Attribute Value for 3GPP-IMSI-MCC-MNC - Behavioral Change
> This AAA-related behavioral change is applicable only to P-GW.
> In the earlier releases, for PGW mediation accounting, the number of digits in 3GPP-IMSI-MCC-MNC AVP was decided based on the MCC and MNC in the PGW service PLMN configuration.
> In the current release, the number of digits in the 3GPP-IMSI-MCC-MNC attribute value is purely based on a hardcoded table containing a list of MCCs for which the MNC is of 3 digits.
> Note that internally a table is maintained for this, which is used to compare the first three digits of IMSI with entries in the table and check whether there is a match. If yes, the MNC is encoded as three digits (which is the 4th, 5th and 6th digits in IMSI) else it will be encoded as 2 digits (4th and 5th digits of IMSI).
> 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.
> Monitoring-Key AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface, and all Diameter dictionaries except for the KTF-specific dictionary.
> In the earlier releases, PCEF considered the Monitoring-Key AVP as an unsigned integer internally and hence stripped off the insignificant zeroes in the AVP while encoding/decoding it over Gx.
> In the current release, the insignificant zeroes are not stripped off while encoding/decoding the Monitoring-Key AVP over Gx.
> New Attributes Inclusion in starent-vsa1 Dictionary
> In 12.0 and later releases, no new attributes can be added to the starent-vsa1 dictionary. If there are any new attributes to be added, these can only be added to the starent dictionary. For more information, please contact your Cisco account representative.
> 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.
> Rejection of Access Side Update Procedure - Behavioral Change
> This Diameter-related change is applicable only for a GnGp call in P-GW.
> In the earlier releases, if default bearer QoS/APN AMBR change was reported in CCR-U but not authorized by PCRF, the access side Update PDP context (UPC) request was rejected with GTP_SYSTEM_FAILURE message in case of 3G call on P-GW.
> In the current release, if QOS_Change trigger is hit and PCRF does not authorize the QoS, the access side UPC request is not rejected in case of 3G call on PGW.
> Sanity Checks for Revalidation-Time AVP - Behavioral 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.

> Smart Call Home will be available as part of a Cisco SMARTnet Service contract. For more information, refer to the Smart Call Home website at: http://www.cisco.com/en/US/products/ps7334/serv_home.html.
> Supported-Features AVP - Behavioral Change
> This Diameter-related behavior change applies to all products that use 3GPP Rel. 7 Gx dictionaries.
> In the earlier releases, if a 3GPP 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 was sent with “M” bit set.
> [V] [M] Supported-Features:
> [M] Vendor-Id: 10415
> [V] [M] Feature-List-ID: 1
> [V] [M] Feature-List: 2
> In the current release, if a 3GPP 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 will be sent with “M” bit cleared. All sub AVPs in this grouped AVP will also have 'M' bit cleared.
> [V] Supported-Features:
> [M] Vendor-Id: 10415
> [V] Feature-List-ID: 1
> [V] Feature-List: 2
> 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.
> Termination-Cause AVP in CCR-T Request - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, when the OCS Gy servers are down, then in the CCR-T request message, the Termination-Cause AVP had DIAMETER_LOGOUT as the termination cause.
> In the current release, Termination-Cause AVP will have DIAMETER_ADMINISTRATIVE as the termination cause in the CCR-T.
> 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 administration guide for the product that you are deploying.
> Common Features in Release 12.2
> This section provides information on new features that are common to products in Release 12.2.
> CCR-U with Usage Reports - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, CCR-U with accumulated usage report was sent for immediate reporting request or explicit usage monitoring disable request by PCRF without any new threshold in CCA-U, which corresponds to the usage report in previous CCR-U for the same monitoring keys.
> In the current release, the usage monitoring information instances containing Usage-Monitoring-Report / Usage-Monitoring-Support are not forwarded if the usage for the corresponding monitoring keys have been reported in CCR-U. This avoids the duplication of sending another CCR-U with zero usage when no new threshold is provided by PCRF for the corresponding usage report.
> Change in Value for Termination-Cause AVP During Call Termination - Behavioral Change
> This Diameter-related behavioral change is applicable to all products which use Gy interface.
> In the earlier releases, on clearing the call with the clear subscribers all command, DIAMETER_LOGOUT was sent as Termination-Cause to the OCS in CCR-T.
> In the current release, on clearing the call DIAMETER_ADMINISTRATIVE is sent as Termination-Cause to the OCS in CCR-T.
> Dynamic Route - Behavioral Change
> This Diameter-related behavioral change is applicable to GGSN, HSGW, PDG, PDIF, P-GW, SCSCF/ICSCF, S-GW.
> Old behavior: A dynamic route entry was deleted immediately after the expiry of route.
> New behavior: If there are multiple dynamic routes (multipath routes) for a host then either all should exist or none should exist. That is, a multipath dynamic route entry will be deleted only if all the multipath routes are expired. Because of this change the cli command, show diameter route table will show dynamic route entries with negative expiry value.
> Encoding of 3GPP-SGSN-MCC-MNC AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use Gx interface.
> In the earlier releases, for 3GPP-SGSN-MCC-MNC AVP, the mandatory (M) bit was reset thereby causing Gx CCR-I to be rejected.
> In the current release, the M bit will be set for the 3GPP-SGSN-MCC-MNC AVP.
> Encoding of Acct-Application-Id AVP in CER/CEA - Behavioral Change
> This behavioral change to aaa-custom5 dictionary is customer specific. For more information contact your local sales representative.
> In the earlier releases, CER/CEA received without Acct-Application-Id AVP was considered as an error due to the fact that the Diameter connections were closed at that time.
> In the current release, Diameter connections will remain active even when CEA is received without Acct-Application-Id AVP. Hence, CER/CEA messages received without Acct-Application-Id AVP are no longer considered as an error.
> Encoding of Allocation-Retention-Priority AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the Allocation-Retention-Priority (ARP) AVP and all sub AVPs were sent without M bit set according to 8.7.0 version of 3GPP standard spec, TS 29.212.
> In the current release, the ARP AVP and all sub AVPs are being sent with M bit set as per the 3GPP standard spec TS 29.212, version 8.6.0.
> Encoding of AN-GW-Address AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use Gxa interface.
> Old behavior: The AN-GW-Address AVP was not sent in the CCR-I and RAA messages.
> New behavior: The AN-GW-Address AVP is now sent in the CCA-I and RAA messages for Gxa 3GPP2 standard dictionary.
> Encoding of Gx Specific Diameter AVPs - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface, and HSGW that use the Gxa interface.
> In the earlier releases, “M” bit was set for the following Gx-specific Diameter AVPs violating the standard spec, 3GPP TS 29.212:

> l | Allocation-Retention-Priority

> l | AN-GW-Address

> l | APN-Aggregate-Max-Bitrate-DL

> l | APN-Aggregate-Max-Bitrate-UL

> l | Charging-Correlation-Indicator

> l | CoA-IP-Address

> l | CoA-Information

> l | Default-EPS-Bearer-QoS

> l | Event-Report-Indication

> l | Flow-Information

> l | Flow-Label

> l | Packet-Filter-Content

> l | Packet-Filter-Identifier

> l | Packet-Filter-Information

> l | Packet-Filter-Operation

> l | Pre-emption-Capability

> l | Pre-emption-Vulnerability

> l | Priority-Level

> l | RAT-Type

> l | Resource-Allocation-Notification

> l | Security-Parameter-Index

> l | Tunnel-Header-Filter

> l | Tunnel-Header-Length

> l | Tunnel-Information

> In the current release, the “M” bit is removed for these AVPs. The Diameter incoming message parsing now takes care of the absence of the “M” bit in these AVPs correctly.
> Encoding of Packet-Filter-Content and Precedence AVPs - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use Gxa interface.
> Old behavior: The Packet-Filter-Content and Precedence AVPs were not sent in the update request message.
> New behavior: The Packet-Filter-Content and Precedence AVPs are now sent in the CCR-U message for Gxa 3GPP2 standard dictionary.
> Encoding of Supported-Features AVP in CCR-I - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the 3GPP Rel. 8 Gx dictionaries “r8-gx-standard” and “dpca-custom17”.
> In the earlier releases, the Supported-Features AVP was sent in CCR-I message with “M” bit cleared.
> [V] Supported-Features:
> [M] Vendor-Id: 10415
> [V] Feature-List-ID: 1
> [V] Feature-List: 1
> In the current release, the Supported-Features AVP is sent in the CCR-I message with “M” bit set.
> [V] [M] Supported-Features:
> [M] Vendor-Id: 10415
> [V] Feature-List-ID: 1
> [V] Feature-List: 1
> Encoding of Termination-Cause AVP - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use Gxa interface.
> Old behavior: The Termination-Cause AVP was not sent in the Credit-Control-Request-Termination (CCR-T) message.
> New behavior: The Termination-Cause AVP is now sent in the CCR-T message for Gxa 3GPP2 standard dictionary.
> Error Code Handling in Diameter for Error Code 5002 (Unknown Session ID) - Behavioral Change
> This behavioral change to dcca-custom12 and dcca-custom13 dictionaries is customer specific. For more information contact your local sales representative.
> When the OCS is unreachable or returns certain failure error-result codes, PCEF should assign default volume quota or time and retry the OCS server when this quota exhausts or time expires. In the earlier releases, the PCEF entered assume positive state when receiving the following error-result codes - UNABLE_TO_DELIVER (3002), UNABLE_TOO_BUSY (3004), ELECTION_LOST (4003), and Permanent failures (5000-5999).
> In the current release, if the PCEF receives the result code 5002, it will disconnect the session and will not enter/re-enter assume positive state. The PCEF will initiate a new session with a CCR-I. No interim data will be reported at this point; the session will continue as a standard new Gy session.
> MSISDN Prefix/Suffix/Range Based OCS/IN Peer Selection
> This feature enables configuring both IMSI-based and MSISDN-based values under a particular credit control group. With this feature enabled, you can select appropriate Diameter peer based on the configured Mobile Station International Subscriber Directory Number (MSISDN) prefix/suffix/range value. Default peer will be selected when the MSISDN value does not match any of the configured range. If the default peer is not configured, one of the peers in Diameter endpoints will be chosen.
> Output of Session Active Counter in show ims-authorization servers ims-auth-service Command - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the counter “Sessions Active” under the “show ims-authorization servers ims-auth-service <service_name>” CLI command was used to indicate the total number of sessions that were referencing the server as active.
> In the current release, this counter provides the count of sessions that are referencing this server as either active or standby.
> RAT-Type - Behavioral Change
> This Diameter-related behavioral change is applicable to all products which use Gx interface.
> In 12.1 and earlier releases, the RAT-Type AVP was marked as Mandatory.
> In 12.2 and later releases, the RAT-Type is marked as NOT Mandatory in order to be compliant with the standard spec 3GPP TS 29.212 v8.6.0. That is, the M flag for the RAT-Type has changed from 1 to 0 in Gx CCR message.
> Static Rules for Bearers
> This Diameter-related behavioral change is applicable only to P-GW.
> In the earlier releases, DCCA was assuming that static rules defined in a rulebase were applicable for all bearers.
> In the current release, the static rules defined in a rulebase are applied only to default bearers.
> The following changes have been made in the DCCA routines to check if DCCA needs to be enabled for a session:

> l | Default bearers — Check for Credit Control configuration in all static rules in the rulebase. Also check if Credit Control requirements of all predefined and dynamic rules have been installed.

> l | Dedicated bearers — Check for Credit Control requirements of all predefined and dynamic rules have been installed. The charging-actions of the installed predefined and dynamic rules decide whether DCCA needs to be enabled.

> Support for New AAA Thresholds
> In this release, the following new thresholds can be configured for generating alarms or alerts based on the archival queue percentage of AAA accounting messages.

> l | threshold aaa-acct-archive-queue-size1

> l | threshold aaa-acct-archive-queue-size2

> l | threshold aaa-acct-archive-queue-size3

> Termination of IP CAN Session - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, IP CAN session was terminated on receiving an experimental result code of range 5xxx in CCA-Update request message.
> In the current release, when experimental-result-code of range 5xxx is received, the Diameter peer is notified of the failure and the IP CAN session is no longer terminated.
> Threshold-based Session Usage Reporting over Gx - Behavioral Change
> This Diameter-related behavioral change is applicable to all products that use the Gx interface.
> In the earlier releases, the session level and rule level usage was reported over the Gx interface only when the volume/time threshold is breached.
> In the current release, even if the volume/time threshold is reached, the session level usage is reported over Gx.
> 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.
> ADC Features in Release 12.2
> This section provides information on new Application Detection and Control (ADC) features in Release 12.2.
> P2P Protocols Detection Support
> This release now supports the detection of the following P2P protocols:

> l | AntsP2P

> l | IMO

> l | MyPeople

> l | Netmotion

> l | OGG

> l | OpenVPN

> l | Quicktime

> l | RDT

> l | Scydo

> l | Spotify

> l | Tango

> l | TunnelVoice — only detection

> l | Ultrabac

> l | Usenet

> l | WhatsApp

> IMPORTANT: The Scydo and WhatsApp protocols are new in 9.0 and later releases.
> For more information, please refer the Application Detection and Control Administration Guide.
> Video Detection Support
> The system now supports video detection for the P2P protocol - Meebo.
> For more information, please refer the Application Detection and 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.
> ECS Features in Release 12.2
> This section provides information on new Enhanced Charging Service (ECS) features in Release 12.2.
> Charging Rulebase Name Selection - Behavior Change
> In 12.0 and earlier releases, if multiple Charging-Rule-Base-Name AVP are received from the PCRF, the "last" rulebase is selected and applied to the call. In early 12.2 releases, the "first" rulebase was being selected.
> To maintain a uniform behavior, in later 12.2 releases also the "last" rulebase will be selected by default.
> In cases where the "first" rulebase has to be selected, in the policy-control charging-rule-base-name CLI command a new command option has been introduced to enable that. For more information, in the Configuration Management chapter see the policy-control charging-rule-base-name CLI command.
> Content ID and Service ID Configurable Limits in CLI
> In 12.1 and earlier releases, and in early 12.2 releases, in the CLI the maximum configurable value for content-id and service-identifier was 65535 (maximum 16 bit value). Now the maximum configurable value is 2147483647 (maximum 31 bit value).
> The content-id and service-identifier keywords in the following commands are affected:
> ACS Charging Action configuration Mode
> content-id 1..2147483647
> service-identifier 1..2147483647
> ACS Ruledef Configuration Mode
> if-protocol http content-id 1..2147483647
> if-protocol wsp-connection-less content-id 1..2147483647
> if-protocol wsp-connection-oriented content-id 1..2147483647
> ACS Rulebase Configuration Mode
> cca quota holding-time 1..4000000000 content-id 1..2147483647
> cca quota time-duration algorithm consumed-time 1..4294967295 [ content-id 1..2147483647 ]
> cca quota time-duration algorithm continuous-time-periods 1..4294967295 [ content-id 1..2147483647 ]
> cca quota time-duration algorithm parking-meter 1..4294967295 [ content-id 1..2147483647 ]
> DNS Snooping
> The DNS Snooping feature enables a set of IP rules to be installed based on the response from a DNS query. The rule in this case contains a fully qualified domain name (for example, m.google.com) or its segment (for example, google) and a switch that causes the domain to be resolved to a set of IP addresses. The rules installed are thus IP rules. Any actions specified in the domain rule are inherited by the resulting IP rules.
> In the 12.2 release, the DNS Snooping feature is supported only on the GGSN and P-GW.
> For more information, refer to the 12.2 Enhanced Charging Services Administration Guide Addendum.
> Static ECS-specific Memory Threshold
> Each SessMgr has some memory dimensioned based on system requirements. ECS has an internal threshold at ~90% of this memory after which it bumps up effective call credits to maximum and this causes silent rejects.

> l | It is capped at a magic number not allowing the SessMgr to use its entire memory.

> l | Silent rejects are done even if there is system memory available. Silent in the sense not known unless someone is watching the logs (e.g. no alarms).

> l | It delays the system to recover from memory leaks by capping the calls. Without ECS, SessMgrs would eventually go to WARN, raise alarms. They can then bloat as much as there is available system memory.

> In earlier releases, at approximately 90% CPU utilization, SessMgrs would start rejecting calls with SessMgr event ID 10018.
> In this release, this limit is bumped up to ~1.25X. Note that the normal behavior is that SessMgrs reject calls at 120%, independent of ECS. SessMgrs will be able to go up to and over their dimensioned maximum capacity independent of ECS.
> Tethering Detection
> The Tethering Detection feature enables detection of subscriber data traffic originating from PC devices tethered to mobile smartphones, and also provides effective reporting to enable service providers take business decisions on how to manage such usage and to bill subscribers accordingly.
> In the 12.2 release, the Tethering Detection feature is supported only on the GGSN.
> For more information, refer to the 12.2 Enhanced Charging Services Administration Guide Addendum.
> 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.
> 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.
> Charging Rulebase Name in LOSDV is Configurable
> The maximum length of the charging rulebase name in List of Service Data Volumes (LOSDV) of eGCDRs can be trimmed now with the inclusion of a new command “gtpp egcdr charging-rulebase-name-max-char-length”. With this new command, user will have flexibility to decide the length of charging rulebase name. The user need to specify the rulebase name length explicitly between 1 to 63 in LOSDV to use this feature. In case zero is specified, the charging rulebase name would not be trimmed.
> For more information, refer the Context Configuration Mode Commands chapter of the Command LIne Interface Reference Guide.
> GGSN Features in Release 12.2
> This section provides information on new GGSN features in Release 12.2.
> Enhanced S6b Support
> S6b is an optional Diameter protocol-based interface over which the GGSN communicates with 3G AAA/HSS in LTE/SAE network for subscriber authorization.
> S6b interface has ability to pull SGSN-MCC-MNC from either GTP or AAA-I and send to OCS. When customer roams into GSM environment, OCS needs location information for online charging and metering. 3GPP-SGSN-MCC-MNC AVP and Location Information AVP are defined in Gy and can be used to identify customer location. With this feature, the GGSN collects the value of SGSN-MCC-MNC from the S6b AAA message, so that it can be available to OCS through Gy interface while passing CCR and CCA messages.
> From Release 12.2 onwards, the S6b interface has been enhanced to pass on the UE assigned IPv6 address (IPv6 prefix and IPv6 interface ID) to the AAA server. S6b interface also has support for Framed-IPv6-Pool, Framed IP Pool, and served party IP address AVPs based IP allocation. With this support, based on the Pool name and APN name received from AAA server, the selection of a particular IP pool from the configuration is made for assigning the IP address.
> GGSN Session License Counting
> Old Behavior
> Session credits and session license were counted for both primary and secondary PDP contexts of GGSN call.
> New Behavior
> Session credits and session license are counted only for primary PDP context of GGSN call.
> GTP-U Sequence Number
> CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
> IPv4v6 Type PDP Support
> GGSN now supports IPv4v6 type PDP from release 12.2 onwards. With this support, on single PDP context, both IPv4 and IPv6 user plane can run simultaneously according to 3GPP TS 23.060 V9.8.0 specification.
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the GGSN. Contact your local Cisco sales representative for additional information.
> Notification of Modification/Deletion of LI Target Provision
> The GGSN supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local Cisco sales representative for additional information.
> Rf Interface Support
> Rf interface enables offline accounting functions on the GGSN in accordance with the 3GPP Release 8 specifications. The charging data information is recorded at the GGSN for each mobile subscriber UE pertaining to the radio network usage. Due to the transfer of charging information to GGSN, the services being rendered are not affected in real time.
> The offline charging functionality is based on the network elements that report the accounting information via different type of messages which trigger the charging generation. Following diameter accounting requests are sent from the network elements to the charging data function (CDF) to achieve this reporting:

> l | START

> l | INTERIM

> l | STOP

> l | EVENT

> 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 HNBs 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.2
> This section provides information on new features that pertain to the HRPD Serving Gateway (HSGW) supporting eHRPD network services in Release 12.2. Additional information on these features can be found in the Cisco ASR 5000 HRPD Serving Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
> AN-GW-Address AVP Missed in CCR-I for Dictionary gxa-3gpp2-standard
> Old Behavior
> The AN-GW-Address was not sent in the CCR-I and RAA messages.
> New Behavior
> Now, the AN-GW-Address AVP is sent in the CCA-I and RAA messages.
> AVPs Missed Under Packet-Filter-Information Group AVP in CCR-U for gxa-3gpp2-standard
> Old Behavior
> The AVPs Packet-Filter-Content and Precedence were not being sent in the update request.
> New Behavior
> Now, the AVPs Packet-Filter-Content and Precedence are sent in the CCR-U message.
> GTP-U Sequence Number
> CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
> Gxa - Behavioral Changes
> Default EPS Bearer QoS
> Default EPS Bearer QoS was not supported in Gxa messages in earlier releases. Support has been added in CCR/CCA/RAR messages.
> CCR
> In case of Default EPS Bearer QoS, the value received from STA in EPS_SUBSCRIBED_QOS_PROFILE will be passed on in CCR-I to PCRF.
> CCA/RAR
> PCRF is supposed to respond in CCA/RAR with QCI 9 for Default Bearer. If HSGW receives a value other than 9, a log is printed. HSGW does not terminate the call in such cases.
> Event Trigger
> Event-Trigger related AVPs were not included in RAA when RAR with Event Trigger was received. Support has been added in RAA messages.
> The new behavior is as follows.

> l | For BSID Change event trigger

> l | RAR with event trigger set-> Include the current applicable values.

> l | RAR with event trigger not set ->Include the current applicable values if the value has changed. Do not include the AVP, if the value has not changed.

> l | For all other event triggers

> l | RAR with event trigger set ->Include the current applicable values.

> l | RAR with event trigger not set -> Do not include the event-trigger-related AVP(s).

> Flow-Information AVP
> Flow-Information AVP was not supported inside QoS-Rule-Definition in Gxa messages. Support has been added in CCA/RAR messages.
> HSGW supports parsing of parameters inside Flow-Information AVP.
> Resource Modification Request
> Event trigger Resource Modification Request will be triggered when a Resource Modification Request is triggered from UE. Earlier event triggers QoS Change/TFT Change were used for the same.
> The event trigger Resource Modification Request need not be turned on from PCRF; it is enabled by default.
> Session-Linking-Indicator
> Session-Linking-Indicator was not supported in Gxa messages in earlier releases. Support has been added in CCR messages.
> This AVP is included only in CCR-Initial messages.

> l | CCR-I sent as a result of PDN Connect will have the value SESSION_LINKING_DEFERRED.

> l | CCR-I sent as a result of BBERF Relocation will have the value SESSION_LINKING_IMMEDIATE

> Supported-Features AVP
> Supported-Features AVP was not supported in Gxa messages in earlier releases. Support has been added in CCR/CCA messages.
> HSGW shall set the Supported-Features AVP to Release 9 to indicate compliance to Rel 9. HSGW does not terminate the session if PCRF advertises release 8 support.
> Gxa: SM Support for New Parameters in QoS Rule Definition
> QoS Rule Definition can contain Flow Information; SM supports handling these new AVPs.
> In case of Gx, these parameters are sent as part of the filters to UE and are used for rule matching. Packet Filter ID needs to be stored for all rules which are configured by PCRF as a result of UE-requested resource modification process. These filter IDs need to be used as a key between PCRF and BBERF for any further modification of the SDF/QoS. Refer to 3GPP TS 29.212: Policy and Charging Control over Gx reference point, for more details.
> Gxa: SM Support for Triggering APN AMBR Change
> This scenario occurs when the PDN-specific AMBR is modified by the AAA and the PCRF has subscribed for the QOS_CHANGE Event Trigger. The HSGW shall send a CCR-Update with QoS-Information (UPDATE) for the PDN to update the AMBR information provided for the APN.
> Sessmgr/IMSA support for sending CCR U with QoS Change for APN AMBR change is already present.
> SM needs to call sessmgr_gxa_trigger at the appropriate place.
> Gxa: Support for Enabling Rules/Rulebase in SM
> HSGW supports enabling of pre-defined rules/rulebase from PCRF for Gxa interface. SM supports enabling the rules received from PCRF.

> 1 | The pre-provisioned policy (policy-map, policy-group) needs to be configured in HSGW configuration. Based on the request in diameter messages (CCA, RAR) for inclusion or removal of a given policy-group/rulebase or policy-map/rulename, the rules are loaded and take effect for data tx/rx and QoS Check process.

> 2 | The assumption here is that if HSGW receives a policy-group/rulebase name in diameter msg to load the rules, HSGW will be loading all of the policies within the given policy-group other than type template. If a policy is termed as type “template,” it will only be loaded if HSGW gets the rulename/policy-map in the diameter msg request.

> The case for deletion of the rules is similar.

> 3 | Once the rules are loaded based on above request, it will be effective for rule matching for data transfer and QoS Check/TFT-matching process.

> Gxa: Support for Sending Rule Report in Case of Loss of Bearer
> Network Initiated QoS
> If a bearer is terminated on the HSGW, the HSGW will generate a CCR-U with a charging rule report containing the list of rules affected by the event and a rule status of inactive.
> Gxa: Support for Storing Packet Data ID
> Each Packet-Filter-Information AVP shall include a packet filter identifier as provided by the PCRF in the QoS rule within the Packet-Filter-Identifier AVP identifying the previously requested packet filter being modified and, if the precedence value is changed, shall include packet filter precedence information within the Precedence AVP.
> The Packet-Filter-Identifier AVP (AVP code 1060) is of type Octet String, and it indicates the identity of the packet filter. The packet filter identifier is assigned by the PCRF and within the scope of the PCRF is unique per UE.
> Handling Hostnames Without the “topon/topoff” Label
> Host names are expected to be configured with either “topon” or “topoff” as the first label in the DNS server. In absence of “topxx” label, host name should be treated as implicit “topoff” and first label of DNS returned host name should be stripped to yield the node name for use in topology match.
> The same applies to P-GW FQDN supplied by AAA.
> When P-GW host name does not have topxx label, APN and P-GW FQDN discovery are performed correctly by HSGW.
> Node selection fallback is also done correctly.
> HSGW Router Solicitation
> CLI added to subscriber template to enable the time interval in milliseconds to wait for router solicit before sending the initial IPv6 router advertisement.
> HSGW Support for APN-OI in S2a APN IE
> If mag-service has “mobility-option-type custom2” configured, MAG will send APN-NI+OI in Service Selection field in PBU. APN-OI is constructed from IMSI in EAP NAI and will have the following format:
> mnc<MNC>.mcc<MCC>.gprs
> The HSGW will support P-GW lookup for initial attach using the APN. If the MIP6-Agent-Info header is not present, or empty, then the APN FQDN will be used, which has the format of:
> <APN-NI>.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
> Improved Dynamic P-GW Selection Mechanism by HSGW
> During dynamic P-GW node selection by MME and HSGW, if the selected P-GW is unreachable, MME and HSGW select the next P-GW entry from the P-GW candidate list returned during the S-NAPTR procedure to set up the PDN connection.
> Scenario
> When eHRPD PDN comes up, PMIPv6 session is tried with first P-GW selected and if no reply is received for max-retransmission...
> Old Behavior
> Reject the PDN.
> New Behavior
> If P-GW does not respond, HSGW tries with another P-GW if available based on DNS resolution results by starting with initial retransmission timeout as configured. There is no limit on the number of P-GW fallback attempts per PDN and HSGW will keep trying fallback as long as alternate P-GWs are available. The session may, however, get dropped if session-timeout gets triggered, in which case PMIPv6 PDN will also get deleted.
> Lawful Intercept
> The Cisco Lawful Intercept feature is supported on the HSGW. Lawful Intercept is a licensed enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your local Cisco sales representative.
> Maximum Number of eHRPD PDNs Supported Per Session Configurable
> Old Behavior
> Previously, the maximum number of eHRPD PDNs supported per subscriber session had a hard limit of three.
> New Behavior
> Now, the maximum number of eHRPD PDNs supported per session is configurable from 1 to 14. Default is 3.
> Network Initiated QoS
> The Network Initiated QoS control is a set of signaling procedures for managing bearers and controlling their QoS assigned by the network. This gives network operators full control over the QoS provided for its offered services for each of its subscriber groups.
> If the UE supports Network Initiated QoS, then the UE shall include the MS Support of Network Requested Bearer Control indicator (BCM) parameter in the additional parameter list of the PCO option when sent in the vendor specific network control protocol (VSNCP) Configure-Request from the UE to the HSGW. Otherwise, the UE shall not include the MS Support of Network Requested Bearer Control indicator (BCM) parameter.
> For Network Initiated QOS, three types of operations are permitted:

> l | Initiate flow request

> l | Deletion of packet filters for the specified traffic flow template (TFT)

> l | Modifications of packet filters for the specified TFT

> Node Selection Error Case Handling, P-GW Support
> Previously, PMIP P-GW was allowed to create a new session with handoff indication.
> Now, when PMIP P-GW receives a PBU with Handoff Indicator set to 2 or 4 (indicating inter-tech handoff) and matching session for IMSI/APN is not found in either eHRPD or LTE, then PBU will be rejected with status code 159 BCE_PBU_PREFIX_SET_DO_NOT_MATCH.
> Node Selection: P-GW IP Address Updated and Retrieved During Handover Description
> If PGW-ID (either IP address or PGW-FQDN) is received in MIP6-Home-Agent-Info AVP on the STa interface, it is only used if one of the following conditions is met:

> l | PDN-GW-Allocation-Type AVP is absent

> l | PDN-GW-Allocation-Type is set to STATIC(0)

> l | PDN-GW-Allocation-Type is set to DYNAMIC and attach type is “Handover”

> Otherwise, PGW-ID is ignored and P-GW is discovered by resolving the APN-FQDN.
> Prefix-len in the IPv4 Home Address Request Option of the PBU Message
> Old Behavior
> Prefix-len in the IPv4 Home Address Request Option of the PBU message sent to P-GW was 0x80.
> New Behavior
> Now, Prefix-len in the IPv4 Home Address Request Option of the PBU message sent to P-GW is 0x00.
> Release 9 3GPP References Supported
> The HSGW currently supports the following Release 9 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support.

> l | 3GPP TS 21.905: Vocabulary for 3GPP Specifications

> l | 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

> l | 3GPP TS 23.402. Architecture enhancements for non-3GPP accesses

> l | 3GPP TS 29.212: Policy and Charging Control over Gx reference point

> l | 3GPP TS 29.214: Policy and Charging control over Rx reference point

> l | 3GPP TS 29.229: Cx and Dx interfaces based on Diameter protocol

> l | 3GPP TS 29.273: 3GPP EPS AAA Interfaces

> Support for Storing EPS_SUBSCRIBED_QOS_PROFILE Received from STa in sessmgr
> If Default-Bearer-QoS is received over STa, the value is included in CCR-I. Any change of Default_Bearer_QoS via the Reauth procedure is included in the subsequent CCR-U.
> Support for Stripping IMSI Prefix
> TS 23.003, version 9.2.0, section 19.3.2 was updated as follows:
> The NAI sent in the Mobile Node Identifier field in PMIPv6 will not include the digit prepended in front of the IMSI that is described above.
> The current HSGW includes NAI received in EAP, and P-GW also expects this digit to be present. To support removing the leading digit, mobility-option-type-value standard configuration in MAG/LMA service will be used to support S2a MN-ID. There is no behavior change for custom1 and it will continue to work as usual.
> Added HSGW support for stripping IMSI prefix.
> Completed P-GW changes to extract IMSI from NAI and handle cases when auth-mode digit is included or removed. mobility-option-type configuration is used and standard is expected to receive PBU without digit prepended.
> In both HSGW/P-GW, PBU is expected to have <IMSI>@realm where IMSI field can only be maximum of 16 digits, including auth-mode. If it is more than 16 digits, then it is decoded as invalid IMSI format and IMSI will not be extracted.
> In addition, mobility-option-type custom2 configuration has been added for this feature. The standard will continue to work as before.
> Termination-Cause AVP Missed in CCR-T Dictionary gxa-3gpp2-standard
> Old Behavior
> The Termination-Cause was not sent in the Credit-Control-Request-Termination.
> New Behavior
> Now, the Termination-Cause AVP is sent in the CCR-T message.
> UE Assigned Full IPv6 Address Reporting to AAA
> S6b interface enhanced to pass the UE Assigned IP Address.
> InTracer Features in Release 12.2
> This section provides information on new InTracer features in release 12.2. For more information on InTracer, refer InTracer Installation and Administration Guide.
> InTracer Query by MSISDN Support for 7600 Gateway
> MSISDN support added to InTracer. User can search based by MSISDN.
> InTracer Configuration support for 7600 SAMI platform
> InTracer now supports configuration of 7600 for subscriber and equipment trace, which involves setting trace parameters like trace profile, transfer interval, buffer limit, access to NE, enabling/ disabling trace and viewing trace status and statistics.
> InTracer scaling architecture
> Architectural change is an enhancement of existing TCE application to support the high scalability and to support high load from gateway.
> 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.
> TAU-based Gn/Gp Handover from 3G SGSN to MME - Behavior Change
> Cell re-selection from a 3G SGSN to an MME based on receiving an S1AP Init UE-based TAU request is now supported.
> 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.
> Equipment Identity Register (EIR) S13 Timeout and Failure Handling
> The MME now supports timeout and failure handling for the EIR on the S13 interface. Configuration of the timeout and/or failure response is now available. Refer to the attach and tau commands in the “Mobility Management Entity Command - Modified in Release 12.0” in the Configuration Management chapter for more information.
> 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.
> X.509 Certificate-based Peer Authentication
> The MME supports X.509 certificate-based peer authentication for IPSec tunnels over the S1-MME interface.
> 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.
> Error Message Correction for Maximum Peer SGSN RNC/RAI Configurations
> The MME now correctly identifies error conditions related to reaching the maximum number of configured peer SGSN RNCs and RAIs.
> Previous Behavior
> When the maximum number of peer-SGSN RAI entries were exceeded (32), the error message displayed was: Failure: Unable to retrieve information: error 390:0
> When the maximum number of peer-SGSN RNC-ID entries were exceeded (32), the error message displayed was: Failure: Unable to retrieve information: error 390:0
> New Behavior
> When the maximum number of peer-SGSN RAI entries are exceeded (32), the new error message displayed is: Failure: Maximum number of Peer SGSN RAI entries already configured
> When the maximum number of peer-SGSN RNC-ID entries are exceeded (32), the new error message displayed is: Failure: Maximum number of Peer SGSN RNC-ID entries already configured
> NAS/S1AP Message Re-Order and Piggybacking
> Previous Behavior
> NAS messages received in an incorrect order were piggybacked without re-ordering and retried causing error conditions.
> New Behavior
> If NAS messages require re-ordering, piggybacking is not performed. For example, for a piggybacked Create Bearer Request, if there is a re-order of the NAS/S1AP message, then the Create Bearer Response message will not be piggybacked with the Modify Bearer Request message.
> NRI Length Configuration
> The MME now has the ability to configure the network resource identifier (NRI) length used for source SGSN discovery via NRI-FQDN based DNS resolution. MME now uses the NRI field to resolve peer SGSN during TAU handoffs and Attaches with mapped GUTI. The length of the NRI field can now be configured for a given PLMN. This allows the MME to extract NRI unambiguously from P-TMSI. For more information, refer to the nri command in the Mobility Management Entity Commands - New in Release 12.2 section of the Configuration Management chapter of this change reference.
> Previous Behavior
> The MME only supported RAI-based FQDNs to resolve source SGSNs.
> New Behavior
> The MME now also supports using NRI-based FQDN to resolve the source SGSN. More specific DNS entries can be configured corresponding to each SGSN. SGSNs are now not required to support relay functionality in order for SGSN Context Request and Identification Request messages to reach source SGSN.
> This change was first introduced in version 12.2, and has since been added to version 12.0.
> Mobility Management Entity Features in Release 12.2
> This section provides information on new Mobility Management Entity (MME) features in Release 12.2.
> VLR Offload
> The MME now supports a maintenance command enabling an operator to enable or disable 'offload' mode for a specified VLR. This capability enables operators to preemptively move subscribers away from an SGs interface associated with an MSS which is planned for maintenance mode.
> When this offload command is set on the MME, all sessions matching this VLR are marked with an ‘offload’ flag. During the next UE activity, the MME requires each UE to perform a combined TAU/LAU.
> The VLR offload functionality and MME offload functionality can be used in a mutually exclusive fashion, such that activation of one prevents activation of the other (and vice versa).
> Refer to the sgs offload sgs-service command in the Mobility Management Entity Command - New in Release 12.2 section in the Configuration Management chapter for more information.
> Modify Bearer Request - Behavioral Change
> Previous Behavior
> Modify Bearer Requests always included the APN-Aggregate Maximum Bit Rate (AMBR) information element.
> New Behavior
> The APN-AMBR IE is now only included for PS handovers.
> DNS Lookup for Periodic TAU - Behavioral Change
> Previous Behavior
> SGW relocation occurred irrespective of TAU update type.
> New Behavior
> SGW selection and relocation does not occur if the TAU update type is 'PERIODIC UPDATING'.
> Default Bearer Context Activation - Behavioral Change
> Previous Behavior
> During a Default Bearer Context activation procedure, the MME sent an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message but did not include the operator identifier (mnc <mnc>.mcc<mcc>.gprs) in the Access Point Name information element.
> New Behavior
> The APN information element now includes both the operator identifier and network identifier in ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST messages.
> Network Sharing Support
> To support a network sharing configuration where core network elements (MME, SGW, PGW) are shared between different service providers, the MME service can now be configured with multiple local PLMNs per service. Each mme-service is now able to process multiple PLMNs and indicate this to the eNodeb during S1 SETUP procedures.
> The configuration of these additional PLMNs is implemented using the network-sharing command within the mme-service config mode.
> Refer to the MME Commands - New in Release 12.2 section in the Configuration Management chapter of this guide and to the Cisco ASR 5000 Series Command Line Interface Reference for details of this new CLI command.
> 2G to 4G Gn/Gp SGSN to MME TAU Requests - Behavioral Change
> Previous Behavior
> During a 2G to 4G Tracking Area Update (TAU), the MME sent the SGSN a Context Request message. If the SGSN replies with an SGSN Context Response which includes no PDP contexts, the MME then sent back a Context Acknowledge message with a GTP_MANDATORY_IE_MISSING error, and the TAU would fail.
> In this case, the MME assumed that the UE would never perform a TAU Attach with zero PDP Contexts active in 3G. As a result, the SGSN Context Response with missing PDP contexts was treated as an error condition.
> New Behavior
> If the SGSN Context Response is received with no PDP contexts, the MME now responds with an SGSN Context Acknowledge with cause 'Request Accepted' allowing the Gn/Gp context transfer, but then rejects the TAU with cause 'No EPS bearer context activated'.
> Remove Preamble from Target-ID of Relocation Request - Behavioral Change
> Previous Behavior
> The MME included the preamble in the target-id of relocation requests (sender side) and always expected the preamble in the target-id of relocation request (receiver side).
> New Behavior
> By default (on sender side), the MME no longer includes the preamble in the target-id of relocation requests. On receiver side, the SGSN/MME will act per target-id length. If the target-id length is 8, then the SGSN/MME will act as target-id without preamble.
> To enable the old behavior, refer to the gtpc command in the Mobility Management Entity Commands - Modified in Release 12.2 section of the Configuration Management chapter of this change reference.
> NRI Length Configuration
> The MME now has the ability to configure the network resource identifier (NRI) length used for source SGSN discovery via NRI-FQDN based DNS resolution. MME now uses the NRI field to resolve peer SGSN during TAU handoffs and Attaches with mapped GUTI. The length of the NRI field can now be configured for a given PLMN. This allows the MME to extract NRI unambiguously from P-TMSI. For more information, refer to the nri command in the Mobility Management Entity Commands - New in Release 12.2 section of the Configuration Management chapter of this change reference.
> Previous Behavior
> The MME only supported RAI-based FQDNs to resolve source SGSNs.
> New Behavior
> The MME now also supports using NRI-based FQDN to resolve the source SGSN. More specific DNS entries can be configured corresponding to each SGSN. SGSNs are now not required to support relay functionality in order for SGSN Context Request and Identification Request messages to reach source SGSN.
> Regional Zone Code Restriction
> Regional Zone Code Restriction allows an operator to control the areas in which a UE can roam in to receive service. The code representing the zone in which a UE is to be offered service by the network can be configured in the HSS or using local provisioning in the MME.
> Release 9 3GPP References Supported
> The MME currently supports the following Release 9 3GPP specifications:

> l | 3GPP TS 24.301 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 9)

> l | 3GPP TS 29.274 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 9)

> l | 3GPP TS 29.272 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 9)

> l | 3GPP TS 36.413 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 9)

> Circuit-Switched Fallback
> Support for PS Suspension/Resumption Message - Behavioral Change
> The MME now supports the suspend notification on the S3 interface from the SGSN per 3GPP TS 23.272 (9.5.0) and TS 29.274 (9.4.0). The suspend notification is received and responded to by the eGTP-C demux process.
> SGs SCTP Multi-homing Support
> The SGs interface between the MME and the MSC/VLR now supports SCTP multi-homing. Refer to the bind and vlr commands in the “Mobility Management Entity Commands - Modified in Release 12.2” section of the Configuration Management chapter for more information.
> SGs Service Distribution
> The MME Demux task now learns about SGs services, and configured VLRs, and assigns them to MME Managers based upon a hash algorithm.
> Emergency Cause Code Support
> CSFB mobile emergency calls now use the emergency cause code to indicate to the eNodeB that the call is for emergency purposes. The CS-Fallback-High-Priority cause code is supported in Release 9.
> IMSI Paging
> Per section 5.1.3.1 of 3GPP TS 29.118, the MME now supports IMSI paging based on the following from the specification:
> If the UE is not known and the “MME-Reset” restoration indicator at the MME is set to “true”, the MME shall handle the paging request as follows:

> l | if the MME only supports “SMS only”, the MME shall return an SGsAP-PAGING-REJECT message to the VLR indicating in the SGs cause information element “Mobile terminating CS fallback call rejected by the user”;

> l | if the SGsAP-PAGING-REQUEST message includes the Location area identifier information element, the MME shall page the UE in all the tracking areas served by the MME that can be mapped to the location area indicated in the Location area identifier information element; or

> l | if the SGsAP-PAGING-REQUEST message does not include the Location area identifier information element, the MME may page in all the tracking areas served by the MME, or the tracking areas served by the MME and by the VLR.

> NOTE: The MME can initiate the paging procedure using IMSI with CN domain indicator set to “PS” to request the UE to initiate the attach procedure as described in 3GPP TS 24.301.
> Dual Addressing PDP Contexts
> Support for Dual Addressing on Pre-release 8 SGSNs (Gn/Gp) - Behavioral Change
> The MME now supports dual-addressing for all network nodes including pre-release 8 SGSNs over Gn/Gp.
> Dual Addressing PDP Contexts
> Support for Dual Addressing on Pre-release 8 SGSNs (Gn/Gp) - Behavioral Change
> The MME now supports dual-addressing for all network nodes including pre-release 8 SGSNs over Gn/Gp.
> Equipment Identity Register (EIR) S13 Timeout and Failure Handling
> The MME now supports timeout and failure handling for the EIR on the S13 interface. Configuration of the timeout and/or failure response is now available. Refer to the attach and tau commands in the “Mobility Management Entity Command - Modified in Release 12.2” in the Configuration Management chapter for more information.
> Radio Information Management (RIM) Behavioral Change
> The MME supports RAN Information Management (RIM) procedures as defined in 3GPP TS 23.401 on the S1-MME, S3, Gn, and S10 interfaces.
> S1-MME Enhancements
> S1AP Cause and RANAP Cause Code Mapping - Behavioral Change
> S1AP and RANAP cause codes are mapped as directed in 3GPP TS 23.401 (V9.7.0) and TS 29.010 (V9.2.0).
> MME Support for (RIM) Information Exchange Between eNodeB and RNC - Behavioral Change
> The MME now supports the transparent exchange of RIM information that helps target an RNC to establish RRC connection with the UE.
> Support for eNB/MME (S1-MME) Direct Information Transfer Procedure - Behavioral Change
> The eNB/MME Direct Information Transfer procedure transfers RAN information between an eNB and an MME in unacknowledged mode. The MME does not interpret the transferred RAN information. This procedure uses non-UE associated signalling.
> Support for eNB/MME Configuration Transfer - Inter-MME - Behavioral Change
> The eNB/MME Configuration Transfer procedure transfers RAN configuration information between the eNB and the MME in unacknowledged mode. The MME does not interpret the transferred RAN configuration information.
> Support for IPv6 IPSec and Multi-homing over S1-MME
> The S1-MME interface now supports IPv6 IPSec including multi-homing.
> SON Information Transfer Over S1-MME - Behavioral Change
> The MME now supports SON information transfer via MME/eNB Configuration Transfer messages defined in 3GPP TS 36.413.
> S1-MME Initiated IPSec Tunnel - Behavioral Change
> The MME now supports the initiation of IPSec tunnels to the eNodeB if the following conditions exist:

> l | The first tunnel setup is always triggered by eNodeB. This is the tunnel over which initial SCTP exchanges occur.

> l | MME initiates additional tunnels to the eNodeB after SCTP connection is setup if

> l | the MME is multi-homed: a tunnel is initiated from MME's second address to eNodeB.

> l | the eNodeB is multi-homed: Tunnels are initiated from MME's primary address to each secondary address of eNodeB.

> l | both of the above: A tunnel is initiated from each of MME's addresses to each address of eNodeB.

> In all three cases, the MME does not initiate a duplicate tunnel between the same end points if such a tunnel already exists, either because the eNodeB initiated them previously or because the tunnels from a previous initiation by the MME were not torn down.
> If there is collision, for example, if the eNodeB also initiates a tunnel in the meantime, the tunnel initiated by eNodeB is given preference and the MME-initiated tunnel is torn down. This can happen both after an MME-initiated tunnel has been established or is waiting establishment.
> Tunnels initiated by the MME are not torn down when the SCTP associations on the tunnels no longer exist.
> IPv6 Interface Support - Behavioral Changes
> S3/S10/S11 IPv6 behavioral Changes
> The changes include MME selecting an IPv6 address for a peer-node in S11/S10/S3 interface.
> There is no change in functional behavior over the S11/S10/S3 interfaces.
> IP versions over S11/S10/S3 are not dependant on each other. For example, the MME may use IPv6 over S11 and IPv4 over S10 (provided the MME-EGTPC-Service is bound to both IPv6 and IPv4 address).
> The logic for selecting an S-GW/peer-MME/peer-SGSN is now: preference is given for IPv6 addresses. IPv4 addresses are ignored if IPv6 addresses are present. This applies to weighted selections using the TAI database, as well. Weights for IPv4 addresses are ignored if IPv6 addresses are present (only IPv6 addresses are load-balanced if present).
> If the MME-EGTPC-Service is bound to an IPv4 address and there are only IPv6 addresses available during peer node selection (and vice versa), it is considered as a node selection failure (reason: No suitable addresses available).
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
> Notification of LI Target Provision Modification/Deletion
> The MME now supports the ability to send notifications to LI administrators when an existing LI target provision has been modified or deleted. CP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
> S3 Interface Enhancements
> IPv6 Support
> The S3 interface now supports IPv6 addressing.
> MME to 2G SGSN (GERAN) RAU Attach Support - Behavioral Change
> The MME now supports RAU-based attach procedures to a 2G SGSN over the S3 interface as defined in 3GPP TS 23.401.
> 2G SGSN (GERAN) to MME TAU Attach Support - Behavioral Change
> The MME now supports TAU-based attach procedures from a 2G SGSN over the S3 interface.
> S10 Interface IPv6 Support
> The S10 interface now supports IPv6 addressing.
> S11 Interface Enhancements
> IPv6 Support
> The S11 interface now supports IPv6 addressing.
> NAS Protocol Enhancements
> Additional PDN Connectivity - Behavioral Change
> This feature applies to additional PDN connection for an APN that already has an existing PDN connection, all within a UE context. In such situations, the additional PDN connection uses the same P-GW as the existing connection if both the following conditions are met:

> l | New connection uses dynamic discovery to obtain P-GW address.

> l | PGW for the existing connection was discovered dynamically.

> Dynamic discovery refers to APN FQDN based DNS resolution.
> DNS discovery will still happen for the new PDN request as the fallback list is built up front using the existing design. This avoids changes to NAS FSM. But the requests will be fed from local cache and external requests will be rare unless the TTL is very low.
> The following INFO level mme-app log is added to indicate the re-use.
> 2011-Feb-22+16:10:02.742 [mme-app 147003 info] [1/0/21528 <sessmgr:1> mme_app_util.c:10826] [callid 00004e29] [context: ingress, contextID: 2] [software internal system syslog] Existing PGW for same APN re-used.
> NOT SUPPORTED:
> The P-GW re-use does not apply if the P-GW for the existing connection was allocated statically by any of the following means:

> l | Static Pool

> l | Static allocation by HSS (by IP address or by P-GW FQDN)

> l | Fallback to Static Pool because of DNS discovery failure

> Support for Out-of-order Reception of Default and Dedicated Bearer UE Responses - Behavioral Change
> The MME now does not retry the dedicated bearer request even if the dedicated bearer response is received before the default bearer response, once a successful default bearer response is received.
> Non-delivered NAS Message Handling - Behavioral Change
> The NAS message non-delivery handling is based on the following logic:
> If the message could not be delivered due to an intra-MME handover and the target TA is included in the TAI list, then upon successful completion of the intra-MME handover the MME retransmits the message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME retransmits the message.
> NAS Messages Affected:

> l | EMM messages

> l | GUTI Reallocation Command - Not supported since it is not implemented yet

> l | Authentication Request - Supported, request resumed after HO

> l | Security Mode Command - Supported, request resumed after HO

> l | Identity Request - Not relevant to handover

> l | EMM Information - Not supported

> l | Detach Accept - Not supported

> l | Detach Request - A handover is rejected if a detach request is pending, hence not relevant

> l | TAU Accept - Not supported

> l | Notification Procedure (srvcc) - Not supported

> l | ESM messages

> l | Activate Default Bearer Request - Supported, request resumed after HO

> l | Activate Dedicated Bearer Request - Supported, request resumed after HO

> l | Deactivate Bearer Request - Supported, but not resumed after HO, since during HO the relevant PDN or bearer is deleted

> l | ESM Information Request - Not supported

> l | Modify EPS Bearer Request - Supported, request resumed after HO

> l | ESM Status - Not supported

> Monitor protocol supports decoding of S1AP NAS Non-delivery indication message. The NAS protocol selector shall not show these message since these are not messages sent by UE
> S1AP statistics count the NAS Non-delivery indication message. The un-delivered messages are not counted against NAS statistics.
> UMTS to LTE ID Mapping
> UMTS networks are configured with LACs allocated from the reserved space of 32K to 64K. In LTE networks, this space is typically reserved for MME group IDs. To overcome this issue during inter-RAT handovers, the MME can now be configured with mappings between LACs and MME group IDs.
> Single Radio Voice Call Continuity
> Voice over IP (VoIP) subscribers anchored in the IP Multimedia Subsystem (IMS) network can move out of an LTE coverage area and continue the call over the circuit-switched (CS) network through the use of the Single Radio Voice Call Continuity (SRVCC) feature. The smooth handover of the VoIP call does not require dual-mode radio.
> To support SRVCC functionality on the MME, an Sv reference point is included providing an interface to the enhanced Mobile Switching Center (eMSC) server responsible for communicating with the MME during the handover process.
> Emergency Sessions
> The MME supports the creation of emergency bearer services which, in turn, support IMS emergency sessions. Emergency bearer services are provided to normally attached UEs and to UEs that are in a limited service state (depending on local service regulations, policies, and restrictions).
> APN AVPs
> Wild-card Selected APN Information Now in APN AVPs - Behavioral Change
> When APN selection is based on wild-carded APN-Information, the Update-Location-Request of S6a interface will now contain the Active-APN list along with Specific-APN-Info under the list. Below is the new definition of both the AVPs:
> Active-APN ::= <AVP-Header: 1612 10415 Type:GROUPED Flags: M >
> { Context-Identifier }
> { Service-Selection }
> { MIP6-Agent-Info }
> { Visited-Network-Identifier }
> *[ Specific-APN-Info ]
> *[ AVP ]
> Specific-APN-Info ::= <AVP-Header: 1472 10415 Type:GROUPED Flags:M >
> { Service-Selection }
> { MIP6-Agent-Info }
> [ Visited-Network-Identifier ]
> *[ AVP ]
> Previous behavior:

> l | Service-Selection and MIP6-Agent-Info AVPs were NOT present under Active-APN level if Specific-APN-Info is present.

> l | Visited-Network-Identifier AVP was NOT present under Specific-APN-Info level.

> New behavior:
> Service-Selection, MIP6-Agent-Info and Visited-Network-Identifier AVPs will be present under both Active-APN as well as Specific-APN-Info AVP.
> 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
> In this release, 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.
> MUR Features in Release 12.2
> Aggregation Support for Top N Subscribers Report
> In this release, the Top N Subscribers Report and Top N VCD Subscribers Report are available per week and month.
> E-mailing Capabilities of MUR
> Apart from custom reporting, the support for e-mailing weekly/monthly reports and all alarms including KPI alarms is made available in this release.
> If the user(s) and e-mail server are configured in MUR,

> 1 | Weekly Reports and Monthly Reports URL will be e-mailed to configured e-mail users at the start of the week and at the start of the month

> 2 | If MUR alarms are enabled then KPI alarms are e-mailed to configured users

> MUR Installer Changes
> In this release, a new parameter “Available Port Range for MUR Components (200 Ports)” has been introduced during the MUR installation. With this parameter, the user can either accept the default port range or enter a new port range when the default ports are not available.
> Please note that the user is required to enter only the start port number as the end port number will be populated automatically based on the start port number. If any of the port/ports in the specified range is/are busy then the installer throws error and prompts the user to enter new start port number.
> MUR Support for Tethering Detection
> The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis. The EDRs generated by the chassis will be enhanced to include OS signatures.
> IMPORTANT: Use of Smartphone tethering detection feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing User Agent and IMEI field, and populates the following set of data in the respective database files.

> l | Laptop (USB Dongles device group) - User Agent data - Identifies the browser from which the HTTP or WAP request is generated from.

> l | Laptop (USB Dongles device group) - OS Signature data - Applications and Operating systems running on the smartphone are device-specific

> l | Smartphone - IMEI/TAC data - Unique identifier for a device

> MUR allows the user to enter dongle TACs through the GUI. This in turn allows MUR to identify all laptop OSs and Laptop UAs in the network by mapping the user identified dongle TACs to the corresponding laptop OS and laptop UAs for a flow. All other TACs could either be smartphone TACs or simplephone TACs. If MUR finds a laptop OS or laptop UA matching to a smartphone TAC, MUR will mark the flow as tethered and put into a tethered DB file. These database files are then pushed to all gateways under the /mnt/hd-raid/data/databases/ directory immediately or at a configurable intervals.
> MUR provides the required data for tethering detection to the chassis. ECS software running on the chassis plays a vital role in the tethering detection. For information on how the detection is performed, see the 12.2 Enhanced Charging Services Administration Guide Addendum.
> New EDR Attributes for MUR Reporting
> The EDR attribute “sn-volume-amt” reports the total uplink/downlink packets/bytes during a flow. This also contains the packets/bytes dropped and retransmitted by ECS.
> With the use of “sn-volume-amt” counters, the report may not be an accurate representation of the packets/bytes actually downloaded by the subscribers. This might result in over-charging or over-reporting (the volume) of the subscribers.
> To avoid this scenario, in this release, MUR supports the following new EDR attributes:

> l | sn-charge-volume ip bytes downlink

> l | sn-charge-volume ip pkts downlink

> l | sn-charge-volume ip bytes uplink

> l | sn-charge-volume ip pkts uplink

> MUR provides the flexibility to choose among legacy “sn-volume-amt” or newly added counters “sn-charge-volume” to count the volume. By default, MUR will use “sn-volume-amt” to count the volume.
> Offline Subscriber Search Configuration
> In the current release, MUR can be used in “Offline Subscriber Search Only” mode. In this mode, MUR will not parse incoming EDR files, so no online reports will be generated.
> It will move the incoming EDR files to archive directory, so that you can avail “Offline Subscriber Search Reports” only. By default, this mode is turned off. To run MUR in Offline Mode, set parameter value as “True”. To turn off Offline Mode, set the parameter value as “False”.
> Region-based Reporting
> In 12.0 and earlier releases, RDP was considered as a region. So, all reports were based on RDP. Whenever an RDP is configured, internally MUR used to create corresponding region for the same. However, in release 12.2 and beyond, one gateway's files will be processed by two or multiple RDPs. In that case, RDP does not stand as a region. So, reports will be required across all the RDPs under one specific region.
> Particularly, when there are multiple such regions where each region has more than one RDPs, this feature becomes more important. A different case for the requirement of this feature is a region where there are multiple gateways and they are processed by different RDPs. In that case, per RDP based reports will not make sense, rather, region based reports will be required.
> In this release, MUR allows users to create individual regions, and add RDPs to those regions. All the gateways must be associated with RDP(s) or NOC and not to a region.
> Subscriber Search Enhancement
> Along with the support for string-based MSISDNs (called as NAI: Network Access Identifier) of HA/PDSN (CDMA), subscriber search has been enhanced to include options to search by more dimensions like IMEI, Subscriber Port, etc.
> The MUR GUI provides user with options to select type of search dimension as well as fields/columns that will appear in excel report. For example, user can select Search By MSISDN for searching subscribers having numeric MSISDNs, NAI for searching subscribers having string-based MSISDNs of HA/PDSN (CDMA).
> Based on the reporting requirements, the user can add/remove the EDR fields from Optional Fields list to Report Fields list. Users can request an e-mail with report attached, while entering a search request.
> The mandatory fields present at the time of search will be included in output CSV report. The fields applicable to flow EDRs will be present in flow CSV report. Fields applicable to HTTP EDRs will be present in Http CSV report.
> Support for Additional Ports and Numerous P2P Protocols
> MUR supports additional ports, as listed on IANA site, starting from 0 to 1600 and each of them are mapped to respective protocols.
> In this release, MUR allows the user to select from the available port range at the time of installation.
> Support for Granular Reporting
> The granularity of access controls to user is being extended to ensure that access to reports is controllable by the user. This implies that the user is allowed to configure the granularity settings based on which the reports will be generated in real-time. For example, if granularity 5 is configured, then data will be parsed and report will be viewed with 5 minutes granularity.
> The EDRs are processed as frequently as possible allowing reports to be generated shortly after the period to which they apply. Granularity support is currently provided for DPI and HTTP Content Type Summary reports.
> Support for Meebo Protocols
> MUR makes the MEEBO video/voice protocol available as P2P protocols by default. The meebo-audio is now mapped to voip, meebo-video to video and meebo-unclassified to streaming category.
> Support for New Reports
> In this release, MUR supports generation of the following new reports:

> l | Reports based on HTTP Services: This feature extends the definition of a service from host name to include a URL or part of a URL and/or port number. HTTP services can be defined as a combination of Host name, Content type, and Part of URL.

> l | Reports on Top N Device groups vs Top N Hosts and vice-versa: These reports are possible from the MUR GUI through HTTP tab and Custom Reporting option under Available Reports menu.

> l | Video Usage Monitoring Report: Through this custom TopN reporting feature, it is possible to monitor and report the video traffic usage as and when needed. This report is mainly required to identify TopN hosts for video traffic and also to determine the biggest sources of video traffic, which drives the network load at a greater extent.

> HTTP content type will be used to identify the video traffic. Ideally video traffic should be derived from flow-EDRs. Since the video usage monitoring report is generated based on HTTP content type, only HTTP traffic will be counted.

> l | Report based on Cell Location: This feature allows the usage to be reviewed by Cell ID either as a Top N list of usage by location or a list of fixed locations to be monitored (for top N subscribers per cell) or as a filter on reports (comparable to SGSN group or Device group).

> On selecting Location Group filter from the Filter selection panel, the following reports can be derived:

> l | Location by volume

> l | Cell per location by volume

> TopN subscribers per cell report can also be generated but through the TopN Search tab under Custom Reporting.

> l | Report for Roaming Monitor: The concept of “Roaming Partner Group” is introduced for this reporting. Roaming partner can be defined using MCC-MNC pair as well as SGSN group. Each roaming partner can have multiple MCC-MNC pairs and SGSN groups.

> MUR users should manually configure MCC and MNC through System menu, and then map this MCC-MNC combination with the roaming partner.

> l | Reports based on HTTP Service Profile: Service Profile is defined as the group of rulebases. Hence, for the service profile reports to be fetched, rulebase name is the mandatory input required from the user. The “Rulebase” name should be added and then a Service Profile must be created to map with the rulebases.

> l | Report on Top N Unknown Ports: This report highlights the top N ports for which traffic is classified as either unidentified or unknown. This report can be viewed through the link Edr unknown port infos under the System menu.

> l | Reports based on Session: This report provides the statistical analysis of user sessions over the session duration. A session is defined as the unique combination of GGSN address and charging identifier. Charging identifier is used together with GGSN address to identify all records produced in SGSN(s) and GGSN involved in a single PDP context.

> Support for P2P Video Detection
> MUR now supports traffic type detection for P2P protocols such as Skype, Gtalk, MSN, Yahoo, and Oscar with the use of “traffic-type” attribute present in the EDR fields. Based on the value of this EDR attribute, the data will be classified to respective protocols.
> Support for TopN HTTP Hosts Report
> TopN IP Traffic Report is no longer supported. MUR now supports TopN HTTP Hosts report, which can be used instead. This report uses “ip-server-ip-address” Flow-EDR attribute.
> In the XLS report, TopN IP worksheet will be empty.
> MVG Features in Release 12.0
> The Mobile Video Gateway is a new product in Release 12.0.
> For information about the Mobile Video Gateway, see the Mobile Video Gateway Administration Guide.
> MVG Features in Release 12.2
> This section provides information on new Mobile Video Gateway features in Release 12.2.
> MVG Support on the GGSN
> In Release 12.2, the Mobile Video Gateway software can be integrated with a GGSN (Gateway GPRS Support Node) in a GPRS/UMTS (General Packet Radio Service/Universal Mobile Telecommunications System) network.
> For more information, see the Mobile Video Gateway Administration Guide for Release 12.2.
> 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.
> For more information, see the Network Address Translation Administration Guide.
> NAT Features in Release 12.2
> This section provides information on new Network Address Translation (NAT) features in Release 12.2.
> Support for NAT64
> Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. The IPv4 address of IPv4 server/host in an IPv4 network is obtained to and from IPv6 addresses by using the configured stateful prefix. The IPv6 addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the usual NAT manner.
> NAT64 is applied on traffic based on the rule match (Destination based NATing). If NAT64 has to be applied, then the NAT64 will translate and forward them as IPv4 packets through the IPv4 network to the IPv4 receiver. The reverse takes place for packets generated by hosts connected to the IPv4 network for an IPv6 receiver. If NAT64 is not applied on the IPv6 packet, then the IPv6 packet will not be translated and sent as is (NAT bypassed) and will be routed within the IPv6 network to the destination.
> NAT64 will not be applied for packets whose destination IP address does not match a pre-defined prefix. NAT64 will be applied only for packets whose destination IP address matches a pre-defined prefix. The pre-defined prefix is configurable, and it can be a single prefix or a group of prefixes.
> Support for NAT64 ALGs
> NAT64 ALGS support the following protocols:

> l | File Transfer Protocol (FTP)

> l | Point-to-Point Tunneling Protocol (PPTP)

> l | Real Time Streaming Protocol (RTSP)

> l | Trivial File Transfer Protocol (TFTP)

> ICSR Support
> This release now supports the following:

> l | Many-to-one NAT flow recovery in ICSR

> l | SIP ALG supports ICSR and is applicable only to UDP flows

> For more information, see the Network Address Translation Administration Guide.
> PDG/TTG Features in Release 12.2
> This section provides information on new PDG/TTG features in Release 12.2.
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the PDG/TTG. Contact your local sales representative for detailed information.
> Notification of LI Target Provision Modification/Deletion
> The PDG/TTG now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
> PDSN Features in Release 12.2
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the PDSN. Contact your local sales representative for detailed information.
> Notification of LI Target Provision Modification/Deletion
> The PDSN now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
> Support for Transfer of LI Information in TCP Format
> The PDSN now has the capability to send intercepted information in TCP format. Contact your local sales representative for detailed information.
> 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.
> 3G Access to GGSN-PGW-R8 - Gx Bearer ID Missing
> Old Behavior
> In case when UE_ONLY BCM was received from PCRF, IMSA terminated the call for P-GW/GnGp P-GW because BCM of UE_ONLY was not supported.
> New Behavior
> When BCM of UE_ONLY is received from PCRF, P-GW/GnGp P-GW will not terminate the call. This is applicable to all dictionaries.
> New policy-control bind-default-bearer CLI command will bind all the PCC dynamic or pre-defined rules coming from PCRF to the default bearer in the following circumstances:

> l | no QCI

> l | QCI that matches the default bearer, but no ARP defined

> l | QCI and ARP that matches the default bearer.

> This CLI will be used when BCM mode is UE_ONLY.
> If the P-GW gets a rule with QCI/ARP other then the default bearer, it will ignore such rules and send a response that the rule could not be installed.
> This command will not work for dedicated bearers (secondary PDP contexts). If the P-GW gets a PCC dynamic rule, pre-defined rule from PCRF with QCI or ARP different from that of the default bearer, then those rules will be dropped. Secondary bearers initiated by UE will not be supported.
> ARP Command Extended
> Implemented changes to extend the existing CLI command for allocation-retention-priority to also optionally include enabling of PCI and PVI flags.
> If these are not enabled explicitly, then the current values will hold true [PCI = 1, PVI = 0].
> Charging Rulebase Name in LOSDV is Configurable
> The maximum length of the charging rulebase name in List of Service Data Volumes (LOSDV) of P-GW CDRs can be trimmed now with the inclusion of new command gtpp egcdr rulebase-max-length <rulebase_name_max_length>. With this new command, user will have the flexibility to decide the length of charging rulebase name. The user needs to specify the rulebase name length explicitly, between 1 to 63, in LOSDV to use this feature. In case zero is specified, the charging rulebase name would not be trimmed.
> For more information, refer the Context Configuration Mode Commands or GTPP Group Configuration Mode Commands chapter of the Command Line Interface Reference Guide.
> ChargingRuleBaseName in P-GW CDRs
> Old Behavior
> RuleBase attribute was sent as it is on the P-GW CDRs without trimming to 16 characters.
> New Behavior
> For GTPP dictionary custom40, RuleBase attribute name is trimmed to 16 characters in P-GW CDRs.
> Diameter AVP Behavior Change
> Formerly, insignificant zeroes in the monitoring key were stripped off while encoding/decoding it over Gx.
> Now, insignificant zeroes are not stripped off while encoding/decoding the monitoring key AVP over Gx. As monitoring key is internally interpreted as an unsigned integer and the insignificant zeroes are not stripped off from the key, the value should be of four bytes in length and not lesser or greater; this will prevent PCRF rejection due to invalid length.
> 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.
> IKEv2 IP Security Support on S5 Interface
> IP Security (IPSec) on the S5 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 S-GW initiates an IPSec tunnel to the P-GW. The P-GW service is responsible to verify the configuration and use an IPSec API to make the P-GW listen on the service address for IKE requests.
> When configured for IPSec, the S5 Interface carries GTP-C signaling traffic and GTP-U data traffic that flows through an IPSec tunnel.
> 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.
> X.509 Certificate-based Peer Authentication
> The P-GW supports X.509 certificate-based peer authentication for IPSec tunnels over the S5 interface.
> P-GW Features in Release 12.2
> This section provides information on new Packet Data Network Gateway (P-GW) features in Release 12.2. 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.
> 1:1 NAT64 Not Happening if NAT44 Initiated First and Vice Versa
> Old Behavior
> 1:1 NAT IP was either used for NAting IPv4 or IPv6 traffic, but not both. There was no 1:1 NAT64 binding table. All downlink traffic received on 1:1 NAT64 IP was translated to client IPv6 addr in ACL clp, irrespective of the interface id used for uplink.
> New Behavior
> 1:1 NAT IP can be shared by IPv4/IPv6 traffic. 1:1 NAT64 binding table is maintained to store the interface ID/prefix. The downlink traffic is properly translated based on the binding table. The interface ID/prefix are obtained form the binding entry.
> 1:1 NAT 64 will now function as expected.
> Accurate UE Time Zone Reporting
> Verified that P-GW is able to process UE time zone IE from S5/S8 from MME/S-GW. Also, P-GW-PCRF interaction has been verified.
> Always-On Licensing
> Traditionally, transactional models have been based on registered subscriber sessions. In an “always-on” deployment model, however, the bulk of user traffic is registered all of the time. Most of these registered subscriber sessions are idle a majority of the time. Therefore, Always-On Licensing charges only for connected-active subscriber sessions.
> A connected-active subscriber session would be in “ECM Connected state,” as specified in 3GPP TS 23.401, with a data packet sent/received within the last one minute (on average). This transactional model allows providers to better manage and achieve more predictable spending on their capacity as a function of the Total Cost of Ownership (TCO).
> CLI Command “show ims-authorization” Output Corrected
> Old Behavior
> Bearer ID was displayed as “0” in the output of CLI command show ims-authorization sessions all for all except access type 3GPP-GPRS.
> New Behavior
> Bearer ID is displayed as “NA” in the output of CLI command show ims-authorization sessions all for all except access type 3GPP-GPRS.
> Configuration Changes to Allow Gy-based User Sessions to Continue During OCS Failure and Ability for P-GW/HA to Continue Data Session for Fixed Time/Quota During OCS Outage
> Existing servers-unreachable command has been modified. If set, new configuration options would:

> l | Determine the gateway behavior if OCS becomes unreachable, either due to transport failure or due to message timeouts owing to network congestion.

> l | Control the triggering of server-unreachable scenarios at response timeout or at Tx expiry.

> l | Allow P-GW/HA to continue data session for fixed time/quota during OCS outage.

> Dedicated Bearer Restrictions
> Using local policies, the following procedures can be performed:

> l | Allow dedicated bearers for subscribers belonging to all PLMNs.

> l | This is achieved by activating predefined rules on the PCEF.

> l | Allow dedicated bearers on a per PLMN basis (list must support at least 5 PLMNs).

> l | Serving-PLMN can be used as a classifier to evaluate the condition.

> Allow dedicated bearers for all PLMNs
> config
> local policy test
> ruledef all-plmn
> condition priority 1 serving-plmn match .*
> exit
> actiondef create-bearer
> action priority 1 activate-rule ded-bearer
> exit
> eventbase new-call
> rule priority 1 ruledef all-plmn actiondef create-bearer
> end
> exit
> end
> Allow dedicated bearers on a per PLMN basis
> config
> local policy test
> ruledef select-plmn
> condition priority 1 serving-plmn eq 123.* 456.*
> exit
> actiondef create-bearer
> action priority 1 activate-rule ded-bearer
> exit
> eventbase new-call
> rule priority 1 ruledef select-plmn actiondef create-bearer
> end
> exit
> end
> ECS Maximum Sessions Limit
> Old Behavior
> Every bearer in a P-GW (or pdp context in case of GGSN) belonging to the same subscriber consumed one ECS license each. When a subscriber had multiple bearers/pdp contexts, then ECS licenses were exhausted before the actual limit for subscribers was reached, which resulted in new calls being denied.
> New Behavior
> Now, a single ECS license is consumed per subscriber, irrespective of the number of default or dedicated bearers (primary or secondary pdp contexts) it may have. ECS licenses will be exhausted only after reaching the configured limits.
> Flow Definition Based on Domain Name
> Added support for grp-of-ruledefs and predefined-dynamic-rule. Added DNS analyzer changes for storing IPv4, IPv6 and CNAME entries and removing the config lists on “no” CLIs. Added CLI command for adding ip server-domain-name ruledef and creating IP table per rulebase.
> Functional Behavior Change for Prefix Len Value in IPv4 Home Address Reply Option in PBA
> If CLI command ip pool has subscriber-gw-address configured, then value configured will be sent in IPv4 default router address option in PBA.
> In addition, value of prefix len in PBA will be set to mask of the pool if mobility-option-type-value standard is configured in LMA service.
> GTP-U Sequence Number
> CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
> Gx Interface Updates

> l | Support for IPv4 deferred address selection.

> l | Support for new Packet-Filter-Operation and Packet-Filter-Information AVPs.

> l | Support for sending 3GPP-MS-Time Zone.

> l | Support for Event Trigger related AVPs in RAA.

> l | Support for Flow-Information in Charging Rule Definition.

> Gy Feature Parity
> Custom dictionary added to support the following features developed for the Home Agent DCCA Gy:

> l | Conveying of User Location Information to OCS for all RAT types

> l | Conveying of RAT type info to OCS

> l | Conveying of SGSN IP address to OCS

> l | Support of DCCA redirection

> l | Support of default quota

> l | Support of DCCA failure handling action=continue with timer (allow session to continue and disconnect after timer)

> IMSI+CC Based Virtual APN Selection
> Old Behavior
> With previous virtual-apn CLI command, either cc or imsi could be used to define a selection rule for virtual apn.
> New Behavior
> Now, virtual-apn CLI command can also be used to define a imsi+cc virtual apn selection rule.
> Install Rules on Default Bearer Without Access Interactions
> While installing the dynamic and predef rules in LTE scenario, if qci and arp values specified in the rule are of the default bearer, then TFT is not sent to MS. Also, if qci and arp are not specified in the rule, then the configuration of the default bearer will be used and TFT is not sent to MS.
> CLI Changes:
> policy-control update-default-bearer
> default policy-control update-default-bearer
> These above configurations will continue sending TFT to the MS on default bearer.
> no policy-control update-default-bearer
> This configuration will not send TFT to MS on default bearer.
> Interface ID Not Allowed in IPv6 Range Pools
> Old Behavior
> CLI command ipv6 pool <name> range <start_address end_address> was allowing interface ID as part of configuration.
> New Behavior
> When interface ID part of the IPv6 address is configured as part of range, interface ID is cleared and a warning message is displayed.
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the P-GW. Contact your local sales representative for detailed information.
> Notification of LI Target Provision Modification/Deletion
> The P-GW now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
> NAT Binding Updates (NBU) Supported on P-GW
> This functionality has been implemented.
> Node Selection: P-GW Selects OCS
> P-GW may be configured with Diameter peer information for a pair of primary and secondary Online Charging Server (OCS). In this case, P-GW shall select the secondary OCS when the primary OCS is not available. P-GW shall perform an AAAA DNS query (IPv6) on FQDN (from Diameter peer information) to obtain the IP addresses of primary and secondary OCS nodes. P-GW shall then establish CER/CEA connectivity toward both OCS nodes. For normal Gy Diameter Credit-Control Application (DCCA) requests, the P-GW shall use the primary OCS connection.
> Option Required to Keep eGTP-C Sessions Alive After Echo Timeout
> Previously, the system cleared all subscribers to the downed eGTP-C peer after echo timeout. This is still the default system behavior.
> New CLI configuration has been added to allow the following alternate behavior in peer outage/restart scenarios:

> 1 | When there is an eGTP-C timeout, log event, but do not clear subscribers.

> 2 | When the peer comes back, only clear subscribers if the recovery/restart counter has been incremented on the peer.

> P2P Local Pattern MyPeople Support in Customer PCEF
> Completed the following CLI command changes as part of the P2P CLI implementation:

> l | show active-charging sessions

> l | how active-charging flows

> l | show active-charging flows

> l | show active-charging analyzer statistics

> P-CDR Enhancements to Service and Rating IDs
> The allowed range of content-id configurable was changed to maximum 31-bit value. The allowed range of service-identifier configurable was changed to maximum 31-bit value. The following CLI commands help text has been changed to display maximum value as 2147483647 instead of 65535:

> l | service-identifier <value>

> l | content-id <value>

> l | cca quota holding-time <value 1> content-id <value 2>

> Old behavior: The maximum value allowed to be configured for content-id and service-identifier was 65535 (maximum 16-bit value).
> New behavior: The maximum value now allowed to be configured for content-id and service-identifier is changed to 2147483647 (maximum 31-bit value).
> P-GW CDR Adaptation
> custom42 is a new GTPP dictionary supporting ASCII format P-GW CDRs.
> P-GW CDRs are locally stored on HDD.
> The following events trigger closure and the sending of a partial P-GW CDR:

> l | every x octets configured using “volume x” (up/down/total)

> A P-GW CDR is closed as the final record of a subscriber session for the following events:

> l | Detach Request received from UE

> l | Delete bearer context request received from S-GW.

> l | Manual subscriber clearing

> l | Abnormal Releases, such as path failures

> P-GW Failed CRBN Change with GW_PCEF_MALFUNCTION
> Old Behavior
> If default bearer QoS/APN AMBR change is reported in CCR-U but not authorized, the access side procedure is rejected in case of 3G call on P-GW.
> New Behavior
> If default bearer QoS/APN AMBR change is reported in CCR-U but not authorized, the access side procedure is not rejected in case of 3G call on P-GW.
> P-GW RAR Handling While Waiting for CCA Issue for Gy OUT-OF-CREDIT
> Old Behavior
> In the case when RAR was received from PCRF when there is a pending auth state, PCEF responded with a permanent failure (Unable to Comply). As per RFC 3588, the client/server should not retry the request if there is a permanent failure in a response. PCEF should not respond with permanent failure and instead let the PCRF retry the request after some time.
> New Behavior
> Since there are no transient failures fitting this category, using protocol error “Unable to Deliver”.
> Range for ARP Value in Local Policy Increased
> Old Behavior
> ARP had a range from 1-15.
> New Behavior
> ARP range increased to 1-127.
> RAR handling in P-GW from OCS

> 1 | If rating-group/service-identifier is received in RAR,

> l | regardless of Gating Expire Time expiry, PCEF respond and shall immediately send CCR-U, Rating-Group/Service-Identifier, Reporting-Reason = forced_reauth.

> l | if the corresponding service group is in denied state, Used-Service-Unit shall be set to 0.

> l | if the corresponding service group is in active state, Used-Service-Unit shall be set to real value.

> 2 | If rating-group/service-identifier is not received,

> l | regardless of Gating Expire Time expiry, PCEF shall not send CCR-U

> l | when user traffic comes and Gating Expire time expires, PCRF shall send CCR-U, Reporting-Reason = quota_exhausted

> l | if the corresponding service group is in denied state, Used-Service-Unit shall be set to 0

> 3 | Inter-RAT handover case:

> l | PCRF shall send all the MSCCs for all the rating groups including denied rating groups

> l | reporting-reason = Rating-Condition-Change

> l | if the corresponding service group is in denied state, Used-Service-Unit shall be set to 0

> l | if the corresponding service group is in active state, Used-Service-Unit shall be set to real value

> Support at Minid
> Support has been added in minidiameter to send Gating-Expire-Time AVP in response to CCR-FINAL (for FUA-Terminate and 4012 case).
> Support at DCCA Level
> mscc->grant.gating_expire_time is at mscc level and represent those MSCCs for which Gating-Expire-Time AVP was received from the server.
> The timestamp is stored in:
> time_t gating_expire_time /* and indicates the time for which PGW
> must have GATE-Off for gate-off services.*/
> Release 9 3GPP References Supported
> The P-GW currently supports the following Release 9 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support.

> l | 3GPP TR 21.905: Vocabulary for 3GPP Specifications

> l | 3GPP TS 22.115: Service aspects; Charging and billing

> l | 3GPP TS 23.003: Numbering, addressing and identification

> l | 3GPP TS 23.007: Restoration procedures

> l | 3GPP TS 23.060. General Packet Radio Service (GPRS); Service description; Stage 2

> l | 3GPP TS 23.203: Policy and charging control architecture

> l | 3GPP TS 23.207: End-to-end Quality of Service (QoS) concept and architecture

> l | 3GPP TS 23.216: Single Radio Voice Call Continuity (SRVCC); Stage 2

> l | 3GPP TS 23.228: IP Multimedia Subsystem (IMS); Stage 2

> l | 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

> l | 3GPP TS 23.402. Architecture enhancements for non-3GPP accesses

> l | 3GPP TS 24.008: Mobile radio interface Layer 3 specification; Core network protocols

> l | 3GPP TS 29.060: General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface

> l | 3GPP TS 29.061: Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)

> l | 3GPP TS 29.212: Policy and Charging Control over Gx reference point

> l | 3GPP TS 29.214: Policy and Charging control over Rx reference point

> l | 3GPP TS 29.229: Cx and Dx interfaces based on Diameter protocol

> l | 3GPP TS 29.230: Diameter applications; 3GPP specific codes and identifiers

> l | 3GPP TS 29.272: Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol

> l | 3GPP TS 29.273: 3GPP EPS AAA Interfaces

> l | 3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

> l | 3GPP TS 29.275: Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage 3

> l | 3GPP TS 29.281: General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)

> l | 3GPP TS 29.282: Mobile IPv6 vendor specific option format and usage within 3GPP

> l | 3GPP TS 32.240: Telecommunication management; Charging management; Charging architecture and principles

> l | 3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS) domain charging

> l | 3GPP TS 32.298: Telecommunication management; Charging management; Charging Data Record (CDR) parameter description

> l | 3GPP TS 32.299: Telecommunication management; Charging management; Diameter charging application

> Removed “violate-action shape” from “apn-ambr” Command
> Added support for grp-of-ruledefs and predefined-dynamic-rule. Added DNS analyzer changes for storing IPv4, IPv6 and CNAME entries and removing the config lists on “no” CLIs. Added CLI command for adding ip server-domain-name ruledef and creating IP table per rulebase.
> Rf Interface Updates

> l | In SDF level accounting, buckets are created and maintained using the Reporting-Level AVP value present in Gx message. The following are the accounting keys currently supported:

> l | Rating-group

> l | Rating-group and Service-Identifier

> l | Rating-group and QCI

> l | Rating-group, Service-Identifier, and QCI

> New CLI added in Accounting Policy Configuration Mode.

> l | Existing volume/time limit is applied for session level in accounting policy. New CLI configuration added at SDF level.

> l | Service Data Volume Limit: Volume Limit reached for a specific flow. The container for this change condition will be cached by the P-GW and the container will be in an ACR Interim/Stop sent for partial record (Interim), final Record (Stop), or AII trigger (Interim) trigger.

> l | Service Data Time Limit: Time Limit reached for a specific flow. The container for this change condition will be cached by the P-GW and the container will be in an ACR Interim/Stop sent for partial record (Interim), final Record (Stop), or AII trigger (Interim) trigger.

> S5/S8 Interface Updates

> l | Updated mobility option type values for IPv4 Home Address, Address Acknowledgement, GRE Key, and Default Router options to the IANA assigned values.

> l | FTEID SGW_GTPU_INTERFACE_FOR_UL_DATA_FWD now 28.

> l | Trace info IE added in Identification Rsp.

> l | UE Timezone added in Forward Relocation Req and Context Rsp.

> l | Changes for supporting suspend/resume on S5/S8 interface.

> l | Indication IE is not 3byte. Changes include:

> l | Monitor protocol changes

> l | Encode/decode changes in indication IE

> S6b Interface Updates

> l | PGW-Relocation-Indication AVP support added for S6b to support stale session notification/deletion.

> l | Assign static IP address over S6b support.

> l | S6b interface enhanced to pass the UE Assigned IP Address.

> l | S6b updated to define the IPv6 pool name AVP, and the P-GW supports the IPv6 pool name coming from AAA. Added support for Framed-IPv6-Prefix and Framed-Interface-ID.

> Some AVPs Incorrectly Encoded in Gx Messages
> Modified the Diameter dictionary.
> Old Behavior
> “M” bit was set in some AVPs, violating the standard.
> New Behavior
> Removed the “M” bit in the following AVPs:

> l | Allocation-Retention-Priority

> l | AN-GW-Address

> l | APN-Aggregate-Max-Bitrate-DL

> l | APN-Aggregate-Max-Bitrate-UL

> l | Charging-Correlation-Indicator

> l | CoA-IP-Address

> l | CoA-Information

> l | Default-EPS-Bearer-QoS

> l | Event-Report-Indication

> l | Flow-Information

> l | Flow-Label

> l | Packet-Filter-Content

> l | Packet-Filter-Identifier

> l | Packet-Filter-Information

> l | Packet-Filter-Operation

> l | Pre-emption-Capability

> l | Pre-emption-Vulnerability

> l | Priority-Level

> l | Resource-Allocation-Notification

> l | Security-Parameter-Index

> l | Tunnel-Header-Filter

> l | Tunnel-Header-Length

> l | Tunnel-Information

> l | RAT-Type

> The diameter incoming message parsing should take care of the absence of the “M” bit in these AVPs correctly.
> Static Rules Applied Only to Default Bearers
> Old Behavior
> Static rules should be applied only to default bearers. A check for this was missed in the DCCA init routine which decides whether a sub session is online charged by checking the “charging actions” of all static rules configured in the chassis and the installed pre-defined and dynamic rules.
> New Behavior
> Now, static rules are considered only for default bearers in the DCCA init routine. For dedicated bearers, only the charging actions of the installed pre-defined rules and dynamic rules decide whether DCCA needs to be enabled.
> Supported-feature AVP in CCA from PCRF
> Unless otherwise stated, the use of the Supported-Features AVP on the Gx reference point shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point.
> The Supported Features here may have M bit set and Feature List ID and Feature List must not have “M” bit set.
> Rel 8 is mandatory feature and does not mention the AVP flags for Feature-List-ID or Feature List.
> Support for Stripping IMSI Prefix
> TS 23.003, version 9.2.0, section 19.3.2 was updated as follows:
> The NAI sent in the Mobile Node Identifier field in PMIPv6 will not include the digit prepended in front of the IMSI that is described above.
> The current HSGW includes NAI received in EAP, and P-GW also expects this digit to be present. To support removing the leading digit, mobility-option-type-value standard configuration in MAG/LMA service will be used to support S2a MN-ID. There is no behavior change for custom1 and it will continue to work as usual.
> Added HSGW support for stripping IMSI prefix.
> Completed P-GW changes to extract IMSI from NAI and handle cases when auth-mode digit is included or removed. mobility-option-type configuration is used and standard is expected to receive PBU without digit prepended.
> In both HSGW/P-GW, PBU is expected to have <IMSI>@realm where IMSI field can only be maximum of 16 digits, including auth-mode. If it is more than 16 digits, then it is decoded as invalid IMSI format and IMSI will not be extracted.
> In addition, mobility-option-type custom2 configuration has been added for this feature. The standard will continue to work as before.
> Traffic Shaping Not Supported for APN-AMBR
> P-GW does not support traffic shaping for APN-AMBR. Therefore, the keyword shape and its options have been removed from the apn-ambr CLI command in the APN Configuration Mode.
> UE Assigned Full IPv6 Address Reporting to AAA by P-GW
> The P-GW needs to report the full IPv6 address assigned to the UE only. There is no need to report the IPv4 address, if assigned to the UE. The P-GW shall use Framed-IPv6-Prefix AVP to report the IPv6 prefix and Framed-Interface-Id to report the interface identifier (IID).
> Virtual APN Selection Based on MSISDN Range and CC/RAT Type for P-GW
> Parsed CC, RAT and MSISDN from incoming EGTP session create request.
> Added EUTRAN RAT type in mapping function. Code for obtaining cc-profile from charging char IE.
> VoLTE Based E911 Support
> With this support, a UE is able to connect to an emergency PDN and make Enhanced 911 (E911) calls while providing the required location information to the Public Safety Access Point (PSAP).
> E911 is a telecommunications-based system that is designed to link people who are experiencing an emergency with the public resources that can help. This feature introduces support for E911-based calls across the LTE and IMS networks. In a voice over LTE scenario, the subscriber attaches to a dedicated packet data network (PDN) called EPDN (Emergency PDN) in order to establish a voice over IP connection to the PSAP. Signaling either happens on the default emergency bearer, or signaling and RTP media flow over separate dedicated emergency bearers. Additionally, different than normal PDN attachment that relies on AAA and PCRF components for call establishment, the EPDN attributes are configured locally on the P-GW, which eliminates the potential for emergency call failure if either of these systems is not available.
> Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are functionalities provided by the serving network when the network is configured to support emergency services. Emergency bearer services are provided to normally attached UEs and to UEs that are in a limited service state (depending on local service regulations, policies, and restrictions). Receiving emergency services in limited service state does not require a subscription.
> The standard (refer to 3GPP TS 23.401) has identified four behaviors that are supported:

> l | Valid UEs only

> l | Authenticated UEs only

> l | IMSI required, authentication optional

> l | All UEs

> To request emergency services, the UE has the following two options:

> l | UEs that are in a limited service state (due to attach reject from the network, or since no SIM is present), initiate an ATTACH indicating that the ATTACH is for receiving emergency bearer services. After a successful attach, the services that the network provides the UE is solely in the context of Emergency Bearer Services.

> l | UEs that camp normally on a cell initiates a normal ATTACH if it requires emergency services. Normal attached UEs initiated a UE Requested PDN Connectivity procedure to request Emergency Bearer Services.

> Policy and Charging Control (PCC) Support in Release 12.1
> The Policy and Charging Control (PCC) is a new product in StarOS Release 12.1.
> The Cisco® ASR 5000 Platform provides 3GPP PPC solution to network carriers in UTRAN/E-UTRAN/cdma2000-1x/HRPD networks.
> The Cisco PCC solution is based on 3GPP PCC model and standards, and intelligently extends it such as to simplify the complex and diverse requirements of policy and charging management for global operators.
> The PCC solution comprises of Policy and Charging Rules Function (PCRF), Subscriber profile repository (SPR), and other interfacing module like Policy Provisioning Tool (PPT) to implement and control the policy based subscriber access in the existing wireless network as well as service flow based credit control implementation.
> It includes the following functional entities:

> l | Intelligent Policy Control Function (IPCF)

> l | Subscriber Service Controller (SSC)

> l | Policy Provisioning Tool (PPT)

> For information about the PCC solution, see the following guides:

> l | Cisco ASR 5000 Series Intelligent Policy Control Function Administration Guide

> l | Subscriber Service Controller Installation and Administration Guide

> l | Policy Provisioning Tool Installation and Administration Guide.

> Intelligent Policy Control Function in Release 12.1
> Intelligent Policy Control Function (IPCF) provides policy control and charging rule functions in a core network.
> IPCF acts as a PCRF functions supplemented with usage monitoring capability that enables policies around data consumption. IPCF interfaces with the PCEF over standard Gx interface for policy management and optionally over
> Cisco IPCF is compliant in accordance with 3GPP standard in operator’s core network. Some of the key functions of IPCF are to:

> l | Derive and authorize the QoS information for the service data flow for session as well as bearer usage

> l | Select the appropriate charging criteria and mechanism apt for the data usage

> l | Provides network control regarding the service data flow detection and gating

> l | Ensure the PCEF user plane traffic treatment is in accordance with the user's subscription profile

> l | Correlate service and charging information across PCEF and AF

> For information about the IPCF solution, refer Cisco ASR 5000 Series Intelligent Policy Control Function Administration Guide
> Subscriber Service Controller in Release 12.1
> Subscriber Service Controller (SSC) is an application that complements and extends the functionality of Intelligent Policy Control Function (IPCF).
> SSC uses Subscriber Profile Repository (SPR) data store, to implement the usage control policies in a centralized manner. It also handles account details as well as session state information of the subscriber. SSC can manage the event notification function for PCC, by sending e-mails or text messages to subscribers. SSC provides storage facility for subscriber profile along with centralized management of subscriber policy and quota for your deployment.
> SSC works in conjunction with IPCF, PPT and other PCC components
> For information about the SSC, refer Subscriber Service Controller Installation and Administration Guide.
> Policy Provisioning Tool in Release 12.1
> Cisco Policy Provisioning Tool (PPT) is a Web-based client-server application which provides the user (network operator) a comprehensive use case design experience. It enables the network operator to design a service plan and subscriber profile data modelling at a time with the help of use case design and configuration.
> PPT is designed to simplify use case configuration by importing the relevant Policy Control Enforcement Function (PCEF) flow, rules and APN data elements.
> PCEF, typically located at the gateway is responsible for enforcing the policy and charging related decisions received from IPCF. PCEF performs service data flow detection as well as gate enforcement for the data flows.
> For information about the PPT, refer Policy Provisioning Tool Installation and Administration Guide.
> The PPT application 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 Policy Provisioning Tool Overview chapter of the Policy Provisioning Tool Installation and Administration 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.
> 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

> SCM Features in Release 12.2
> 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.
> AAA Required Only for 200 OK During Re-Invite
> During Re-Invite, AAR is required to be sent only after 200 OK. Previously, it was also sent for INV message during re-invite procedure.
> AAR Should Only be Sent for LTE Access
> A new access-profile policy has been added for pcrf-control. This will enable pcrf-policy control to be enabled per access-type.
> Unless the pcrf-policy-control is enabled for an access-type or in the default-access-profile, it will be disabled by default.
> Active/Standby Groups for AS Routing
> CLI has been added to support active/standby groups for AS Routing.
> Add Configured Domain Based on Prefix in Request-URI
> CLI route command, which specifies that a route lookup should be performed and the request URI modified, has been expanded to allow add, delete, and change options.
> Added Support for “+g.oma.sip-im”
> Added support for Accept contact feature tag “+g.oma.sip-im”.
> AS Service-type Based Routing (Accept-contact)
> During Registration, CSCF stores and manages the capability of UE. When a UE receives a call, the CSCF refers to the capability of that UE, and if the required service is not supported an error response is generated.
> CLI has been added to configure UE capability failure to accept or reject with specific response code.
> AS Triggering Based on Shared iFC
> CLI added for displaying Initial Filter Criteria (iFC) in XML format, as per 3GPP TS 29.228 Annex E.
> Authentication Flag in MAA Message
> S-CSCF does not need to check subscriber's authentication if authentication flag is set to 0 in MAA message.
> Block S-CSCF IP Going to UE in Service Route When Acting as A-BG
> This functionality has been implemented.
> Called-station-id AVP in AAR Removed
> This functionality has been implemented.
> Call Forwarding Failure
> Call forwarding failed when History-info header from AS had syntax issue. Now, S-CSCF supports reserved type ( blank, @ ) for History-Info value and forwards the INVITE with History-Info having reserved type ( blank, @ ).
> CSCF Handles Multiple Subscriptions in the Same Dialog
> This functionality has been implemented in accordance with RFC 3265, 3.1.4.2.
> CSCF Supports Multi-part ACL
> Added support for multi-part ACL. Keywords can now be entered multiple times within a single command to support multi-part ACL in CSCF in the following CLI commands (CSCF ACL Configuration Mode):

> l | deny

> l | permit

> l | redirect

> CSCF Supports REGI Management

> l | Display of Registration timestamp in show sub cscf-only full CLI output

> l | Do not validate authorization received from UE for challenge re-register

> l | Skip SAR for Re-Registration

> l | Reply 200 OK for Re-Register in case of HSS Failure.

> Custom AVP in ACR
> When new CLI is enabled, User Name AVP will be filled with Public User ID with URI Scheme in ACR message.
> Custom Feature Tags Supported
> CLI has been added to use custom tags to represent UE capabilities.
> Custom Registration Binding
> CLI command added to enable the S-CSCF to return only one binding (latest contact) for each registration without including other bindings, if any.
> Diameter Support for CDF Prefix Based Routing
> Diameter updated to support CDF prefix/capability based routing.
> Different RCS-e Tags Need to be Processed Separately
> Previously, all RCS-e tags were processed as the same tag. Now, they are processed separately and Rf feature-code AVP is sent accordingly.
> Disable IPSec Based on CLI Option
> An extra parameter has been added to the existing CLI to insert integrity-param in P-CSCF.
> Disable UAR/UAA: P-CSCF to select the S-CSCF based on destination aor routing/DNS routing.
> If new user-authorization CLI command is enabled, and I-CSCF role is enabled in S-CSCF, I-CSCF will send UAR/UAA diameter message to HSS.
> Diversion Header Customized and Support for Additional Rf AVPs
> Custom Diversion header supported.
> The following new Rf AVPs are also now supported:

> l | RF-LGUPLUS-Start-Time

> l | RF-LGUPLUS-End-Time

> l | RF-LGUPLUS-Service-Type

> l | Recipient-Code

> l | Call-Integrity

> l | AIN-Indicator

> l | Call-Forwarded-Address

> DNS Lookup Table Entries Increased to 1024
> The maximum number of entries for ip localhost CLI command has been increased from 256 to 1024.
> Domain Name in OPTION Message
> When custom volte command is enabled and hostname is configured, S-CSCF will add hostname:service-port in From header of OPTIONS request.
> Feature Parameter in the ACR for Feature Code
> Feature parameter in the ACR must include the feature code based on the P-LGTVTS-Charging-Data.
> Forking Based on CLI
> New CLI controls the default-request forking-type in S-CSCF.
> Forking Based on the P_xxx_forking_list Header
> Added changes to support Forkidlist and device id.
> Handling FQDN for CDF Address When “custom volte” Enabled
> Old Behavior
> The CDF address provided by HSS is used when no CDF matches the “prefix and capability based selection criteria”, then:

> 1 | The CDF address provided by HSS is handled as plain CDF address itself.

> 2 | CSCF supports handling of more than one CDF address, such as primary and secondary CDF.

> This was the default behavior.
> New Behavior
> The CDF address provided by HSS is used when no CDF matches the “prefix and capability based selection criteria”, then:

> 1 | The CDF address received from HSS will always be treated as a AAAGroup Name. The FQDN/IP and port part of address will be extracted and used as AAAGroup name.

> 2 | CSCF will only support one CDF address.

> This is now the default behavior.
> HSS Prefix Based Selection for LIR/LIA
> HSS prefix based selection for LIR/LIA supported.
> The keyword source has been removed from the following command in the CSCF Diameter Selection Configuration Mode.
> Previous:
> [ no ] aaa-group name criteria { source aor aor_prefix | subscriber-capability { audio [ only ] | text | video } | subscriber-ip-type { v4 | v6 } } +
> Now:
> [ no ] aaa-group name criteria { aor aor_prefix | subscriber-capability { audio [ only ] | text | video } | subscriber-ip-type { v4 | v6 } } +
> Previously, if criteria source aor <aor-prefix> was configured, fetching of aaa group name was done based on source aor. Now, fetching of aaa group name for a subscriber can be based on source aor match or destination aor match.
> HSS Prefix Based Selection Over Cx Interface
> This functionality has been implemented.
> HSS Selection CLI Modified for Easy Updating
> To support re-arrangement of prefix related configuration, preference will be associated with each diameter selection entry in the diameter selection table. The keyword preference and its options have been added to the aaa-group command in CSCF Diameter Selection Configuration Mode.
> If preference is specified, the entry matching the preference is updated.
> If preference is not specified, it is assigned a preference one greater than the last entry's preference in the diameter selection table.
> Preference is mandatory for diameter selection entry deletion.
> The preference associated with each CLI is displayed in show configuration output.
> HSS Selection Method
> New CLI configures matching criteria for selecting a AAA group name. When a subscriber registers, the selection criteria are compared and the AAA group name from the matching entry will be picked up. The selected AAA group will be used for all HSS interactions for that subscriber. Maximum of 3 criteria can be configured per entry. A maximum of 1024 such entries can be configured.
> HSS selection need not be done for Re-Register.
> I-CSCF Added Functionality
> The following features have been implemented for the I-CSCF in this build:

> l | Ability to retry Register on a second S-CSCF server based on UAR returned capabilities when the first server times out or sends an error response

> l | Congestion control

> l | License management

> ICSR Support for IMS
> ICSR is supported for the following:

> l | Basic registration

> l | Basic call

> l | Subscribe/Notify

> l | Diameter information for Rx

> l | CSCF session-related counters

> l | GRUU

> l | Subscriber statistics

> Implicit Expires Timer Configured for REGISTER
> New CLI specifies the implicit amount of time that a registration can exist on the system.
> If the implicit timer is configured and the UE time expires, then the system responds with 200OK with Expires-header set to configured implicit-expires time.
> If implicit timer is not configured, then previous logic of sending 423 response is used.
> INVITE Message to AS Modified
> When custom volte command is enabled, “TYPE 3” tag in the IOI is not sent to AS. S-CSCF adds orig-ioi parameter in P-Charging-Vector while sending towards AS in all SIP method scenarios (except REG).
> Unwanted AVPs are also removed from custom Rx dictionary.
> MegaD Enhancement for MediaType AVP in LIR and MS Status Code AVP in LIA
> MegaD now accepts in LIR Media-Type AVP:
> Media-Type: Identify Video call/Voice call, Video call(1), Voice call(0)
> In addition, system sends the following in LIA:
> MS Status code: 0(IDLE), 1(NORMAL), 2(UNREG), 3(REGISTERED), 4(POWEROFF), 5(1xBUSY), 6(VTBUSY)
> Monitor Protocol Support for RTP packets
> The following two protocols have been added to the system’s protocol monitoring utility initiated by the monitor protocol CLI command:

> l | RTP (IMS)

> l | RTCP (IMS)

> Multi-domain Support
> User may register with a domain other than the default-aor-domain.
> New AVPs for AAR Added
> For invite, the following new AVPs have been added in AAR message:

> l | AF_Applicatoin _Id

> l | calling party address

> l | called party address

> l | ROLE of Node

> New Rf-Interface AVPs Supported
> New diameter authentication custom dictionary “aaa-custom5” added for Rf interface to support the following new AVPs:

> l | Service-type

> l | Call-Forwarded-Address

> l | Recipient-Code

> l | Call-Integrity

> l | AIN-Indicator

> l | Feature-Code

> New Rx-Interface AVPs Supported
> New custom dictionary “rx-custom01” added for Rx interface to support the following new AVPs:

> l | AF_Applicatoin _Id

> l | calling party address

> l | called party address

> l | ROLE of Node

> Additional custom dictionary name changes made in Proxy-CSCF Configuration Mode.
> NPDB Support Using Multiple Client IP Addresses
> Multiple bind commands now supported for each NPDB client in CSCF NPDB Client Configuration Mode.
> Number of SiFC-IDs per Subscriber in Received SAA can be More Than 20
> Previously, S-CSCF could only support a maximum of 20 SiFC IDs per subscriber.
> Now, 48 SiFC-IDs are supported per subscriber.
> Outbound ACL Support for Handling Terminating Domain
> New aclLookUp APIs added in standalone request states in callLeg.
> P-CSCF Adds Rport Param in Hosted NAT Scenarios
> P-CSCF now adds rport param in hosted NAT scenarios.
> P-CSCF Removes the P-LGUPlus-PRID Header Towards UE
> P-CSCF removes the P-LGUPlus-PRID header received from S-CSCF while forwarding to UE.
> P-CSCF Supports Redirection of UE

> l | CSCF applies new inbound-acl criteria on incoming requests.

> l | New option added to redirect the request to other CSCFs.

> l | New parameter added to existing options to check ACL criteria for subscriber capabilities.

> P-CSCF Supports P-Profile-Key header
> If the identity of the served user of the request was taken from the P-Preferred-Identity header field by its matching a registered wildcarded public user identity and the P-CSCF supports the SIP P-Profile-Key private header extension, The P-CSCF now includes the wildcarded public user identity value in the P-Profile-Key header field, as defined in RFC 5002 [97].
> P-LGUPlus-PRID-Info Added in All Out-of-dialog Requests
> New CLI allows a custom specific header, P-LGUPlus-PRID-Info, which contains the private user id of the user sending any dialogue crating request or any standalone requests, to be added in the message toward nexthop. The addition of this custom header will be done when Proxy-CSCF forwards this message.
> Port Range Configuration Supported for Media Bridging
> New keyword v6port-range in media-bridging CLI command specifies port ranges to be used with IPv6 addresses. Only selected ports from the range specified should be used for media bridging.
> PRID Shown in subscriber cscf-only full Command Output
> Private User ID is now shown in output of CLI command show subscribers cscf-only full.
> Redirection Based on User-Agent Header Supported
> CLI has been added to support redirection based on User-Agent Header.
> Registration of Multiple Devices with Different device-type
> Registration of multiple devices with different device-type for same private userid.
> Routing Control Depending on Terminal Capability Registered
> CLI has been added to configure UE capability failure to accept or reject with specific response code.
> SBC Media Loss Detection Timer Made Configurable
> New keyword timeout in release-call-on-media-loss CLI command specifies the media loss timeout value; media loss after timeout value results in call release.
> S-CSCF Able to Send Dummy-AS 200OK Response
> If the AS which is triggered by iFC has a problem, new CLI allows configuration of the reply value for that peer AS.
> S-CSCF Adds GRUU Towards AS in P-LGUPlus-Instance-Info Header
> Fulfilled requirement to add P-LGUPlus-Instance-Info header with value of Public-GRUU generated by S-CSCF towards AS.
> S-CSCF Not Sending Message to P-CSCF After Receiving 603, 486, 415 from AS
> AS changes tag in To header for these messages. Now, S-CSCF forwards 183 responses with different To-tag.
> S-CSCF Sends P-LGUPlus-PRID-Info in REGISTER Message Sent Toward AS
> New CLI allows a custom specific header, P-LGUPlus-PRID-Info, which contains the private user id of the user sending the REGISTER request, to be added in the REGISTER message towards AS during third party registration.
> S-CSCF Subdomain Based PSI Routing
> When the Request URI in the incoming request matches the locally configured PSI, then I-CSCF must not do location query and must route the request based on the internal DNS.
> S-CSCF Support for IPv6 to IPv4 Interworking
> The following interworking scenarios have been addressed in this release:

> l | Handling 3xx responses containing Contacts with different IP versions

> l | Follow-me URIs with different IP versions

> l | Multiple peer-servers with different IP versions using hunting logic

> S-CSCF Supports P-Profile-Key header
> When the S-CSCF does not have the user profile, it initiates the S-CSCF Registration/Deregistration notification procedure, as described in 3GPP TS 29.228 [14]; with the purpose of downloading the relevant user profile and informs the HSS that the user is unregistered.
> The S-CSCF will assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When requesting the user profile the S-CSCF can include the information in the P-Profile-Key header field in the S-CSCF Registration/deregistration notification.
> Selective Interworking with Multiple MGCFs and MGCF
> New criteria added when choosing routing criteria for the CSCF service.
> Selective Interworking on AS Capability and Subscriber Prefix
> New criteria added when choosing routing criteria for the CSCF service.
> Separation of traffic to/from BGCF
> SCM now supports the separation of traffic to/from BGCF.
> Server Name AVP in MAR and SAR
> CLI command added to enable the S-CSCF to fill the server name AVP in MAR and SAR for Cx interface with configured server name.
> Session Released when RAR with Event 4 is Sent by PCRF
> Session is released when RAR with event INDICATION_OF_RELEASE_BEARER (4) is received from PCRF.
> Shared IPv6 Prefix Used for v4v6 Interworking
> Instead of using a different IPv6 prefix for each subscriber, using shared-prefix pool at VPN level. With this, first 64 bits remains the same for all the users across different session managers.
> SiFC Not Triggered When SiFC Set ID Received Without Extension
> This functionality has been implemented, as per 3GPP TS 29.228.
> SiFC ID Number Configuration in CLI Increased
> SiFC ID number configuration in CLI increased to 1 - 2,000.
> The system now stores 1,000 SiFC IDs per context; previously, it was 256.
> Support Enable/Disable of AAR for 18X Response
> CLI has been added to support enabling AAR for 180, 183 and 18X responses. If disabled, then AAR will not be sent when system gets 18X from AS or other peers.
> Support for Displaying of Connection Status to NPDB Server
> NPDB connection status shown using CLI.
> Support for Custom AVPs for MAR/MAA Over Cx Interface
> New diameter authentication custom dictionary “aaa-custom8” added.
> Support for Custom AVPs in MAR Over Cx
> The following AVPs need to be filled in MAR message before sending it on Cx Interface:

> l | SIP-Authentication-Context

> l | SIP-AOR

> l | User-Agent

> Support for Custom NPDB
> CLI has been added to support the NPDB (Number Portability Data Base) feature. NPDB is based on a client server architecture. NPDB client in S-CSCF service performs query for called subscriber number on NPDB server, which returns Routing Number for the query.
> NPDB client uses TCP connection to the NPDB server through the sessmgr and maintain a prefix table with 1,000 entries.
> Support for HSS/CDF Server when RF CEA Does Not Have Acc-App-Id
> Previously, CER/CEA received without Acct-Application-Id AVP was considered an error.
> Now, CER/CEA messages received without Acct-Application-Id are not considered an error for customer-specific Rf.
> Support for HTTP-Digest-MD5 custom auth-algorithm
> New CLI allows a custom-md5 option in authentication configuration.
> Support for LIA Based Routing Using MS Status
> LIA based on the MS Status from the LIA message. The system can route, accept, or reject-with-error-code the call based on MS Status code from LIA message.
> Support for LIR Media-Type and P-LGT-Term-Status
> LIR now fills the Media-Type AVP.
> MS-Status-AVP data is now also copied into P-LGT-Term-Status SIP header, which is added by I-CSCF and sent to terminating S-CSCF. Terminating Application server uses this P-LGT-Term-Status SIP header to execute the supplementary features.
> Support for Prefix/Capability Based CDF Selection
> New CLI is added for enabling or disabling CDF selection per access-type.
> Support for TPS Based Control Towards AS
> New CLI added to control the rate of messages going from S-CSCF to application server (AS) based on Transactions Per Second (TPS).
> Support for Triggering NOTIFY Through reg-event
> New CLI enables reg-event package at S-CSCF. System will send 501 “Not implemented” if the CLI is not enabled.
> Support PCRF Interworking with Options to Reject/Proceed Call
> This support is only for INVITE. If PCRF is enabled and PCRF server is down, REGISTER is expected to fail.
> Support Showing of IPv4/v6 Subscribers
> CLI command show subscribers enhanced.
> Sample show subscribers summary output format:
> Before:
> cscf-sip: 8
> After:
> cscf-sip: 8 cscf-sip-pcscf: 4
> cscf-sip-v4: 8 cscf-sip-scscf: 4
> cscf-sip-v6: 0 cscf-sip-rfc3261: 0
> cscf-access-wifi: 2 cscf-access-wired: 6
> cscf-access-evdo: 0 cscf-access-1xcdma: 0
> cscf-access-wcdma: 0 cscf-access-lte: 0
> cscf-access-ehrpd: 0 cscf-access-undetermined: 0
> cscf-ue-ims: 8 cscf-security-ipsec: 0
> cscf-ue-nonims: 0 cscf-security-tls: 0
> Sample show subscribers summary cscf-service <cscfservice> output format:
> Before:
> Registered subscribers : 4
> Unregistered subscribers : 0
> Access service collapsed : 0
> No. of CSCF sessions : 0
> Mobile originated calls : 0
> Mobile terminated calls : 0
> Network to network calls : 0
> After:
> Registered subscribers : 4
> Unregistered subscribers : 0
> Access service collapsed : 0
> No. of CSCF sessions : 0
> Mobile originated calls : 0
> Mobile terminated calls : 0
> Network to network calls : 0
> No of IPv4 subscribers : 4
> No of IPv6 subscribers : 0
> No of PCSCF subscribers : 4
> No of SCSCF subscribers : 0
> No of RFC3261 subscribers :0
> No of WiFi subscribers : 1
> No of Wired subscribers : 3
> No of EvDO subscribers : 0
> No of WCDMA subscribers : 0
> No of 1xCDMA subscribers : 0
> No of LTE subscribers : 0
> No of EHRPD subscribers : 0
> No of undetermined access subscribers : 0
> No of IMS subscribers : 4
> No of non-IMS subscribers: 0
> No of IPSec subscribers : 0
> No of TLS subscribers : 0
> No of Domain 192.168.145.150 subscribers : 2
> No of Domain starent.com subscribers : 2
> System Must Provide Session Management
> Session query based on the subscriber number now includes session category (type), starting time, and calling/called number.
> Tel-URI to SIP-URI Conversion
> CLI has been added to support converting a Tel-URI to SIP-URI.
> Timer C Made Configurable
> CLI has been added to support configuration of Timer C.
> ue-capability-failure - Custom Response Codes Configurable per RCS-e Tag
> Previously, all RCS-e feature tags uses a single ue-capability-failure response code. CLI has been added in route selection, hss selection, ue-capability-failure response code, and ACL configuration to support configuring response codes for each RCS-e feature tag.
> Update Calling-Party AVP in CDR with Diversion-Header for Call-Forward
> If a call is forwarded by AS and the Diversion header is included in INVITE, the header value is used as calling party of CDR.
> Updated “Service-Info-Status” AVP in AAR to Indicate 18x or 200
> CSCF has added a new indication in AAR message for 18X or 200OK.
> 3GPP “Service-Info-Status” AVP includes a new value “2” (PROVISIONAL_RESP_INDICATION_SERVICE_INFORMATION(2)) in custom dictionary rx-custom01. This indicates that the AAR was triggered for 18x response.
> Via Header Type Customer Requirements
> S-CSCF will always use IP address in Via header, regardless of bind address hostname.
> P-CSCF will use IP address towards network and hostname towards UE if configured.
> 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.
> Multiple PDN CDR Information Transmission Behavior Change
> Previous behavior: Upon receiving RAT type, ULI, and MS timezone information from the MME for an additional PDN in a multi-PDN call, the S-GW would send this information on to the P-GW even if theses parameters had not changed. Also, if these parameters were only for one of the PDNs in a multi-PDN call, they were reported as the parameters for all the PDNs.
> New behavior: The S-GW now forwards RAT type, ULI, and MS timezone only if there are changes to these parameters. If these parameters are only reported for one PDN in a multi-PDN call, they are only identified for the PDN for which they belong in the CDR.
> 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.
> IKEv2 IP Security Support on S1-U and S5 Interfaces
> IP Security (IPSec) on the S1-U and S5 interfaces 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 S-GW. The S-GW service is responsible to verify the configuration and use an IPSec API to make the S-GW listen on the service address for IKE requests.
> When configured for IPSec, the S1-U interface carries subscriber data traffic and the S5 interface carries GTP-C signaling traffic and GTP-U data traffic that flows through an IPSec tunnel.
> X.509 Certificate-based Peer Authentication
> The S-GW supports X.509 certificate-based peer authentication for IPSec tunnels.
> Serving Gateway Features in Release 12.2
> This section provides information on new Serving Gateway (S-GW) features in Release 12.2. Additional information on these features can be found in the Cisco ASR 5000 Series Serving Gateway Administration Guide.
> Downlink Data Notification Delay Timer
> A new configuration command is available to help calculate a timer that delays the sending of excess Downlink Data Notification messages by the S-GW to the MME in instances where downlink data is received before a Modify Bearer Request.
> CSFB Support
> The S-GW now forwards Suspend/Resume messages towards the P-GW as an enhancement to the Circuit Switched Fallback (CSFB) feature in compliance with 3GPP Release 9.
> The S-GW forwards Suspend Notification messages towards the P-GW to suspend downlink data for non-GBR traffic; the P-GW then drops all downlink packets. Later, when the UE finishes with CS services and moves back to E-UTRAN, the MME sends a Resume Notification message to the S-GW which forwards the message to the P-GW. The downlink data traffic then resumes.
> Emergency Session Support
> The S-GW now supports Emergency PDN handling based on 3GPP Release 9.
> GTP-U Sequence Number
> CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reordered.
> Lawful Intercept
> TCP Proxy Support
> TCP Proxy support is now available for Lawful Intercept on the S-GW. Contact your local sales representative for detailed information.
> Notification of LI Target Modification/Deletion
> The S-GW now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
> Location Reporting
> Location reporting can be used to support a variety of applications including emergency calls, lawful intercept, and charging. This feature reports both user location information (ULI) and user CSG information (UC)I.

> l | ULI data reported in GTPv2 messages includes:

> l | TAI-ID: Tracking Area Identity

> l | MCC: MNC: Mobile Country Code, Mobile Network Code

> l | TAC: Tracking Area Code

> UCI data reported in GTPv2 messages includes:

> l | MCC: MNC: Mobile Country Code, Mobile Network Code

> l | CSG-ID: Closed Subscriber Group Identifier

> l | Access Mode: CSG access mode received from the source eNodeB or RNC

> The S-GW stores the ULI and UCI, and also reports the information to the accounting framework. This may lead to generation of Gz and Rf Interim records. The S-GW also forwards the received ULI and UCI to the P-GW. If the S-GW receives the UE time zone IE from the MME, it forwards this IE towards the P-GW across the S5/S8 interface.
> Additionally, if the S-GW receives the UE timezone from S11/S4 interface, it now forwards this information to the P-GW.
> Rf/Gz Accounting Support Using Operator Policy
> The Diameter Rf interface supports offline charging (3GPP 32.240) for network services that are paid for periodically. For example, a user may have a subscription for voice calls that is paid monthly. The Rf protocol allows an IMS Charging Trigger Function (CTF) to issue offline charging events to a Charging Data Function (CDF). The charging events can either be one-time events or may be session-based.
> The S-GW supports the enabling of this Diameter interface via operator policy. Options for accounting mode include: GTPP (default), RADIUS / Diameter or None.
> 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 Release Notes available with the new releases, 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.
> 2G Attach Failure Statistics Enhanced
> The software has been modified to more accurately segregate and represent 2G attach failure rates due to internal errors vs. procedure collisions. Multiple counters have been added, and some modified, to peg specific failures due to internal errors, and to peg failures due to ongoing procedure collisions, and counters added to log total attach failures due to internal errors.
> The purpose and meaning of the ‘total-attach-failure’ counter has changed from being a combination of attach failures due to ongoing procedures and internal errors. Now the counter represents attach failures due only to internal errors.
> 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 Remapping Based on Charging Characteristics - Behavioral Change
> Previous Behavior: The original APN remapping behavior was such that if any of the subscription record had matching charging characteristics then the requested APN would be remapped to the configured APN <apn_net_id>.
> New Behavior: APN remapping behavior has been modified so that remapping occurs only when the charging characteristics value in the subscription record associated with the requested APN matches the configured value. This will avoid remapping of all APNs that the subscriber requests. This change is implemented with the new new-ni keyword of the cc command in the APN Remap Table configuration mode - explained in “Modified Commands” section of the Configuration chapter.
> APN custom33 Encoding of S-CDRs - Behavioral Change
> Previous Behavior: In the custom33 dictionary, the APN OI and NI were length encoded.
> New Behavior: In the custom33 dictionary, the APN OI and NI are dot encoded.
> 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 Profile and IMEI Range Associations - Behavioral Change
> Previous Behavior: The maximum number of APN profiles that could be associated with an operator policy was 50. The maximum number of IMEI ranges that could be associated with an operator policy was 10.
> New Behavior: The maximum number of APN profiles that can be associated with an operator policy has increased from 50 to 128. The maximum number of IMEI ranges that can be associated with an operator policy has increased from 10 to 128 IMEI ranges.
> 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 of GGSN/PGW based on Network Capability - Behavioral Change - Demo Support
> Previous Behavior: The SGSN could only select a GGSN (perform only DNS “A” queries).
> New Behavior: The SGSN can also perform a DNS “SNAPTR” type (Straightforward Name Authority Pointer) query to select a PGW if the mobile UE is Release 9 compliant.
> The Gn/Gp SGSN can now be configured to select a combined PGW/GGSN node to anchor a PDP context. During PDP context activation, after the APN is selected, normally a Gn/Gp SGSN does a DNS A/AAA query to resolve the APN into a GGSN IP address. Now, if the MS and the network are both EPC-capable, then the Gn/Gp SGSN should select a combined PGW/GGSN node to anchor the PDP context. This will enable the subscriber to roam into an EPC network without losing the PDP context.
> In order to support PGW selection for an MS that is EPC capable, an SGSN shall do a DNS SNAPTR query for APN resolution.
> If this feature is not enabled on the SGSN, the SGSN proceeds with the selection of a GGSN as usual, despite the UE ‘s network capability. Without this feature, whenever a release 9 compliant UE moves from a 2G/3G network to a 4G network, the PDP context has to be deactivated from the GGSN and a new activation towards a PGW is needed.
> With this feature enabled, the signaling load on the network side is reduced because the deactivation and activation procedure is avoided when the SGSN selects a PGW during 2G/3G activation.
> 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.
> 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.

> Configurable SCTP Receiver Window Size - Behavior Change
> It is now possible for the operator to configure a reduced priority for LinkManager Control messages, thereby giving timer messages the highest priority. The timer messages are retained at the highest priority and data messages are kept at a lower priority. As a part of this enhancement, a new parameter, sctp-init-rwnd, will enable the SCTP association to maintain a configurable window at the receiving end.
> Configurable Start for MS Authentication on First Vector
> To avoid high traffic levels during PDP establishment, the SGSN has been modified to reduce the attach time, as much as possible, so that the devices can attach and discontinue sending requests. This change is intended to reduce the time needed to retrieve vectors over the Gr interface by allowing the operator to configure the SGSN to start authentication towards the MS as soon as it receives the first vector from the AuC/HLR. With the change to the configuration, the SGSN begins the MS authentication process immediately after receiving the first vector from the HLR, while the SAI continues in parallel.
> Continue with Attach when EIR is Unreachable
> The attach process may continue in the case of an IMEI check timeout, based on the SGSN service and/or the GPRS service configuration. But the attach only proceeds if the route towards the EIR is up and the IMEI request timer expires.
> The software has been enhanced to configure the SGSN to allow the attach process to continue if the route towards the EIR is down, e.g., the DPC / SSN is out of service. This new CLI control command has been added to SGSN service and GPRS service configuration modes.
> 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”.
> custom33 Dictionary - IPv6 Support - Behavior Change
> The SGSN now supports both IPv4 or IPv6 formats for the PDP IP address field in the S-CDR using the custom33 dictionary.
> 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).
> DLCI Utilization Counters and Statistics-
> To facilitate monitoring and troubleshooting of Gb/FR E1/T1 connections, new CLI output counters have been added to measure the current and high/low watermark counters. As well, a new bulk statistics schema has been added, DLCI-Util, to monitor DLCI utilization thresholds.
> DNS-SNAPTR Config CLI Moved - Behavior Change
> Previous Behavior: The option to enable DNS SNAPTR for 3G subscribers with EPC subscription was under SGSN Global configuration.
> New Behavior: The CLI to enable DNS SNAPTR for 3G subscribers with EPC subscription has been moved to APN Profile configuration. This will enable control of this feature per APN.
> IMPORTANT: Impact on Customer: CLI configuration change required.
> 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.
> Empty SCCP Connection Requests, Support for
> The SGSN now fully supports empty SCCP Connection Requests and now adds the ability to process intra-RAU/ Detach/Service Request messages after empty CRs.
> The SCCP CR messages contain the RNC’s local reference for the particular connection at the SCCP level but not any RANAP payload. Typically, the SCCP CRs will have a max payload of 130 octets with the RANAP-Initial-UE message from the RNC as the only RANAP message in the CR. The payload of the RANAP-Initial-UE can be one of the following:

> l | Attach with IMSI/ (P-TMSI/RAI)

> l | RAU with (P-TMSI/RAI)

> l | Service Request with P-TMSI

> l | Detach Request with P-TMSI

> In situations where the payload exceeds 130 octets, the RNC may send an empty CR followed by the direct-transfer 1 (DT1) message with the actual payload.
> 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).
> GMM-SM Event Logging
> To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server. This feature logs the following events:
> • Attaches
> • Activation of PDP Context
> • RAU
> • ISRAU
> • Deactivation of PDP Context
> • Detaches
> • Authentications
> • PDP Modifications
> The new SGSN event logging feature is enabled/disabled per service with new commands.
> 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.
> Handling of CAMEL Subscribers, Configurable
> By default, the SGSN updates the CAMEL subscription included in the INSERT-SUBSCRIBER-DATA (ISD) messages received from the HLR. While processing the ATTACH request from the CAMEL subscriber, the SGSN checks whether it has a CAMEL service associated with the corresponding service (either GPRS service or SGN service). It drops the ATTACH request if there is no CAMEL service associated with a corresponding service.
> Also by default, the SGSN does not allow establishment of a Direct Tunnel (DT) for a CAMEL subscriber. It strictly validates the subscriber against the CAMEL subscription during the Direct Tunnel setup procedure.
> This enhancement makes it possible to control the behavior of the SGSN by configuring the SGSN to ignore the CAMEL subscription. This allows the SGSN to successfully complete an ATTACH procedure when there is an ATTACH Request from a CAMEL subscriber and there is no CAMEL service association in the SGSN. As well, during the Direct Tunnel establishment, validation of the CAMEL subscription is ignored to allow the DT to setup when there is no CAMEL service association in the SGSN.
> Handling Multiple MS Attaches All with the Same Random TLLI
> It is now possible to configure the SGSN to allow only one subscriber, at a time, to attach using a fixed random TLLI. While an Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other attaches sent to the SGSN with the same random TLLI, but using a different IMSI, will be dropped by the SGSN’s Linkmgr.
> A configurable timer has been implemented on the SGSN (invalidate old-TLLI timer) which will start upon the receipt of an Attach-Complete message with an old random TLLI. This timer will stop once an uplink packet (e.g., an Activation Request message) is received from the attached subscriber with the TLLI allocated by the SGSN. If no uplink packet is received by the subscriber with the TLLI allocated within the configured time (wait-time), the random TLLI mapping with that IMSI is freed and any other Attach Request with the same fixed random TLLI is accepted. No further attaches from the configured fixed-random TLLI are accepted until the timer is either stopped or has expired. In addition, to limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to control which subscribers will be provided his functionality.
> Horizontal Link Aggregation
> The SGSN now supports enhanced link aggregation (LAG) within ports on different XGLCs.
> LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs.
> The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down.
> Ignoring Excess Length of Received RANAP Messages
> On receiving RANAP messages from the RNC, the SGSN could experience a problem with PDP context establishment if the message is too long. Following a successful Attach, if the SGSN received a SCCP Connection Request with a GMM Service Request message from the RNC, the SGSN might respond with a SCCP Connection Refused for no clear reason. Further investigation revealed that at the RANAP layer the messages contained an Extension item, a Redirect Attempt Flag, and the SGSN reported a decode error while processing this additional octet.
> 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, contact your local Cisco sales representative.
> 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 low-speed:

> 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 high-speed:

> 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 high-speed and AERM/SUERM parameters are only available when SS7 link is configured for low-speed.
> 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
> Now 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.
> Nearest GGSN Selection
> 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.
> Network Initiated PDP Context Field in S-CDR - Behavioral Change
> Previous Behavior: In earlier releases, the dictionaries used by the S-CDRs included but did not implement the Network Initiated PDP Context field, hence the field was not populated.
> New Behavior: Now, all the SGSN’s 3GPP compliant dictionaries implement this field and the field will be populated in the following dictionaries: custom6, custom8, custom13, custom24. This field will be populated if the PDP context is activated by the network side or if the customer is enabling a RAU from LTE to 3G.
> Network Overload Protection - Optimized
> The SGSN’s optimized network overload protection performs attach-rate throttling to avoid overloading Gr, Gn and Gf interfaces. When enabled, the IMSIMgr throttles the attach rate to a value configured with a new set of queue-size and wait-time keywords.
> If the SGSN receives more than the configured number of attaches in a second, then the attaches are buffered in the pacing queue and requests are only dropped when the buffer overflows due to high incoming attach rate. Messages in the queue are processed (FIFO) until they age-out when the queued message's lifetime crosses the configured wait-time. The wait-time and the attach rate decide the optimal size of the queue.
> Printing Format Changed for RAI and OLD-RAI Fields - Behavioral Change
> The GMM-SM event logging feature has been enhanced so that the EDR print format is no longer fixed in length. The length is now variable. So, if the MNC has 2 digits then the RAI or OLD-RAI print format does not append a zero “0” which could cause an MNC error. During the GMM-SM event logging, the RAI and OLD-RAI fields in the EDR now have a variable length depending on the number of digits in the MNC. Based on the MNC, the length can now be 15 (xxx-xxx-xxxx-xx) or 14 (xxx-xx-xxxx-xx) characters. For example, if MNC has 2 digits “09” then the RAI or OLD_RAI prints as - xxx-09-xxxx-xx.
> 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.
> P-TMSI Signature Validation Feature
> When enabled, this feature allows the SGSN to send the Attach Reject for the Attach Request received with a P-TMSI signature mismatch message. This is done, primarily, to avoid the identification of incorrect mapping of P-TMSI/IMSI at the SGSN if the P-TMSI was allocated to a different MS. Enabling this feature allows the SGSN to validate the PTMSI signature present in the Attach Request against the PTMSI-SIGNATURE stored in the SGSN and then the SGSN sends the Attach Reject to the MS if the P-TMSI signature does not match.
> This is applicable only for 2G attaches and this configuration forces the operator to enable P-TMSI reallocation during Attach and INTER-SGSN-RAU procedures.
> 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 - Behavior 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.
> per RNC QoS Override - Behavior Change
> Previous Behavior: Previously, there was no QoS capping for R7 RNC and capping was set at 16 mbps for all pre-R7 RNC. Bit rate override was not available.
> New Behavior: Now, bit rate override is configurable per RNC. For cap rate information, refer to the release-compliance command information in the Command Line Interface Reference.
> 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.
> Supporting/non-Supporting UE for Attach and RAU - Behavior Change
> Previous Behavior: The SGSN believed the UE could be classified as supporting or non-supporting only during Attach.
> New Behavior: Now, the SGSN classifies the UE as supporting or non-supporting UE for either Attach or RAU.
> Threshold for Additional Authentication Vectors
> The software has been enhanced to allow the operator to configure a threshold indicating the minimum number of unused vectors that should be maintained by the SGSN before it initiates a SAI to refill the buffer. With this feature enabled, the SGSN will maintain a specific number of unused vectors at all times. The SAI is initiated when a vector is used up by the SGSN for authentication and the configuration threshold is hit. The SAI initiated, due to this configuration, will be ongoing in parallel to the procedures. This feature changes how many vectors are retrieved from the HLR each time and stored on the SGSN so it should increase performance by decreasing the amount of interaction with the HLR during procedures.
> Trap for non-Receipt of Reset-ACK - Behavior Change
> Previous Behavior: The SGSN was not generating traps if Reset-ACK was not received from the RNC. The SGSN was logging not having received a Reset-ACK.
> New Behavior: Now, upon expiry of all retransmission timers for reset from the SGSN, the SGSN will generate a visible trap and make a log entry when Reset-ACK is not received. The new trap is of type Notification, so there is no clear trap operation required.
> Verification of EDR GMM-SM Event Logs
> New counters have been added for 2G Modify PDP Abort and for 3G Modify Abort. The new counters facilitate verification of the EDR GMM-SM event logs.
> 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 low-speed:

> 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 high-speed:

> 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 high-speed and AERM/SUERM parameters are only available when SS7 link is configured for low-speed.
> 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.
> SGSN Features in Release 12.2
> This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.2. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
> Actions per GTT Association
> The maximum number of actions per GTT association has been increased from 8 to 15.
> APN Remapping Based on Charging Characteristics - Behavioral Change
> Previous Behavior: The original APN remapping behavior was such that if any of the subscription record had matching charging characteristics then the requested APN would be remapped to the configured APN <apn_net_id>.
> New Behavior: APN remapping behavior has been modified so that remapping occurs only when the charging characteristics value in the subscription record associated with the requested APN matches the configured value. This will avoid remapping of all APNs that the subscriber requests. This change is implemented with the new new-ni keyword of the cc command in the APN Remap Table configuration mode - explained in “Modified Commands” section of the Configuration chapter.
> BVC Reset Handling - Behavioral Change
> Previous Behavior: When a BVC was mapped to a specific cell-ID and the SGSN received a BVC Reset with a different cell-ID, then a new entry was added in the mapping for the new BVCI but the old mapping entry was not deleted. The BVCI of the subscriber was not updated until the SGSN received the next uplink packet from the MS.
> New Behavior: The SGSN maintains BVC to cell-ID mapping. When a BVC is mapped to a specific cell-ID and the SGSN receives a BVC Reset with a different cell-ID, then a new entry is added in the mapping for the new BVCI. The BVCI of the subscriber is updated and the old mapping entry is deleted.
> APN Selection of GGSN/PGW based on Network Capability - Behavioral Change
> Previous Behavior: The SGSN could only select a GGSN (perform only DNS “A” queries).
> New Behavior: The SGSN can also perform a DNS “SNAPTR” type (Straightforward Name Authority Pointer) query to select a PGW if the mobile UE is Release 9 compliant.
> The Gn/Gp SGSN can now be configured to select a combined PGW/GGSN node to anchor a PDP context. During PDP context activation, after the APN is selected, normally a Gn/Gp SGSN does a DNS A/AAA query to resolve the APN into a GGSN IP address. Now, if the MS and the network are both EPC-capable, then the Gn/Gp SGSN should select a combined PGW/GGSN node to anchor the PDP context. This will enable the subscriber to roam into an EPC network without losing the PDP context.
> In order to support PGW selection for an MS that is EPC capable, an SGSN shall do a DNS SNAPTR query for APN resolution.
> If this feature is not enabled on the SGSN, the SGSN proceeds with the selection of a GGSN as usual, despite the UE ‘s network capability. Without this feature, whenever a release 9 compliant UE moves from a 2G/3G network to a 4G network, the PDP context has to be deactivated from the GGSN and a new activation towards a PGW is needed.
> With this feature enabled, the signaling load on the network side is reduced because the deactivation and activation procedure is avoided when the SGSN selects a PGW during 2G/3G activation.
> Configurable SCTP Receiver Window Size - Behavior Change
> It is now possible for the operator to configure a reduced priority for LinkManager Control messages, thereby giving timer messages the highest priority. The timer messages are retained at the highest priority and data messages are kept at a lower priority. As a part of this enhancement, a new parameter, sctp-init-rwnd, will enable the SCTP association to maintain a configurable window at the receiving end.
> Configurable Start for MS Authentication on First Vector
> To avoid high traffic levels during PDP establishment, the SGSN has been modified to reduce the attach time, as much as possible, so that the devices can attach and discontinue sending requests. This change is intended to reduce the time needed to retrieve vectors over the Gr interface by allowing the operator to configure the SGSN to start authentication towards the MS as soon as it receives the first vector from the AuC/HLR. With the change to the configuration, the SGSN begins the MS authentication process immediately after receiving the first vector from the HLR, while the SAI continues in parallel.
> Continue with Attach when EIR is Unreachable
> The attach process may continue in the case of an IMEI check timeout, based on the SGSN service and/or the GPRS service configuration. But the attach only proceeds if the route towards the EIR is up and the IMEI request timer expires.
> The software has been enhanced to configure the SGSN to allow the attach process to continue if the route towards the EIR is down, e.g., the DPC / SSN is out of service. This new CLI control command has been added to SGSN service and GPRS service configuration modes.
> Continuous File Sequence Numbers for S-CDR
> A file sequence number is a unique number assigned to an individual CDR file. This file sequence number is stored in the aaaproxy and if the aaaproxy restarts or the chassis restarts then the sequence number used to reset. This feature prevents the file sequence number from resetting to zero and recovers the file sequence number so that the number continues to be incremented.
> The file sequence number is stored in RAM and whenever a file is transferred from RAM to the hard disk drive (HDD on the SMC), the file containing the latest sequence number is also sent to the HDD.
> custom29 Dictionary - New
> The custom29 dictionary has been implemented in compliance with 3GPP 32.215 v4.5.0 to provide standard Release 4 format for S-CDRs with all IP addresses in binary format. This implementation follows standards with the following exceptions:
> • The MSISDN field does not include the Nature of Address and Numbering Plan indicators.
> • The QoS length should be restricted to 12 bytes.
> custom33 Dictionary - IPv6 Support - Behavior Change
> The SGSN now supports both IPv4 or IPv6 formats for the PDP IP address field in the S-CDR using the custom33 dictionary.
> DLCI Utilization Counters and Statistics-
> To facilitate monitoring and troubleshooting of Gb/FR E1/T1 connections, new CLI output counters have been added to measure the current and high/low watermark counters. As well, a new bulk statistics schema has been added, DLCI-Util, to monitor DLCI utilization thresholds.
> Dual PDP Address (IPv4v6) Support for Gn/Gp
> In accordance with 3GPP TS24.008, TS23.060, and TS29.060 Release 9.0 specifications, the SGSN now honors MS/UE requests for dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix.
> It is now possible, to configure SGSN support for MS/UE requested dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix. Once support is configured for the entire SGSN, the operator has multiple configurable options to refine the level of support for dual PDP type addressing:

> l | Disable SGSN support for dual PDP type addressing.

> l | Disable support at the RNC-level for a specific RNC that either does or does not support this type of addressing.

> l | Configure the SGSN to override the MS/UE requested IPv4v6 PDP type, if SGSN does not support IPv4v6, on the basis of APN selection.

> l | Configure a default APN with a wildcard subscription with PDP type IPv4v6.

> Empty SCCP Connection Requests, Support for
> The SGSN now fully supports empty SCCP Connection Requests and now adds the ability to process intra-RAU/ Detach/Service Request messages after empty CRs.
> The SCCP CR messages contain the RNC’s local reference for the particular connection at the SCCP level but not any RANAP payload. Typically, the SCCP CRs will have a max payload of 130 octets with the RANAP-Initial-UE message from the RNC as the only RANAP message in the CR. The payload of the RANAP-Initial-UE can be one of the following:

> l | Attach with IMSI/ (P-TMSI/RAI)

> l | RAU with (P-TMSI/RAI)

> l | Service Request with P-TMSI

> l | Detach Request with P-TMSI

> In situations where the payload exceeds 130 octets, the RNC may send an empty CR followed by the direct-transfer 1 (DT1) message with the actual payload.
> GMM-SM Event Logging
> To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server. This feature logs the following events:
> • Attaches
> • Activation of PDP Context
> • RAU
> • ISRAU
> • Deactivation of PDP Context
> • Detaches
> • Authentications
> • PDP Modifications
> The new SGSN event logging feature is enabled/disabled per service with new commands.
> GTPU Filter for IuPS and SGTP Service Information - Behavioral Change
> Previous Behavior: The SGSN performed GTP protocol user plane (GTPU) path management per remote node. Paths (connection between two endpoints identified by IP addresses) were not monitored individually. In case of GTPU path failure, all PDPs associated with the remote node were deleted.
> New Behavior: By default, GTPU path management is now done per path. The SGSN tracks the PDPs towards the GGSN and the RABs towards the RNC on a per path basis. This makes it possible to list all paths towards a remote node and perform path analysis. As well, in case of path failure, only the PDP contexts and RABs associated with the failed path are affected.
> Handling of CAMEL Subscribers, Configurable
> By default, the SGSN updates the CAMEL subscription included in the INSERT-SUBSCRIBER-DATA (ISD) messages received from the HLR. While processing the ATTACH request from the CAMEL subscriber, the SGSN checks whether it has a CAMEL service associated with the corresponding service (either GPRS service or SGN service). It drops the ATTACH request if there is no CAMEL service associated with a corresponding service.
> Also by default, the SGSN does not allow establishment of a Direct Tunnel (DT) for a CAMEL subscriber. It strictly validates the subscriber against the CAMEL subscription during the Direct Tunnel setup procedure.
> This enhancement makes it possible to control the behavior of the SGSN by configuring the SGSN to ignore the CAMEL subscription. This allows the SGSN to successfully complete an ATTACH procedure when there is an ATTACH Request from a CAMEL subscriber and there is no CAMEL service association in the SGSN. As well, during the Direct Tunnel establishment, validation of the CAMEL subscription is ignored to allow the DT to setup when there is no CAMEL service association in the SGSN.
> Handling inter-SGSN/inter-system Suspend (2G) - Behavioral Change
> Previous Behavior: The SGSN only handled Suspend messages received for a known MS with a RA configured in the SGSN’s GPRS service configuration. However, the response to Suspend messages received with a 3G RA or unknown RA was to send Suspend-NAK.
> New Behavior: Upon reception of Suspend, the old SGSN suspends data transmission towards the UE and typically starts buffering of packets to ensure these packets are not sent towards the RAN node where they might be lost because the subscriber has moved to the coverage of a different SGSN. The SGSN does not initiate Paging for a suspended MS and waits for the MS to send RAU Request/Resume to resume GPRS service.
> In accordance with 3GPP TS 23.060 16.2.1.1.1, the SGSN responds to received Suspend messages in the following manner:

> l | Inter-SGSN-Suspend: the SGSN forwards inter-SGSN Suspend Request to the old SGSN (derived using the RA in the Suspend Request), and then sends Suspend-Ack upon receiving Suspend-Ack from the old SGSN.

> l | Intra-SGSN-Inter-RAT-Suspend: the SGSN sends SRNS-Ctxt-Request to the RNC upon receiving inter-system Suspend Request, and then sends Suspend-Ack upon receiving SRNS-Ctxt-Response from the RNC.

> Handling Multiple MS Attaches All with the Same Random TLLI
> It is now possible to configure the SGSN to allow only one subscriber, at a time, to attach using a fixed random TLLI. While an Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other attaches sent to the SGSN with the same random TLLI, but using a different IMSI, will be dropped by the SGSN’s Linkmgr.
> A configurable timer has been implemented on the SGSN (invalidate old-TLLI timer) which will start upon the receipt of an Attach-Complete message with an old random TLLI. This timer will stop once an uplink packet (e.g., an Activation Request message) is received from the attached subscriber with the TLLI allocated by the SGSN. If no uplink packet is received by the subscriber with the TLLI allocated within the configured time (wait-time), the random TLLI mapping with that IMSI is freed and any other Attach Request with the same fixed random TLLI is accepted. No further attaches from the configured fixed-random TLLI are accepted until the timer is either stopped or has expired. In addition, to limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to control which subscribers will be provided his functionality.
> Ignoring Excess Length of Received RANAP Messages
> On receiving RANAP messages from the RNC, the SGSN could experience a problem with PDP context establishment if the message is too long. Following a successful Attach, if the SGSN received a SCCP Connection Request with a GMM Service Request message from the RNC, the SGSN might respond with a SCCP Connection Refused for no clear reason. Further investigation revealed that at the RANAP layer the messages contained an Extension item, a Redirect Attempt Flag, and the SGSN reported a decode error while processing this additional octet.
> 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.

> Network Overload Protection - Optimized
> The SGSN’s optimized network overload protection performs attach-rate throttling to avoid overloading Gr, Gn and Gf interfaces. When enabled, the IMSIMgr throttles the attach rate to a value configured with a new set of queue-size and wait-time keywords.
> If the SGSN receives more than the configured number of attaches in a second, then the attaches are buffered in the pacing queue and requests are only dropped when the buffer overflows due to high incoming attach rate. Messages in the queue are processed (FIFO) until they age-out when the queued message's lifetime crosses the configured wait-time. The wait-time and the attach rate decide the optimal size of the queue.
> Paging for Packets Queued in the BSSGP Layer - Behavioral Change
> Previous Behavior: If an MS became unreachable or moved into Stand-by, the state of the MS was marked as ‘suspended’ in the BSSGP layer. The SGSN did not initiate Paging so packets for that MS remained in the BSSGP BVC/MS flow control queue until the SGSN received an uplink packet or a new packet for the MS from the GGSN.
> New Behavior: Now if the SGSN becomes aware that the MS moves to standby state, due to expiry of the ready timer or due to radio status, the SGSN initiates PS-Paging towards the MS. If the MS responds to the Paging, then the SGSN can resume sending queued packets without waiting for any activity from/for the MS. This results in a reduction of unnecessary queuing of data.
> Printing Format Changed for RAI and OLD-RAI Fields - Behavioral Change
> The GMM-SM event logging feature has been enhanced so that the EDR print format is no longer fixed in length. The length is now variable. So, if the MNC has 2 digits then the RAI or OLD-RAI print format does not append a zero “0” which could cause an MNC error. During the GMM-SM event logging, the RAI and OLD-RAI fields in the EDR now have a variable length depending on the number of digits in the MNC. Based on the MNC, the length can now be 15 (xxx-xxx-xxxx-xx) or 14 (xxx-xx-xxxx-xx) characters. For example, if MNC has 2 digits “09” then the RAI or OLD_RAI prints as - xxx-09-xxxx-xx.
> P-TMSI Signature Validation Feature
> When enabled, this feature allows the SGSN to send the Attach Reject for the Attach Request received with a P-TMSI signature mismatch message. This is done, primarily, to avoid the identification of incorrect mapping of P-TMSI/IMSI at the SGSN if the P-TMSI was allocated to a different MS. Enabling this feature allows the SGSN to validate the PTMSI signature present in the Attach Request against the PTMSI-SIGNATURE stored in the SGSN and then the SGSN sends the Attach Reject to the MS if the P-TMSI signature does not match.
> This is applicable only for 2G attaches and this configuration forces the operator to enable P-TMSI reallocation during Attach and INTER-SGSN-RAU procedures.
> PSC3 Card Qualified for SGSN
> The SGSN now supports the PSC3 limited to 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.
> Selective Authentication/P-TMSI Reallocation/ P-TMSI Signature Reallocation - Behavioral Change
> Previous Behavior: Subscriber event authentication, P-TMSI reallocation and P-TMSI signature reallocation were default functions.
> New Behavior: Authentication for Attach Request, Activate Request, Service Request, RAU Request, SMS Request, and Detach Request is now performed selectively and requires operator configuration to enable the functionality. Authentication and P-TMSI reallocation enabling configuration are only applicable when the SGSN’s performance of these functions is optional.
> The command structures of the subscriber event authentication, and of the P-TMSI reallocation and P-TMSI signature reallocation have been re-architected to ensure a consistent and more intuitive user experience. As a result, there are now three consistent forms for each command. The functionality is now selective and the configuration forms of the commands now enable the functionality optionally for:

> l | Every instance or every nth instance of a procedure

> l | On the basis of UMTS or GPRS or both

> l | On the basis of elapsed time intervals between events.

> The ‘no’ forms of the commands consistently disable the functionality in the configuration file. The ‘remove’ forms of the commands consistently delete the specified functionality from the call control profile configuration. As these functions are now performed selectively, according to the operator’s configuration in a call control profile, all default forms of these commands have been deprecated.
> Authentication and P-TMSI reallocation enabling configurations are only applicable when the SGSN’s performance of these functions is optional.
> There are situations in which authentication will be performed unconditionally:

> l | IMSI Attach – all IMSI attaches will be authenticated

> l | When the subscriber has not been authenticated before and the SGSN does not have a vector

> l | When there is a P-TMSI signature mismatch

> l | When there is a CKSN mismatch

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

> l | Inter SGSN Attach/RAU

> l | Inter-RAT Attach/RAU in 2G

> l | IMSI Attach

> Threshold for Additional Authentication Vectors
> The software has been enhanced to allow the operator to configure a threshold indicating the minimum number of unused vectors that should be maintained by the SGSN before it initiates a SAI to refill the buffer. With this feature enabled, the SGSN will maintain a specific number of unused vectors at all times. The SAI is initiated when a vector is used up by the SGSN for authentication and the configuration threshold is hit. The SAI initiated, due to this configuration, will be ongoing in parallel to the procedures. This feature changes how many vectors are retrieved from the HLR each time and stored on the SGSN so it should increase performance by decreasing the amount of interaction with the HLR during procedures.
> TPO Optimization on the GGSN
> To reduce the impact of handoffs on TCP flows, optimizations (traffic performance optimization – TPO) will be done at the GGSN. The GGSN needs to be made aware of handoffs before handoffs are completed to reduce the interruptions on the data plane.
> The old SGSN informs the GGSN about the start of handoff through a self-generated GTPU packet with proprietary private extensions. The GGSN does not treat this packet as an uplink packet but as an indication that handoff is going to occur. The SGSN sends a pre-handoff GTPU notification to a GGSN only if the GGSN has sent a proprietary GTPU message to inform the SGSN of the GGSN's interest in knowing about handoffs. The SGSN does not treat this GTPU message as a downlink packet.
> NOTE: This solution works ONLY between ASR 5000 SGSNs running release 12.2 and ASR 5000 GGSNs running release 12.2. This feature is configured and initiated at the GGSN.
> Unlimited Zone Code Lists - Behavioral Change
> Previous behavior: Previously, it was only possible to configure up to 10 zone code lists per Call Control Profile.
> New Behavior: The assignment of zone codes has been altered. There is no longer a limit to the number of zone code lists that can be configured per Call Control Profile because the zone code lists are now dynamically allocated based on configuration.
> The SGSN zone code lists are configured with the zone-code command in the call control profile configuration mode to create a zone code which lists one or more location areas (LACs) into which a subscriber is allowed to roam. Previously, there was a static limit of 10 zone codes configurable per call control profile. The subscriber may need more flexibility than 10 zone codes per call control profile, however, it is impossible to predict the maximum number required. So the implementation has changed from a static number of zone codes configured per call control profile to an unlimited number utilizing dynamically allocated memory for zone codes defined for call control profiles.
> Update GPRS Location (UGL) Logic Enhancements
> The handling of subscription data in the SGSN database has been modified as follows:

> l | SGSN sends a UGL on a Routing Area Update (RAU)/ Attach Request from an area which is served by a different SGSN number/MAP service/SGTP service. All fallbacks from various services are handled gracefully

> l | SGSN sends a Purge to the HLR on subscriber cleanup whenever a successful UGL is done.

> l | SGSN sends a UGL upon uplink activity after an HLR reset. Interaction with the next Attach/RAU as uplink activity should then be handled correctly

> Forcing Authentication when MS/UE Security Fails
> When GMM authentication is skipped, the SGSN and the MS continue to re-use the latest keys exchanged during the most recent GMM authentication procedure. This can result in the SGSN and the MS going out of sync with the CK and IK currently in use. If a mismatch occurs, then the security mode can timeout or be rejected because the MS will not be able to decipher or perform integrity checks on network messages. This can introduce useless signaling in the network.
> This feature allows the operator to enable a forced GMM authentication that will either resolve this type of problem or avoid it. As well, operators can configure a frequency of authentication that best meets their needs.
> 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 Cluster Software
> Previously with WEM configured as single installations, there was a Single Point of Failure (SPoF).
> Multiple WEM servers can now be configured as part of a redundant High Availability failover cluster.
> Oracle Cluster software is supported on Sun servers with the Solaris operating system.
> Symantec Veritas Cluster software is supported on both Sun servers using Solaris or RHEL operating system and Cisco UCS servers using RHEL.
> Refer to the appendices in the Cisco Web Element Manager Installation and Administration Guide for detailed configuration information.
> Support for Disabling FTP ESPV Mode in bsserver.cfg File
> WEM users now have the option to disable Extended Passive (EPSV) Mode for FTP file transfers of bulk statistic information. By default, WEM uses EPSV mode. To disable ESPV mode, set the FTP_USE_EPSV= field in the WEM server’s bsserver.cfg file to 0.
> Support for Femto Protocols in Monitor Protocol/Subscriber
> WEM now supports the monitoring of protocols and subscribers via the HNBAP and RUA Femto protocols.
> Web Element Manager Path

> l | Monitor/Test | Monitoring Operations | Monitor Protocol

> l | Monitor/Test | Monitoring Operations | Monitor Subscriber

> Chassis Name Included in License Update Message
> When a license update operation is performed in the Exec Mode Commands screen, the license update message now specifies the name of the chassis for which the license was updated.
> Web Element Manager Path
> Performance | Exec Mode Commands
> Removal of migrate.tar.gz File
> The migrate.tar.gz file, which provided files that performed WEM database backup and restore functions, has been removed as a separate .tar.gz file from the WEM installation package. Instead, the files related to WEM database and restore functionality now are extracted as individual files when the WEM installation .tar file is unzipped. The files include:

> l | ems_migrate

> l | ems_migrate.cfg

> l | README.ems_migrate

> Enhancement to WEM Installation Script on RHEL Platform
> The WEM installation script for Red Hat Linux platforms now automatically sets the core file size for the WEM installation to unlimited. This eliminates the need for users to manually set this parameter.
> To view the core file size (blocks) setting, navigate to the <ems_dir_name>/server directory on the UCS RHEL server and enter the ./serv status command.
> Solaris Patch Upgrade for U.S.Time Zone
> Users based in the United States should ensure that the timezone patch 113225-07 (or later) and libc patch 112874-33 (or later) be installed in support of extended daylight savings time (DST) support.
> In addition, if Solaris 9 is used, it must be installed using the “End User System support 64-bit” software group must be specified during the installation of the operating system. This option installs the libraries required for proper operation of the Web Element Manager.
> For United States users of Solaris 10 with a Recommended Patch Cluster dated on or after April 2011: Users with Solaris 10 should ensure that the timezone patch 138856-02 or later is installed in support of extended Daylight Savings Time (DST).
> Hide or Display Option for GUI Pull-Down Menus and Sub-Menus
> Administrators have the ability to hide or display any parent menu and submenu in the GUI as required. This allows the Admin to control what is or is not accessible to the WEM user.
> This is controlled by a flag set in the menu.xml file. This file, and an example of how to set the flag, are described in the “Configuration File” appendix in the Cisco WEM Installation and Administration Guide.
> Improved Support for Solaris Installations with New Patch Advisory
> Certain patches from Solaris had shown themselves to be unstable There are improvements in stability by installing the following new Patches, documented in the Overview section of the Web Element Manager Installation and Administration Guide:
> The following changes are suggested:
> Solaris 10 with Recommended Patch Cluster dated on or after July 16, 2007 and not later than Nov 2010. Do not install the kernel patch beyond 142900-07.
> IMPORTANT: Solaris 10 Kernel patch released between 137137-09 and 142900-04 may result in kernel panic while executing/invoking system calls. Solaris 10 Kernel patch released after 142900-07 has an issue, which will result in failure while invoking WEM Monitor subscriber and Monitor protocol screens.
> Support for Auto Discovery of New Chassis
> Previously the Auto Discovery Dialog Box did not discriminate between newly found devices and devices that had been in the database for an indeterminate amount of time, leading to administrative confusion and the possibility of duplication in the database.
> The Auto Discovery Dialog Box now supports a new feature where if a discovery is started, only chassis discovered during the latest sweep will be added to the Discovery Result area. If any device discovered during this sweep is already in the database, then a checkbox in the IMGList Added column will be checked. This will prevent the Admin trying to add it twice. If all chassis found during this search have already been added to the database, then all entries will have the checkmark and the Add to IMGList button will be disabled.
> For any newly discovered chassis without a checkmark, the Admin can add it to the database using the Add to IMGList button.
> Any chassis discovered prior to the current search and already in the database is ignored.
> The WEM path is Monitor Test Menu | Monitor Operations | Auto Discovery
> Web Element Manager Features in Release 12.2
> There following are new features for the Web Element Manager (WEM) application in Release 12.2.
> WEM, MUR, InTracer and PPT Co-Located on One Server
> Web Element Manager, MUR, PPT and InTracer software can now be co-located on a Cisco UCS server running Cisco MITG Rhel Operating System. This is documented in the MITG RHEL Application Note.
> There is a caveat that because WEM and MUR are both processor-intensive, running both on the same server is not recommended.
> Improved Support for Solaris Installations with New Patch Advisory
> Certain patches from Solaris had shown themselves to be unstable There are improvements in stability by installing the following new Patches, documented in the Overview section of the Web Element Manager Installation and Administration Guide:
> The following changes are suggested:
> Solaris 10 with Recommended Patch Cluster dated on or after July 16, 2007 and not later than November 2010. Do not install the kernel patch beyond 142900-07.
> IMPORTANT: Solaris 10 Kernel patch released between 137137-09 and 142900-04 may result in kernel panic while executing/invoking system calls. Solaris 10 Kernel patch released after 142900-07 has an issue, which will result in failure while invoking WEM Monitor Subscriber and Monitor Protocol screens.
> Superuser Password Change Required on Next Login
> If the superuser password is reset using the script ./set_superuser_password.sh, then on the next login the user is prompted to change the password as the password “superuser” is temporary and does not conform to password strength requirements. After the change, the user can login with the new password.
> For further information on ./set_superuser_password.sh configuration, please refer to the Cisco Web Element Manager Installation and Administration Guide.
> Script for Upgrading Non-Database WEM Tables in Cluster Mode
> During a WEM upgrade in cluster mode, the WEM now automatically executes a script that will upgrade all non-database WEM tables. A README file is included with the WEM installer package that provides details about the script’s functionality.
> MITG-RHEL Application Note Change
> The note concerning X-11 configuration has been removed.

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