Rf Interface Support

This chapter provides an overview of the Diameter Rf interface and describes how to configure the Rf interface.

Rf interface support is available on the Cisco system running StarOS 10.0 or later releases for the following products:

  • Gateway GPRS Support Node (GGSN)
  • HRPD Serving Gateway (HSGW)
  • Proxy Call Session Control Function (P-CSCF)
  • Packet Data Network Gateway (P-GW)
  • Serving Call Session Control Function (S-CSCF)
  • Serving Gateway (S-GW)

It is recommended that before using the procedures in this chapter you select the configuration example that best meets your service model, and configure the required elements for that model as described in the administration guide for the product that you are deploying.

This chapter describes the following topics:

Introduction

The Rf interface is the offline charging interface between the Charging Trigger Function (CTF) (for example, P-GW, S-GW, P-CSCF) and the Charging Collection Function (CCF). The Rf interface specification for LTE/GPRS/eHRPD offline charging is based on 3GPP TS 32.299 V8.6.0, 3GPP TS 32.251 V8.5.0 and other 3GPP specifications. The Rf interface specification for IP Multimedia Subsystem (IMS) offline charging is based on 3GPP TS 32.260 V8.12.0 and 3GPP TS 32.299 V8.13.0.

Offline charging is used for network services that are paid for periodically. For example, a user may have a subscription for voice calls that is paid monthly. The Rf protocol allows the CTF (Diameter client) to issue offline charging events to a Charging Data Function (CDF) (Diameter server). The charging events can either be one-time events or may be session-based.

The system provides a Diameter Offline Charging Application that can be used by deployed applications to generate charging events based on the Rf protocol. The offline charging application uses the base Diameter protocol implementation, and allows any application deployed on chassis to act as CTF to a configured CDF.

In general, accounting information from core network elements is required to be gathered so that the billing system can generate a consolidated record for each rendered service.

The CCF with the CDF and Charging Gateway Function (CGF) will be implemented as part of the core network application. The CDF function collects and aggregates Rf messages from the various CTFs and creates CDRs. The CGF collects CDRs from the CDFs and generates charging data record files for the data mediation/billing system for billing.

Offline Charging Architecture

The following diagram provides the high level charging architecture as specified in 3GPP 32.240. The interface between CSCF, S-GW, HSGW, P-GW and GGSN with CCF is Rf interface. Rf interface for EPC domain is as per 3GPP standards applicable to the PS Domain (e.g. 32.240, 32.251, 32.299, etc.).


Figure 1. Charging Architecture

The following figure shows the Rf interface between CTF and CDF.


Figure 2. Logical Offline Charging Architecture

The Rf offline charging architecture mainly consists of three network elements — CCF, CTF and Diameter Dynamic Routing Agent (DRA).

Charging Collection Function

The CCF implements the CDF and CGF. The CCF will serve as the Diameter Server for the Rf interface. All network elements supporting the CTF function should establish a Diameter based Rf Interface over TCP connections to the DRA. The DRA function will establish Rf Interface connection over TCP connections to the CCF.

The CCF is primarily responsible for receipt of all accounting information over the defined interface and the generation of CDR (aka UDRs and FDRs) records that are in local storage. This data is then transferred to the billing system using other interfaces. The CCF is also responsible for ensuring that the format of such CDRs is consistent with the billing system requirements. The CDF function within the CCF generates and CGF transfers the CDRs to the billing system.

The CDF function in the CCF is responsible for collecting the charging information and passing it on to the appropriate CGF via the GTP' based interface per 3GPP standards. The CGF passes CDR files to billing mediation via SCP.

Charging Trigger Function

The CTF will generate CDR records and passes it onto CCF. When a P-GW service is configured as CTF, then it will generate Flow Data Record (FDR) information as indicated via the PCRF. The P-GW generates Rf messages on a per PDN session basis. There are no per UE or per bearer charging messages generated by the P-GW.

The service data flows within IP-CAN bearer data traffic is categorized based on a combination of multiple key fields (Rating Group, Rating Group and Service -Identifier). Each Service-Data-Container captures single bi-directional flow or a group of single bidirectional flows as defined by Rating Group or Rating Group and Service-Identifier.

Similarly, when S-GW service is configured as CTF, it will generate Usage Data Record (UDR) information configurable on a per PDN basis QCI basis. Note that per bearer charging and per UE charging are no longer required. The Diameter charging sessions to the CCF are setup on a per PDN connection basis.

Dynamic Routing Agent

The DRA provides load distribution on a per session basis for Rf traffic from CTFs to CCFs. The DRA acts like a Diameter Server to the Gateways. The DRA acts like a Diameter client to CCF. DRA appears to be a CCF to the CTF and as a CTF to the CCF.

The DRA routes the Rf traffic on a per Diameter charging session basis. The load distribution algorithm can be configured in the DRA (Round Robin, Weighted distribution, etc). All Accounting Records (ACRs) in one Diameter charging session will be routed by the DRA to the same CCF. Upon failure of one CCF, the DRA selects an alternate CCF from a pool of CCFs.

License Requirements

The Rf interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific 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.

Supported Standards

Rf interface support is based on the following standards:

  • IETF RFC 4006: Diameter Credit Control Application; August 2005
  • 3GPP TS 32.299 V9.6.0 (2010-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Diameter charging applications (Release 9)

Features and Terminology

This section describes features and terminology pertaining to Rf functionality.

Offline Charging Scenarios

Offline charging for both events and sessions between CTF and the CDF is performed using the Rf reference point as defined in 3GPP TS 32.240.

Basic Principles

The Diameter client and server must implement the basic functionality of Diameter accounting, as defined by the RFC 3588 — Diameter Base Protocol.

For offline charging, the CTF implements the accounting state machine as described in RFC 3588. The CDF server implements the accounting state machine "SERVER, STATELESS ACCOUNTING" as specified in RFC 3588, i.e. there is no order in which the server expects to receive the accounting information.

The reporting of offline charging events to the CDF is managed through the Diameter Accounting Request (ACR) message. Rf supports the following ACR event types:


Table 1. Rf ACR Event Types

Request

Description

START

Starts an accounting session

INTERIM

Updates an accounting session

STOP

Stops an accounting session

EVENT

Indicates a one-time accounting event


ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. In contrast, EVENT accounting data is unrelated to sessions, and is used e.g. for a simple registration or interrogation and successful service event triggered by a network element. In addition, EVENT accounting data is also used for unsuccessful session establishment attempts.

IMPORTANT:

The ACR Event Type "EVENT" is supported in Rf CDRs only in the case of IMS specific Rf implementation.

The following table describes all possible ACRs that might be sent from the IMS nodes i.e. a P-CSCF and S-CSCF.


Table 2. Accounting Request Messages Triggered by SIP Methods or ISUP Messages for P-CSCF and S-CSCF

Diameter Message

Triggering SIP Method/ISUP Message

ACR [Start]

SIP 200 OK acknowledging an initial SIP INVITE

ISUP:ANM (applicable for the MGCF)

ACR [Interim]

SIP 200 OK acknowledging a SIP

RE-INVITE or SIP UPDATE [e.g. change in media components]

Expiration of AVP [Acct-Interim-Interval]

SIP Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP RE-INVITE or SIP UPDATE

ACR [Stop]

SIP BYE message (both normal and abnormal session termination cases)

ISUP:REL (applicable for the MGCF)

ACR [Event]
SIP 200 OK acknowledging non-session related SIP messages, which are:
  • SIP NOTIFY
  • SIP MESSAGE
  • SIP REGISTER
  • SIP SUBSCRIBE
  • SIP PUBLISH

SIP 200 OK acknowledging an initial SIP INVITE

SIP 202 Accepted acknowledging a SIP REFER or any other method

SIP Final Response 2xx (except SIP 200 OK)

SIP Final/Redirection Response 3xx

SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up

SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure

SIP CANCEL, indicating abortion of a SIP session set-up



Event Based Charging

In the case of event based charging, the network reports the usage or the service rendered where the service offering is rendered in a single operation. It is reported using the ACR EVENT.

In this scenario, CTF asks the CDF to store event related charging data.

Session Based Charging

Session based charging is the process of reporting usage reports for a session and uses the START, INTERIM & STOP accounting data. During a session, a network element may transmit multiple ACR Interims' depending on the proceeding of the session.

In this scenario, CTF asks the CDF to store session related charging data.

Diameter Base Protocol

The Diameter Base Protocol maintains the underlying connection between the Diameter Client and the Diameter Server. The connection between the client and server is TCP based.

In order for the application to be compliant with the specification, state machines should be implemented at some level within the implementation.

Diameter Base supports the following Rf message commands that can be used within the application.


Table 3. Diameter Rf Messages

Command Name

Source

Destination

Abbreviation

Accounting-Request

CTF

CDF

ACR

Accounting-Answer

CDF

CTF

ACA


There are a series of other Diameter messages exchanged to check the status of the connection and the capabilities.
  • Capabilities Exchange Messages: Capabilities Exchange Messages are exchanged between the diameter peers to know the capabilities of each other and identity of each other.
    • Capabilities Exchange Request (CER): This message is sent from the client to the server to know the capabilities of the server.
    • Capabilities Exchange Answer (CEA): This message is sent from the server to the client in response to the CER message.
  • Device Watchdog Request (DWR): After the CER/CEA messages are exchanged, if there is no more traffic between peers for a while, to monitor the health of the connection, DWR message is sent from the client. The Device Watchdog timer (Tw) is configurable and can vary from 6 through 30 seconds. A very low value will result in duplication of messages. The default value is 30 seconds. On two consecutive expiries of Tw without a DWA, the peer is considered to be down.

    IMPORTANT:

    DWR is sent only after Tw expiry after the last message that came from the server. Say if there is continuous exchange of messages between the peers, DWR might not be sent if (Current Time - Last message received time from server) is less than Tw.

  • Device Watchdog Answer (DWA): This is the response to the DWR message from the server. This is used to monitor the connection state.
  • Disconnect Peer Request (DPR): This message is sent to the peer to inform to shutdown the connection. There is no capability currently to send the message to the Diameter server.
  • Disconnect Peer Answer (DPA): This message is the response to the DPR request from the peer. On receiving the DPR, the peer sends DPA and puts the connection state to “DO NOT WANT TO TALK TO YOU” state and there is no way to get the connection back except for reconfiguring the peer again.A timeout value for retrying the disconnected peer must be provided.

Timer Expiry Behavior

Upon establishing the Diameter connection, an accounting interim timer (AII) is used to indicate the expiration of a Diameter accounting session, and is configurable at the CTF. The CTF indicates the timer value in the ACR-Start, in the Acct-Interim-Interval AVP. The CDF responds with its own AII value (through the DRA), which must be used by the CTF to start a timer upon whose expiration an ACR INTERIM message must be sent. An instance of the AII timer is started in the CCF at the beginning of the accounting session, reset on the receipt of an ACR-Interim and stopped on the receipt of the ACR-Stop. After expiration of the AII timer, ACR INTERIM message will be generated and the timer will be reset and the accounting session will be continued.

Rf Interface Failures/Error Conditions

The current architecture allows for primary and secondary connections or Active-Active connections for each network element with the CDF elements.

DRA/CCF Connection Failure

When the connection towards one of the primary/Active DRAs in CCF becomes unavailable, the CTF picks the Secondary/Active IP address and begins to use that as a Primary.

If no DRA (and/or the CCF) is reachable, the network element must buffer the generated accounting data in non-volatile memory. Once the DRA connection is up, all accounting messages must be pulled by the CDF through offline file transfer.

No Reply from CCF

In case the CTF/DRA does not receive an ACA in response to an ACR, it may retransmit the ACR message. The waiting time until a retransmission is sent, and the maximum number of repetitions are both configurable by the operator. When the maximum number of retransmissions is reached and still no ACA reply has been received, the CTF/DRA sends the ACRs to the secondary/alternate DRA/CCF.

Detection of Message Duplication

The Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with the T-flag as described in RFC 3588.

If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from duplicated message(s) is used.

CCF Detected Failure

The CCF closes a CDR when it detects that expected Diameter ACRs for a particular session have not been received for a period of time. The exact behavior of the CCF is operator configurable.

How it Works

This section describes how offline charging for subscribers works with Rf interface support in GPRS/eHRPD/LTE/IMS networks.

The following figure and table explain the transactions that are required on the Diameter Rf interface in order to perform event based charging. The operation may alternatively be carried out prior to, concurrently with or after service/content delivery.
Figure 3. Rf Call Flow for Event Based Charging

Table 4. Rf Call Flow Description for Event Based Charging
Step Description

1

The network element (CTF) receives indication that service has been used/delivered.

2

The CTF (acting as Diameter client) sends Accounting-Request (ACR) with Accounting-Record-Type AVP set to EVENT_RECORD to indicate service specific information to the CDF (acting as Diameter server).

3

The CDF receives the relevant service charging parameters and processes accounting request.

4

The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type AVP set to EVENT_RECORD to the CTF in order to inform that charging information was received.


The following figure and table explain the simple Rf call flow for session based charging.
Figure 4. Rf Call Flow for Session Based Charging

Table 5. Rf Call Flow Description for Session Based Charging
Step Description

1

The CTF receives a service request. The service request may be initiated either by the user or the other network element.

2

In order to start accounting session, the CTF sends a Accounting-Request (ACR) with Accounting-Record-Type AVP set to START_RECORD to the CDF.

3

The session is initiated and the CDF opens a CDR for the current session.

4

The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to START_RECORD to the CTF and possibly Acct-Interim-Interval AVP (AII) set to non-zero value indicating the desired intermediate charging interval.

5

When either AII elapses or charging condition changes are recognized at CTF, the CTF sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set to INTERIM_RECORD to the CDF.

6

The CDF updates the CDR in question.

7

The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to INTERIM_RECORD to the CTF.

8

The service is terminated.

9

The CTF sends a Accounting-Request (ACR) with Accounting-Record-Type AVP set to STOP_RECORD to the CDF.

10

The CDF updates the CDR accordingly and closes the CDR.

11

The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to STOP_RECORD to the CTF.


Configuring Rf Interface Support

To configure Rf interface support:

  1. Configure the core network service as described in this Administration Guide.
  2. Enable Active Charging Service (ACS) and create ACS as described in the Enhanced Charging Services Administration Guide.

    IMPORTANT:

    The procedures in this section assume that you have installed and configured your chassis including the ECS installation and configuration as described in the Enhanced Charging Services Administration Guide.

  3. Enable Rf accounting in ACS as described in the Enabling Rf Interface in Active Charging Service section.
  4. Configure Rf interface support as described in the relevant sections:
  5. 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.

Enabling Rf Interface in Active Charging Service

To enable the billing record generation and Rf accounting, use the following configuration:

configure

   active-charging
service <service_name>

      rulebase <rulebase_name>

         billing-records rf

         active-charging
rf { rating-group-override | service-id-override }

         end

Notes:

  • Prior to creating the Active Charging Service (ACS), the require active-charging command should be configured to enable ACS functionality.
  • The billing-records rf command configures Rf record type of billing to be performed for subscriber sessions. Rf accounting is applicable only for dynamic and predefined ACS rules. For more information on the rules and its configuration, refer to the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference.
  • The active-charging rf command is used to enforce a specific rating group / service identifier on all PCC rules, predefined ACS rules, and static ACS rules for Rf-based accounting. As this CLI configuration is applied at the rulebase level, all the APNs that have the current rulebase defined will inherit the configuration.For more information on this command, refer to the ACS Rulebase Configuration Mode Commands chapter in the Command Line Interface Reference.

Configuring GGSN / P-GW Rf Interface Support

To configure the standard Rf interface support for GGSN/P-GW, use the following configuration:

configure

   context <context_name>

      apn <apn_name>

         associate
accounting-policy <policy_name>

         exit

      policy
accounting <policy_name>

         accounting-event-trigger { cgi-sai-change | ecgi-change | flow-information-change | interim-timeout | location-change | rai-change | tai-change } action { interim | stop-start }

         accounting-keys qci

         accounting-level { flow | pdn | pdn-qci | qci | sdf | subscriber }

         cc
profile index { buckets num | interval seconds | sdf-interval seconds | sdf-volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } }  | serving-nodes num | tariff
time1 min
hrs [ time2 min hrs...time4 min hrs ] | volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } } }

         max-containers { containers | fill-buffer }

         end

Notes:

  • The policy can be configured in any context.
  • For information on configuring accounting levels/policies/modes/event triggers, refer to the Accounting Policy Configuration Mode Commands chapter in the Command Line Interface Reference.
  • Depending on the triggers configured, the containers will either be cached or released. In the case of GGSN/P-GW, the containers will be cached when the event trigger is one of the following:
    • QOS_CHANGE
    • FLOW_INFORMATION_CHANGE
    • LOCATION_CHANGE
    • SERVING_NODE_CHANGE
    • SERVICE_IDLE
    • SERVICE_DATA_VOLUME_LIMIT
    • SERVICE_DATA_TIME_LIMIT
    • IP_FLOW_TERMINATION
    • TARIFF_CHANGE
    If the event trigger is one of the following, the containers will be released:
    • VOLUME_LIMIT
    • TIME_LIMIT
    • RAT_CHANGE
    • TIMEZONE_CHANGE
    • PLMN_CHANGE

    IMPORTANT:

    Currently, SDF and flow level accounting are supported in P-GW.

The following assumptions guide the behavior of P-GW, GGSN, S-GW, HSGW and CCF for Change-Condition triggers:
  • Data in the ACR messages due to change conditions contain the snapshot of all data that is applicable to the interval of the flow/session from the previous ACR message. This includes all data that is already sent and has not changed (e.g. SGSN-Address).
  • All information that is in a PDN session/flow up to the point of the Change-Condition trigger is captured (snapshot) in the ACR-Interim messages. Information about the target S-GW/HSGW/Time-Zone/ULI/3GPP2-BSID/QoS-Information/PLMN Change/etc will be in subsequent Rf messages.
  • When multiple change conditions occur, the precedence of reporting change conditions is as follows for S-GW and HSGW only:
    • Normal/Abnormal Release (Stop)
    • Management Intervention (Stop)
    • RAT Change
    • UE Timezone Change
    • Serving Node PLMN Change
    • Max Number of Changes in Charging conditions
    • Volume Limit
    • Time Limit
    • Service Data Volume Limit
    • Service Data Time Limit
    • Service Idled out
    • Serving Node Change
    • User Location Change
    • QoS Change
    Even though Accounting Interim Interval (AII) timer expiration trigger is not a Change-Condition, AII timer trigger has the lowest precedence among the above triggers. The AII timer will be reset when a ACR Interim for any of the above triggers is sent.For P-GW and GGSN, Service-Data-Container grouped AVP has the Change-Condition AVP as multiple occurrence AVP sending all the Change-Conditions that occur at a point in time, so the above precedence is not needed.

Table 6. P-GW/GGSN and CCF Behavior for Change-Condition in ACR-Stop and ACR-Interim for LTE/E-HRPD/GGSN
ACR Message Change-Condition Value CCF Response to Change-Condition Value CC Level Population Comments
Addition of Container Partial FDR Final FDR PS-Information Level SDC Level
Stop Normal Release YES NO YES Normal Release Normal Release When PDN/IP session is closed, C-C in both level will have Normal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Normal Release YES NO NO N/A Normal Release Flow is closed, SDC CC is populated and closed container is added to record. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Stop Abnormal Release YES NO YES Abnormal Release Abnormal Release When PDN/IP session is closed, C-C in both level will have Abnormal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Abnormal Release YES NO NO N/A Abnormal Release Flow is closed, SDC CC is populated and closed container is added to record. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). QoS-Change YES NO NO N/A QoS-Change The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Interim Volume Limit YES YES NO Volume Limit Volume Limit For PDN/IP Session Volume Limit. The Volume Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry this charging profile that will passed on from the HSS/AAA to P-GW/GGSN through various interfaces.  The charging profile will be provisioned in the HSS.
Interim Time Limit YES YES NO Time Limit Time Limit For PDN/IP Session Time Limit. The Time Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry this charging profile that will passed on from the HSS/AAA to P-GW/GGSN through various interfaces.  The charging profile will be provisioned in the HSS.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Serving Node Change YES NO NO N/A Serving Node Change The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Interim Serving Node PLMN Change YES YES NO Serving Node PLMN Change Serving Node PLMN Change .
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). User Location Change YES NO NO N/A User Location Change This is BSID Change in eHRPD. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Interim RAT Change YES YES NO RAT Change RAT Change .
Interim UE Timezone Change YES YES NO UE Timezone change UE Timezone change This is not applicable for eHRPD.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Tariff Time Change YES NO NO N/A Tariff Time Change Triggered when Tariff Time changes. Tariff Time Change requires an online charging side change. The implementation of this Change Condition is dependent on implementation of Online Charging update.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Service Idled Out YES NO NO N/A Service Idled Out Flow Idled out. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Service Data Volume Limit YES NO NO N/A Service Data Volume Limit Volume Limit reached for a specific flow. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Service Data Time Limit YES NO NO N/A Service Data Time Limit Time Limit reached for a specific flow. The container for this change condition will be cached by the P-GW/GGSN and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Interim Max Number of Changes in Charging Conditions YES YES NO YES YES, Will include SDC that correponds to the CCs that occurred (Normal Release of Flow, Abnormal Release of Flow, QoS-Change, Serving Node Change, User Location Change, Tariff Time Change, Service Idled Out, Service Data Volunme Limt, Service Data Time Limit) This ACR[Interim] is triggered at the instant when the Max Number of changes in charging conditions takes place. Max Change Condition is applicable for QoS-Change, Service-Idled Out, ULI change, Flow Normal Release, Flow Abnormal Release, Service Data Volume Limit, Service Data Time Limit, AII Timer ACR Interim and Service Node Change CC only. The Max Number of Changes in Charging Conditions is set at 10. Example assuming 1 flow in the PDN Session: [1] Max Number of Changes in Charging Conditions set at P-GW/GGSN = 2. [2] Change Condition 1 takes place. No ACR Interim is sent. P-GW/GGSN stores the SDC. [3] Change Condition 2 takes place. An ACR Interim is sent. Now Max Number of Changes in Charging conditions is populated in the PS-Information 2 Service-Data-Containers (1 for each change condition) are populated in the ACR Interim. [4] CCF creates the partial record.
Stop Management Intervention YES NO YES YES YES Management intervention will close the PDN session from P-GW/GGSN.
Interim - YES NO NO N/A N/A This is included here to indicate that an ACR[Interim] due to AII timer will contain one or more populated SDC/s for a/all flow/s, but Change-Condition AVP will NOT be populated.


Configuring HSGW Rf Interface Support

To configure HSGW Rf interface support, use the following configuration:

configure

   context <context_name>

      hsgw-service<service_name>

         associate
accounting-policy <policy_name>

         exit

      exit

      policy
accounting <policy_name>

      accounting-event-trigger { cgi-sai-change | ecgi-change | flow-information-change | interim-timeout | location-change | rai-change | tai-change } action { interim | stop-start }

      accounting-keys qci

      accounting-level { flow | pdn | pdn-qci | qci | sdf | subscriber }

      cc
profile index { buckets num | interval seconds | sdf-interval seconds | sdf-volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } }  | serving-nodes num | tariff
time1 min
hrs [ time2 min hrs...time4 min hrs ] | volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } } }

      max-containers { containers | fill-buffer }

      exit

   end

Notes:

  • The policy can be configured in any context.
  • For information on configuring accounting policies/modes/event triggers, refer to the Accounting Policy Configuration Mode Commands chapter in the Command Line Interface Reference.
  • For an HSGW session, the containers will be cached when the event trigger is one of the following: QOS_CHANGE FLOW_INFORMATION_CHANGE LOCATION_CHANGE SERVING_NODE_CHANGE Similarly, if the event trigger is one of the following, the containers will be released: VOLUME_LIMIT TIME_LIMIT

Table 7. HSGW and CCF Behavior for Change-Condition in ACR[Stop] and ACR[Interim] for eHRPD
ACR Message Change-Condition Value CCF Response to Change-Condition Value PDN Connection level reporting(PDN Session based accounting) EPS bearer level reporting(PDN Session per QCI accounting) Comments
Addition of Container Partial UDR Final UDR C-C on PS-Information Level C-C on TDV Level CC on PS-Information Level CC on TDV Level
Stop Normal Release YES NO YES Normal Release Normal Release for all bearers Normal Release Normal Release When PDN session/PDN Session per QCI is closed, C-C in both level will have Normal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Normal Release YES NO NO N/A Normal Release for the specific bearer that is released N/A N/A This is applicable for per PDN Session based accounting only. This is when a bearer is closed in a PDN Session accounting charging session. TDV is populated and the container is added to the record.The container for this change condition will be cached by the HSGW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Stop Abnormal Release YES NO YES Abnormal Release Abnormal Release for all bearers Abnormal Release Abnormal Release When PDN session/PDN Session per QCI is closed, C-C in both level will have Abnormal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Abnormal Release YES NO NO N/A Abormal Release for the specific bearer that is released. N/A N/A This is for FFS. This is applicable for per PDN Session based accounting only. This is when a bearer is closed abnormally in a PDN Session accounting charging session. TDV is populated and the container is added to the record. The container for this change condition will be cached by the HSGW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). QoS-Change YES NO NO N/A QoS-Change - added to TDV for the bearer that the trigger affected, ACR sent when MaxCCC is reached (if Max CC is provisioned) N/A QoS-Change - added to TDV, ACR sent when MaxCCC is reached (if MaxCC is provisioned) The container for this change condition will be cached by the HSGW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.For APN-AMBR change, containers (TDVs) for all existing non-GBR bearers will be cached.
Interim Volume Limit YES YES NO Volume Limit for all bearers Volume Limit for all bearers Volume Limit Volume Limit The Volume Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry this charging profile that will passed on from the HSS/AAA to HSGW through various interfaces. The charging profile will be provisioned in the HSS.
Interim Time Limit YES YES NO Time Limit for all bearers Time Limit for all bearers Time Limit Time Limit The Time Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry this charging profile that will passed on from the HSS/AAA to HSGW through various interfaces. The charging profile will be provisioned in the HSS.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Serving Node Change YES NO NO N/A Serving Node Change - added to TDV for all bearers, ACR sent when MaxCCC is reached (if MaxCC is configured) N/A Serving Node Change - added to TDV, ACR sent when MaxCCC is reached (if MaxCC is configured) The container for this change condition will be cached by the HSGW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
N/A Serving Node PLMN Change N/A N/A N/A N/A N/A N/A N/A HSGW PLMN Change, Normal Release is sent.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). User Location Change YES NO NO N/A ULI Change - added to TDV for all bearers, ACR sent when MaxCCC is reached (if MaxCC is configured) N/A ULI Change - added to TDV, ACR sent when MaxCCC is reached (if MaxCC is configured) This is BSID Change in eHRPD.The container for this change condition will be cached by the HSGW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
N/A RAT Change N/A N/A N/A N/A N/A N/A N/A RAT Change is not applicable, as S-GW will be changed and old S-GW will send a Normal Release.
N/A UE Timezone Change N/A N/A N/A N/A N/A N/A N/A UE Timezone not reported in eHRPD accounting.
N/A Tariff Time Change N/A N/A N/A N/A N/A N/A N/A .
N/A Service Idled Out N/A N/A N/A N/A N/A N/A N/A .
N/A ServiceSpecificUnit Limit N/A N/A N/A N/A N/A N/A N/A This is Online charging related, so not applicable for Offline charging.
Interim Max Number of Changes in Charging Conditions YES YES NO Max Number of Changes in Charging TDV corresponds to change condition that occurred (Qos-Change or ULI change or Normal Bearer Release or Abnormal Bearer Release or Serving Node Change ) Max Number of Changes in Charging TDV corresponds to change condition that occurred (Qos-Change or ULI change or Serving Node Change ) This ACR[Interim] is triggered at the instant when the Max Number of changes in charging conditions takes place. The Max Number of Changes in Charging Conditions is set at 10. Example: [1] Max Number of Changes in Charging Conditions set at S-GW = 2. [2] When Change Condition 1 takes place an ACR[interim] is sent and Traffic-Data-Volumes added to the UDR. (continued)
. . . . . . . . . . [3] Change Condition 2 takes place. An ACR Interim is sent. Now Max Number of Changes in Charging conditions is populated in the PS-Information and the second Change Condition 2 is populated in the Traffic-Data-Volumes. [4] CCF creates the partial record.
N/A Management Intervention N/A N/A N/A N/A N/A N/A N/A Management intervention will close the PDN session from P-GW.
Interim - YES NO NO N/A N/A N/A N/A This is included here to indicate that an ACR[Interim] due to AII timer will contain one or more populated TDVs for a/all bearer/s, but Change-Condition AVP will NOT be populated.


Configuring P-CSCF/S-CSCF Rf Interface Support

To configure P-CSCF/S-CSCF Rf interface support, use the following configuration:

configure

   context vpn

      aaa
group default

         diameter
authentication dictionary aaa-custom8

         diameter
accounting dictionary aaa-custom2

         diameter
accounting endpoint <endpoint_name>

         diameter
accounting server <server_name> priority <priority>

      exit

      diameter
endpoint <endpoint_name>

         origin
realm <realm_name>

         use-proxy

         origin
host <host_name> address <ip_address>

         peer <peer_name> address <ip_address>

      exit

end

Notes:

  • For information on commands used in the basic configuration for Rf support, refer to the Command Line Interface Reference.

Enabling Charging for SIP Methods

To enable the charging for all Session Initiation Protocol (SIP) methods in CSCF, use the following configuration:

configure

   context vpn

      cscf
service pcscf 

      charging

end

IMPORTANT:

Please note that charging is disabled by default.

To enable the charging for all SIP methods except REGISTER, use the following configuration:

configure

   context vpn

      cscf
service pcscf 

      charging

         exclude register

end

To enable the charging only for INVITE SIP method, use the following configuration:

configure

   context vpn

      cscf
service pcscf 

      no charging

         exclude invite

end

Configuring S-GW Rf Interface Support

To configure S-GW Rf interface support, use the following configuration:

configure

   context <context_name>

      sgw-service<service_name>

         associate
accounting-policy <policy_name>

         exit

      exit

   policy
accounting <policy_name>

      accounting-event-trigger { cgi-sai-change | ecgi-change | flow-information-change | interim-timeout | location-change | rai-change | tai-change } action { interim | stop-start }

      accounting-keys qci

      accounting-level { flow | pdn | pdn-qci | qci | sdf | subscriber }

      cc
profile index { buckets num | interval seconds | sdf-interval seconds | sdf-volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } }  | serving-nodes num | tariff
time1 min
hrs [ time2 min hrs...time4 min hrs ] | volume { downlink octets { uplink octets } | total octets | uplink octets { downlink octets } } }

      max-containers { containers | fill-buffer }

      exit

         end

Notes:

  • The policy can be configured in any context.
  • For information on configuring accounting policies/modes/event triggers, refer to the Accounting Policy Configuration Mode Commands chapter in the Command Line Interface Reference.
  • For an S-GW session, the containers will be cached when the event trigger is one of the following: QOS_CHANGE FLOW_INFORMATION_CHANGE LOCATION_CHANGE Similarly, if the event trigger is one of the following, the containers will be released: VOLUME_LIMIT TIME_LIMIT PLMN_CHANGE TIMEZONE_CHANGE

Table 8. S-GW and CCF Behavior for Change-Condition in ACR[Stop] and ACR[Interim] for LTE
ACR Message Change-Condition Value CCF Response to Change-Condition Value PDN Connection level reporting(PDN Session based accounting) EPS bearer level reporting(PDN Session per QCI accounting) Comments
Addition of Container Partial UDR Final UDR C-C on PS-Information Level C-C on TDV Level CC on PS-Information Level CC on TDV Level
Stop Normal Release YES NO YES Normal Release Normal Release for all bearers Normal Release Normal Release When PDN session/PDN Session per QCI is closed, C-C in both level will have Normal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Normal Release YES NO NO N/A Normal Release for the specific bearer that is released N/A N/A This is applicable for per PDN Session based accounting only. This is when a bearer is closed in a PDN Session accounting charging session. TDV is populated and the container is added to the record.The container for this change condition will be cached by the S-GW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
Stop Abnormal Release YES NO YES Abnormal Release Abnormal Release for all bearers Abnormal Release Abnormal Release When PDN session/PDN Session per QCI is closed, C-C in both level will have Abnormal Release.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). Abnormal Release YES NO NO N/A Abormal Release for the specific bearer that is released. N/A N/A This is for FFS. This is applicable for per PDN Session based accounting only. This is when a bearer is closed abnormally in a PDN Session accounting charging session. TDV is populated and the container is added to the record.The container for this change condition will be cached by the S-GW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). QoS-Change YES NO NO N/A QoS-Change - added to TDV for the bearer that is affected by this trigger. N/A QoS-Change - added to TDV.) The container for this change condition will be cached by the S-GW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.For APN-AMBR change, containers (TDVs) for all existing non-GBR bearers will be cached.
Interim Volume Limit YES YES NO Volume Limit for all bearers Volume Limit for all bearers Volume Limit for all bearers Volume Limit On a per PDN Session basis for per PDN accounting. On a per PDN per QCI basis for the per PDN per QCI accounting.The Volume Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry the charging profile identifier that is passed from HSS to S-GW via MME. The charging profile value can be configured in the HSS on a per APN basis.
Interim Time Limit YES YES NO Time Limit for all bearers Time Limit for all bearers Time Limit Time Limit The Time Limit is configured as part of the Charging profile and the Charging-Characteristics AVP will carry the charging profile identifier that is passed from HSS to S-GW via MME. The charging profile value can be configured in the HSS on a per APN basis.
N/A Serving Node Change N/A N/A N/A N/A N/A N/A N/A N/A
Interim Serving Node PLMN Change YES YES NO Serving Node PLMN Change for all bearers Serving Node PLMN Change for all bearers Serving Node PLMN Change for bearer Serving Node PLMN Change for bearer PLMN change noticed at the S-GW, without S-GW relocation. eNB/MME may change and belong to a new PLMN (rural operator) or eNB may change with no MME/S-GW relocation; however eNB belongs to new serving network. This Change Condition is required as S-GW could support a MME owned by a rural operator. With S-GW relocation, the old S-GW terminates the Diameter charging session & the new S-GW starts a Diameter charging session (S-GW-Change AVP included).
None (as this change condition is a counter for the Max Number of Changes in Charging Conditions). User Location Change YES NO NO N/A ULI Change - added to TDV for all bearers. N/A ULI Change - added to TDV. The container for this change condition will be cached by the S-GW and the container will be in a ACR Interim/Stop sent for partial record (Interim), final Record (Stop) or AII trigger (Interim) trigger.
N/A RAT Change YES YES NO RAT Change RAT Change YES YES RAT Change is not applicable, as S-GW will be changed and old S-GW will send a Normal Release.
Interim UE Timezone Change YES YES NO UE Timezone UE Timezone Change for all bearers UE Timezone UE Timezone change .
N/A Tariff Time Change N/A N/A N/A N/A N/A N/A N/A .
N/A Service Idled Out N/A N/A N/A N/A N/A N/A N/A .
N/A ServiceSpecificUnit Limit N/A N/A N/A N/A N/A N/A N/A This is Online charging related, so not applicable for Offline charging.
Interim Max Number of Changes in Charging Conditions YES YES NO Max Number of Changes in Charging TDV corresponds to change condition that occurred (Qos-Change or ULI change or Normal Bearer Termination, Abnormal Bearer Termination.) Max Number of Changes in Charging TDV corresponds to change condition that occurred (Qos-Change or ULI Change) This ACR[Interim] is triggered at the instant when the Max Number of changes in charging conditions takes place.The Max Number of Changes in Charging Conditions is set at 10. Example: [1] Max Number of Changes in Charging Conditions set at S-GW = 2. [2] When Change Condition 1 takes place no ACR[interim] is sent, but S-GW will store the container data for this change condition. (continued)
. . . . . . . . . . [3] Change Condition 2 takes place. An ACR Interim is sent. Now Max Number of Changes in Charging conditions is populated in the PS-Information and the both the TDVs for the Change condition 1 and Change Condition 2 is populated in the 2 TDVs. Please note the TDVs need to be in the order that they are created so that the Billing Mediation system is not confused with the usage data sequence. [4] CCF creates the partial record.
N/A Management Intervention N/A N/A N/A N/A N/A N/A N/A Management intervention will close the PDN session from P-GW.
Interim - YES NO NO N/A N/A N/A N/A This is included here to indicate that an ACR[Interim] due to AII timer will contain one or more populated TDVs for a/all bearer/s, but Change-Condition AVP will NOT be populated.


Gathering Statistics

This section explains how to gather Rf and related statistics and configuration information.

In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.

Statistics/Information Action to perform

Complete statistics for Diameter Rf accounting sessions

show diameter aaa-statistics



The following is a sample output of the show diameter aaa-statistics command:

Authentication  Servers
Summary

 -------------------------------

Message Stats :

  Total MA Requests:
           0        Total MA Answers:              0

  MAR - Retries:   
            0        MAA Timeouts:                  0

  MAA - Dropped:   
            0

  Total SA Requests:
           0        Total SA Answers:              0

  SAR - Retries:   
            0        SAA Timeouts:                  0

  SAA - Dropped:   
            0

  Total UA Requests:
           0        Total UA Answers:              0

  UAR - Retries:   
            0        UAA Timeouts:                  0

  UAA - Dropped:   
            0

  Total LI Requests:
           0        Total LI Answers:              0

  LIR - Retries:   
            0        LIA Timeouts:                  0

  LIA - Dropped:   
            0

  Total RT Requests:
           0        Total RT Answers:              0

  RTR - Rejected:  
            0

  Total PP Requests:
           0        Total PP Answers:              0

  PPR - Rejected:  
            0

  Total DE Requests:
           0        Total DE Answers:              0

  DEA - Accept:    
            0        DEA - Reject:                  0

  DER - Retries:   
            0        DEA Timeouts:                  0

  DEA - Dropped:   
            0

  Total AA Requests:
           0        Total AA Answers:              0

  AAR - Retries:   
            0        AAA Timeouts:                  0

  AAA - Dropped:   
            0

  ASR:             
            0        ASA:                           0

  RAR:             
            0        RAA:                           0

  STR:             
            0        STA:                           0

  STR - Retries:   
            0

Message Error Stats:

  Diameter Protocol
Errs:        0       Bad Answers:                   0

  Unknown Session Reqs:
         0       Bad Requests:                  0

  Request Timeouts:
             0       Parse Errors:                  0

  Request Retries: 
             0

Session Stats:

  Total Sessions:  
              0      Freed Sessions:                  0

  Session Timeouts:
              0      Active Sessions:                 0

STR Termination Cause
Stats:

  Diameter Logout: 
             0       Service Not Provided:          0

  Bad Answer:      
             0       Administrative:                0

  Link Broken:     
             0       Auth Expired:                  0

  User Moved:      
             0       Session Timeout:               0

  User Request:    
             0       Lost Carrier                   0

  Lost Service:    
             0       Idle Timeout                   0

  NAS Session Timeout:
          0       Admin Reset                    0

  Admin Reboot:    
             0       Port Error:                    0

  NAS Error:       
             0       NAS Request:                   0

  NAS Reboot:      
             0       Port Unneeded:                 0

  Port Preempted:  
             0       Port Suspended:                0

  Service Unavailable:
          0       Callback:                      0

  User Error:      
             0       Host Request:                  0

 Accounting Servers
Summary

 ---------------------------

Message Stats :

  Total AC Requests:
            0        Total AC Answers:              0

  ACR-Start:       
             0        ACA-Start:                     0

  ACR-Start  Retries
:           0        ACA-Start  Timeouts:           0

  ACR-Interim:     
             0        ACA-Interim:                   0

  ACR-Interim  Retries
:         0        ACA-Interim  Timeouts:         0

  ACR-Event:       
             0        ACA-Event:                     0

  ACR-Stop :       
             0        ACA-Stop:                      0

  ACR-Stop  Retries
:            0        ACA-Stop  Timeouts:            0

  ACA-Dropped :    
             0

AC Message Error Stats:

  Diameter Protocol
Errs:        0        Bad Answers:                   0

  Unknown Session Reqs:
         0        Bad Requests:                  0

  Request Timeouts:
             0        Parse Errors:                  0

  Request Retries: 
             0