> Configuring Enhanced Charging Services
> This chapter describes procedures to configure ECS functionality.
> The following procedures are covered in this chapter:

> l | Initial Configuration

> l | Configuring the Enhanced Charging Service

> l | Configuring Prepaid Credit Control Application (CCA)

> l | Configuring Redirection of Subscriber Traffic to ECS

> l | Configuring GTPP Accounting

> l | Configuring EDR/UDR Parameters

> l | Configuring x-header Insertion Feature

> l | Configuring Post Processing Feature

> l | Configuring Time-of-Day Activation/Deactivation of Rules Feature

> Initial Configuration
> To perform the initial configuration:

> 1 | Create the ECS administrative user account as described in the Creating the ECS Administrative User Account section.

> 2 | Install the ECS license as described in the Installing the ECS License section.

> 3 | Enable Active Charging as described in the Enabling Active Charging Service section.

> 4 | Save your configuration as described in the Saving Your Configuration chapter.

> IMPORTANT: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Creating the ECS Administrative User Account
> At least one administrative user account that has ECS functionality privileges must be configured on the system. This is the account that is used to log on and execute ECS-related commands. For security purposes, it is recommended that these user accounts be created along with general system functionality administration.
> Use the following configuration example to create the ECS Administrative user account:
> configure
> context local
> administrator <user_name> password <password> ecs
> end
> Notes:

> l | Aside from having ECS capabilities, an ECS Administrator account also has the same capabilities and privileges as any other system-level administrator account.

> l | You can also create system ECS user account for a config-administrator, operator, or inspector. ECS accounts have all the same system level privileges of normal system accounts except that they have full ECS command execution capability. For example, an ECS has rights to execute every command that a regular administrator can in addition to all of the ECS commands.

> l | Note that only Administrator and Config-administrator-level users can provision ECS functionality. Refer to the Configuring System Settings chapter of the System Administration and Configuration Guide for additional information on administrative user privileges.

> Installing the ECS License
> To configure and enable ECS functionality on your system you must obtain and install the [600-00-7526] Enhanced Charging Bundle 1 1k Sessions license.
> To configure and enable Diameter and DCCA functionality with ECS on your system, you must obtain and install the [600-00-7574] Enhanced Charging Bundle 2 1k Sessions license.
> For information on installing licenses, see the Managing License Keys section of the Software Management Operations chapter in the Administration and Configuration Guide.
> Enabling Active Charging Service
> Active Charging must be enabled before configuring charging services.
> Use the following configuration example to enable Active Charging Service:
> configure
> require active-charging
> context local
> interface <interface_name>
> ip address <ip_address/mask>
> exit
> server ftpd
> end
> Notes:

> l | If you are using the Category-based Content Filtering application, refer to the Content Filtering Services Administration Guide for specific configuration procedures.

> Configuring the Enhanced Charging Service
> A charging service has analyzers that define which packets to examine and ruledefs (ruledefs) that define what packet contents to take action on and what action to take when the ruledef is true. Charging services are configured at the global configuration level and are available to perform packet inspection on sessions in all contexts.
> To configure the Enhanced Charging Service:

> 1 | Create the Active Charging Service as described in the Creating the Active Charging Service section.

> 2 | Configure a routing ruledef as described in the Configuring Routing Rule Definitions section.

> 3 | Configure a charging ruledef as described in the Configuring Charging Rule Definitions section.

> 4 | Configure a post-processing ruledef as described in the Configuring Post-processing Rule Definitions section.

> 5 | Create a charging action as described in the Configuring Charging Actions section.

> 6 | Define a rulebase as described in the Configuring Rulebases section.

> 7 | Set EDR formats as described in the Setting EDR Formats section.

> 8 | Set UDR formats as described in the Setting UDR Formats section.

> 9 | Enable charging record retrieval as described in the Enabling Charging Record Retrieval section.

> 10 | Save your configuration as described in the Saving Your Configuration chapter.

> IMPORTANT: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Creating the Active Charging Service
> Use the following configuration example to create an Active Charging Service:
> configure
> active-charging service <service_name> [ -noconfirm ]
> end
> Configuring Rule Definitions
> A ruledef can be a charging or routing, or a post-processing rule. If the same ruledef is required to be a charging rule in one rulebase and a post-processing rule in another one, then two separate identical ruledefs will have to be defined.
> Configuring Charging Rule Definitions
> Use the following configuration example to create and configure a charging ruledef:
> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> <protocol> <expression> <operator> <condition>
> rule-application charging
> end
> Notes:

> l | For information on all the protocol types, expressions, operators, and conditions supported, refer to the Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging ruledef charging
> Configuring Routing Rule Definitions
> Use the following configuration example to create and configure a routing ruledef:
> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> <protocol> <expression> <operator> <condition>
> rule-application routing
> end
> Notes:

> l | The rule-application option specifies the ruledef type. By default, if not specified, the system configures the ruledef as a charging ruledef.

> l | For information on all the protocol types, expressions, operators, and conditions supported, refer to the Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.

> l | Up to 10 rule matches can be configured in one ruledef.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging ruledef routing
> Configuring Post-processing Rule Definitions
> Use the following configuration example to create and configure a post-processing ruledef:
> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> <protocol> <expression> <operator> <condition>
> rule-application post-processing
> end
> Notes:

> l | The rule-application option specifies the ruledef type. By default, if not specified, the system configures the ruledef as a charging ruledef.

> l | For information on all the protocol types, expressions, operators, and conditions supported, refer to the Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging ruledef post-processing
> Configuring Group of Ruledefs
> A group-of-ruledefs enables grouping rules into categories, so that charging systems can base the charging policy on the category.
> Use the following configuration example to create and configure a group-of-ruledefs:
> configure
> active-charging service <service_name>
> group-of-ruledefs <group_name> [ -noconfirm ]
> add-ruledef priority <priority> ruledef <ruledef_name>
> group-of-ruledefs-application { charging | post-processing }
> end
> Notes:

> l | A maximum of 128 ruledefs can be added to a group-of-ruledefs.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging group-of-ruledefs all
> Configuring Charging Actions
> Charging actions are used with rulebases and must be created before a rulebase is configured.
> Use the following configuration example to create a charging action:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name> [ -noconfirm ]
> content-id <content_id>
> retransmissions-counted
> billing-action [ edr <edr_format> [ wait-until-flow-ends ] | egcdr | exclude-from-udrs | radius ] +
> end
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging charging-action all
> Configuring IP Readdressing
> Readdressing of packets based on the destination IP address of the packets enables redirecting unknown gateway traffic to known/trusted gateways. This is implemented by configuring the re-address server in the charging action.
> To configure the IP Readdressing feature, use the following configuration example:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name>
> flow action readdress { server <ip_address> [ port <port_number> ] | port <port_number> }
> end
> Configuring Next Hop Address
> To configure the Next Hop Address configuration feature, use the following configuration example:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name>
> nexthop-forwarding-address <ip_address>
> end
> Configuring Rulebases
> A rulebase specifies which protocol analyzers to run and which packets are analyzed. Multiple rulebases may be defined for the Active Charging Service. A rulebase is basically a subscriber’s profile in a charging service.
> Use the following configuration example to define a rulebase:
> configure
> active-charging service <service_name>
> rulebase <rulebase_name> [ -noconfirm ]
> flow end-condition { { content-filtering | normal-end-signaling | timeout + } | { { hagr | handoff | session-end } [ flow-overflow ] + } [ url-blacklisting ] } edr <edr_format_name>
> billing-records udr udr-format <udr_format_name>
> action priority <action_priority> { [ dynamic-only | static-and-dynamic | timedef <timedef_name> ] { group-of-ruledefs <ruledefs_group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ monitoring-key <monitoring_key> ] [ description <description> ] }
> route priority <route_priority> ruledef <ruledef_name> analyzer <analyzer> [ description <description> ]
> rtp dynamic-flow-detection
> udr threshold interval <interval>
> cca radius charging context <context> group <group_name>
> cca radius accounting interval <interval>
> end
> Notes:

> l | When R7 Gx is enabled, “static-and-dynamic” rules behave exactly like “dynamic-only” rules. I.e. they must be activated explicitly by the PCRF. When Gx is not enabled, “static-and-dynamic” rules behave exactly like static rules.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging rulebase all
> Setting EDR Formats
> ECS generates postpaid charging data files which can be retrieved from the system periodically and used as input to a billing mediation system for postprocessing.
> EDRs are generated according to action statements in rule commands.
> Up to 32 different EDR schema types may be specified, each composed of up to 32 fields or analyzer parameter names. The records are written at the time of each rule event in a comma-separated (CSV) format.
> IMPORTANT: If you have configured RADIUS Prepaid Billing, configuring charging records is optional.
> Use the following configuration example to set the EDR formats:
> configure
> active-charging service <service_name>
> edr-format <edr_format_name> [ -noconfirm ]
> attribute <attribute> { [ format { MM/DD/YY-HH:MM:SS | MM/DD/YYYY-HH:MM:SS | YYYY/MM/DD-HH:MM:SS | YYYYMMDDHHMMSS | seconds } ] [ localtime ] | [ { ip | tcp } { bytes | pkts } { downlink | uplink } ] priority <priority> }
> rule-variable <protocol> <rule> priority <priority>
> event-label <event-label> priority <priority>
> end
> IMPORTANT: For information on EDR format configuration and rule variables, refer to the EDR Format Configuration Mode Commands chapter of the Command Line Interface Reference.
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging edr-format all
> Setting UDR Formats
> ECS generates postpaid charging data files which can be retrieved from the system periodically and used as input to a billing mediation system for postprocessing.
> UDRs are generated according to action statements in rule commands. Up to 32 different UDR schema types may be specified, each composed of up to 32 fields or analyzer parameter names. The records are written thresholds in a comma-separated (CSV) format.
> IMPORTANT: If you have configured RADIUS Prepaid Billing, configuring charging records is optional.
> Use the following configuration example to set the UDR format:
> configure
> active-charging service <service_name>
> udr-format <udr_format_name> [ -noconfirm ]
> attribute <attribute> { [ format { MM/DD/YY-HH:MM:SS | MM/DD/YYYY-HH:MM:SS | YYYY/MM/DD-HH:MM:SS | YYYYMMDDHHMMSS | seconds } ] [ localtime ] | [ { bytes | pkts } { downlink | uplink } ] ] priority <priority> }
> end
> IMPORTANT: For information on UDR format configuration and rule variables, refer to the UDR Format Configuration Mode Commands chapter of the Command Line Interface Reference.
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging udr-format all
> Enabling Charging Record Retrieval
> To retrieve charging records you must configure the context that stores the charging records to accept SFTP connections.
> Use the following configuration example to enable SFTP:
> configure
> context local
> administrator <user_name> [ encrypted ] password <password>
> config-administrator <user_name> [ encrypted ] password <password>
> exit
> context <context_name>
> ssh generate key
> server sshd
> subsystem sftp
> end
> Notes:

> l | You must specify the sftp keyword to enable the new account to SFTP into the context to retrieve record files.

> Optional Configurations
> This section describes the following optional configuration procedures:

> l | Configuring a Rulebase for a Subscriber

> l | Configuring a Rulebase within an APN

> l | Configuring Charging Rule Optimization

> IMPORTANT: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring a Rulebase for a Subscriber
> This section describes how to apply an existing rulebase to a subscriber. For information on how to configure rulebases, see the Configuring Rulebases section.
> Use the following configuration example to configure a rulebase for a subscriber:
> configure
> context <context_name>
> subscriber name <subscriber_name> [ -noconfirm ]
> active-charging rulebase <rulebase_name>
> end
> Save your configuration as described in the Saving Your Configuration chapter.
> Configuring a Rulebase within an APN
> IMPORTANT: This information is only applicable to GGSN networks.
> This section describes how to configure an existing rulebase within an APN for a GGSN. For information on how to configure rulebases, see the Configuring Rulebases section.
> Use the following configuration example to configure a rulebase within an APN:
> configure
> context <context_name>
> apn <apn_name> [ -noconfirm ]
> active-charging rulebase <rulebase_name>
> end
> Save your configuration as described in the Saving Your Configuration chapter.
> Configuring Charging Rule Optimization
> This section describes how to configure the internal optimization level for improved performance when the system evaluates each instance of the action CLI command.
> Use the following configuration example to configure the rule optimization level:
> configure
> active-charging service <service_name>
> rulebase <rulebase_name>
> charging-rule-optimization { high | low | medium }
> end
> Notes:

> l | Both the medium and high options causes reorganization of the entire memory structure whenever any change is made (for example, adding another action CLI command).

> l | high option causes allocation of a significant amount of memory for the most efficient organization.

> l | Save your configuration as described in the Saving Your Configuration chapter.

> Configuring Prepaid Credit Control Application (CCA)
> This section describes how to configure the Prepaid Credit Control Application for Diameter or RADIUS.
> IMPORTANT: To configure and enable Diameter and DCCA functionality with ECS on your system, you must obtain and install the [600-00-7574] Enhanced Charging Bundle 2 1k Sessions license.
> IMPORTANT: Before configuring Diameter or RADIUS CCA, you must configure AAA parameters as described in the AAA Interface Administration and Reference.
> To configure Prepaid Credit Control Application:

> 1 | Configure the Prepaid Credit Control Application for Diameter or RADIUS as described in the Configuring Prepaid CCA for Diameter or RADIUS section.

> 2 | Configure the required Prepaid Credit Control Mode:

> l | Configuring Diameter Prepaid Credit Control Application (DCCA)

> –or–

> l | Configuring RADIUS Prepaid Credit Control Application

> 3 | Save your configuration as described in the Saving Your Configuration chapter.

> IMPORTANT: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring Prepaid CCA for Diameter or RADIUS
> Use the following configuration example to configure the Prepaid Credit Control Application for Diameter or RADIUS:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name>
> cca charging credit [ preemptively-request | rating-group <coupon_id> ]
> exit
> credit-control [ group <group_name> ]
> mode { diameter | radius }
> quota time-threshold { <absolute_value> | percent <percent_value> }
> quota unit-threshold { <absolute_value> | percent <percent_value> }
> quota volume-threshold { <absolute_value> | percent <percent_value> }
> end
> Notes:

> l | <service_name> must be the name of the Active Charging Service in which you want to configure Prepaid Credit Control Application.

> l | <charging_action_name> must be the name of the charging action for which you want to configure Prepaid Credit Control Application.

> l | Option. To configure the redirection of URL for packets that match a ruledef and action on quota request timer, in the Charging Action Configuration mode, enter the following command. This command also specifies the redirect-URL action on packet and flow for Session Control functionality.

> flow action redirect-url <redirect_url> [ clear-quota-retry-timer ]
> The following sample shows the redirection of a URL for packets that match a ruledef.
> charging-action http-redirect
> content-id 3020
> retransmissions-counted
> billing-action exclude-from-udrs
> flow action redirect-url "http://10.1.67.214/cgi-bin/aoc.cgi\077 imsi=#bearer.calling-station-id#&url=#http.url#&acctsessid=#bearer.acct-session-id#&correlationid=#bearer.correlation-id#&username=#bearer.user-name#&ip=#bearer.served-bsa-addr#&subid=#bearer.subscriber-id#&host=#http.host#&httpuri=#http.uri#" clear-quota-retry-timer
> end

> l | Option. To configure credit control quota related parameters, use the following configuration example:

> configure
> active-charging service <service_name>
> rulebase <rulebase_name>
> cca quota { holding-time <holding_time> content-id <content_id> | retry-time <retry_time> [ max-retries <max_retries> ] }
> cca quota time-duration algorithm { consumed-time <consumed_time> [ plus-idle ] [ content-id <content_id> ] | continuous-time-periods <seconds> [ content-id <content_id> ] | parking-meter <seconds> [ content-id <content_id> ] }
> end
> <rulebase_name> must be the name of the rulebase in which you want to configure Prepaid Credit Control configurables.

> l | Option. To define credit control rules for quota state and URL redirect match rules with RADIUS AVP, use the following configuration example:

> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> cca quota-state <operator> { limit-reached | lower-bandwidth }
> cca redirect-indicator <operator> <indicator_value>
> end
> <ruledef_name> must be the name of the ruledef that you want to use for Prepaid Credit Control Application rules.
> cca redirect-indicator configuration is a RADIUS specific configuration.

> l | Option. This is a Diameter-specific configuration. To configure the failure handling options for credit control session, in the Credit Control Configuration Mode, use the following configuration:

> configure
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> failure-handling { ccfh-session-timeout <session_timeout> | { initial-request | terminate-request | update-request } { continue [ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate [ retry-after-tx-expiry ] | terminate }
> end

> l | Option. To configure the triggering option for credit reauthorization when the named values in the subscriber session changes, in the Credit Control Configuration Mode, enter the following command:

> configure
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> trigger type { cellid | lac | qos | rat | sgsn }+
> end

> l | Option: This is a Diameter specific configuration. If the configuration is for 3GPP network, to configure the virtual or real APN name to be sent in Credit Control Application (CCA) message, in the Credit Control Configuration Mode, enter the following command:

> configure
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> apn-name-to-be-included { gn | virtual }
> end
> Configuring Diameter Prepaid Credit Control Application (DCCA)
> This section describes how to configure the Diameter Prepaid Credit Control Application.
> IMPORTANT: To configure and enable Diameter and DCCA functionality with ECS on your system, you must obtain and install the [600-00-7574] Enhanced Charging Bundle 2 1k Sessions license.
> Use the following configuration example to configure Diameter Prepaid Credit Control Application.
> IMPORTANT: It is assumed that you have already fully configured the AAA parameters as described in the AAA Interface Administration and Reference, and Credit Control Application as described in Configuring Prepaid Credit Control Application (CCA) section for Diameter mode.
> configure
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> mode diameter
> diameter origin endpoint <endpoint_name>
> diameter dictionary <dcca_dictionary>
> diameter peer-select peer <peer_name> [ realm <realm_name> ] [ secondary-peer <sec_peer_name> [ realm <realm_name> ] ] [ imsi-based { [ prefix | suffix ] <imsi/prefix/suffix_start_value> } [ to <imsi/prefix/suffix_end_value> ] ]
> end
> Notes:

> l | Diameter peer configuration set with the diameter peer-select command can be overridden by the dcca peer-select peer command in the APN Configuration mode for 3GPP service networks, and in Subscriber Configuration mode in other service networks.

> l | The specific Credit Control Group to be used for subscribers must be configured in the APN Configuration Mode using the credit-control-group <cc_group_name> command.

> l | Option. To configure the maximum time, in seconds, to wait for a response from Diameter peer, in the Credit Control Configuration Mode, enter the following command:

> diameter pending-timeout <duration>

> l | Option. To configure Diameter Credit Control Session Failover, in the Credit Control Configuration Mode, enter the following command:

> diameter session failover
> When enabled, in the event of failure, failure handling action is based on the failure-handling CLI.

> l | Option. If you want to configure the service for IMS authorization in 3GPP service network, you can configure dynamic rule matching with Gx interface and dynamic rule matching order in rulebase, use the following configuration example:

> configure
> active-charging service <service_name>
> rulebase <rulebase_name>
> dynamic-rule order { always-first | first-if-tied }
> action priority <action_priority> { [ dynamic-only | static-and-dynamic | timedef <timedef_name> ] { group-of-ruledefs <ruledefs_group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ monitoring-key <monitoring_key> ] [ description <description> ] }
> end

> l | Option. To configure Diameter group AVP Requested-Service-Unit for Gy interface support to include a sub-AVP in CCRs using volume, time, and unit specific charging, in the Rulebase Configuration Mode, enter the following command:

> cca diameter requested-service-unit sub-avp { time cc-time <duration> | units cc-service-specific-units <charging_unit> | volume { cc-input-octets <bytes> | cc-output-octets <bytes> | cc-total-octets <bytes> } + }

> l | If the Diameter endpoint parameters are not yet configured, see the Configuring Diameter Endpoint section in the AAA Interface Administration and Reference for information on how to configure them.

> Configuring Peer-Select in Subscriber Configuration Mode (Optional)
> This section describes how to configure Diameter peer-select within a subscriber configuration.
> IMPORTANT: The dcca peer-select configuration completely overrides all instances of diameter peer-select configured within the Credit Control Configuration Mode for an Active Charging service.
> Use the following configuration example to configure DCCA peers within a subscriber configuration:
> configure
> context <context_name>
> subscriber name <subscriber_name>
> dcca peer-select peer <host_name> [ [ realm <realm_name> ] [ secondary-peer <host_name> [ realm <realm_name> ] ] ]
> end
> Configuring Peer-Select in APN Configuration Mode (Optional)
> IMPORTANT: This information is only applicable to GGSN networks.
> This section describes how to configure Diameter peer-select within an APN configuration.
> IMPORTANT: The dcca peer-select configuration completely overrides all instances of diameter peer-select configured within the Credit Control Configuration Mode for an Active Charging service.
> Use the following configuration example to configure DCCA peers within an APN:
> configure
> context <context_name>
> apn <apn_name>
> dcca peer-select peer <host_name> [ [ realm <realm_name> ] [ secondary-peer <host_name> [ realm <realm_name> ] ] ]
> end
> Configuring RADIUS Prepaid Credit Control Application
> RADIUS prepaid billing operates on a per content-type basis. Individual content-types are marked for prepaid treatment. When a traffic analysis rule marked with prepaid content-types matches, it triggers prepaid charge management.
> IMPORTANT: The RADIUS Prepaid feature of ECS has no connection to the system-level Prepaid Billing Support or the 3GPP2 Prepaid features that are enabled under different licenses.
> Use the following configuration example to configure RADIUS Prepaid Charging with Enhanced Charging feature.
> IMPORTANT: It is assumed that you have already fully configured the AAA parameters as described in the AAA Interface Administration and Reference, and Credit Control Application as described in Configuring Prepaid Credit Control Application (CCA) section for RADIUS mode.
> configure
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> mode radius
> exit
> rulebase <rulebase_name>
> cca radius charging context <vpn_context> [ group <group_name> ]
> end
> Notes:

> l | <rulebase_name> must be the name of the rulebase in which you want to configure Prepaid Credit Control configurables.

> l | <vpn_context> must be the charging context in which the RADIUS parameters are configured:

> l | Option. To specify the accounting interval duration for RADIUS prepaid accounting, in the Rulebase Configuration Mode, enter the following command:

> cca radius accounting interval <interval>

> l | Option. To specify the user password for RADIUS prepaid services, in the Rulebase Configuration Mode, enter the following command:

> cca radius user-password [ encrypted ] password <password>

> l | If RADIUS server parameters are not yet configured, configure them as described in the Configuring AAA Functionality section of the AAA Interface Administration and Reference.

> Configuring Gy Interface
> IMPORTANT: This feature is only available in GGSN/UMTS networks.
> Use the following configuration example to configure the standard Gy interface:
> configure
> context <context_name>
> diameter endpoint <endpoint_name>
> origin realm <realm>
> origin host <diameter_host> address <ip_address>
> peer <peer> realm <realm> address <ip_address>
> exit
> exit
> active-charging service <service_name>
> credit-control [ group <group_name> ]
> diameter origin endpoint <endpoint_name>
> diameter peer-select peer <peer> realm <realm>
> diameter pending-timeout <timeout>
> diameter session failover
> trigger type cellid
> diameter dictionary <dictionary>
> failure-handling ccfh-session-timeout <session_timeout>
> failure-handling initial-request continue go-offline-after-tx-expiry
> failure-handling update-request continue
> failure-handling terminate-request continue
> exit
> exit
> context <context_name>
> apn <apn_name>
> selection-mode sent-by-ms
> ims-auth-service <service>
> ip access-group <access_list> in
> ip access-group <access_list> out
> ip context-name <context_name>
> active-charging rulebase <rulebase_name>
> end
> Configuring Redirection of Subscriber Traffic to ECS
> User traffic is directed through the ECS service inspection engine by using Access Control List (ACL) mechanism to selectively steer subscriber traffic.
> To configure redirection of subscriber traffic to ECS:

> 1 | Create an ECS ACL as described in the Creating an ECS ACL section.

> 2 | Apply an ACL to an individual subscriber as described in the Applying an ACL to an Individual Subscriber section.

> 3 | Apply an ACL to the subscriber named default as described in the Applying an ACL to the Subscriber Named default section.

> 4 | Apply the ACL to an APN as described in the Applying the ACL to an APN section.

> 5 | Save your configuration as described in the Saving Your Configuration chapter.

> IMPORTANT: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Creating an ECS ACL
> Use the following configuration example to create an ACL to use in steering subscriber traffic through ECS:
> configure
> context <context_name>
> ip access-list <access_list_name>
> redirect css service <service_name> <keywords> <options>
> end
> Notes:

> l | <service_name> must be the ACS service name; no CSS service needs to be configured.

> Applying an ACL to an Individual Subscriber
> IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.
> To apply an ACL to a RADIUS-based subscriber, use the Filter-Id attribute. For more information on this attribute, refer to the AAA Interface Administration and Reference.
> Use the following configuration example to apply an ACL to an individual subscriber:
> configure
> context <context_name>
> subscriber name <subscriber_name>
> ip access-group <acl_name> [ in | out ]
> end
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following commands:
> context <context_name>
> show subscribers configuration username <subscriber_name>
> Applying an ACL to the Subscriber Named default
> Use the following configuration example to apply an ACL to the default subscriber:
> configure
> context <context_name>
> subscriber default
> ip access-group <acl_name> [ in | out ]
> end
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following commands:
> context <context_name>
> show subscribers configuration username default
> Applying the ACL to an APN
> IMPORTANT: This information is only applicable to GGSN networks.
> Use the following configuration example to apply an ACL to an APN:
> configure
> context <context_name>
> apn <apn_name>
> ip access-group <acl_name> [ in | out ]
> end
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following commands:
> context <context_name>
> show apn name <apn_name>
> Configuring GTPP Accounting
> IMPORTANT: This section assumes that you have already fully configured a GGSN service.
> This section describes how to configure GTPP accounting which generates G-CDRs for ECS. Generated G-CDRs are sent to a configured Charging Gateway Function (CGF). ECS G-CDRs are sent in ASN.1 format and are encoded as described in 3GPP TS 32.015 V3.9.0 (2002–03) and 3GPP TS 29.060 V6.7.0 (2004–12).
> The GGSN service should be configured in the source context.
> IMPORTANT: If you have configured RADIUS accounting you do not need to configure GTPP accounting.
> Use the following configuration example to configure GTPP accounting:
> configure
> gtpp single-source
> context <context_name>
> apn <apn_name>
> accounting-mode none
> exit
> gtpp charging-agent address <ip_address>
> gtpp server <ip_address>
> end
> Notes:

> l | The gtpp single-source command must be entered before any other configuration commands. If you add it to an existing configuration, make sure that it is the first command implemented after cards and ports are configured. This ensures that this command is implemented before any AAA Manager or Session Manager processes are started.

> l | The GGSN has a concept of an accounting context. By default the accounting context is the context in which the GGSN service is configured. Make sure that you configure the GTPP charging agent and the GTPP accounting servers.

> Save your configuration as described in the Saving Your Configuration chapter.
> Configuring EDR/UDR Parameters
> This section provides an example configuration to configure EDR/UDR file transfer and file properties parameters, including configuring hard disk support on SMC card on ST40 platform, transfer modes, transfer interval, etc.
> To configure EDR/UDR file parameters:
> configure
> context <context_name>
> edr-module active-charging-service
> cdr [ [ push-interval <interval> ] [ push-trigger space-usage-percent <trigger_percentage> ] [ remove-file-after-transfer ] [ transfer-mode { pull | push primary { encrypted-url <encrypted_url> | url <url> } [ secondary { encrypted-secondary-url <encrypted_secondry_url> | url <secondary_url> } ] } ] [ via local-context ] + | use-harddisk ]
> file [ charging-service-name { include | omit } ] [ compression { gzip | none } ] [ current-prefix <string> ] [ delete-timeout <seconds> ] [ directory <directory_name> ] [ edr-format-name ] [ exclude-checksum-record ] [ field-separator { hyphen | omit | underscore } ] [ file-sequence-number rulebase-seq-num ] [ headers ] [ name <file_name> ] [ reset-indicator ] [ rotation [ num-records <number> | time <seconds> | volume <bytes> ] ] [ sequence-number { omit | padded | padded-six-length | unpadded } ] [ storage-limit <limit> ] [ time-stamp { expanded-format | rotated-format | unix-format } ] [ trailing-text <string> ] [ trap-on-file-delete ] [ xor-final-record ] +
> exit
> udr-module active-charging-service
> file [ charging-service-name { include | omit } ] [ compression { gzip | none } ] [ current-prefix <string> ] [ delete-timeout <seconds> ] [ directory <directory_name> ] [ exclude-checksum-record ] [ field-separator { hyphen | omit | underscore } ] [ file-sequence-number rulebase-seq-num ] [ headers ] [ name <file_name> ] [ reset-indicator ] [ rotation [ num-records <number> | time <seconds> | volume <bytes> ] ] [ sequence-number { omit | padded | padded-six-length | unpadded } ] [ storage-limit <limit> ] [ time-stamp { expanded-format | rotated-format | unix-format } ] [ trailing-text <string> ] [ trap-on-file-delete ] [ udr-seq-num ] [ xor-final-record ] +
> end
> Notes:

> l | The cdr command keywords can be configured either in the EDR or the UDR Configuration Mode. Configuring in one mode prevents the configurations from being applied in the other mode.

> l | The use-harddisk keyword is only available on the ST40 platform.

> l | For the storage-limit <limit> keyword, on the ST16 platform, the total storage limit is 256 MB (268435456 bytes). And, on ST40 platform, the total storage limit is 512 MB (536870912 bytes). This limit is for both UDR and EDR files combined.

> Verifying your Configurations
> To view EDR-UDR file statistics, in the Exec Mode, enter the following command:
> show active-charging edr-udr-file statistics
> Pushing EDR/UDR Files Manually
> Use the following command to manually push EDR/UDR files to the configured L-ESS:
> cdr-push { all | local-filename <file_name> }
> Notes:

> l | Before you can use this command, the CDR transfer mode and file locations must be set to push in the EDR/UDR Module Configuration Mode.

> l | The cdr-push command is available in the Exec Mode.

> l | <file_name> must be absolute path of the local file to push.

> Retrieving EDR and UDR Files
> To retrieve UDR or EDR files you must SFTP into the context that was configured for EDR or UDR file generation with the FTP enabled account that you configured in the Enabling Charging Record Retrieval section.
> The following commands use SFTP to log on to a context named ECP as a user named ecpadmin, through an interface configured in the ECS context that has the IP address 192.168.1.10 and retrieve all EDR or UDR files from the default locations:
> sftp -oUser=ecpadmin@ECP 192.168.1.10:/records/edr/*
> sftp -oUser=ecpadmin@ECP 192.168.1.10:/records/udr/*
> Configuring x-header Insertion Feature
> IMPORTANT: This is a customer-specific feature. Please contact your sales representative for more information.
> This section describes how to configure the x-header Insertion feature.
> To configure the x-header Insertion feature:

> 1 | Create/configure a ruledef to identify the HTTP packets in which the x-headers must be inserted. For information on how to create/configure ruledefs, see the Configuring Charging Rule Definitions section.

> 2 | Create/configure a rulebase and configure the charging-action, which will insert the x-header fields into the HTTP packets. For information on how to create/configure rulebases, see the Configuring Rulebases section.

> 3 | Create the x-header format as described in the Creating the x-header Format section.

> 4 | Configure the x-header format as described in the Configuring the x-header Format section.

> 5 | Configure insertion of the x-header fields as described in the Configuring Charging Action for Insertion of x-header Fields section.

> 6 | Save your configuration as described in the Saving Your Configuration chapter.

> Creating the x-header Format
> Use the following configuration example to create an x-header format:
> configure
> active-charging service <acs_service>
> xheader-format <xheader_format_name> [ -noconfirm ]
> end
> Configuring the x-header Format
> Use the following configuration example to configure an x-header format:
> configure
> active-charging service <acs_service>
> xheader-format <xheader_format_name> [ -noconfirm ]
> insert <xheader_field_name> { string-constant <xheader_field_value> | variable { bearer { 3gpp charging-id | ggsn-address | imsi | radius-calling-station-id | sgsn-address | sn-rulebase | subscriber-ip-address } | http { host | url } }
> end
> Configuring Charging Action for Insertion of x-header Fields
> Use the following configuration example to configure a charging action for insertion of x-header fields:
> configure
> active-charging service <acs_service>
> charging-action <charging_action_name> [ -noconfirm ]
> xheader-insert xheader-format <xheader_format_name> [-noconfirm]
> end
> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging xheader-format all
> Configuring Post Processing Feature
> This section describes how to configure the Post-processing feature to enable processing of packets even if rule matching for them has been disabled.
> Use the following configuration example to configure the Post-processing feature:
> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> <protocol> <expression> <operator> <condition>
> rule-application post-processing
> exit
> charging-action <charging_action_name>
> ...
> exit
> rulebase <rulebase_name>
> action priority <action_priority> { [ dynamic-only | static-and-dynamic | timedef <timedef_name> ] { group-of-ruledefs <ruledefs_group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ monitoring-key <monitoring_key> ] [ description <description> ] }
> post-processing priority <priority> ruledef <ruledef_name> charging-action <charging_action_name>
> ...
> end
> Notes:

> l | In the Rulebase Configuration Mode, the ruledef configured for post-processing action must have been configured for post processing in the Ruledef Configuration mode.

> l | If the same ruledef is required to be a charging rule in one rulebase and a post-processing rule in another one, then two separate identical ruledefs will have to be defined.

> l | Save your configuration as described in the Saving Your Configuration chapter.

> l | In this release, post processing with group-of-ruledefs is not supported.

> l | In this release, delay charging with dynamic rules is not supported, hence there cannot be dynamic post-processing rules.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following commands:
> To view post-processing ruledef configuration:
> show active-charging ruledef post-processing
> To view post-processing ruledef statistics:
> show active-charging ruledef statistics all post-processing
> Configuring Time-of-Day Activation/Deactivation of Rules Feature
> This section describes how to configure the Time-of-Day Activation/Deactivation of Rules feature to enable charging according to day/time.
> Use the following configuration example to configure the Time-of-Day Activation/Deactivation of Rules feature:
> configure
> active-charging service <service_name>
> ruledef <ruledef_name>
> ...
> exit
> timedef <timedef_name> [ -noconfirm ]
> start day { friday | monday | saturday | sunday | thursday | tuesday | wednesday } time <hh> <mm> <ss> end day { friday | monday | saturday | sunday | thursday | tuesday | wednesday } time <hh> <mm> <ss>
> start time <hh> <mm> <ss> end time <hh> <mm> <ss>
> exit
> charging-action <charging_action_name>
> ...
> exit
> rulebase <rulebase_name>
> action priority <action_priority> timedef <timedef_name> { group-of-ruledefs <group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ description <description> ]
> ...
> end
> Notes:

> l | If, in a timeslot, only the time is specified, that timeslot will be applicable for all days.

> l | If for a timeslot, “start time” > “end time”, that rule will span the midnight. I.e. that rule is considered to be active from the current day till the next day.

> l | If for a timeslot, “start day” > “end day”, that rule will span over the current week till the end day in the next week.

> l | In the following cases a rule will be active all the time: - a timedef is not configured in an action priority - a timedef is configured in an action priority, but the named timedef is not defined - a timedef is defined but with no timeslots

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging timedef all
> Configuring URL Filtering Feature
> This section describes how to configure the URL Filtering feature to simplify rules for URL detection.
> Use the following configuration example to configure the URL Filtering feature:
> To create a group-of-prefixed-URLs:
> configure
> active-charging service <service_name>
> group-of-prefixed-urls <group_name> [ -noconfirm ]
> end
> To configure the URLs to be filtered in the group-of-prefixed-URLs:
> configure
> active-charging service <service_name>
> group-of-prefixed-urls <group_name>
> prefixed-url <url_1>
> ...
> prefixed-url <url_10>
> end
> To enable or disable the group in the rulebase for processing prefixed URLs:
> configure
> active-charging service <service_name>
> rulebase <rulebase_name>
> url-preprocessing bypass group-of-prefixed-urls <group_name>
> ...
> url-preprocessing bypass group-of-prefixed-urls <group_name_n>
> end
> Notes:

> l | A maximum of 64 group-of-prefixed-urls can be created and configured.

> l | A maximum of 10 prefixed URLs can be configured in a group-of-prefixed-urls.

> l | In a rulebase, multiple group-of-prefixed-urls can be configured to be filtered.

> Verifying your Configuration
> To verify your configuration, in the Exec Mode, enter the following command:
> show active-charging group-of-prefixed-urls { all | name <group_name> } [ service name <acs_service> ] [ | { grep <grep_options> | more } ]

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