> New Feature Summary
> This guide identifies features and functionality added or modified between software releases 8.x and 9.0. Topics covered in this chapter are:

> l | Common Features in Release 9.0

> l | ASN GW Features in Release 9.0

> l | Content Filtering in Release 9.0

> l | ECS Features in Release 9.0

> l | eHRPD Features in Release 9.0

> l | ESS Features in Release 9.0

> l | Firewall Features in Release 9.0

> l | GGSN Features in Release 9.0

> l | GSS Features in Release 9.0

> l | HA Features in Release 9.0

> l | inPilot Features in Release 9.0

> l | IP Services Gateway Features in Release 9.0

> l | LTE/SAE Features in Release 9.0

> l | NAT Features in Release 9.0

> l | PDIF Features in Release 9.0

> l | PDSN Features in Release 9.0

> l | Peer-to-Peer Features in Release 9.0

> l | SCM Features in Release 9.0

> l | SGSN Features in Release 9.0

> l | Web Element Manager Features in Release 9.0

> Related Documents
> Additional information on these items is located in the documents provided with the 9.0 release, see the table below.

> 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
> Command Line Interface Reference | 901-00-0014 AT
> Enhanced Charging Service Administration Guide | 901-00-0038 X
> SCM Administration Guide | 901-00-0041 E
> Content Filtering Services Administration Guide | 901-00-0056 J
> Peer-to-Peer Detection Administration Guide | 901-00-0057 M
> Packet Data Interworking Function Administration Guide | 901-00-0059 L
> Personal Stateful Firewall Administration Guide | 901-00-0060 N
> PDG/TTG Administration Guide | 901-00-0093 B
> PHS Gateway Administration Guide | 901-00-0075 E
> HRPD Serving Gateway Administration Guide | 901-00-0076 A
> PDN Gateway Administration Guide | 901-00-0077 A
> Serving Gateway Administration Guide | 901-00-0078 A
> Mobility Management Entity Administration Guide | 901-00-0079 A
> NAT Administration Guide | 901-00-0086 D
> InPilot Installation and Administration Guide | 901-00-0087 A

> Common Features in Release 9.0
> This section provides information on new features that are common to products in Release 9.0.
> Dynamic MPLS Label Support
> Benefits
> This feature provides dynamic MPLS label support for ingress and egress traffic where system works as MPLS-Customer Edge system and maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session with an Autonomous System Border Router (ASBR).
> Description
> In deployment scenario the MPLS-CE system maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session with peer. The peer in this scenario is not a PE router but an ASBR. The ASBR does not need to maintain any VRF configuration. The PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses eBGP to redistribute those labeled VPN-IPv4 routes to MPLS-CE in another AS. Because of eBGP connection, ASBR changes the next-hop and labels in the routes learnt from iBGP peers before advertising to MPLS-CE. MPLS-CE is directly connected eBGP peering and uses only MP-eBGP to advertise and learn routes. MPLS-CE pushes/pops single label to/from ASBR, which is learnt over MP-eBGP connection. This scenario uses dynamic MPLS label and avoids configuration of VRFs on PE, which are already configured on MPLS-CE.
> For more information on functioning and configuration of this interface, refer Multiple Protocol Lable Switching chapter in System Enhanced Feature Configuration Guide.
> License Keys
> Requires separate license key.
> Side-by-side Redundancy for the 10 Gig Line Card (XGLC)
> Starent chassis provides the redundancy scheme for using top and bottom line card slots for one-to-one redundancy for line cards with top and bottom line card slot for one-to-one redundancy.
> The XGLC is a full-height card that requires both top and bottom line card slots for a single 10-gigabit port. This means that the scheme for using top and bottom line card slots for one-to-one redundancy is not workable for XGLCs. To achieve one-to-one line card redundancy, user must install two XGLCs in adjacent slots. Otherwise, user can configure port and card redundancy for the XGLCs in the same way as other line cards. There are no restrictions that prevent the side-to-side 1:1 XGLC redundant arrangement from functioning with other Ethernet line card types.
> Each PSC or PSC2 is mated to a single XGLC. Monitoring functions occur in a distributed fashion. Select the line cards that act as a redundant pair via the CLI. Configure the redundant pairs prior to configuring the interface bindings so that proper parallel physical and logical port configurations are established. The card redundancy and monitoring begins as soon as the PSC or PSC2 in front is active.
> Note: Side-by-side 1:1 redundancy only operates on top line card slot numbers: cards 17 through 23 and 26 through 32. Make sure that both PSCs or PSC2s in front of the line cards are of the same type, configured as a redundant pair, and active.
> For more information on side by side 1:1 redundancy for 10 Gig line card (XGLC), refer ST40 Hardware Installation Guide.
> Packet Processor Card (PPC)
> The PPC has features a quad-core x86 2.5Ghz CPU and 16GB of RAM. The processor runs a single copy of the operating system. To check the CPU in the CLI, use the show cpu table command. The operating system running on the PPC treats the dual-core processor as a 2-way multi-processor. You can see this in the output of the show cpu info verbose command.
> IMPORTANT: For this release, the PPC is limited to CDMA and HA functionality.
> A second-generation data transport fixed programmable gate array (DT2 FPGA, abbreviated as DT2) connects the PPC’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 PPC 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.
> Redundancy

> l | The PPC is fully redundant with a spare PPC.

> Capacity

> l | 3 million SAU and 6 million PDP contexts

> l | 2 million PDSN sessions

> l | 6 million HA sessions

> Power Estimate

> l | 325W Maximum

> DCCA URCS (IPC-G) Steering Based on Subscriber IMSI Prefix/Suffix
> This release supports peer selection using IMSI prefix or suffix, or IMSI prefix or suffix range. Subscribers are now assigned to a primary OCS instance based on the IMSI prefix or suffix of a length of 1 to 15 digits. If the prefix or suffix keyword is not specified, the suffix will be considered. Up to 64 peer selects can be configured. At any time, either prefix or suffix mode can be used in one DCCA config. If the prefix or suffix mode is used, the lengths of all prefix/suffix must be equal.
> EDR/UDR File Push Directory Structure
> In earlier StarOS 9.0 releases, whenever CDR transfer mode push was configured with a remote URL, on the external server the chassis would by default create an extra directory in the base directory path before creating the edr/udr directories.
> For example, with the following configuration:
> cdr transfer-mode push primary url sftp://root:sn@1.2.3.4/<base_directory>
> cdr push-interval 60
> cdr remove-file-after-transfer
> cdr use-harddisk
> The following directory structure was created on the external server:
> <base_directory>
> | <chassis1_host_name>
> | edr
> | udr
> | <chassis2_host_name>
> | edr
> | udr
> This enabled to keep EDR and UDR files from multiple chassis pushing to the same external server with same base directory separate.
> In the current release, the default behavior has changed, the extra directory with the chassis host name will not be created on the external server. This behavior is the same as in the StarOS 8.x releases. The directory structure will be:
> <base_directory>
> | edr
> | udr
> 3GPP R7 Gx Interface Support
> As defined by the 3GPP standards, the R7 Gx interface is located between the GGSN and the Policy Decision Function (PDF) / Policy and Charging Rule Function (PCRF). It is a Diameter-based interface and provides the functions provided earlier by the Gx (R6) and Go interfaces. Gx interface as part of a Policy / PCC framework allows the operator to have dynamic policy and charging control, key features when “flat rate” broadband services are offered. However, it is paramount that the operator maintains control over the available resources, and provides a fair usage policy to its subscribers, via bandwidth control, quota management and other mechanisms.
> This release supports the following features:

> l | PCEF-based bearer binding

> l | IMSA support for secondary contexts

> l | QoS Negotiation AVP and QoS Upgrade AVP in Gx messages

> l | Single repository of ruledefs for all PDP contexts

> l | Moving of PCC rules across PDP contexts if indicated by PCRF

> l | QoS enforcement per service data flow

> l | Bearer identifier value extensible to non-GPRS access type

> l | Ability to define static policies to deny and allow based on 5-tuple information; ability to enable and disable from the PCRF

> Bearer ID in Bearer-level QoS Information
> In previous releases, in case of PCRF-based binding, when the bearer-level QoS information was received from PCRF without bearer ID, the UPC request with the change in QoS was sent to the default bearer.
> In this release, this behavior has changed. In case of PCRF-based binding, the bearer ID is expected as part of the bearer-level QoS information from the PCRF. Otherwise the QoS information is ignored.
> Bearer ID Validation
> In previous releases, the bearer ID in the QoS-Information AVP from the PCRF was not being validated at the PCEF.
> In this release, the bearer ID is validated and if found to be invalid is ignored.
> Failure Handling Action
> In StarOS 8.1 and earlier releases, when the failure handling action configured under the IMSA service is terminate, and if the primary server is down but the secondary server is up during call establishment, the call is terminated.
> In this release, this behavior has changed, the call is established with the secondary server.
> Gn APN in Gx Messages
> In StarOS 8.0, if in the APN configuration both the virtual APN name and Gn APN name are configured, the virtual APN name is sent in the Gx messages.
> In this release, if both the virtual APN name and Gn APN name are configured, the Gn APN name is sent in the Gx messages. In case only the Gn APN name is configured, the Gn APN name is sent.
> Maximum Number of Charging-Rule-Definition AVPs Supported in a Single CCA
> In previous releases, there was no limit check for the number of Charging-Rule-Definition AVPs (dynamic rules) that are processed in a single Gx CCA command. In StarOS 9.0, the number of dynamic rules is limited to 100 per Gx message.
> In this release, the following per Gx message limits are applicable:

> l | Charging-Rule-Names: 256

> l | Charging-Rule-Base-Names: 20

> l | Charging-Rule-Definitions: 100

> l | Length of Charging-rule-name/base-name: 32

> Provisioning of Event Triggers
> In this release, whenever the PCRF subscribes to one or more event triggers by using the RAR command, the PCEF sends the corresponding currently applicable values (e.g. 3GPP-SGSN-Address AVP or 3GPP-SGSN-IPv6-Address AVP, RAT-Type, 3GPP-User-Location-Info, etc.) to the PCRF in the RAA if available, and in this case, the Event-Trigger AVPs will not be included.
> Rejection of Unauthorized Gx Messages
> In StarOS 8.1, if PCRF does not authorize the requested QoS values, the PCEF does not reject the Gx response messages.
> In StarOS 9.0, if the PCRF does not authorize the requested QoS values, or if QoS values previously authorized by the PCRF are not available, the PCEF rejects the Gx messages from PCRF and the corresponding access side procedure. The Max Uplink/Downlink, Guaranteed Uplink/Downlink parameters are considered to check whether the QoS values are authorized or not. Validation is done across all Gx messages.
> ASN GW Features in Release 9.0
> This section provides information for new features in the ASN GW Service in Release 9.0.
> None for this release.
> Content Filtering in Release 9.0
> This section provides information for new features in the Content Filtering product.
> Category-based Static-and-Dynamic Content Filtering
> This release introduces support for Category-based Static-and-Dynamic Content Filtering, wherein if static rating categorizes a URL as either “dynamic” or “unknown”, the “requested content” is sent for dynamic rating. Wherein the “requested content” is analyzed and categorized. Action is taken based on the category determined by dynamic rating, and the action configured for that category in the subscriber’s content filtering policy. Possible actions include permitting, blocking, redirecting, and inserting/altering content.
> Dynamic Content Filtering enables on-the-fly content analysis of Web traffic using different content analysis techniques. When a Web page is received, it is analyzed and then categorized according to the content found in the page. Whether a Web site has existed for five months or for five minutes does not matter since determination of the category to which the Web page belongs is made just at the time of request. A combination of static filtering and dynamic inspection provides real accuracy and scalability as the Web weaves an increasingly sophisticated network of sites.
> IMPORTANT: Category-based Content Filtering can only work in static-only or in static-and-dynamic modes. Dynamic-only Content Filtering mode is not supported.
> For more information, refer to the Content Filtering Services Administration Guide.
> ECS Features in Release 9.0
> This section provides information on new features in the Enhanced Charging Service in Release 9.0.
> 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).
> IPv6 and ICMPv6 Support in Enhanced Charging Service
> StarOS 9.0 introduces support for IPv6 and ICMPv6 packets and their parsing in the Enhanced Charging Service.
> ECS can now parse both IPv4 and IPv6 packets and pass them to upper layers for analysis. ECS will match the rule based on IPv6 fields and generate various statistics for IPv6 packets. Dynamic routing used by various analyzers like FTP, RTSP, RTP, and SIP also supports IPv6 addresses.
> The enhancement to ECS in Release 9.0 provides appropriate CLIs to configure IPv6 fields in rules and EDRs. Various CLIs are provided to configure rules related to IPv6 fields for charging and routing. Several fields in EDRs give IP address. ECS will also support IPv6 addresses in these EDR fields. Show command CLIs which show IP addresses support IPv6 addresses as well. The various logs in ECS which log IP addresses along with other information, supports IPv6 addresses as well. ECS supports various header fields of IPv6 in EDRs. In config-acs-edr mode, ECS supports generating EDRs for IPv6 fields.
> StarOS 9.0 also supports ICMPv6 packets and their parsing in ECSv2. The header structure of ICMP and ICMPv6 is similar but the values of header fields like type and code have different meaning in the two.
> With the support for IPv6 in ECS, AAAA record type is now supported in DNS for IPv6 addresses.
> URL Filtering
> This release supports the URL Filtering feature, which simplifies using rule definitions for URL detection. Prefixed URLs are URLs of the proxies. A packet can have a URL of the proxy and the actual URL contiguously. First a packet is searched for the presence of proxy URL. If the proxy URL is found, it is truncated from the parsed information and only the actual URL (that immediately follows it) is used for rule matching and EDR generation.
> For more information, refer to the Enhanced Charging Service Administration Guide.
> eHRPD Features in Release 9.0
> This section contains information on new 9.0 features that pertain to the HRPD Serving Gateway (HSGW) and the PDN Gateway (P-GW) supporting eHRPD network services.
> New HSGW Features
> The HSGW is new in release 9.0.
> The HSGW terminates the eHRPD access network interface from the Evolved Access Network/Evolved Packet Core Function (eAN/ePCF) and routes UE-originated or terminated packet data traffic. It provides interworking with the eAN/ePCF and the PDN Gateway (P-GW) within the Evolved Packet Core (EPC) or LTE/SAE core network and performs the following functions:

> l | Mobility anchoring for inter-eAN handoffs

> l | Transport level packet marking in the uplink and the downlink, e.g., setting the DiffServ Code Point, based on the QCI of the associated EPS bearer

> l | Uplink and downlink charging per UE, PDN, and QCI

> l | Downlink bearer binding based on policy information

> l | Uplink bearer binding verification with packet dropping of UL traffic that does not comply with established uplink policy

> l | MAG functions for S2a mobility (i.e., Network-based mobility based on PMIPv6)

> l | Support for IPv4 and IPv6 address assignment

> l | EAP Authenticator function

> l | Policy enforcement functions defined for the Gxa interface

> l | Robust Header Compression (RoHC)

> l | Support for VSNCP and VSNP with UE

> l | Support for packet-based or HDLC-like framing on auxiliary connections

> l | IPv6 SLACC support, generating RAs responding to RSs

> New P-GW Features
> The P-GW is new in Release 9.0.
> The P-GW terminates the SGi interface towards the Packet Data Network (PDN). If a UE is accessing multiple PDNs, there may be more than one P-GW for that UE. The P-GW provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one P-GW for accessing multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.
> Another key role of the P-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX and 3GPP2 (CDMA 1X and EvDO).
> P-GW functions for supporting non-3GPP access (eHRPD) include:

> l | Mobility anchor for mobility between 3GPP access systems and non-3GPP access systems. This is sometimes referred to as the SAE Anchor function.

> l | Policy enforcement (gating and rate enforcement)

> l | Per-user based packet filtering (deep packet inspection)

> l | Charging support

> l | Lawful Interception

> l | UE IP address allocation

> l | Packet screening

> l | Transport level packet marking in the downlink;

> l | Down link rate enforcement based on Aggregate Maximum Bit Rate (AMBR)

> l | Local Mobility Anchor (LMA) according to draft-ietf-netlmm-proxymip6, if PMIP-based S5 or S8 is used.

> l | DSMIPv6 Home Agent, as described in draft-ietf-mip6-nemo-v4traversal, if S2c is used.

> ESS Features in Release 9.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).
> Generic L-ESS
> In this release, the L-ESS is designed to support simultaneous fetching of any types of files from one or more chassis. That is, it can fetch CDR, EDR, NBR, UDR file, etc.
> The current design of L-ESS allows dynamic configuration of source and destination. This further allows multi-threading and multi-processing of the associated hardware components, thereby improving the performance of L-ESS.
> Firewall Features in Release 9.0
> This section provides information for new features in the Stateful Firewall product in Release 9.0.
> Per Subscriber Stateful Firewall Licensing
> In previous releases, the Stateful Firewall license was required to enable and configure NAT. In this release, Stateful Firewall and NAT licenses are separated.
> The “[600-00-7808] Stateful Firewall With DPI” license has been obsoleted.
> Stateful Firewall must be enabled and configured using the “[600-00-7571] Per Subscriber Stateful Firewall 1k sessions” license. This license enables CLI privileges only for Enhanced Charging Service (ECSv2) and Per Subscriber Stateful Firewall. NAT features cannot be enabled/configured with this license. Some CLI commands that are common to both Stateful Firewall and NAT are available with either Stateful Firewall or NAT license.
> For more information, please contact your local sales representative.
> GGSN Features in Release 9.0
> This section provides information for new features for the GGSN Service in Release 9.0.
> GRE Protocol Interface
> GRE protocol functionality adds one additional protocol on ST-series Multimedia Core Platforms (ST40 or higher) to support mobile users to connect to their enterprise networks through Generic Routing Encapsulation (GRE).
> GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
> The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiator.
> GRE Tunneling is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSEC offers, for example).
> GRE Tunneling consists of three main components:

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

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

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

> The most simplified form of the deployment scenario is shown in the following figure, in which GGSN has two APNs talking to two corporate networks over GRE tunnels.
> GRE Deployment Scenario
> Apart from other command configuration addition/modifications in various configuration modes, following new configuration modes were added to Command Line Interface for this feature support:

> l | OSPF VRF Configuration Mode

> l | IP VRF Context Configuration Mode

> l | GRE Tunnel Interface Configuration Mode

> This feature requires separate license to enable this for UMTS subscribers.
> For more information on functioning and configuration of this interface, refer GRE Protocol Interface chapter in System Enhanced Feature Configuration Guide.
> Overcharging Protection on Loss of Radio Coverage
> This solution provides the ability to configure mobile carriers to maximize their network solutions and balancing the requirements to accurately bill their customer.
> Consider scenario where a mobile is streaming or downloading very large files from external sources and the mobile goes out of radio coverage. If this download is happening on Background/Interactive traffic class then the GGSN is unaware of such loss of connectivity as SGSN does not perform the Update PDP Context procedure to set QoS to 0kbps (this is done when traffic class is either Streaming or Conversational only). The GGSN continues to forward the downlink packets to SGSN. In the loss of radio coverage, the SGSN will do paging request and find out that the mobile is not responding; SGSN will then drops the packets. In such cases, the G-CDR will have increased counts but S-CDR will not. This means that when operators charge the subscribers based on G-CDR the subscribers may be overcharged. This feature is implemented to avoid the overcharging in such cases.
> This implementation is based on Starent-specific private extension to GTP messages and/or any co-relation of G-CDRs and S-CDRs. It also does not modify any RANAP messages.
> This feature requires separate license to enable this for UMTS subscribers.
> For more information of this feature, refer Subscriber Overcharging Protection chapter in System Enhanced Feature Configuration Guide.
> GSS Features in Release 9.0
> This section provides information for new GSS features for Release 9.0
> Multiple Instance GSS
> Release 9.0 enables support for multiple data streams from one server or a single cluster setup to utilize multiple instances of GSS with a single installation and multiple databases.
> In a cluster setup, there is only one installation per node. During installation, GSS is installed at a fixed location (/opt/gss_global directory). The initial GSS installation does not create any GSS instance. Once GSS is installed on both the nodes, the /opt/gss_global/make_gss_instance script utility creates instances as an when needed and validates the conflicting ports/username across the instances.
> For all instances on the node, only one set of binaries and scripts are used. Each instance will have its own configuration file, log directory, tools directory and separate PostgreSQL database. The alarms and events generated by each instance are sent to its corresponding chassis. Individual GSS instance can also be stopped, started or switched over. Upgrade is smooth and will involve minimum down time as possible.
> Each GSS instance can be uninstalled separately and will not have any impact on the other instances. Global installation can be only uninstalled if there are no instances configured or running on the system.
> The advantages of this feature include:

> l | Only one installation required for multiple instances

> l | One binary used across all the instances on the node

> l | Upgrading one set of binaries would upgrade all the instances

> l | In cluster mode resource groups, instances can be balanced across the nodes

> For more information on the installation, uninstallation and upgrade procedures for multiple GSS instances, refer to Multiple Instances of GSS section in GSS Installation Management chapter of GSS Installation and Administration Guide.
> Monitoring of Disk Partitions
> This feature enables support for disk monitoring of shared postgres and gss installation disk partition along with GSS data files disk partition. This feature is supported only for single instance GSS, and for GSS in cluster mode.
> This feature can be enabled after installation by configuring specific parameters in the gss configuration file. For information on configuring the parameters, refer to the Modifying a GSS Configuration section in the GTPP Storage Server Administration chapter of GSS Installation and Administration Guide.
> IMPORTANT: This feature does not support backward compatibility and hence GSN build should always match with GSS build.
> HA Features in Release 9.0
> This section provides information for new features in the Home Agent product in Release 9.0.
> None for this release.
> inPilot Features in Release 9.0
> This section provides information for new inPilot features in Release 9.0.
> Bulkstat and KPI Reports
> The Bulkstat report provides details of the processed bulk statistics from any application (PDSN, GGSN, SGSN, and so on) on the managed nodes in a timely manner. Users need to be assigned to the Region levels so that when a user logs in to the inPilot Server, the data can be viewed for all nodes under the parent node. Only the Admin users are assigned to the top of the tree (root node or NOC node) and have access to the whole network data. The Bulkstat Report can be viewed for the desired bulkstats by selecting the BULKSTAT tab.
> The KPI report provides details of the KPIs for each selected schema. The KPI Report can be viewed for the desired KPIs by selecting the KPI tab.
> Exporting Reports to PDF Format
> The inPilot application now supports exporting reports to PDF file format.
> To export a report to PDF format, in the HOME and DPI REPORTS tabs of the inPilot GUI, click the Export to PDF button. The PDF file is displayed in a new window and can be saved for future reference. If there is no data available for a report, the Export to PDF button is disabled.
> GUI/Console based Installation
> The inPilot application and its components can be installed and uninstalled using one of the following two methods.

> l | Using script-based installer

> l | Using GUI/console-based installer

> Log File Path
> After inPilot upgrade to newer versions, the log files are generated at /starbi/logs/ directory as against the /starbi/server/logs directory in previous releases.
> RAT Classification Report
> RAT Classification Report can be viewed under Available Reports in the HOME tab.
> RAT Type reports are generated only if a RAT-type variable is available in EDRs. The RAT related parameters are applicable only for a GGSN call.
> If a RAT-type variable is not available, then all the traffic is displayed as Unclassified RAT Type in RAT Type reports. This is the case for a PDSN call.
> Supported File System
> inPilot now recommends the ZFS file system with two ZFS pools for Sun Microsystems Netra™ T5220 and Sun Microsystems Netra™ X4450 servers. The inPilot installation procedure also includes a checkpoint for ZFS when the user performs installation on a non-ZFS partition path.
> Voice Call Duration Reports
> The TopN VCD Subscribers report displays the top N subscribers based on their voice usage (voice duration) for Yahoo, MSN and Skype voice protocols. The summary report displays the voice summary (voice duration) for VoIP category.
> TopN VCD Subscribers Report can be viewed under Available Reports in the HOME tab.
> For more information on the above mentioned features, refer to inPilot Installation and Administration Guide and inPilot Online Help.
> IP Services Gateway Features in Release 9.0
> This section provides information for new features in the IP Services Gateway product.
> None for this release.
> LTE/SAE Features in Release 9.0
> This section contains information on new 9.0 features that pertain to the PDN Gateway (P-GW), the Mobility Management Entity (MME) and the Serving Gateway (S-GW) supporting LTE network services.
> New P-GW Features
> The P-GW is new in Release 9.0.
> The P-GW terminates the SGi interface towards the Packet Data Network (PDN). If a UE is accessing multiple PDNs, there may be more than one P-GW for that UE. The P-GW provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one P-GW for accessing multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.
> The P-GW provides the following basic functions:

> l | Terminates the interface towards the PDN (SGi)

> l | PGW functions for GTP-based S5/S8 include:

> l | per-user packet filtering (e.g.deep packet inspection)

> l | lawful intercept

> l | UE IP address allocation

> l | UL and DL service level charging, gating control, and service level rate enforcement

> l | DL rate enforcement based on AMBR (Aggregate Max Bit Rate) and based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI

> l | DHCPv4 and DHCPv6 functions (client, relay and server)

> New MME Features
> The MME is new in Release 9.0.
> The MME resides in the control plane and manages states (attach, detach, idle, RAN mobility), authentication, paging, mobility with 3GPP 2G/3G nodes (SGSN), roaming, and other bearer management functions. The MME is the key control-node for the LTE access-network. The MME provides the following basic functions:

> l | NAS

> l | signalling

> l | signalling security

> l | UE access in ECM-IDLE state (including control and execution of paging retransmission)

> l | Tracking Area (TA) list management

> l | P-GW and S-GW selection

> l | MME selection for handovers with MME change

> l | SGSN selection for handovers to 2G or 3G 3GPP access networks

> l | Terminates interface to HSS (S6a)

> l | Authentication

> l | Bearer management functions including dedicated bearer establishment

> l | HRPD access node (terminating S101 reference point) selection for handovers to HRPD

> l | Transparent transfer of HRPD signalling messages and transfer of status information between E-UTRAN and HRPD access, as specified in the pre-registration and handover flows

> New S-GW Features
> The Serving Gateway routes and forwards data packets from the UE and acts as the mobility anchor during inter-eNodeB handovers. Signals controlling the data traffic are received on the S-GW from the MME which determines the S-GW that will best serve the UE for the session. Every UE accessing the EPC is associated with a single S-GW.
> For each UE associated with the EPS, there is a single S-GW at any given time providing the following basic functions:

> l | Terminates the interface towards E-UTRAN (S1-U)

> l | Functions for the GTP-based S5/S8 include:

> l | local mobility anchor point for inter-eNodeB handover

> l | mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G system and P-GW)

> l | ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure

> l | lawful intercept

> l | packet routing and forwarding

> l | transport level packet marking in the uplink and the downlink (e.g. setting the DiffServ Code Point)

> l | Accounting

> NAT Features in Release 9.0
> This section contains information for new features in the Network Address Translation (NAT) product in Release 9.0.
> NAT Licensing
> In previous releases, the Stateful Firewall license was required to enable and configure NAT. In this release, Stateful Firewall and NAT licenses are separated.
> The “[600-00-7804] NAT/PAT Without DPI” license has been obsoleted.
> NAT must now be enabled and configured using the “[600-00-7805] NAT/PAT With DPI” license. This license enables CLI privileges only for Enhanced Charging Service (ECSv2) and NAT/PAT with DPI. Stateful Firewall features cannot be enabled/configured with this license. Some CLI commands that are common to both NAT and Stateful Firewall will be available with either NAT or Stateful Firewall license.
> For more information, please contact your local sales representative.
> PDG/TTG Features in Release 9.0
> The PDG/TTG is a new product in Release 9.0. The PDG/TTG enables mobile operators to provide Fixed Mobile Convergence (FMC) services to subscribers with dual-mode handsets and dual-mode access cards via WiFi access points. The PDG/TTG makes it possible for operators to provide secure access to the operator’s 3GPP network from a non-secure network, reduce the load on the macro wireless network, enhance in-building wireless coverage, and make use of existing backhaul infrastructure to reduce the cost of carrying wireless calls.
> This PDG/TTG software release provides TTG functionality. The TTG is a network element that enables 3GPP PDG functionality for existing GGSN deployments. The TTG and the subset of existing GGSN functions work together to provide PDG functionality to the subscriber UEs in the WLAN.
> The PDG/TTG is a licensed product. For information about PDG/TTG licenses, contact your Starent representative.
> IMPORTANT: This PDG/TTG software release provides TTG functionality only. PDG functionality is not supported in this release.
> The TTG features and functions in this release include:

> l | PDG service

> l | TTG mode

> l | IKEv2 and IP Security (IPSec) encryption

> l | Multiple digital certificate selection based on APN

> l | Subscriber traffic policing for IPSec access

> l | DSCP marking for IPSec access

> l | WLAN access control

> l | RADIUS and Diameter support

> l | EAP fast re-authentication

> l | Pseudonym NAI support

> l | Multiple APN support for IPSec access

> l | Congestion control

> l | Bulk statistics

> l | Threshold crossing alerts (TCAs)

> For more information about TTG features and functions, see the PDG/TTG Administration Guide.
> PDIF Features in Release 9.0
> This section provides information for new features in the Packet Data Interworking Function.
> Multiple 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.
> IMPORTANT: In this software release, the PDIF supports IPv4 traffic selectors only.
> Selective Diameter Profile Update Request Control
> For mobile IP calls, the Selective Diameter Profile Update Request Control feature allows WiFi data-only sessions to co-exist with VoIP sessions on the PDIF platform.
> When the PDIF is accessed by voice-enabled devices, it needs to interact with the HSS in order for a subscriber session to access the IP core network. When the PDIF is accessed by data-only devices, there is no need to interact with the HSS.
> 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.
> Selective PUR profiles on the AAA server are mapped to subscribers during AAA authentication via the Radius vendor-specific attribute (VSA) FMC-Type. FMC-Type has these possible values: voice or data. When the AAA server sets the FMC-Type value to voice, the PDIF and the HSS exchange PUR and PUA messages. When the AAA server sets the FMC-Type value to data, the PDIF and the HSS do not exchange PUR and PUA messages.
> For more information about PDIF features and functions, see the Packet Data Interworking Function Administration Guide.
> PDSN Features in Release 9.0
> This section provides information for new features in the Packet Data Serving Node in Release 9.0.
> None for this release.
> Peer-to-Peer Features in Release 9.0
> This section provides information for new features in the inline Peer-to-Peer support.
> Dynamic P2P Signature Updates
> P2P traffic detection is tricky because most of the P2P protocol details are proprietary, and the protocol characteristics change frequently. As these P2P standards are proprietary, there is a tight coupling between the peers too (all the peers need to understand the protocols). Since P2P detection depends heavily on the known traffic characteristics the detection can suffer if the P2P protocol changes, if some existing traffic characteristics were not known (new use case scenarios), if one P2P traffic characteristic matches with another P2P traffic (false positives), and if there are flaws (bugs) in the detection logic. Whenever such degradation in P2P detection logic is identified, the P2P detection logic must be enhanced to improve the detection accuracy.
> In the earlier releases, the P2P detection logic was part of the ST-chassis software load (ST16/ST40 software), to continue to detect new traffic patterns based on the changing traffic characteristics, operators needed to upgrade the complete software with the updated detection logic.
> This release supports dynamic upgrades of the P2P detection logic (signatures) alone on an active ST16/ST40 without warranting a full software upgrade, and hence without a software restart or reboot. This is implemented through signature files.
> IMPORTANT: This release supports dynamic signature upgrades for the following P2P protocols:
> Bittorrent, DirectConnect, eDonkey, Gnutella, Skype, Yahoo
> For more information, see the Peer-to-Peer Detection Administration Guide.
> P2P Protocols Detection Support
> With release 9.0, the system supports detection of the following P2P protocols:

> l | GTalk

> l | Voice

> l | Non-voice

> l | ooVoo

> With release 9.0, the system supports enhanced detection accuracy, for charging purposes, for the following P2P protocols:

> l | GTalk

> l | Voice

> l | Non-voice

> l | Mute

> l | ooVoo

> l | Oscar:

> l | Voice

> l | Non-voice

> l | Pando

> l | QQlive

> l | SopCast

> SCM Features in Release 9.0
> This section provides information for new features in Release 9.0 for the Session Control Manager (SCM). Additional information on these features can be found in the Session Control Manager Overview section of the Product Overview, in the Session Control Manager Administration Guide, and in the CLI Reference Guide.
> IPv4-IPv6 Interworking
> Benefits
> This feature allows the P-CSCF to provide IPv4-IPv6 interworking in the following scenarios:

> l | When UEs are IPv6-only and the IMS core network is IPv4-only

> l | When UEs are IPv4-only and the IMS core network is IPv6-only

> In addition, IPv4-IPv6 interworking helps an IPv4 IMS network transition to an all-IPv6 IMS network.
> The following interworking requirements are currently supported:

> l | IPv4 TCP and IPv6 TCP

> l | Transport switching allowed based on size for both v4 and v6 network

> l | UDP fragmentation allowed for both v4 and v6 networks

> l | P-CSCF supports Mw and Gm interfaces on both v4 and v6

> l | KPIs for Mw and Gm interfaces are supported on both v4 and v6

> l | DNS supported for v4 and v6 networks

> l | Interworking supported for IM and presence

> l | Both v4 and v6 handsets are supported simultaneously on the same P-CSCF node

> Description
> P-CSCF will provide IPv4-IPv6 interworking functionality between IPv6-only UEs and IPv4-only core network elements (I/S-CSCF) by acting as a dual stack. To achieve the dual-stack behavior, P-CSCF will be configured in two services with the first service (V6-SVC) listening on an IPv6 address and the second service (V4-SVC) listening on an IPv4 address. SIP messages coming from IPv6 UEs will come to V6-SVC and will be forwarded to the IPv4 core network through V4-SVC. Similarly, messages from the IPv4 core network come to V4-SVC and will be forwarded to IPv6 UEs via V6-SVC. P-CSCF also provides interworking functionality between IPV4-only UEs and IPv6-only core network elements.
> To identify the need for v4-v6 interworking for a new incoming IPv6 REGISTER arriving at V6-SVC, a route lookup is performed based on the request-uri, first in V4-SVC context and then in V6-SVC context if the first lookup does not return any matching route entry. If a matching IPv4 next-hop route entry is found, then this indicates that interworking needs to be done. If no route entry is found, then a DNS query on request-uri domain is done for both A and AAAA type records. If DNS response yields only an IPv4 address, then this is also the case for performing v4-v6 interworking.
> Headers (such as Via, Path, etc.) are automatically set to IPv4 bind address of P-CSCF V4-SVC. Remaining headers will be not be altered and sent as is toward the S-CSCF. The IPv4 address in a Path header received from S-CSCF in 200Ok of REGISTER will be replaced with V6-SVC’s IPv6 address before forwarding to UE.
> P-CSCF handling different v4-v6 interworking scenarios is shown below.
> Interworking Between IPv6 UE and IPv4 IMS Core Network
> Interworking Between IPv4 UE and IPv6 IMS Core Network
> SGSN Features in Release 9.0
> This section provides information for new features in Release 9.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.
> Configurable Gf IMEI Check Event Timer
> PR 127561; ST16 PR 127561
> The lower boundary for the 1-in-N IMEI check timer has been changed to 1 second. Now the configurable timeout range is 1 to 30 seconds, with a default of 15 seconds.
> Previously, the configurable timeout range was 15 to 30 seconds per the 3GPP specification.
> For more information, refer to the MAP Service Configuration Mode chapter of the Command Line Interface Reference.
> 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.
> 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.
> 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.
> Limits / Engineering Rules
> The following limits for release 9.0 have been modified in the Engineer Rules appendix of the SGSN Administration Guide.

> l | 2G Interface Rules:

> l | Maximum number of NSEs has increased from 256 to 512

> l | Maximum number of NSEs controlling the same RA has increased from 64 to 128

> 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.

> Lawful Intercept
> The SGSN now supports Phase 1 LI Buffering. For details, please contact your customer sales or support representative.
> 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
> With this feature, the 3G SGSN now supports more than one PLMN ID per SGSN. Multiple PLMN support facilitates MS handover from one PLMN to another PLMN.
> Multiple PLMN support also means an operator can 'hire out' their infrastructure to other operators who may wish to use their own PLMN IDs. As well, multiple PLMN support enables an operator to assign more than one PLMN ID to a cell-site or an operator can assign each cell-site a single PLMN ID in a multi-cell network (typically, there are no more than 3 or 4 PLMN IDs in a single network).
> This feature is enabled by configuring, within a single context, multiple instances of either an IuPS service for a single 3G SGSN service. Each IuPS service is configured with a unique PLMN ID. Each of the SGSN services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context.
> Overcharging Protection
> Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs.
> When a mobile is streaming or downloading files from external sources (via background or interactive traffic class) and the mobile goes out of radio coverage, the GGSN is unaware of such loss of connectivity and continues to forward the downlink packets to the SGSN.
> To accommodate such situations, the SGSN can be configured to set a proprietary private IE extension to set the QoS to 0kbps upon a loss of radio coverage occurs. This setting notifies the GGSN of the LORC to prevent overcharging.
> Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the command to configure the GTPC private extension and refer to the IuPS Service Configuration Mode chapter of the Command Line Interface Reference to configure the LORC Cause IE.
> PSC2 - Packet Services Card 2
> The SGSN now supports the Packet Services Card 2 (PSC2), the next-generation packet forwarding card for the ST40. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions. For more information about this card, refer to the “SGSN Overview” in the SGSN Administration Guide and the ST40 Hardware Installation and Administration Guide.
> Suppression of Paging Cause IE in Paging Request
> The CLI has been modified to allow the operator to configure suppression of the Paging Cause IE in a Paging Request. As well, the operator has been given the ability to configure the cause value for various paging sources.
> For details, refer to the ranap command in the RNC Configuration Mode chapter of the Command Line Interface Reference.
> 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
> .
> .
> XGLC - 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. For more information about this card, refer to the “SGSN Overview” in the SGSN Administration Guide and the ST40 Hardware Installation and Administration Guide.
> Web Element Manager Features in Release 9.0
> This section provides information for new features for the Web Element Manager application in Release 9.0.
> None for this release.

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