2b-1 GGSN Product Description v3

GPRS Gateway Service Node (GGSN)

Product Overview

NOTICE OF COPYRIGHT

The material contained in this document is for informational purposes only and is subject to change without notice.

No part of this document may be reproduced, transmitted, transcribed, or stored in a retrieval system in any form or by any means, mechanical, magnetic, optical, chemical, or otherwise without the written permission of Starent Networks, Corp.

Starent, the Starent logo, ST16, and ST40 are registered trademarks of Starent Networks, Corp. How Wireless Connects™ and StarOS™ are trademarks of Starent Networks, Corp.

VA Linux® is a registered trademark of VA Linux Systems, Inc. Microsoft® and Microsoft Windows® are registered trademarks of Microsoft Corporation. Sun®, Solaris®, and Netra® are registered trademarks of Sun Microsystems. Linux® is a registered trademark of Linus Torvalds. Adobe®, Acrobat®, Acrobat Reader® are registered trademarks of Adobe Systems, Inc. CompactFlash™ is a trademark of SanDisk Corporation. Panduit® is a registered trademark or Panduit Corporation. HyperTerminal® is a registered trademark of Hilgraeve Inc. MOLEX® is a registered trademark of Molex, Inc. Rad Hat® is a registered trademark of Red Hat, Inc.

Any trademarks, trade names, service marks, or service names owned or registered by any other company and used in this documentation are the property of their respective companies.

Copyright © 2008 by Starent Networks, Corp. 30 International Place Tewksbury, MA 01876 978.851.1100

All Rights Reserved

Visit us at http://www.starentnetworks.com

TABLE OF CONTENTS

PDP Context Support............................................................................................................................................6 APN Support.........................................................................................................................................................6 GTPP Support .......................................................................................................................................................7 RADIUS Support ..................................................................................................................................................9 DHCP Support ....................................................................................................................................................10 Session Recovery ................................................................................................................................................11 Software Upgrade ...............................................................................................................................................12 Management System Overview ..........................................................................................................................13 Bulk Statistics Support........................................................................................................................................14 Threshold Crossing Alerts (TCA) Support .........................................................................................................16 IP Header Compression ......................................................................................................................................17 IPv6 Support .......................................................................................................................................................17 Mobile IP Home and Foreign Agents .................................................................................................................18 Proxy Mobile IP..................................................................................................................................................19 Session Persistence .............................................................................................................................................20 Access Control List Support ...............................................................................................................................21 Service Steering ..................................................................................................................................................22 IP Policy Forwarding ..........................................................................................................................................23 800 RADIUS Service Groups.............................................................................................................................24 Overlapping IP Address Pool Support ................................................................................................................25 Routing Protocol Support ...................................................................................................................................26 L2TP LAC Support.............................................................................................................................................27 L2TP LNS Support .............................................................................................................................................28 IP Security...........................................................................................................................................................28 Quality of Service Support..................................................................................................................................30 Traffic Policing and Rate Limiting .....................................................................................................................30 Dynamic QoS Renegotiation ..............................................................................................................................32 Intelligent Traffic Control...................................................................................................................................33 Dynamic RADIUS Extensions ...........................................................................................................................34 Lawful Intercept..................................................................................................................................................35 Web Element Management System ....................................................................................................................36 GTPP Storage Server ..........................................................................................................................................37 Enhanced Charging Service Overview ...............................................................................................................38 Content Analysis Support ...................................................................................................................................40 Support for Multiple Detail Record Types .........................................................................................................42 Diameter Credit Control Application..................................................................................................................43 Gy Interface Support...........................................................................................................................................43 ECS Storage Server.............................................................................................................................................45 Gx Interface Support...........................................................................................................................................45 Gx+ Interface Support.........................................................................................................................................46 Streamlined ICAP Interface Support ..................................................................................................................47 GGSN Inter-Chassis Session Recovery ..............................................................................................................49 Converged DSL Support on the GGSN ..............................................................................................................50 Peer-to-Peer Traffic Detection ............................................................................................................................52 Integrated Content Filtering................................................................................................................................53

Starent GGSN Product Description

4

ANSI T1.276 Compliance ..................................................................................................................................54 Inbound Diameter Connections ..........................................................................................................................54 GGSN: Direct Tunnel .........................................................................................................................................55 Multimedia Broadcast / Multicast Services (MBMS).........................................................................................56 802.3ad Link Aggregation in Gigabit Ethernet Line Card..................................................................................56 QoS Renegotiation Extensions ...........................................................................................................................57 Traffic Shaping ...................................................................................................................................................58 Network Controlled QoS (NRSPCA) .................................................................................................................59 Peer to Peer (P2P) Service Enhancements..........................................................................................................60


5


6

GGSN SOFTWARE FEATURE SUMMARY

PDP Context Support

Benefits

Support for subscriber primary and secondary Packet Data Protocol (PDP) contexts in accordance with the following standards:

3GPP TS 23.060 V3.7.0 (2001-01): 3rd Generation Partnership project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description (Release 1999) as an additional reference for GPRS/UMTS procedures

3GPP TS 29.061 v4.5.0 (2002-06): 3rd Generation Partnership Project; Technical Specification Group Core Network; Packet Domain; Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services and Packet Data Networks (PDN) (Release 4)

Description

PDP context processing is based on the APN that the subscriber is attempting to access. Templates for all of the possible APNs that subscribers will be accessing must be configured within the system. Up to 1024 APNs can be configured on the system.

Each APN template consists of parameters pertaining to how PDP contexts are processed such as the following:

Type (IPv4, IPv6, and/or PPP)

Accounting protocol (GTPP or RADIUS)

Authentication protocol (CHAP, MSCHAP, PAP, MSID-based)

Charging characteristics (use SGSN-supplied or use configured)

IP address allocation method (static or dynamic)

PDP Context timers

Mobile IP and Proxy Mobile IP configuration

Quality of Service

A total of 11 PDP contexts are supported per subscriber. These could be all primaries, or 1 Primary and 10 secondaries or any combination of primary and secondary. Note that there must be at least one primary PDP context in order for secondaries to come up.

License Keys

This functionality is enabled by default on the GGSN; no license keys are required to use it.

APN Support

Benefits

The GGSN's Access Point Name (APN) support offers several benefits:


7

Extensive parameter configuration flexibility for the APN.

Creation of subscriber tiers for individual subscribers or sets of subscribers within the APN.

Virtual APNs to allow differentiated services within a single APN.

Description

Up to 1024 APNs may be configured in the GGSN. An APN may be configured for any type of PDP context, i.e., PPP, IPv4, IPv6 or both IPv4 and IPv6. Many dozens of parameters may be configured independently for each APN. Here are a few highlights of what may be configured:

Accounting: RADIUS, GTPP or none. Server group to use. Charging characteristics. Interface with mediation servers.

Authentication: Protocol, such as, CHAP or PAP or none. Default username/password. Server group to use. Limit for number of PDP contexts.

Enhanced Charging: Name of rulebase to use, which holds the enhanced charging configuration (e.g., eG-CDR variations, charging rules, prepaid/postpaid options, etc.).

IP: Method for IP address allocation (e.g., local allocation by GGSN, Mobile IP, DHCP, DHCP relay, etc.). IP address ranges, with or without overlapping ranges across APNs.

Tunneling: PPP may be tunneled with L2TP. IPv4 may be tunneled with GRE, IP-in-IP or L2TP. Load-balancing across multiple tunnels. IPv6 is tunneled in IPv4. Additional tunneling techniques, such as, IPsec and VLAN tagging may be selected by the APN, but are configured in the GGSN independently from the APN.

QoS: IPv4 header ToS handling. Traffic rate limits for different 3GPP traffic classes. Mapping of R98 QoS attributes to work around particular handset defections. Dynamic QoS renegotiation (described elsewhere).

After an APN is determined by the GGSN, the subscriber may be authenticated/authorized with an AAA server. The GGSN allows the AAA server to return VSAs (Vendor Specific Attributes) that override any/all of the APN configuration. This allows different subscriber tier profiles to be configured in the AAA server, and passed to the GGSN during subscriber authentication/authorization.

The GGSN's Virtual APN feature allows the carrier to use a single APN to configure differentiated services. The APN that is supplied by the SGSN is evaluated by the GGSN in conjunction with multiple configurable parameters. Then the GGSN selects an APN configuration based on the supplied APN and those configurable parameters. The configurable parameters are the subscriber's mcc/mnc, whether the subscriber is home/visiting/roaming, the subscriber's domain name and the IP address/range of the SGSN.

License Keys


GTPP Support

Benefits

Support for the GPRS Tunnelling Protocol Prime (GTPP) in accordance with the following standards:


8

3GPP TS 32.015 v3.6.0 (2001-06): 3rd Generation Partnership project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging and billing; GSM call and event data for the Packet Switched (PS) domain (Release 1999) for support of Charging on GGSN

3GPP TS 32.215 V4.6.0 (2003-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Charging data description for the Packet Switched (PS) domain (Release 4)

3GPP TS 29.060 V6.7.0 (2004-12): Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 6)

Description

The system supports the use of GTPP for PDP context accounting. When the GTPP protocol is used, accounting messages are sent to the charging gateways (CGs) over the Ga interface. The Ga interface and GTPP functionality are typically configured within the system’s source context. As specified by the standards, a CDR is not generated when a session starts. CDRs are generated according to the interim triggers configured using the charging characteristics configured for the GGSN, and a CDR is generated when the session ends. For interim accounting, STOP/START pairs are sent based on configured triggers.

GTPP version 2 is always used. However, if version 2 is not supported by the CGF, the system reverts to using GTPP version 1. All subsequent CDRs are always fully-qualified partial CDRs. All CDR fields are R4.

Whether or not the GGSN accepts charging characteristics from the SGSN can be configured on a per-APN basis based on whether the subscriber is visiting, roaming or, home.

By default, the GGSN always accepts the charging characteristics from the SGSN. They must always be provided by the SGSN for GTPv1 requests for primary PDP contexts. If they are not provided for secondary PDP contexts, the GGSN re-uses those from the primary.

If the system is configured to reject the charging characteristics from the SGSN, the GGSN can be configured with its own that can be applied based on the subscriber type (visiting, roaming, or home) at the APN level. GGSN charging characteristics consist of a profile index and behavior settings. The profile indexes specify the criteria for closing accounting records based specific criteria.

The following table provides a summary of when G-CDRs are generated:

Table 1-1 G-CDR Generation Summary

Triggers APN Accounting Mode

SGSN handoff Send CDR based on cc profile configuration

QoS change Send CDR based on cc profile configuration

CLI: cc profile volume limit

Send CDR

CLI: cc profile tariff time Send CDR

CLI: gtpp interim now Send CDR

CLI: radius interim accounting now

-


9

CLI: radius accounting interim interval sec

-

PDP context establishment -

PDP context termination Send CDR

License Keys


RADIUS Support

Benefits

Provides a mechanism for performing authorization, authentication, and accounting (AAA) for subscriber PDP contexts based on the following standards:

RFC-2618, RADIUS Authentication Client MIB, June 1999

RFC-2620, RADIUS Accounting Client MIB, June 1999

RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

RFC-2866, RADIUS Accounting, June 2000

RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000

RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000

RFC-2869, RADIUS Extensions, June 2000

Description

The Remote Authentication Dial-In User Service (RADIUS) protocol is used to provide AAA functionality for subscriber PDP contexts. (RADIUS accounting is optional since GTPP can also be used.)

Within context contexts configured on the system, there are AAA and RADIUS protocol-specific parameters that can be configured. The RADIUS protocol-specific parameters are further differentiated between RADIUS Authentication server RADIUS Accounting server interaction.

Among the RADIUS parameters that can be configured are:

Priority: Dictates the order in which the servers are used allowing for multiple servers to be configured in a single context.

Routing Algorithm: Dictate the method for selecting among configured servers. The specified algorithm dictates how the ST16 distributes AAA messages across the configured AAA servers for new sessions. Once a session is established and a AAA server has been selected, all subsequent AAA messages for the session will be delivered to the same server.

In the event that a single server becomes unreachable, the system attempts to communicate with the other servers that are configured. The system also provides configurable parameters that specify how it should behave should all of the RADIUS AAA servers become unreachable.


10

The system provides an additional level of flexibility by supporting the configuration RADIUS server groups. This functionality allows operators to differentiate AAA services for subscribers based on the APN used to facilitate their PDP context.

In general, 128 AAA Server IP address/port per context can be configured on the system and it selects servers from this list depending on the server selection algorithm (round robin, first server). Instead of having a single list of servers per context, this feature provides the ability to configure multiple server groups. Each server group, in turn, consists of a list of servers.

This feature works in following way:

All RADIUS authentication/accounting servers configured at the context-level are treated as part of a server group named “default”. This default server group is available to all subscribers in that context through the realm (domain) without any configuration.

It provides a facility to create “user defined” RADIUS server groups, as many as 399 (excluding “default” server group), within a context. Any of the user defined RADIUS server groups are available for assignment to a subscriber through the APN configuration within that context.

Since the configuration of the APN can specify the RADIUS server group to use as well as IP address pools from which to assign addresses, the system implements a mechanism to support some in-band radius server implementations (i.e. radius servers which are located in the corporate network, and not in the operator’s network) where the NAS-IP address is part of the subscriber pool. In these scenarios, the ST16 GGSN supports the configuration of the first IP address of the subscriber pool for use as the RADIUS NAS-IP address.

License Keys


DHCP Support

Benefits

Dynamic IP address assignment to subscriber IP PDP contexts using the Dynamic Host Control Protocol as defined by the following standards:

RFC 2131, Dynamic Host Configuration Protocol

RFC 2132, DHCP Options and BOOTP Vendor Extensions

Description

As previously described in the PDP Context Support section of this document, the method by which IP addresses are assigned to a PDP context is configured on an APN-by-APN basis. Each APN template dictates whether it will support static or dynamic addresses.

Dynamically assigned IP addresses for subscriber PDP contexts can be assigned through the use of DHCP.

The system can be configured to support DHCP using either of the following mechanisms:


11

DHCP-proxy: The system assigns an IP address that it receives from a DHCP server. To reduce call setup times, the system requests a group of addresses from the DHCP server immediately after booting. These addresses must match the addresses configured in a static pool on the system.

DHCP-relay: The system forwards DHCP packets received from the MS to a DHCP server and relays responses back to the MS.

License Keys


Session Recovery

Benefits

The Session Recovery feature 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 feature is also useful for Software Patch Upgrade activities. If session recovery feature is enabled during the software patch upgrading, it helps to permit preservation of existing sessions on the active PAC during the upgrade process.

Description

Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of "standby mode" session and AAA managers for each active control processor (CP) being used.

Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate Packet Accelerator Card (PAC) to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The PAC used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

The additional hardware resources required for session recovery include a standby system processor card (SPC) and a standby PAC.

There are two modes for Session Recovery.


12

Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby PAC. In this mode, recovery is performed by using the mirrored "standby-mode" session manager task(s) running on active PACs. The "standby-mode" task is renamed, made active, and is then populated using information from other tasks such as AAA manager.

Full PAC recovery mode: Used when a PAC hardware failure occurs, or when a PAC migration failure happens. In this mode, the standby PAC is made active and the "standby-mode" session manager and AAA manager tasks on the newly activated PAC perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different PACs to ensure task recovery.

License Keys Session Recovery functionality is a licensed feature.

Software Upgrade

Benefits

Performing a software upgrade on the system can be done in one of several ways to minimize impact to system performance and reduce downtime.

Description

ST16 Intelligent Mobile Gateway software can be upgraded by three methods:

Software Patch Upgrade: This limited-use method is only applicable when an interim release of software is made available to correct a defect or other known issue in the operating system. Software patches are based on the same operating system version last made available but with a different build number.

This Software Patch Upgrade method provides a minimally invasive way to upgrade the system while it is on-line. It allows current or new sessions to be supported until such time as they are either self-terminated (subscriber ends session) or automatically terminated by the system based on user-configured thresholds (such as the elapsed session time or the number of sessions being processed). The software patch is then applied to the system, one card at a time, until the entire system has been updated.


13

On-Line Software Upgrade: This method is used to perform a software upgrade of the entire operating system. Like the Software Patch Upgrade Method, this method allows active sessions to be maintained until they are either self-terminated (subscriber ends session) or meet the optionally defined upgrade limit values. The key differences between this on-line method and the software patch method are:

Off-Line Software Upgrade: An off-line software upgrade can be performed for any system, upgrading from any version of operating system software to any version, regardless of version number. This process is considered off-line because while many of the steps can be performed while the system is currently supporting sessions, the last step of this process will take the entire system off-line (by means of rebooting the system) to actually apply the software upgrade.

License Keys

No license keys are required to support the described upgrade methods.

Management System Overview

Benefits

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

Description

Starent ST16 O&M module offers comprehensive management capabilities to the operators and enables them to operate ST16 more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.

These include:

Using the command line interface (CLI)

Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces

Local login through the Console port on SPIO card using an RS-232 serial connection

Using the Web Element Manager application

Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000

Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO

Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)

Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management


14

Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities

Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG's) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.

Figure 1-3 Element Management Methods

License Keys

GGSN management functionality is enabled by default; no license keys are required to use it. However, a separate license is required for the Web Element Manager.

Bulk Statistics Support

Benefits

The system’s support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.


15

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

Description

The ST16 can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. The following schemas are supported:

System: Provides system-level statistics

Card: Provides card-level statistics

Port: Provides port-level statistics

FA: Provides FA service statistics

HA: Provides HA service statistics

IP Pool: Provides IP pool statistics

PPP: Provides Point-to-Point Protocol statistics

GTPC: Provides GPRS Tunneling Protocol - Control message statistics

GTPP: Provides GPRS Tunneling Protocol - Prime message statistics

APN: Provides Access Point Name statistics

RADIUS: Provides per-RADIUS server statistics

ECS: Provides Enhanced Charging Service Statistics

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the IMG or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, IMG host name, IMG uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

License Keys

Bulk statistics functionality is supported on the GGSN by default; ; no license keys are required to use it.


16

Threshold Crossing Alerts (TCA) Support

Benefits

Thresholding on the ST16 is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The ST16 supports Threshold Crossing Alerts for certain key resources such as CPU, memory, IP pool addresses, etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

Description

The following thresholding models are supported by the system:

Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

Thresholding reports conditions using one of the following mechanisms:

SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

Logs are supported in both the Alert and the Alarm models.

Alarm System: High threshold alarms generated within the specified polling interval are considered "outstanding" until a the condition no longer exists or a condition clear alarm is generated. "Outstanding" alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

The Alarm System is used only in conjunction with the Alarm model.

License Keys



17

IP Header Compression

Benefits

Implementing IP header compression provides the following benefits:

Improves interactive response time

Allows the use of small packets for bulk data with good line efficiency

Allows the use of small packets for delay sensitive low data-rate traffic

Decreases header overhead.

Reduces packet loss rate over lossy links.

Description

The system supports the following IP header compression algorithms for subscriber traffic:

Van Jacobsen (VJ) - The RFC 1144 (CTCP) header compression standard was developed by V. Jacobson in 1990. It is commonly known as VJ compression. It describes a basic method for compressing the headers of IPv4/TCP packets to improve performance over low speed serial links.

By default IP header compression using the VJ algorithm is enabled for subscribers.

License Keys No license key is required to implement Van Jacobsen header compression.

IPv6 Support

Benefits

Allows IPv6 subscribers to connect via the GPRS/UMTS infrastructure in accordance with the following standards:

RFC 2460: Internet Protocol, Version 6 (IPv6) Specification

RFC 2461: Neighbor Discovery for IPv6

RFC 2462: IPv6 Stateless Address Autoconfiguration

RFC 3314: Recommendations for IPv6 in 3GPP Standards

RFC 3316: Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts

RFC 3056: Connection of IPv6 domains via IPv4 clouds

3GPP TS 23.060: General Packet Radio Service (GPRS) Service description

3GPP TS 27.060: Mobile Station Supporting Packet Switched Services

3GPP TS 29.061: Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services and Packet Data Networks (PDN)

Description

The GGSN allows an APN to be configured for IPv6 PDP contexts. Also, an APN may be configured to simultaneously allow IPv4 PDP contexts.


18

The GGSN supports IPv6 stateless dynamic auto-configuration. The mobile station may select any value for the interface identifier portion of the address. The link-local address is assigned by the GGSN to avoid any conflict between the mobile station link-local address and the GGSN address. The mobile station uses the interface identifier assigned by the GGSN during the stateless address auto-configuration procedure. Once this has completed, the mobile can select any interface identifier for further communication as long as it does not conflict with the GGSN's interface identifier that the mobile learned through router advertisement messages from the GGSN.

Control and configuration of the above is specified as part of the APN configuration on the GGSN, e.g., IPv6 address prefix and parameters for the IPv6 router advertisements. RADIUS VSAs may be used to override the APN configuration.

Following IPv6 PDP context establishment, the GGSN can perform either manual or automatic 6to4 tunneling, according to RFC 3056, Connection of IPv6 Domains Via IPv4 Clouds.

License Keys

IPv6 functionality is license enabled. The following licenses are required:

IPv6, part numbers 600-00-7521, 600-00-7576

Mobile IP Home and Foreign Agents

Benefits

Consolidation of GGSN, HA and/or FA services on the same platform eliminates CapEx and OpEx requirements for separate network elements and devices under management. Service integration also enables seamless mobility and inter-technology roaming between 1xEV-DO and UMTS/W-CDMA/GPRS/EDGE radio access networks. This shared configuration also enables common address pools to be applied across all service types. In addition, this combination of collapsed services does not create dependencies for Mobile IP client software on the user access device and consequently does not introduce additional requirements for Mobile IP signaling in the 3GPP radio access network.

Description

The ST16 Intelligent Mobile Gateway platform is capable of supporting both GGSN and Mobile IP functions on a single chassis. For Mobile IP applications, the system can be configured to provide the function of a Gateway GPRS Support Node/Foreign Agent (GGSNSN/FA) and/or a Home Agent (HA).

HA and FA components are defined by RFC 2002 in support of Mobile IP. Mobile IP provides a network-layer solution that allows mobile nodes (MNs, i.e. mobile phones, wireless PDAs, and other mobile devices) to receive routed IP packets from their home network while they are connected to any visitor network using their permanent or home IP address. Mobile IP allows mobility in a dynamic method that allows nodes to maintain ongoing communications while changing links as the user traverses the global Internet from various locations outside their home network.

When configured to support HA functionality, the system is capable of supporting these enhanced features:

Mobile IP HA Session Rejection/Redirection: Enables the HA service to either reject new calls or redirect them to another HA when a destination network connection failure is detected. When network connectivity is re-established, the HA service begins to accept calls again in the normal manner. This


19

feature provides the benefit of reducing OpEx through increased operational efficiency and limiting of system downtime.

Mobile IP Registration Revocation: Registration Revocation is a general mechanism whereby the HA providing Mobile IP or Proxy Mobile IP functionality to a mobile node can notify the GGSN/FA of the termination of a binding. Mobile IP Registration Revocation can be triggered at the HA by any of the following:

Administrative clearing of calls

Session Manager software task outage resulting in the loss of FA sessions (sessions that could not be recovered)

Session Idle timer expiry (when configured to send Revocation)

Any other condition under which a binding is terminated due to local policy (duplicate IMSI detected, duplicate home address requested)

This functionality provides the following benefits:

Timely release of Mobile IP resources at the FA and/or HA

Accurate accounting

Timely notification to mobile node of change in service

Mobile IP NAT Traversal: The Mobile IP protocol does not easily accommodate subscriber mobile nodes that are located behind WLAN or WAN-based NAT devices because it assumes that the addresses of mobile nodes or FA's are globally routable prefixes. However, the mobile node's Care of Address (CCoA/CoA) is a private address. This presents a problem when remote hosts try to reach the mobile node via the public advertised addresses. The ST16 provides a solution that utilizes UDP tunneling subject to subscriber reservation requests. In this application, the HA uses IP UDP tunneling to reach the mobile subscriber and includes the same private address that was provided in original reservation request in the encapsulated IP payload packet header.

This functionality enables converged WiFi-cellular data deployments in which the system is used to concentrate and switch traffic between WiFi hotspots. UDP/IP tunneling enables NAT firewalls in WLAN hotspots to maintain state information for address translation between NAT'd public address/UDP ports and addresses that are privately assigned for the mobile access device by a local DHCP server.

License Keys

Basic HA and FA functionality is enabled by default on the GGSN; no license keys are required to use them. However, the following licenses are required to in order to support the Mobile IP NAT Traversal feature:

MIP NAT Traversal, part number 600-00-7557

Proxy Mobile IP

Benefits

Mobility for subscriber sessions is provided through the Mobile IP protocol as defined in RFCs 2002-2005. However, some older mobile nodes (MNs) do not support the Mobile IP protocol. The Proxy Mobile IP feature provides a mobility solution for these MNs.


20

Description

For IP PDP contexts using Proxy Mobile IP, the MN establishes a session with the GGSN as it normally would. However, the GGSN/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the IP PDP context with the GGSN, no Agent Advertisement messages are communicated with the MN).

The MN is assigned an IP address by either the HA, a AAA server, or on a static-basis. The address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.

Proxy Mobile IP can be performed on a per-subscriber basis based on information contained in their user profile, or for all subscribers facilitated by a specific APN. In the case of non-transparent IP PDP contexts, attributes returned from the subscriber’s profile take precedence over the configuration of the APN.

License Keys


Session Persistence

Benefits

Provides seamless mobility to mobile subscribers as they roam between WiLAN and 3G cellular access networks. This type of inter-technology roaming is ordinarily not possible as wireline access networks do not include SGSN’s to permit inter-SGSN call hand-offs with cellular access networks.

Descriptions

The Starent Session Persistence Solution maintains consistent user identities and application transparency for your mobile subscribers as they roam across bearer access networks. This is accomplished through the integration of Home Agent (HA) and GGSN functionality on the wireless access gateway in the packet network and the use of standards-based protocols such as Mobile IP and Mobile IP NAT Traversal. The solution also includes Session Persistence client software that runs on dual-mode WiFi/GPRS/EDGE and/or UMTS/W-CDMA access devices including cellular phones and laptop computers with wireless data cards. The Session Persistence client is designed to permit Mobile IP tunneling over the applicable underlying network including cellular access connections and cable or XDSL broadband access networks. When the user is attached to a WiFi access network, the Session Persistence client utilizes a Mobile IP Co-located Care of Address Foreign Agent Service (CCoA FA) and establishes a MIP tunnel to the HA service in the ST16 platform. This scenario is completely transparent to the GGSN service that operates in the same ST16. The Mobile IP protocol requires a publicly addressable FA service; however, this is a problem when the mobile subscriber is located behind a NAT firewall. In this case, the NAT firewall has no way of maintaining state to associate the public NAT’d address with the private address assigned to the user by local DHCP server. Mobile IP NAT Traversal solves this problem by establishing a UDP/IP tunnel between the subscriber access device and Home Agent. The NAT firewall uses the UDP port address to build state for the subscriber session. During this Mobile IP transaction, the HA establishes a mobility binding record for the subscriber session.


21

When the subscriber roams to a 3GPP cellular access network, it uses the IP address from normal PDP IP context establishment as its new Mobile IP Care of Address to refresh the mobility binding record at the ST16 Home Agent. For reduced latency between access hand-offs, it is also possible to utilize a permanent ‘always-on’ PDP IP context with the IP address maintained in the MIP session persistence client. In this scenario, the mobile access device only needs to re-establish the dormant RAB wireless connection with the 3GPP access network prior to transmitting a new Mobile IP registration.

The ST16 also enables network-provisioned VPN’s for Session Persistence applications by permitting use of overlapping address pools on the HA and using various tunneling protocols including IPSEC, Layer 2 Tunneling Protocol (L2TP) and Ethernet IEEE 802.1Q VLAN’s for separation of subscriber traffic. This application may be further augmented by additional features such as 800 RADIUS Server Groups to permit use of enterprise controlled AAA servers and custom dictionaries.

License Keys

Use of the Session Persistence feature requires the following licenses:

HA for GGSN Software license, 10K sessions, part number 600-00-7592

GGSN Software license, 10K sessions, part number 600-00-7545

IMPORTANT Other licenses (i.e. IP Security and L2TP) may be additionally required depending on your implementation.

Access Control List Support

Benefit

Access Control Lists provide a mechanism for controlling (i.e permitting, denying, redirecting, etc.) packets in and out of the system.

Description

IP access lists, or access control lists (ACLs) as they are commonly referred to, are used to control the flow of packets into and out of the system. They are configured on a per-context basis and consist of "rules" (ACL rules) or filters that control the action taken on packets that match the filter criteria. Once configured, an ACL can be applied to any of the following:

An individual interface

All traffic facilitated by a context (known as a policy ACL)

An individual subscriber

All subscriber sessions facilitated by a specific context

There are two primary components of an ACL:

Rule: A single ACL consists of one or more ACL rules. As discussed earlier, the rule is a filter configured to take a specific action on packets matching specific criteria. Up to 128 rules can be configured per ACL.

Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.


22

Rule Order: A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.

License Keys


Service Steering

Benefits

The advantages of the integrated Service Steering Architecture are:

Eliminates the cost of purchasing an external load balancer

Simplifies management into one platform

The ST16 is subscriber aware so it can perform more sophisticated Service Steering operations than an external Service Steering platform which is not subscriber aware.

The Service Steering Architecture performs load balancing and bypass for external application servers.

Description

The Service Steering Architecture, also know as Content Service Steering (CSS), defines how traffic is handled by the ST16 platform based on the content of the data presented by a mobile subscriber. It is a broad term that includes features such as load balancing, NAT, HTTP redirection, and DNS redirection. These features are currently available in external load balancers sold by several different vendors. Service Steering can be considered an inline service, but should not be confused with a content server. Service Steering controls how the subscriber data is forwarded to a particular inline server, but does not control the content.

In addition to external application servers, Service Steering can also be used to direct traffic to inline servers or services that are internal to the ST16 .


23

Figure 1-4 Service Steering Examples

Service Steering is applied when a subscriber session is created, by downloading service policies from RADIUS or LDAP. This policy information can include items such as:

The services allowed for the subscriber

The sequence on which those services should be applied

Allowed QoS for the subscriber

The Network to which the subscriber belongs (VPN, etc.)

In-line service examples:

Enhanced Charging: The Starent Enhanced Charging Service (ECS) feature provides full stateful inspection and awareness of layer 3 through layer 7 application protocols.

Traffic Optimization: The Starent Traffic Performance Optimization (TPO) feature provides optimization and acceleration of subscriber traffic over mobile wireless links. Utilizing both compression and optimization techniques.

VPN Services: To provide maximal flexibility in connecting to network-based services such as VPNs, the ST16 supports the most comprehensive suite of tunneling protocols in the industry

License Keys

Different license keys are required based on the service(s) to be implemented. Please contact your local Sales or Support representative for additional information.

IP Policy Forwarding

Benefits

IP Policy Forwarding enables the routing of subscriber data traffic to specific destinations based on configuration. This functionality can be implemented in support of enterprise-specific applications (i.e. routing traffic to specific enterprise domains) or for routing traffic to back-end servers for additional processing.


24

Description

The system can be configured to automatically forward data packets to a predetermined network destination. This can be done in one of three ways:

IP Pool-based Next Hop Forwarding - Forwards data packets based on the IP pool from which a subscriber obtains an IP address.

ACL-based Policy Forwarding - Forwards data packets based on policies defined in Access Control Lists (ACLs) and applied to contexts or interfaces.

Subscriber specific Next Hop Forwarding - Forwards all packets for a specific subscriber.

The simplest way to forward subscriber data is to use IP Pool-based Next Hop Forwarding. An IP pool is configured with the address of a next hop gateway and data packets from all subscribers using the IP pool are forward to that gateway.

Subscriber Next Hop forwarding is also very simple. In the subscriber configuration a nexthop forwarding address is specified and all data packets for that subscriber are forwarded to the specified nexthop destination.

ACL-based Policy Forwarding gives you more control on redirecting data packets. By configuring an Access Control List (ACL) you can forward data packets from a context or an interface by different criteria, such as; source or destination IP address, ICMP type, or TCP/UDP port numbers.

ACLs are applied first. If ACL-based Policy Forwarding and Pool-based Next Hop Forwarding or Subscriber are configured, data packets are first redirected as defined in the ACL, then all remaining data packets are redirected to the next hop gateway defined by the IP pool or subscriber profile.

License Keys


800 RADIUS Service Groups

Benefits

Value-added feature to enable VPN service provisioning for enterprise or MVNO customers. Enables each corporate customer to maintain its own AAA servers with its own unique configurable parameters and custom dictionaries.

Description

This feature provides support for up to 800 RADIUS AAA server groups and 800 NAS IP addresses that can be provisioned within a single context or across the entire chassis. A total of 128 servers can be assigned to an individual server group. Up to 1,600 accounting, authentication and/or mediation servers are supported per chassis and may be distributed across a maximum of 1,000 APN's. This feature also enables the AAA servers to be distributed across multiple APN within the same context.

IMPORTANT Due to additional memory requirements, this service can only be used with 8GB Packet Accelerator Cards (PAC's).


25

License Keys

No license will be required to support this functionality.

Overlapping IP Address Pool Support

Benefits

Overlapping IP Address Pools provides a mechanism for allowing operators to more flexibly support multiple corporate VPN customers with the same private IP address space without the expensive investments in physically separate routers, or expensive configurations using virtual routers.

Description

The ST16 supports two type of overlapping pools: resource and overlap. Resource pools are designed for dynamic assignment only, and use a VPN tunnel, such as a GRE tunnel, to forward and received the private IP addresses to and from the VPN. Overlapping type pools can be used for both dynamic and static, and use VLANs and a next hop forwarding address to connect to the VPN customer.

To forward downstream traffic to the correct PDP context, the GGSN uses either the GRE tunnel ID, or the VLAN ID to match the packet. When forwarding traffic upstream, the GGSN uses the tunnel and forwarding information in the IP pool configuration, so overlapping pools must be configured in the APN for this feature to be used.

When a PDP context is created, the IP addresses is either assigned from the IP pool, in this case the forwarding rules are also configured into the GGSN at this point. If the address is assigned statically, when the GGSN confirms the IP address from the pool configured in the APN, the forwarding rules are also applied.

Figure 1-5 Typical GGSN/Corporate Network Connection Using VLAN

The GGSN can scale to as many actual overlapping pools as there are VLAN interfaces per context, and there can be multiple contexts per GGSN, or when using resource then the limit is the number of IP pools.


26

This scalability allows operators, who wish to provide VPN services to customers using the customer's private IP address space, need not be concerned about escalating hardware costs, or complex configurations.

License Keys


Routing Protocol Support

Benefits

The system’s support for various routing protocols and routing mechanism provides an efficient mechanism for ensuring the delivery of subscriber data packets.

Description

The following routing mechanisms and protocols are supported by the system:

Static Routes: The system supports the configuration of static network routes on a per context basis. Network routes are defined by specifying an IP address and mask for the route, the name of the interface in the currant context that the route must use, and a next hop IP address.

Open Shortest Path First (OSPF) Protocol version 2: A link-state routing protocol, OSPF is an interior gateway protocol (IGP) that routes IP packets based solely on the destination IP address found in the IP packet header using the shortest path first. IP packets are routed "as is", meaning they are not encapsulated in any further protocol headers as they transit the network.

Variable length subnetting, areas, and redistribution into and out of OSPF are supported.

OSPF routing is supported in accordance with the following standards:

RFC-1587, OSPF NSSA Option, March 1994

RFC-1850, OSPF Version 2 Management Information Base, November 1995

RFC-2328, OSPF Version 2, April 1998

Border Gateway Protocol version 4 (BGP-4): The ST16 supports a subset of BGP (RFC-1771, A Border Gateway Protocol 4 (BGP-4)), suitable for eBGP support of multi-homing typically used to support geographically redundant mobile gateways, is supported.

EBGP is supported with multi-hop, route filtering, redistribution, and route maps. The network command is support for manual route advertisement or redistribution.

BGP route policy and path selection is supported by the following means:

Prefix match based on route access list,

AS path access-list,

Modification of AS path through path prepend,

Origin type,

MED,

Weight


27

Route Policy: Routing policies modify and redirect routes to and from the system to satisfy specific routing needs. The following methods are used with or without active routing protocols (i.e. static or dynamic routing) to prescribe routing policy:

Route Access Lists: The basic building block of a routing policy, route access lists filter routes based upon a specified range of IP addresses.

IP Prefix Lists: A more advanced element of a routing policy. An IP Prefix list filters routes based upon IP prefixes.

AS Path Access Lists: A basic building block used for Border Gateway Protocol (BGP) routing, these lists filter Autonomous System (AS) paths.

Route Maps: Route-maps are used for detailed control over the manipulation of routes during route selection or route advertisement by a routing protocol and in route redistribution between routing protocols. This detailed control is achieved using IP Prefix Lists, Route Access Lists and AS Path Access Lists to specify IP addresses, address ranges, and Autonomous System Paths.

Equal Cost Multiple Path (ECMP): ECMP allows distribution of traffic across multiple routes that have the same cost to the destination. In this manner, throughput load is distributed across multiple path, typically to lessen the burden on any one route and provide redundancy. The mobile gateway supports from four to ten equal-cost paths.

License Keys


L2TP LAC Support

Benefits

The system configured as a Layer 2 Tunneling Protocol Access Concentrator (LAC) enables communication with L2TP Network Servers (LNSs) for the establishment of secure virtual private network (VPN) tunnels between the operator and a subscriber’s corporate or home network.

Description

The use of L2TP in VPN networks is often used as it allows the corporation to have more control over authentication and IP address assignment. An operator may do a first level of authentication, however use PPP to exchange user name and password, and use IPCP to request an address. To support PPP negotiation between the GGSN and the corporation, an L2TP tunnel must be setup in the GGSN running a LAC service.

L2TP establishes L2TP control tunnels between LAC and LNS before tunneling the subscriber PPP connections as L2TP sessions. The ST16 LAC service is based on the same architecture as the GGSN and benefits from dynamic resource allocation and distributed message and data processing. This design allows the ST16 LAC service to support over 4000 setups per second or a maximum of over 3G of throughput. There can be a maximum up to 65535 sessions in a single tunnel and as many as 500,000 L2TP sessions using 32,000 tunnels per system.

The LAC sessions can also be configured to be redundant, thereby mitigating any impact of hardware of software issues. Tunnel state is preserved by copying the information across processor cards.


28

License Keys

L2TP LAC functionality is license enabled. The following license is required:

L2TP LAC, part numbers 600-00-7508, 600-00-7530

L2TP LNS Support

Benefits

The system configured as a Layer 2 Tunneling Protocol Network Server (LNS) supports the termination secure virtual private network (VPN) tunnels between from L2TP Access Concentrators (LACs).

Description

The ST16 LNS service takes advantage of the high performance PPP processing already supported in the ST16 design and is a natural evolution from the LAC. The ST16 LNS can be used as a standalone, or running alongside a GGSN service in the same platform, terminating L2TP services in a cost effective and seamless manner.

L2TP establishes L2TP control tunnels between LAC and LNS before tunneling the subscriber PPP connections as L2TP sessions. There can be a maximum of up to 65535 sessions in a single tunnel and up to 500,000 sessions per LNS.

The LNS architecture is similar to the ST16 GGSN and utilizes the concept of a de-multiplexer to intelligently assign new L2TP sessions across the available software and hardware resources on the platform without operator intervention.

License Keys

L2TP LNS functionality is license enabled in blocks of 10000 sessions. The following license is required:

L2TP LNS 10k Sessions, part numbers 600-00-7503

IP Security

Benefits

IPSecurity provides a mechanism for establishing secure tunnels from mobile subscribers to pre-defined endpoints (i.e. enterprise or home networks) in accordance with the following standards:

RFC 2401, Security Architecture for the Internet Protocol

RFC 2402, IP Authentication Header (AH)

RFC 2406, IP Encapsulating Security Payload (ESP)

RFC 2409, The Internet Key Exchange (IKE)

RFC-3193, Securing L2TP using IPSEC, November 2001

Description

IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure


29

tunnels with peer security gateways. IPSec can be implemented on the system for the following applications:

PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. IPSec Applications shows IPSec configurations.

Figure 1-6 IPSec Applications

Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.

Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.

License Keys

IP Security is a license enabled feature. The following licenses are required:


30

IPSec, part number 600-00-7507

Quality of Service Support

Benefits

Provides operator control over the prioritization of different types of traffic.

Description

Quality of Service (QoS) provides internal processing prioritization based on needs, and DiffServ remarking to allow external devices to perform prioritization.

The features described here are internal prioritization and DiffServ remarking for external prioritization. See the Traffic Policing and Rate Limiting feature, the Dynamic QoS Renegotiation feature and the Intelligent Traffic Control feature descriptions, for additional QoS capabilities of the GGSN.

Every CPU on the GGSN has 7 queues for receiving packets. There are 3 system queues (traffic for the Operating System kernel, traffic for the protocols and traffic for logging) and 4 queues for subscriber data. The 4 data queues are for internal prioritization of the subscriber traffic. The data queues are internally labeled "gold", "silver", "bronze" and "best-effort". When traffic for a subscriber arrives at the GGSN, the data queue is selected according to the configuration option, as follows.

Always put it onto the best-effort queue.

Put it onto the queue configured for that subscriber or subscriber tier.

Use the DiffServ marking to determine which queue to use.

Traffic is emptied from the data queues on a priority basis, with rate-limiting for individual queues and bandwidth-borrowing when queues are not using their complete limits.

External prioritization (i.e., the value to use for the DiffServ marking) is configured differently for the uplink and downlink directions. In the uplink direction, each APN is configurable for the DiffServ ToS value to use for each of the 3GPP traffic classes. Alternatively, you can configure "pass-through", whereby the ToS value will pass through unchanged.

In the downlink direction, the ToS value of the subscriber packet is not changed, but you can configure what to use for the ToS value of the outer GTP tunnel. The value for ToS is configurable for each of the 3GPP traffic classes. In addition, the connections between the GGSN and one or more SGSNs can be configured as a "GGSN Service", and different values for ToS for the same 3GPP traffic class may be configured for different GGSN Services.

License Keys


Traffic Policing and Rate Limiting

Benefits

Allows the operator to proportion the network and support service-level agreements (SLAs) for customers.


31

Description

The Traffic-Policing feature enables configuring and enforcing bandwidth limitations on individual PDP contexts of a particular 3GPP traffic class. Values for traffic classes are defined in 3GPP TS 23.107 and are negotiated with the SGSN during PDP context activation using the values configured for the APN on the GGSN. Configuration and enforcement is done independently on the downlink and the uplink directions for each of the 3GPP traffic classes. Configuration is on a per-APN basis, but may be overridden for individual subscribers or subscriber tiers during RADIUS authentication/authorization.

A Token Bucket Algorithm (a modified trTCM, as specified in RFC2698) is used to implement the Traffic-Policing feature. The algorithm measures the following criteria when determining how to mark a packet.

Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets may be transmitted/received for the subscriber during the sampling interval.

Peak Data Rate (PDR): The maximum rate (in bits per second) that packets may be transmitted/received for the subscriber during the sampling interval.

Burst-size: The maximum number of bytes that may be transmitted/received for the subscriber during the sampling interval for both committed (CBS) and peak (PBS) rate conditions. This represents the maximum number of tokens that can be placed in the subscriber's "bucket". Note that the committed burst size (CBS) equals the peak burst size (PBS) for each subscriber.

Tokens are removed from the subscriber's bucket based on the size of the packets being transmitted/received. Every time a packet arrives, the system determines how many tokens need to be added (returned) to a subscriber's CBS (and PBS) bucket. This value is derived by computing the product of the time difference between incoming packets and the CDR (or PDR). The computed value is then added to the tokens remaining in the subscriber's CBS (or PBS) bucket. The total number of tokens can not be greater than the configured burst-size. If the total number of tokens is greater than the burst-size, the number is set to equal the burst-size. After passing through the Token Bucket Algorithm, the packet is internally classified with a color, as follows:

There are not enough tokens in the PBS bucket to allow a packet to pass, then the packet is considered to be in violation and is marked "red" and the violation counter is incremented by one.

There are enough tokens in the PBS bucket to allow a packet to pass, but not in the CBS "bucket", then the packet is considered to be in excess and is marked "yellow", the PBS bucket is decremented by the packet size, and the exceed counter is incremented by one.

There are more tokens present in the CBS bucket than the size of the packet, then the packet is considered as conforming and is marked "green" and the CBS and PBS buckets are decremented by the packet size.

The APN on the GGSN can be configured with actions to take for red and yellow packets. Any of the following actions may be specified.

Drop: The offending packet is discarded.

Transmit: The offending packet is passed.

Lower the IP Precedence: The packet's ToS octet is set to "0", thus downgrading it to Best Effort, prior to passing the packet.

Different actions may be specified for red and yellow, as well as for uplink and downlink directions and different 3GPP traffic classes.


32

Refer to the Intelligent Traffic Control section for additional policing and rate-limiting capabilities of the GGSN.

License Keys

Traffic policing is a license enabled feature. The following license is required:

Per Subscriber Traffic Policing / Shaping, part number 600-00-7542

Dynamic QoS Renegotiation

Benefits

In the present implementation of QoS for GPRS/UMTS services, mobile operators are limiting the profit potential of their networks by architecting the QoS service around the application. However, it is clear that the QoS granted to each subscriber does not depend on the type of application, but only by the Access Point Name (APN) used. As a result, significant quantities of expensive radio resources are reserved for subscribers that don't require them. Because these subscribers won't use most of the bandwidth allocated, the operator will not realize the expected revenues. At the same time, subscribers with real needs and a potential to generate substantial revenues can get rejected or experience poor service quality.

Some solutions exist to overcome this issue, for example, secondary PDP contexts. However, most require features that are not available in most handsets or core networks. With the Dynamic QoS Renegotiation feature, the GGSN analyses the transactions performed by the subscriber and triggers QoS renegotiations with the SGSN in order to grant the QoS that optimizes both the service provided to the subscriber as well as the allocation of radio resources.

Description

Dynamic QoS Renegotiation involves the following processes.

Initial QoS

Service Detection

Classification of Application Traffic

Quality of Service Renegotiation

Following the renegotiation, CDRs are generated that include the current QoS and optionally the services accessed.

Here is an example of QoS renegotiation. Subscriber_1 and Subscriber_2 have "gold" and "silver" profiles respectively.


33

Figure 1-7 Example QoS Renegotiation

Both profiles are the same, except the gold profile subscribers get double the bandwidth for Interactive applications, such as web browsing. Initially, both subscribers are granted the QoS for the Interactive traffic class. Note that the gold subscriber gets double the bandwidth of the silver subscriber.

When the GGSN detects the start of a streaming application, it renegotiates the QoS to be that of the Streaming traffic class. After the streaming traffic ends and a dampening timer expires, the GGSN renegotiates the QoS to be that of the Interactive traffic class. All renegotiations are performed by the GGSN using the update PDP context messaging with the SGSN.

The diagram next illustrates the detection of traffic desiring a Conversational traffic class. The QoS is renegotiated, and then renegotiated back to the Interactive traffic class after the video call terminates.

The Dynamic QoS Renegotiation feature can be enabled on a per-APN basis, but may be overridden for individual subscribers or subscriber tiers during RADIUS authentication/authorization.

License Keys

Dynamic QoS Renegotiation is a license enabled feature. The following license is required:

GGSN Dynamic QoS Renegotiation, part number 600-00-7556

Intelligent Traffic Control

Benefits

Enables operators to provide differentiated tiered service provisioning for native and non-native subscribers.

Description

Mobile carriers are looking for creative methods for maximizing network resources while, at the same time, enhancing their end users overall experience. These same mobile operators are beginning to


34

examine solutions for providing preferential treatment for their native subscribers and services as compared to, for example, roaming subscribers, Mobile Virtual Network Operators (MVNOs) and/or Peer-to-Peer (P2P) applications. The overall end goal is to provide superior levels of performance for their customers/services, while ensuring that non-native users/applications do not overwhelm network resources.

ITC provides the ability to examine each subscriber session and respective flow(s) such that selective, configurable limits on a per-subscriber/per-flow basis can be applied. Initially, QoS in this context is defined as traffic policing on a per-subscriber/per-flow basis with the potential to manipulate Differentiated Services Code Points (DSCPs), queue redirection (i.e. move traffic to a Best Effort (BE) classification) and/or simply dropping out of profile traffic. ITC enables 5 tuple packet filters for individual application flows to be either manually configured via CLI or dynamically established via RSVP TFT IE's in 1xEV-DO Rev A or as a consequence of PDP context establishments in UMTS/W-CDMA networks. Policy rules may be locally assigned or obtained from an external PCRF via push/pull policy signaling interactions. Policies may be applied on a per-subscriber, per-context and/or chassis-wide basis.

License Keys

Intelligent Traffic Control is a license enabled feature. The following license is required:

Intelligent Traffic Control, part number 600-00-7568

Dynamic RADIUS Extensions

Benefits

Dynamic RADIUS extension support provide operators with greater control over subscriber PDP contexts by providing the ability to dynamically redirect data traffic, and or disconnect the PDP context.

This functionality is based on the following standard:

RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003

Description

The system supports the configuration and use of the following dynamic RADIUS extensions:

Change of Authorization: The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session.

Disconnect Message: The DM message is used to disconnect subscriber sessions in the system from a RADIUS server. The DM request message should contain necessary attributes to identify the subscriber session.

The above extensions can be used to dynamically re-direct subscriber PDP contexts to an alternate address for performing functions such as provisioning and/or account set up. This functionality is referred to as Session Redirection, or Hotlining.

Session redirection provides a means to redirect subscriber traffic to an external server by applying ACL rules to the traffic of an existing or a new subscriber session. The destination address and optionally the


35

destination port of TCP/IP or UDP/IP packets from the subscriber are rewritten so the packet is forwarded to the designated redirected address.

Return traffic to the subscriber has the source address and port rewritten to the original values. The redirect ACL may be applied dynamically by means of the Radius Change of Authorization (CoA) extension.

License Keys

Dynamic RADIUS extensions is a license enabled feature. The following license is required:

Change of Authorization, part number 600-00-7518

Lawful Intercept

Benefits

The system supports the lawful interception (LI) of subscriber session information. This functionality provides Telecommunication Service Providers (TSPs) with a mechanism to assist Law Enforcement Agencies (LEAs) in the monitoring of suspicious individuals (referred to as targets) for potential criminal activity.

The following standards were referenced for the system’s LI implementation:

TR-45 Lawfully Authorized Electronic Surveillance TIA/EIA J-STD-025 PN4465 RV 1.7

3GPP TS 33.106 V6.1.0 (2004-06): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful Interception requirements (Release 6)

3GPP TS 33.107 V6.2.0 (2004-06): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Lawful interception architecture and functions (Release 6)

Technical Directive: Requirements for implementing statutory telecommunications interception measures (TR TKÜ), Version 4.0

Description

LEAs provide one or more TSPs with court orders or warrants requesting the monitoring of a particular target. The target is identified by information such as their mobile station Integrated Services Digital Network (MSISDN) number, or their international mobile subscriber identification (IMSI) number.

Once the target has been identified, the system, functioning as either a GGSN or HA, serves as an access function (AF) and performs monitoring for both new PDP contexts or PDP contexts that are already in progress. While monitoring, the system intercepts and duplicates Content of Communication (CC) and/or Intercept Related Information (IRI) and forwards it to a delivery function (DF) over an extensible, proprietary interface. Note that when a target establishes multiple, simultaneous PDP contexts, the system intercepts CC and IRI for each of them. The DF, in turn, delivers the intercepted content to one or more collection functions (CFs).

License Keys

Lawful Intercept is a license-enabled feature. The following licenses are required:


36

Lawful Intercept, part number 600-00-7522

Enhanced Lawful Intercept, part number 600-00-7567

Web Element Management System

Benefits

Provides a graphical user interface (GUI) for performing fault, configuration, accounting, performance, and security (FCAPS) management of the ST16 Intelligent Mobile Gateway.

Description

The ST16 Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete fault, configuration, accounting, performance, and security (FCAPS) management capability for the system.

For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more ST16's via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.

The following figure demonstrates various interfaces between the Starent Web Element Manager and other network components.

Figure 1-8 Web Element Manager Network Interfaces


37

Minimum System Requirements

Web Element Manager Server Recommendations:

SUN Microsystems SUN FIRE V240 server

1.34 GHz UltraSPARC IIIi processors

2 GB RAM

73 GB SCSI Hard Disk Drive

Dual Ethernet interfaces (10/100 or 1000 Mbps)

Internal CD-ROM drive

Operating Environment:

Solaris 8 with Recommended Patch Cluster dated January 25, 2005 (minimum)

Solaris 9 with Recommended Patch Cluster dated January 25, 2005 (minimum)

Web Element Manager Client Recommendations

Workstation supporting Solaris/Sun, Linux, UNIX, Microsoft Windows XP, Windows 2000, or Windows NT operating system

Java Runtime Environment (JRE) version 1.4.x or 1.5.x

Java policy file (obtained during initial access to the Web Element Manager server)

Microsoft Internet Explorer version 5.0 (or higher), Netscape Navigator version 4.72 (or higher), or other Internet browser

License Keys

A license key is required in order to use the Web Element Manager application. Please contact your local Sales or Support representative for more information.

GTPP Storage Server

Benefits

The GGSN Storage Server (GSS) enables the backing-up of charging data records to an external storage server whenever they cannot be sent to the charging system. This reduces the risk of accounting data loss.

Description

Peripheral CDR storage for the ST16 GGSN is performed by the GGSN Storage Server (GSS). The GSS is based on Sun server and RAID arrays. CDRs are transmitted in parallel to GSS and to the CGF to ensure that CDRs are not lost in case of CGF unavailability. When the CGF has acknowledged the reception of the GCDRs, these CDRs are updated in GSS (acknowledged CDRs are tagged on GSS). The transmission of GCDRs to GSS is performed using a variant of GTPP that enables updates to the GCDRs once the response from the CGF has been received.

GSS stores GTPP requests with the database, each request containing 1 or more GCDRs. The GCDRs are transferred to flat files after a configured time interval or configured GCDR count. One million GCDRs typically require 255MB of storage space. The amount of data that can be stored at GCDR storage server


38

depends upon how frequently the billing-system/CGF retrieves data from the GCDR storage server. Retrieval of CDRs on GSS is performed using FTP or SFTP.

To ensure the high availability of the GSS itself, it is possible to deploy the GSS in clustered environment with redundant storage facility.

The GSS enhances the mobile carrier's ability to manage the charging detail records and provide abilities to backup the billing/charging data redundancy for the billing systems, with or without a Charging Gateway function (CGF). It also generates CDR files for the off-line billing system.

The GSS functions with a GGSN in a GPRS/UMTS network with or without a CGF.

License Keys

No license is needed to run the GTPP Storage Server.

Enhanced Charging Service Overview

Benefits

The Enhanced Charging Service provides an integrated in-line service for inspecting subscriber data packets and generating detail records to enable billing based on usage and traffic patterns.

Description

The Enhanced Charging Service (ECS) is an in-line service feature that is integrated within the system. ECS enhances the mobile carrier's ability to provide flexible, differentiated, and detailed billing to subscribers by using Layer 3 through Layer 7 Deep Packet inspection with the ability to integrate with back-end billing mediation systems.

ECS interacts with active mediation systems to provide full real-time prepaid and active charging capabilities. Here the active mediation system provides the rating and charging function for different applications.

In addition, ECS also includes extensive record generation capabilities for post-paid charging with in-depth understanding of the user session. Refer to the Support for Multiple Detail Record Types section for more information.

The major components include:

Service Steering: Directs subscriber traffic into the ECS subsystem. Service Steering is used to direct selective subscriber traffic flows via an Access Control List (ACL). It is used for other redirection applications as well for both internal and external services and servers.

Protocol Analyzer: The software stack responsible for analyzing the individual protocol fields and states during packet inspection. It performs two types of packet inspection:

Shallow Packet Inspection: inspection of the layer 3 (IP header) and layer 4 (e.g. UDP or TCP header) information.

Deep Packet Inspection: inspection of layer 7 and 7+ information. Deep packet inspection functionality includes:


39

Detection of URI (Uniform Resource Identifier) information at level 7 (e.g., HTTP, WTP, RTSP Uniform Resource Locators (URLs))

Identification of true destination in the case of terminating proxies, where shallow packet inspection would only reveal the destination IP address / port number of a terminating proxy

De-encapsulation of upper layer protocol headers, such as MMS-over-WTP, WSP-over-UDP, and IP-over GPRS

Verification that traffic actually conforms to the protocol the layer 4 port number suggests

Rule Definitions: User-defined expressions, based on protocol fields and/or protocol-states, which define what actions to take when specific field values are true. Expressions may contain a number of operator types (string, =, >, etc.) based on the data type of the operand. Each Ruledef configuration is consisting of multiple expressions applicable to any of the fields or states supported by the respective analyzers.

Rule Bases: a collection of rule definitions and their associated billing policy. The rule base determines the action to be taken when a rule is matched. It is possible to define a rule definition with different actions.

Figure 1-9 Enhanced Charging Service Components

Mediation and Charging Methods

To provide maximum flexibility when integrating with billing mediation systems, ECS supports a full range of charging and authorization interfaces.

Pre-paid: In a pre-paid environment, the subscribers pay for service prior to use. While the subscriber is using the service, credit is deducted from subscriber's account until it is exhausted or call ends. The pre-paid accounting server is responsible for authorizing network nodes (GGSNs) to grant access to the user, as well as grant quotas for either time connected or volume used. It is up to the network node


40

to track the quota use, and when these use quotas run low, the network node sends a request to the pre-paid server for more quota.

If the user has not used up the purchased credit, the server grants quota and if no credit is available to the subscriber the call will be disconnected. ECS and DCCA manage this functionality by providing the ability to setup quotas for different services.

Pre-paid quota in ECS is implemented using DIAMETER Credit Control Application (DCCA) for the GGSN. DCCA supports the implementation of real-time credit control for a variety of services, such as networks access, messaging services, and download services.

In addition to being a general solution for real-time cost and credit control, DCCA includes these features:

Real-time Rate Service Information-DCCA can verify when end subscribers' accounts are exhausted or expired; or deny additional chargeable events.

Support for Multiple Services-DCCA supports the usage of multiple services within one subscriber session. Multiple Service support includes:

The ability to identify and process the service or group of services that are subject to different cost structures.

Independent credit control of multiple services in a single credit control sub-session.

Refer to the Diameter Credit Control Application section for more information.

Post-paid: In a post-paid environment, the subscribers pay after use of the service. A AAA server is responsible for authorizing network nodes (GGSNs) to grant access to the user and a CDR system generates G-CDRs/eG-CDRs/EDRs/UDRs or Comma Separated Values (CSVs) for billing information on pre-defined intervals of volume or per time.

License Keys

Support for the Enhanced Charging Service requires one of the following session-use licenses:

Enhanced Charging Standard 1k Sessions, part number 600-00-7526

Enhanced Charging Premium 1k Sessions, part number 600-00-7574

Content Analysis Support

Benefits

The Enhanced Charging Service is capable of performing content analysis on packets of many different protocols at different layers of the OSI model.

Description

The ECS content analyzers are able to inspect and maintain state across various protocols at all layers of the OSI stack. ECS system supports, inspects, and analyzes the following protocols:


41

IP

TCP

UDP

DNS

FTP

TFTP

SMTP

POP3

HTTP

ICMP

WAP: WTP and WSP

Real-Time Streaming: RTP and RTSP

MMS

SIP and SDP

File analysis: examination of downloaded file characteristics (e.g. file size, chunks transferred, etc.) from file transfer protocols such as HTTP and FTP

Traffic analyzers in enhanced charging subsystem are based on configured rules. Rules used for Traffic analysis analyze packet flows and form usage records. Usage records are created per content type and forwarded to a pre-paid server or to a mediation/billing system. A traffic analyzer performs shallow (Layer 3 and Layer 4) and deep (above Layer 4) packet inspection of the IP packet flows.

The Traffic Analyzer function is able to do a shallow (layer 3 and layer 4) and deep (above layer 4) packet inspection of IP Packet Flows.

It is able to correlate all layer 3 packets (and bytes) with higher layer trigger criteria (e.g. URL detected in a HTTP header) and it is also perform stateful packet inspection to complex protocols like FTP, RTSP, SIP that dynamically open ports for the data path and by this way, user plane payload is differentiated into “categories”.

The Traffic Analyzer works on the application level as well and performs event based charging without the interference of the service platforms.

License Keys

This functionality is available for use with the Enhanced Charging Service which requires one of the following session-use licenses:


42



Support for Multiple Detail Record Types

Benefits

To meet the requirements of standard solutions and at the same time, provide flexible and detailed information on service usage, the Enhanced Charging Service (ECS) provides the following type of usage records:

Enhanced GGSN Call Detail Records (eG-CDRs)

Event Detail Records (EDRs)

Usage Detail Records (UDRs)

Description

ECS provides for the generation of charging data files, which can be periodically retrieved from the system and used as input to a billing mediation system for post-processing. These files are provided in a standard format, so that the impact on the existing billing/mediation system is minimal and at the same time, these records contain all the information required for billing based on the content.

GTPP accounting in ECS allows the collection of counters for different types of data traffic into detail records. The following types of detail records are supported:

Enhanced GGSN Charging Detail Records (eG-CDRs): An enhanced format of standard G-CDRs to provide greater portability of charging information. This format supports customer specific formats and can be provided in ASCII or ASN.1 Format.

Event Detail Records (EDRs): An alternative to standard G-CDRs when the information provided by the G-CDRs is not sufficient to do the content billing. EDRs are generated according to explicit action statements in rule commands that are user-configurable. The EDRs are generated in comma separated values (CSV) format, generated as defined in traffic analysis rules.

User Detail Records (UDRs): Contain accounting information related to a specific mobile subscriber. The fields to be reported in them are user-configurable and are generated on any trigger of time threshold, volume threshold, handoffs, and call termination. The UDRs are generated in comma separated values (CSV) format, generated as defined in traffic analysis rules.

After collection of eG-CDRs/G-CDRs, system sends them to a Charging Gateway Function (CGF) and/or GTPP Storage Server (GSS) for billing processing. Collected UDRs and/or EDRs are stored in memory until they’re collected by the ECS Storage Server (ESS).

License Keys

This functionality is available for use with the Enhanced Charging Service which requires one of the following session-use licenses:


43



Diameter Credit Control Application

Benefits

Provides a pre-paid billing mechanism for real-time cost and credit control based on the following standards:

RFC 3588, Diameter Base Protocol, September 2003

RFC 4006, Diameter Credit-Control Application, August 2005

3GPP Release 7 Gy interface, 3GPP TS 32.299 v7.4.0

Description

The Diameter Credit Control Application (DCCA) is used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, download services etc.

Used in conjunction with ECS, the DCCA interface uses a mechanism to allow the user to be informed of the charges to be levied for a requested service. In addition, there are services such as gaming and advertising that may credit as well as debit from a user account.

DCCA also supports the following:

Real-time Rate Service Information: The ability to verify when end subscribers' accounts are exhausted or expired; or deny additional chargeable events.

Support for Multiple Services: The usage of multiple services within one subscriber session is supported. Multiple Service support includes:

The ability to identify and process the service or group of services that are subject to different cost structures.

Independent credit control of multiple services in a single credit control sub-session.

License Keys

This functionality is available for use with the Enhanced Charging Service which requires the following session-use licenses:

Enhanced Charging Bundle 2, 1k Sessions, part number 600-00-7574

Gy Interface Support

Benefits

The Gy interface enables the wireless operator to implement a standardized interface for real time content based charging with differentiated rates for time based and volume based charging.


44

As it is based on a quota mechanism, the Gy interface enables the wireless operator to spare expensive Prepaid System resources.

As it enables time-, volume-, and event-based charging models, the Gy interface flexibly enables the operator to implement charging models tailored to their service strategies

Description

The Gy interface provides a standardized Diameter interface for real time content based charging of data services. It is based on the 3GPP standards and relies on quota allocation.

It provides an online charging interface that works with the ECS deep packet inspection feature. With Gy, customer traffic can be gated and billed in an "online" or "prepaid" style. Both time- and volume-based charging models are supported. In all of these models, differentiated rates can be applied to different services based on shallow or deep packet inspection.

Gy is a Diameter interface. As such, it is implemented atop, and inherits features from, the Diameter Base Protocol. The ST16 supports the applicable Base network and application features, including directly connected, relayed or proxied DCCA servers using TLS or plaintext TCP.

In the simplest possible installation, the ST16 will exchange GY Diameter messages over Diameter TCP links between itself and one "prepay" server. For a more robust installation, multiple servers would be used. These servers may optionally share or mirror a single quota database so as to support Gy session failover from one server to the other. For a more scalable installation, a layer of proxies or other Diameter agents can be introduced to provide features such as multi-path message routing or message and session redirection features.

The Starent implementation is based on the following standards:

RFC 4006 generic DCCA, including:

CCR Initial, Update, and Final signaling.

ASR and RAR asynchronous DCCA server messages.

Time, Total-Octets, and Service-Specific-Units quota management.

Multiple independent quotas using Multiple-Services-Credit-Control.

Rating-Group for quota-to-traffic association.

CC-Failure-Handling and CC-Session-Failover features.

Final-Unit-Action TERMINATE behavior.

Tariff-Time-Change feature.

3GPP TS 32.299 online mode "Gy" DCCA, including:

Final-Unit-Action REDIRECT behavior.

Quota-Holding-Time. This defines a user traffic idle time, on a per category basis, after which the usage is returned and no new quota is explicitly requested.

Quota-Thresholds. These AVPs define a low value watermark at which new quota will be sought before the quota is entirely gone; the intent is to limit interruption of user traffic. These AVPs exist for all quota flavors - example "Time-Quota-Threshold".

Trigger-Type. This AVP defines a set of events which will induce a re-authentication of the current session and its quota categories.


45

License Keys

The Gy interface is a licensed feature, its part number is 600-00-7574.

ECS Storage Server

Benefits

The ECS Storage Server (ESS) enables the backing-up of detail records generated by ECS to an external storage server. This reduces the risk of accounting data loss.

Description

The CDR subsystem on the ST16 provides 64MB of non-volatile, non-redundant storage for accounting information. This on-board memory is intended as a short-term buffer for accounting information, so that mediation systems can periodically retrieve the buffered information for bill generation purposes. However if network outages or other failures cause mediation systems to lose contact with the ST16, it is possible that the CDR subsystem 64MB storage area will be filled with un-retrieved accounting information. When the storage is filled the CDR subsystem starts deleting the oldest files to make sure that there is room for new billing files and un-retrieved accounting information can be lost. Use of an external storage server with a large storage volume in close proximity to the ST16 ensures room for storing a large amount of billing data that is not lost by any failure.

The External Storage Server (ESS) is designed to be used as a safe storage area. A mediation or billing server within your network must be configured to collect accounting records from the ESS once it retrieves them.

The ESS connects to the ST16 at user configurable intervals and uses Secured File Transfer Protocol (SFTP) to retrieve billing files. The billing files are downloaded to a temporary area on the ESS machine. When ESS determines that all files are downloaded completely, they are moved to a final area for collection by a mediation or billing server. ESS always leaves the last file retrieved in the temporary directory to ensure that the latest file gets completely downloaded. On the next file retrieval cycle, if newer files are retrieved or if there are no new files to retrieve, this file is then transferred to the final directory.

The only required command line arguments are the username, password and host name or IP address to use when connecting o the ST16 .

License Keys

The ECS Storage Server is a licensed feature, its part number is 600-00-7559.

Gx Interface Support

Description

Starent provides support for 3GPP standard-based Gx interface, compliant with 3GPP standards releases 6 and 7. In addition, Starent developed a customer-specific Gx+ interface.


46

The implementation of this interface has been according to the document 3GGP TS 23.203. The goal of the Gx (R6) and Gx (R7) interface is to provide network based QoS control as well as dynamic charging rules on a per bearer basis for an individual subscriber. The Gx interface is in particular needed to control and charge multimedia applications.

The Gx (R7) 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.

Starent has implemented some extensions to the standard Gx interface, (usually called Gx+). Starent’s implementation addresses the limitations of the interface (IP 5-tuples are used to designate flows) by allowing to pre-configure “inactive” L7 & P2P rules, which are then activated via Gx/Gx+.

License Keys

The Gx interface is a licensed feature, its part number is 600-00-7585.

Gx+ Interface Support

Benefits

Gx+ interface support on the system enables the wireless operator to:

Implement differentiated service profiles for different subscribers

Intelligently charge the services accessed depending on the service type and parameters

This interface is particularly suited to control and charge multimedia applications and IMS services.

Description

The goal of the Gx+ interface is to provide network based QoS control as well as dynamic charging rules on a per bearer basis. The Gx+ interface is in particular needed to control and charge multimedia applications.

The Gx+ interface is located between the GGSN and the E-PDF / PCRF. It is a Diameter- based interface and provides the functions provided earlier by the Gx and Go interfaces:


47

QoS control based on either a token-based or token-less mechanism. In the token-based mechanism, the E-PDF or PCRF dynamically assign network resources to the different bearers used by the subscriber. These resource assignments are transmitted in Tokens carried over the Gx+ interface. The authorization tokens are allocated by the network (E-PDF/PCRF), hence the network is in full control of the mechanism since it only authorizes resources. The token-less mechanism is for further study.

Dynamic rules for Flexible Bearer Charging. These dynamic charging rules are carried in the resource assignment tokens and provide 5-tuple type charging rules that enables to implement a specific charging policy for each subscriber bearer. These charging rules will be applied by the FBC function of the GGSN, and produce the appropriate eGCDRs or the appropriate messages on the Gy interface to the OCS.

As of March 2007, the 3GPP standards bodies has completed the first standardized specification of Gx+. Starent’s implementation predates this specification and is a pre-standards implementation of 3GPP Release 7 Gx.

License Keys

The Gx+ interface is a licensed feature, its part number is 600-00-7585.

Streamlined ICAP Interface Support

Benefits

The fact that the external service platform leverages the ST16 Deep Packet Inspection used for the FBC function offers the following benefits:

Coordinate the ST16 FBC and the external service platform decisions. For example, a redirection for charging criterion (Advice of Charge, Top Up page) would not make sense if the service is barred by the external Application Server)

Single Deep Packet Inspection function, resulting in a better utilization of the network resources, and in particular of the Application Server processing resources

Only the relevant requests are sent to the external application server on a per subscriber per service accessed basis, vs. all the traffic. This results in a very significant optimization of the network resources, but also of the response time perceived by the subscriber.

Description

The streamlined ICAP interface leverages the ST16 Deep Packet Inspection to enable external Application Servers to provide their services without performing the DPI functionality and without being inserted in the data flow. For example with an external Adult Content Filtering Platform.

A high-level view of the streamlined ICAP interface is shown in the following figure:


48

Figure 1-10 High-Level View of Streamlined ICAP Interface

The ST16 GGSN is configured to support deep packet inspection, it is assumed this capability is used for content charging.

If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the GGSN deep packet inspection code. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the APN, in an ICAP message to the Application Server (AS). The AS checks the URL and decides if the request should be authorized, blocked or redirected by answering to the GET / POST with:

A 200 OK message if the request is accepted

A 302 Redirect message in case of redirection. This redirect message includes the URL to which the subscriber should be redirected

A 403 Denied message is the request should be blocked

Depending on the response received, the ST16 GGSN will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.

Content Charging is performed by the GGSN only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the AS.

License Keys

The ICAP interface is a licensed feature, its part number is 600-00-7578.


49

GGSN Inter-Chassis Session Recovery

Benefits

The ST16 provides industry leading carrier class redundancy. The system protects against all single points of failure (hardware and software) and attempts to recover to an operational state when multiple simultaneous failures occur.

The system provides several levels of system redundancy:

Under normal N+1 PAC hardware redundancy, if a catastrophic PAC failure occurs all affected calls are migrated to the standby PAC if possible. Calls which cannot be migrated are gracefully terminated with proper call-termination signaling and accounting records are generated with statistics accurate to the last internal checkpoint

If the Session Recovery feature is enabled, any total PAC failure will cause a PAC switchover and all established sessions for supported call-types are recovered without any loss of session.

Even though Starent provides excellent intra-chassis redundancy with these two schemes, certain catastrophic failures which can cause total chassis outages, such as IP routing failures, line-cuts, loss of power, or physical destruction of the ST16 chassis, cannot be protected by this scheme. In such cases, the GGSN Inter-Chassis Session Recovery feature provides geographic redundancy between sites. This has the benefit of not only providing enhanced subscriber experience even during catastrophic outages, but can also protect other systems such as the RAN from subscriber re-activation storms.

Description

The Interchassis Session Recovery feature allows for continuous call processing without interrupting subscriber services. This is accomplished through the use of redundant chassis. The chassis are configured as primary and backup with one being active and one in recovery mode. A checkpoint duration timer is used to control when subscriber data is sent from the active chassis to the inactive chassis. If the active chassis handling the call traffic goes out of service, the inactive chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session. The chassis determines which is active through a propriety TCP-based connection called a redundancy link. This link is used to exchange Hello messages between the primary and backup chassis and must be maintained for proper system operation.

Interchassis Communication

Chassis configured to support Interchassis Session Recovery communicate using periodic Hello messages. These messages are sent by each chassis to notify the peer of its current state. The Hello message contains information about the chassis such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be received from the chassis’ peer. If the standby chassis does not receive a Hello message from the active chassis within the dead interval, the standby chassis transitions to the active state. In situations where the redundancy link goes out of service, a priority scheme is used to determine which chassis processes the session. The following priority scheme is used:


50

router identifier

chassis priority

SPIO MAC address

Checkpoint Messages

Checkpoint messages are sent from the active chassis to the inactive chassis. Checkpoint messages are sent at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected on the session. The checkpoint parameter determines the amount of time a session must be active before it is included in the checkpoint message.

License Keys

GGSN Inter-Chassis Session Recovery is enabled by an added-cost license key. The part numbers are:

GGSN Inter-Chassis Session Recovery 10k Sessions, part number 600-00-7584

GGSN Inter-Chassis Session Recovery 1k Sessions, part number 600-00-7615

Converged DSL Support on the GGSN

Benefits

Digital Subscriber Line (DSL) is one of the dominant technologies used to provide wired broadband access to consumers and SOHO/ROBO today. DSL operates over copper telephone line owned by Local Exchange Carriers, who often have strong relationships to the Mobile Wireless Operators either through shared ownership or joint holdings. This feature allows Mobile Wireless Operators to provide DSL converged services with the Starent GGSN.

Description

Converged DSL / GGSN leverages the existing L2TP feature set of the Starent GGSN to aggregate both GTP sessions (PDP contexts) as well as L2TP sessions (PPP) in the same platform. A typical DSL access network consists of three main elements:

A network of DSL Access Multiplexers (DSLAM)

A Broadband Remote Access Server (B-RAS) acting as a L2TP Access Concentrator

A Broadband Remote Access Server (B-RAS) acting as a L2TP Network Server

A conceptual diagram of a typical DSL access network is shown below.


51

RADIUS AAA B-RAS LNS

B-RAS LAC

L2TP

DSLAM Network

The Starent GGSN acts as a L2TP Network Server (LNS) and interfaces with a DSL Broadband Remote Access Server acting as a L2TP Access Concentrator (LAC). In addition the L2TP sessions are tightly integrated with existing GGSN features such as APN support and Enhanced Charging, to provide seamless multi-access technology support. This allows the Starent GGSN to provide aggregation for both DSL and GSM networks, as shown in the diagram below.

CGF / Prepaid Server

ST16GGSN and LNS

B-RAS LAC SGSN

L2TP GTP

DSLAM Network RAN

License Keys

Converged DSL functionality is license enabled. The following licenses are required:


52

L2TP LNS, part numbers 600-00-7503, 600-00-7506

Peer-to-Peer Traffic Detection

Benefits

The rise in use of Peer-to-peer (P2P) applications such as Skype and BitTorrent are presenting new challenges to the Mobile Wireless Operators. In addition to the cannibalization of network operators’ existing voice and video services, a primary concern is network bandwidth load caused by such applications. Operationally instead of a hub-spoke architecture, P2P applications are capable of contracting many hubs interconnected by spokes. P2P protocols that desire high BW are designed to probe and acquire as much bandwidth as available over all connections. This wide fan-out of P2P architectures combined with loosely coupled network state allows for rapid bring-up of P2P networks which can cause network instability and fluctuation in load including transitory congestion.

Starent’s P2P detection feature provides detection, reporting, and control of P2P applications, allowing network operators to take preventative action on P2P applications where necessary.

Description

Detecting peer-to-peer protocols requires recognizing, in real time, some uniquely identifying characteristic of the protocol. Typical packet classification relies only on information uniquely typed in the packet header of packets of the stream(s) running the particular protocol to be identified. Such methods can be used to detect simple peer-to-peer protocols.

However a small class of P2P protocols is stealthier and more challenging to detect. For some protocols no single marker can be identified with confidence as unique to the protocol. Starent’s P2P detection feature utilizes a variety of techniques, sometimes simultaneously, to detect such protocols with high confidence. In addition to header pattern classification, Starent’s technology also uses time-series connection patterning to detect the most sophisticated and stealthiest class of P2P protocols. Once detected, the Starent GGSN can generate reports using G-CDR or other data record formats or invoke policy actions such as blocking or rate limiting on such P2P application flows.

Release 7.0 included detection and control for the following protocols:

Skype

BitTorrent

eMule

eDonkey

Yahoo! Instant Messenger

MSN Messenger

License Keys

Peer-to-peer detection functionality is license enabled. The following licenses are required:

Peer-to-peer detection license bundle, 1K sessions, part number 600-01-7605

In addition, Peer-to-peer detection requires the following annual subscription fee:


53

Peer-to-peer subscription service, 1K sessions, part number 700-60-1011

Integrated Content Filtering

Benefits

Content Filtering is an in-line service applicable that uses deep packet inspection to discern HTTP, WAP, and other content requests. Content Filtering makes use of a database of apriori-classified URLs and a dynamic classification engine to categorize web pages and URL requests. Content Filtering allows carriers to regulate and control content as a means to:

Address market demand to control heretofore largely unregulated content the application du jour preventing access by minors to pornography

Reduce abusive use of their network resources by minimizing abusive applications that grab as much network resource as available

Deliver new revenue generating services by way of limiting access of particular services to paying subscribers

Description

Content Filtering is a network service applied to subscriber sessions including some subset of the following functions:

Categorizing subscribers in terms of what network content is permissible to be accessed

Categorizing content into the same classes, statically or in real time.

Real-time filtering of data traffic from the MN and to the MN

Actions as a consequence of reception of data of a particular class on behalf of a particular subscriber

Permit traffic to go on

Block

Redirect

Alter content

Content Filtering policy attributes can be provided in RADIUS VSA attributes in the AAA RADIUS Access Accept message during normal subscriber session AAA authentication procedures on the GGSN or alternatively over a Diameter interface (e.g. Gx) with the PCRF.

License Keys

Integrated Content Filtering functionality is license enabled. The following licenses are required:

Integrated Content Filtering Service, 1K sessions, part number 600-01-7586



54

Content Filtering Subscription Service, 1K sessions, part number 700-60-1010

ANSI T1.276 Compliance

Benefits

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures. Starent plans support for the applicable portions of ANSI T1.276 in both the Web Element Management System (W-EMS) and ST16 products in 2007.

Description

ANSI T1.276 specifies several measures for password security. These measures include:

Password strength guidelines

Password storage guidelines for NEs

Password maintenance, e.g. periodic forced password changes

These measures are applicable to the ST16 and the W-EMS since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the ST16 platform supports a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. For the ST16, ANSI T1.276 guidelines will only be implemented for locally configured operators.

License Keys


Inbound Diameter Connections

Benefits

Inbound Diameter connection support allows servers which cannot receive TCP connections to initiate a Diameter / TCP connection to the ST16 or ST40.

Description

Prior to release 7.0, the ST16 / ST40 expects to initiate all connections to the Diameter-based prepaid server or policy server. Incoming TCP connections to the system are dropped as the ST16 / ST40 does not expect to receive such connections.

With this feature, the ST16 / ST40 is able to receive inbound TCP connections for carriage of Diameter messages.

License Keys

This functionality is enabled by default with the Diameter feature; no additional license keys are required to use it.


55

GGSN: Direct Tunnel

Benefits

Direct tunnel improves the user experience (e.g. expedited web page delivery, reduced round trip delay for conversational services, etc.) by eliminating SGSN tunnel ‘switching’ latency from the user plane. An additional advantage of Direct Tunnel from an operational and capital expenditure perspective is that direct tunnel optimises the usage of user plane resources by removing the requirement for user plane processing on the SGSN.

Description

The Direct Tunnel architecture allows the establishment of a direct user plane tunnel between the RAN and the GGSN, bypassing the SGSN. The SGSN continues to handle the control plane signalling and typical makes the decision to establish Direct Tunnel at PDP Context Activation. A Direct Tunnel is achieved at PDP context activation by the SGSN establishing a user plane (GTP-U) tunnel directly between RNC and GGSN (using an Update PDP Context Request towards the GGSN).

A major consequence of deploying Direct Tunnel is that it will produce 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 ST40 GGSN and SGSN offers massive control plane transaction capabilities, ensuring ST40 control plane capacity will not be a capacity limiting factor once Direct Tunnel is deployed.

License Keys

This functionality does not require any additional license keys to use it.


56

Multimedia Broadcast / Multicast Services (MBMS)

Description

The Starent 3GPP platforms support MBMS which is a point-to-multipoint data transmission service in which data is transmitted from a single source entity to multiple recipients in either broadcast or multicast fashion. The network elements can switch between broadcast and multicast depending on the type of service required. The Starent SGSN and GGSN MBMS functionality has been designed based on 3GPP TS 23.246 V.6.0.0.

The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast or unicast traffic as MBMS data. Upon notification from the BM-SC the GGSN shall be able to request the establishment of a user-plane for a broadcast or multicast MBMS transmission. Further, upon BM-SC notification the GGSN will tear down the established user plane. User-plane establishment for multicast services is carried out towards those SGSNs that have requested to receive transmissions for the specific multicast service, while for broadcast services the user plane is created to those SGSN IP addresses that are present in the Gmb MBMS Session Start Request message 3GPP-SGSN-Address AVP.

The GGSN will receive IP multicast or unicast traffic (whether from BM-SC or other data sources) and route this data to the proper GTP tunnels set-up as part of the service.

License Keys MBMS in the GGSN is license enabled.

802.3ad Link Aggregation in Gigabit Ethernet Line Card

Description

802.3ad is a standard way of doing link aggregation. Conceptually, several Ethernet adapters are aggregated into a single virtual adapter, providing greater bandwidth and protection against failures. Please note that this functionality is available for the 4-port Gigabit Ethernet Line Card only for the Starent platform.

Benefits

The advantages of using 802.3ad are that it does not change packet format by adding headers or alter sequence numbers, which does not affect the length of the packets; it does not re-order or mis-order packets because packets associated with a given “conversation” are transmitted on the same link and; it does not add significant latency.

A single logical interface can be bound to 4 physical interfaces thereby allowing for simpler configuration. Before this functionality was available in the ST platform, to configure a logical interface to provide more than 1Gbps, equal cost multi path need to be configured across multiple logical interfaces. Link aggregation moves the link sharing to layer 2, removing the need for ECMP.

License Keys

This functionality does not require any additional license keys to use it. It comes standard when purchasing the 4-port Gigabit Ethernet Line card.


57

QoS Renegotiation Extensions

Description

This feature includes three sub features:

Layer 7 QoS renegotiation

Traffic Shaping

Network Controlled QoS

These features are explained in the sections below:

QoS Renegotiation Extensions - Functional Feature Description

Dynamic QoS renegotiation is a feature that has been part of StarOS since 5.0, however operators have not been able to deploy this feature as the SGSN and RAN do not support the modify PDP context procedures.

This feature allows the GGSN to analyse application traffic and trigger QoS renegotiation with the SGSN to optimise service performance. In dynamic QoS renegotiation, the GGSN performs packet inspection of the data traffic to detect the type of service being utilized and automatically renegotiate the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR. QoS renegotiation is performed by sending an update PDP context request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.

Layer 3/4 based QoS renegotiation

In the existing Dynamic QoS Renegotiation feature, layer 3/4 detection is configured using Access Control List (ACL) rules. In short, QoS renegotiation configuration follows the form:

<trigger> <action> In the existing release, <trigger> is simply permit ACL statement containing a 5-tuple (IP source and destination address, protocol, protocol source and destination port) pattern match. <action> is represented by the treatment keyword followed by a 3GPP class (background, conversational, interactive, streaming.) If the system detects a pattern matching the trigger condition, the corresponding QoS class specified in the treatment action is negotiated with the SGSN. A third parameter of Dynamic QoS Renegotiation the QoS enforcement action configured in the APN. Bandwidth limiting and remarking parameters can be configured for each 3GPP QoS class. Note that up to three priorities can be configured for interactive class, thus up to six different bandwidth limiting schemas can be configured.

Layer 7 based QoS renegotiation

Layer 7 QoS renegotiation is an extension of the existing Dynamic QoS Renegotiation. This extension involves adding QoS treatment as a charging action into ECS. Upon matching a particular Layer 7


58

rule, for example the access of a particular URL, or the detection of peer-to-peer traffic, the GGSN shall trigger the renegotiation of the PDP context. This method is particularly useful for limiting undesirable applications that use many different flows, a behaviour that is common to many peer-to-peer applications. Since it is resource-intensive to individually rate limit or shape many hundreds of micro-flows, a more efficient and optimal method is to rate limit the PDP context itself. This feature will add the ability to trigger QoS renegotiation as a charging action within the rulebase. Only support for L7 QoS renegotiation on the primary PDP context is provided. Secondary PDP context renegotiation can only be triggered using Layer 3/4 rules. QoS renegotiation of secondary PDP contexts using L7 triggers is left for further study. In particular, it is not generally possible to classify P2P traffic, the most interesting category of non-IMS traffic for QoS, into a secondary PDP context, thus limiting its usefulness. As well IMS traffic can be classified by L3/4 triggers.

Benefits

Extensions to the Dynamic QoS Renegotiation feature set provides carriers with an advanced, flexible QoS mechanism that provides a simplified migration path towards fully dynamic, IMS-based QoS. By locating the intelligence within the GGSN, the carrier can also provide QoS services for pre-IMS or non-IMS services such as common peer-to-peer protocols (e.g. VoIP). In addition, as most control operations are localized within the GGSN or negotiated within the RAN, the QoS renegotiation extensions minimizes UE involvement in QoS and policy control, thus simplifying handsets and handset interactions and ensuring that QoS policy resides within the carrier’s control.

License Keys

This is part of Dynamic QoS Renegotiation, which is a license enabled feature. The following license is required:

GGSN Dynamic QoS Renegotiation, part number 600-00-7556

Traffic Shaping

Description

The shaping algorithm assumes that the total capacity of the physical connections to the radio network (i.e. SGSN, PCF) exceeds the normal peak bandwidth of subscriber traffic.

For example, if the normal peak throughput at busy hour is 1.9 Gbps, then it is assumed that there are at least two Gigabit Ethernet connections to the RAN. This assumption removes the need to guarantee fairness among subscribers, and also makes the subscribers’ traffic contract the likely cause of any shaping or discarding action.

The shaping algorithm can be described with the following parameters:

Maximum Transmission Rate (MTR): This rate is configured on a per-subscriber basis and is similar to Insured Rate in dual leaky bucket algorithms. The MTR defines the peak rate at which the subscriber is allowed to transmit. Note that this maximum rate, unlike Insured Rate, is not guaranteed. However due to Assumption 1 MTR is almost always provided.


59

Excess Rate (ER): This parameter defines the rate at which traffic exceeding MTR is serviced. Traffic which exceeds ER is discarded.

When a packet is received, the system determines whether the packet may be transmitted. If the subscriber’s MTR is not exceeded, the packet is transmitted, else the packet is buffered.

Buffered packets are serviced at a fixed rate. If the rate is exceeded, or if the system runs out of memory to buffer the packets, the packet is discarded.

The negotiated QoS is used to determine the MTR. Therefore when QoS is renegotiated as part of the L7 QoS renegotiation feature for example, then the MTR value is adjusted and shaping will occur at a different rate.

Benefits

Traffic shaping has many benefits, in particular:

As a congestion control and avoidance mechanism As a traffic control mechanism, to ensure subscribers adhere to a traffic contract To augment (1) and (2) with the ability to buffer instantaneous bursts until the congestion conditions

clear or the subscriber’s traffic contract allows for the buffered packets to be sent As a retransmission avoidance method to be used during congestion or when a subscriber exceeds

their traffic contract, by buffering instead of discarding instantaneous bursts

Traffic shaping can be especially beneficial to operators since the NGME is situated at the edge of the network where last-mile (over the air) bandwidth is much less than core network bandwidth, and there will be many situations where the NGME will be receiving much more traffic from the Internet than a particular subscriber’s radio bearer can receive. For especially bursty traffic flows, the additional buffering capability of shaping can result in significantly fewer retransmissions.

In this release, the traffic shaping feature will provide shaping capability suited for non-real-time traffic on a per-subscriber level. Thus the feature will focus on:

Longer duration timers that will provide dequeuing from the shaping buffer in durations that may be tolerable for real-time traffic but will likely not be suited for real-time interactive traffic

Single queuing disciplines, i.e. no differentiated queuing for different applications or service classes Best effort queuing disciplines, guarantees will not be made regarding loss rate, jitter, or latency

License Keys

Traffic policing and shaping is a license enabled feature. The following license is required:

Per Subscriber Traffic Policing / Shaping, part number 600-00-7542

Network Controlled QoS (NRSPCA)

Description

Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN (Network Requested Update PDP Context, or NRUPC), or a new secondary PDP context is activated on the request of the GGSN (Network Requested Secondary PDP Context Activation, or NRSPCA). In this phase, Network-Controlled QoS is added as an action to


60

Dynamic QoS Renegotiation, so that NRUPC and NRSPCA may be triggered by a pre-configured Layer 3/4 packet-matching rule.

NRUPC and NRSCPA are only be triggered by Layer 3 / 4 inspection. NRUPC and NRSCPA can only be triggered in this phase via statically configured PCC rules (specifically, via the permit statement in an ACL). Dynamic triggers via Gx is for further study.

Network-controlled QoS shall conform to the following 3GPP Change Requests and specifications:

3GPP TS 29.060 CR633 Rev6 3GPP TS 23.060 CR0558 3GPP TR 23.818 V0.10.0

When a pre-configured trigger is matched, it shall be possible to create a new or update an existing PDP context with a particular profile, where profile is defined (at least) as TFT and QoS.

Bearer Control Mode (BCM) shall be configurable on per APN basis. If not configured, BCM shall default to “Both”.

BCM may be configurable on a per PDP context basis using RADIUS; this will require a new VSA. This functionality is not committed unless there is a strong request from an operator.

Safe guards might be required to ensure that following a GGSN PDP Context Modification a loop is not entered if the UE or RAN rejects the request to upgrade to a higher QoS.

License Keys

This functionality is a license-enabled feature.

Peer to Peer (P2P) Service Enhancements

Description

Postpaid (offline) charging is supported for P2P in a similar manner as for ECS.

e-GCDRs are supported and additionally EDRs (Event Detail Records) and UDRs (Usage Detail Records),

for recording volume in bytes and packets, and duration,

along with rules for generation.

For P2P protocols requiring behavioral detection such as Skype and BitTorrent, due to the nature of detection there is an initial period when a flow is recognized as likely P2P. If criteria are met, the flow is classified as P2P. Volume and duration accounting for charging or statistics begins when a flow is identified as P2P. So volume counts and durations will be reported slightly understated with respect to the start of the session. The preamble period is quite short and only requires a few packets so the volume understatement is very small.

Up to this release P2P reporting was supported on the EMS for aggregate volume, corresponding content ids associated with particular P2P protocols. By periodic polling, average rates can be calculated . So, for


61

example, statistics on bytes, packets per P2P protocol, per P2P statistics, optionally in comparison to other ECS-available statistics including volume and or average rates per chassis were available in report and graphical form via a GUI interface.

With this release, UDRs will be optionally sent to the R-ESS1 by way of L-ESS. All reports available on the L-ESS for ECS statistics are available for P2P statistics. For example,

summary report: Reports category-wise distribution of system-wide traffic

Additionally, new is a top-N-users report,

top-N-users: Reports the top ‘N’ users of P2P in terms of volume, where the time-span and number of users to be captured is supplied.

Voice break out from bundled P2P protocol. Some P2P protocols are many applications grouped together, frequently with a voice component, a file transfer component, instant messenger, and or other components. Skype is one of these “bundled” services. For release 8.0, Starent will:

break out the voice component of Skype and account separately from non-voice components of Skype.

Other protocols that may be broken out into Voice and non-Voice components are:

VCast

MSN

Yahoo

AOL

In regards to charging/billing, note that eG-CDR formats are not changed. Please note that EDR and UDR are not supported on the GSS and require the L-ESS and R-ESS applications from Starent. These record types do not affect the charging interface.

Benefits

Starent works to gather information from may operators to understand which enhancements are beneficial. The need to support detailed reporting using the UDR has been highlighted as a important means to understand the proportion of traffic is P2P and the distribution over the subscriber base.

License Keys

Peer-to-peer detection functionality is license enabled. The following licenses are required:

Peer-to-peer detection license bundle, 1K sessions, part number 600-01-7605


Peer-to-peer subscription service, 1K sessions, part number 700-60-1011

1 R-ESS and L-ESS are the reporting applications offered by Starent that perform analysis of the usage records and generate reports from them.

2b-1 GGSN Product Description v3

Documents

Transcript of 2b-1 GGSN Product Description v3