CHARGING ID CORRELATION IN AN IMS NETWORK

Abstract

In a method of correlating information relating to message in a SIP session, a first SIP message that includes a first IMS Charging Identifier, ICID, is received. The first SIP message is retargeted by generating a second SIP message that includes a second ICID. A reference to the first ICID is inserted into the second SIP message. Information relating to the first SIP message is correlated with information relating to the second SIP message based on the first ICID and the reference to the first ICID in the second SIP message.

Description

TECHNICAL FIELD

The present invention relates to correlation of the use of a charging identifier (ICID) in an IP Multimedia Subsystem (IMS) telecommunications network.

BACKGROUND

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or between subscriber terminals and IMS network entities such as application servers). Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.

FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The Serving CSCF (S-CSCF) handles the provision of services to the user, while Application Servers (ASs) implement the IMS service functionality. Application Servers may be connected either as session end-points or “linked in” to a session by an S-CSCF. The S-CSCF is a SIP server, but performs session control as well, handles SIP registrations, and is in the path of all signaling messages, so that it can inspect every message in a session. It decides to which AS(s) the SIP message will be forwarded for the provision of services and it provides routing services.

The charging mechanisms for IMS sessions are either offline (post-paid) charging, using accounting messages, or online (pre-paid) charging, using credit control messages and procedures. For off-line charging the various IMS network entities that handle transactions act as charge triggering functions (CTFs) generating charging information which is sent to a Charging Data Function (CDF) over an Rf interface. For on-line charging, the IMS network entities communicate with an Online Charging System (OCS) over the Ro interface. The information collected by the CDF/OCS can then be used in whatever way the operator sees fit. The information collected in this way is categorized as charging information, but in fact it can be information relating to things other than charging (billing), such as a form of Deep Packet Inspection (DPI), statistics, security, traffic monitoring, etc. The following discussion and illustrative examples use offline charging, but the principles apply equally with regard to online charging.

In general SIP signals are directed between a pair of end points. In other words the address information provided by the sender in the signal header specifies the recipient end-point (e.g. in the form of a recipient uniform resource identifier, R-URI), and the signal is routed over the network to that end-point. However, there are a number of situations in which SIP signals are re-targeted to a different end-point. Examples of IMS services that involve retargeting include Communication Diversion (CDIV), Do Not Disturb, Communication Distribution, Flexible Alerting, and Conference.

For example, the 3GPP technical specification TS 24.604 Communication Diversion defines how a user B that receives a communication (SIP INVITE) or message (SIP MESSAGE) is able to divert the communication to a new target, C. This is shown in FIG. 2, where a SIP INVITE 101 is sent from an entity in an originating network 10 towards user B. The IMS network serving user B includes a S-CSCF 12 assigned to user B and an AS 14 providing a CDIV service. There is also a Charging Data Function 16. The S-CSCF 12 forwards the SIP INVITE 102 to B's terminating AS 14, which triggers 103 the CDIV to retarget the SIP INVITE to C. C is a user, or other entity in a terminating network 18. The CDIV procedure involves B's terminating AS 14 sending a new SIP INVITE 104 towards user C. The R-URI is changed by B's terminating AS 14 so that the S-CSCF 12 routes the SIP INVITE 105 towards C's terminating network 18.

When B's terminating AS 14 creates the new call leg on behalf of B—e.g. at Call Diversion—it generates a new IMS Charging Identifier (ICID) for the new call leg towards C. The new ICID value (icidB) is generated and placed in the P-Charging-Vector (PCV) header of the outgoing SIP INVITE 104. When this has been received, as acknowledged by the exchange of SIP 200 OK messages 106, 107, B's terminating AS 14 also uses the new ICID in an Accounting Request message (ACR) 108 sent to the CDF 16. The process is completed by the return of SIP 200 OK and acknowledgement (ACK) messages 109-115 between the entities.

FIG. 3 illustrates the procedure where ASs are chained. In other words services are being provided to user B by more than one AS. These services may include user B's originating services, such as Outgoing Communication Barring (OCB) for example, provided by B's originating AS. These originating services may be run after the CDIV service has been implemented by B's terminating AS 14. Alternatively, the operator may select to run B's originating services in B's originating AS by sending the retargeted INVITE to the S-CSCF, which then sends the retargeted INVITE to B's originating AS to perform B's originating services, such as OCB. Thus, in addition to the entities shown in FIG. 2 and described above, there is an originating AS 20 serving user B. At steps 201 to 204, B's terminating AS 14 creates a new INVITE towards C, as described above for FIG. 2 steps 101-104. However, in this scenario, the new call leg triggers originating services provided by B's originating AS 20. Thus, B's S-CSCF 12 sends the SIP INVITE 205 initially to B's originating AS 20, and only after it is returned 206, forwards it 207 to C's terminating network 18.

The SIP INVITE includes a P-Served-User header, PSU, which is inserted by B's S-CSCF 12, and is used by B's originating AS 20 to identify the served user because the R-URI in the INVITE is directed to C, and the P-Asserted-Identity is pointing at A. After communications are established, as indicated by the return of 200 OK messages 208, 209, B's originating AS 20 can send an ACR 210 to the CDF 16. This will include the ICID icidB that was included by B's terminating AS 14 in the INVITE 205 and in the INVITE 206 received at B's originating AS 20. The procedure is then completed with the exchange of acknowledgement/200 OK messages 211-221.

B's originating AS 20 does not have access to the received ICID (icidA in FIG. 3) in the original INVITE 201. As a result, B's originating AS 20, when sending the ACR 210 providing charging data to the CDF 16, is unable to provide information that would enable the CDF 16 to correlate the charging data with the original SIP INVITE from A.

Note that in the FIG. 2 scenario, it is possible that B's terminating AS 14 could be configured with the capability to include the ICID (icidA) from the INVITE 102 received by B as a cross-reference (Related icid) in the ACR 108. However, for the FIG. 3 scenario this would not be possible, as B's originating AS 20 has not seen the original INVITE 202.

Thus, in situations where a new call leg is generated by an AS (or other network entity that performs a retargeting function) it is not always possible to correlate the charging information generated by the network entities serving the as they do not have access to the ICID value of the previous call leg.

Also, the ICID may be used for other purposes than just charging. For example, the ICID may be used in network tracing as the common identifier of a SIP session through the complete network. However, where there has been a retargeting it is not possible to correlate the leg between A and B with the leg between B and C because the ICID has changed when B's terminating AS has triggered a retargeting service such as CDIV.

SUMMARY

According to a first aspect, there is provided a method of correlating information relating to messages in a SIP session. A first SIP message that includes a first IMS Charging Identifier, ICID, is received. The first SIP message is retargeted by generating a second SIP message that includes a second ICID. A reference to the first ICID is inserted into the second SIP message. Information relating to the first SIP message is correlated with information relating to the second SIP message based on the first ICID and the reference to the first ICID in the second SIP message.

Embodiments also provide that the same procedure is adopted for multiple retargeting of the SIP message, whereby each retargeted SIP message has a reference to the ICID of the previous SIP message inserted. It is an advantage that the referenced ICIDs carried by retargeted SIP messages can be used to correlate the charging information for all call legs generated for the served user.

According to a second aspect there is provided an IMS network entity configured, on receiving a first SIP message directed to a served user and containing a first ICID, to retarget the message by generating a second SIP message containing a second ICID and to include a reference to the first ICID in the second SIP message.

According to another aspect there is provided an IMS network entity configured to receive a message from another IMS network entity. The message comprises information relating to a SIP session and references to a plurality of associated ICIDs. The IMS network entity is configured to correlate the information with information received in other messages that comprise references one or more of the same ICIDs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically the integration of an IP Multimedia Subsystem into a 3G mobile communications system;

FIG. 2 is a signal diagram illustrating a retargeting operation triggered by a Communication Diversion service in accordance with current procedures;

FIG. 3 is a signal diagram illustrating a retargeting operation triggered by a Communication Diversion service involving chained application servers in accordance with current procedures;

FIG. 4 is a signal diagram illustrating a retargeting operation triggered by a Communication Diversion service involving chained application servers in accordance with an embodiment described herein;

FIG. 5 is a flow diagram illustrating steps that are carried out in accordance with embodiments described herein.

DETAILED DESCRIPTION

FIG. 4 depicts the same CDIV operation involving chained application servers as shown in FIG. 2 and described above. At steps 301 to 303, an INVITE is received at B's terminating AS 14, as described above for FIG. 2 steps 101-103 and FIG. 3, steps 201-203. This triggers the CDIV function 303, and so B's terminating AS 14 retargets the INVITE by generating a new SIP INVITE 304 towards C. In addition to including the ICID icidB, B's terminating AS now also includes an originating ICID parameter, orig-icid, which is a reference to the ICID, icidA in the original INVITE received. Note that the orig-icid parameter is not itself an ICID of the SIP INVITE, as it is not specified in the ICID field (which now specifies icidB as the ICID). Now the INIVITEs 305 and 306 forwarded to and returned from B's originating AS 20 also include the orig-icid parameter, as does the INVITE 307 sent to C's terminating network.

However, in this scenario, the new call leg triggers originating services provided by B's originating AS 20. Thus, B's S-CSCF 12 sends the SIP INVITE 205 initially to B's originating AS 20, and only after it is returned 206, forwards it 207 to C's terminating network 18. After communications are established, as indicated by the return of 200 OK messages 308, 309, B's originating AS 20 can send an ACR 310 to the CDF 16. This will include not only the ICID icidB that was included by B's terminating AS 14 when it generated the INVITE 304, but also the orig-icid, icidA, that was also inserted by B's terminating AS 14 into the INVITE 304. The procedure is then completed with the exchange of acknowledgement/200 OK messages 311-321.

Accordingly, every time a network entity (e.g an AS) retargets a message, it not only includes the new ICID (icidB in the examples above) but also includes an orig-icid parameter that contains a reference to the original ICID (icidA) of the original message. This original ICID can then be inserted in the generated charging information for correlation purposes.

For a call that undergoes multiple retargeting (i.e. multiple diversions), the icid-value in the received message is used as the orig-icid value in the new outgoing message (the old orig-icid value in the received message is discarded) while a new icid-value is generated by the retargeting AS for the ICID in the new message. Thus every retargeted message includes both an ICID generated by the retargeting entity (e.g AS) as well as a reference to the ICID of the previous message that triggered the retargeting. In this way the ICID values can be used to correlate every message with its previous message, back to the originating message.

FIG. 5 is a flow chart illustrating the steps that occur when B's terminating AS 14 retargets a call—i.e. creates a new call leg on behalf of B, e.g. at Call Diversion. At step 501 a SIP INVITE (or other SIP message) is received. The P-Charging-Vector (PCV) header is stored (502). As described above, at step 503 the INVITE is retargeted. This includes (504) generating a new ICID value and placing this in the P-Charging-Vector (PCV) header of the outgoing SIP INVITE. In addition to this, the ICID received in the incoming INVITE is also added to the outgoing SIP INVITE, e.g. as a new orig-icid parameter in the PCV header. At step 505 a SIP 200 OK is received. At step 506 the charging information is sent to the CDF. This includes (step 507) the orig-icid as well as the new ICID. In this example, the PCV header is used as an example of the transport mechanism for the reference to the original ICID, orig-icid. The syntax could be:

• • P-Charging-Vector=“P-Charging-Vector” HCOLON icid-value *(SEMI charge-params)
  • charge-params=icid-gen-addr/orig-ioi/term-ioi/orig-icid/generic-param
  • icid-value=“icid-value” EQUAL gen-value
  • icid-gen-addr=“icid-generated-at” EQUAL host
  • orig-ioi=“orig-ioi” EQUAL gen-value
  • term-ioi=“term-ioi” EQUAL gen-value
  • orig-icid=“orig-icid” EQUAL gen-value

The terms shown in bold text are the new parameters.

The inclusion of the reference to the original ICID in the outgoing SIP message, and subsequently in messages (ACR) sent to the Charging Data system, makes it possible for the charging system to correlate the charging information for all call legs generated for the served user. One consequence of this is an improvement in the input data for rating decisions. For example, at call diversions an operator may decide to reduce or omit the setup fee for the new leg where this is a result of a retargeting service.

A further advantage is that it is now possible to perform a network trace from the originating user A to user C when user B's AS has performed a retarget to C as a result of, for example, CDIV. The ICID generated by user A's originating network is also available in C's terminating network in the form of the orig-icid parameter. This is not possible under current procedures regardless of whether there is chaining of ASs. In FIG. 3, even if B's terminating AS 14 is capable of including a related icid parameter in the ACR, there is no way currently for C's terminating network to know or discover the original ICID in the INVITE from A.

Claims

1. A method of correlating information relating to messages in a Session Initiation Protocol (SIP) session, the method comprising: receiving a first SIP message that includes a first Internet Protocol (IP) Multimedia Subsystem (IMS) Charging Identifier (ICID);retargeting the first SIP message by generating a second SIP message that includes a second ICID;inserting a reference to the first ICID into the second SIP message; andcorrelating information relating to the first SIP message with information relating to the second SIP message based on the first ICID and the reference to the first ICID in the second SIP message.

2. The method of claim 1 wherein the retargeting of the first SIP message is performed at an Application Server or other IMS network entity that performs a retargeting operation serving a user to which the first SIP message is directed.

3. The method of claim 1 further comprising retargeting the second SIP message by generating a third SIP message, inserting a reference to the second ICID into the third SIP message, and correlating information relating to the second and third SIP messages based on the second ICID and the reference to the second ICID in the third SIP message.

4. The method of claim 3 further comprising correlating information relating to the first and third SIP messages based on the first and second ICIDs and the references to the first and second ICIDs in the second and third SIP messages.

5. The method of claim 3 wherein the first SIP message is directed to a user and retargeting of the first SIP message is performed at a terminating Application Server (AS) serving a user, while retargeting of the second SIP message is performed at an originating AS serving the user.

6. The method of claim 1 wherein the retargeting of the first and/or second SIP message comprises generating the respective second and/or third SIP message as a SIP INVITE directed to a different user than the user to whom the first SIP message was directed.

7. The method of claim 1 wherein the retargeting of the first and/or second SI P message comprises application of one of: a Communication Diversion (CDIV); a Do Not Disturb service; a Communication Distribution service; a Flexible Alerting service; a Conference service, or any other retargeting service.

8. The method of claim 1, wherein the information relating to the first, second or third SIP messages comprises charging information, the method further comprising forwarding the charging information to a Charging Data Function (CDF), together with the ICID and referenced ICID contained in the SIP message.

9. The method of claim 8 wherein the CDF correlates the charging information with other charging information received that includes a corresponding ICID or referenced ICID.

10. The method of claim 1 wherein the information relating to the first, second or third SIP messages comprises charging information, the method further comprising forwarding the charging information to an Online Charging System (OCS), together with the ICID and referenced ICID contained in the SIP message.

11. The method of claim 10 wherein the OCS correlates the charging information with other charging information received that includes a corresponding ICID or referenced ICID.

12. The method of claim 1 wherein correlating the information relating to the first, second or third SIP messages comprises performing a network trace using the ICIDs in the SIP messages.

13. An Internet Protocol (IP) Multimedia Subsystem (IMS) network entity configured, on receiving a first Session Initiation Protocol (SIP) message directed to a served user and containing a first IMS Charging Identifier (ICID), to retarget the message by generating a second SIP message containing a second ICID and to include a reference to the first ICID in the second SIP message.

14. The IMS network entity of claim 13 wherein the network entity is an Application Server providing a service that performs a retargeting function.

15. An Internet Protocol (IP) Multimedia Subsystem (IMS) network entity configured to receive a message from another IMS network entity, the message comprising information relating to a Session Initiation Protocol (SIP) session and references to a plurality of associated IMS Charging Identifiers (ICIDs), and to correlate the information with information received in other messages that comprise references to one or more of the same ICIDs.

16. The IMS network entity of claim 15 wherein the network entity comprises a Charging Data Function (CDF), and the information in the messages received comprises charging information.

17. The IMS network entity of claim 15 wherein the network entity comprises an Online Charging System (OCS), and the information in the messages received comprises charging information.