# Enhanced Charging Service Configuration

This chapter describes how to configure the Enhanced Charging Service (ECS) functionality, also known as Active Charging Service (ACS).

The following topics are covered in this chapter:

- Initial Configuration
- Configuring the Enhanced Charging Service
- Configuring Enhanced Features

## Initial Configuration

Initial configuration includes the following:

1. Install the ECS license as described in the Installing the ECS License section.
2. Create the ECS administrative user account as described in the Creating the ECS Administrative User Account section.
3. Enable ECS as described in the Enabling Active Charging Service section.
4. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

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

To create the ECS administrative user account, use the following configuration:

    configure

      context
    local

         administrator <user_name> password <password> ecs

         end

Notes:

- Aside from having ECS capabilities, an ECS Administrator account also has the same capabilities and privileges as any other system-level administrator account.
- You can also create system ECS user account for a config-administrator, operator, or inspector. ECS accounts have the same system-level privileges of normal system accounts except that they have full ECS command execution capability. For example, an ECS account has rights to execute every command that a regular administrator can in addition to all of the ECS commands.
- 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

The ECS in-line service is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on licensing requirements.

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

Enabling Enhanced Charging Service

Enhanced charging must be enabled before configuring charging services.

To enable Enhanced Charging Service, use the following configuration:

    configure

       require
    active-charging

          context local

             interface <interface_name>

                ip
    address <ip_address/mask>

                exit

             server ftpd

             end

Notes:

- The require active-charging command must be configured before any services are configured, so that the resource subsystem can appropriately reserve adequate memory for ECS-related tasks. After configuring this command, the configuration must be saved and the system rebooted in order to allocate the resources for ECS on system startup.

## 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 matched. 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 ECS service as described in the Creating the Active Charging Service section.
2. Configure a ruledef as described in the Configuring Rule Definitions section.
3. Create a charging action as described in the Configuring Charging Actions section.
4. Define a rulebase as described in the Configuring Rulebase section.
5. Optional. Define a rulebase list in the ACS configuration mode and configure the rulebase list in an APN, as described in the Configuring Rulebase Lists section.
6. Set EDR formats as described in the Setting EDR Formats section.
7. Set UDR formats as described in the Setting UDR Formats section.
8. Enable charging record retrieval as described in the Enabling Charging Record Retrieval section.
9. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

   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 Enhanced Charging Service

To create an Enhanced Charging Service, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

       end

Notes:

- In this release, only one ECS service can be created in a system.

Configuring Rule Definitions

This section describes how to create and configure rule definitions.

To create and configure a ruledef use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          ruledef <ruledef_name>

             <protocol> <expression>
    <operator> <condition>

             rule-application { charging | post-processing | routing | tpo }

             end

Notes:

- If the same ruledef is to be used for charging in one rulebase and for post-processing in another, then two separate identical ruledefs should be defined.
- For information on all the protocol types, expressions, operators, and conditions supported, refer to the ACS Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.
- The rule-application command specifies the ruledef type. By default, if not specified, the system considers a ruledef as a charging ruledef.
- TPO ruledefs are used for Traffic Performance Optimization (TPO) in-line service match-rule and match-advertisement features. For more information on TPO, refer to the Traffic Performance Optimization Administration Guide.
- 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 { all | charging | name ruledef_name | post-processing | routing | tpo }

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.

To create and configure a group-of-ruledefs, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          group-of-ruledefs <ruledef_group_name>

             add-ruledef
    priority <priority> ruledef <ruledef_name>

             group-of-ruledefs-application { charging | content-filtering | gx-alias | post-processing | tpo }

             end

Notes:

- A maximum of 128 ruledefs can be added to a group-of-ruledefs.
- The group-of-ruledefs-application command specifies the group-of-ruledef type. By default, if not specified, the system considers a group-of-ruledef as a charging group-of-ruledef.
- TPO group-of-ruledefs are used for Traffic Performance Optimization (TPO) in-line service match-rule and match-advertisement features. For more information on TPO, refer to the Traffic Performance Optimization Administration Guide.

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging group-of-ruledefs name <ruledef_group_name>

Configuring Charging Actions

Charging actions are used with rulebases and must be created before a rulebase is configured.

To create a charging action, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          charging-action <charging_action_name>

             content-id <content_id>

             retransmissions-counted

             billing-action { create-edrs { charging-edr <charging_edr_format_name> | reporting-edr <reporting_edr_format_name> } + [ wait-until-flow-ends ] | egcdr | exclude-from-udrs | radius | rf } +

             end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging charging-action name <charging_action_name>

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:

    configure

       active-charging
    service <ecs_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:

    configure

       active-charging
    service <ecs_service_name>

          charging-action <charging_action_name>

             nexthop-forwarding-address <ip_address>

             end

Configuring Rulebase

A rulebase specifies which protocol analyzers to run and which packets are analyzed. Multiple rulebases may be defined for the Enhanced Charging Service. A rulebase is basically a subscriber’s profile in a charging service.

To create and configure a rulebase, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          rulebase <rulebase_name>

             flow
    end-condition { content-filtering | hagr | handoff | normal-end-signaling | session-end | url-blacklisting | timeout } [ flow-overflow ] + { charging-edr <charging_edr_format_name> | reporting-edr <reporting_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 <ruledef_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:

- 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 name <rulebase_name>

Configuring Rulebase Lists

To create a rulebase list, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          rulebase-list <rulebase_list_name>
    <rulebase_name> [ <rulebase_name> + ]

          exit

Configuring a Rulebase List in an APN

To configure the rulebase list that was created in the ACS configuration mode in an APN, use the following configuration:

    configure

       context <context_name>

          apn <apn_name>

             active-charging
    rulebase-list <rulebase_list_name>

             exit

Verifying your configuration

To verify your configuration for the rulebase list and APN, in the Exec mode, enter the following command:

show configuration

To verify your APN configuration, in the Exec mode, enter the following command:

show configuration apn <apn_name>

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.

To set the EDR formats use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          edr-format <edr_format_name>

             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 name <edr_format_name>

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.

To set the UDR format, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          udr-format <udr_format_name>

             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 name <udr_format_name>

Enabling Charging Record Retrieval

To retrieve charging records you must configure the context that stores the charging records to accept SFTP connections.

To enable SFTP, use the following configuration:

    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:

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

- Configuring a Rulebase for a Subscriber
- Configuring a Rulebase within an APN
- 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.

To configure a rulebase for a subscriber, use the following configuration:

    configure

       context <context_name>

          subscriber
    name <subscriber_name>

             active-charging
    rulebase <rulebase_name>

             end

Configuring a Rulebase in an APN

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.

IMPORTANT:

This information is only applicable to GGSN networks.

To configure a rulebase in an APN, use the following configuration:

    configure

       context <context_name>

          apn <apn_name>

             active-charging
    rulebase <rulebase_name>

             end

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.

To configure the rule optimization level, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          rulebase <rulebase_name>

             charging-rule-optimization { high | low | medium }

             end

Notes:

- In StarOS 14.0 and later releases, the charging-rule-optimization command is deprecated. Rule optimization is always enabled with the optimization level set to high as standard behavior.
- In 11.0 and later releases, the medium option is deprecated.
- Both the high and medium options cause reorganization of the entire memory structure whenever any change is made (for example, addition of another action CLI command).
- The high option causes allocation of a significant amount of memory for the most efficient organization.

Configuring Enhanced Features

The configuration examples in this section are optional and provided to cover the most common uses of ECS in a live network.

The following topics are covered in this section:

- Configuring Prepaid Credit Control Application (CCA)
- Configuring Redirection of Subscriber Traffic to ECS
- Configuring GTPP Accounting
- Configuring DNS Snooping Feature
- Configuring EDRUDR Parameters
- Configuring Fair Usage Feature
- Configuring Post Processing Feature
- Configuring TCP Proxy
- Configuring Tethering Detection Feature
- Configuring Time-of-Day ActivationDeactivation of Rules Feature
- Configuring URL Filtering Feature
- Configuring x-header Insertion Feature

### 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, you must obtain and install the relevant license on the chassis. Contact your Cisco account representative for detailed information on licensing requirements.

IMPORTANT:

Before configuring Diameter or RADIUS CCA, you must configure AAA parameters. For more information , if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to 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:
   - Configuring Diameter Prepaid Credit Control Application (DCCA)
   - Configuring RADIUS Prepaid Credit Control Application

   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

To configure the Prepaid Credit Control Application for Diameter or RADIUS, use the following configuration:

    configure

       active-charging
    service <ecs_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:

- <ecs_service_name> must be the name of the Enhanced Charging Service in which you want to configure Prepaid Credit Control Application.
- <charging_action_name> must be the name of the charging action for which you want to configure Prepaid Credit Control Application.
- Optional: 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.In 12.2 and later releases: flow action redirect-url <redirect_url> [ [ encryption { blowfish128 | blowfish64 } [ encrypted ] key <key> ] [ clear-quota-retry-timer ]In 12.1 and earlier releases: flow action redirect-url <redirect_url> [ clear-quota-retry-timer ]The following example 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

- Optional: To configure credit control quota related parameters, use the following configuration:configure active-charging service <ecs_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.

- Optional: To define credit control rules for quota state and URL redirect match rules with RADIUS AVP, use the following configuration:configure active-charging service <ecs_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.

- Optional: 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 <ecs_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
- Optional: To configure the triggering option for credit reauthorization when the named values in the subscriber session changes, use the following configuration:configure active-charging service <ecs_service_name> credit-control [ group <group_name> ] trigger type { cellid | lac | qos | rat | sgsn } + end

- Optional: 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, use the following configuration:configure active-charging service <ecs_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, you must obtain and install the relevant license on the chassis. Contact your Cisco account representative for detailed information on licensing requirements.

IMPORTANT:

It is assumed that you have already fully configured the AAA parameters, and Credit Control Application as described in Configuring Prepaid Credit Control Application (CCA) section for Diameter mode. For information on configuring AAA parameters, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

To configure Diameter Prepaid Credit Control Application, use the following configuration.

    configure

       active-charging
    service <ecs_service_name>

          credit-control [ group <cc_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:

- 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.
- 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.
- Optional: 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>
- Optional: To configure Diameter Credit Control Session Failover, in the Credit Control Configuration Mode, enter the following command:diameter session failoverWhen enabled, in the event of failure, failure handling action is based on the failure-handling CLI.
- Optional: 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:configure active-charging service <ecs_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 <ruledef_group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ monitoring-key <monitoring_key> ] [ description <description> ] } end

- Optional: 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> } + }
- Ensure the Diameter endpoint parameters are configured. For information on configuring Diameter endpoint, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

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 Enhanced Charging Service.

To configure DCCA peers within a subscriber configuration, use the following 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)

This section describes how to configure Diameter peer-select within an APN configuration.

IMPORTANT:

This information is only applicable to GGSN networks.

IMPORTANT:

The dcca peer-select configuration completely overrides all instances of diameter peer-select configured within the Credit Control Configuration Mode for an Enhanced Charging Service.

To configure DCCA peers within an APN, use the following configuration:

    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.

IMPORTANT:

It is assumed that you have already fully configured the AAA parameters, and Credit Control Application as described in Configuring Prepaid Credit Control Application (CCA) section for RADIUS mode. For information on configuring AAA parameters, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

To configure RADIUS Prepaid Charging with Enhanced Charging, use the following configuration.

    configure

       active-charging
    service <ecs_service_name>

          credit-control [ group <group_name> ]

             mode radius

             exit

          rulebase <rulebase_name>

             cca
    radius charging context <vpn_context> [ group <group_name> ]

             end

Notes:

- <rulebase_name> must be the name of the rulebase in which you want to configure Prepaid Credit Control configurables.
- <vpn_context> must be the charging context in which the RADIUS parameters are configured:
- Optional: To specify the accounting interval duration for RADIUS prepaid accounting, in the Rulebase Configuration Mode, enter the following command:cca radius accounting interval <interval>
- Optional: 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>
- Ensure the RADIUS server parameters are configured. For more information , if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

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

   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

To create an ACL to use in steering subscriber traffic through ECS, use the following configuration:

    configure

       context <context_name>

          ip
    access-list <access_list_name>

             redirect
    css service <ecs_service_name>
    <keywords> <options>

             end

Notes:

- <ecs_service_name> must be the enhanced charging service’s 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, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

To apply an ACL to an individual subscriber, use the following configuration:

    configure

       context <context_name>

          subscriber
    name <subscriber_name>

             ip
    access-group <acl_name> [ in | out ]

             end

Applying an ACL to the Subscriber Named default

To apply an ACL to the default subscriber, use the following configuration:

    configure

       context <context_name>

          subscriber default

             ip
    access-group <acl_name> [ in | out ]

             end

Applying the ACL to an APN

To apply an ACL to an APN, use the following configuration:

IMPORTANT:

This information is only applicable to UMTS networks.

    configure

       context <context_name>

          apn <apn_name>

             ip
    access-group <acl_name> [ in | out ]

             end

Configuring GTPP Accounting

For information on configuring GTPP accounting, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

Configuring DNS Snooping Feature

This section describes how to configure the DNS Snooping feature.

To configure the DNS Snooping feature use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          ip
    dns-learnt-entries timeout <timeout_period>

          ruledef <ruledef_name>

             ip
    server-domain-name { = | contains | ends-with | starts-with }<domain_name/domain_name_segment>

             ...

             exit

          rulebase <rulebase_name>

             action
    priority <priority> ruledef <ruledef_name> charging-action <charging_action_name>

             ...

             end

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 ASR 5000, transfer modes, transfer interval, etc.

To configure EDR/UDR file parameters:

    configure

       context <context_name>

          edr-module
    active-charging-service  [ charging | reporting ]

    cdr { purge { storage-limit <storage_limit> | time-limit <time_limit> } [ max-files <max_records_to_purge> ] | push-interval <push_interval> | push-trigger space-usage-percent <trigger_percentage> | remove-file-after-transfer | transfer-mode { pull [ module-only ] | push primary { encrypted-url <encrypted_url> | url <url> } [ [ max-files <max_records> ] [ module-only ] [ secondary { encrypted-secondary-url <encrypted_secondary_url> | secondary-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 { length <length> | omit | padded | padded-six-length | unpadded } ] [ storage-limit <limit> ] [ single-edr-format ] [ 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 { length <length> | 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:

- 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.
- If the edr-module active-charging-service command is configured without the charging or reporting keywords, by default the EDR module is enabled for charging EDRs.
- When the configured threshold limit is reached on the hard disk drive, the records that are created dynamically in the /mnt/hd-raid/data/records/ directory are automatically deleted. Files that are manually created should be deleted manually.
- The use-harddisk keyword is only available on the ASR 5000.

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

To manually push EDR/UDR files to the configured L-ESS, in the Exec mode, use the following command:

cdr-push { all | local-filename <file_name> }

Notes:

- 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.
- The cdr-push command is available in the Exec Mode.
- <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.

This was done 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 Fair Usage Feature

This section describes how to configure the Fair Usage feature to perform instance level load balancing and subscriber resource usage control.

To configure the Fair Usage feature, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          fair-usage

          fair-usage
    threshold-percent <usage_threshold>

          fair-usage
    deact-margin <deactivate_margin>

          fair-usage
    adjust-factor <adjust_factor>

          fair-usage
    inline-memory-share <max_mem_for_in-line>

          rulebase <rulebase_name>

             fair-usage
    session-waiver-percent <session_waiver>

             end

Notes:

- fair-usage command enables the Fair Usage feature.
- fair-usage threshold-percent <usage_threshold> command configures when to enable resource monitoring. As long as the amount of available memory is greater than the configured threshold, any memory requests are granted.<usage_threshold> is a percent value, and must be an integer from 1 through 100.
- fair-usage deact-margin <deactivate_margin> command configures when to disable resource monitoring. It is the window size between restricting/not restricting memory utilization.For example, if the “fair-usage threshold-percent” is set to 75%, on reaching this threshold resource monitoring is enabled. If the “fair-usage deact-margin” is set to 5%, when memory utilization falls 5% below “fair-usage threshold-percent”, i.e. to 70%, resource monitoring is disabled.<deactivate_margin> is a percentage value, and must be an integer from 1 through 100. By default, it is set to 10 percent.
- fair-usage adjust-factor <adjust_factor> is a hidden CLI command available to operators. This command configures the accuracy of memory reporting. When Session Manager reports its memory consumption, this percentage is added to the value being reported. With this, the reported memory will change as the sessions obtain/release memory.<adjust_factor> is a percentage value, and must be an integer from 1 through 100. By default, it is set to 10 percent.
- fair-usage inline-memory-share <max_mem_for_in-line> is a hidden CLI command available to operators for fine tuning the the performance of this feature. This command configures the amount of memory possibly allocated to in-line services on a Session Manager instance. This limit is per Session Manager.<max_mem_for_in-line> is a percentage value, and must be an integer from 1 through 100. By default, it is set to 60 percent.
- fair-usage session-waiver-percent <session_waiver> command configured in the rulebase configures a waiver for subscribers using the rulebase to use more than the average amount of memory limit configured in the fair-usage threshold-percent <usage_threshold> command. <session_waiver> is a percentage value, and must be an integer from 0 through 1000. By default, it is set to 20 percent.

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.

To configure the Post-processing feature, use the following configuration:

    configure

       active-charging
    service <ecs_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 <ruledef_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:

- In the Rulebase Configuration Mode, the ruledef configured for post-processing action must have been configured for post processing in the Ruledef Configuration Mode.
- If the same ruledef is required to be a charging rule in one rulebase and a post-processing rule in another rulebase, then two separate identical ruledefs must be defined.
- In this release, post processing with group-of-ruledefs is not supported.
- In this release, delay charging with dynamic rules is not supported, hence there cannot be dynamic post-processing rules.

Configuring Service Group QoS Feature

To create and configure a QoS-Group-of-Ruledefs, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          qos-group-of-ruledefs <qos_group_of_ruledefs_name> [ -noconfirm ] [ description <description> ]

             add-ruledef <ruledef_name>

             end

Notes:

- To configure flow action in the charging-action, in the ACS Charging Action Configuration Mode, use the flow action CLI command.
- To configure bandwidth limits for a flow, in the in the ACS Charging Action Configuration Mode use the flow limit-for-bandwidth CLI command.
- To view subscriber statistics and information on dynamic updates to charging parameters per call ID, in the Exec Mode, use the following command:show active-charging subscribers callid <call_id> charging-updates [ statistics ] [ charging-action [ name <charging_action_name> ] | qos-group [ name <qos_group_of_ruledefs_name> ] ] [ | { grep <grep_options> | more } ]

Configuring TCP Proxy

This section describes how to configure the TCP Proxy feature.

To enable and configure the TCP Proxy feature in the rulebase, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          rulebase <rulebase_name>

             tcp
    proxy-mode { dynamic { all | content-filtering | dcca | ip-readdressing | nexthop-readdressing | xheader-insert + } | static [ port [ <port_number> [ to <port_number> ] ] ] }

             end

Configuring Flow Admission Control

To configure the TCP Proxy Flow Admission Control feature, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          fair-usage
    tcp-proxy max-flows-per-subscriber <max_flows>

          fair-usage
    tcp-proxy memory-share <memory_share>

          end

Notes:

- It is not necessary for the Fair Usage feature to be enabled before this configuration.
- <max_flows> specifies the maximum number of flows for which TCP Proxy can be used per subscriber. Note that this limit is per Session Manager.
- <memory_share> specifies what portion of ECS memory should be reserved for TCP Proxy flows. Note that it is a percentage value.

Verifying your Configuration

To verify your configuration, in the Exec mode, use the following command:

show active-charging tcp-proxy statistics [ rulebase <rulebase_name> ] [ verbose ] [ | { grep <grep_options> | more } ]

Configuring Tethering Detection Feature

IMPORTANT:

The Tethering Detection feature has limitations that restrict its optimal use and is not supported in this release. It is available only for lab / testing purposes.

This section describes how to configure the Tethering Detection feature to detect subscriber flows from PC devices tethered to mobile smartphones.

IMPORTANT:

This command is available only if the Smartphone Tethering Detection license is enabled For more information please contact your Cisco account representative.

To enable and configure the Tethering Detection feature, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          tethering-database [ os-signature <os_signature_db_file_name> | tac <tac_db_file_name> | ua-signature <ua_signature_db_file_name> ] +

          ruledef <tethering_detection_ruledef_name>

             tethering-detection { flow-not-tethered | flow-tethered }

             exit

          rulebase <rulebase_name>

             tethering-detection [ os-db-only | ua-db-only ]

             action
    priority <priority> ruledef <tethering_detection_ruledef_name> charging-action <charging_action_name>

             ...

             end

Upgrading Tethering Detection Databases

To upgrade the Tethering Detection feature databases, in the Exec mode, use the following CLI command:

    upgrade tethering-detection
    database { all | os-signature | tac | ua-signature } [ -noconfirm ]

Notes:

- To load and upgrade the OS, UA, and TAC databases used in detecting tethering, the database files must be copied from MUR onto the ASR chassis to the designated directory path for storing the database files:/mnt/hd-raid/data/databases/Any further upgrades to the database files can be done by placing the file named new-filename in the designated directory path. ECS auto-detects the presence of files available for upgrade daily. When a new version of a file is found, the upgrade process is triggered. The upgrade can also be forced by running the upgrade command in the CLI. On a successful upgrade this file is renamed to filename.

Sample Tethering Detection Feature Configurations

The following examples illustrate two different implementations of the Tethering Detection feature’s configuration.

- The following type of configuration is suitable where ECS performance is critical and the operator wants to put in a flat charging plan in place for all the tethered traffic. In such a scenario, addition of a single new ruledef to the configuration suffices. Placing this ruledef at the highest priority in the rulebase will ensure all the tethered flows are charged as per the tariff plan for tethered traffic.

      configure

         active-charging
      service ecs_service

            tethering-database

            ruledef
      tethered-traffic

               tethering-detection
      flow-tethered

               tcp
      any-match = TRUE

               exit

            ruledef
      ftp-pkts

               ftp
      any-match = TRUE

               exit

            ruledef
      http-pkts

               http
      any-match = TRUE

               exit

            ruledef
      tcp-pkts

               tcp
      any-match = TRUE

               exit

            ruledef
      ip-pkts

               ip
      any-match = TRUE

               exit

            ruledef
      http-port

               tcp
      either-port = 80

               rule-application
      routing

               exit

            ruledef
      ftp-port

               tcp
      either-port = 21

               rule-application
      routing

               exit

            charging-action
      premium

               content-id
      1

               retransmissions-counted

               billing-action
      egcdr

               exit

            charging-action
      standard

               content-id
      2

               retransmissions-counted

               billing-action
      egcdr

               exit

            rulebase
      consumer

               tethering-detection

               action
      priority 10 ruledef tethered-traffic charging-action premium

               action
      priority 20 ruledef ftp-pkts charging-action standard

               action
      priority 30 ruledef http-pkts charging-action standard

               action
      priority 40 ruledef tcp-pkts charging-action standard

               action
      priority 50 ruledef ip-pkts charging-action standard

               route
      priority 80 ruledef http-port analyzer http

               exit

            rulebase
      default

            end

- The following type of configuration is suitable when operators want to apply differentiated charging to various flows that are found to be tethered. In this case, traffic that requires different charging action or content ID when it is tethered will be identified using two ruledefs, one with “flow-is-tethered = TRUE” option and another without this option. This configuration provides finer granularity of control but results in higher performance degradation because the rule matching tree size increases.

      configure

         active-charging
      service ecs_service

            tethering-database

            ruledef
      ftp-pkts

               ftp
      any-match = TRUE

               exit

            ruledef
      ftp-pkts-tethered

               ftp
      any-match = TRUE

               tethering-detection
      flow-tethered

               exit

            ruledef
      http-pkts

               http
      any-match = TRUE

               exit

            ruledef
      http-pkts-tethered

               http
      any-match = TRUE

               tethering-detection
      flow-tethered

               exit

            ruledef
      tcp-pkts

               tcp
      any-match = TRUE

               exit

            ruledef
      tcp-pkts-tethered

               tcp
      any-match = TRUE

               tethering-detection
      flow-tethered

               exit

            ruledef
      ip-pkts

               ip
      any-match = TRUE

               exit

            ruledef
      ip-pkts-tethered

               ip
      any-match = TRUE

               tethering-detection
      flow-tethered

               exit

            ruledef
      http-port

               tcp
      either-port = 80

               rule-application
      routing

               exit

            ruledef
      ftp-port

               tcp
      either-port = 21

               rule-application
      routing

               exit

            charging-action
      premium-http

               content-id
      10

               retransmissions-counted

               billing-action
      egcdr

               exit

            charging-action
      premium-ftp

               content-id
      20

               retransmissions-counted

               billing-action
      egcdr

               exit

            charging-action
      premium

               content-id
      1

               retransmissions-counted

               billing-action
      egcdr

               exit

            charging-action
      standard

               content-id
      2

               retransmissions-counted

               billing-action
      egcdr

               exit

            rulebase
      consumer

               tethering-detection

               action
      priority 10 ruledef ftp-pkts-tethered charging-action premium-ftp

               action
      priority 20 ruledef ftp-pkts charging-action standard

               action
      priority 30 ruledef http-pkts-tethered charging-action premium-http

               action
      priority 40 ruledef http-pkts charging-action standard

               action
      priority 50 ruledef tcp-pkts-tethered charging-action premium

               action
      priority 60 ruledef tcp-pkts charging-action standard

               action
      priority 70 ruledef ip-pkts-tethered charging-action premium

               action
      priority 80 ruledef ip-pkts charging-action standard

               route
      priority 80 ruledef http-port analyzer http

               exit

            rulebase
      default

               end

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.

To configure the Time-of-Day Activation/Deactivation of Rules feature, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          ruledef <ruledef_name>

             ...

             exit

          timedef <timedef_name>

             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 <ruledef_group_name> | ruledef <ruledef_name> } charging-action <charging_action_name> [ description <description> ]

             ...

             end

Notes:

- In a timeslot if only the time is specified, that timeslot will be applicable for all days.
- 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.
- If for a timeslot, “start day” > “end day”, that rule will span over the current week till the end day in the next week.
- 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 name <timedef_name>

Configuring URL Filtering Feature

This section describes how to configure the URL Filtering feature to simplify rules for URL detection.

To create a group-of-prefixed-URLs, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          group-of-prefixed-urls <prefixed_urls_group_name>

          end

To configure the URLs to be filtered in the group-of-prefixed-URLs, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          group-of-prefixed-urls <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, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          rulebase <rulebase_name>

             url-preprocessing
    bypass group-of-prefixed-urls <prefixed_urls_group_name>

             ...

             url-preprocessing
    bypass group-of-prefixed-urls <prefixed_urls_group_name>

             end

Notes:

- A maximum of 64 group-of-prefixed-urls can be created and configured.
- A maximum of 10 prefixed URLs can be configured in each group-of-prefixed-urls.
- 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 name <prefixed_urls_group_name>

### Configuring X-Header Insertion and Encryption Feature

This section describes how to configure the X-Header Insertion and Encryption features, collectively known as Header Enrichment.

#### Configuring X-Header Insertion

This section describes how to configure the X-Header Insertion feature.

IMPORTANT:

This feature is license dependent. Please contact your Cisco account representative for more information.

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 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 of x-header Fields section.

Creating the X-Header Format

To create an x-header format, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          xheader-format <xheader_format_name>

          end

Configuring the X-Header Format

To configure an x-header format, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          xheader-format <xheader_format_name>

             insert <xheader_field_name> { string-constant <xheader_field_value> | variable { bearer { 3gpp { apn | charging-characteristics | charging-id | imei | imsi | qos | rat-type | s-mcc-mnc | sgsn-address } | acr | customer-id | ggsn-address | mdn | msisdn-no-cc | radius-calling-station-id | session-id | sn-rulebase | subscriber-ip-address | username } [ encrypt ] | http { host | url } }

             end

Configuring Charging Action for Insertion of X-Header Fields

To configure a charging action for insertion of x-header fields, use the following configuration:

    configure

       active-charging
    service <ecs_service_name>

          charging-action <charging_action_name>

             xheader-insert
    xheader-format <xheader_format_name> [ encryption
    rc4md5 [ encrypted ] key <key> ] [ first-request-only ] [ -noconfirm ]

             end

Notes:

- If rc4md5 encryption is configured in the charging action, it will take precedence over RSA certificate based encryption for flows hitting particular charging action.

#### Configuring X-Header Encryption

This section describes how to configure the X-Header Encryption feature.

IMPORTANT:

This feature is license dependent. Please contact your Cisco account representative for more information.

To configure the X-Header Encryption feature:

1. Configure X-Header Insertion as described in the Configuring X-Header Insertion section.
2. Create/configure a rulebase and configure the encryption certificate to use and the re-encryption parameter as described in the Configuring X-Header Encryption section.
3. Configure the encryption certificate to use as described in the Configuring Encryption Certificate section.

Configuring X-Header Encryption

To configure X-Header Encryption, use the following configuration example:

    configure

       active-charging
    service <ecs_service_name>

          rulebase <rulebase_name>

             xheader-encryption
    certificate-name <certificate_name>

             xheader-encryption
    re-encryption period <re-encryption_period>

             end

Notes:

- This configuration enables X-Header Encryption for all subscribers using the specified rulebase <rulebase_name>.
- If the certificate is removed, ECS will continue using the copy that it has. It will only free its copy if the certificate name is removed from the rulebase.
- Changes to x-header format configuration will not trigger re-encryption for existing calls. The changed configuration will however, be applicable for new calls. The changed configuration will also apply at the next re-encryption time to those existing calls for which re-encryption timeout is specified. If encryption is enabled for a parameter while data is flowing, since its encrypted value will not be available, insertion of that parameter will stop.

Configuring Encryption Certificate

To configure the encryption certificate, use the following configuration example:

    configure

       certificate
    name <certificate_name> pem { { data <pem_certificate_data> private-key pem [ encrypted ] data <pem_pvt_key> } | { url <url> private-key pem { [ encrypted ] data <pem_pvt_key> | url <url> } }

       end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging xheader-format name <xheader_format_name>