Cisco Content Services Gateway - 2nd Generation Release 6.0 Installation and Configuration Guide Cisco IOS Release 12.4(24)MDB

Configuring Gx Support

CSG2 provides policy control via the Gx interface.

Gx is a Third Generation Partnership Project (3GPP) Diameter application. In a Gx-enabled network, a Gx reference point is located between a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The Gx reference point can be used for charging control and policy control by applying Attribute Value Pairs (AVPs) relevant to the application.

The PCRF acts as a Diameter server and performs the following functions:

•It uses the Gx interface to provision PCC rules to, and remove PCC rules from, the PCEF.

•It handles policy control decisions.

•It provides network control regarding the service data flow detection, gating, Quality of Service (QoS), and flow-based charging (except credit management) towards the PCEF.

•It receives session- and media-related information from Application Functions (AFs) and informs the AFs of traffic plane events.

The PCEF acts as a Diameter client and performs the following functions:

•It uses the Gx interface to send traffic plane events to the PCRF.

•It enforces policy, handles flow-based charging, and controls QoS and the handling of user plane traffic.

•It provides service data flow detection and counting as well as online and offline charging interactions.

•It can report changes in the status of service data flows.

In a Gx-enabled network, the PCC rules are used to:

•Detect a packet that belongs to a service data flow.

•Identify the service to which the service data flow contributes.

•Provide applicable charging parameters and policy control for a service data flow.

PCC rules are dynamically provisioned by the PCRF to the PCEF over the Gx interface. Dynamic PCC rules are dynamically generated in the PCRF. Dynamic PCC rules can be activated, modified, and deactivated at any time.

In a Gx-enabled network, the CSG2 acts as a PCEF, either as part of an eGGSN node, with a CSG2 and a GGSN as separate cards in a Cisco 7600 Series Router, or as a stand-alone Gi-node, with interoperability from external GGSNs.

•In eGGSN mode, the CSG2 acts as a Gx interface endpoint while the GGSN manages PDP contexts. The CSG2 and the GGSN communicate with each other using the RADIUS protocol.

The CSG2 provides basic Gx support with enhancements for per-user Layer 7 rules, policy preloading, and per-user service policies.

The GGSN provides GTP, PDP AAA Authentication, and QoS RAN Signaling.

To enable the CSG2 to parse user profile attributes in eGGSN mode, you must configure either the ip csg entries user profile radius pass command or the ip csg entries user profile radius remove command.

•In Gi-node mode, the stand-alone CSG2 acts as a Gx interface endpoint. Gi-node mode supports all of the same functions as eGGSN mode, with the following exception:

–PDP Context QoS Signaling is not supported.

The CSG2 supports both the eGGSN mode and the Gi-node mode in both RADIUS endpoint and RADIUS proxy modes.

Figure 10-1 illustrates the placement of the CSG2 in a Gx-enabled network:

Figure 10-1 CSG2 in a Gx-Enabled Network

The CSG2 provides the following Gx features:

•Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature

•Enabling Gx on the CSG2

•Configuring a User Profile

•Dynamic Redirection

•Preloading Policies

•Gx TCP Signature Reporting

•Gx User Agent Reporting

•Dynamic Provisioning of 3GPP Per-User DGRs

•Dynamic Provisioning of Cisco Per-User DGRs

•Gx Event Triggers

•Volume and Duration Triggers

•Per-Subscriber Volume and Time Thresholds

•Support for 64-Bit Volume Threshold over Gx Interface

•Service Flow Detection Triggers

•Gx Event Trigger Usage Reporting

•Gx Usage Query

•Gx Service Groups

•Billing Plan Assignment and Modification

•PDP Context QoS Signaling

•Secondary PDP Context Activation

•PCRF-Specified Service-Level and User-Level QoS

•PCRF Failure Handling

•Diameter Error Processing

•User Session Continuation After PCRF Timeout

•Restrictions for Gx

Note Gx features in the CSG2 R6 and later require the 2 GB-SAMI option. The CSG2 R6 and later on the 1 GB-SAMI option does not support Gx.

Enabling Gx on the CSG2

To enable Gx support on the CSG2, enter the following command in global configuration mode:

csg2(config)# ip csg pcc gx [distributed]

You can set a Gx message rate for the CSG2. The CSG2 applies the Gx message rate to each TP. That is, the rate is set on a per-TP basis.

To set a Gx message rate, in messages per second, for each TP in the CSG2, enter the following command in global configuration mode:

csg2(config)# ip csg load gx rate gx-rate

Configuring a User Profile

To enable Gx support for a CSG2 subscriber, define a user profile and associate that profile with the subscriber.

The user profile:

•Enables Gx for all associated subscribers.

•Defines the actions that the CSG2 is to take if a PCRF fails.

•Defines the Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the PCRF.

To define a user profile, enter the following commands beginning in global configuration mode:

csg2(config)# ip csg user profile 
profile-name

csg2(config-csg-user-profile)# pcc gx

csg2(config-csg-user-profile)# pcrf failure 
[continue | terminate]

csg2(config-csg-user-profile)# pcrf profile 
mpcc-profile-name

csg2(config-csg-user-profile)# pcrf timeout 
[continue | terminate]

To associate a user profile with a subscriber, enter the following command in global configuration mode:

csg2(config)# ip csg select profile-name 
{any | radius called-station-id csid-string}

The CSG2 determines that a user is a Gx user in one of the following ways:

•The GGSN sends a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request with Cisco vendor-specific attributes (VSAs) that indicate that the user is a Gx user.

•The CSG2 compares the access point name (APN) name in attribute 30 (Called-Station-Id) of the RADIUS Accounting Start against a configured list of APN names to determine that the user is a Gx user.

Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature

The CSG2 supports the Cisco eGGSN for Cisco GGSN release 10.0. This section includes the following features:

•Support for Single IP GGSN

•RADIUS VSA Subattributes for Single IP Support

•Route Injection

Support for Single IP GGSN

The CSG2 supports GGSN single IP routing in an eGGSN environment. The CSG2 provides the following capabilities as part of its support:

•Direct messaging to a GGSN Traffic and Control Processor (TCOP) for RADIUS and GTP' interfaces.

•Prepaid or eG-CDR communication to each GGSN TCOP. The CSG2 can send and receive GTP' Data Records to a TCOP port that differs from the defined port of the eGGSN quota server. The port is communicated to the CSG2 in a RADIUS Accounting Request. GTP' control packets are sent to the configured port on the CSG2 for an eGGSN quota server.

RADIUS VSA Subattributes for Single IP Support

The CSG2 supports the RADIUS VSA subattributes that provide the Change of Authorization (CoA) destination port, the Packet of Disconnect (PoD) destination port, or the eGGSN quota server information (IP address, control port, and data port).

•The CSG2 sends the CoA or PoD message to the port received in a RADIUS VSA subattribute.

If no RADIUS VSA subattribute contains the port, the CSG2 uses the CoA or PoD Network Access Server (NAS) port (configured with the ip csg radius coa nas or ip csg radius pod nas command in global configuration mode) as the destination port.

•The CSG2 sends eGGSN quota server control messages, such as nodealive and echo, to the control port.

The CSG2 sends eGGSN quota server data messages, such as eG-CDR or prepaid quota manager messages, to the data port.

The eGGSN quota server can be selected as a prepaid quota server on the basis of RADIUS VSA subattribute eggsn_qs_mode. If the eGGSN quota server is selected as a prepaid quota server, it can receive prepaid messages, such as User Authorization and Service Authorization messages.

Single IP routing requires that Cisco-specific VSA subattributes eggsn_qs and eggsn_qs_mode must both be present in the same RADIUS Accounting Start or Update request.

Route Injection

Route injection enables the CSG2 to advertise routes for subscriber IP address pools via the Open Shortest Path First (OSPF) protocol. This allows adjacent routers to dynamically route traffic for a subscriber to the CSG2 that owns the subscriber, instead of utilizing static routing mechanisms such as static IP routes or policy-based routing.

1. The CSG2 receives the routes to be injected in RADIUS Accounting Start or RADIUS Interim Accounting Request messages.

2. The CSG2 extracts the route injection mask from the RADIUS Access-Accept message or RADIUS Accounting-Request message by using the Cisco subattribute 1 VSA. The format of the VSA is:

–Attribute number: 26 (=vendor specific)

–Vendor ID: 9 (=Cisco)

–Subattribute: 1 (=Cisco generic)

–Format: csg:dl_subnet_mask= mask

The mask must be something like 255.255.255.0 or 255.255.0.0. Mask definitions in the following format are not supported: /32, /24, /8.

3. The CSG2 inserts the mask and an IP prefix into the routing table.

4. The OSPF routing protocol advertises the route to the Supervisor Engine, which in turn determines the flows to be routed back through the CSG2.

Multiple subscribers can use the same route. When all of the subscribers using a given route log off, the CSG2 removes the route from the routing table.

To enable route injection for the CSG2, enter the following commands in global configuration mode:

csg2(config)# router mobile

csg2(config)# ip csg radius route inject

Dynamic Redirection

The CSG2 extends the Cisco-Flow-Status AVP to enable PCRF-specified redirection for a charging rule or service. If the PCRF had previously specified a Cisco-Flow-Status of BLOCK for the rule or service, it might instead specify a Cisco-Flow-Status of REDIRECT. The PCRF also includes the grouped Redirect-Server-AVP to specify the Redirect-Server information. The PCRF-specified redirect takes effect immediately, and is not related to the redirect for prepaid charging low-quota situations.

The CSG2 supports dynamic redirection for HTTP, Session Initiation Protocol (SIP), and wireless application protocol (WAP) URLs. The CSG2 does not support Layer 3 redirection to an Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) address. Mid-stream transactions and protocols other than HTTP, SIP, and WAP are blocked.

You cannot use the ip csg redirect command in conjunction with dynamic redirection.

Preloading Policies

The CSG2 can preload global billing plans, contents, domain groups, headers, header groups, maps, Quality of Service (QoS) profiles, policies, and services, as necessary, from the PCRF.

If configured to do so, the CSG2 preloads policies when it boots up. However, you can also dynamically load new and changed policies at any time, without rebooting the CSG2.

Note The standby CSG2 must have replicated all preloaded policy information before requesting replicated User Table, session, and service information from the active CSG2.

To preload policies for the CSG2 from the PCRF without rebooting, enter the following command in privileged EXEC mode:

csg2# csg start preload

You can also configure a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the PCRF.

To configure a delay and retry number, enter the following command in global configuration mode:

csg2(config)# ip csg preload request 
delay delay-in-seconds retries number-of-retries

Preloaded policies are subject to the same requirements and restrictions as policies that are configured via CLI. In general, preloaded CSG2 components cannot reference or be associated with components that are configured via CLI, and vice versa. The following sections list additional considerations to keep in mind when preparing policies for preloading:

•Preloaded Billing Plans

•Preloaded Contents

•Preloaded Domain Groups

•Preloaded Headers

•Preloaded Header Groups

•Preloaded Maps

•Preloaded Policies

•Preloaded Services

Preloaded Billing Plans

When preparing billing plans for preloading, keep the following considerations in mind:

•Only one billing plan (either preloaded or configured via CLI) can be the default billing plan.

•All services and QoS profiles associated with a preloaded billing plan must also be preloaded.

•If you associate more than one preloaded service with a given preloaded billing plan, the services must have different content/policy pairs.

•You cannot associate more than one preloaded service that is configured with activation automatic with a given preloaded billing plan.

•A preloaded service that is configured with mode prepaid virtual can be associated only with a preloaded billing plan that is configured with mode prepaid.

•Virtual prepaid mode is supported for preloaded billing plans.

Preloaded Contents

When preparing contents for preloading, keep the following considerations in mind:

•All client groups, domain groups, and policies associated with a preloaded content must also be preloaded.

•All VRFs associated with a preloaded content must be preconfigured via CLI, using the vrf definition command in global configuration mode.

•If parse protocol wap is configured for a preloaded content, you must also configure the udp keyword on the ip command for that content.

•You cannot specify just one port with a value of zero on the ip command for a preloaded content. Both the beginning port number and the ending port number must be zero, or neither can be zero.

•You cannot remove a preloaded content that is currently referenced by a service.

•You cannot specify duplicate preloaded contents (that is, contents configured with the same options).

•You cannot configure a preloaded content with an invalid IP address/IP mask combination or an unknown application type.

Preloaded Domain Groups

You cannot configure the same priority for two different domain groups (either preloaded or configured via CLI).

Preloaded Headers

When preparing headers for preloading, keep the following considerations in mind:

•You cannot specify duplicate RADIUS attributes or VSA subattributes for a given preloaded header.

•RADIUS attribute 26 requires the Vsa-Vendor-Id and Vsa-Subattribute-Type Attribute Value Pairs (AVPs). The Vsa-Vendor-Id and Vsa-Subattribute-Type AVPs are valid only for RADIUS attribute 26.

Preloaded Header Groups

All headers associated with a preloaded header group must also be preloaded.

Preloaded Maps

When preparing maps for preloading, keep the following considerations in mind:

•Preloaded header and attribute maps must contain an attribute string.

•You cannot remove a preloaded map that is currently referenced by a policy.

•You cannot modify a preloaded map that is referenced by a content that is currently in service.

Preloaded Policies

When preparing policies for preloading, keep the following considerations in mind:

•All header groups and maps associated with a preloaded policy must also be preloaded.

•You cannot remove a preloaded policy that is currently referenced by a content or service.

•All class maps associated with a preloaded policy must be preconfigured via CLI, using the class-map command in global configuration mode.

Preloaded Services

When preparing services for preloading, keep the following considerations in mind:

•All header groups and QoS profiles associated with a preloaded service must also be preloaded.

•You cannot configure a content/policy pair for a preloaded service if it is already configured for a different service in the same billing plan.

•A policy must already be configured for a content before configuring the associated content/policy pair.

•You cannot configure basis byte tcp for RTSP, SIP, or WAP. Therefore, basis byte tcp is mutually exclusive with meter exclude control sip and meter exclude mms wap for preloaded services.

•You cannot configure basis byte tcp for a preloaded service unless all associated preloaded contents are TCP-only.

•If you configure basis second for a preloaded service, you must configure all associated content commands with weight 1 (the default setting).

•If you configure basis second or basis second connect for a preloaded service, you cannot configure the refund command.

•If you configure basis second connect for a preloaded service, you cannot configure the following commands:

–aoc append url

–aoc confirm

–aoc enable

–idle

–meter include imap

–verify confirm

–verify enable

•If you configure meter exclude control sip for a preloaded service, you must also configure basis byte ip, basis fixed, or basis second transaction for the service.

•If you configure meter exclude mms wap for a preloaded service, you must also configure basis byte ip or basis fixed for the service.

•If you configure meter exclude pause rtsp or meter exclude svc-idle for a preloaded service, you must also configure basis second for the service.

•If you configure meter increment, meter initial, or meter minimum for a preloaded service, you must also configure basis second or basis second connect.

•Dual basis for a preloaded service has the same requirements and restrictions as first basis. The dual basis must be different from the first basis.

•All refund policies associated with a preloaded content must be preconfigured via CLI, using the ip csg refund command in global configuration mode.

Gx TCP Signature Reporting

The CSG2 supports exporting the IP and TCP headers from a subscriber TCP SYN (or SYN-ACK) packet to a Policy and Charging Rule Function (PCRF) device via the Gx protocol. The PCRF selectively arms a Cisco per-user TCP Signature trigger to request the TCP signature information. The subscriber must be identified as a Gx user to allow this reporting to the PCRF.

The PCRF can arm the TCP Signature trigger using a subscriber Credit Control Answer (CCA) or Resource Allocation Request (RAR) message. The CSG2 reports the TCP signature of the next TCP flow in a subscriber Credit Control Request-Update (CCR-U) message. After the trigger is hit, it is cleared until it is armed again by the PCRF.

The TCP Signature trigger can be used with or without the User Agent trigger for the same session.

There are no CSG2 commands required to enable this support.

Gx User Agent Reporting

To improve modem mode detection, the CSG2 supports exporting the User Agent headers from a subscriber TCP SYN (or SYN-ACK) packet to a PCRF device via the Gx protocol. The PCRF selectively arms a Cisco trigger to request the User Agent information. The subscriber must be identified as a Gx user to allow this reporting to the PCRF.

The PCRF can arm the User Agent trigger using a subscriber CCA or RAR message. The CSG2 reports the User Agent header of the next HTTP or WAP 1.x transaction that contains a User Agent header in a subscriber CCR-U message. After the trigger is hit, it is cleared until it is armed again by the PCRF.

The User Agent trigger can be used with or without the TCP Signature trigger for the same session.

There are no CSG2 commands required to enable this support.

Dynamic Provisioning of 3GPP Per-User DGRs

The CSG2 uses a 3GPP-compliant PCC architecture to dynamically download 3GPP per-user Dynamic Gx Rules (DGRs) for each subscriber PDP context. The CSG2 supports unsolicited provisioning of rules by the PCRF. The eGGSN, if present, establishes the PDP context only after downloading the PCC rules.

The CSG2 includes a number of elements as AVPs in updates sent to the PCRF (such as SGSN Address, RAT, and so on). In addition, the CSG2 reports the time of the mobile (not of the gateway) in CCR and Resource Allocation Answer (RAA) messages.

The CSG2 can dynamically provision 3GPP per-user DGRs using both standard AVPs and Cisco AVPs.

When provisioning with standard AVPs, the CSG2 uses the following procedure:

Step 1 After identifying a user as a Gx user, the CSG2 sends a Diameter CCR to the PCRF.

Step 2 The PCRF responds with a CCA message with one or more Layer 4 DGRs formatted as standard Charging-Rule-Definition AVPs.

Step 3 The CSG2 associates the DGRs with the User Table entry, downloads the DGRs, and sends a RADIUS CoA Request to the GGSN when complete.

Note If the CSG2 is a Gi-node, it does not send a RADIUS CoA to the GGSN. Instead, it delays the proxy or acknowledgement of the RADIUS Accounting Request until it has successfully downloaded the rules.

If the PCRF fails, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.

When provisioning with Cisco AVPs, the CSG2 uses the following procedure:

Step 1 After identifying a user is a Gx user, the CSG2 sends a Diameter CCR to the PCRF.

Step 2 The PCRF responds with a CCA message with one or more Layer 4 DGRs formatted as Cisco-Charging-Rule-Definition AVPs. (The use of Cisco-Charging-Rule-Definition AVPs enables features that are available with configured Gx contents.)

Step 3 The CSG2 associates the DGRs with the User Table entry, downloads the rules, and proxies (or ACKs) the RADIUS request when complete.

Note If the CSG2 is a Gi-node, it does not send a RADIUS CoA to the GGSN. Instead, it delays the proxy or acknowledgement of the RADIUS Accounting Request until it has successfully downloaded the rules.

If the PCRF fails, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.

There are no CSG2 commands required to enable this support.

Dynamic Provisioning of Cisco Per-User DGRs

The CSG2 supports Layer 7 DGRs by referencing global contents, policies, and services that are either configured or dynamically downloaded. The CSG2 dynamically provisions Cisco per-user DGRs using Cisco AVPs.

When provisioning with standard AVPs, the CSG2 uses the following procedure:

Step 1 After identifying a user is a Gx user, the CSG2 sends a Diameter CCR to the PCRF.

Step 2 The PCRF responds with a CCA message with one or more Layer 7 DGRs formatted as Cisco-Charging-Rule-Definition AVPs. The CCA can also include one or more Layer 4 DGRs formatted as either standard Charging-Rule-Definition AVPs or Cisco-Charging-Rule-Definition AVPs.

Step 3 The CSG2 associates the DGRs with the User Table entry, downloads the rules, and proxies (or ACKs) the RADIUS request when complete.

Note If the CSG2 is a Gi-node, it does not send a RADIUS CoA to the GGSN. Instead, it delays the proxy or acknowledgement of the RADIUS Accounting Request until it has successfully downloaded the rules.

If the PCRF fails, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.

There are no CSG2 commands required to enable this support.

Gx Event Triggers

The CSG2 supports the use of armed event triggers to provide the following roaming features in a Gx-enabled network:

•Dynamic blocking of subscriber traffic, of a service, or of a change in the service-level Qos when a subscriber roams. The PCRF might also indicate that the CSG2 is to continue forwarding traffic without blocking or modifying any QoS.

•Blocking the establishment of the PDP context, or of traffic for specific DGRs or services when a subscriber roams.

•Policy reauthorization.

The CSG2 supports the following 3GPP Gx event triggers:

There are no CSG2 commands required to enable this support.

Volume and Duration Triggers

The CSG2 can report excessive DGR volume usage and duration to the PCRF.

•The PCRF specifies the maximum DGR volume usage in an armed volume trigger. When a subscriber passes traffic that matches a DGR, and the IP byte volume (uplink plus downlink) associated with the DGR equals or exceeds the trigger value, the CSG2 reports the usage for the DGR to the PCRF in a CCR and disables the trigger. The PCRF can re-arm the trigger in the CCA.

•The PCRF specifies the maximum DGR duration for an armed time duration trigger. When a subscriber passes traffic that matches a DGR, the CSG2 notes the timestamp of the first packet. Each time the CSG2 processes another packet, it compares the timestamp to that of the first packet. If the difference between the two timestamps exceeds the duration trigger, the CSG2 reports the usage for the DGR to the PCRF in a CCR and disables the trigger. The PCRF can re-arm the trigger in the CCA.

There are no CSG2 commands required to enable this support.

Per-Subscriber Volume and Time Thresholds

The CSG2 provides per-subscriber volume and time thresholds. These thresholds, which do not require a corresponding charging rule, enable you to selectively and dynamically control subscriber IP flows (IMS and non-IMS) for flow-gating, differentiated billing and charging, and QoS.

The per-subscriber volume threshold is triggered each time the sum of all bytes for the subscriber exceeds the specified threshold. The CSG2 then sends a CCR-U to the PCRF with the current volume of traffic and resets the trigger. When the threshold is reached, the PCRF can make the decision to change the QoS.

The per-subscriber time threshold is triggered when the time between the first packet and the current packet exceeds the time threshold. The CSG2 then sends a CCR-U to the PCRF and resets the trigger.

Each event that is triggered is reported in its own CCR-U; events are not grouped.

Charging rule triggers can still be used in conjunction with these per-subscriber triggers. Each trigger generates its own independent CCR-U to the PCRF when the threshold is exceeded.

There are no CSG2 commands required to enable this support.

The output of the show ip csg users detail command includes the Subscriber Sign-On Timestamp and User Table Entry Creation Time fields.

Support for 64-Bit Volume Threshold over Gx Interface

The CSG2 supports both 32-bit and 64-bit volume threshold values over the Gx interface. These values, in bytes, mean that subscribers can be provisioned with volume thresholds of up to 2 GB and up to 4 GB, respectively.

•If the PCRF sends the 64-bit AVP to the CSG2, the CSG2 uses that AVP.

•If the PCRF sends the 32-bit AVP to the CSG2, the CSG2 uses that AVP.

•If the PCRF sends both the 32-bit and 64-bit AVPs to the CSG2, the CSG2 uses the 64-bit AVP.

There are no CSG2 commands required to enable this support.

Service Flow Detection Triggers

The CSG2 can notify the PCRF when it receives the first packet that matches a DGR. The PCRF requests the notification in an armed service flow detection trigger. When a subscriber passes traffic that matches a DGR, the CSG2 notifies the PCRF in a CCR, disables the trigger, and handles the traffic. The PCRF can re-arm the trigger in the CCA.

There are no CSG2 commands required to enable this support.

Gx Event Trigger Usage Reporting

The PCRF can instruct the CSG2 to include usage information in the CCR-U when an event trigger is hit. The CSG2 includes volume and time usage for each rule, service group, and the user, as well as the most recent values in the Gx AVPs, or the lack of AVPs if they are absent. Each usage is then reset to 0, the CSG2 disables the trigger, and the PCRF can re-arm the trigger in the CCA.

The CSG2 supports the following 3GPP Gx event triggers:

There are no CSG2 commands required to enable this support.

Gx Usage Query

The Gx Usage Query feature enables the PCRF to query the current volume and time usage from the CSG2 in a single Resource Allocation Request (RAR) message rather than multiple messages. That reduces the number of flows required. The CSG2 sends the usage values to the PCRF in a Resource Allocation Answer (RAA) message.

There are no CSG2 commands required to enable this support.

Gx Service Groups

The CSG2 Gx implementation provides several per-subscriber controls (such as thresholds and Cisco QoS enforcement) that are implemented at various levels - user level, service level, and charging rule level.

Note All of these controls pertain to individual subscribers. For example, "service level" means control of a service for an individual subscriber, not a service aggregated over many subscribers.

The PCRF can specify controls for groups of services for a given subscriber. The controls that are implemented for service groups are:

•Cisco QoS

•Volume and Time Triggers and Thresholds

•Flow Gating (Permit/Drop/URL Redirect)

For a given subscriber, a service can be a member of a only one service group. Thus, a user IP flow might be a member of a single service group (as well as a member of a single service). The service group volume threshold and QoS are shared among all flows on a packet-by-packet basis (that is, the threshold and QoS are not split in any pre-determined way among flows or services).

When a subscriber sends traffic that matches a service, any block or redirect that is associated with the service is applied. If the traffic is allowed to pass by the service, the service group flow status is applied.

The threshold implementation is similar to the per-user, per-service, and per-rule implementations. The PCRF can enable or disable the feature by arming and disarming the triggers and thresholds in CCA and RAR messages.

Service group control and service membership in a group must be specified via Gx by the PCRF. Service group control is not configurable via commands nor specified via the GTP' prepaid interface.

The CSG2 sends service group information in CDRs.

There are no CSG2 commands required to enable this support.

Billing Plan Assignment and Modification

The PCRF can assign a new or changed billing plan to a CSG2 subscriber. The PCRF sends the billing plan assignment to the CSG2, and the CSG2 then associates the billing plan with a User Table entry.

If there is already a RADIUS or quota server billing plan assigned to the subscriber, the PCRF billing plan overrides the existing billing plan. When the PCRF overrides an existing billing plan, the CSG2 immediately ends all existing user transactions and services for that subscriber.

There are no CSG2 commands required to enable this support.

PDP Context QoS Signaling

The eGGSN can signal a QoS change for a PDP context by sending a PDP Update Request to the SGSN. If the SGSN rejects the QoS Update Procedure, the eGGSN increments a counter.

This feature is supported only on in eGGSN mode, not in Gi-node mode.

There are no CSG2 commands required to enable this support.

Secondary PDP Context Activation

The GGSN can send a RADIUS Accounting Start Request to the CSG2, requesting a new Accounting-Session-Id for an existing subscriber. The CSG2 then sends a Diameter CCR to the PCRF, and the PCRF responds with a CCA message, provisioning zero, one, or more Layer 4 or Layer 7 DGRs formatted as either standard Charging-Rule-Definition AVPs or Cisco-Charging-Rule-Definition AVPs.

There are no CSG2 commands required to enable this support.

PCRF-Specified Service-Level and User-Level QoS

The PCRF can specify QoS parameters for the CSG2 to apply to a specific service for a user, or to all traffic for a user.

There are no CSG2 commands required to enable this support.

PCRF Failure Handling

The PCRF can fail to respond to the PCEF if all of the Diameter peers for the MPCC profile are down, too busy, unable to deliver, or looping. If that occurs, and if configured to do so, the CSG2 can take the following actions:

•Apply the already provisioned per-user rules to the flows

•Report the failed PCRF in BMA CDRs and quota server messages

•Switch to a standby PCRF

To define PCRF failure handling for the CSG2, enter the following command in global configuration mode:

csg2(config-csg-user-profile)# pcrf failure 
[continue | terminate]

CCR-I Retry Feature

In current implementation, when CCR-I fails due to peer failure or transaction timeout, CSG2 assigns default billing plan and never interacts with PCRF till user session is re-established.

By allowing CCR-I to be retried, user can be assigned subscribed billing plan and user session can be monitored for the usage by PCRF.

For CCR-I retry, CSG2 uses the following procedure:

Step 1 The PGW sends a RADIUS Accounting Start Request to the CSG. It contains the Gx enabled flag.

Step 2 CSG2 sends a CCR-I to the PCRF.

Step 3 CCR-I Timeouts/fails. PCRF timeout/failure continue has been configured. User is created with user default billing plan.

Step 4 User level time threshold trigger is armed.

Step 5 Time threshold trigger fires and CSG2 retries the CCR-I message to the PCRF.

Step 6 If CSG2 does not receive CCA-I or receives CCA-I with 3002, 3004 or 3005 response code, then continue again from Step 4.

Prerequisites:

•Configure pcrf failure continue and pcrf timeout continue under csg user profile configuration.

•Traffic flow should be present for this CCR retry feature to work.

To configure the CCR-I retry, enter the following command in csg user profile configuration mode:

csg2(config-csg-user-profile)# pcrf 
continue reauth ccr-i time

csg2(config-csg-user-profile)# no pcrf 
continue reauth ccr-i time

Note The reauth time can be any value between 0 and 4294967295, 0 being the equivalent of `no' form of the CLI.

CCR-U Retry Feature

In current implementation, when a CCR-U fails due to peer failure or transaction timeout, CSG2 will stop reporting usage unless PCRF sets the trigger again via RAR/CCA-U.

By allowing CCR-U to be retried, CSG2 can report interim usage to PCRF.

For CCR-U retry, CSG2 uses the following procedure:

Step 1 Trigger traffic which in turn will trigger CCR-U retry.

Step 2 CSG2 sends a CCR-U to the PCRF for the given trigger.

Step 3 CCR-U timeouts/fails. PCRF timeout/failure continue has been configured.

Step 4 User level time threshold trigger is armed.

Step 5 Time threshold trigger fires and CSG2 retries the CCR-U message to the PCRF.

Step 6 If CSG2 does not receive CCA-U or receives CCA-U with 3002, 3004 or 3005 response code, then continue again from Step 4.

Prerequisites:

•Configure pcrf failure continue and pcrf timeout continue under csg user profile configuration.

•Traffic flow should be present for this CCR retry feature to work.

To configure the CCR-U retry, enter the following command in csg user profile configuration mode:

csg2(config-csg-user-profile)# pcrf 
continue reauth ccr-u time

csg2(config-csg-user-profile)# no pcrf 
continue reauth ccr-u time

Note The reauth time can be any value between 0 and 4294967295, 0 being the equivalent of `no' form of the CLI.

Diameter Error Processing

If a Diameter Gx CCR request is sent to a peer and any of the following results occurs, the CSG2 AAA protocol stack retries the request on another diameter peer in the AAA server group:

•Error response with Result-code = 3002: DIAMETER_UNABLE_TO_DELIVER

•Error response with Result-code = 3004: DIAMETER_TOO_BUSY

•Error response with Result-code = 3005: DIAMETER_LOOP_DETECTED

•Transaction timeout: no response before the transaction timer expires

The CSG2 AAA protocol stack tries every peer in the diameter peer AAA server group in sequence, until a response other than one of the above results is received. (That is, until the CSG2 receives a successful response with a 2001 Result-code, or some other error response such as a 5012 Result-code.) The CSG2 AAA stack does not retry the CCR to the same peer in the AAA server group.

So, in a typical scenario in which the AAA server group contains two peers, the CCR might be tried to the primary peer, with a retry sent to the secondary peer after a transaction timeout or 3002/3004/3005 error response.

User Session Continuation After PCRF Timeout

If configured to do so, and if all of the Diameter peers for the MPCC profile are down, the CSG2 can take the following actions in the event that the PCRF times out:

•The CSG2 applies the already provisioned per-user rules to the flows.

•The CSG2 reports the timed-out PCRF in BMA CDRs and quota server messages.

•The CSG2 switches to a standby PCRF.

To define PCRF timeout handling for the CSG2, enter the following command in global configuration mode:

csg2(config-csg-user-profile)# pcrf timeout 
[continue | terminate]

Configurable Counting Behavior for Gx CCR-U Timeouts or Errors

By default, the CSG2 continues to count usage if the CCR-U fails for any reason, such as a timeout. However, you can enable the CSG2 to stop counting usage if the CCR-U fails. To do so, enter the following command in global configuration mode:

csg2(config)# ip csg ccr-u-fail stop-count

Restrictions for Gx

For Gx, the CSG2 imposes the following restrictions:

•The CSG2 does not provide IPv6 transport for the control plane interfaces.

•In a Gx charging rule, the flow descriptions in both the uplink and downlink directions must map to the same service.

•Mapping an existing flow or session to a new DGR is not supported.

•Provisioning of charging gateways (BMAs, quota servers, and so on) is not supported.

•Policy control for HTTP X-Forwarded-For data packets is not supported.

•Per-rule QoS is not enforced on the CSG2.

•If a global content update results in changed parameters, the CSG2 closes all open transactions and sessions associated with the content.

•Only one external preloading server can be active at any given time.

•If the CSG2 receives a flow before it receives per-user PCC rules from PCRF, the CSG2 matches the flow against existing CSG2 contents.

•Preloaded policy objects must not reference CLI-configured objects, and vice versa. For example, a preloaded billing plan must not reference a CLI-configured service.

•You cannot use preloading to modify a CLI-configured object, and you cannot use the CLI to modify a preloaded policy object.