The present invention relates to the provision of location information in an IP Multimedia Subsystem (IMS) network, and more particularly to the provision of such information for the purpose of handling session or event charging. Background

IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.

The IP Multimedia Subsystem (IMS) is an access independent architectural framework for supporting traditional telephony as well as the new IP multimedia services (Release 11 : 3GPP TS 22.228 V12.9.0; 23.228 V12.7.0; 24.229 V12.7.0; 29.228 V12.4.0; 29.229 V12.4.0; 29.328 V12.7.0; 29.329 V12.5.0). IMS provides key features to enrich the end- user person-to-person communication experience through the use of standardized IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP- based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.

The IMS makes use of the Session Initiation Protocol (SIP), as specified in IETF RFC 3261 , to set up and control calls or sessions between user terminals (or terminals and application servers). The Session Description Protocol (SDP), carried by SIP signaling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signaling between a User Equipment (UE) and the IMS as well as between the components within the IMS.

By way of example, Figure 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a LTE access network (IMS can of course operate over other access networks including, for example, UMTS packet switched and circuit switched access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. 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 (or from an external network). Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or "linked in" by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be "linked in" during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from a Home Subscriber Server (HSS) during the IMS registration procedure as part of a user's Subscriber Profile. Examples of ASs are a Telephony AS (TAS) that is responsible for setting up voice calls between users and a voice mail AS that allows users to access voice mail services.

3GPP TS 32.260 defines the Offline and Online Charging description for the IP Multimedia Subsystem. For both Offline and Online charging, charging information for network resource usage is collected concurrently with that resource usage. In Offline charging this charging information does not affect, in real-time, the service rendered. However, in Online charging, authorization for the network resource usage must be obtained by the network prior to the actual resource usage.

Figure 2 illustrates schematically the IMS offline charging architecture. In this architecture a Charging Trigger Function (CTF) generates offline charging events based on the observation of network resource usage. All IMS entities handling SIP signalling can be provided with CTF functionality (the entities implementing the CTF shown in Figure 2 are merely exemplary, and other nodes may also implement the CTF). The CTF is the focal point for collecting the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the Charging Data Function (CDF), for example using the Diameter protocol. The Charging Data Function (CDF) receives charging events from the CTFs via the Rf reference point. It then uses the information contained in the charging events to construct Charging Data Records (CDRs). The CDRs produced by the CDF are transferred to the Charging Gateway Function (CGF) via the Ga reference point. The CGF acts as a gateway between the 3GPP network and the network operator's Billing Domain (BD), and uses the Bx reference point for the transfer of CDR files to the BD. The BD typically comprises post-processing systems such as the operator's billing system or billing mediation device. The Charging Gateway Function's (CGF) main functionalities are in principle equivalent to those of the Charging Collection Function's (CCF) for IMS.

Figure 3 illustrates schematically the IMS online charging architecture. In this architecture, when receiving a network resource usage request, a CTF assembles the relevant charging information (which is not necessarily identical to the charging information employed in offline charging) and generates an online charging event that is transferred to the Online Charging Function (OCF) within the Online Charging System (OCS) in real-time using the Ro reference point, again using, for example, Diameter. The OCF then returns an appropriate resource usage authorization based, for example, on subscriber account information. This resource usage authorization may be limited in its scope (e.g. volume of data or duration), and may therefore have to be renewed from time to time as long as the subscriber's network resource usage persists. If required by the operator, CDRs may additionally be generated for online charged subscribers. The OCF includes the Session Based Charging Function (SBCF/SCF) and the Event Based Charging Function (EBCF/ECF). The SBCF is responsible for online charging of network/user sessions, e.g. voice calls, IP CAN bearers, IP CAN session or IMS sessions. The EBCF performs event- based online charging (often referred to as "content charging") in conjunction with any application server or service NE, including SIP application servers. As illustrated in Figure 3, only an AS (e.g. a Telephony Application Server, TAS), an MRFC or an S-CSCF support online charging. However, with regards to the S-CSCF, the S-CSCF does not trigger any online charging events. A special CTF is therefore needed in order to mediate between the Ro based SBCF and the SIP based service control implemented by the S-CSCF. This role is taken by the IMS Gateway Function (IMS- GWF), which translates between SIP service control towards the S-CSCF and Ro credit control on the OCS side. From the perspective of the online charging architecture, the IMS-GWF is an online charging capable CTF; whilst from the perspective of the S-CSCF the IMS-GWF is a SIP application server and is triggered in the same way. As such, the S-CSCF supports online charging using either the ISC interface (i.e. if the application server addressed over the ISC interface is IMS-GWF), or the Ro interface directly (if the IMS-GWF is integrated within the S-CSCF).

Generation of Diameter charging messages in a CTF is in most cases triggered by the receipt of a certain SIP message (request or response). The same SIP message may trigger charging in all CTFs through which it passes. The CTF indicates to the CDF/OCF whether to start, update or terminate a charging session based on the SIP message it receives (or may indicate some other charging event). The SIP messages carry information related to the service as well as to the user originating and terminating the SIP message. The charging messages forward this information to the CDF/OCF to enable correct rating and charging decisions.

The tariff (rate) for a given service applied by a network operator, e.g. a telephony service, may depend on the location of the user served by that network operator. For example, a lower rate may be applied when the user is located within the operator's home network with a higher rate being applied when the user is roaming in a visited network. Location information for the served user is transferred over SIP as a P-Access-Network-lnformation (PANI) header and reported over Diameter using the Access-Network-Information AVP. The PANI header in a SIP request reflects the location of the user sending the request, i.e. a SIP response carries the location of the user sending the response. The location information of a user can be changed during an ongoing SIP dialog.

As well as depending on the location of the served user, the tariff applied by a network operator may depend upon the location of the remote or peer user. In order to provide this information to the CDF (offline charging) or OCF (online charging), non-SIP solutions have been discussed wherein a look-up of location data is performed towards a database that is regularly updated with location data. A hypothetical example with such an external lookup from OCS as applied within the context of SIP/IMS is shown in Figure 4. In this example, the User Equipment A (UeA) represents a user originating a session and which is served by a home IMS network responsible for charging UeA for the session, UeB represents a remote user served by a different IMS network, and DB represents a database holding location information. The database look-up solution illustrated in Figure 4 is disadvantageous as it adds signaling load and latency to the session set up phase.

It is noted here that whilst the term "user" has been used above to refer to a User Equipment (UE), i.e. a served user or "subscriber", the term also encompasses network nodes that may provide an endpoint for an IMS session or event. For example, an IMS session may be created between a UE and a voice mail server within the IMS network.

Summary It is an object of the present invention to provide a means for efficiently providing location information for both or all users involved in an IMS enabled session of event, to a charging system entity such as an OCF or a CDF.

According to a first aspect of the present invention there is provided 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. According to an embodiment of the invention, the SIP header is P-Access-Network-lnfo, PANI, header.

A first of said users may be a user served by the IMS network with a second of said users being a remote user served by a further IMS network. In this case, the charging message may be 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. Alternatively, least one of said users may be a network node.

The charging message may include, for each location, an identity of the associated user, wherein each identity is a SIP-Uniform Resource Identifier, SIP-URI or a Tel-Uniform Resource Identifier, Tel-URI.

Where said charging system is an offline charging system, said charging message may be sent from the CTF to a Charging Data Function, CDF, of the offline charging system, via an Rf interface. Where said charging system is an online charging system, said charging message may be sent from the CTF to an Online Charging Function, OCF, of the online charging system, via an Ro interface.

A location may be derived from a SI P header, a step of deriving comprising performing a lookup to map a content of the header to a geographical zone, in which case said lookup is performed using a database co-located with the CTF or remotely accessed by the CTF.

According to a second aspect of the present invention there is provided apparatus for providing location-related charging information to a charging system associated with an I P 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 comprises 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, SI P, message from each of said users, each message containing a SIP header identifying a location of the sending user. The apparatus is further operative to 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. According to a third aspect of the present invention there is provided a Call/Session Control Function, Application Server, Gateway Control Function, or Multimedia Resource Function Controller comprising the apparatus of the above second aspect of the invention.

According to a fourth aspect of the present invention there is provided a method of obtaining location-related charging information at a charging system associated with an I P 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 the charging system, receiving from a Charging Trigger Function, CTF, within the IMS network, a charging message containing a location of each user. The location may be a contents of a P-Access-Network-lnfo, PANI , header.

According to an embodiment of the invention, the first of said users may be a user served by the IMS network and a second of said users is a remote user served by a further IMS network. In this case, the charging message may be 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.

The method may comprise using said location at the charging system to generate a charge to be applied to one or both of the users.

The charging message may include, 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.

The or each identity may be a SIP-Uniform Resource Identifier, SIP-URI or a Tel-Uniform Resource Identifier, Tel-URI. Brief Description of the Drawings

Figure 1 illustrates schematically an IMS network integrated into an LTE access network; Figure 2 illustrates schematically an IMS offline charging architecture;

Figure 3 illustrates schematically an IMS online charging architecture;

Figure 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;

Figure 5 illustrates signaling associated with providing location related charging information to a charging system, both for an offline and an online case;

Figure 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;

Figure 7 illustrates schematically an IMS node with CTF function; and

Figure 8 is a flow diagram illustrating a method of providing location related charging information to a charging system.

Detailed description

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 Figure 4.

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. 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 relNVITE 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.

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.

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).

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. The charging information can be structured in different ways and one example is (according to the Diameter Base protocol RFC6733, chapter 4.2):

*Remote-User-Location-lnformation AVP

*Remote-Access-Network-lnformation AVP

Remote-Party-Address AVP

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

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

Figure 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. Figure 5 further illustrates that UeB sends a relNVITE to UeB, e.g. to change the session parameters. Upon receipt of the relNVITE, 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 relNVITE causes the CTF to send to the CDF an update charging message. Both messages contain the ANI-A and RULI-B.

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:

*Remote-User-Location-lnformation AVP

*Remote-Access-Network-lnformation AVP

Called-Party-Address AVP and for the terminating (called) side information:

*Remote-User-Location-lnformation AVP

*Remote-Access-Network-lnformation AVP

Calling-Party-Address AVP

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.

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).

The proposed structure above for the remote user can be extended to include the zone information:

*Remote-User-Location-lnformation AVP

Remote-Access-Network-Information AVP

Remote-Party-Address AVP

Zone-Information AVP

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

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.

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.

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. Figure 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.

Figure 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.

Figure 8 is a flow diagram illustrating a method that is implemented within the node of Figure 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.