The present invention relates to the transmission of service validation messages by a user equipment device (UE) in a mobile communications system.

GSM, UMTS and EPC (evolved packet core) networks provide functions that implement offline and/or online charging mechanisms on the bearer, subsystem and service levels. In order to support these charging mechanisms, the network performs real-time monitoring of resource usage on the above three levels in order to detect the relevant chargeable events.

In offline charging, a resource usage is reported from a network to a billing domain (BD) after the resource usage has occurred. In online charging, a subscriber account, located in an online charging system (OCS), is queried prior to granting permission to use the requested network resources.

Typical examples of network resource usage are a voice call of certain duration, the transport of a certain volume of data, or the submission of a multimedia message of a certain size. The network resource usage requests may be initiated by the UE or by the network.

Offline charging is a process where charging information for network resource usage is collected concurrently with that resource usage. The charging information is then passed through a chain of logical charging functions. At the end of this process, charging data record (CDR) files are generated by the network, which are then transferred to the network operator's billing domain for subscriber billing and/or inter-operator accounting (or additional functions, e.g. statistics, at the operator's discretion). The BD typically comprises post-processing systems such as the operator's billing system or billing mediation device. In conclusion, offline charging is a mechanism where charging information does not affect, in real-time, the service rendered.

Online charging is a process where charging information for network resource usage is collected concurrently with that resource usage in the same fashion as in offline charging. However, authorization for the network resource usage must be obtained by the network prior to the actual resource usage to occur. This authorization is granted by the OCS upon request from the network. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization. The resource usage authorization may be limited in its scope (e.g. volume of data or duration), therefore the authorization may have to be renewed from time to time as long as the user's network resource usage persists.

Online charging is a mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with the control of network resource usage is required.

A charging trigger function (CTF) generates charging events based on the observation of network resource usage. A charging data function (CDF) receives charging events from the CTF via a so-called Rf reference point. The CDF then uses the information contained in the charging events to construct CDRs. The CDRs produced by the CDF are transferred immediately to a charging gateway function (CGF) via a so-called Ga reference point. The CGF acts as a gateway between the 3GPP network and the BD. It uses a so-called Bx reference point for the transfer of CDR files to the BD. The OCF consists of two distinct modules, namely a session based charging function (SBCF) and an event based charging function (EBCF).

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 in conjunction with any application server or service NE, including SIP application servers.

A rating function (RF) determines a value of the network resource usage (described in the charging event received by the OCF from the network) on behalf of the OCF.

An offline charging system (OFCS) is a grouping of charging functions used for offline charging. It collects and processes charging events from one or more CTFs, and it generates CDRs for subsequent offline downstream billing processes. In case a subscriber is roaming and served by a visited network, both charging systems (in the visited network and in the home network) will charge the subscriber separately. Roaming charges usually are per minute for voice calls (different charge for mobile originated and mobile terminated voice calls), per SMS and per megabyte data volume. For charging reasons both networks communicate via a transferred account procedure (TAP). The transfer mechanism for TAP is a mechanism called customized applications for mobile network enhanced logic (CAMEL).

For all services provided by a visited network that are routed through the home network like e.g. voice calls, SMS, IMS, it is possible for the operator of the home network to validate all charges transferred from the serving network via the TAP. There exist already some services that are currently not routed through the home network, like local breakout internet access or locally routed voice over IP (VoIP) calls. These locally served services are likely to become more popular. The home operator lacks a mechanism to verify charges transferred from the serving network via the TAP for locally routed services. Currently operators must trust each other that services the serving network transmits charges for, have actually been provided to the roaming subscriber. There is need for a mechanism that enables the home operator to validate roaming charges.

US 2002/0161723 A1 describes a technique in which the identity of a UE is validated using keys stored in the UE and an authentication center in a conventional manner. When the UE is attached to a local network other than its home network, a shared secret key, shared by the home network operator and the UE is used to validate the UE with the local network operator. If a user of the UE wishes to make a purchase making use of the UE to authorize payment, messages are exchanged with a seller using a different communication network, with the UE signing a message from the seller to indicate acceptance of the transaction. A network signature verification service is then used to check the signature. The signature verification service is distinguished from the home network and the local network. As described, both the UE and the signature verification service are provided with the signing key WO 2005/004456 describes a mechanism for charging a user of a UE using a visited network in which a home network issues accounting certificates which are sent to the UE enabling the UE to provide these to the service provider of the visited network.

The present invention provides a method of authenticating a transaction performed by a mobile communication user equipment, UE, device which has performed an

authentication and key agreement procedure between the UE device and a mobile management entity of a visited network in order to establish a security context between the UE device and the visited network, the method comprising sending a service validation message from the UE device to the visited network, the service validation message having been digitally signed by the UE device using an integrity protection key shared between the UE device and a home network; and forwarding the service validation message from the visited network to the home network.

The present invention provides a mechanism that gives the home operator more control over roaming charges transferred via TAP. User consent could be part of this

mechanism. One aspect of this mechanism is to establish a shared secret between a UE and a home operator and use this shared secret to generate integrity protected service validation messages. The shared secret could also be used to send integrity protected messages from the home operator network to the UE; e.g. a list with preferred or allowed visited networks. Several alternatives are provided as to how to transfer these service validation messages from the UE to the home operator. The most beneficial option is to enhance the CTF in the visited network, so the service validation messages generated in the roaming UE are added to the generated CDRs in the serving network and forwarded to the home operator via TAP charging messages. There are also several alternatives to share a secret between a UE and a home network which is unknown to the visited network. One option is to run an authentication and key agreement function (AKA) twice, but do not share the integrity protection key with the visited network for the second run. An advantage of this method is that there is no impact on existing SIM cards. In later phases of the 5G standardization it is possible that a key derivation function (KDF) will be used to derive all session keys from home network to visited network, i.e. the visited network does not receive the home network's keys but keys dedicated to the visited network derived from the home network's keys. In this case, the integrity protection key of the home network, now unknown to the visited network, can be used.

Particular aspects of the invention may give an operator control over roaming charges and/or establish more reliable roaming charge business agreements. An implementation of the invention may be based on technical means instead of trust and the invention enables a user to avoid fraud relating to roaming charges.

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 is a schematic representation of a mobile management entity requesting authentication vectors from a home environment Fig. 2 is a schematic representation of an authentication and key agreement procedure; and

Fig. 3 is a message flow chart illustrating an embodiment of the invention. In a first embodiment, a known initial challenge response mechanism called

"authentication and key agreement" (AKA), in which session keys are generated is run twice in order to generate two different integrity keys. In a legacy LTE roaming scenario AKA is performed between a UE and a mobility management entity (MME) of the serving network once. The MME requests an authentication vector from the home operator including the challenge, the root session key KASME and the expected response to the challenge. The MME sends the challenge to the UE; the UE calculates the response to this challenge and the corresponding root session key. The UE sends the response back to the MME. The MME verifies the response with the help of the expected response. The generated session key is stored together with an identifier KSIASME in the UE and the MME and is used to establish a security context to the UE. The AKA procedure is described in 3GPP TS 33.401 v15.0.0.

In this embodiment, the AKA procedure is performed twice. The first run is as described above. In the second run only the challenge and the expected response is transferred from the home network to the serving network, i.e. a session root key KASME2 is kept in the home network and not given to the serving (visited) network. A root for the session key hierarchy for the security context between serving network and UE is KASMEI and the integrity protection key for the service confirmation message is derived from KASME2. Since the serving network has no knowledge of KASME2, the integrity protected service validation messages, signed with the integrity protection key only the UE and the home operator share with each other, cannot be generated by the serving network but only by the UE. In case the serving network changes the content of the service validation message the integrity verification in the home network will fail. Fig. 1 illustrates an MME requesting one or more authentication vectors from a subscriber database in the home environment (HE) of the home operator's network. The AKA procedure is illustrated in Fig. 2 (prior-art).

In later standardization releases the current session keys known in the home network may not be forwarded from the home operator to the serving network. Accordingly, in a second embodiment, the session keys of the home operator stay only with the home operator and the session keys used in the serving network will be derived from the existing keys in the home network and the UE instead. In this case, the above procedure of a second AKA run is obsolete, as the UE and home operator can integrity protect their communication via the home operator's session keys. If service validation messages are an optional feature that is only performed by the UE and the serving network in case the home network is requesting, it is then necessary to signal the request from the home operator's network to the serving network. It is beneficial to add the information in the response to the authentication request from the HE to the MME in the serving network. In a third embodiment, the home operator's network requests service validation messages in one or more dedicated messages to the serving network. In a fourth embodiment, the HE requests service authentication messages from the serving network implicitly by responding with one authentication vector more than requested. Also, the UE needs to receive a request to generate service validation messages. This request could be sent as additional piece of information from home operator's network or serving network in the authentication process, e.g. in a non-access stratum (NAS) security mode command message. In another embodiment service validation messages are requested by the serving network to the UE in one or more dedicated messages. In one embodiment, the serving network requests service validation messages during an attach procedure, e.g. during authentication process or security context setup. In another embodiment, the serving network requests service validation messages on a per bearer basis during the bearer setup procedure. It is beneficial for the serving network to request a corresponding periodicity for the generation of service validation messages in the UE. In another embodiment, the UE decides the periodicity based on stored policy information provided by the home operator's network.

Whether service validation messages are requested and in which periodicity the UE is requested to generate service validation messages is in the home operator's discretion. It could be a per subscriber policy, or a per access class policy, or based on UE capabilities. In one embodiment, a service validation messages policy is stored in the HE of the home operator's network. In another embodiment, the service validation messages policy is part of a policy control and charging function (PCCF). The service validation messages sent from the UE via the visited network to the home network have to be protected from replay attacks. This could be performed with timestamps or message sequence numbers or both. The first service validation message could be a validation in advance, i.e. it validates the setup or the reception of a configuration for setup of a service without a significant service provision being validated. This first service validation message should include a time stamp or the message sequence number 1 and when the second validation message can be expected; e.g. in one minute or in 100 Kbyte roaming data traffic or at the end of a phone call. From the second service validation message onwards, (for each service) the messages could include additional feedback information for the previous service period such as voice call quality for the previous minute of the voice call or the data rate of the last 100 Kbyte roaming data traffic.

The following is an example of such a service validation message.

ID: Subscriber ID; e.g. GUTI (global unique temporary ID)

Ver: Protocol version information

SEQ: Message sequence number; e.g. 16 bit

TS: Timestamp

P: Expected periodicity of service validation messages for this service

SID: Service identifier (e.g. local breakout data service, voice call, bearer or PDU session ID)

FB: Feedback information for current service

MAC: Message authentication code as integrity protection with shared session key.

An exemplary message flow chart is shown in Fig. 3. A user turns on his UE in a foreign country. The UE finds during the registration procedure, step 1 , a serving network with which the home operator has a roaming agreement. A home operator controlled list of allowed networks is stored in the SIM. The serving network requests in step 2 an authentication vector from the home operator for the roaming user. A mobility

management entity MME of the serving network requests in step 3 one or more authentication vectors AV from a home environment HE of the home network. The HE responds in step 4 with the requested authentication vector and one additional authentication vector. The home network MME forwards in step 5 a session key for integrity protection derived out of the additional authentication vector to a charging gateway function. The serving network receives in step 6 two authentication vectors AV. One is complete as known in the prior-art and in a second AV according to the invention the root of the session key hierarchy (at least the session key for integrity protection) is not included. Reception of an additional authentication vector could implicitly signal the serving network that service validation messages are requested from the home operator network. This request could also be explicitly with a NAS service validation request within messages between the MME and HE according to 3GPP TS 33.401. The AKA run as part of the authentication procedure in the prior-art according to TS 33.401 is not shown in the figure. The serving network then performs a second AKA (or the potential successor AKA ^* ) procedure in step 7 in which the serving network signals in a NAS security mode command message to the UE that the session key for integrity protection of this additional AKA run shall be used to sign service validation messages and that these service validation messages are requested. The UE confirms in step 8 the request in the NAS security mode complete message to the serving network. The integrity protection key resulting of the second AKA run is stored in the UE in order to generate the MAC field of service validation messages. The user now initiates a locally routed voice call and therefore a first service validation message is generated in the UE and sent in step 9 a NAS service validation message to the serving mobility management entity (MME) of the serving network. The first service validation message contains the GUTI of the user, the message sequence number "1 ", current time stamp, expected periodicity of one minute, as service identifier "local voice call", empty feedback information field and a valid message authentication code for the first seven fields of the message.

The serving network MME forwards in step 10 the validation message to the charging data function CDF. The CDF also receives in step 1 1 a charging events message from the charging trigger function CTF and generates a CDR and according to this invention concatenates the service validation message to the CDR. As the service validation messages are generated by the UE autonomously, configured or influenced by the home or visited network. It is beneficial to synchronize a service validation message with the CDRs, so that with each CDR a corresponding service validation message is

concatenated, but a not synchronous solution would be possible as well. In this case a single CDR may include zero, one or more validation messages depending on availability of the message in the CDR. In case more than one service validation messages are contained in a single CDR, some may validate previous CDRs that did not contain service validation messages.

The CDR (with the service validation message concatenated) produced by the CDF is transferred in step 12 immediately to the charging gateway function CGF via the Ga reference point. The CGF generates in step 13 a TAP charging message with the service validation message included, which is transferred via the CAMEL interface over SS7 to the CGF of the home operator. The CGF of the home operator validates in step 14 the requested service validation message before proceeding with the charging procedure.

An alternative to the above is the generation of service validation messages based on a trigger from the visited network. The CDF or any other entity of the charging system of the visited network may trigger the UE in a new NAS message or with new information in a known NAS message to generate a service validation message so that it is ensured that every TAP charging message includes one service validation message validating the charged-for service. In this alternative, as the UE does not control the time of generation of service validation messages, the messages may not contain any information about expected next service validation message, i.e. there is no periodicity information.

Service validation messages may be generated in the UE to validate a setup or provision of a service by a visited (roamed-to) network. The service validation message may comprise service information relating to a service setup or provisioned by the visited network and a signature validating the service information to the home network.

The invention provides in one aspect a transmission of the service validation message to the visited network for transmission to the home network in relation to a charging information from the visited to the home network about a setup or provisioned service to be charged (CDR).

In summary, this invention provides for the transmission of service validation messages by a visited network to the home network in relation to a charging information (CDR) from the visited to the home network about a setup or provisioned service to be charged. The Service validation messages may comprise integrity protection with a key shared between UE and home operator, replay protection with timestamps or message sequence numbers or both, first service validation message in advance, expected periodicity of following messages in a first message or all messages, feedback for last service period, a service validation message per service; e.g. data traffic and voice call service, and service validation messages triggered by the visited network, i.e. generated on-demand from the visited network. An Integrity protection key shared between UE and home operator is either generated via a second AKA run, or achieved by deriving exclusive session keys for the serving network.