Cisco GGSN Release 9.2 Configuration Guide, Cisco IOS Release 12.4(22)YE3

Implementing Enhanced Service-Aware Billing

This chapter describes how to implement the Cisco Gateway GPRS Support Node (GGSN) as a service-aware GGSN. A service-aware GGSN is capable of real-time credit-control for prepaid subscribers and service-aware billing for postpaid and prepaid subscribers.

Note Service-aware GGSN functionality is supported for IPv4 PDP contexts only.

For complete descriptions of the GGSN commands in this chapter, refer to the Cisco GGSN Command Reference for the Cisco GGSN release you are using. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

This chapter includes the following sections:

•Service-Aware GGSN Overview

•Reviewing Limitations and Restrictions

•Enabling Support for Service-Aware Billing

•Configuring Wait Accounting

•Configuring the GGSN to Generate Enhanced G-CDRs

•Configuring Quota Server Support on the Cisco GGSN

•Monitoring and Maintaining the Quota Server-to-CSG2 Configuration

•Implementing Service-Aware Billing with Diameter/DCCA Support

•Implementing Service-Aware Billing with OCS Address Selection Support

•Enabling PCC on an APN

•Configuring Standalone GGSN Prepaid Quota Enforcement

•Configuring the Charging Record Type on an APN

•GTP-Session Redundancy for Service-Aware PDPs Overview

•Configuring Per-Service Local Sequence Number Synchronization

•Trigger Conditions for Enhance Quota Server Interface Users

•Configuration Examples

Service-Aware GGSN Overview

Implemented together, the Cisco GGSN and Cisco CSG2 function as a service-aware GGSN.

There are two methods of implementing a service-aware GGSN; using the Cisco GGSN and Cisco CSG2 configuration with Cisco IOS Diameter protocol/Diameter Credit Control Application (DCCA) support on the GGSN, or implementing a service-aware GGSN using the Cisco GGSN and Cisco CSG2 configuration with Online Charging Service (OCS) address support on the GGSN.

In a service-aware GGSN implementation, the Cisco CSG2 and GGSN provide the following functions:

•The Cisco CSG2

–Inspects packets and categorizes traffic

–Requests quota and reports usage

–Provides billing plans, service names, and content definitions

–Acts as a RADIUS proxy for non-DCCA traffic

–Functions in prepaid mode for each service-flow charge recording

For detailed information about configuring the Cisco CSG2, see Cisco Content Services Gateway - 2nd Generation Installation and Configuration Guide.

http://www.cisco.com/en/US/products/sw/wirelssw/ps779/products_configuration_guide_book09186a0080856678.html

•When implemented with Diameter/DCCA, the GGSN

–Functions as a quota server to the Cisco CSG2

–Provides the Diameter interface to the DCCA server for quota requests and returns

–Manages the quota requested by the Cisco CSG2 and received from the DCCA server

–Maps DCCA server rulebases to Cisco CSG2 billing plans

–Maps DCCA server category quota to Cisco CSG2 service quota

•When implemented with OCS address selection support, the GGSN functions as a quota server for postpaid subscribers only. OCS address selection support enables an external OCS to which the Cisco CSG2 has a direct connection to provide online credit control for prepaid subscribers.

To implement a service-aware GGSN, complete the tasks in the following sections:

•Reviewing Limitations and Restrictions

•Enabling Support for Service-Aware Billing (Required)

•Configuring Wait Accounting (Required if support for service-aware billing is enabled on an APN)

•Configuring the GGSN to Generate Enhanced G-CDRs (Required)

•Configuring Quota Server Support on the Cisco GGSN (Required)

•Implementing Service-Aware Billing with Diameter/DCCA Support
(Required if OCS Address Selection Support is not enabled)

•Implementing Service-Aware Billing with OCS Address Selection Support
(Required if Diameter/DCCA Support is not configured)

•Configuring the Enhanced Billing Parameters in Charging Profiles (Required)

•GTP-Session Redundancy for Service-Aware PDPs Overview

Reviewing Limitations and Restrictions

Before implementing enhanced service-aware billing, note the following:

•If session redundancy is required, the GGSN supports a maximum of 21 categories per user.

•RADIUS accounting must be enabled between the Cisco CSG and GGSN to populate the KUT entries with the PDP context user information.

•The Cisco CSG2 must be configured with the quota server addresses of all the GGSN instances.

•If using DCCA, the service IDs on the Cisco CSG must be configured as numeric strings that match the category IDs on the DCCA server.

•If RADIUS is not being used, the Cisco CSG2 must be configured as a RADIUS proxy on the GGSN.

•On the SGSN, the values configured for the number GTP N3 requests and T3 retransmissions must be larger than the sum of all possible server timers (RADIUS, DCCA, and Cisco CSG2).

Specifically the SGSN N3*T3 must be greater than:

2 x RADIUS timeout + N x DCCA timeout + Cisco CSG2 timeout

where:

–2 is for both authentication and accounting.

–N is for the number of Diameter servers configured in the server group.

•If you enable support for service-aware billing on an APN, you must configure the GGSN to wait for a RADIUS accounting response before sending a Create PDP Context response to the SGSN.

Enabling Support for Service-Aware Billing

You must enable support for enhanced service-aware billing on the GGSN before you can implement service-aware billing features on the Cisco GGSN.

To enable service-aware billing support on the GGSN, complete the following task while in global configuration mode:

To enable service-aware billing support on a particular access-point, complete the following task while in access-point configuration mode.

Note If you enable support for service-aware billing on an APN, you must configure the GGSN to wait for a RADIUS accounting response before it sends a Create PDP Context response to the SGSN. For information about configuring the GGSN to wait for a RADIUS accounting response, see "Configuring Wait Accounting" section.

Configuring Wait Accounting

If service-aware billing is enabled on an APN, you must configure wait accounting on the GGSN. When wait accounting is configured on the GGSN, the waits for a RADIUS accounting response before it sends a Create PDP Context response to the SGSN

To enable wait accounting on the GGSN, complete the following task while in global configuration mode:

Note Wait accounting is required for an eGGSN implementation, but is optional for a Standalone GGSN Quota Enforcement.

Configuring the GGSN to Generate Enhanced G-CDRs

G-CDRs contain information for the entire duration of, or part of, a PDP context. The G-CDR includes information such as the subscriber (MSISDN, IMSI), APN used, QoS applied, SGSN ID (as the mobile access location), a time stamp and duration, the data volume recorded separately for the upstream and downstream direction, and volume thresholds for intermediate CDR generation and tariff time switches.

In addition to the information above, enhanced G-CDRs (eG-CDRs) also contain a service-record information element (IE) that contains the usage data of each service flow used by a PDP session, specified by category ID. For example, the upstream and downstream volume and the duration are recorded per service flow.

By default, the GGSN does not include the service records in G-CDRs. To support a service-aware GGSN implementation, you must configure the GGSN to generate eG-CDRs by configuring it to include service records in G-CDRs.

Note With Cisco GGSN Release 9.2 and later, the generation of enhanced G-CDRs (eG-CDRs) requires that charging release 7 has been configured on the GGSN by using the gprs charging release 7 global configuration command.

To configure the GGSN to include the service records in G-CDRs, use the following command while in global configuration mode:

To configure the GGSN to include the public land mobile network (PLMN) ID, radio access technology (RAT), or User Location Info fields in the service-record IE in eG-CDRs, use the following command while in global configuration mode:

Router(config)# gprs charging service-record include [plmn-id | 
rat | user-loc-info-change]

Configuring Quota Server Support on the Cisco GGSN

To configure quota server support on the GGSN, complete the tasks in the following sections:

•Configuring a Cisco CSG2 Server Group (Required)

•Configuring the Quota Server Interface on the GGSN (Required)

•Configuring the GGSN to Use the Cisco CSG2 as an Authentication and Accounting Proxy (Required if RADIUS is not being used)

•Monitoring and Maintaining the Quota Server-to-CSG2 Configuration

Configuring a Cisco CSG2 Server Group

We recommend that you configure two Cisco CSG2s (one active, the other standby) to function as one when interacting with the quota server process on the GGSN.

When configuring the Cisco CSG2 group that the GGSN quota server interface will use to communicate with the Cisco CSG2, you must specify a virtual IP address along with the real IP addresses of each of the Cisco CSG2s that make up the redundant pair. The quota server process on the GGSN communicates with the virtual address and the active Cisco CSG2 listens to the virtual IP address.

To configure a Cisco CSG2 group on the GGSN, complete the following tasks, beginning in global configuration mode:

Configuring the Quota Server Interface on the GGSN

In releases prior to Cisco GGSN Release 9.2, the GGSN uses the quota server interface to the Cisco CSG2 exchange of quota server messages to obtain usage information to generate eG-CDRs for the following types of users:

•Service-aware prepaid (Gy) and service-aware postpaid (QS) users

For prepaid subscribers or for postpaid subscribers configured as prepaid on the CSG2, the GGSN functions as the quota server and adds service containers to the eG-CDRs whenever it receives usage from the CSG2 over the quota server interface.

With Cisco GGSN Release 9.2 and later, you can specify the service-msg keyword option of the ggsn quota-server command to configure an enhanced quota server interface between the GGSN and Cisco CSG2. An enhanced quota server interface supports the exchange of service control messages that contain service usage information and enable the GGSN to generate eG-CDRs for the following additional types of users:

•Service-aware prepaid (GTP') users

In a service-aware GGSN implemented with OCS address selection, the GGSN does not function as a quota server for prepaid users. OCS address selection support enables the Cisco CSG2 to obtain quota from an external OCS to which it has a direct GTP' connection. The GGSN generates eG-CDRs by obtaining the service usage via the enhanced quota server interface.

•Service-aware postpaid users

The GGSN does not function as the quota server for service-aware postpaid users. The GGSN uses the enhanced quota server interface to obtain usage from the Cisco CSG2 and adds the usage to the eG-CDRs.

•Policy and Charging Control (PCC)-enabled (Gx) users

When Gx-enabled users are also prepaid (Gy) users support for eG-CDR generation is as present in releases prior to Cisco IOS Release 12.4(22)YE2 and the service containers are added to eG-CDRs based on the usage received in quota server messages.

When a Gx user is also a prepaid user in an implementation in which the CSG2 has a direct OCS interface, or a postpaid user (either service-aware or non service-aware), the GGSN will obtain usage from the CSG2 via the enhanced quota server interface and add the usage to the eG-CDRs.

Note With Cisco IOS Release 12.4(22)YE2 and later, when an enhanced quota server interface is enabled on the GGSN, the GGSN does not function as the quota server for service aware postpaid users or Gx postpaid users, therefore, these uses must be configured as postpaid on the Cisco CSG2. For information about configuring the Cisco CSG2, refer to the Cisco Content Services Gateway 2nd Generation - Release 3.5 Installation and Configuration Guide.

Quota Server Interface

The quota server interface on the GGSN provides support of the following:

•Attributes in RADIUS Accounting Start messages to the Cisco CSG2

–Billing plan ID—Corresponds with the rulebase ID received from a DCCA server. The quota server process on the GGSN maps the rulebase ID to the billing plan ID.

–Quota server address and port—IP address and port of the quota server that the Cisco CSG2 should use for a user.

–By default, this is the IP address of the GGSN unless OCS address selection support is enabled on the GGSN. For information about enabling OCS address selection support on the GGSN, see "Implementing Service-Aware Billing with OCS Address Selection Support" section.

–Downlink next hop address—Next hop address (user address) for downlink traffic (Cisco CSG2-to-GGSN).

•Threshold Limit Values (TLVs):

–Quota Consumption Timer (QCT). The QCT is assumed to be zero.

–Quota Holding Timer (QHT)

–Quota Threshold

For more information on the quota server interface, billing plans, and the QCT and QHT, see the Cisco Content Services Gateway Installation and Configuration Guide.

Enhanced Quota Server Interface

The enhanced quota server interface provides the additional support the following:

•Service control messages

–Service Control Request (SCR)

–Service Control Request Ack

–Service Control Usage (SCU)

–Service Control Usage Ack

•Attributes in RADIUS Accounting and Stop messages to the Cisco CSG2

–Quota server mode—Specifies the capability of the enhanced quota server interface; whether online charging is enabled or offline charging is enabled.

–eG-CDR correlator ID—Identifier that the GGSN uses to match Service Control Usage with the Service Control Request

When configuring an enhance quota server interface, note the following:

•An APN must be enabled for service-aware billing support (service-aware command) or PCC-enabled (pcc command) to trigger service control messages.

•GPRS Charging Release 7 must be configured as described in the "Configuring the Charging Release" section on page 6-8.

•Configure a charging record type for participating APNs as described in the "Configuring the Charging Record Type on an APN" section.

•Configure the sychronization for per -service local sequence number as described in the "Configuring Per-Service Local Sequence Number Synchronization" section.

•You can configure one quota server interface per GGSN. Configuring more than one quota server interface overwrites the existing interface.

To configure the quota server interface on the GGSN, complete the following tasks, beginning in global configuration mode:

Advertising the Next Hop Address For Downlink Traffic

To configure the next hop address (the user address) for downlink traffic (Cisco CSG2-to-GGSN) to be advertised in Accounting Start requests to the RADIUS endpoint, complete the following task while in access-point configuration mode:

GGSN(access-point-config)# advertise downlink 
next-hop ip-address

Configuring the GGSN to Use the Cisco CSG2 as an Authentication and Accounting Proxy

If you are not using RADIUS, you must configure the Cisco CSG2 as a RADIUS proxy.

To configure the GGSN to use the Cisco CSG2 as a RADIUS proxy, you must complete the following tasks:

•Configuring a Global RADIUS Server

•Configuring an AAA RADIUS Server Group that includes the Cisco CSG2

•Using Method List to Specify Supported Services

•Specifying Method Lists for an APN

Configuring a Global RADIUS Server

To configure a RADIUS server globally, complete the following tasks while in global configuration mode:

Configuring an AAA RADIUS Server Group that includes the Cisco CSG2

To define a AAA RADIUS server group, and include the Cisco CSG2 as a server in the server group, complete the following tasks, beginning in global configuration mode:

Using Method List to Specify Supported Services

To use AAA method lists to specify the types of services the group will support, complete the following tasks, beginning in global configuration mode:

Specifying Method Lists for an APN

To reference method lists for the APNs that will use the Cisco CSG2 as a RADIUS proxy, complete the following tasks while in access-point configuration mode:

Monitoring and Maintaining the Quota Server-to-CSG2 Configuration

Use the following commands in privileged EXEC mode to monitor and maintain the quota server-to-Cisco CSG2 configuration.

Router# clear ggsn quota-server statistics

Router# show ggsn quota-server [parameters | 
statistics]

Router# show ggsn csg [parameters | statistics]

Implementing Service-Aware Billing with Diameter/DCCA Support

To implement a service-aware GGSN with Diameter/DCCA support, complete the tasks in the following sections:

•Reviewing Service-Aware Billing with DCCA/Diameter

•Configuring the Diameter Base

•Configuring the DCCA Client Process on the GGSN

•Enabling Support for Vendor-Specific AVPs in DCCA Messages

•Configuring the Enhanced Billing Parameters in Charging Profiles

Reviewing Service-Aware Billing with DCCA/Diameter

In a service-aware GGSN implementation with DCCA, the Cisco CSG categorizes traffic, reports usage, and manages quota. The GGSN functions as a DCCA client to communicate with a DCCA server to provide the following functions:

•Diameter interface (Gy) to the DCCA server via which the Cisco CSG requests quota and reports usage.

•Quota negotiation by sending quota requests from the Cisco CSG2 to the DCCA server and pushing quota returns from the DCCA server to the Cisco CSG2.

•DCCA server rulebases to Cisco CSG2 billing plans mapping.

•DCCA server category quota to Cisco CSG2 service quota mapping.

•PDP maintenance and determining if a PDP is prepaid or postpaid.

If prepaid service-based charging or postpaid service-based charging are required, entries are created on the Cisco CSG. The Cisco CSG inspects the service categories, and reports usage to the GGSN. If the user is to be treated as a postpaid subscriber (offline charging), the GGSN records the usage information that is reported by the Cisco CSG in an eG-CDR. If the user is to be treated as a prepaid subscriber (online charging), the GGSN records the reported usage information in an eG-CDRs, and translates and sends the information to a DCCA server.

The GGSN also handles Gn-side triggers for quota reauthorization and server-initiated reauthorization or termination requests. The Cisco CSG sends the authorization requests, quota reports, and service stops to the GGSN,. The GGSN translates what the Cisco CSG sends into DCCA messages for transport over the Diameter interface. When the DCCA server responds with additional quota, the GGSN pushes the quota to the Cisco CSG.

Note If RADIUS is not being used, the Cisco CSG must be configured as a RADIUS proxy.

Figure 7-1 shows the functions and characteristics of a service-aware GGSN implemented with DCCA support.

Figure 7-1 High-Level Overview of Service-Aware GGSN Functions When Implemented with DCCA Support

t

Supported Features

To enable the implementation of a service-aware GGSN with DCCA, the Cisco GGSN supports the following features:

•Diameter/DCCA client interface support for online/real-time credit control for prepaid subscribers (IP PDP contexts only)

•Quota server functionality and interface to Cisco CSG for per-service billing

•Enhanced G-CDRs for service-based CDRs for prepaid and postpaid subscribers

•AAA authentication interface—DCCA rulebase support and charging profile selection

•AAA accounting interface—Cisco CSG Known User Table (KUT) population and Cisco CSG-based proxies

•Enhanced Ga interface for offline charging

Unsupported Features

The following features are not supported by a service-aware GGSN implementation with DCCA:

•Charging differentiation for secondary PDP contexts

•PPP PDP contexts

•PPP regeneration

•Network management

•Cell identity

•PDP contexts for both online DCCA exchange and offline service-based usage

•Dynamic configuration for blocking/forwarding traffic while waiting for quota reauthorization

•Diameter proxy, relay, or redirection

•Diameter transport layer security

•SCTP transport

•No dual quota support (for receiving volume and time quota)

Messaging Support

To support credit control via Diameter, the DCCA client process on the GGSN and the DCCA server exchange the following messages:

•Credit Control Request (CCR)—Initial, Update, and Final

•Credit Control Answer (CCA)—Initial, Update, and Final

In addition, the GGSN Diameter interface supports the following base Diameter messages:

•Capability Exchange Request (CER) and Capability Exchange Answer (CEA)—The GGSN advertises DCCA support in CER messages. In addition, the GGSN can be configured to advertise support for vendor-specific attribute value pairs (AVPs) using the diameter vendor support command in global configuration mode.

•Disconnect Peer Request (DPR) and Disconnect Peer Answer (DPA)—The GGSN sends a DPR message when the CER with a Diameter peer fails or there is no Diameter server configured.

•Device Watchdog Request (DWR) and Device Watchdog Answer (DWA)—The GGSN uses DWR and DWA messages to detect transport failures with a Diameter peer. A watchdog timer can be configured for each Diameter peer using the timer watchdog Diameter peer configuration command.

•Re-auth Request (RAR) and Re-auth Answer (RAA)

•Abort Session Request (ASR) / Abort Session Answer (ASA)—No Failed-AVP is sent in an ASA when an incorrect ASR is sent from the DCCA server.

As a DCCA client, the GGSN also receives the following notifications from Cisco IOS AAA:

•CCA message receipts

•Asynchronous session termination requests

•Server-initiated RARs

Service-Aware Billing with DCCA Data Flows

The following is a high-level overview of the flow of traffic during the creation of a PDP context for a prepaid subscriber in an enhanced service-aware billing implementation using DCCA.

PDP Context Creation Data Flow for Prepaid Subscribers

1. The SGSN sends a Create PDP Context request to the service-aware GGSN.

2. The GGSN sends an Access-Request message to the RADIUS (server or Cisco CSG2 configured as a RADIUS proxy).

3. The RADIUS returns an Access-Accept response. From the Access-Accept response, the GGSN obtains a default rulebase ID, or if the response does not contain a default rulebase ID, the GGSN obtains the rulebase ID from a locally configured value in the charging profile selected for the Create PDP Context request.

4. The service-aware GGSN sends a Diameter Credit Control Request (CCR) to the DCCA server.

5. The DCCA server returns a Credit Control Answer (CCA) to the GGSN. This CCA might contain a rulebase and quota request.

6. If the CCA contains a rulebase, the GGSN sends an Accounting-Start request with the selected rulebase to the RADIUS.

7. The RADIUS receives the Accounting-Start request from the GGSN and creates a KUT for the user.

8. The RADIUS sends an Accounting-Start response to the GGSN.

9. If the DCCA server sends a quota request in a CCA to the GGSN.

10. The GGSN pushes the quota request to the Cisco CSG2.

11. When the GGSN receives a quota push response from the Cisco CSG2, it sends the Create PDP Context response to the SGSN, and the context is established.

PDP Context Creation Data Flow for Postpaid Subscribers

1. The SGSN sends a Create PDP Context request to the service-aware GGSN.

2. The GGSN sends an Accounting-Start request containing the selected rulebase to the RADIUS (server or the Cisco CSG2 configured as a RADIUS proxy).

3. The RADIUS proxy receives the Accounting-Start request and creates a KUT for the user.

4. The RADIUS proxy sends an Accounting-Start response to the GGSN.

5. When the GGSN receives the Accounting-Start response from the RADIUS proxy, it sends a Create PDP Context response to the SGSN, and the context is established.

Configuring the Diameter Base

To configure the Diameter protocol base, complete the tasks in the following sections:

•Configuring a Diameter Peer

•Enabling Diameter AAA

•Configuring Diameter Protocol Parameters Globally

•Monitoring and Maintaining the Diameter Base

Configuring a Diameter Peer

To configure a Diameter peer, use the following commands, beginning in global configuration mode:

.

Enabling Diameter AAA

To enable Diameter AAA, complete the tasks in the following sections:

•Defining the Diameter AAA Server Group

•Defining an Authorization Method List for Prepaid Subscribers

Defining the Diameter AAA Server Group

For redundancy, configure Diameter servers as Diameter AAA server groups that consist of a primary and secondary server.

To define a Diameter AAA server group, use the following commands, beginning in global configuration mode:

Defining an Authorization Method List for Prepaid Subscribers

To apply parameters that restrict access to a network for prepaid subscribers, use the following command while in global configuration mode:

Configuring Diameter Protocol Parameters Globally

The GGSN uses global Diameter protocol parameters if you have not defined Diameter parameters at the Diameter peer level.

To configure global Diameter parameters, complete the following tasks while in global configuration mode:

Monitoring and Maintaining the Diameter Base

Use the following command in privileged EXEC mode to monitor and maintain Diameter peer configurations.

Router# show diameter peer

Configuring the DCCA Client Process on the GGSN

The GGSN functions as a DCCA client when interacting with the DCCA server to obtain and request quota. As a DCCA client, the GGSN sends CCR messages to and receives CCAs from the DCCA server for credit control sessions (one credit control session per PDP session). In addition, the defaults you configure in the DCCA client profile dictate how the GGSN handles credit control sessions if a server failover should occur and no instructions are sent by the server.

Failure Handling Defaults on the DCCA Client

The following two AVPs determine how the CC sessions are handled if a failover occurs:

•CC-Session-Failover AVP—Indicates that a CC session should fail over to the alternate Diameter server. You set this AVP by using the session-failover DCCA client profile configuration command.

•Credit-Control-Failure-Handling (CCFH) AVP—Determines how the GGSN behaves if a failure does occur. You set this AVP by using the ccfh DCCA client profile configuration command.

While you can configure defaults for these AVPs in the DCCA client profile for failure handling, the values received from the DCCA server override the defaults you configure on the GGSN.

The CCFH AVP determines the action the DCCA client takes on a session when the following fault conditions occur:

•Tx timeout expires.

•CCA message containing protocol error (Result-Code 3xxx) is received.

•CCA fails (for example, a CCA with a permanent failure notification [Result-Code 5xxx]) is received.

•Failure-to-send condition exists. (The DCCA client is not able to communicate with the desired destination.)

•An invalid answer is received.

To configure a DCCA client profile, in which you configure the characteristics of a DCCA client process, and reference to from the charging profile, use the following commands, beginning in global configuration mode:

.

Router(config-dcca-profile)# ccfh {continue | 
terminate | retry_terminate} 

Enabling Support for Vendor-Specific AVPs in DCCA Messages

The Cisco GGSN supports the following DCCA implementations:

•VF_CLCI (Vodafone)

•3GPP Gy-compliant (3GPP)

Note With Cisco GGSN Release 9.0 and later, neither of these implemenations are supported by default. A DCCA implementation must be explicitly enabled using the gprs dcca 3gpp command or the gprs dcca clci command.

The Gy-compliant implementation supports some additional 3GPP Vendor Specific Attributes (VSAs) in addition to the standard DCCA attributes. The VF_CLCI compliant implementation supports Vodafone specific VSAs, 3GPP VSAs where necessary, and the standard DCCA attributes.

The Cisco GGSN advertises the support of only DCCA application (Auth-Application-Id of 4) in CER messages. In addition, it advertises the support of the following Vendor Ids (for recognizing the vendor specific AVPs).

•Cisco (vendor id = 9)

•3GPP (vendor id = 10415)

•Vodafone (vendor id = 12645)

To enable the Cisco GGSN to send 3GPP VSAs in DCCA messages to the DCCA server, complete the following task while in global configuration mode.

Router(config)# gprs dcca 3gpp

To enable the GGSN to send Vodafone VSAs in DCCA messages to the DCCA server, in addition to the standard DCCA attributes and 3GPP VSAs, complete the following task while in global configuration mode.

Router(config)# gprs dcca clci

For a list of supported AVPs in respect to the Gy-based and VF-CLCI, refer to the Diameter Credit Control Application on the Cisco GGSN technical whitepaper.

Configuring the Enhanced Billing Parameters in Charging Profiles

The GGSN supports up to 256 charging profiles, numbered 0 to 255. Profile 0 is a set profile that always exists on the GGSN. It is the global default charging profile. You do not create profile 0, however, you can modify it using the charging-related global configuration commands. Profiles 1 to 255 are user-defined and customized using the Cisco GGSN charging profile configuration commands.

To support service-aware billing, you can configure a charging profile to allow eG-CDRs and suppress G-CDRs for all or only online charging.

You can also configure the following service-aware billing characteristics in a charging profile:

•The default rulebase-ID to apply to a user

•A default charging type (to be used primarily for a prepaid or postpaid subscriber)

•A default DCCA server to contact for quota requests (presence indicates online charging)

To configure service-aware billing characteristics in a charging profile, complete the tasks in the following sections:

•Specifying a Default Rulebase ID

•Specifying a DCCA Client Profile for Online Billing

•Suppressing CDRs for Prepaid Subscribers

•Configuring Trigger Conditions for Postpaid Subscribers

Specifying a Default Rulebase ID

In a service-aware implementation with Diameter/DCCA (see "Implementing Service-Aware Billing with Diameter/DCCA Support" section), rulebases contain the rules for defining categories of traffic; categories on which decisions such as whether to allow or disallow traffic, and how to measure traffic, are based. The GGSN maps Diameter rulebase IDs to Cisco CSG2 billing plans.

To configure a default rulebase ID to apply to PDP contexts using a particular charging profile, use the following command while in charging profile configuration mode:

Note The rulebase value presented in a RADIUS Access Accept message overrides the default rulebase ID configured in a charging profile. A rulebase ID received in a CCA initial message from a DCCA server overrides the rulebase ID received from the RADIUS server and the default rulebase ID configured in a charging profile.

For Gy:DCCA prepaid solution, the Rulebase ID cannot be received in a DCCA and the Rulebase ID does not apply to the standalone prepaid solution.

Specifying a DCCA Client Profile for Online Billing

When the primary PDP context is created, the charging profile is selected.

If you define a DCCA profile in the charging profile, online billing is indicated for that PDP. Therefore, regardless of whether or not a user is prepaid or postpaid, the GGSN contacts the DCCA server if the content dcca profile configuration is present.

Note This charging profile configuration requires that service-aware billing has been implemented with Diameter/DCCA (see "Implementing Service-Aware Billing with Diameter/DCCA Support" section.)

If the user is to be treated as a postpaid subscriber, the DCCA server returns a CAA with a result-code of CREDIT_CONTROL_NOT_APPLICABLE (4011) and the user is treated as a postpaid subscriber.

If a charging profile does not contain a DCCA profile configuration, users are treated as postpaid (offline billing).

To specify the DCCA client profile to communicate with a DCCA server, use the following command while in charging profile configuration mode:

Suppressing CDRs for Prepaid Subscribers

In a service-aware implementation with Diameter/DCCA (see "Implementing Service-Aware Billing with Diameter/DCCA Support" section), charging for prepaid subscribers is handled by the DCCA client; therefore, eG-CDRs do not need to be generated for prepaid subscribers.

To configure the GGSN to suppress eG-CDRs for users with an active connection to a DCCA server, use the following command while in charging profile configuration mode:

Note When enabled, if a Diameter server error occurs while a session is active, the user is reverted to postpaid status, but CDRs for the PDP context are not generated.

Configuring Trigger Conditions for Postpaid Subscribers

If a user is a prepaid subscriber not using an enhanced quota server interface, all the credit control is performed by the DCCA server. If the user is a postpaid subscriber not using an enhanced quota server interface, and service-aware billing is enabled, the default values configured in a charging profile define the conditions that control how often usages should be reported.

Note Triggers must be explicitly enabled for both prepaid and postpaid subscribers.

To define the trigger conditions in a charging profile for postpaid subscribers, use the following commands while in charging profile configuration mode:

Implementing Service-Aware Billing with OCS Address Selection Support

As an alternative to the GGSN with DCCA online charging solution, you can configure the GGSN to support OCS address selection. OCS address selection enables online credit control for prepaid subscribers to be provided by an external OCS to which the Cisco CSG2 has a direct GTP' interface. When you configure the GGSN to support OCS address selection, the GGSN functions as a quota server for postpaid subscribers only. The GGSN does not generate enhanced G-CDRs (eG-CDRs) for prepaid subscribers.

By default, the GGSN sends its IP address in Accounting-Start messages to the Cisco CSG2 (functioning as a RADIUS proxy) to establish itself as the quota server for postpaid and prepaid subscribers. When OCS address selection support is configured, if the IP address of an OCS is returned in the "csg:quota_server" attribute in an Access-Accept message from the AAA server, the GGSN forwards that address in the same attribute in an Accounting-Start message to the Cisco CSG2. This notifies the Cisco CSG2 to use the external OCS as the quota server for this PDP context. In a service-aware GGSN implementation using OCS address selection, the GGSN functions as the quota server for postpaid subscribers only.

Service-Aware Billing with OCS Address Selection Data Flows

The following is a high-level overview of the flow of traffic during the creation of a PDP context for a prepaid subscriber in an enhanced service-aware billing implementation using OCS address selection.

1. The SGSN sends a Create PDP Context request to the service-aware GGSN.

2. The GGSN sends an Access-Request message to the RADIUS endpoint (server or the Cisco CSG2 configured as a RADIUS proxy).

3. The RADIUS endpoint determines if the user is prepaid, and if so, responds to the Access-Request message with an Access-Accept message that includes the "csg:quota_server" attribute containing the IP address and port of an external OCS.

4. If the APN is configured as service-aware, and the GGSN is configured to generate eG-CDRs, the GGSN receives the Access-Accept from the RADIUS endpoint, and because the csg_quota_server attribute is present and includes the IP address of an OCS, the GGSN determines that the user is a prepaid subscriber, and returns an Accounting-Start request that includes the following attributes:

–csg:billing_plan

–csg:quota_server attribute—The csg:quota_server attribute contains the OCS IP address and port to the Cisco CSG2. If it does not, the GGSN forwards its own IP address in the csg:quota_server field.)

–csg:eggsn_qs—IP address and port number of the enhanced quota server interface.

–csg:eggsn_qs_mode—Indicates whether the enhanced quota server interface is enabled to exchange service control messages with the CSG2.

5. Upon receiving the Accounting-Start Request, the RADIUS endpoint performs the following:

a. Creates a KUT entry.

b. Identifies that the GGSN generates the eG-CDRs, and disables service level CDR generation for the user.

c. Identifies that the user is a prepaid user based on the billing plan received.

d. Enables the quota server message exchange with the specified OCS address.

e. Enables service control message exchange with the GGSN.

f. Sends an Accounting-Start Response to the GGSN.

6. The GGSN sends a Create PDP Context response to the SGSN, and the context is established.

7. When trigger conditions occur, Service Control Requests (SCRs) and Service Control Usage (SCU) messages are exchanged between the GGSN and CSG2 to add service containers to eG-CDRs, and/or close eG-CDRs.

8. The GGSN generates eG-CDRs and sends them to the charging gateway.

Note When an external OCS is used as the quota server for prepaid subscribers, the GGSN receives service-level usage reports from the Cisco CSG2 for postpaid subscribers and generates eG-CDRs accordingly. The GGSN does not generate eG-CDRs for prepaid subscribers unless an enhanced quota interface has been configured as described in "Configuring the Quota Server Interface on the GGSN" section.

OCS address selection support on the GGSN requires that the following conditions are met:

•Support for service-aware billing is enabled globally and at the APN level (see the "Enabling Support for Service-Aware Billing" section).

•Wait accounting is enabled (using the "Configuring Wait Accounting" section).

•GGSN is configured to communicate with the Cisco CSG2 (see the "Configuring Quota Server Support on the Cisco GGSN" section).

•The GGSN is configured to generate eG-CDRs (see the "Configuring the GGSN to Generate Enhanced G-CDRs" section).

•The correct configuration exists on the AAA server.

To enable OCS address selection support on the GGSN, use the following command while in global configuration mode:

Enabling PCC on an APN

The Gx interface is a reference point between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF). It is used for provisioning and removal of Policy and Charging Control (PCC) files from PCRF to PCEF.

When a Create PDP Context request is received from an SGSN on a PCC-enabled APN:

1. After authentication, the GGSN sends an Accounting Start messages to the CSG2 that contains the following Cisco AVPs (in addition to the other standard 3GPP attributes):

–pcc_enabled—Indicates whether a subscriber is a Gx user. If enabled, the CSG2 marks the subscriber as a Gx user and communicates with the PCRF for this subscribers session. (If not enabled, the CSG2 marks the subscriber as a non-Gx subscriber and does not communicate with the PCRF.)

–coa_flags—Indicates whether the GGSN supports Gx updates via RADIUS CoA messaging. If enabled, the GGSN supports Gx updates via RADIUS CoA messaging. (If not enabled, indicates MS-initiated QoS updates.)

2. If the GGSN is configured to generate eG-CDRs, in the Accounting Start message, the GGSN includes the following additional attributes:

–csg:eggsn_qs—IP address and port number of the enhanced quota server interface.

–csg:eggsn_qs_mode—Indicates whether the enhanced quota server interface is enabled to exchange service control messages with the CSG2.

3. Upon receiving the Accounting-Start Request, the CSG2 performs the following:

a. Creates a KUT entry.

b. Identifies that it is a Gx user based on the attributes received.

c. Identifies that GGSN generates the eG-CDRs, and disables service level CDR generation for the user.

d. Enables the exchange of service control messages with the enhanced quota server interface defined in the csg:eggsn_qs attribute in the Accounting Start message.

4. The CSG2 communicates with the PCRF to provision charging rules and the authorized QoS attributes.

5. The CSG2 sends a CoA request to the GGSN that notifies the GGSN of the authorization status and authorized QoS attributes, and sends an Accounting Start response to the GGSN.

6. The Cisco GGSN receives the CoA request, and based on the authorization status, sends the Create PDP Context response to the SGSN and the PDP context is created.

7. When trigger conditions occur, Service Control Requests (SCRs) and Service Control Usage (SCU) messages are exchanged between the GGSN and CSG2 to add service containers to eG-CDRs, and/or close eG-CDRs.

8. The GGSN generates eG-CDRs and sends them to the charging gateway.

Note If an APN is PCC-enabled, you must configure the GGSN to wait for a RADIUS accounting start response before sending a Create PDP Context response to the SGSN. For information about configuring wait accounting, see "Configuring Wait Accounting" section.

To configure an APN as a PCC-enabled APN, use the following command in access-point configuration mode:

Configuring Standalone GGSN Prepaid Quota Enforcement

You can implement prepaid quota enforcement using a service-aware GGSN, the Cisco GGSN and Cisco CSG2 implemented together to provide enhanced billing services, or you can implement prepaid quota enforcement using a Cisco GGSN operating in standalone mode.

When you implement the prepaid feature using a Cisco GGSN operating in standalone mode, the GGSN monitors data packets on volume basis, time basis, or both, for each prepaid subscriber. If you have configured the GGSN for both volume and time quota, the GGSN inspects both usages, and requests additional quota as soon as either usage meets its threshold or expires.

When configuring standalone GGSN prepaid quota enforcement, note the following:

•Support for service-aware billing must be enabled on the GGSN using the gprs service-aware global configuration command.

•The measurement of time starts as soon as the session is established.

•The GGSN monitors on a per-user basis, not on a per-service basis.

•In a redundant configuration, the active GGSN synchronizes quota allocated information with the standby GGSN when event triggers occur, such as at the time of each quota grant. Periodic synchronization of quota usage information is not performed. To ensure a user is not overcharged, the standby and active GGSNs maintain synchronization of the CC-Request-Number along with each quota grant.

•The GGSN monitors quota on a per-user basis, therefore, when the standalone GGSN requests quota, only one service is expected in the MSCC AVP. If the CCA contains multiple services, or no service in the MSCC AVP, the CCA is considered an invalid answer, and the CCFH determines the action.

•Only single service is supported. If multiple services are configured, the CCFH determines whether the GGSN rejects the PDP or converts it to postpaid.

•With a dual quota, the Quota Holding Timer (QHT) starts after the Quota Consumption Timer (QCT). Even though the QCT does not apply to volume quota, this behavior is due to time quota. With time quota, the QHT starts after the quota consumption ceases, which occurs after the QCT.

•If a DCCA profile is not configured under the charging profile, the PDP is rejected.

•Once a PDP is converted to postpaid, enhanced G-CDRs are no longer generated, only G-CDRs.

•In a redundant configuration, all timers (QHT, QCT, time threshold, etc.) except for the Quota Validity Timer (QVT) are restarted once the standby GGSN becomes active. The QVT timestamp is synchronized, and when a standby GGSN becomes active, the newly active GGSN waits for the remaining time to elapse instead of restarting the timer.

To configure the GGSN to perform quota enforcement for prepaid subscribers while in standalone mode, use the following command while in global configuration mode:

To configure the maximum limit on the volume/time quota threshold in terms of percentage of the volume/time quota received, use the following command while in global configuration mode:

When you configure the prepaid quota threshold, the threshold value used on the GGSN will be the lesser of the following:

•Threshold value received in a CCA

•Configured percentage of the quota grant.

To monitor standalone quota enforcement, use the following commands while in privileged EXEC mode:

Configuring the Charging Record Type on an APN

With Cisco GGSN Release 9.2, and later, you can configure the charging record type for an APN. This command is supported when one of the following conditions exists:

•You have configured the APN to be service-aware (see "Enabling Support for Service-Aware Billing" section) or PCC-enabled (see "Enabling PCC on an APN" section).

•You have configured the quota server interface to support the exchange service control messages (see "Configuring the Quota Server Interface on the GGSN" section).

•GPRS Charging Release 7 is configured (see "Configuring the Charging Release" section on page 6-8).

To configure the charging record type for an APN, use the following command while in access-point configuration mode:

You can configure the charging record type while in the following modes:

•global configuration

•charging profile configuration

•access-point configuration

When configuring the charging record type at the APN level, note that the charging profile configuration overrides the global configuration, and the APN level configuration overrides the charging profile configuration.

For example, you can enable eG-CDR generation globally by using the gprs charging cdr-option service-record command, and then configure the charging record type gcdr command under an APN to restrict the user of that APN to generate G-CDRs. The remaining service aware users will generate eG-CDRs.

If the charging record type command is not configure at the APN level, the default behavior is based on the existing eG-CDR generation global configuration set by using the gprs charging cdr-option service-record command.

GTP-Session Redundancy for Service-Aware PDPs Overview

GTP-Session Redundancy (GTP-SR) ensures that when an active GGSN fails, a standby GGSN has all the necessary information about a PDP context to continue service without interruption. In an enhanced service-aware billing environment, this means service-related information must also be synchronized from the active to standby service-aware GGSN. Therefore, with GGSN Release 5.2 and later, service-aware data necessary to establish charging for service-aware PDP sessions is synchronized with the standby GGSN.

The service-aware data synchronized with the standby GGSN includes the following:

•Per-PDP context services—Rulebase ID and DCCA failure handling settings (CCSF and CCSH AVPs).

•Per-category information—Category ID, Cisco CSG2 session, and category state and event triggers. Many category states are intermediate states; therefore, they are not synchronized to the standby service-aware GGSN. The following category states are synchronized: blacklist, idle, and authorized.

All event triggers are recorded. At the end of the processing of an event on the active GGSN, the clearing of the event's trigger is synchronized to the standby GGSN. If a switchover occurs, if an event trigger is found present on a category, the newly active GGSN re-initiates the event.

•Path states—The quota server process on the active GGSN synchronizes the state of the path to a Cisco CSG2 to the quota server process on the standby GGSN. The path echo timer on the standby quota server is not started unless the standby quota server becomes active. Path sequence numbers are not synchronized. After a switchover occurs, the newly active quota server starts from 0.

Note Category usage data is not synchronized from an active GGSN to the standby GGSN. This prevents over-reporting of usage if a switchover occurs.

GTP-SR for Service-Aware PDP Sessions Guidelines

In addition to the prerequisites listed in Chapter 5, "Configuring GGSN GTP Session Redundancy," to achieve session redundancy for service-aware PDP sessions, ensure that the following configurations exist on the redundantly configured service-aware GGSN's:

•GTP-SR is enabled on the GGSN using the gprs redundancy command in global configuration mode. Also, if the GGSN is functioning as a Diameter node, ensure that it is enabled to track session states by using the diameter redundancy command in global configuration mode. See the "Configuring the Diameter Base" section for information on configuring Diameter redundancy.

•The quota server process is configured the same on both the active GGSN and the standby GGSN. Specifically, on each active/standby pair, the quota server address is the same. To ensure that the Cisco CSG2 only talks to the active quota server process, configure it to always route messages for the quota server through the virtual HSRP address for the Gi interface. In reverse, the virtual Cisco CSG2 address is used by the GGSN to deliver messages to the active Cisco CSG2 of a redundant pair. See the "Configuring a Cisco CSG2 Server Group" section for more information about configuring a virtual Cisco CSG2 address.

•If using Diameter, you must configure a DCCA client source address on both the active GGSN and the standby GGSN. The DCCA client source address is the local address used in the TCP connection to the DCCA server. We recommend that you use a logical interface that is routable via a virtual HRSP address between the active GGSN and the standby GGSN.

For information on configuring Cisco IOS HRSP, see Configuring the Hot Standby Router Protocol section of the Cisco IOS IP Configuration Guide, Release 12.3. For detailed information on GTP-SR, see Chapter 5, "Configuring GGSN GTP Session Redundancy."

For information about fault-tolerance on the Cisco CSG2, see Cisco Content Services Gateway - 2nd Generation Installation and Configuration Guide.

http://www.cisco.com/en/US/products/sw/wirelssw/ps779/products_configuration_guide_book09186a0080856678.html

Configuring Per-Service Local Sequence Number Synchronization

The charging gateway uses the per service local sequence number to detect duplicate service containers associated with a PDP context.

To minimize the amount of data being synchronized to the standby GGSN, the per service local sequence number is not synchronized each time an eG-CDR is closed. Instead, the current value of the local sequence number and the local sequence number last synchronized for a PDP context is checked, and if the difference is more than the configured window size, the current local sequence number is synchronized with the standby GGSN. When a standby GGSN becomes the active GGSN, it starts from the last value synchronized, plus the window size.

To configure the window size that determines when the per service local sequence number is synchronized with the standby GGSN, use the following command in global configuration mode:

Trigger Conditions for Enhance Quota Server Interface Users

The Cisco GGSN generates eG-CDRs when the following types of trigger conditions occur when the Cisco CSG2 has a direct interface to an OCS, when a subscriber is a Gx user, or when a user is postpaid:

•PDP Context Modification

•Tariff Time Change

•Service Flow Reports

•eG-CDR Closure

Note The following trigger conditions do not require any special configuration on the GGSN. Volume and duration, and service flow triggers must be configured on the Cisco CSG2. For information about configuring the Cisco CSG2, refer to the Cisco Content Services Gateway 2nd Generation - Release 3.5 Installation and Configuration Guide.

PDP Context Modification

When the one of following PDP context modification triggers occur, the GGSN performs the following actions:

•RAT type, PLMN change, or MS time zone change

–Adds a volume container followed by the list of service containers.

–Closes the eG-CDR.

–If a SVC record limit is reached, closes the eG-CDR, opens a partial CDR, and adds the remaining SVC records to the new eG-CDR.

•QoS change or user location change

–Adds a volume container followed by a list of service containers.

–If the maximum change condition limit is reached, closes the eG-CDR.

–If a SVC record limit is reached, closes the eG-CDR, opens a partial CDR, and adds the remaining SVC records to the new eG-CDR.

•SGSN change

–Adds a volume container followed by a list of service containers.

–If the maximum SGSN limit is reached, closes the eG-CDR.

–Otherwise, if the maximum change condition limit is reached, closes the eG-CDR.

–In between, if there an SVC record limit is reached, closes the eG-CDR, opens a partial CDR, and adds the remaining SVC records to the new eG-CDR.

Tariff Time Change

When a tariff time change occurs, the GGSN performs the following actions:

•Adds a volume container

•If the maximum change limit is reached, closes the eG-CDR.

•If it is prepaid GTP' user, the Cisco CSG2 might send a service usage message and the GGSN adds it to the eG-CDR.

Service Flow Reports

When the following service flow trigger conditions occur, the GGSN generates service containers for each service:

•Time limit expiration

•Volume limit expiration

•Service flow termination

Volume and duration, and service flow triggers must be configured on the Cisco CSG2. For information about configuring volume and duration triggers, and service flow triggers on the Cisco CSG2, refer to the Cisco Content Services Gateway 2nd Generation - Release 3.5 Installation and Configuration Guide.

Additionally, for prepaid GTP' users, the GGSN generates service containers for the following trigger conditions when the same triggers are configured on the Cisco CSG2:

•Time threshold reached

•Volume threshold reached

•Time quota exhausted

•Volume quota exhausted

•Service data flow termination or when service idles out

eG-CDR Closure

When the following eG-CDR closure trigger conditions occur, the GGSN adds the volume containers followed by service containers, except for when CDRs are manually cleared:

•End of PDP context

•Partial record reason

–Data volume limit

–Time limit

–Maximum number of charging condition changes (QoS, tariff time, user-location-info change)

–Management intervention

–MS time zone change

–Inter-PLMN SGSN change

–RAT change

Configuration Examples

The following is one example of enhanced service-aware billing support configured on the GGSN.

Current configuration :3537 bytes

!

! Last configuration change at 15:26:45 UTC Fri Jan 7 2005

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service gprs ggsn

!

hostname sup-samiA

!

boot-start-marker

boot-end-marker

!

enable password abc

!

aaa new-model

!

!

!Configures the CSG2 RADIUS server group

!

aaa group server radius CSG-group

server 10.10.65.100 auth-port 1812 acct-port 1813

!

!Configures the Diameter server group

!

aaa group server diameter DCCA

server name DCCA

!

!

!Assigns AAA services to the CSG2 RADIUS and Diameter server groups

!

aaa authentication ppp CSG-list group CSG-group

aaa authorization prepaid DCCA group DCCA

aaa authorization network CSG-list group CSG

aaa accounting network CSG-list start-stop group CSG-group

aaa session-id common

ip subnet-zero

!

!

ip cef

!

!

...

!

!

gprs access-point-list gprs

!

...

!

!

!Enables service-aware billing on the GGSN

!

gprs service-aware

!

gprs access-point-list gprs

 access-point 10

  access-point-name cisco.com

  access-mode non-transparent

  aaa-group authentication CSG-list

  aaa-group accounting CSG-list

  gtp response-message wait-accounting

  charging profile any 1 override

  service-aware

  advertise downlink next-hop 10.10.150.2

  !

 access-point 20

  access-point-name yahoo.com

  access-mode non-transparent

  aaa-group authentication CSG

  aaa-group accounting CSG

  gtp response-message wait-accounting

  charging profile any 1 override

  service-aware

  !

 !

!

!Configures a DCCA client profile

!

gprs dcca profile 1

  ccfh continue

  authorization CSG-list

  destination-realm cisco.com

  trigger sgsn-change

  trigger qos-change

!

gprs charging profile 1

  limit volume 64000

  limit duration 64000

  content rulebase PREPAID

  content dcca profile 1

  content postpaid volume 64000

  content postpaid time 1200

  content postpaid qos-change

  content postpaid sgsn-change

!

!Congigures the quota server

!

ggsn quota-server qs

 interface Loopback2

 csg group csg_1

 !

!

!Configures a CSG2 group

!

ggsn csg-group csg_1

 virtual-address 10.10.65.10

 port 4386

 real-address 10.10.65.2

 !

tftp-server abcbar

!

radius-server host 10.10.65.100 auth-port 1812 acct-port 1813

radius-server host 10.20.154.201 auth-port 1812 acct-port 1813

radius-server key abc

radius-server vsa send accounting

radius-server vsa send accounting 3gpp2

!

!configures Diameter global parameters

!

diameter origin realm corporationA.com

diameter origin host sup-sami42.corporationA.com

diameter vendor supported cisco

!

!configures Diameter peer

!

diameter peer DCCA

 address ipv4 172.18.43.59

 transport tcp port 4100

 timer connection 20

 timer watchdog 25

 destination realm corporationA.com

!

!

...

!

end