> New Feature Summary
> This guide identifies features and functionality added or modified between software releases 7.x and 8.x. All features listed in this guide are split up according to the release that it was initially supported in.
> Additional information on the new features is available in the following documents:

> Cisco ASR 5000 Series 9.0 Release Documentation
> Document | Part Number
> Release 8.x to 9.0 Change Reference | OL-22957-01
> Product Overview Guide | OL-22937-01
> Aggregation Services Router Installation and Administration Guide | OL-22995-01
> Cisco Web Element Manager Installation and Administration Guide | OL-22945-01
> SNMP MIB Reference Manual | OL-22941-01
> AAA Interface Administration and Reference | OL-22955-01
> GTPP Storage Server Installation and Administration Guide | OL-22950-01
> Thresholding Configuration Guide | OL-22966-01
> Statistics and Counters Reference | OL-22990-01
> Command Line Interface Reference | OL-22947-01
> System Administration Guide | OL-22969-01
> Enhanced Feature Configuration Guide | OL-22982-01
> Gateway GPRS Support Node Administration Guide | OL-22943-01
> Serving GPRS Support Node Administration Guide | OL-22978-01

> Starent ST40 Series 9.0 Release Documentation
> Document | Part Number
> PDSN Administration Guide | 901-00-0003 Z
> Content Filtering Services Administration Guide | 901-00-0056 I
> Peer-to-Peer Detection Administration Guide | 901-00-0057 K
> Packet Data Interworking Function Administration Guide | 901-00-0059 J
> Personal Stateful Firewall Administration Guide | 901-00-0060 L
> ST16 Hardware Installation and Administration Buide | 901-00-0088 A

> Common Features in Release 8.0
> This section provides information on new features that are common to all products in Release 8.0.
> Configurable Transmit Timing Source
> It is now possible to configure the transmit clock source, as either Building Integrated Timing Supply (BITS) or line-timing, for application services using SDH or SONET over the Optical line card or the Channelized line card.
> BITS-timing provides the transmit timing source, using Stratum 3 compliant BITS modules resident on either the SPIO with a BITS BNC interface or the SPIO with a BITS 3-pin interface. Line-timing recovers the receive timing from an external clock source via a port on an Optical or Channelized line card. It is possible to configure both clock sources, so that one timing source backs up the other.
> To configure and manage this feature, a new CLI configuration sub-mode has been added to the Global configuration mode - the BITS Port Configuration Mode, details in the Command Line Interface Reference, includes the following new commands:
> - default
> - end
> - exit
> - mode
> - preferred slot
> - recover
> - shutdown
> - snmp trap link-status
> Configuration of this clock source is explained in Configuring Transmit Timing Source in the System Administration Guide.
> CDR PUSH Transfer Mode
> The CDR files can be pushed from the chassis to the configured external storage server periodically using the SFTP protocol. This functionality is supported both on the ST16 and ST40 platforms.
> With the PUSH transfer mode, the external storage server URL to which the CDR files need to be transferred should be specified. The configuration allows a primary and a secondary server to be configured. Configuring the secondary server is optional. Whenever a file transfer to the primary server fails for four consecutive times, the files will be transferred to the secondary server. The transfer will switch back to the original primary server when:

> l | Four consecutive transfer failures to the secondary server occur

> l | After switching from the primary server, 30 minutes elapses

> With the push transfer mode, the following can be configured:

> l | Transfer interval: A time interval, in seconds, after which the CDRs are pushed to the configured IP periodically. All the files that are completed before the PUSH timer expires are pushed.

> l | Remove file after transfer: An option to keep or remove the CDR files on the hard disk after they are transferred to the external storage server successfully.

> DHCP Service Support with MPLS Labels
> This support added to configure traffic from the specified DHCP service bind address to use the MPLS labels. This support also provides the configuration to define the next-hop gateway address.
> To configure and manage this feature, a new optional keyword nexthop-forwarding-address nexthop_ip_address with other options has been added to the bind address ip_address command in DHCP Configuration mode in the Command Line Interface Reference.
> Configuration of this support is explained in Multi Protocol Label Switching chapter in the System Enhanced Feature Configuration Guide.
> IMPORTANT: To enable this feature you need MPLS feature license on your system.
> Four-Port Gigabit Ethernet Line Card (QGLC)
> A new four port Gigabit Ethernet line card (usually referred to as the Quad Gig-E Line Card or QGLC) has been introduced for the ST40 platform only.
> Using hot-swappable small form-factor pluggable (SFP) modules, the card can support either 1000Base-SX, 1000base-LX and 1000Base-T configurations. Note that all four ports must be of one type; there can be no mix-and-matching interfaces.
> QGLCs can be installed in chassis slots 17 through 23, 26 through 39, and 42 through 48. These cards should always be installed directly behind their respective PSCs, but are not required to be placed behind any redundant PSCs (those operating in Standby mode). Cards inserted in pairs behind an active PSC offer 1:1 redundancy and automatic failover.
> It has four ports instead of one which is less expensive than having to buy more than one line card if you need more than one port. With more ports the QGLC line card increases aggregate throughput to external devices (up to 2.8 Gbps depending on call model).
> The QGLC uses a new generation of Fixed Programmable Gate Array (FPGA).The new FPGA allows the Star Channel (the 140Gbps internal bus) to be used for firmware upgrades. This dramatically improves the time it takes upgrade the card firmware for future enhancements.
> See also the “Link Aggregation” section below.
> For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
> Hard Disk Support on SMC Card in ST40 Platform
> To add storage capability a hard disk drive (HDD) has been introduced in the ST40 platform.
> When storing CDR files on the SMC HDD, at first they are stored on the RAMFS before being moved to the HDD. The files can then be off-loaded via FTP or SFTP to an external server (such as the L-ESS or the GSS) or billing system.
> When using the HDD for EDR/UDR storage, EDR/UDR files are transferred from RAMFS on the PSC card to the HDD on the SMC card. The HDD may also be used to store any data that needs to be backed up.
> The secondary SMC card also contains an HDD, which serves as a redundant and becomes active during an SMC failover. The HDD on the secondary is mirrored to the HDD on the primary in order to avoid any data loss. Basically, the drives are raid-1 redundant.
> HDD support is only available on the ST40 platform, so in the case of an “ST16” or an “ST40 without a HDD”, a card failover results in a loss of CDR files. In the case of card failover on an “ST40 with a HDD”, the new Active SMC starts pushing the files. Any files that are left in the middle of the transfer will be transferred again.
> “monitor protocol” CLI Command Option to use with HDD Configuration
> If the hard disk drive (HDD) is used for CDR storage, with the monitor protocol CLI command in the Exec Mode, the CDR option (29) must be used and not GTPP option (27).
> Link Aggregation
> Provides a means of aggregating or trunking from one to four ports on a redundant pair of Quad Gig-E line cards (QGLC) in order to guarantee a file transmission is sent serially over one link until it is finished downloading. Each PSC and its associated QGLC(s) forms a system and negotiates with an aggregation on a remote port using Link Aggregation Configuration Protocol (LACP).
> For more information see “Configuring System Options” in the System Administration Guide.
> New SNMP MIB Objects and Traps
> This release supports many new SNMP MIB objects and traps as indicated in this guide.
> New Bulk Statistics
> This release supports many new bulk statistics as indicated in this guide.
> New RADIUS Attributes
> This release supports many new RADIUS attributes as indicated in this guide.
> Configuration and Performance Parameter Enhancements
> This release includes a number of new and/or modified commands and Web Element Manager application functions. These are detailed in this guide.
> Software Patch Upgrades Not Supported
> Software Patch Upgrades are not supported in this release.
> Common Features in Release 8.1
> This section provides information on new features that are common to products in Release 8.1.
> Duplicate CDR Detection
> When AAA proxy is configured to write CDRs into the SMC hard disk, there are chances of duplicate records being written to the file if the AAA proxy crashes after writing the file to the RAM disk and before sending an ACK to AAAMgr. To prevent this, a mechanism is now in place for the AAA proxy to avoid writing duplicate records when AAAMgr retransmits the request later.
> Intelligent Packet Monitoring System (IPMS)
> The Starent Networks now provides IPMS (Intelligent Packet Monitoring System) solution for operators to analyze and investigate call related events on the Starent Networks Access Gateways (AGWs) like PDIF, PDSN, GGSN, SGSN, etc.
> The Intelligent Packet Monitoring System application provides the functions to assist operators to analyze and investigate call related events at a later point of time. When IPMS is enabled for a product, the AGW sends a copy of call control events as well as system event packets (IKE, Proxy-MIP, RADIUS, DIAMETER etc.) with some additional information to an external server for every call as part of normal system processing. The external server stores the received call control events and system event packets for later analysis.
> IMPORTANT: Initially IPMS is available for Starent Networks PDIF access gateway only.
> The IPMS client service can be enabled on AGW through ipms command in Context Configuration Mode and IPMS servers can be configured in IPMS Client Configuration Mode on an AGW. For more information on hardware and other requirements for this application support, refer IPMS Installation and Administration Guide.
> The Intelligent Packet Monitoring System solution is a separate product and must be purchased separately. Contact your designated sales or service representative.
> Domain-based L2TP Tunnel Support
> This feature enables initiation of new L2TP create tunnel request to same LNS address based on the value of attribute “Tunnel-Server-Auth-ID” in Access-Accept message received from AAA server. This value is treated as a key to identify tunnel. Thus, effectively, this result in multiple L2TP tunnels based on the value of attribute received from AAA server by a LAC. This value of attribute is treated as a key to identify tunnel.
> In earlier implementation, LAC chooses to create a new tunnel between LAC and LNS pair only when existing tunnel has reached its full capacity of allowed L2TP sessions per tunnel. There was no provision to the further segregation of the traffic between LAC and LNS.
> New CLI command tunnel selection-key { tunnel-server-auth-id | none } is added in LAC service configuration mode to support this feature. This command will provide facility to create new tunnel on the basis of value of domain attribute received from AAA server before reaching the session capacity on existing tunnels.
> IMPORTANT: Currently this support is available for GGSN only.
> Software Patch Upgrades Not Supported
> Software Patch Upgrades are not supported in this release.
> Common Features in Release 8.3
> This section provides information on new features that are common to all products in Release 8.3.
> Packet Services Card 2
> The Packet Services Card 2 (PSC2) is the next-generation packet forwarding card for the ST40. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions.
> The PSC2 has been enhanced with a faster network processor unit, featuring two quad-core Intel x86 2.5Ghz CPUs, 32 GB of RAM. The PSC2 provides 2 to 2.7 times the data throughput of the original PSC, and the switch fabric interface has been doubled.
> A second-generation data transport fixed programmable gate array (DT2 FPGA, abbreviated as DT2) connects the PSC2’s NPU bus to the switch fabric interface. The FPGA also provides a bypass path between the line card or Redundancy Crossbar Card (RCC) and the switch fabric for ATM traffic. Traffic from the line cards or the RCC is received over the FPGA’s serial links and is sent to the NPU on its switch fabric interface. The traffic destined for the line cards or RCC is diverted from the NPU interface and sent over the serial links.
> DT2 FPGA also connects to the control processors subsystem via a PCI-E bus. The PCI-E interface allows the control processors to perform register accesses to the FPGA and some components attached to it, and also allows DMA operations between the NPU and the control processors’ memory. A statistics engine is provided in the FPGA. Two reduced latency DRAM (RLDRAM) chips attached to the FPGA provide 64MB of storage for counters.
> The PSC2 has a 2.5 G/bps-based security processor that provides the highest performance for cryptographic acceleration of next-generation IP Security (IPsec), Secure Sockets Layer (SSL) and wireless LAN/WAN security applications with the latest security algorithms.
> Interoperability
> It is not recommended that PSC2s are mixed with PSCs, since this prevents the PSC2 from operating at its full potential. Due to the different processor speeds and memory configurations, the PSC2 cannot be combined in a chassis with the original PSC 16 GB.
> For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
> 10 Gigabit Ethernet Line Card
> The 10 Gigabit Ethernet Line Card is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ST40 and the packet core network, and reduces the number of physical ports needed on the ST40.
> The XGLC is a full-height line card. To install an XGLC, you must remove the half-height card guide in the rear of the chassis. Once installed, use only the upper slot number to refer to or configure the XGLC. XGLCs can be installed in chassis slots 17 through 23 and 26 through 32. These cards should always be installed directly behind their respective PSCs or PSC2s, but they are not required behind any redundant PSCs or PSC2s (those operating in Standby mode).
> The one-port XGLC supports the IEEE 802.3-2005 revision which defines full duplex operation of 10 Gigabit Ethernet.
> The XGLC use a Small Form Factor Pluggable (SPF+) module. The modules support one of two media types: 10GBASE-SR (Short Reach) 850nm, 300m over Multimode (MMF), or 10GBASE-LR (Long Reach) 1310nm, 10km over Single Mode (SMF).
> The XGLC is configured and monitored via the System Management Card (SMC) over the system’s control bus. Both SMCs must be active to maintain maximum forwarding rates.
> A feature of the higher speed line cards (XGLC and the Quad Gigabit Ethernet Line Card or QGLC), is the ability to use the Star Channel if the firmware needs to be upgraded. The Star Channel is a 2x140Gbps redundancy bus between the PSC and the line card that allows a faster download. Another way to perform a firmware upgrade is via the System Management Bus, with 1 Mbps throughput, which connects the SMC to every card in the system.
> The supported redundancy scheme for XGLC is L3, Equal Cost Multi Path (ECMP).
> For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
> ASN GW Features in Release 8.0
> This section provides information for new features in the ASN GW Service in Release 8.0.
> Currently, there are no new ASN GW features in Release 8.0.
> ASN GW Features in Release 8.1
> This section provides information for new features in the ASN GW Service.
> IMPORTANT: The features in this section are all available in Release 8.1
> Multi-host Support
> ASN GW now supports multi host feature to provide multiple host connectivity.
> The WiMAX CPE modem is used in Fixed/Nomadic application to support multiple IP hosts and it share the singles WiMAX airlink to connect to the WiMAX IP network.
> This feature is a effective solution for Small Office/Home Office (SOHO) users to provide multiple station connectivity through one airlink.
> Multi Host Support with WiMAX Network
> The WiMAX ASNGW allows each WiMAX MS (identified by its 6-byte MSID) to be assigned with a single IP address. IP accounting is maintained for the IP address.
> The ASNGW is responsible for managing the allocation and freeing of IP address, to manage the data path for it and to maintain accounting of data packets for it.
> For more information on this feature, refer to the Multi-host Support section in ASN GW Overview chapter.
> Content Filtering in Release 8.0
> This section provides information for new features in the Content Filtering product.
> Currently, there are no new Content Filtering features in Release 8.0
> Content Filtering in Release 8.1
> This section provides information for new features in the Content Filtering product.
> IMPORTANT: The new features in this section are all available in Release 8.1.
> URL Blacklisted Content Filtering
> In the URL Blacklisted Content Filtering solution, all HTTP/WAP requests from subscribers are inspected in order to determine the requested destination URLs/URIs. Each URL/URI is then matched against a database of blacklisted URLs, if there is a match, one fixed action—discard, redirect, or terminate—is taken. If the requested URL/URI is not present in the blacklist in its exact, literal form then the request is passed on as usual. This content filtering solution can either be applied to all subscribers or none. Typical cases include applying a blacklisted database of child porn URLs to all subscribers so that they are not inadvertently exposed to such content.
> For more information, see the Content Filtering Services Administration Guide.
> ECS Features in Release 8.0
> This section provides information for new features in the Enhanced Charging Service in Release 8.0.
> Group of Ruledefs Configuration Mode
> In support for grouped rule categories, a Group of Ruledefs Configuration Mode has been included within the Active Charging Service Mode. This enables grouping rules into categories, so that charging systems can base the charging policy on the category. A group of ruledefs may contain optimizable ruledefs. If all the ruledefs in a group of ruledefs can be optimized, and if the group is included in a rulebase that has optimization turned on, then the group will be optimized.
> IP Readdressing
> Readdressing of packets based on the destination IP address of the packets is now supported. This enables redirecting unknown gateway traffic to known/trusted gateways.
> The IP Readdressing is configured in the flow action defined in a charging action. IP readdressing works for traffic that matches particular ruledef and hence the charging action. IP readdressing is applicable to both uplink and downlink traffic. In the Active Charging Subsystem, uplink packets are modified after packet inspection, rule matching, etc., where the destination IP/port is determined, and replaced with the readdress IP/port just before they are sent out. Downlink packets (containing the readdressed IP/port) are modified as soon as they are received, before the packet inspection, where the source IP/port is replaced with the original server IP/port number.
> For one flow from an MS, if one packet is re-addressed, then all the packets in that flow will be re-addressed to the same server. Features like DPI, rule-matching, etc. remain unaffected. Each IP address + port combination will be defined as a ruledef.
> In case of IP fragmentation, packets with successful IP reassembly will be readdressed. However, IP fragmentation failure packets will not be re-addressed.
> Packet Filter Configuration Mode
> In support for the Network Controlled QoS (NCQoS) feature providing control of QoS for subscriber from network element side; i.e. GGSN, a Packet Filter Configuration Mode has been included within the Active Charging Service mode. This mode enables configuring a packet filter’s parameters.
> Corrected DCCA Behavior upon Receipt of Charging-Rule-Base-Name AVP
> The “Charging-Rule-Base-Name” AVP (code: 1004) is sent in CCA messages from the Gy server to set the rulebase. The rulebase that comes in this AVP must already be configured in the system. In v7.0, ACSMgr checks for the rulebase, and if it is not present discards the message, a CCR-T is not sent. In v7.1 and later, if the rulebase is not present the message is rejected, and a CCR-T is sent with DIAMETER_BAD_ANSWER as the termination cause.
> Pipelining of HTTP Requests
> ECS now supports pipelining of up to 32 HTTP requests on the same TCP connection. Pipeline overflow requests are not analyzed. Such overflow requests are treated as http-error. The billing system, based on this information, decides to charge or not charge, or refund the subscriber accordingly.
> ECS Features in Release 8.1
> This section provides information for new features in the Enhanced Charging Service in Release 8.0.
> Enhanced Charging Service in Optimized Mode
> IMPORTANT: In Release 8.1, Enhanced Charging Service must be enabled in Optimized mode.
> In the Optimized mode, ACS Managers (ACSMgrs) are merged with Session Manager (SessMgr), and enhanced charging facilities run as part of the SessMgr. Also, the controller functionality is unified, i.e. the ACS Controller (ACSCtrl) is merged with the Session Controller (SessCtrl).
> In the Optimized mode, recovery/reconciliation of ACSCtrl with ACSMgrs is coupled with SessCtrl recovery. I.e., SessCtrl handles recovery of enhanced charging specific configuration. And, reconciliation of ACSCtrl vis-à-vis SRDB tasks is added to SessCtrl reconciliation. SRDB tasks hold the third-party database, which is used for static category-based content-filtering. In Release 8.0, these SRDB tasks are handled by ACSCtrl. In Release 8.1 the SessCtrl controls these SRDB tasks.
> The Optimized mode benefits the in-line services that run as part of ECS, i.e. Firewall and Peer-to-Peer with performance improvement.
> IMPORTANT: By default, on installing Release 8.1, the system comes up with ECS in non-optimized mode. If the ECS mode is changed from the default (non-optimized) mode to the Optimized mode, or vice-versa, the system must be rebooted for the change to take effect.
> IMPORTANT: In UMTS networks, if ECS is configured in the Optimized mode, secondary PDP context traffic does not undergo ECS processing.
> EDR Generation in Flow-end and Transaction Complete Scenarios with sn-volume Fields
> In this release sn-volume-amt counters will be re-initialized only when the fields are populated in EDRs. For example, consider the following two EDR formats:
> edr-format edr1
> rule-variable http url priority 10
> attribute sn-volume-amt ip bytes uplink priority 500
> attribute sn-volume-amt ip bytes downlink priority 510
> attribute sn-volume-amt ip pkts uplink priority 520
> attribute sn-volume-amt ip pkts downlink priority 530
> attribute sn-app-protocol priority 1000
> exit
> edr-format edr2
> rule-variable http url priority 10
> attribute sn-app-protocol priority 1000
> exit
> Previously, if edr2 was generated, even though sn-volume-amt fields are not populated, sn-volume-amt counters (uplink bytes, uplink packets, downlink bytes, downlink packets) were re-initialized. So the total volume reflected by EDRs in sn-volume-amt counters was less than the actual count.
> In this release, sn-volume-amt counters will be re-initialized only if these fields are populated in the EDRs. Now, if edr2 is generated, these counters will not be re-initialized. These will be re-initialized only when edr1 is generated.
> Also, note that only those counters will be re-initialized which are populated in EDR. For example, in the following EDR format:
> edr-format edr3
> rule-variable http url priority 10
> attribute sn-volume-amt ip bytes uplink priority 500
> attribute sn-volume-amt ip bytes downlink priority 510
> attribute sn-app-protocol priority 1000
> exit
> If edr3 is generated, only uplink bytes and downlink bytes counters will be re-initialized and uplink packets and downlink packets will contain the previous values till these fields are populated (say when edr1 is generated).
> Origin-host Encoding for Optimized Mode
> The origin host encoding sent in all Diameter messages from the system in the <instance>-<facility-name>.<origin-host> format has changed.
> In the non-optimized mode, it is encoded as 001-acsmgr.starentnetworks.com.
> In the optimized mode, it is encoded as 001-sessmgr.starentnetworks.com.
> Number of TCP Connections for Optimized Mode
> The number of TCP connections established to the Diameter server has changed:

> l | In the non-optimized mode, it is a maximum of 12 PSC x 6 ACSMgrs.

> l | In the optimized mode, the number of connections will be <number of PSC> x 7 SessMgrs.

> ASR in Rel. 7 Gx Implementation Not Supported
> In the Rel. 7 Gx implementation, any Abort-Session-Request (ASR) received by the PCEF/BBERF will be treated as an unsupported command. In response, an Abort-Session-Answer (ASA) is sent with DIAMETER_COMMAND_UNSUPPORTED (3001).
> Charging Rule Definition Rejection if Precedence AVP Missing in Create Case
> In the v8.0 Rel. 7 Gx implementation, when a charging rule definition is sent from PCRF without the Precedence AVP, the default precedence value (255) is populated. Existing precedence of the rule definition changes to the default value (255) even when there is no Precedence AVP in the update.
> Now, if the Precedence AVP is missing in the new charging rule definition sent from the PCRF, the default precedence value (255) is not populated, and the charging rule definition is rejected. In the update case, if the Precedence AVP is missing, it is not updated with the default precedence value (255), and the charging rule definition is not rejected. The existing precedence is used.
> Pipelining of HTTP Requests
> ECS now supports pipelining of up to 32 HTTP requests on the same TCP connection. Pipeline overflow requests are not analyzed. Such overflow requests are treated as http-error. The billing system, based on this information, decides to charge or not charge, or refund the subscriber accordingly.
> Default IP for Unsupported Protocol
> Unsupported protocol in the flow description is considered as failure and is no longer set with IP as default protocol. In the create case, the rule definition is rejected when this failure happens. In the update case, the existing rule definition is removed when the failure happens.
> ESS Features in Release 8.0
> This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
> Currently, there are no new ESS features in Release 8.0.
> ESS Features in Release 8.1
> This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
> Support for Ignoring Insignificant UDRs
> R-ESS introduces new configurables to selectively discard the insignificant UDRS in the database based on a threshold limit in the form of number of total bytes. The statistics of the discarded UDRs will be displayed in Summary Report. Discarding the insignificant UDRs will result in the reduction of the number of records in the database and improvement of the R-ESS reporting performance.
> The R-ESS extends its support to include yet another configurable that is set accordingly to enable the collection of parsing statistics report.
> Support for Multiple Content Types
> This functionality allows the user to select multiple content types from GUI as well as CLI and enables the R-ESS to generate Threshold Content Type and/or Top N Content Type reports based on the selected types. This feature further enables the R-ESS to specify a combined threshold for the selected content types and view the list of users who have used the most amount of traffic for the content types.
> Support for Pushing of xDR Files
> The L-ESS application extends its support to include some new configurables that are set appropriately to pull the xDR files from ST-series platform and push the files to configured destinations. When this functionality is enabled, L-ESS will start the pull process and file transfer process simultaneously or separately based on the configurations. The L-ESS is configured in such a way that the files are accepted from ST-series platform and then pushed to a central location at L-ESS. The L-ESS pushes the files further to the destinations. The file transfer process will automatically detect the number of hosts and whether they are willing to push EDR / UDR files to L-ESS by detecting the directories present below the configured base path.
> Support for Forwarding SNMP Traps to Multiple Destinations
> The L-ESS extends its support to include some new parameters in the configuration file, allowing the user to configure up to a maximum of four SNMP destinations for the traps to be forwarded.
> Also, a script ‘addhosts.sh’ is modified for addition and removal of Starent and SNMP Manager hosts dynamically. This script is now menu driven and provides option for adding and removing these hosts.
> For more information, see the ESS Installation and Administration Guide.
> Firewall Features in Release 8.0
> This section provides information for new features in the Stateful Firewall product in Release 8.0.
> ACS and Stateful Firewall Integration
> The integration of Stateful Firewall and Enhanced Charging Service in this release has resulted in the following changes:

> l | Firewall Configuration Mode—This mode is no longer available.

> l | Firewall ALG Configuration Mode—This mode is no longer available.

> l | Firewall Policy Configuration Mode—This mode is no longer available.

> l | ACS Firewall Ruledef Configuration Mode—This new mode is available under the ACS Configuration mode. Firewall rule definitions are configured in this mode.

> l | Firewall Rulebase Configuration Mode—This mode is no longer available. Both ACS and Firewall ruledefs are now included in ACS rulebases.

> l | Firewall Host Pool Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS Host Pool Configuration Mode.

> l | Firewall IMSI Pool Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS IMSI Pool Configuration Mode.

> l | Firewall Port Map Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS Port Map Configuration Mode.

> Firewall Ruledef Configuration Mode
> A new Firewall Ruledef Configuration mode is available in Release 8.0 under the ACS Configuration mode. Firewall rule definitions are configured in this mode.
> Host Pool, IMSI Pool, and Port Map Support in ACS
> The Host Pool, IMSI Pool, and Port Map configuration modes, which were specific to Stateful Firewall configuration, are moved under the ACS Configuration mode for Release 8.0.
> Licensing
> With this release, if a Stateful Firewall license is installed on the system, Active Charging Services (ACS) will also be enabled. A separate ECSv2 license will not be required to enable ACS. However, if an ECSv2 license is installed on the system, a Firewall license is still required to enable Firewall.
> Firewall Features in Release 8.1
> This section provides information for new features in the Stateful Firewall product in Release 8.1.
> Network Address Translation (NAT)
> The NAT feature is used to translate non-routable private IP addresses to routable public IP address(es) from a pool of public IP addresses that have been assigned for NAT. This conserves on the number of public IP addresses required to communicate with external networks, and ensures security as the IP address scheme for the internal network is masked from external hosts, and each outgoing and incoming packet is translated. NAT can be used to perform address translation for simple-IP and mobile-IP.
> NAT can be selectively applied to different flows (5 tuple connections) originating from the subscribers based on the flows' L3/L4 characteristics (Source-IP, Source-Port, Destination-IP, Destination-Port, and Protocol). Some flows can be selectively marked for “no NAT” processing based on the flows' L3/L4 characteristics.
> NAT works by inspecting both incoming and outgoing IP datagrams and, as needed, modifying the source IP address and port number in the IP header to reflect the configured NAT address mapping for outgoing datagrams. The reverse NAT translations is done for incoming datagrams.
> In StarOS 8.1, the NAT feature is only available for UMTS networks.
> For more information, see the Personal Stateful Firewall Administration Guide.
> Policy-based Firewall and NAT Functionality
> In StarOS 8.1, Stateful Firewall releases for CDMA networks use rulebase-based configurations. Whereas, while earlier releases of Stateful Firewall and NAT for UMTS networks used rulebase-based configurations, the current releases use policy-based configurations.
> In the Policy-based Firewall and NAT implementation, Firewall-and-NAT policies are configured in the ACS Firewall-and-NAT Policy Configuration Mode. Each policy contains a set of ruledefs and the firewall/NAT configurations. Multiple such policies can be configured, however, only one policy is applied to a subscriber at any point of time.
> The policy used for a subscriber can be changed either from the CLI, or by dynamic update of policy name in Diameter and RADIUS messages. In both cases NAT status on the active call remains unchanged.
> For more information, see the Personal Stateful Firewall Administration Guide.
> Upgrading to Release 8.1
> When upgrading from a pre-8.1 release to 8.1, Firewall must be enabled in the rulebase or the Firewall-and-NAT policy as shown in the following configuration examples.
> If the build is 8.1 pre 31st July, use the following configuration:
> configure
> active-charging service <service_name>
> rulebase <acs_rulebase_name>
> ...
> firewall policy firewall-required
> ...
> exit
> If the build is 8.1 post 31st July, use the following configuration:
> configure
> active-charging service <service_name>
> fw-and-nat policy <policy_name>
> ...
> firewall policy firewall-required
> ...
> exit
> For more information, please contact your local service representative.
> GGSN Features in Release 8.0
> This section provides information for new features for the GGSN Service in Release 8.0.
> Multimedia Broadcast Multicast Service (MBMS)
> Starent Networks GGSN now supports Multimedia Broadcast and Multicast Service. The MBMS is an IP datacast type of service in GSM and UMTS cellular network. It eliminates unnecessary replication of data on UMTS wireless networks by transmitting a single stream of data to multiple users. By delivering a single, unidirectional data stream to many subscribers, MBMS makes more efficient use of wireless network resources than traditional point to point connections.
> MBMS is a solution for transferring light video and audio clips and also a suitable method for mass communications. MBMS functionality on the system is provided by an existing GGSN and/or SGSN service license. In the absence of a valid license, the system functions as a standard unicast GGSN. When a GGSN is functioning in a MBMS environment, it supports Gmb protocol interface with Broadcast/Multicast Service Center (BM-SC) for messaging.
> Figure 1-2 shows the reference architecture of MBMS service in UMTS network.
> MBMS Reference Architecture in UMTS network
> For more details on configuration of this service, refer Multimedia Broadcast and Multicast Service chapter in System Enhanced Feature Configuration Guide.
> Network Controlled QoS (NCQoS)
> This feature provides control of QoS for subscriber from network element side; i.e. GGSN. It uses bearer control mode and Active Charging Services parameters to provide packet filtering and other quality class identifier related configurations.
> Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN through Network Requested Update PDP Context (NRUPC) message. It can also activate a new secondary PDP context on Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
> This feature requires separate license key.
> For more details on configuration of this service, refer Dynamic QoS Renegotiation chapter in System Enhanced Feature Configuration Guide.
> Traffic Shaping
> This is an enhanced feature is a traffic rate limiting method similar to Traffic Policing, however, shaping provides a buffer facility for packets exceeding the configured limit. Once the packets exceed the data-rate, the packets queue inside the buffer to be delivered at a later time.
> The bandwidth enforcement can be done in the downlink and the uplink directions independently. If there is no more buffer space available for subscriber data, the system can be configured to either drop the packets or keep them for the next scheduled traffic session.
> This feature requires separate license key.
> For details on configuring this service, refer to the Traffic Policing and Shaping chapter in the System Enhanced Feature Configuration Guide.
> Direct Tunnel Support
> Direct tunnel improves the user experience (e.g. expedited web page delivery, reduced round trip delay for conversational services, etc.) by eliminating SGSN tunnel ‘switching’ latency from the user plane. An additional advantage of Direct Tunnel from an operational and capital expenditure perspective is that direct tunnel optimizes the usage of user plane resources by removing the requirement for user plane processing on the SGSN.
> The Direct Tunnel architecture allows the establishment of a direct user plane tunnel between the RAN and the GGSN, bypassing the SGSN. The SGSN continues to handle the control plane signalling and typical makes the decision to establish Direct Tunnel at PDP Context Activation. A Direct Tunnel is achieved at PDP context activation by the SGSN establishing a user plane (GTP-U) tunnel directly between RNC and GGSN (using an Update PDP Context Request towards the GGSN).
> The following figure illustrates the working of direct Tunnel between RNC and GGSN.
> Direct Tunnel Support in GGSN
> A major consequence of deploying Direct Tunnel is that it produces a significant increase in control plane load on both the SGSN and GGSN components of the packet core. It is therefore of paramount importance to a wireless operator to ensure that the deployed GGSNs are capable of handling the additional control plane loads introduced of part of Direct Tunnel deployment. The Starent GGSN and SGSN offers massive control plane transaction capabilities, ensuring system control plane capacity will not be a capacity limiting factor once Direct Tunnel is deployed.
> This feature requires separate license key.
> Highest Preference to LNS for DNS Value
> DNS query and DNS resolve procedure on system is now modified to support DNS parameters from LNS.
> The system will supports configuration of DNS at the Context level in Context configuration with ip name-server command as well as at the APN level in APN configuration mode with dns and ipv6 dns commands, or it can be received from AAA server.
> When DNS is requested in PCO configuration, the following preference will be followed for DNS value:
> 1. DNS Values received from LNS have the first preference.
> 2. DNS values received from RADIUS Server has the second preference.
> 3. DNS values locally configured at the APN level has the third preference.
> 4. DNS values configured at context level has the last preference.
> The same preference would be applicable for the NBNS servers to be negotiated via ICPC with the LNS.
> CCR (T) Sent after Receiving “Diameter-Credit-Limit-Reached” at Message Level in CCA (I) after Upgrade to v8.0
> In the earlier releases, in this scenario, the system did not send a CCR (T) with DIAMETER-ADMINISTRATIVE result-code; the system silently discarded the answer and terminated the session.
> In v8.0, the system sends a CCR (T) with DIAMETER_ADMINISTRATIVE as the result-code. System failure-handling can be set to “retry & terminate” (default) or “terminate”.
> GGSN Features in Release 8.1
> This section provides information for new features for the GGSN Service.
> Hard Disk Storage for CDR Files
> A hard disk has been introduced in the ST40 platform to add storage capability. When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see Hard Disk Support on SMC Card in ST40 Platform.

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

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

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

> NPU Assisted MBMS Data Flow
> ST40 platforms now supports NPU assisted processing of MBMS data packets and relieves the Session Manager to provide better performance. Currently with NPU assisted data processing ST40 can support 225 SGSNs per MBMS Bearer Service for downlink of MBMS data. Earlier it was limited to 15.
> This enhancement is not applicable to ST16 platforms and a maximum of 15 downlink SGSNs per MBMS Bearer service are supported.
> For details about this new enhancement, refer MBMS Service Configuration chapter of the System Enhanced Feature Configuration Guide.
> Rel. 7 Gx Interface Support
> Starent Networks GGSN now supports Rel. 7 Gx interface.
> For IMS deployment in GPRS/UMTS networks the system uses Rel. 7 Gx interface for policy-based admission control support and flow-based charging. The Rel. 7 Gx interface supports enforcing policy control features like gating, bandwidth limiting, etc., and also supports flow-based charging. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify service data flows and do charging. Other parameters associated with the rules are used to enforce policy control.
> The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/Starent Networks GGSN and the Policy and Charging Rules Function (PCRF).
> For more information see the Gx Interface Support chapter of the System Enhanced Feature Configuration Guide.
> Quad Gig-E Line Card (QGLC) & Link Aggregation
> The GGSN now supports the four-port gigabit-Ethernet line card - QGLC. This card will enable the GGSN to utilize standard-compliant link aggregation. For additional feature information, see QGLC and Link Aggregation feature descriptions in the Common Features in Release 8.0 section of this chapter.
> For details about this new line card, see the Hardware Platform Overview chapter of the Hardware Installation and Administration Guide.
> GGSN Behavior on QOS Change
> The GGSN system now drops uplink/downlink packets when SGSN sends Update PDP Context request for QOS change with maximum bit rate (MBR) as zero for conversational/streaming class of services. This is the default behavior and no configuration required.
> Secondary GTPP Group and Enable/Disable CDR Archiving
> Regulatory requirements in EU require GGSN to send CDRs to both GSS and CGF while GSS being the billing interface. CDRs sent to CGF should not be buffered and retried in the event the CGF goes down and later comes back. To support this, a secondary GTPP group can be configured under APN, and SessMgr duplicates CDRs to both GTPP groups with a CLI to enable/disable archiving in GTPP group.
> Configuring Secondary GTPP Group under the APN
> This feature enables configuring a secondary GTPP group in the APN. If the secondary group is configured, when the accounting information is generated, it will also be duplicated to the specified secondary group. This can serve as a backup of the accounting information by sending one record to a GSS server and the other to a CGF server or both to either the GSS/CGF.
> Enabling/disabling CDR Archiving in GTPP Group
> This enables/disables archiving for CGF only. When enabled, once the server is detected to be down, the request sent to the CGF is purged. Also, the requests generated for the period when the server is down is purged. If a secondary CGF is configured, new requests are directed to the secondary CGF while the requests retried with the primary are purged. By default this is disabled.
> Transport Layer Protocol Selection over Ga Interface
> Benefits
> This new support provides facility to configure the transport layer protocol for Ga interface on AGW (GSNs). Now operator can run Ga interface on TCP as well.
> Description
> Currently Ga interface between AGW and GTPP server was supported with UDP as default transport layer protocol. To provide connection-oriented session on Ga interface, new configurable feature is to select between UDP and TCP as transport layer protocol for Ga interface. For more information refer gtpp transport-layer command in GTPP Server Group Configuration Mode Commands chapter of Command Line Interface Reference.
> This feature requires no additional license.
> NSAPI Encoding in Diameter
> In the earlier releases, the GGSN was encoding ASCII format of the NSAPI in decimal format. NSAPI values of 0 to 9 were encoded in single byte, but values above 10 were encoded as 2 bytes, which lead to faulty message in the OCS.
> Now the ASCII format of the NSAPI is encoded in hexadecimal format to restrict the values to one byte.
> For example, earlier the value of 10 was encoded as 0x30 0x31 in the byte stream. Now it is encoded as 0x41 in byte stream representing the hexadecimal value A.
> GSS Features in Release 8.0
> This section provides information for new features for the GSS for Release 8.0
> Menu-Driven Installation
> Also new in this release, a menu-driven installation management interface with quick, simple menu selections for installation, uninstallation, and upgrade processes. For details, refer to the GTPP Storage Server Installation and Administration Guide.
> SGSN Support
> In Release 8.0, GTPP Storage Server (GSS) extends its support to include Serving GPRS Support Nodes (SGSNs), as well as Gateway GPRS Support Nodes (GGSNs), as sources of CDRs to be preserved and managed.
> custom4 Format
> The custom4 format was created to support writing CDRs in blocks with the FileGen utility. This file format is similar to custom3 file format except CDRs will be written in 2kbyte blocks in a file.

> l | Header: No Header

> l | Contents: CDR1CDR2FFFFFF|CDR3FFFFF..|..CDRnFFFF| where | represents the end of a 2k block

> l | EoF marker: No EoF marker

> l | File name format: <GSN_Locatio n>_<date>+<time>_<total-cdrs>_file<fileseqnum>.u

> GSS Features in Release 8.1
> This section provides information for new features for the GSS product.
> Support for New File Formats
> The GTPP Storage Server (GSS) extends its support to include the following file formats:

> l | Custom5 Format

> This file format is similar to custom3 file format except that the sequence number for CDR file name is of six digits in length ranging from 000001 to 999999.

> l | Header: No Header

> l | Contents: CDR1CDR2CDR3…CDRn

> l | EoF marker: No EoF marker

> l | File name format: <GSN_Location>_<date>+<time>_<total-cdrs>_file<fixed-length-seqnum>.u

> l | Custom7 Format

> This customer-specific file format contains CDRs converted from ASN.1 format to ASCII format according to the following conventions. Each line in the file consists of one CDR which contains 33 parameters occupying 491 bytes.

> l | Header: No Header

> l | Contents: CDR1CDR2CDR3…CDRn

> l | EoF marker: No EoF marker

> l | File name format: Processed_04_YYYYMMDDhhmmss.cdr

> IMPORTANT: The custom7 file format is customer-specific. For more information on this file format, contact your local sales representative.
> Archive Mode Functionality
> In this release, the archive mode functionality is enabled by default during GSS installation without requiring user’s input. The default activation is due to the removal of support for non-archive mode.
> Support for GTPP Custom Dictionary
> In this release, the GTPP Storage Server (GSS) extends its support to include custom12 through custom20 in the GTPP custom dictionaries.
> HA Features in Release 8.0
> This section provides information for new features in the Home Agent product in Release 8.0.
> Mobile IPv6
> Benefits
> Enables use of single mobility core network for provisioning of IPv6 and IPv4 Mobile IP access services. Mitigates IPv4 address depletion concerns for address intensive always-on applications and interactive applications such as VoIP, video telephony and Push-to-Talk (PTT).
> Description
> MIPv6 allows a user to maintain a persistent IPv6 address even when handing off between Access Service Networks (ASN's) connected to different ASN GW's and allows the access device to be reachable via the same MIPv6 Home of Address (HoA) irrespective of the current point of attachment. A Mobile IPv6 Node (MN) uses two IPv6 addresses:

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

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

> The MN can operate in two modes:

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

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

> Supported Features

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

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

> l | Native 6-in-6 tunneling between ST40 ASN GW and HA's

> l | Session-based 6TO4 tunneling between ST40 HA and ST16 ASN GW

> l | Platform-based 6TO4 tunneling between ST40 HA and adjacent 6BONE gateway routers

> Session Continuity Support for 3GPP2 and WiMAX Handoffs
> From Release 7.1, this feature provides the seamless session mobility for WiMAX subscriber and other access technology subscribers; i.e. 3GPP2. By implementation of this feature HA can be configured for:

> l | 3GPP2 HA Service

> l | 3GPP HA Service

> l | WiMAX HA Service

> l | Combination of 3GPP2 and WiMAX HA Service

> The above configurations provide the session continuity capability that enables a dual mode device (a multi radio device) to continue its active data session as it changes its active network attachment from 3GPP2 to Wimax and vice versa with no perceived user impacts from a user experience perspective. This capability brings the following benefits:

> l | common billing and customer care

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

> l | better user experience with seamless session continuity

> This feature requires a separate license to enable WiMAX service.
> HA Features in Release 8.1
> This section provides information for new features in the Home Agent product.
> Currently, there are no new HA features in Release 8.1.
> IP Services Gateway Features in Release 8.0
> This section provides information for new features in the IP Services Gateway product.
> Currently, there are no new IPSG features in Release 8.0.
> IP Services Gateway Features in Release 8.1
> This section provides information for new features in the IP Services Gateway.
> Currently, there are no new IPSG features in Release 8.1.
> PDIF Features in Release 8.0
> PDIF is not supported in Release 8.0.
> PDIF Features in Release 8.1
> This section provides information for new features in the Packet Data Interworking Function.
> Congestion Control and Overload Disconnect Support
> Beginning with the 8.1 release of 01/01/09, PDIF supports congestion control and overload disconnect.
> Refer to the “Congestion Control” chapter in the PDIF Administration Guide, and to the Command Line Interface Reference Guide for more configuration information
> Custom DNS Handling
> New CLI added to Crypto Template Config Mode: dns-handling { normal | custom }
> During IKEv2 session setup, MS may or may not include INTERNAL_IP4_DNS in the Config Payload (CP). PDIF may obtain one or more DNS addresses for the subscriber in DNS NVSE from a proxy-MIP Registration Reply message. If Multiple Authentication is used, these DNS addresses may be also received in Diameter AVPs during the first authentication phase, or in RADIUS attributes in the Access Accept messages during the second authentication phase.
> In normal mode, by default PDIF always returns the DNS address in the config payload in the second authentication phase if one is received from either the configuration or the HA.
> Custom mode is a new feature added to the CLI for this release to provide an alternative to the default operation. In custom mode, depending on the number of INTERNAL_IP4_DNS, PDIF supports the variety of behaviors described in the custom-dns handling section in the “Crypto Template Configuration Mode Commands” chapter of the CLI Reference Guide.
> DELETE Payload Default Action Change
> The IKEv2 stack currently always inserts a DELETE Payload in an INFORMATIONAL DELETE Response from both the PDIF and the MN (WMN).
> This default behavior has been updated to not insert a DELETE Payload when the response is from the PDIF.
> Note that this behavior is supported by clarifications in RFC 4718.
> IPMS Support
> IPMS is a licensed feature for PDIF. It provides access to more saved reporting and analysis information. It supports MIBs as they are developed and bulkstats. It must be configured in its own context.
> IPMS is described in detail in its own documentation suite, including online help files.
> Multiple Authentication
> Multiple Authentication is used when setting up a Proxy-Mobile-IP call with PDIF. In Stage One the device is authenticated with an HSS server. In Stage Two, the subscriber is authenticated with a AAA server over a RADIUS interface.
> In Stage One, the authentication method must be EAP-AKA. In Stage Two, the authentication must be either MD5 or GTC. If neither MD5 nor GTC is supported, the PDIF can convert these authentication messages and use standard PAP/CHAP authentication instead.
> This is fully described in the “PDIF Overview” chapter in the PDIF Administration Guide.
> Online Upgrade
> PDIF is now using an online upgrade model called Active-Standby. This requires a license to activate. Two chassis are connected by a redundancy link and Service Redundancy Protocol (SRP) is used over the link to monitor and control chassis state. Both active and standby chassis have SRP-Activated resources defined. Loopback interfaces are used in the example in the Admin Guide.
> "SRP-Activated" means that the resource is configured with srp-activate to make the protocol work between the two chassis. These resources are the same between the Active and Standby PDIF. Loop-back IP addresses in Ingress and Egress contexts and IP pools in egress contexts are usually SRP-Activated resources. Only the active chassis enables the SRP-Activated resources.
> Online upgrade is discussed in the PDIF Administration Guide.
> SRP and other required commands are documented in the Command Line Interface Reference.
> Public and Private Key Mismatch Check
> PDIF supports x.509 certificates. Every certificate has a public key of its own and configuration on a PDIF is done with the public key and a private key. A mechanism has now been added to verify the AUTH payload from PDIF using PDIF’s public key. If there is a mis-match in the keys, you now see the following warning:
> Failure: Public and Private key given for certificate does not match!
> Session Recovery
> Session Recovery is now a licensed feature for PDIF. It is described in the “PDIF Session Recovery” chapter of the Enhanced Features Guide and is also described in the PDIF Admin Guide.
> It is activated by the CLI require session recovery in the Global Config mode.
> PDIF Features in Release 8.3
> This section provides information about new features in the Packet Data Interworking Function.
> Multiple IPSec Traffic Selectors
> Beginning with Release 8.3, the PDIF supports multiple IPsec traffic selectors.
> The PDIF can be configured with multiple IPsec traffic classes, each containing up to 128 traffic selectors, which are used during traffic selector negotiation with UEs. Multiple traffic selectors allow the PDIF to direct outbound traffic to selected IP addresses based on the following protocols: IP, TCP, UDP, and ICMP. The PDIF can also direct TCP and UDP traffic to selected IP addresses and port ranges.
> For more information, see the chapters “Packet Data Interworking Function Overview” and “Configuration” in the PDIF Administration Guide.
> Selective Diameter Profile Update Request Control
> Beginning with Release 8.3, the PDIF includes a selective Diameter Profile Update Request Control feature. For mobile IP calls, this feature allows WiFi data-only sessions to co-exist with VoIP sessions on the PDIF platform.
> This feature is used to identify which subscriber sessions need to have the PDIF and the HSS exchange Diameter Profile Update Request (PUR) and Profile Update Answer (PUA) messages, and allows the PDIF to handle the call setup for a data-only client without having to interact with the HSS.
> This feature is enabled by default and requires no configuration.
> For more information, see the chapter “Packet Data Interworking Function Overview” in the PDIF Administration Guide.
> PDSN Features in Release 8.0
> This section provides information for new features in the Packet Data Serving Node in Release 8.0.
> Traffic Shaping
> This is an enhanced feature for the 8.0 release and is a traffic rate limiting method similar to the Traffic Policing, but it provides a buffer facility for packets exceeded the configured limit. Once the packet exceeds the data-rate, the packet queued inside the buffer to be delivered at a later time. Requires separate license key.
> The bandwidth enforcement can be done in the downlink and the uplink direction independently. If there is no more buffer space available for subscriber data system can be configured to either drop the packets or kept for the next scheduled traffic session.
> For more details on configuration of this service, refer Traffic Policing and Shaping chapter in System Enhanced Feature Configuration Guide.
> PDSN Features in Release 8.1
> This section provides information for new features in the Packet Data Serving Node product.
> Currently, there are no new PDSN features in Release 8.1.
> Peer-to-Peer Features in Release 8.0
> This section provides information for new features for the inline Peer-to-Peer support.
> Currently, there are no new P2P features in Release 8.0.
> Peer-to-Peer Features in Release 8.1
> This section provides information for new features for the inline Peer-to-Peer support.
> IMPORTANT: The P2P features in this section are all available in Release 8.1 only.
> P2P Protocols supported for detection
> With release 8.1, the system supports detection of the following P2P protocols:

> l | aol

> IMPORTANT: The AOL protocol is detected as Oscar.

> l | applejuice

> l | ares

> l | ddlink

> l | directconnect

> l | feidian

> l | filetopia

> l | fring

> l | gadu_gadu

> l | halflife2

> l | hamachivpn

> l | imesh

> l | irc

> l | iskoot

> l | manolito

> l | mute

> l | oscar

> l | pando

> l | popo

> l | pplive

> l | ppstream

> l | qq

> l | qqlive

> l | skinny

> l | sopcast

> l | soulseek

> l | steam

> l | tvants

> l | tvuplayer

> l | uusee

> l | vpnx

> l | vtun

> l | winmx

> l | wofwarcraft

> l | xbox

> l | zattoo

> SGSN Features in Release 8.0
> This section provides information for new features (listed alphabetically) in Release 8.0 for the Serving GPRS Support Node (SGSN). Additional information on these features can be found in the SGSN Overview section of the Product Overview, in the SGSN Administration Guide, and in the CLI Reference Guide.
> Limits / Engineering Rules
> The following limits for releases 8.0, 8.1, and 9.0 have been modified in the Engineer Rules appendix of the SGSN Administration Guide.

> l | 2G Gb over FR Intf: Max NSEs controlling the same RA increased from 16 to 64

> l | 2G Gb over IP Intf: Max NSEs controlling the same RA increased from 16 to 64

> l | Connection Rules:

> l | Max # of logically connected GGSNs per Gn/Gp intf increased from 20,000 to “no limit”

> l | Max # of packets buffered -- rules have been clarified: - Minimum of 2KB/subscriber. - Maximum of 10KB/subscriber -- if buffers are available in the shared pool*. (*SGSN provides a buffer pool of 10M per session manager - buffer to be shared by all subscribers “belonging” to that session manager.)

> l | SIGTRAN: Max number of peer servers per SS7RD increased from 144 to 256.

> Correction:

> l | Max# of RNCs per 3G intf: corrected from 1024 to 256.

> 1-in-N IMEI Checks for Subscriber Events
> The IMEI check procedure is performed to avoid fraudulent usage of mobile equipment. At attach, when a subscriber registers with an SGSN, the SGSN retrieves the MS equipment identity and then sends a “Check_IMEI” request to the EIR.
> The EIR maintains a database of all equipment. The database is organized in three lists – white, gray, and black lists. The EIR checks the three lists to determine on which list the MS’ equipment identity belongs. Then the EIR returns the status request back to the SGSN with the list information.

> l | If the equipment status is black-listed, the SGSN does not allow the mobile to register with the SGSN.

> l | If the equipment status is white-listed, the SGSN proceeds with the registration.

> l | If the equipment status is gray-listed, the default handling is to allow the registration, which can be overridden via the SGSN CLI.

> The number of IMEI checks is configured with the check-imei-every-n-events keyword of the equipment-identity-register command in the MAP Service configuration mode. The feature is enabled with the verify-equipment-identity keyword of the gmm retrieve-equipment-identity imei command in the SGSN Operator Policy configuration mode. See the appropriate configuration mode chapters in the CLI Reference Guide for details.
> 1-in-N Selective Authentication of Subscriber Events
> The SGSN Operator Policy now provides a mechanism to configure selective re-authentication and / or P-TMSI re-allocation for 3G events, where an event is one of the following: an attach request, a RAU, a service request, an activate primary PDP context request, a detach request. The N frequency range is 1 to 16. Configuration means that N minus 1 events are skipped before authentication occurs. For configuration details, see the authenticate command in the SGSN Operator Policy Configuration Mode chapter of the CLI Reference Guide.
> 2.5G/3G Dual Access
> Within the same chassis, the SGSN can simultaneously operate as both a 2.5G SGSN and a 3G SGSN. This co-location has been done without proprietary protocols thus avoiding problems with mobility and handoff. Dual access provides a range of benefits, such as: use of the same hardware, load sharing, and the need for fewer IP addresses.
> Attach Rate Throttle
> It is unlikely that the SGSN would become a bottleneck because of the SGSN’s high signaling rates. However, other nodes in the network may not scale commensurately. To provide network overload protection, the SGSN provides a mechanism to control the number of attaches occurring through it on a per second basis.
> Fractional E1/DS1 Support
> The SGSN, using the Channelized Line Cards, now supports fractional E1/DS1 with up to 8 configurable groupings of timeslots per port. This feature is configured with a combination of the path and frame-relay commands in the Channelized Port Configuration Mode chapters of the CLI Reference Guide.
> Disable Signaling Indication IE in RANAP messages
> In accordance with RANAP standards, the Signaling Indication IE is only included in RANAP messages RANAP (RAB Assignment Request and/or the Relocation Request messages) when the traffic class is "interactive".
> The Command Line Interface (CLI) has been modified to enable the operator to control whether the IE is included if both of the following conditions are met:
> 1. When the traffic class is "interactive".
> 2. Signaling Indication IE is included in the current QoS and the value is optimized (value of "1").
> New CLI commands have been added to the Radio-Network-Controller configuration mode to govern the inclusion of the Signaling Indication IE in RANAP messages. Refer to the Command Line Interface Reference for information on enabling/disabling this feature.
> Ga Interface to the CGF/GSS
> The SGSN now supports the Ga interface to the CGF for accounting purposes. The SGSN uses the Ga interface to communicate with the charging gateway function (CGF) or the GTPP Storage Server (GSS) using GTP Prime (GTPP). The charging gateway is responsible for buffering and pre-processing billing records. One or more Ga interfaces can be configured per system context. This interface is supported through the following commands in the Context configuration Mode:

> l | gtpp charging-agent address

> l | gtpp duplicate-hold-time minutes

> l | gtpp echo-interval

> l | gtpp max-cdrs

> l | gtpp max-pdu-size

> l | gtpp max-retries

> l | gtpp redirection-allowed

> l | gtpp server

> l | gtpp storage-server

> l | gtpp timeout

> Gb-Flex - SGSN Pooling
> The SGSN, with its high capacity, signaling performance, and peering capabilities combined with its level of fault tolerance, delivers many of the benefits of Flex functionary even without deploying SGSN pooling.
> As defined by 3GPP TS 23.236, the SGSN implements Gb-Flex functionality to ensure SGSN pooling for 2.5G accesses as both separate pools and as dual-access pools. SGSN pooling enables the following:

> l | Eliminates the single point of failure between a BSS and an SGSN.

> l | Ensures geographical redundancy, as a pool can be distributed across sites.

> l | Minimizes subscriber impact during service, maintenance, or node additions or replacements.

> l | Increases overall capacity via load sharing across the SGSNs in a pool.

> l | Reduces the need/frequency for inter-SGSN RAUs. This substantially reduces signaling load and data transfer delays.

> l | Supports load redistribution with the SGSN off loading procedure.

> Gs Interface to the MSC/VLR
> In Release 8.0, the SGSN now supports the Gs interface to the MSC/VLR. This interface is vital in the call-setup process as these databases provide authentication information about MS/UEs attempting to attach.
> The Gs Service Configuration Mode has been added to configure and manage the Gs interface between the SGSN and the MSC/VLR. This new mode includes the following commands:
> - associate-sccp-network
> - bssap+
> - default
> - end
> - exit
> - max-retransmission
> - non-pool-area
> - pool-area
> - timeout
> - vlr
> The new commands will be found the chapter titled Gs Service Configuration Mode Commands in the Command Line Interface Reference.
> Limiting Iu Connections in RANAP Messages
> A new command has been created to enable the operator to further control message length by configuring the number of IuConIDs sent in each SGSN Init Reset Resource message.
> This change will have no impact on current or future configurations as the previously coded system value was 250.
> Refer to the RNC Configuration Mode chapter of the Command Line Interface Reference for additional information.
> Local QoS Capping
> The operator can configure a cap or limit for the QoS bit rate.
> The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
> Depending upon the keywords included in the command, the SGSN can: take the QoS parameter configuration from the HLR configuration. take the QoS parameter configuration from the local settings for use in the APN policy. during session establishment, apply the lower of either the HLR subscription or the locally configured values.
> Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
> Network-Initiated PDP Context Activation
> SGSN now supports standards compliant network-initiated PDP context activation. The network, or actually the GGSN, is not actually initiating the PDP context activation - it is requesting the MS/UE to activate the PDP context.
> QoS Traffic Policing per Subscriber
> The SGSN now offers QoS traffic policing which enables the operator to configure and enforce bandwidth limitations on individual PDP contexts of a particular traffic class. Traffic policing typically deals with eliminating bursts of traffic and managing a traffic flow in order to comply with a traffic contract.
> The SGSN conforms to the DiffServ model for QoS by handling the 3GPP defined classes of traffic, QoS negotiation, DSCP marking, traffic policing, and support for HSDPA/HSUPA.
> The SGSN can police uplink and downlink traffic according to predefined QoS negotiated limits fixed on the basis of individual contexts - either primary or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698) algorithm for traffic policing.
> For more information, see the SGSN Overview in the Product Overview and the Traffic Policing and Shaping and Dynamic QoS Renegotiation chapter in System Enhanced Feature Configuration Guide.
> Session Recovery Support
> The session recovery feature, now available for both 2G and 3G SGSNs, handles SGSN services for all attached and/or activated subscribers. When enabled, session recovery provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
> This is an enhanced feature and requires a separate license key to be enabled with the SGSN service. For more information on session recovery, refer to the System Enhanced Feature Configuration Guide.
> Short Message Service - SMS
> The SGSN implements a configurable short message service (SMS) to send and receive text messages up to 140 octets in length. The SGSN handles multiple, simultaneous messages of both types: those sent from the MS/UE (SMS-MO: mobile originating) and those sent to the MS/UE (SMS-MT: mobile terminating).
> After verifying a subscription for the PLMN’s SMS service, the SGSN connects with the SMSC (short message service center), via a Gd interface, to relay received messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward. In the reverse, the SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and checks the subscriber state before relaying them to the target MS/UE. The SGSN will employ both the Page procedure and MNRG (mobile not reachable for GPRS) flags in an attempt to deliver messages to subscribers that are absent.
> The SGSN supports both charging for SMS messages (MO - mobile originating and MT - mobile terminating) and lawful intercept of SMS-MO and SMS-MT messages.
> Configuration for the service is explained in the SGSN Administration Guide. The various CLI used to enable and configure the SMS service are defined in the Command Line Interface Reference.
> CLI

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

> [cntxt_name]st40(config-map-service-serv_name)# short-message-service
> [cntxt_name]st40(config-map-service-serv_name-sms-service)#
> HSPA Fallback (aka Data Rate Management per RNC)
> Benefits
> Configurable control of data rates on a per RNC basis enables operators to allow subscribers to roam in and out of coverages areas with different QoS levels.
> Description
> The SGSN can now limit data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot support higher data rates - such as those enabled by HSPA+ (theoretically, up to 256 Mbps both downlink and uplink). Being able to specify the QoS individually for each RNC makes it possible for operators to allow their subscribers to move in-and-out of coverage areas with different QoS levels, such as those based on 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+).
> For example, when a PDP established on an RNC with 21 Mbps is handed off to an RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated to 16 Mbps. Note that an MS/UE may choose to drop the PDP during the QoS renegotiation to a lower value.
> This data rate management per RNC functionality is enabled, in the RNC configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rate or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode chapter in the Command Line Interface Reference (version 8.x).
> Tracking Usage of GPRS Encryption Algorithm
> Usage of the GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity depending upon the GEAx level used - GEA1, GEA2, or GEA3.
> Operators could use a mechanism that would enable them to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool would also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity to exceed.
> Enhanced counters should display the absolute number of attached subscribers using each of the GEA algorithms.
> Counters have been added to the output of the show sub gprs-only summary CLI command to track:

> l | the number of subscribers capable of GEA0-GEO3, and

> l | the number of subscribers with negotiated GEAx levels.

> New counters display the number of subscribers whose MS network capability supports GEA0/- GEA1/GEA2/GEA3. Similarly, the new counters under "Negotiated" indicate the number of subscribers who have negotiated with the SGSN to use a specific encryption algorithm according to the ciphering priority configuration and the network capability.
> Sample Output:
> [local]bngnc3# show sub gprs-only sum
> Total Subscribers : 2 Total Ready Subscribers : 0
> Total Detached Subscribers : 1 Total Standby Subscribers : 1
> Total Suspended Subscribers : 0
> Total subscribers with encryption algorithm
> Capability : Negotiated :
> GEA0 : 1 GEA0 : 1
> GEA1 : 0 GEA1 : 0
> GEA2 : 0 GEA2 : 0
> GEA3 : 1 GEA3 : 0
> Total Active Subscribers : 0 Total PDP contexts : 0
> pdp-type-ipv4 : 0 pdp-type-ppp : 0
> pdp-type-ipv6 : 0
> .
> .
> SGSN Behavior - Modified for Release 8.0
> NSE related limits, which are not configurable, have been modified for release 8.0 only:

> l | Number of NSEs was 1024, now is 256

> l | Number of local NSVLs was 4, now is 4

> l | Number of peer NSVLs per NSE was 16, now is 64

> l | Number of NSVCs per IP-NSE was 64, now is 256

> l | Number of NSVCs per FR-NSE was 64, now is 128

> SGSN Features in Release 8.1
> This section provides information for new features in the Serving GPRS Support Node (SGSN) product.
> Default APN
> Operators can configure a “default APN” for subscribers not provisioned in the HLR. This feature is available in releases 8.1 and higher.
> The Default APN feature will be used in error situations when the SGSN cannot select a valid APN via the normal APN selection process. Within an operator policy, a default APN can be configured for the SGSN to: override a requested APN when the HLR does not have the requested APN in the subscription profile. provide a viable APN if APN selection fails because there was no "requested APN" and wildcard subscription was not an option.
> In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.
> Refer to the SGSN Operator Policy Configuration Mode in the Command Line Interface Reference for the command to configure this feature.
> Direct Tunnel Support
> In accordance with standards, one tunnel functionality enables the SGSN to establish a direct tunnel at the user plane level - a GTP-U tunnel, directly between the RAN and the GGSN.
> SGSN Direct Tunnel
> The SGSN typically establishes a direct tunnel at PDP context activation using an update PDP context request towards the GGSN.
> In effect, a direct tunnel reduces data plane latency as the tunnel functionality acts to remove the SGSN from the data plane and limit the SGSN to the control plane for processing. This improves the user experience (e.g., expedites web page delivery, reduces round trip delay for conversational services). Additionally, direct tunnel functionality implements the standard “SGSN optimization” to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN to handle the user plane processing.
> Direct tunnel means a significant increase in control plane load on both the SGSN and GGSN components of the packet core. Hence, deployment requires highly scalable GGSNs since the volume and frequency of update PDP context messages to the GGSN will increase substantially. Platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
> For more information on Direct Tunnel configuration, refer to SGSN Direct Tunnel Configuration chapter in System Enhanced Feature Configuration Guide.
> This features requires a special license.
> Disable Signaling Indication IE in RANAP messages
> In accordance with RANAP standards, the Signaling Indication IE is only included in RANAP messages RANAP (RAB Assignment Request and/or the Relocation Request messages) when the traffic class is "interactive".
> The Command Line Interface (CLI) has been modified to enable the operator to control whether the IE is included if both of the following conditions are met:
> 1.when the traffic class is "interactive".
> 2.Signaling Indication IE is included in the current QoS and the value is optimized (value of "1").
> New CLI commands have been added to the RNC configuration mode to govern the inclusion of the Signaling Indication IE in RANAP messages. Refer to the Command Line Interface Reference for information on enabling/disabling this feature.
> Ga Interface Supports Configurable Transport Layer
> It is now possible to configure the transport layer from the standard UPD to TCP. This functionality has been added to enable the carrier to select connection-oriented sessions for the Ga interface. For more information, refer to the gtpp transport-layer command in the GTPP Group Configuration Mode chapter of the Command Line Interface Reference.
> Hard Disk Storage for CDR Files
> A hard disk has been introduced in the ST40 platform to add storage capability. When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see Hard Disk Support on SMC Card in ST40 Platform.

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

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

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

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

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

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

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

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

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

> l | Enables service downtime for maintenance scheduling.

> Limiting Iu Connections in RANAP Messages
> A new command has been created to enable the operator to further control message length by configuring the number of IuConIDs sent in each SGSN Init Reset Resource message.
> This change will have no impact on current or future configurations as the previously coded system value was 250.
> Refer to the RNC Configuration Mode chapter of the Command Line Interface Reference for additional information.
> Local QoS Capping
> The operator can configure a cap or limit for the QoS bit rate.
> The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
> Depending upon the keywords included in the command, the SGSN can: take the QoS parameter configuration from the HLR configuration. take the QoS parameter configuration from the local settings for use in the APN policy. during session establishment, apply the lower of either the HLR subscription or the locally configured values.
> Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
> Multiple PLMN Support (2.5G only)
> With this new feature, the 2.5G SGSN supports cell-sites with more than one PLMN-ID. Operators can now assign a different PLMN-ID to each cell in the network (typically, there are no more than 3 or 4 PLMN-IDs in a single network). This multiple PLMN support also enables an operator to 'hire out' their infrastructure to other operators who wish to use their own PLMN-IDs. Each cell can be part of only one PLMN (one GRPS service). By configuring the GPRS service for each PLMN-ID, this feature allows the 2.5G SGSN to perform handovers between the service instances.
> Configuring Multiple PLMN Support:
> The 2.5G SGSN supports MS handover from one PLMN to another PLMN by configuring multiple instances of the GPRS service, each with a different PLMN-ID, in the same context. Each of the GPRS services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context. For command details, refer to the GPRS Service Configuration Mode and MAP, SGTP, and GS Service Configuration Mode chapters in the Command Line Interface Reference.
> To enable appropriate S-CDR generation in a multiple PLMN-ID scenario, use the plmn-id-change keyword for the gtpp trigger command in the GTPP Group Configuration Mode also documented in the CLI Reference.
> Network Sharing
> The SGSN enables two or more network operators to share common network infrastructure. In accordance with 3GPP TS 23.251, the SGSN supports two different configurations for network sharing based on the resources being shared: gateway core network (GWCN) and multi-operator core network (MOCN).
> With GWCN, the complete radio access network and partial core network are shared among different operators. Each operator will have its own network node for GGSN/HLR, etc., while sharing SGSN/MSC and the remaining radio network.
> With MOCN, the complete radio network is shared among different operators, while each operator maintains its own separate core network.
> With these two configurations, the SGSN supports multiple scenarios such as MOCN with non-supporting UE, MOCN with supporting UE, GWCN with supporting UE, and GWCN with non-supporting UE.
> NPU FastPath
> The NPU FastPath feature is proprietary and only available on the ST40 SGSN systems. The purpose of this type of internal direct tunnel is to optimize resource usage and reduce latency when processing GTP-U packets. Incoming traffic passes through the switch fabric and the routing headers are changed to re-route traffic from the incoming network processing unit (NPU) of the ingress PSC directly to the outgoing NPU of the egress PSC. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.
> SGSN NPU FastPath
> Fast path is established when both ends of a tunnel are available. Two fast path flows are established, one for the uplink and one for the downlink direction for a given PDP context.
> If FastPath cannot be established, the NPU forwards the GTP-U packets to a CPU for processing and they are processed like all other packets.
> FastPath can not be established for subscriber PDP sessions if:

> l | Traffic Policing is enabled

> l | Subscriber Monitoring is enabled

> l | Lawful Intercept (LI) is enabled

> l | IP Source Violation Checks are enabled

> l | GTP-v0 tunnel is esatlished with a GGSN

> FastPath will be dropped temporarily during:

> l | Intra-SGSN RAU

> l | Iu-connection release

> Quad Gig-E Line Card (QGLC) & Link Aggregation
> The SGSN now supports the four-port gigabit-Ethernet line card - QGLC. This card will enable the SGSN to utilize standard-compliant link aggregation. For additional feature information, see QGLC and Link Aggregation feature descriptions in the Common Features in Release 8.0 section of this chapter.
> For details about this new line card, see the Hardware Platform Overview chapter of the Hardware Installation and Administration Guide.
> Tracking Usage of GPRS Encryption Algorithm
> Usage of the GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity depending upon the GEAx level used - GEA1, GEA2, or GEA3.
> Operators could use a mechanism that would enable them to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool would also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity to exceed.
> Enhanced counters should display the absolute number of attached subscribers using each of the GEA algorithms.
> Counters have been added to the output of the show sub gprs-only summary CLI command to track:

> l | the number of subscribers capable of GEA0-GEO3, and

> l | the number of subscribers with negotiated GEAx levels.

> New counters display the number of subscribers whose MS network capability supports GEA0/GEA1/GEA2/GEA3. Similarly, the new counters under "Negotiated" indicate the number of subscribers who have negotiated with the SGSN to use a specific encryption algorithm according to the ciphering priority configuration and the network capability.
> Sample Output:
> [local]bngnc3# show sub gprs-only sum
> Total Subscribers : 2 Total Ready Subscribers : 0
> Total Detached Subscribers : 1 Total Standby Subscribers : 1
> Total Suspended Subscribers : 0
> Total subscribers with encryption algorithm
> Capability : Negotiated :
> GEA0 : 1 GEA0 : 1
> GEA1 : 0 GEA1 : 0
> GEA2 : 0 GEA2 : 0
> GEA3 : 1 GEA3 : 0
> Total Active Subscribers : 0 Total PDP contexts : 0
> pdp-type-ipv4 : 0 pdp-type-ppp : 0
> pdp-type-ipv6 : 0
> .
> .
> Traffic Handling - QoS Provisioning with ARP
> The SGSN now enables setting the priority of service via the configuration of the allocation/retention priority (ARP) IE. By including this IE in the RANAP message during the RAB assignment procedure it is possible to specify the relative importance of the radio access bearers for the allocation and retention of traffic. When there is a resource crunch, the IE is used by the RNC to allocate or deallocate resources according to the defined priority. This IE also tells whether queuing of packets is allowed or not.
> Although the HLR subscription record only provides a single priority parameter (values 0 to 3), the RNC needs additional information, which our configuration command maps to the subscription priority. Additional information needed:

> l | Priority Level: 1..15

> l | Pre-emption Capability: shall-not-trigger-pre-emption, may-trigger-pre-emption

> l | Pre-emption Vulnerability: pre-emptable, not-pre-emptable

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

> For configuration details, see SGSN APN Configuration Mode in the CLI Reference Guide.
> CLC2 - Channelized Line Card 2
> For Frame Relay signaling, the SGSN now supports the Channelized Line Card 2 (CLC2), the next-generation SONET/SDH channelized line card for the ST40. In North America, the card supplies ANSI SONET STS-3 (optical OC-3) signaling. In Europe, the card supplies SDH STM-1 (optical OC-3). The transmission rate for the card is 155.52 Mb/s with 336 SONET channels supplying T1 and 252 SDH channels supplying E1. The CLC2 is RoHs 6/6 compliant. Each CLC2 provides four optical fiber physical interfaces (ports). For more information about this card, refer to the ST40 Hardware Installation and Administration Guide.
> OLC2 - Optical Line Card 2
> For ATM signaling, the SGSN now supports the Optical Line Card 2 (CLC2), the next-generation SONET/SDH optical line card for ATM signaling on the ST40. The OLC2 supports all features, including 4 ports, available on the original OLC but now includes RoHs 6/6 compliance. For more information about this card, refer to the ST40 Hardware Installation and Administration Guide.
> Web Element Manager Features in Release 8.0
> This section provides information for new features for the Web Element Manager application in Release 8.0.
> Support for Configurable DSCP Marking Based on Allocation/Retention Priority
> GGSN now supports configurable DSCP marking based on traffic handling priority and allocation/retention priority for the Interactive Traffic class. A DSCP value matrix is introduced and used to map based on these priorities only if the allocation priority is present in the QOS profile.
> Web Element Manager Path
> Click Configuration | GGSN | GGSN Service | Add / Modify GGSN Service Configuration Dialog Box - Timers/QoS tab.
> Click Configuration | GGSN | GGSN Service | GGSN Service Details Configuration Dialog Box.
> Click Configuration | GGSN | APN | APN Configuration Dialog Box - Tunnel / Qos tab.
> Click Configuration | GGSN | APN | Add / Modify APN Configuration Dialog Box - Tunnel / Qos tab.
> Support for SGSN Bulk Statistics
> WEM now provides support for SGSN bulk statistics. Multiple bulk statistic counters are introduced and grouped according to the following SGSN schemas:

> l | SGSN Schema: These are variables per SGSN service and uniquely identified by SGSN service name and VPN context.

> l | SCCP Schema: Each SCCP network is uniquely identified by a number in the chassis. All the statistics in this schema are per sccp-network.

> l | SGTP Schema: These are variables per SGTP service and identified uniquely by SGTP service name and VPN context.

> l | SS7RD Schema: Each SS7-routing domain is identified by a number unique across the chassis. All the statistics in this schema are per ss7rd.

> Support for SGSN Alarms/Traps in Web Element Manager
> WEM now supports a new set of traps related to the SGSN services and sessions:

> l | starSGSNServiceStart

> l | starSGSNServiceStop

> l | starM3UAPCUnavailable

> l | starM3UAPCAvailable

> l | starM3UAASDown

> l | starM3UAASActive

> l | starM3UAASPDown

> l | starM3UAASPUp

> l | starSCCPSspRcvd

> l | starSCCPSspClear

> l | starSGSNRNCReset

> l | starSGSNHLRReset

> l | starSGSNGtpcPathFailure

> l | starSGSNGtpcPathFailureClear

> l | starSGSNGtpuPathFailure

> l | starSGSNGtpuPathFailureClear

> l | starMTP3LinkOutOfService

> l | starMTP3LinkInService

> l | starMTP3LinkSetUnavailable

> l | starMTP3LinkSetAvailable

> l | starSCTPAssociationFail

> l | starSCTPAssociationEstablished

> l | starSCTPPathDown

> l | starSCTPPathUp

> l | starThreshSGSNSessions

> l | starThreshClearSGSNSessions

> l | starThreshPerServiceSGSNSessions

> l | starThreshClearPerServiceSGSNSessions

> l | starThreshSGSNPdpSessions

> l | starThreshClearSGSNPdpSessions

> l | starThreshPerServiceSGSNPdpSessions

> l | starThreshClearPerServiceSGSNPdpSessions

> Support for Content Filtering Report Configuration
> WEM provides support for ad hoc generation of reports.
> Web Element Manager Path
> Click Accounting | Content Filtering | Report Configuration.
> Click Accounting | Content Filtering | View Reports.
> Web Element Manager Features in Release 8.1
> This section provides information for new features for the Web Element Manager application.
> Support for PDIF functionality
> This functionality provides the various configurables to configure PDIF and obtain the PDIF bulkstats.
> Web Element Manager Path
> Click Configuration | PDIF | PDIF Service | PDIF Service Dialog Box – General / AAA/HSS tab.
> Click Configuration | PDIF | PDIF Service | Add/Modify PDIF Service Dialog Box – General / AAA/HSS tab.
> Click Performance | PDIF | PDIF Statistics Dialog Box.
> Support for IKEv2 Transform Set
> WEM provides PDIF support for the IKEv2 IKE Security Association and IP Security transform sets.
> Web Element Manager Path
> Click Configuration | Context Provisioning | IP Security | IKEv2 IKESA Transform Set | IKEv2 IKESA Transform Set Configuration Dialog Box.
> Click Configuration | Context Provisioning | IP Security | IKEv2 IKESA Transform Set | Add/Modify IKEv2 IKESA Transform Set Dialog Box.
> Click Configuration | Context Provisioning | IP Security | IKEv2 IPSEC Transform Set | IKEv2 IPSEC Transform Set Configuration Dialog Box.
> Click Configuration | Context Provisioning | IP Security | IKEv2 IPSEC Transform Set | Add/Modify IKEv2 IPSEC Transform Set Dialog Box.
> Support for Crypto Template
> WEM provides PDIF support for the crypto template. The Crypto Template Configuration Mode is used to configure an IKEv2 PDIF IPSec policy. A PDIF service will not function without a configured crypto template. Only one crypto template can be configured per PDIF service.
> The Crypto Template Payload Configuration Mode is used to assign the correct IPSec transform set from a list of up to four different transform sets, and to assign Mobile IP addresses.
> Web Element Manager Path
> Click Configuration | Context Provisioning | IP Security | Crypto Template | Crypto Template Configuration Dialog Box - General / IKEv2 IKESA/Authentication / Payload tab.
> Click Configuration | Context Provisioning | IP Security | Add/Modify Crypto Template | Crypto Template Configuration Dialog Box - General / IKEv2 IKESA/Authentication / Payload tab.
> Support for IPv6
> WEM provides PDIF support for IPv6 Neighbors, IPv6 Route, and IPv6 Interface Summary.
> Web Element Manager Path
> Click Configuration | Context Provisioning | IPv6 Neighbors | IPv6 Neighbor Configuration Dialog Box.
> Click Configuration | Context Provisioning | IPv6 Neighbors | Add IPv6 Neighbor Dialog Box.
> Click Configuration | Context Provisioning | IPv6 Route | IPv6 Route Configuration Dialog Box.
> Click Configuration | Context Provisioning | IPv6 Route | Add/Modify IPv6 Route Dialog Box.
> Click Performance | IPv6 Interface Summary | IPv6 Interface Summary Dialog Box.
> Support for Diameter Configuration
> WEM provides PDIF support to configure the Diameter Endpoint and Diameter Authentication configuration.
> Web Element Manager Path
> Click Configuration | Context Provisioning | Diameter Configuration | Diameter Endpoint.
> Click Configuration | Context Provisioning | Diameter Configuration | Diameter Authentication.
> Support for URL Blacklisting Statistics
> WEM provides support for the URL Blacklisting Statistics.
> Web Element Manager Path
> Click Performance | Active Charging | URL Blacklisting Statistics.
> Support for Content Filtering Statistics
> WEM provides support for the Content Filtering and Category Database Statistics.
> Web Element Manager Path
> Click Performance | Active Charging | Content Filtering Statistics.
> Click Performance | Content Filtering | Content Filtering Statistics.
> Click Performance | Content Filtering | Category Database Statistics.
> Support for EAP Profile
> WEM provides support for the EAP Profile functionality.
> Web Element Manager Path
> Click Configuration | Context Provisioning | EAP Profile.
> Support for Certificate Configuration
> WEM provides support for Certificate configuration and Private Key configuration.
> Web Element Manager Path
> Click Configuration | Certificate Configuration.
> Support for Network Audit Tool
> The Network Audit Tool in WEM supports the on demand or periodic auditing of IMG configuration attributes (audit attributes) such as PPP MRU, Auth Sequence, Bulkstats Schema Needs Update, etc.
> Web Element Manager Path
> Click Security | Configuration Audit | Query Information.
> Click Security | Configuration Audit | Schedule.
> Click Security | Configuration Audit | On Demand.
> Click Security | Configuration Audit | Results.
> IPMP Configuration on WEM Server
> IP Multipath (IPMP) configuration is now provided on WEM server.
> IP Multipathing is a feature supported on Sun® Solaris® provided by Sun Microsystems. With IPMP, two or more NICs are dedicated for each network to which the host connects. Each interface is assigned a static “test” IP address, which is used to access the operational state of the interface. Each virtual IP address is assigned to an interface, though there may be more interfaces than virtual IP addresses, some of the interfaces being purely for standby purposes. When the failure of an interface is detected its virtual IP addresses are swapped to an operational interface in the group.
> IMPORTANT: IPMP is a feature supported on Sun® Solaris® provided by Sun Microsystems. The configuration is included in Section VI of the System Administration Guide: IP Services from Sun Microsystems. For more information, refer to the Sun documentation
> No separate license key required for this configuration.
> For more information on configuration of this feature on WEM Servers, refer WEM Installation and Administration Guide.

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