IPSG is a StarOS™ application that runs on Cisco® ASR 5500 and virtualized platforms. For additional platform information, refer to the appropriate System Administration Guide and/or contact your Cisco account representative.

The IP Services Gateway is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on licensing requirements.

For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

When configured in RADIUS server mode, the IPSG inspects identical RADIUS accounting request packets sent to the RADIUS accounting server and the IPSG simultaneously.

As shown in the following figure, the IPSG inspects the RADIUS accounting request, extracts the required user information, then sends a RADIUS accounting response message back to the access gateway. The IPSG has three reference points: sn, si, and sr. The sn interface transmits/receives data packets to/from the access gateway (GGSN, HA, PDSN, etc.). The si interface transmits/receives data packets to/from the Internet or a packet data network. The sr interface receives RADIUS accounting requests from the access gateway. The system inspects the accounting request packets and extracts information to be used to determine the appropriate service(s) to apply to the flow.

When configured in RADIUS snoop mode, the IPSG simply inspects RADIUS accounting request packets sent to a RADIUS server through the IPSG.

As shown in the following figure, the IPSG has three reference points: sn, si, and sr. The sn interface transmits/receives data packets to/from the access gateway (GGSN, HA, PDSN, etc.). The si interface transmits/receives data packets to/from the Internet or a packet data network. The sr interface receives RADIUS accounting requests from the access gateway. The system inspects the accounting request packets and extracts information to be used to determine the appropriate service(s) to apply to the flow. Information is not extracted from the RADIUS accounting responses so they are sent directly to the access gateway by the RADIUS Server, but can also be sent back through the IPSG.

Application Detection and Control (ADC) is an in-line service feature that detects peer-to-peer protocols in real time and applies actions such as permitting, blocking, charging, bandwidth control, and TOS marking.

For more information, refer to the Application Detection and Control Administration Guide.

Content Filtering is an in-line service feature that filters HTTP and WAP requests from mobile subscribers based on the URLs in the requests. This enables operators to filter and control the content that an individual subscriber can access, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers' preferences.

For more information, refer to the Content Filtering Services Administration Guide.

Enhanced Charging Service (ECS)/Active Charging Service (ACS) is the primary vehicle performing packet inspection and applying rules to the session which includes the delivery of enhanced services.

For more information, refer to the Enhanced Charging Service Administration Guide.

This feature introduces IPSG support for Accounting-On and Accounting-Off RADIUS accounting messages, in addition to the existing start, interim-update, and stop messages. The Accounting-On message sent by the peer RADIUS client indicates that the RADIUS client has restarted and is ready to accept calls.

An Accounting-Off message indicates that the peer RADIUS client is shutting down.

IPSG clears the existing subscriber sessions on receiving the Accounting-On/Off messages, and proxies the message to the RADIUS server (Proxy mode). The existing sessions are cleared based on the NAS-IP address of the subscriber that was assigned when the Acct-start message was created . If there is no NAS-IP-Address available, the peer IP address is considered as the NAS-IP-Address for the session. IPSG clears calls based on the NAS-IP address AVP in the Accounting-On/Off message irrespective of the origin of the message.

In a high-bandwidth bulk data flow scenario, user experience is impacted due to various wireless network conditions and policies like shaping, throttling, and other bottlenecks that induce congestion, especially in the RAN. This results in TCP applying its saw-tooth algorithm for congestion control and impacts user experience, and overall system capacity is not fully utilized.

The Cisco Ultra Traffic Optimization solution provides clientless optimization of TCP and HTTP traffic. This solution is integrated with Cisco IPSG and has the following benefits:

• Increases the capacity of existing cell sites and therefore, enables more traffic transmission.

• Improves Quality of Experience (QoE) of users by providing more bits per second.

• Provides instantaneous stabilizing and maximizing per subscriber throughput, particularly during network congestion.

For detailed information on Cisco Ultra Traffic Optimization solution, refer to the Cisco Ultra Traffic Optimization chapter in the IPSG Administration Guide.

Content Service Steering (CSS), defines how traffic is handled by the system based on the content of the data presented by a mobile subscriber. CSS can be used to direct traffic to in-line services that are internal to the system. CSS controls how subscriber data is forwarded to a particular in-line service, but does not control the content.

IPSG supports steering subscriber sessions to Content Filtering Service based on their policy setting. If a subscriber does not have a policy setting (ACL name) requiring Content Filtering, their session will bypass the Content Filtering Service and will be routed on to the destination address.

If subscriber policy entitlements indicate that filtering is required for a subscriber, CSS is used to steer subscriber sessions to the Content Filtering in-line service.

If a subscriber is using a mobile application with protocol type not supported, their session will bypass the Content Filtering Service and will be efficiently routed on to destination address.

For more information regarding CSS, refer to the Content Service Steering chapter in the System Administration Guide.

Dynamic RADIUS extension support provides 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 RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003 standard.

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

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

Important

For more information on dynamic RADIUS extensions support, refer the CoA, RADIUS, and Session Redirection (Hotlining) appendix of this guide.

To support roaming IMS subscribers in a GPRS/UMTS network, the IPSG must be able to charge only for the amount of resources consumed by the particular IMS application and bandwidth used. The IPSG must also allow for the provisioning and control of the resources used by the IMS subscriber. To facilitate this, the IPSG supports the R7 Gx interface to a Policy Control and Charging Rule Function (PCRF).

For detailed information on Gx Interface support, refer to the Gx Interface Support appendix in the IP Services Gateway Administration Guide.

Note the following for IPSG:

The following figure shows the interface and basic message flow of the Gx interface.

IPSG also supports IMS Authorization Service Session Recovery with the following limitations:

This is a Diameter protocol-based interface over which the IPSG communicates with a Charging Trigger Function (CTF) server that provides online charging data. Gy interface support 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.

For more information on Gy interface support, refer to the Gy Interface Support appendix in the IP Services Gateway Administration Guide.

The Cisco Lawful Intercept feature is supported on the IPSG. Lawful Intercept is a license-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

Multiple IPSG services, can be configured on the system using different contexts. Each such IPSG service functions independently as an IPSG. Both source and destination contexts must be different for each IPSG service.

Support for overlapping IP addresses for subscribers serviced by access networks on IPSG using VLANs is now possible through this feature. Overlapping IP addresses can be set up by defining multiple interfaces on the Sn interface (access side) and binding them to separate VLANs, while a single interface is setup to separate traffic using VPNv4 on the Si side (network side). When IPSG receives a packet, the appropriate session is identified based on the combination of IP address and VLAN. Currently, a maximum of 500 VLANs can be configured.

IPSG running on Cisco ASR 5500 acts as a BGPv4 peer (BGP proxy) per VLAN on the Sn interface, and MP-BGP peer on the Si interface. There can be 500 BGPv4 peers on the access side. IPSG can support a maximum of 64 BGP sessions per context, and hence 8 contexts are required to address 500 BGP sessions. On the Si interface, one VPNv4 per context is used, with a maximum of 8 VPNv4 contexts (if 8 contexts are used). The Sn and Si interfaces must be in the same context.

The session creation and deletion on IPSG is triggered on receiving the enriched AAA Accounting Start/Stop requests from the Cisco Account Register (CAR) AAA. The VLAN information is forwarded using the SN1-Assigned-VLAN-ID AVP.

This feature can be enabled using the CLI in the IPSG RADIUS Server Configuration Mode. Refer the IP Services Gateway Configuration chapter for configuration information.

This feature enables IPSG to validate RADIUS accounting messages from different configured RADIUS client IP addresses, and forward requests to the session manager.

In an architecture where multiple sites of IPSG and Radius Proxies exist, GGSN forwards RADIUS accounting messages to IPSG through its Radius Proxy. In an event where the Radius Proxy is unreachable, GGSN forwards subsequent messages using the RADIUS Proxy belonging to another site. IPSG updates the RADIUS client IP in the subscriber session, and forwards all control messages from the session manager to the alternate client.

This feature can be enabled using the validate-client-ip keyword in the radius accounting command under the IPSG RADIUS Server Configuration Mode. By default, the RADIUS client IPs are validated, and can be disabled using the disable radius accounting validate-client-ip command.

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.

Session recovery is performed by mirroring key software processes (for example, 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 (for example, 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 processing card to ensure that a double software fault (for example, Session Manager and VPN Manager fails at same time on same card) cannot occur. The packet processing card 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.

For more information on Session Recovery, refer to the Session Recovery chapter in the System Administration Guide.

Note that the Inter-Chassis Session Recovery feature is not supported in this release.