Rf Interface Support

Overview

This document describes support of Rf interface on SBC as IMS Network elements P-CSCF and IBCF.

The first phase of Rf Interface support was implemented in 4.2.0 release for INVITE or Session-related charging records. This release extends Rf functionality to support reporting Non-Session related offline charging events, including the following:

• Subscription – Initial Subscribe, un-Subscribe, un-Subscribe using Notify, Administratively unsubscribe using CLI/EMA
• Registration – Initial Register, de-register, de-register using notify, Administratively De-register using CLI/EMA
• Sessions – ACR (START/STOP/INTERIM/EVENT) for session setup, tear-down, long duration calls and failed calls respectively.
• Out-of-dialog Notify relay–Event record is generated
• Out-of-dialog Message relay
• Out-of-dialog Publish relay
• Out-of-dialog Option relay
• Out-of-Dialog REFER relay

IMS network elements share the charging information with each other using SIP header fields. SIP headers "P-charging-Vector" and "P-charging-Function-Address" as defined in RFC 3455 are used to transfer the charging information among IMS core network elements.

IMS network elements (S-CSCF, P-CSCF, I-CSCF, BGCF, IBCF, and MGCF) apply off-line charging through the Rf interface using the CDF address as received via SIP signaling or the locally configured CDF address in the IMS network element.

The charging architecture implementing Diameter adheres to the structure where all communications for off-line charging purposes between the CTF (Diameter client) and the CDF (Diameter server) are carried out on the Diameter Rf reference point, where the CTF reports charging information to the Charging Data Function (CDF). The CDF uses this information to construct and format CDRs.

3GPP Logical Off-line Charging Architecture

The Rf reference point from the Charging Trigger Function (CTF) to the Charging Data Function (CDF) is intended for the transport of off-line charging events. The following figure depicts the position of the Rf within the overall 3rd Generation Partnership Project (3GPP) charging architecture.

Figure 1: 3GPP Network Architecture

The SBC Core supports the following Rf Interface functionality:

• Rf interface-based offline billing either as IBCF or P-CSCF, which is compliant with standard IMS along with the file based and stream based CDR.
• A system-wide flag to select either CDR/streaming-based charging or Rf-interface based charging.
• Base diameter towards Rf Interface.
• Diameter node support of Rf application along with the existing Rx application. The Diameter node uses "Route Table" to find peer for outbound request based on destination realm and application.

Rf Interface is configured with the following steps:

1. Configure Diameter Node–Configure Diameter host configuration (SBC) stating primary and secondary origin host, plus IP Interface Group and the IP Address used by the Node to create connections towards peer.

   % set addressContext <addressContextName> diamNode <diamNodeName> primaryOriginHost <primaryOriginHostName> secondaryOriginHost <secondaryOriginHostName> ipV4Address <ipV4AddressName> ipV6Address <ipV6AddressName> originRealm <originRealmName> transactionTimeout <timeOut> ipInterfaceGroupName <ipInterfaceGroupName>

2. Configure Diameter peers–Rf servers that are used as CDF are configured as Diameter Peers, including IP address, FQDN name, and TCP port.

    % set addressContext <addressContextName> diamNode <diamNodeName> peer <peerName> fqdn <fqdn Name> ipAddress <ipAddress> tcpPort <tcpPortName> state enabled

3. Configure Realm routes for this Diameter Node–Identify the Realm FQDN of this route and the Peer to which the Realm belongs.

   % set addressContext <addressContextName> diamNode <diamNodeName> realmRoute <realmRoute> realm <RealmFqdn> peer <peerName> state enabled

Use the global signaling Diam Sig Controls object to configure global diameter signaling controls such as enabling the Rf Accounting application at the system level to send accounting information over Rf Interface. See Signaling - CLI for configuration details.

Charging Trigger Function

The Charging Trigger Function (CTF) generates charging events based on the observation of network resource usage. In every network and service element that provides charging information, the CTF is the focal point for collecting the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the Charging Data Function. The CTF is therefore a mandatory, integrated component in all network elements that provide off-line charging functionality.

CTF is comprised of two functional blocks:

Accounting Metrics Collection

This process exhibits the following behavior:

• Monitors signaling functions for calls, service events or sessions established by the network users
• Handles user traffic for these calls, service events or sessions
• Service delivery to the user via these calls, service events or sessions.

Metrics are included to identify the user and the user's consumption of network resources and/or services in real-time. The exact behavior and functionality of this process involves following depending upon functions / services that the NE provides. The Account Metrics Collection can therefore be considered as the network element dependent part of the CTF.

• trigger conditions for collection of charging information,
• information elements to collect,
• which service events, signaling or user traffic to monitor,
• relationship to services/bearers/sessions.

Depending on implementation choice, NE functions (for example, the handling of service events or signaling/user traffic) are distributed among multiple physical “devices” within the NE. To capture the required charging information from the service events or signaling/user traffic, the design of the Accounting Metrics Collection must match the physical design / distribution of these functions within the NE (In other words, the Accounting Metrics Collection becomes a distributed functionality itself).

Accounting Data Forwarding

This process receives the collected accounting metrics and determines the occurrence of chargeable events from a set of one or more of these metrics. It then assembles charging events that match the detected chargeable events, and forwards the charging events towards the Charging Data Function via the Rf reference point. The charging events provide information pertinent to the chargeable event, that is, characterizing the network resource usage together with an identification of the involved user(s). There is no assumption of any synchronization between the reception of individual accounting metrics; however, it must be possible for the Accounting Data Forwarding to complete its overall functionality per charging event in real-time.

While the exact information received by the Account Data Forwarding from the Account Metrics Collection, and the relevant chargeable events, are specific to each type of network element, the overall functionality of receiving, assembling and forwarding the charging information can be considered generic. Hence the Accounting Data Forwarding is considered the NE independent part of the CTF.

Charging Data Function

The Charging Data Function (CDF) receives charging events from the Charging Trigger Function via the Rf reference point. It then uses the information contained in the charging events to construct CDRs. This procedure is characterized by the following conditions:

• CDRs may be constructed from single charging events, that is, a 1:1 relation between event and CDR.
• CDRs may be constructed from a set of several charging events, that is, a n:1 relation between event and CDR.
• Each charging event is used for exactly one CDR, that is, a 1:n relationship between event and CDR (with n>1) is not possible.
• Multiple charging events that are used to create a single CDR may not necessarily be of the same type.
• There is no requirement or assumption of any synchronization between the reception of the charging event(s) and the creation of the resulting CDR. However, the CDF is capable of receiving and processing charging events and generating the resulting CDR in near real-time.
• The relationship between CDF and CTF may be 1:1 (integrated CDF) or 1:n (separated CDF). This includes the possibility of NEs of different types feeding charging events into the same CDF.
• All charging events used to build a CDR must originate from the same NE, that is, there is no cross-NE or cross-NE-type correlation of charging events in the CDF.

The results of the CDF tasks are charging data records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain / subsystem / service in the related middle tier charging specifications.

Charging Gateway Function

The CDRs produced by the CDF are transferred immediately to the Charging Gateway Function (CGF) via the Ga reference point. The CGF acts as a gateway between the 3GPP network and the Billing Domain. It uses the Bx reference point for the transfer of CDR files to the BD. The entity relationship between the CDF and the CGF is m:1, that is, one or more CDFs may feed CDRs into a single CGF. The CGF comprises the following main functions:

• CDR reception from the CDF via the Ga reference point in near real-time. The protocols that may cross the Ga reference point are specified in 3GPP TS 32.295 [54].
• CDR preprocessing:
  
  • Validation, Consolidation and (Re-) Formatting of CDRs.
  • CDR error handling.
  • Persistent CDR storage.
• CDR routing and filtering, that is, storing CDRs on separate files based on filtering criteria such as CDR type, CDR parameters, originating CDF, and so on.
• CDR File Management, for example, file creation, file opening / closure triggers, file deletion.
• CDR file transfer to the BD.

Offline Charging Functionality

Off-line charging functionality is based on the network elements reporting accounting information upon reception of various messages which trigger charging generation, as most of the accounting relevant information is contained in these messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [start, interim, stop, and event] from the network elements to the CDF.

Off-line charging is classified into following types.

• Session-based charging (types START, INTERIM, STOP).
• Event-based charging (type EVENT) for OOD SUBSCRIBE, REFER, NOTIFY, REGISTER, OPTIONS, MESSAGE and PUBLISH.

ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. The SBC sends the START and STOP records if Rf accounting is enabled. SBC sends available charging information as per Rf interface specifications.

In contrast, EVENT accounting data is unrelated to sessions, and is used for example, for a simple registration or interrogation or successful service event triggered by a network element or unsuccessful session establishment attempts.

The Accounting Request (ACR) and Accounting Answer (ACA) as specified in the Diameter Base Protocol Accounting (DBPA) application are the messages used for off-line charging.

Offline charging can be operator-configurable in the nodes for which SIP messages an Accounting Request is sent. The following table lists all possible ACRs that might be sent from a P-CSCF, I-CSCF, S-CSCF, MGCF, or BGCF.

Table 1: SBC Handling of Diameter Messages

Supported Attribute-Value Pairs (AVPs)

The following AVPs are supported for Rf interface:

Table 2: Rf Interface Supported Attribute-Value Pairs

For more information on AVPs, refer to the following 3GPP documents at

• 3GPP TS 32.299
• 3GPP TS 32.260

Impact to Ingress and Egress Protocol Variant Specific Field Descriptions

If the Rf flag is enabled, both Ingress and Egress Protocol Variant Specific data contain the following additional information related to Rf.

• Node Functionality: whether P-CSCF or IBCF
• Role of Node: Originating or Terminating
• usePcfaCcf: Flag whether to use ccf in P-Charging-Function-Address

Figure 2: Accounting Records Summary for call-specific records