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.
CTF: Charging Trigger Function
CDF: Charging Data Function
CGF: Charging Gateway Function
BD: Billing Domain. This may also be a billing mediation device/post-processing system.
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:
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.
Configure Diameter peers–Rf servers that are used as CDF are configured as Diameter Peers, including IP address, FQDN name, and TCP port.
Configure Realm routes for this Diameter Node–Identify the Realm FQDN of this route and the Peer to which the Realm belongs.
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 .
- 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.
In this release, SBC supports only event records for unsuccessful session 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.
IMS Node Triggering of SIP Methods / ISUP Messages
IMS Node sends ACR (Start) to Rf Accounting server when SIP 200 OK acknowledging an Initial SIP INVITE is received.
IMS Node sends ACR (Interim) to Rf Accounting server, when "Accounting Interim interval" for the session expires.
When "Acct-Interim-Interval" AVP is received from the AAA server in ACA message, SBC treats the value received as the "Accounting Interim interval" for the session.
When "Acct-Interim-Interval" AVP is NOT received from the AAA server in ACA message, SBC treats the default "Accounting Interim interval" value configured on the system as "Accounting Interim Interval" for the session.
|When "Acct-Interim-Interval" AVP is NOT received from the AAA server in ACA message and "Accounting Interim Interval" value configured on the system is '0', SBC does NOT send ACR (Interim) Message for the session.|
When "Acct-Interim-Interval" AVP is received from the AAA server in ACA message, SBC sends ACR (Interim) Message for the session based on the value received in "Acct-Interim-Interval AVP", irrespective of "Accounting interim interval" value configured on the system.
IMS Node sends ACR (STOP) with Cause-Code AVP (AVP code 861) to Rf Accounting server when session is terminated. (Session for which ACR (Start) was originally sent by the node).
|When an ongoing SIP session has been normally released either by the user or by the network (SIP BYE message initiated by the user or initiated by the network has been received by the IMS node after the reception of the SIP ACK message), SBC sends the ACR (STOP) as below.|
When the SIP session is not successfully established (that is, Timer H expires and SIP ACK is not received, or SIP BYE is received after reception of the 200 OK final response and SIP ACK is not received), SBC sends the ACR:
Cause-code AVP (AVP code 861) = "Unsuccessful session setup" 2
When the SIP session is terminated by the IMS node because of a system error (for example, system wide error or failure, crash, card failure) after session is established, SBC sends the ACR:
Cause-code AVP (AVP code 861) = "Unspecified error" 1
"Unspecified error" is used when Specific Cause-codes not defined. SBC sends "1" for any "Internal" or unspecified errors which cannot be mapped to any existing cause-codes.
IMS Node sends the ACR (EVENT) to Rf Accounting server to report a failed session attempt in following scenarios:
On the Rf interface there is no ACR (ATTEMPT) record type, ACR (EVENT) is used to report attempt records.
IMS Node sends the ACR (EVENT) to Rf Accounting server, to report a redirection of a session attempt in following scenario.
IMS Node sends the ACR (EVENT) to Rf Accounting server to report a redirection of a session attempt in following scenario.
IMS Node sends the ACR (EVENT) to Rf Accounting server to report non-session related SIP Message events on receipt of following messages.
When a successful transaction terminating the Registration dialog is detected by the IMS node, the node sends the ACR as below.
In the following scenarios:
When the SIP transaction is terminated due to an IMS node receiving/initiating a 3xx Final response, Node sends the ACR as below.
When the SIP transaction (INVITE or Non-INVITE transaction) is terminated due to an IMS node receiving/initiating a Failure response (that is, 4xx, 5xx, 6xx) error response, Node sends the ACR with appropriate Cause-code AVP (AVP code 861) value as below.
When the SIP transaction (INVITE or Non-INVITE transaction) is terminated due to an IMS node has internal or Unknown error (for example, error in processing a request/response), Node sends one of the cause codes in the ACR as below.
Transaction failures which do not map to previous requirements should be logged as Internal or Unknown errors. This is a catch-all cause-code.
When a successful transaction terminating the Subscription dialog is detected by the IMS node, the node sends the ACR with cause-code AVP (AVP code 861) = End of SUBSCRIBE dialog (-2).
On the Rf interface there is no ACR (ATTEMPT) record type, ACR (EVENT) is used to report attempt records
Supported Attribute-Value Pairs (AVPs)
The following AVPs are supported for Rf interface:
|Session-Id||263||This field identifies the operation session.|
|Origin-Host||264||This field contains the identification of the source point of the operation and the realm of the operation originator.|
|Origin-Realm||296||This field contains the realm of the operation originator.|
|Destination-Realm||283||This field contains the realm of the operator domain. The realm will be addressed with the domain address of the corresponding public URI.|
This field is of type "DiameterIdentity". This is present in all the unsolicited agent initiated messages, may present in request messages, and must not present in answer messages.
|Accounting-Record-Type||480||This field defines the transfer type that is, event for event based charging and start, interim, stop for session based charging.|
This field contains the sequence number of the transferred messages.
|Acct-Application-Id||259||The field corresponds to the application ID of the Diameter Accounting Application and is defined with the value 3.|
|User-Name||1||This field contains the user name determined by the domain that is, bearer, sub-system, or service as described in middle tier TS.|
|Acct-Interim-Interval||85||This field indicates the preferred intermediate charging interval value.|
This field contains the state associated to the CTF.
|Event-Timestamp||55||This field corresponds to the exact time the accounting is requested.|
|Route-record||282||This field contains an identifier inserted by a relaying or proxying node to identify the node from where the message is received.|
|Service-Context-Id||461||This field indicates the service and the corresponding "middle tier" TS.|
|Service-Information||873||This parameter contains the individual service specific parameters as defined in the corresponding "middle tier" TS.|
This field contains the Private User Identity and/or Public User Identity/Identities.
|876||This field allows the transmission of additional IMS service specific information elements.|
This field contains the SIP Method, the content of the SIP “Event” header, and the content of the SIP “expires” header when present in the SIP request.
|Node Functionality||862||This field contains the function of the node.|
|Role of Node||829||This field specifies whether the IMS node is serving the Originating or the Terminating party. The AVP "Role of Node" is used when SBC acts as P-CSCF and IBCF. The value of the "Role of Node" AVP is determined in SIPSG and sent to CAM through CC.|
|User Session ID||830||This field contains the session identifier. For a SIP session the Session-ID contains the SIP Call ID. When the AS acts as B2BUA, the incoming session is identified.|
|Calling Party Address||831||This field contains the address (SIP URI or TEL URI)URI of the party (Public User Identity or Public Service Identity) initiating a session or requesting a service.|
|Called Party Address||832|
For SIP transactions, except for registration, this field contains the address of the party (Public User ID or Public Service ID) to whom the SIP transaction is posted.
|Number-Portability-Routing-Information||2024||This field includes information on number portability after DNS/ENUM request from IMS node in the calling users' home network.|
|Requested Party Address||1251||For SIP transactions this field contains the address of the party (Public User ID or Public Service ID) to whom the SIP transaction was originally posted.|
This field is of type "Grouped" and contains the identification of the network neighbors (originating and terminating) as exchanged via SIP signaling if available.
|IMS Charging Identifier||841||This field contains the IMS Charging Identifier (ICID) as generated by an IMS node for a SIP session.|
|Early-Media-Description||1272||This field contains session and media parameters related to media components set to active during the SIP session establishment and before a final successful or unsuccessful SIP answer to the initial SIP INVITE request is received.|
|SDP-Media-Component||843||This is a grouped field comprising several sub-fields associated with one media component. As several media components may exist for a session in parallel, these sub-fields may occur several times. This AVP along with the core media attributes contain all the OMR attributes including visited-realm lines and other OMR attributes.|
|SDP-Session-Description||842||This field contains the content of an "attribute-line" (i=, c=, b=, k=, a=, etc.) related to a session. For Offer SDP, this AVP contains the connection information present in the c-line of the offer SDP received by SBC. For answer SDP, this AVP contains the connection information present in the c-line of the answer SDP sent out by SBC.|
|Served-Party-IP-Address||848||This field contains the IP address of either the calling or called party, depending on whether the P-CSCF is in touch with the calling or the called party.|
|Access-Network-Information||1263||This field contains the content of the P-header P-Access-Network-Info.|
|Result-Code||268||This field contains the result of the specific query.|
|Cause-Code||861||This field contains the cause code value from IMS node related to session termination.|
This field contains the timestamp of the SIP Request and the timestamp of the response to the SIP Request.
This field is used to identify the end user.
|SDP-Media-Name||844||This field contains the content of a "m=" line in the SDP data.|
|SDP-Media-Description||845||This field contains the content of an "attribute-line" (i=, c=, b=, k=, a=, etc.) related to a media component.|
This field indicates the party, which has requested the session modification.
|Media-Initiator-Party||1288||This field contains the address of the party who initiates the media action, like adding/removing, connecting/disconnecting the media.|
|SDP-Type||2036||This field contains information if the SDP media component is either SDP offer or SDP answer.|
|SDP-TimeStamps||1273||This field contains the time of the SDP offer and the SDP answer.|
|SDP-Offer-Timestamp||1274||This field contains the time in UTC format of the SDP offer.|
|SDP-Answer-Timestamp||1275||This field contains the time in UTC format of the response to the SDP offer.|
This field holds information about the NNI used for interconnection and roaming. This AVP is applicable only for IBCF. The following fields are present in this AVP:
The following fields are added in this AVP:
|Transit-IOI-List||2701||SBC sends "Transit-IOI-List" AVP in ACR [START, INTERMEDIATE, STOP, EVENT] messages over Rf interface. This is performed for both INVITE and non-INVITE messages. This is applicable to both P-CSCF and IBCF Rf messages. Multiple occurrences of this AVP are in chronological order, that is, the value in the SIP request is listed first followed by the values received in SIP responses. If only a value for the SIP response is available, the Transit-IOI-List for the SIP request are included with the value "unknown".|
|IMS-Communication-Service-Identifier||1281||SBC sends “IMS-Communication-Service-Identifier” AVP in ACR [START] messages over Rf interface. This is applicable for INVITE message. This holds the IMS Communication Service Identifier (ICSI) as contained in the P-Asserted-Service header of a SIP request. This is applicable to both P-CSCF and IBCF Rf messages.|
|From-Address||2708||SBC sends “From-Address” AVP in ACR [START, INTERMEDIATE, STOP, and EVENT] messages over Rf interface. This essentially covers both INVITE and non-INVITE messages.This includes the information from the SIP From header. This is applicable to both P-CSCF and IBCF Rf messages.|
|IMS-Emergency-Indicator||2322||SBC sends “IMS-Emergency-Indicator” AVP in ACR [START, INTERMEDIATE, STOP, and EVENT] messages over Rf interface. This indicates the IMS session as an IMS emergency session or IMS registration. This covers both INVITE and REGISTER messages. This is applicable only to P-CSCF Rf messages|
This field is of type "Grouped", which provides information on access transfer for IMS service continuity.
|This field is of type "Enumerated", which indicates the type of transfer occurred.|
This field is of type "UTF8String" and contains the address (Public User ID: SIP URI, E.164, and so on) of the finally asserted called party.
|SIP-Method||824||This field is of type "UTF8String" and contains the name of the SIP Method (INVITE, UPDATE, and so on).|
|Event||825||This field is of type "UTF8String" and contains the content of the "Event" header.|
This field is of type "Unsigned32" and contains the content of the "Expires" header.
This field is of type "Time" and contains the time in UTC format of the SIP request (for example, Invite, Update, and so on).
|SIP-Response-Timestamp||835||This field is of type "Time" and contains the time in UTC format of the response to the SIP request (for example, 200 OK).|
|IMS-Charging-Identifier||841||This field is of type "UTF8String" and contains the IMS Charging Identifier (ICID) as generated by an IMS node for a SIP session.|
|IMS-Visited-Network-Identifier||2713||This field carries P-Visited-Network-Id header value inserted by SBC in the outgoing REGISTER request.|
|SIP-Request-Timestamp-Fraction||2301||This field is of type Unsigned32 and holds the milliseconds fraction in relation to SIP-Request-Timestamp.|
|SIP-Response-Timestamp-Fraction||2302||This field is of type Unsigned32 and holds the milliseconds fraction in relation to SIP-Response-Timestamp.|
For more information on AVPs, refer to the following 3GPP documents at 3GPP web sitte:
- 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
FigureAccounting Records Summary for call-specific records
Max Length in
Ingress Protocol Variant Specific Data
|Egress Protocol Variant Specific Data||1849||Characters||55||69||59||51||68||STRING|
SBC may insert non-ASCII characters in CDRs when messages are parsed in the initial INVITE.