ACR Event Records
The OCSBC supports ACR [Event] records, according to 3GPP TS 32.260. This is in addition to start, stop and interim records. These records reflect a preset type of SIP event. The ACRs are then sent to the CCF.
The OCSBC can create Event ACR messages on REGISTER, local-re-REGISTER and/or Short Message Service (SMS) message requests. A local re-register is when registration caching is enabled and the REGISTER from an currently registered endpoint occurs before half of the registration expiration time. In such cases the OCSBC sends a 200 OK to the re-registering endpoint and does not forward the re-REGISTER to the registrar. A message is an SMS event, on which the OCSBC collects critical RF information.
Event record creation is enabled with the generate-event parameter in the account config. This parameter can be set to register, local-register, message or any combination of all three values. The configured value(s) indicates the type of message that initiates an event ACR message sent to a CCF. Register only prompts the OCSBC to create Event ACRs at a REGISTER. Local-register prompts the OCSBC to create Event ACRs on a re-REGISTER that was replied to by the OCSBC. Message prompts the OCSBC to create EVENT ACRs sending information on SMS traffic within STOP records.
Event messages are created when the OCSBC receives a SIP Final Response 2xx or SIP Final Response (4xx or 5xx), that indicates an unsuccessful REGISTER.
Event ACR messages are also generated to indicate there has been an unsuccessful session attempt. Upon receiving a 4xx, 5xx or 6xx response to a SIP Invite, an Event message is created.
ACR Event Message Construction
An Event ACR is generated according to the tables that describe the AVPs present in the OCSBC’s ACR message. Refer to the checked items in the Event column to see all included AVPs. Note that the Accounting-Record-Type AVP (480) is set to Event_Record (1).
Event-Type AVP
The Event-Type AVP (AVP code 823) is a Grouped AVP and contains information about the type of chargeable telecommunication service/event for which the accounting-request and/or credit control request message(s) is generated.
It is used in an AAR Event record. In this context, refer to the following:
| AVP | Number | Acme # | Definition |
|---|---|---|---|
| [ SIP-Method ] | 824 | 173 | Contains the name of the SIP Method. Values
include REGISTER or MESSAGE (for SMS).
These generate an accounting request to the CCF. |
| [ Event ] | 825 | 245 | Holds the content of the "Event:" header.
This is not present in a REGISTER or re-REGISTER message |
| [ Expires ] | 888 | 246 | Holds the content of the "Expires" header.
Upon a re-REGISTER this value is the time remaining until the endpoint’s registration expires. |
The OCSBC generates additional information for SMS and distributes the information within the SIP-Method grouped AVP.
Expires Value
A refresher on the expires value: If the Contacts: header does not contain an expires parameter, the OCSBC adds one with the value in the Expires: header in the 200 OK returned to the UA who sent the INVITE. If there is no Expires: header, the OCSBC adds expires parameter with a value of 3600 and an Expires header with a value of 3600 to the 200 OK.
As the OCSBC forwards the final 200 OK to the initiating endpoint, the Expires (888) AVP contains the largest expires value of all expires parameters in Contact: headers.
When registration caching is enabled and the OCSBC receives a reREGISTER from an endpoint before the halftime of the local registration has expired, the OCSBC inserts the maximum of all associates contacts’ remaing time until expiry in the Expires AVP.
Event ACRs Generated for Unsuccessful Session Attempts
When any of the following responses are received in response to a SIP Invite, an Event ACR message is created to indicate there has been an unsuccessful session attempt:
- 4xx Request Failure Code — this code is used when the SIP transaction is terminated due to an IMS node receiving a 4xx error response.
- 5xx Server Failure Code — this code is used when the SIP transaction is terminated due to an IMS node receiving a 5xx error response.
- 6xx Global Failure Code — this code is used when the SIP transaction is terminated due to an IMS node receiving a 6xx error response.
This example call flow shows how a 5xx server failure results in the sending of an Event ACR.
Call Flow Example Showing Event ACR Generation Due to 5xx Server Failure
The following call flow example shows two session agents. The first session agent replies with 503, which results in an Event ACR with cause code 503. The second session agent replies with 200OK that causes the sending of a Start ACR. The generate-start parameter is OK.
Call Flow Example Showing Sending of an Event and Start ACR
This example call flow illustrates the same call flow when generate-start are equal to Invite. In this case, Start, Interim and Stop ACRs are sent. The generate-start parameter is OK.
Call Flow Example Showing Generation of Event ACRs Due to 5xx Server Failures
This example call flow shows how a session is created and a Start ACR is sent but then a 5xx server failure occurs that results in sending an Interim ACR. The generate-start parameter is Invite.
Call Flow Example Showing Sending of Start and Interim ACRs
This example call flow shows how the SD rejects a call before a session is created. When the enhanced-cdr option is not set, an Event ACR is then sent.
Call Flow Example Showing Unsuccessful Session Creation and Sending of a Event ACR
Event ACRs Generated for Receipt of SIP Messages
An Event ACR is issued when the following SIP messages are received:
- 200 OK message for a SIP Register from the IMS core.
- SIP Final/Redirection Response 3xx
- SIP Final Response (4xx, 5xx or 6xx) — this indicates an unsuccessful session-unrelated procedure.
- SIP Final Response (4xx, 5xx or 6xx) — this indicates an unsuccessful SIP session set-up.
This example call flow shows an Event ACR that is created due to the reception of a 3xx SIP message. In this example the call fails after being redirected.
Event ACR Created Upon Reception of a 3xx Message Followed by Call Failure After Redirect
This example call flow shows an Event ACR that is created due to the reception of a 3xx SIP message. Then it shows a Start ACR upon reception of a 200OK. In this example the call succeeds after being redirected. The generate-start is OK.
Event ACR Created Upon Reception of a 3xx Message Followed by Call Success After Redirect
This example call flow shows a Start ACR being sent when an Invite is received and an Interim ACR that is created due to the reception of a 3xx SIP message. In this example the call succeeds after being redirected. The generate-start is Invite.
Event ACRs for SMS
The OCSBC generates call data event records with information for SMS that differs somewhat from that of calls. You configure the OCSBC to generate ACRs for SMS using the same procedures you use for calls, which then treats the SMS messages as events, similar to call data during registrations.
End stations send SMS messages using a SIP MESSAGE (content-type=application/vnd.3gpp.sms) with a GSM-SMS body. The OCSBC complies with 3GPP specifications 23.040 (Technical realization of the Short Message Service (SMS) and 24.011 Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface) with respect to message format. The OCSBC parses message information for AVP data during message processing and ultimately provides ACRs to the CCF using the Rf interface.
SMS processing that includes ACR generation includes a separate timer, the sms-report-timeout within the sip-config, for SMS accounting. If the OCSBC does not receive a delivery report /submit report within this timer's value, it discards all accounting for that message. The diagrams below present the start and stop locations of this timer within the context of overall ACR generation.
The call flow diagram below illustrates the OCSBC, as P-CSCF, gathering data for the SMS report during a message originating scenario. The OCSBC ultimately issues the ACR after the message delivery is complete.
The call flow diagram below illustrates the OCSBC, as P-CSCF, gathering data for the SMS report during a message terminating scenario.
VoLTE Call and SMS AVPs for Diameter
The OCSBC issues custom AVPs that capture VoLTE and SMS information within ACRs. These are in addition to the common AVPs for all traffic. The process for VoLTE calls is the same as all other calls. For SMS, the process is different given that the message is an event, and the data recorded on the message equates to what is recorded for a call session.
The table below identifies AVPs specific to VoLTE and SMS traffic.
| AVP | ACME Diameter Attribute | Start | Interim | Stop | Event = MESSAGE | AVP Type |
| Pgw-IP | 95 | Y | Y | Y | N | UTF8String |
| Sgw-IP | 96 | Y | Y | Y | N | UTF8String |
| IMEI | 97 | Y | Y | Y | Y | UTF8String |
| IMSI | 98 | Y | Y | Y | Y | UTF8String |
| History-Info | 99 | Y | Y | Y | N | UTF8String |
| Sms-Msg-Type | 100 | N | N | N | Y | UTF8String |
| Sms-called party-Number | 101 | N | N | N | Y | UTF8String |
| Sms-calling party-Number | 102 | N | N | N | Y | UTF8String |
| Sms-Msg-Length | 103 | N | N | N | Y | Unsigned32 |
Diameter AVPs for VoLTE Calls
The OCSBC sends an ACR to the PCRF for call accounting with the following VoLTE-specific AVPs. The table shows all mandatory and optional AVP's. If there is data, the OCSBC includes Optional AVPs. If not the OCSBC does not include them.
| AVP Name | AVP Code | Is grouped ? Group hierarchy | Type |
| Access-Network-Information | 1263 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Access-Network-Information ] |
String |
| IMS-Visited-Network-Identifier | 2713 | Yes
[ACR] | [Service-Information] | [IMS Information] | [IMS-Visited-Network-Identifier] |
String |
| Originating-IOI | 839 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Inter-Operator-Identifier] | [Originating-IOI] |
String |
| Terminating-IOI | 840 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Inter-Operator-Identifier] | [Terminating-IOI] |
String |
In addition, the OCSBC sends the following fields as custom AVP's in the ACR.
| IMSI | 98 | UTF8String |
| IMEI | 97 | UTF8String |
| History-Info | 99 | UTF8String |
| PGW-IP Address | 95 | UTF8String |
| SGW-IP Address | 96 | UTF8String |
Diameter AVPs for SMS Messages
The OCSBC sends an ACR to the PCRF for MESSAGE accounting with the following SMS-specific AVPs. The table shows all mandatory and optional AVP's. If there is data, the OCSBC includes Optional AVPs. If not the OCSBC does not include them.
| AVP Name | AVP Code | Is grouped ? Group hierarchy | Type |
| Session ID | 263 | No | String |
| Origin Host | 264 | No | String |
| Origin Realm | 296 | No | String |
| Destination Realm | 283 | No | String |
| Origin State ID | 278 | No | Unsigned Int |
| Accounting record Type | 480 | No | Enum |
| Accounting-Record-Number | 485 | No | Unsigned Int |
| Accounting App ID | 259 | No | Unsigned Int |
| Event Timestamp | 55 | No | Time |
| Service Context ID | 461 | No | String |
| Subscription-Id-Type | 450 | Yes
[ACR] | [Service-Information] | [Subcription ID] | [Subscription-Id-Type] |
Enum |
| SIP-Method | 824 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Event-Type ] | [SIP-Method] |
String |
| Role-Of-Node | 829 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Role-Of-Node] |
Enum |
| Node Functionality | 862 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Node Functionality] |
Enum |
| SIP-Request-Timestamp | 834 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Timestamp ] | [SIP-Request-Timestamp] |
Time |
| SIP-Response-Timestamp | 835 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Timestamp ] | [SIP-Response-Timestamp] |
Time |
| SIP-Request-Timestamp-Fraction | 2301 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Timestamp ] | [SIP-Request-Timestamp- Fraction] |
Unsigned Int |
| SIP-Response-Timestamp-Fraction | 2302 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Timestamp ] | [SIP-Response-Timestamp-Fraction] |
Unsigned Int |
| Access-Network-Information | 1263 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Access-Network-Information ] |
String |
| IMS-Visited-Network-Identifier | 2713 | Yes
[ACR] | [Service-Information] | [IMS Information] | [IMS-Visited-Network-Identifier] |
String |
| Originating-IOI | 839 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Inter-Operator-Identifier] | [Originating-IOI] |
String |
| Terminating-IOI | 840 | Yes
[ACR] | [Service-Information] | [IMS Information] | [Inter-Operator-Identifier] | [Terminating-IOI] |
String |
In addition, the OCSBC sends the following fields as custom AVP's in the ACR.
| IMSI | 98 | UTF8String |
| IMEI | 97 | UTF8String |
| SMS MSG Type | 100 | UTF8String |
| SMS Calling party number | 102 | UTF8String |
| SMS Called party number | 101 | UTF8String |
| Message Length | 103 | Unsigned32 |
Distinct VoLTE Processes
For VoLTE calls, the process for generating CDRs is the largely the same as for other calls. As described, there are additional data points included for these call types.
In addition, the list below presents additional processes reserved for VoLTE data management with which you should be familiar:
- When there is an SRVCC event, the OCSBC creates a separate set of CDRs for the handover session. The OCSBC correlates the original and handover session using the "Generic-ID" field, which points to the Call-ID of the initial session. In addition, the OCSBC populates the Generic-ID field within the Initial Session CDRs (STOP), with the HO session Call-ID.
- The
OCSBC copies the Call id
of the second INVITE (Handover INVITE) into the Generic Id into the CDR for the
first INVITE (initial call) for both MO and MT call
- For mobile originating call—When the OCSBC receives the 200 Ok for the BYE from UE, it inserts the Call id of second INVITE, which is generated from the MSC-S as Generic Id, into the CDR of First MO Invite (Before the handover call).
- For mobile terminating call—When the OCSBC receives the 200 Ok for the BYE from UE, it inserts the Call id of the second INVITE, which is generated from the MSC-S as Generic Id, into the CDR of the first MT INVITE (before the handover call).
- If there is a negative case, such as a BYE timeout, the OCSBC writes the Call id of second INVITE, which is generated from the MSC-S as the Generic Id, into the CDR of the first INVITE (before the handover call) when that corresponding call gets terminated.
Note:
The OCSBC performs these same processes for both RADIUS accounting when generating CDRs and Diameter accounting when generating ACRs.Configurations to Specify VoLTE and SMS Data
You can configure the OCSBC to use specific data in call data records provided over RADIUS, Diameter and within local CSVs. This ensures that the specified fields
There are two configurations available for specifying VoLTE and SMS data:
- Subscribe to IP-CAN-CHANGE events
- Specify Inter-Operator Identifier (IOI)
Subscribe to IP-CAN-CHANGE Events
You can configure a subscription to the IP-CAN-CHANGE event using the Rx interface during the AAA/RAR exchange. To do this, you configure the ip-can-change value to the specific-action-subscription of the applicable ext-policy-config. This causes the OCSBC to apply the value in the AN-GW-Address AVP from the PCRF as the S-GW IP address.
Note:
If the OCSBC receives more than one AN-GW-Address AVP from the PCRF, it applies the value in the AN-GW-Address AVP from the PCRF. It also uses the S-GW IP address the first AVP as the S-GW IP address.Option to Specify IOI
You configure the realm-as-ioi option in the applicable account-config to send the realm name as the IOI in diameter ACRs. If this option is not set, the OCSBC uses the IOI from the charging vector.
Configure this option using the syntax below.
ORACLE(account-config)# options +realm-as-ioiIf you type options and then the option value without the plus sign, you overwrite any previously configured options. To add a new option to an options list, pre-pend the new option with a plus sign as shown in the previous example.
Configuring the ip-can-change Subscription
You use the steps below to Subscribe to IP-CAN-CHANGE events at the PCRF and apply the value in the AN-GW-Address AVP from the PCRF as the S-GW IP address.
Event Local CSV File
This feature also creates an Event CSV file when the generate-event parameter is enabled. The following table describes the inclusive CSV element order:
| CSV Placement | Attribute Name | AVP Number |
|---|---|---|
| 1 | Record Type | 480 |
| 2 | NAS IP Address | |
| 3 | NAS Port | 16 |
| 4 | Calling Station ID | |
| 5 | Called Station ID | |
| 6 | Diameter Session ID | 263 |
| 7 | SIP Method | 824 |
| 8 | Event Time | 55 |
| 9 | User Name | 1 |
| 10 | Node Function | 862 |
| 11 | Application ID | 259 |
| 12 | Role Node | 829 |
| 13 | Event | 825 |
| 14 | Expires | 888 |
| 15 | Associated URI | 856 |
| 16 | Cause Code | 861 |
| 17 | CDR Sequence Number | |
| 18 | Origin Realm | 296 |
| 19 | Origin Host | 264 |
| 20 | Destination Realm | 283 |
| 21 | Destination Host |
The OCSBC generates a different CSV for message events, triggered by SMS traffic. This layout is presented in Appendix B.