WO2011047712A1

WO2011047712A1 - Charging in an ip multimedia subsystem network

Info

Publication number: WO2011047712A1
Application number: PCT/EP2009/063710
Authority: WO
Inventors: Per Roos; Gert Öster; Jan Dahl
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2009-10-20
Filing date: 2009-10-20
Publication date: 2011-04-28
Anticipated expiration: 2012-04-20

Abstract

A method and apparatus for providing charging information in an IP Multimedia Subsystem network. A routing function is located in a transit network between an originating network and a terminating network. The routing function receives a Session Initiation Protocol (SIP) message, the message comprising a P-Charging-Vector header (P-C-V). An intermediate network identifier field that identifies the transit network is added to the P-C-V header, and the SIP message is then sent towards the terminating network.

Description

Charging in an IP Multimedia Subsystem Network

TECHNICAL FIELD The present invention relates to charging in an IP Multimedia Subsystem Network. BACKGROUND

The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnersh ip Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.

The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.

Figure 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in Figure 1 a control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1 , also referred to as the bearer plane and through which signals are directed to/from user equipment, UE, accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.

The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1 , and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer 4. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (l-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the I MS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. A device that attaches to an I MS network can communicate with devices attached to other IMS networks. ETSI TS 124 229 V8.6.0 is concerned with call control protocols for use in the IP Multimedia (IM) Core Network (CN) subsystem. ETSI TS 124 229 V8.6.0 section 4.5 describes charging procedures, and defines an Inter Operator Identifier (IOI). An IOI is a globally unique identifier that is shared between sending and receiving networks, service providers or content providers. SIP signalling concerned with session setup within a single network, or between two networks that have a trust relationship, have a P-Charging-Vector (P-C-V) header field. The P-C-V header field is used to convey charging information relating to the session, and includes parameters such as an IMS Charging Identifier (ICID).

One of the field parameters in P-C-V header field is "orig-ioi" header parameter of the P-Charging-Vector header in a SIP message, and identifies the operator network from which the request originated. A "term-ioi" header field parameter is also available, which defines the terminating operator network, and is left out of the P-Charging-Vector header field in a request such as a SIP INVITE message sent from the originating network. When the originating network receives a SIP 200 OK in response to the SIP I NVITE, the "term-ioi" header field parameter has been populated, which allows the originating network to identify the terminating network from which the response was sent.

This procedure is used as part of the handling of financial settlements between operators; the terminating network is informed of charging data from which originating network, and the originating network can see in which network the call has terminated. Referring to Figure 2, the signalling between the originating and terminating networks is illustrated, with the following numbering corresponding to the numbering in Figure 2: S1 . The originating network 8, shown in this example as home1.com, receives a SIP INVITE from a user, requesting a session with userB@gone2.net S2. The originating network 8 forwards the SIP INVITE to the terminating network 9, gone2.net. It adds to the SIP INVITE a P-C-V header. An example of a P-C-V header from the originating network 8 is:

"P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1.com"

The final parameter defines that the SIP INVITE has originated from the originating network 8, home1 .com.

53. The P-C-V header is removed from the SIP INVITE before the SIP INVITE is forwarded to User B.

54. UserB@gone2.net sends a 200 OK in response to the SIP INVITE to the terminating network 9. S5. The terminating network 9 adds the P-C-V header to the 200 OK including "orig- ioi = home 1 .com" . The termi nati ng network 9 also adds the parameter "term- ioi=gone2.net". An example syntax for the P-C-V header in the 200 OK response sent from the terminating network 9 to the originating network 8 is:

"P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1.com; term-ioi=gone2.net"

S6. The P-C-V header is removed from the 200 OK by the originating network 8, and the 200 OK message is then forwarded to the user. In this way, the terminating network 9 and the originating network 8 can both produce a charging output that includes the identities of the originating network and the terminating network, along with the ICID,

According to RFC 3455, an originating network that supports the P-C-V extension should include the P-C-V header in the outbound message when next hop is within trusted domain (or within the same domain). 101 handling works well for inter operator accounting handling. However, it only works when the call is terminated in 'next hop', in other words, the originating network 8 must communicate directly with the terminating network 9. Referring to Figure 3 herein, a problem arises when the signalling traverses one or more transit networks. The following numbering corresponds to that of Figure 3:

57. The originating network 8, home1.com, receives a SIP INVITE from a user, requesting a session with User B.

58. The originating network 8 forwards the SIP INVITE to the terminating network 9, gone2.net. It adds to the SIP INVITE a P-C-V header. An example of a P-C-V header from the originating network 8 is:

The SIP INVITE is forwarded to transit network transA.com 10, then on to transit network transB.com 1 1 , and finally to the terminating network 9. S9. The P-C-V header is removed from the SIP I NVITE by the terminating network 9, and is forwarded to User B.

510. User B sends a 200 OK in response to the SIP INVITE to the terminating network 9.

51 1. The terminating network 9 adds the P-C-V header to the 200 OK including "orig- ioi=home1.com". The terminating network 9 also adds the parameter "term- ioi=gone2.net". An example syntax for the P-C-V header in the 200 OK response sent from the terminating network 9 to the originating network 8 is:

The SIP 200 OK is forwarded to transit network transB.com 1 1 , then on to transit network transA.com 10, and finally to the originating network 8. S12. The P-C-V header is removed from the 200 OK by the originating network 8, and the 200 OK message is then forwarded to the user.

The orig-ioi and term-ioi are of little use for the transit networks 10, 1 1 if the call is routed via one or several transit operators. The P-C-V only contains information identifying the originating and terminating networks 8, 9, but not which networks that the call has traversed.

In the call case above the operator of transit network transA.com 10 will identify the terminating network as 'gone2.net'. However, this is the wrong network to perform egress accounting against, since the call is routed to transit network transB.com 1 1 . Information about 'transB.com' is not visible in the charging data. Similarly, transit network transB.com 1 1 should according to the charging output perform ingress accounting towards the originating network homel .com 8. However, the signalling was received from transit network transA.com 10, and this is the operator the accounting should be performed against. There is no information in the charging record about transit network transA.com 10. In other words, the charging information generated by transit network transA.com 10 will incorrectly show the terminating network to be gone2.net 9, whereas for the purposes of accounting be transB.com 1 1 . Similarly, the charging information generated by transit network transB.com 1 1 will be incorrect.

Of course, if there was a third transit network between transA.com 10 and transB.com 1 1 , then both the ingress and the egress accounting would be incorrect for the third transit network.

SUMMARY

The inventors have realised that a problem exists for charging when sending signalling from one IMS core network to another IMS core network via at least one intermediate transit IMS network. It is an object of the invention to allow charging to accurately reflect the networks traversed in the case where an intermediate transit network is traversed.

According to a first aspect of the invention, there is provided a method of providing charging information in an IP Multimedia Subsystem network. A routing function is located in a transit network between an originating network and a terminating network. The routing function receives a Session Initiation Protocol (SIP) message, the message comprising a P-Charging-Vector header (P-C-V). An intermediate network identifier field that identifies the transit network is added to the P-C-V header, and the SIP message is then sent towards the terminating network. The addition of the intermediate network identifier allows each network hop to be recorded , and so charging information in the case of a pay-and-forward charging model can be captured without losing end-to-end charging information such as the identities of the originating network and the terminating network. In an optional embodiment, it is necessary to determine that the network is not the terminating network prior to adding the intermediate network identifier field to the P-C-V header. This determination may be made when a SIP Server determines that the end recipient of the SIP message is not provisioned in a Home Subscriber Server of the network.

It is optionally necessary to determine that the network is not the originating network prior to adding the intermediate network identifier field to the P-C-V header. This determination may be made by determining that an originating network identifier field identifies a network other than the transit network.

Examples of nodes at which the routing function is located include any of a Media Gateway Controller, a Breakout Gateway Control Function, a Call Session Control Function such as an Interrogating Call Session Control Function, and an Interconnection Border Control Function, although it is possible that other nodes could also implement the invention.

As an option, the intermediate network identifier field is used to identify at least one intermediate network when charging using a pay-and-forward charging model. If the SI P message traverses more than one transit network, the P-C-V optionally comprises a plurality of intermediate network identifiers. In this case, each intermediate network identifier identifies an intermediate network traversed by the SIP message. According to a second aspect of the invention, there is provided a routing node for use in an IP Multimedia Subsystem network. The routing node is provided with a receiver for receiving a SIP message, the message comprising a P-C-V. A processor is provided for determining that the IP Multimedia Subsystem network is a transit network between an originating network and a terminating network. The processor is also arranged to add an intermediate network identifier field to the P-C-V. The intermediate network identifier identifies the transit network. A transmitter is also provided for sending the SIP message towards the terminating network.

As an option, the processor is arranged to determine that the network is not the terminating network when a SIP Server determines that the end recipient of the SIP message is not provisioned in a Home Subscriber Server of the network.

Optionally, the processor is arranged to determine that the network is not the originating network by determining that an originating network identifier field identifies a network other than the transit network.

Examples of routing nodes include any of a Media Gateway Controller, a Breakout Gateway Control Function, and Call Session Control Function such as an Interrogating Call Session Control Function, and an Interconnection Border Control Function. The routing node is optionally provided with a memory, which is used to store a program executable by the processor.

According to a third aspect of the invention, there is provided a computer program comprising computer readable code which, when run on a computer device, causes the computer device node to perform the method as described above in the first aspect of the invention.

According to a fourth aspect of the invention, there is provided a computer program comprising computer readable code which, when run on a routing node, causes the routing node to behave as a routing node as described above in the second aspect of the invention.

According to a fifth aspect of the invention, there is provided a computer program product comprising a computer readable medium and a computer program as described above in the third and fourth aspects of the invention . The computer program is stored on the computer readable medium. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates schematically in a block diagram an IMS network in association with a mobile network architecture of a General Packet Radio Service (GPRS) access network;

Figure 2 is a signalling diagram illustrating signalling between two network operators; Figure 3 is a signalling diagram illustrating signalling between two network operators where the signalling traverses two transit network operators;

Figure 4 is a signalling diagram illustrating signalling between two network operators where the signalling traverses two transit network operators according to an embodiment of the invention;

Figure 5 illustrates schematically in a block diagram a network node according to an embodiment of the invention; and Figure 6 is a flow diagram illustrating the steps according to an embodiment of the invention.

DETAILED DESCRIPTION Several inter-operator accounting models exist. A first model is 'pay-and-forward'. Using this model, each operator pays the next operator to which signalling is sent for using their network. This is typically used for transmission costs. A second model is end to end (e2e) charging. Using e2e charging, the revenue for transmission usage is shared between intermediate transit operators, while the originating operator pays the terminating operator for service use. This is typically used for a high cost service. Any solution to the problem of identifying intermediate transit networks should ideally be compatible with at least these accounting models.

One possible solution to the problem of identifying intermediate transit networks is to replace the orig-ioi and term-ioi parameters at each "hop" between networks. There is therefore no change to the IOI parameters that are currently used. Instead of providing an end to end view of charging (i.e. they only identify the originating network 8 and the terminating network 9), they provide a "hob by hop" view. So, in the example of Figure 3, when intermediate transit network transA.com receives the SIP INVITE, it changes the orig-ioi parameter from home1 .com to transA.com before forwarding the SIP INVITE to intermediate transit network transB.com. Similarly, when intermediate transit network transB.com 1 1 receives the 200 OK from the terminating network gone2.net 9, transB.com changes the term-ioi parameter from term-ioi=gone2.net to transB.com before forwarding the 200 OK to intermediate network transA.com 10. However, this solution would only work for the 'pay and forward' solution described above, and would make an e2e charging model impossible to implement, as there is no guarantee that the networks identified in the orig-ioi and the term-ioi parameters identify the originating and terminating networks.

According to the present invention, a new parameter is added to the P-C-V header that identifies all intermediate networks that the SI P message traverses. This is termed herein an "inter-ioi". Each time the SIP message traverses a new network, the network determines if it is the terminating network. If so, then it adds a term-ioi as normal, but if it is determined that that SIP message is to be forwarded to another network, then the network adds the new inter-ioi parameter which identifies the network as an intermediate transit network.

Figure 4 illustrates an example of a SIP INVITE and a SIP 200 OK traversing two intermediate transit network, with the following numbering corresponding to the numbering of Figure 4:

513. The originating network 8, home1.com, receives a SIP INVITE from a user, requesting a session with User B.

514. The originating network 8 forwards the SIP INVITE to the terminating network 9, gone2.net. It adds to the SIP INVITE a P-C-V header that includes an orig-ioi parameter identifying the originating network 8. An example of a P-C-V header from the originating network 8 is:

"P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1 .com"

The SIP INVITE is forwarded to transit network transA.com 10. 515. Intermediate transit network transA.com 10 receives the SIP INVITE. It is determined that transA.com 10 is not the terminating network, and so an inter-ioi is added to the P-C-V header that identifies transA.com 10 as an intermediate transit network. A determination that transA.com is not the terminating network may be made, for example, when a terminating Interrogating Call Session Control Function (l-CSCF) does not find userB identified in the Home Subscriber Server (HSS) and therefore decides to send the call to a Breakout Gateway Control Function (BGCF) for external network selection. In this case, the l-CSCF or the BGCF could add the inter-ioi parameter before onward routing. An example of a P-C-V header in the SI P I NVITE from transit network transA.com 10 is:

"P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1 .com; inter-ioi=transA.com" The SIP INVITE is forwarded to transit network transB.com 1 1 .

516. Intermediate transit network transB.com 1 1 receives the SIP INVITE. It is determined that transA.com 10 is not the terminating network, and so a further inter-ioi parameter is added to the P-C-V header that identifies transB.com 1 1 as an intermediate transit network. An example of a P-C-V header in the SI P INVITE from transit network transB.com 1 1 is:

"P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1.com; inter-ioi=transA.com; inter-ioi=transB.com" The SIP INVITE is then forwarded to terminating network gone2.net 9.

517. The terminating network gone2.net 9 determines that it is the terminating network and so removes the P-C-V header from the SIP INVITE before forwarding the SIP INVITE to User B .

518. User B sends a 200 OK in response to the SIP INVITE to the terminating network 9.

519. The terminating network 9 restores the P-C-V header to the SIP 200 OK, and also adds the parameter "term-ioi=gone2.net". An example syntax for the P-C-V header in the 200 OK: "P-Charging-Vector: icid-value=1234bc9876e; icid-generated-at=192.0.6.8; orig- ioi=home1.com; inter-ioi=transA.com; inter-ioi=transB.com; term-ioi=gone2.net"

The SI P 200 OK is forwarded to transit network transB.com 1 1 , then on to transit network transA.com 10, and finally to the originating network 8.

S12. The P-C-V header is removed from the 200 OK by the originating network 8, and the 200 OK message is then forwarded to the user. When each network has received the SIP 200 OK containing the orig-ioi, the inter-iois and the term-ioi, each network is aware of the networks that the SIP messaging has traversed. They can then apply whichever charging model is appropriate for the session that is being set up; either pay and forward, or e2e, or any other charging model. Where the e2e charging model is used, the term-iois may be redundant. However, the size of the parameter is very small compared to the amount of data sent in a typical session, so it is considered that this is negligible.

Referring now to Figure 5, there is illustrated a node 12 for use in an intermediate network. Any node may have the functionality described above. Suitable nodes include the BGCF, the Media Gateway Controller (MGC) or the Interconnection Border Control Function (IBCF), although it will be appreciated that this list is not intended to be exhaustive.

The node 12 is provided with a receiver 13 for receiving the SIP message. A processor 14 analyses the message and determines that the node is located in an intermediate transit network rather than the originating network 8 or the terminating network 9. The fact that the network is not the terminating network may be determined by an l-CSCF, which informs the node 12 that the network is not the terminating network 9. The processor adds an inter-ioi field to the P-C-V header, the inter-ioi field identifying the network, and identifying that it is an intermediate transit network. A transmitter 15 is provided for forwarding the SIP message towards the terminating network. In one embodiment of the invention, the functionality of the node is likely to be implemented as software. In this case, the node 12 is provided with a memory 16. A software program 17 is stored in the memory 16, and executed using the processor 14 to ensure that the node 12 behaves as described above. In an alternative embodiment of the invention, the software program is retrieved by the processor 14 from a remote source. Referring now to Figure 6, the steps according to an embodiment of the invention are illustrated, with the following numbering corresponding to the numbering of Figure 6. S21 . A node 12 in the intermediate transit network 10 receives a SI P message from the originating network 8, or from another intermediate transit network.

S22. A determination is made that the network is n intermediate transit network. S23. An inter-ioi field identifying the intermediate transit network is added to the P-C- V header of the SIP message.

S24. The SIP message is forwarded towards the terminating network 9. S25. The intermediate transit network 10 receives a SI P response message, which includes the orig-ioi, inter-iois identifying all of the intermediate transit networks traversed by the message, and the term-ioi.

S26. Charging is applied on the basis of the charging model and the iois. Where the charging model is pay and forward, then iois of adjacent networks are used to calculate the charging, whereas when the charging model is e2e, only the orig-ioi and the term- ioi are necessary to calculate the charging.

The invention allows correct charging to be applied when using an end-to-end charging model or a pay and forward charging model that takes account, if necessary, of intermediate transit networks. As the P-C-V header contains information that allows correct charging to be applied for either of an e2e charging model or a pay and forward charging model, different classes of traffic can be charged using different models. For example, UserA may send UserB a short text message that is charged using an e2e charging model, and link to media content on UserA's device that is sent to UserB using a pay and forward model. The invention also allows other charging models to make use of the identities of the originating, terminating and any intermediate networks. It will be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the invention as defined in the appended claims. The following acronyms have been used in this description:

AS Application Server

BGCF Breakout Gateway Control Function

HSS Home Subscriber Server

IBCF Interconnection Border Control Function

l-CSCF Interrogating Call Session Control Function

IOI Inter Operator Identifier

IMS IP Multimedia Subsystem

MGC Media Gateway Controller

MGW Media Gateway

P-C-V P-Charging-Vector

SIP Session Initiation Protocol

URI Uniform Resource Identifier

Claims

CLAIMS:

1 . A method of providing charging information in an I P Multimedia Subsystem network, the method comprising:

at a routing function located in a transit network between an originating network and a terminating network, receiving a Session Initiation Protocol message, the message comprising a P-Charging-Vector header;

adding an intermediate network identifier field to the P-Charging-Vector header, the intermediate network identifier identifying the transit network; and

sending the Session I nitiation Protocol message towards the terminating network.

2. The method according to claim 1 , comprising making a determination that the network is not the terminating network prior to adding the intermediate network identifier field to the P-Charging-Vector header, the determination being made when a Session Initiation Protocol Server determines that the end recipient of the Session Initiation Protocol message is not provisioned in a Home Subscriber Server of the network.

3. The method according to claim 1 or 2, comprising making a determination that the network is not the originating network prior to adding the intermediate network identifier field to the P-Charging-Vector header, the determination being made by determining that an originating network identifier field identifies a network other than the transit network.

4. The method according to claim 1 , 2 or 3, wherein the routing function is located at any of a Media Gateway Controller, a Breakout Gateway Control Function, a Call Session Control Function, and an Interconnection Border Control Function.

5. The method according to any of claims 1 to 4, further comprising using the intermediate network identifier field to identify intermediate networks when charging using a pay-and-forward charging model.

6. The method according to any of claims 1 to 5, wherein the P-Charging-Vector header comprises a plurality of intermediate network identifiers, each intermediate network identifier identifying an intermediate network traversed by the Session Initiation Protocol message.

7. A routing node for use in an IP Multimedia Subsystem network, the routing node comprising:

a receiver for receiving a Session Initiation Protocol message, the message comprising a P-Charging-Vector header;

a processor for determining that the IP Multimedia Subsystem network is a transit network between an originating network and a terminating network;

the processor being further arranged to add an intermediate network identifier field to the P-Charging-Vector header, the intermediate network identifier identifying the network; and

a transmitter for sending the Session Initiation Protocol message towards the terminating network.

8. The routing node according to claim 7, wherein the processor is arranged to determine that the network is not the terminating network when a Session Initiation Protocol Server determines that the end recipient of the Session Initiation Protocol message is not provisioned in a Home Subscriber Server of the network.

9. The routing node according to claim 7 or 8, wherein the processor is arranged to determine that the network is not the originating network by determining that an originating network identifier field identifies a network other than the transit network.

10. The routing node according to claim 7 , 8 o r 9, wherein the routing node comprises any of a Media Gateway Controller, a Breakout Gateway Control Function, and Interrogating Call Session Control Function and an Interconnection Border Control Function.

1 1 . The routing node according to any of claims 7 to 1 0, further comprising a memory, the memory storing a program executable by the processor.

12. A computer program comprising computer readable code which, when run on a computer device, causes the computer device node to perform the method according to any one of claims 1 to 6.

13. A computer program comprising computer readable code which, when run on a routing node, causes the routing node to behave as a routing node according to any one of claims 7 to 1 1 .

14. A computer program product comprising a computer readable medium and a computer program according to claim 12 or 13, wherein the computer program is stored on the computer readable medium.