PROVISION OF LOCATION INFORMATION IN AN IP MULTIMEDIA SUBSYSTEM NETWORK

Abstract

A method of providing location-related charging information to a charging system associated with an IP Multimedia Subsystem, IMS, network, where the location-related charging information relates to a session or session initiation or an event involving at least two users. The method comprises, at a Charging Trigger Function, CTF, within the IMS network, receiving a Session Initiation Protocol, SIP, message from each of said users, each message containing a SIP header identifying a location of the sending user. Location information of each user is added to a charging message sent from the CTF to said charging system, location information being, or being derived from, the content of the SIP header received from the user or being derived from that SIP header.

Claims

1. A method of providing location-related charging information to a charging system associated with an IP Multimedia Subsystem (IMS) network, where the location-related charging information relates to a session or session initiation or an event involving at least two users, the method comprising: at a Charging Trigger Function (CTF) within the IMS network, receiving a Session Initiation Protocol (SIP) message from each of said users, each message containing a SIP header identifying a location of the sending user; and adding location information of each user to a charging message sent from the CTF to said charging system, location information being, or being derived from, the content of the SIP header received from the user or being derived from that SIP header.

2. The method of claim 1, wherein said SIP header is P-Access-Network-Info header.

3. The method of claim 1, wherein a first of said users is a user served by the IMS network and a second of said users is a remote user served by a further IMS network.

4. The method of claim 3, wherein said charging message is sent in accordance with the Diameter protocol, the location of the served user being included within an Access-Network-Information (ANI) Attribute-Value-Pair (AVP) of the charging message, and the location of the remote user being included within a further AVP of the charging message.

5. The method of claim 1, wherein at least one of said users is a network node.

6. The method of claim 1, wherein said charging message includes, for each location, an identity of the associated user.

7. The method of claim 6, wherein each identity is a SIP-Uniform Resource Identifier or a Tel-Uniform Resource Identifier.

8-19. (canceled)

20. The method of claim 1, wherein said charging system is either an online charging system or an offline charging system.

21. The method of claim 7, wherein said charging system is an offline charging system and said charging message is sent from the CTF to a Charging Data Function of the offline charging system, via an Rf interface.

22. The method of claim 7, wherein said charging system is an online charging system and said charging message is sent from the CTF to an Online Charging Function of the online charging system, via an Ro interface.

23. The method of claim 1, wherein a location is derived from a SIP header, a step of deriving comprising performing a lookup to map a content of the header to a geographical zone.

24. The method of claim 23, wherein said lookup is performed using a database co-located with the CTF or remotely accessed by the CTF.

25. An apparatus for providing location-related charging information to a charging system associated with an IP Multimedia Subsystem (IMS) network, where the location-related charging information relates to a session or session initiation or an event involving at least two users, the apparatus comprising processor circuitry and a storage unit for storing instructions executable by the processor circuitry, whereby the apparatus is operative to: at a Charging Trigger Function (CTF) within the IMS network, receive a Session Initiation Protocol (SIP) message from each of said users, each message containing a SIP header identifying a location of the sending user; and add location information of each user to a charging message sent from the CTF to said charging system, location being, or being derived from, the content of the SIP header received from the user or being derived from that SIP header.

26. A Call/Session Control Function, Application Server, Gateway Control Function, or Multimedia Resource Function Controller comprising the apparatus of claim 25.

27. A method of obtaining location-related charging information at a charging system associated with an IP Multimedia Subsystem (IMS) network, where the location-related charging information relates to a session or session initiation or an event involving at least two users, the method comprising: at the charging system, receiving from a Charging Trigger Function (CTF) within the IMS network, a charging message containing a location of each user.

28. The method of claim 27, wherein each said location is a contents of a P-Access-Network-Info header.

29. The method of claim 27, wherein a first of said users is a user served by the IMS network and a second of said users is a remote user served by a further IMS network.

30. The method of claim 29, wherein said charging message is in accordance with the Diameter protocol, the location of the served user being included within an Access-Network-Information (ANI) Attribute-Value-Pair (AVP) of the charging message, and the location of the remote user being included within a further AVP of the charging message.

31. The method of claim 27 and comprising using said location at the charging system to generate a charge to be applied to one or both of the users.

32. The method of claim 27, wherein said charging message includes, for each location, an identity of the associated user, the method comprising using the identity within the charging system to allocate charges to the users.

33. The method of claim 32, wherein each identity is a SIP-Uniform Resource Identifier, SIP-URI or a Tel-Uniform Resource Identifier, Tel-URI.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] FIG. 1 illustrates schematically an IMS network integrated into an LTE access network;

[0031] FIG. 2 illustrates schematically an IMS offline charging architecture;

[0032] FIG. 3 illustrates schematically an IMS online charging architecture;

[0033] FIG. 4 illustrates signaling associated with a hypothetical solution to the problem of providing location related charging information to an OCF of an online charging system for both users involved in an IMS session;

[0034] FIG. 5 illustrates signaling associated with providing location related charging information to a charging system, both for an offline and an online case;

[0035] FIG. 6 illustrates signaling associated with providing location related charging information to a charging system, in the case of a session redirected from an end user UE to a voice mail server;

[0036] FIG. 7 illustrates schematically an IMS node with CTF function; and

[0037] FIG. 8 is a flow diagram illustrating a method of providing location related charging information to a charging system.

DETAILED DESCRIPTION

[0038] An introduction to the IP Multimedia Subsystem (IMS) and to charging systems with the IMS has been presented above. In addition, a possible mechanism for providing location information to an IMS charging system in respect of both users (e.g. including a user that is not served by that IMS network) has been described with reference to FIG. 4.

[0039] Considering further IMS-SIP, the PANI header in a SIP message carries location information of the user sending the message. In a dialog, the originating user (A) as well as the terminating user (B) can trigger a request, which means the PANI header in a request can be related to user A or to user B. 3GPP TS 32.299 states that the Access-Network-Information AVP is populated with contents of the PANI header but it does not say whether this shall be done only for the served user or for both. Although the Access-Network-Information AVP can be reported multiple times in a charging message to the CDF/OCF, according to the current standards there is no way to indicate which user it relates to.

[0040] Consider a typical example of a SIP dialog where User A sends an INVITE towards user B, and where User A's home IMS network is responsible for generating charging information applicable to User A. The INVITE contains a PANI header with a location of user A. This location will typically be a globally recognizable identity (e.g. MCC, MNC) of the network in which user A resides. The 200 OK response from User B contains likewise a PANI header with the location of User B. Later on in the dialog, User B wants to switch to a high-definition audio codec and the terminal sends a reINVITE with, in addition to the new SDP information, a PANI header with the location of User B. The resulting response contains a PANI header with the location of User A.

[0041] Online charging is triggered by each message in the dialogue while offline charging is triggered mainly by completed transactions. When a charging message is triggered, the location of the involved parties is added. Today's 3GPP specification allows multiple instances of the Access-Network-Information (ANI) AVP but this is to be able to include user provided PANI headers as well as network provided PANI headers, i.e. related to one and the same user.

[0042] A mechanism is needed to report location from a CTF to the OCF or CDF, as well as to indicate to the OCF/CDF which user this location is applicable to. This can be solved in a number of different ways. One solution is to use the existing ANI AVP to convey the location of the served user (i.e. User A on originating side, and User B on terminating side), whilst a new AVP is used to convey the location of the remote user (i.e. User B on the originating side and User A on the terminating side).

[0043] As there may be services with multiple call legs, e.g. conference calls, the related charging session may also cover multiple call legs, which means that there is a need to tag the location that is provided for each user, in a charging message, with a user identifier. This could involve tagging the location with, for example, the SIP-uri of the user. When a SIP message is received by a CTF, it will store the location information together with the associated identity, i.e. the user sending the SIP message. This information is then added as charging data when a charging message is triggered and sent by the CTF to the OCF/CDF.

[0044] The charging information can be structured in different ways and one example is (according to the Diameter Base protocol RFC6733, chapter 4.2): [0045] *Remote-User-Location-Information AVP [0046] *Remote-Access-Network-Information AVP [0047] Remote-Party-Address AVP

[0048] Nb. * is used to indicate that the message may include more than one instance of the particular AVP.

[0049] The already existing Access-Network-Information AVP could also be reused instead of the Remote-Access-Network-Information AVP in the example above.

[0050] FIG. 5 illustrates signaling associated with this approach, showing both the online (OCF) and offline (CDF) cases. For the online case, the CTF sends an initial charging message to the OCF following receipt of the INVITE from UeA. This is a standard Diameter charging message including the normal Access-Network-Information AVP (ANI-A) identifying the location of served user UeA. Following receipt of the 200 OK response from the non-served user, UeB, the CTF sends a further, update, Diameter charging message to the OCF. This message includes the Remote-User-Location-Information AVP (RULI-B) identifying the location of user UeB as well as the ANI-A sent previously. FIG. 5 further illustrates that UeB sends a reINVITE to UeB, e.g. to change the session parameters. Upon receipt of the reINVITE, the CTF sends an update charging message to the OCF including RULI-B. In the case of offline charging, a first, start, charging message is sent to the CDF following receipt by the CTF of the 200 OK response. Subsequently, receipt by the CTF of the reINVITE causes the CTF to send to the CDF an update charging message. Both messages contain the ANI-A and RULI-B.

[0051] As an alternative to using the Remote-Party-Address AVP, the existing Called-Party-Address and Calling-Party-Address AVPs may be used, resulting in different layouts on the originating and terminating sides. An example with re-use of Calling- and Called-Party-Address is for originating (calling) side information: [0052] *Remote-User-Location-Information AVP [0053] *Remote-Access-Network-Information AVP [0054] Called-Party-Address AVP
and for the terminating (called) side information: [0055] *Remote-User-Location-Information AVP [0056] *Remote-Access-Network-Information AVP [0057] Calling-Party-Address AVP

[0058] Location information provided for a user involved in an IMS service can also be used to create an additional type of location identification for the user. This additional type of location identification is referred to here as a zone. A zone is a predefined area with specific geographic information. The concept of zones can be used to create a higher abstraction level which is stable over time. The mapping of the location information provided in the PANI (e.g. MCC-MNC and LAC/TAC and Cell-Id) to a zone can be done in a database, meaning that, for example, following a cell modification in a mobile network (e.g. change of Cell-Id) only the database needs to be updated and not all nodes that are using zone-based location information for services. The database can be co-located within the CTF (i.e. within the same network node) or can be located externally in another node.

[0059] The zone information for a user shall also be sent to CDF/OCF in a charging message (both items are desirable as the information in the PANI can be used for example to make a determination of roaming, and also includes TZ-info).

[0060] The proposed structure above for the remote user can be extended to include the zone information: [0061] *Remote-User-Location-Information AVP [0062] Remote-Access-Network-Information AVP [0063] Remote-Party-Address AVP [0064] Zone-Information AVP

[0065] The Zone-Information AVP is also included in the charging message for the served user.

[0066] Rather than including a separate Zone-Information AVP, the information could be added as a new parameter to the PANI header, thereby letting the Access-Network-Information AVP carry the information and also providing other nodes in the call chain with the same information. This would allow other nodes to make use of the zone-Information.

[0067] It will be appreciated that, with a zone-mapping based solution, the zone information can also be determined using sources other than the PANI header. For example, it would be possible to use Geolocation SIP headers of a received SIP message as defined in RFC6442 and in 3GPP TS 24.229.

[0068] 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 present invention. For example, as already discussed briefly above, rather than being subscriber (UE), a user whose location and identity that are provided to the OCF/CDF may be in respect of a network node, for example a voice mail server. FIG. 6 illustrates signaling associated with a session initiated between a UeA and a UeB, wherein UeB redirects the session to a voicemail server in UeBs IMS network. Charging messages for both the online and offline charging cases are shown.

[0069] FIG. 7 illustrates schematically an IMS network node 1, such as a CSCF, SIP AS, MRFC, etc, within which a CTF is provided. The node includes processing circuitry 2 and storage circuitry 3. Code and other data is held in the storage circuitry and, when executed, implements functionality required to collect and send location information to one of an online charging system and an offline charging system. More particularly this functionality includes a SIP message receiver function 4 that is responsible for receiving and handling SIP messages that contain a PANI header identifying a location of a message sender. A PANI header extraction function 5 is provided to extract PANI headers and pass these to a function 6 that stores the headers and incorporates them as required into charging messages to be sent to a CDF or OCF.

[0070] FIG. 8 is a flow diagram illustrating a method that is implemented within the node of FIG. 7. The flow is merely exemplary of course and considers a case where SIP messages are received from the served and non-served users (S1, S3), location information extracted from respective PANI headers (S2, S4) and, following a charging event (S5), a single charging message sent to the charging system (CDF/OCF) containing both locations.