DEFINICIONES

OFFLINE CHARGING FOR IMS 113

In the above steps, when the P-CSCFs (P-CSCF1 and P-CSCF2) receive the SIP messages from the MSs (MS1 and MS2), they send the SDP parameters to the Policy Decision Function (PDF). The PDF then authorizes the related media parameters according to the users’ media requirements and the local policy. Details of the PDF will be elaborated in Section 9.4. After authorization, the authorized media parameters are returned to the MS and the resources for setting up the transmission bearer are reserved. The PDF forwards the related IP QoS control parameter to the GGSN. To execute the QoS control policy, the GGSN analyzes the source and destination IP addresses. Then it controls and filters the IP flow following the UMTS R6 and R7 specifications to be described in Chapter 9.

Step 7. [Figure 7.3(a)] Upon receipt of the 200 OK response, P-CSCF2 sends an ACR message to CCF4, S-CSCF2 sends an ACR message to CCF2, S-CSCF1 sends an ACR message to CCF1, and P-CSCF1 sends an ACR message to CCF3. These ACR messages include the Accounting-Record-Type “start’’ to indicate that the CDRs are opened for an IMS call session. The CCFs create the related CDRs (i.e., S-CSCF CDRs and P-CSCF CDRs) and reply with the ACA messages.

Step 8. [Figure 7.3(b)] When the call is terminated, P-CSCF1, S-CSCF1, P-CSCF2 and S-CSCF2 send the ACR messages with Accounting-Record-Type

“stop’’ to the corresponding CCFs for closing the CDRs. These CDRs are then transferred to the corresponding billing systems for offline processing.

A CSCF CDR (created in Figure 7.2(a) and Figure 7.3(a)) contains the following fields [3GP06a]:

• The Record Type field specifies the CSCF type (e.g., P-CSCF CDR or S-CSCF CDR).

• The Role of Node field indicates the role of the CSCF (either originating or terminat-ing) [3GP06b]. The originating nodes are the CSCFs (i.e., P-CSCF1 and S-CSCF1 in Figure 7.2) of the calling party (i.e., MS1). The terminating nodes are the CSCFs (i.e., S-CSCF2 and P-CSCF2 in Figure 7.2) of the called party (i.e., MS2).

• The Node Address field specifies the node providing the accounting information.

This address may be an IP address or a Fully Qualified Domain Name (FQDN) of the IMS node (i.e., the FQDN for P-CSCF1, P-CSCF-2, S-CSCF1 or S-CSCF2 in Figure 7.2).

• The Session ID field contains the call ID specified in the SIP message.

• The Calling and the Called Party Address fields specify the addresses (e.g., SIP Uniform Resource Locator (URL) or TEL URL) of the calling party (MS1) and the called party (MS2), respectively.

• The Served Party IP Address field contains the IP address of either the calling or the called party.

• The Service Request Time Stamp field indicates the time at which the service is requested.

• The Service Delivery Start/End Time Stamp field indicates the time when the IMS session is started/ released.

• The Record Opening/Closure Time field indicates the time when the CCF opens/closes the CDR record.

• The Local Record Sequence Number field includes a unique record number created by the IMS node.

• The (optional) Record Sequence Number field contains a running sequence number employed to link the partial records generated by the CCF.

• The Inter Operator Identifiers (IOIs) field holds the globally unique identifiers of home IMS networks for the calling and the called parties, respectively. More details about the IOI will be given in Section 7.2.

• The Cause for Record Closing field contains the reason for a CDR release. The reason can be “end of session’’, “service change’’, “CCF initiated record closure’’, and so on.

• The IMS Charging Identifier (ICID) field is a unique identifier generated by the IMS for the SIP session.

• The List of SDP Media Components field contains the SIP request timestamp, SIP response timestamp, SDP media components (i.e., SDP media name, SDP media description, GPRS charging ID (i.e., GCID)) and media initiator flag.

• The GGSN Address field specifies the control plane IP address of the GGSN.

In an IMS session, it is possible that the CCF generates multiple partial records due to changes of session characteristics (or changes of charging conditions). These events include tariff switching, QoS changed, or time (volume) limit exceeded. In this case, the Record Sequence Number field is used to link the partial records generated by the CCF.

7.2 IMS Charging Correlation

This section describes how IMS charging is integrated with the PS service domain char-ging described in Section 6.2. Several charchar-ging correlations exist in an IMS session, including:

• correlation between CDRs generated by different IMS nodes;

• correlation between CDRs generated by the GPRS support nodes and CDRs generated by IMS nodes; and

• correlation between CDRs generated by different operators.

IMS CHARGING CORRELATION 115

These charging correlations are described as follows:

The CDRs generated in the IMS nodes are correlated by an IMS Charging Identifier (ICID). This identifier is globally unique across all 3GPP IMS networks for a period of at least one month. Expiration of an ICID can be detected by using IMS node-specific information, e.g., high-granularity time information and location information. A new ICID is generated for an IMS session at the first IMS node that processes the SIP INVITE message. The ICID is included in all subsequent SIP messages (e.g., 200 OK, UPDATE, and BYE) for that IMS session until the session is terminated. For the example shown in Figure 7.2, an ICID is generated by P-CSCF1 for mobile-originated calls. The SIP request includes the ICID specified in the P-Charging-Vector header (see Section 5.6.2). This ICID is passed along the SIP signaling path to all involved IMS nodes. Each IMS node that processes the SIP request retrieves the ICID and includes it in the CDRs generated later. In a CSCF CDR, the ICID is listed in the IMS Charging Identifier field. Therefore, CDRs from different IMS nodes within an IMS session can be correlated in the billing system through the ICID.

In an IMS session, the media (e.g., voice or video) packets are transferred through the GPRS bearer session. The GPRS charging information (e.g., the GGSN address and the GCID) can be used to correlate the GPRS CDRs with the IMS CDRs. The GPRS charging information for a media session is included in the P-Charging-Vector header, and is passed from the GGSN to the P-CSCF (e.g., P-CSCF1 and P-CSCF2 in Figure 7.2). Note that the GPRS charging information for the originating network is used only within the originating network. Similarly, the GPRS charging information for the terminating network is used only within the terminating network. In the SIP signaling path, the GGSN address, the GCID and the ICID are passed from the P-CSCF to the S-CSCF and other IMS nodes. The S-CSCF also passes this information to the CCF. In a CSCF CDR, the related GCID is included in the List of SDP Media Components field.

As described in Section 5.6.2, charging correlation among different operators is achieved through the Inter Operator Identifier (IOI), a globally unique identifier shared between operator networks and service/content providers [3GP08]. With IOIs, the home IMS networks for both call parties can settle the account with each other.

The originating IOI and the terminating IOI are exchanged by the SIP request and response messages. The originating S-CSCF (e.g., S-CSCF1 in Figure 7.2) includes the originating IOI in the P-Charging-Vector header of the SIP request. In a CSCF CDR, the IOIs are listed in the Inter Operator Identifiers field. Upon receipt of the SIP message, the terminating S-CSCF (e.g., S-CSCF2 in Figure 7.2) retrieves the ori-ginating IOI of calling party’s home IMS network. It then includes the terminating IOI in the P-Charging-Vector header of the SIP response message. Through the SIP response message, the originating S-CSCF retrieves the terminating IOI of the called party’s home IMS network.

IMS also supports online charging capabilities through the OCS, where an IMS node or an application server interacts with the OCS in real time to access the user

accounts and controls the charges related to service usage. Details of the OCS and the online charging examples will be given in Chapter 8.

7.3 Multimedia Messaging Service Domain

In the R5 Multimedia Messaging Service (MMS) domain, CDRs generated from the MMS Relay/Server (Figure 7.1(j)) are transferred directly to the billing sys-tem (Figure 7.1(i)) for offline charging. MMS delivers multimedia objects including texts, images, audio and video. In the MMS architecture illustrated in Figure 2.9 (Section 2.3.3), the MMS charging records are generated by the MMS Relay/Server when it sends multimedia messages to the MMS User Agent (UA) or receives multi-media messages from the MMS UA [3GP04]. Several CDRs are generated in an MMS delivery. Figures 7.4 and 7.5 depict the MMS delivery procedure in the following steps [3GP05]:

Step 1. [Figure 7.4(a)] An MMS user agent (UA1) sends a multimedia message to another MMS user agent (UA2). The message (encapsulated in a WAP POST message) is first sent to the MMS Relay/Server. An Originator MM1 Submission Record (O1S-CDR) is created in the MMS Relay/Server.

Step 2. [Figure 7.4(a)] The MMS Relay/Server sends a notification message (encap-sulated in a WAP PUSH message) to UA2.

Step 3. [Figure 7.4(b)] After receiving the notification from the MMS Relay/Server, UA2 requests to receive the multimedia message through a WAP GET message.

Step 4. [Figure 7.4(b)] The multimedia message is sent to UA2 through the WAP GET response at Step 4(a). UA2 retrieves the message and acknowledges the MMS Relay/Server. A Recipient MM1 Retrieve Record (R1Rt-CDR) and a Recipient MM1 Acknowledgment Record (R1A-CDR) are created in the MMS Relay/Server at Step 4(b).

Step 5. [Figure 7.5(a)] Through the WAP PUSH message, the MMS Relay/Server informs UA1 that the multimedia message is delivered successfully. An Ori-ginator MM1 Delivery Report Record (O1D-CDR) is created at the MMS Relay/Server.

Step 6. [Figure 7.5(b)] After UA2 has received the multimedia message, it sends a WAP PUSH message to the MMS Relay/Server to indicate that the message is read. Then a Recipient MM1 Read-reply Recipient Record (R1RR-CDR) is created in the MMS Relay/Server.

Step 7. [Figure 7.5(b)] The CDRs generated in the previous steps are subsequently