Field

The present invention relates to the field of registration of a network user, e.g. a subscriber, in an Internet Protocol Multimedia Subsystem (IMS) core network.

Background

In order to achieve access independence and to maintain a smooth interoperation with wired terminals across the Internet, the IMS as specified e.g. in the 3GPP (3rd Generation Partnership Project) specifications TS 23.228, 24.228, 24.229 and 23.218 has been developed to be conformant to IETF (Internet Engineering Task Force) "Internet Standards". The IP multimedia core network (IM CN) subsystem enables network operators of mobile or cellular networks to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. The intention is to develop such services by mobile network operators and other 3rd party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IM CN subsystem. The IMS thus enables conversions of, and access to, voice, video, messaging, data and web- based technologies for wireless users, and combines the growth of the Internet with the growth in mobile communications.

In the following, two registration-related scenarios and their underlying problems are described.

In a first scenario, a network operator wishes to modify specific details of a subscriber profile and subscription through a home subscriber server (HSS) front end. As part of this modification, the operator may also intend to modify the Mobile Station Integrated Services Digital Network Number (MSISDN) of a subscriber. Reasons for this may be that the mobile number of the subscriber has been subjected to change for the same subscriber identity module (SIM) or the operator wants to make MSISDN derived IP multimedia public identity (IMPU) as default IMPU or a swap needs to be initiated due to SIM theft or loss or SIM conversion. If the MSISDN is modified under certain conditions, the HSS will trigger a registration termination request (e.g. Cx-Registration_Termination_Request (Cx- RTR)) over the Cx interface towards a Serving Call Session Control Function (S- CSCF). The Cx-RTR is sent with a de-registration reason attribute value pair (AVP) that will communicate the reason behind the administrative de-registration at the FISS. At the S-CSCF, the specific handling is dependent on the de-registration reason AVP. If a permanent termination de-registration reason AVP is received, the S-CSCF will remove the registration data and trigger a registration event notification request (e.g. REG-EVENT NOTIFY) towards the related user equipment (UE). The registration event notification request is then constructed with an event value set to “Rejected” due to permanent termination indication of the de-registration reason AVP of the Cx-RTR request. In this first scenario, the operator would want the UE to perform re registration immediately. However, with the event value“Rejected”, the UE will not perform a re-registration and the S-CSCF will not be able to differentiate between a permanent or temporary termination of the subscription based on the information received in Cx-RTR request to construct a scenario-specific registration event notification request.

In a second scenario, as per 3GPP specification TS 24.229, a network- initiated re-authentication is triggered from the network. Here, the operator dictates a re-authentication for those subscribers who are in suspicion with respect to authentication. From the technical specification, the event is triggered from the S- CSCF. On event trigger, the S-CSCF will trigger a notification request (e.g. NOTIFY) to the UE. Now, the UE should perform a re-registration, and the S-CSCF should re-authenticate the UE. However, re-authentication is triggered at the S- CSCF and there is no standard interface where the operator could initiate this procedure.

As a consequence of both scenarios, there is a dependency on a proprietary tool at the S-CSCF to trigger a re-authentication or re-registration procedure that would be exposed to the external world with a security threat. Moreover, on a multi vendor scenario where there are S-CSCFs from different vendors with a common FISS, these proprietary tools must be implemented by all S-CSCF vendors of a given network. However, exposing the S-CSCF interface to the external world through a proprietary tool to trigger re-authentication is always a security threat.

Summary

There is provided according to a first aspect a method comprising:

generating at a subscriber database of a terminal device a registration termination request for de-registering the terminal device;

adding to the registration termination request an indication that registration of the terminal device shall be terminated temporarily; and

forwarding the registration termination request with the indication to a serving network element of the terminal device.

According to a second aspect there is provided a method comprising:

receiving at a serving network element of a terminal device a registration termination request for de-registering the terminal device, the registration termination request comprising an indication that registration of the terminal device shall be terminated temporarily; and

generating at the serving network element in response to the indication a notification with an attribute that signals a deactivated state to the terminal device.

The registration termination request may be a Diameter Cx-RTR request and the indication may be an attribute value pair (AVP).

The serving network element may be a Serving Call Session Control Function of an IMS core network.

The subscriber database may be a home subscriber server of the IMS core network.

The notification may be a SIP NOTIFY request. According to a third aspect there is provided an apparatus configured to generate a registration termination request for de-registering a terminal device; add to the registration termination request an indication that registration of the terminal device shall be terminated temporarily; and forward the registration termination request with the indication to a serving network element of the terminal device.

According to a fourth aspect there is provided an apparatus configured to receive a registration termination request for de-registering a terminal device served by the network element, the registration termination request comprising an indication that registration of the terminal device shall be terminated temporarily; and generate in response to the indication a notification request with an attribute that signals a deactivated state to the terminal device. According to a fifth aspect there is provided a system comprising a subscriber database with an apparatus according to the third aspect and at least one network element with an apparatus according to the fourth aspect.

According to a sixth aspect there is provided an apparatus comprising means for performing the respective actions of the methods according to the first or second aspect.

According to a seventh aspect there is provided an apparatus configured to perform the respective actions of the method according to the first or second aspect.

According to an eighth aspect there is provided a computer program comprising program instructions for causing a computer to perform the method as described above.

The computer program product may be stored on a medium and may cause an apparatus to perform the method as described herein. A chipset may comprise the apparatus as described herein.

Embodiments of the present application aim to address problems associated with the state of the art.

Summary of the Figures

For a better understanding of the present application, reference will now be made by way of example to the accompanying drawings in which:

Figure 1 shows schematically an architecture of an IMS network, in which some embodiments can be implemented;

Figure 2 shows schematically a signalling diagram of an IMS registration procedure; and

Figure 3 shows schematically a signalling diagram of an operator-triggered re-registration or re-authentication procedure according to an embodiment.

Embodiments of the Application

The following describes in further detail suitable systems, apparatuses and possible mechanisms for triggering a re-registration and/or re-authentication in an IMS network as shown in Figure 1. It is however noted that the described embodiments may also be implemented in other systems, apparatuses and possible mechanisms for other types of networks with subscriber database and serving control network elements. More specifically, the following embodiments address the initially presented scenarios in which immediate UE re-registration and/or re-authentication is expected by the network.

Figure 1 shows an architecture of an IMS network according to the above 3GPP specification. The architecture is based on the principle that the service control for home-subscribed services for a roaming subscriber is in the home network HN. In Fig. 1 , an S-CSCF 10 is shown, which currently controls or serves a terminal device or user equipment (UE) 40 according to the subscriber profile or network coverage of the UE 40.

In general, the S-CSCF 10 performs the session control service for the served UE 40. It maintains a session state as needed by the network operator for support of the services which may be provided by an application server (AS) 60 which may be located in an external network or in the home network HN or a visited network VN of the UE 40. Within an operator's network, different S-CSCFs may have different functionalities. The functions performed by the S-CSCF 10 during a respective session are e.g. registration, session flow management, charging and resource utilization management. When a subscriber roams to the visited network VN, the visited network VN supports a Proxy-CSCF (P-CSCF) 30 which enables the session control to be passed to the respective S-CSCF located at the home network HN and providing the service control. Furthermore, an Interrogating-CSCF (l-CSCF) 50 is provided in the home network HN as a contact point within the operator's network for all connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. There may be multiple l-CSCFs within an operator's network. The functions performed by the l-CSCF 50 include assigning an S-CSCF to a user performing a registration procedure, routing a request received from another network towards the assigned S-CSCF, maintaining the address of an S-CSCF from a subscriber database, e.g. a Home Subscriber Server (HSS) 20 as shown in Fig. 1 , and/or forwarding requests or responses to the S-CSCF 10 determined based on the address retrieved from the HSS 20.

The P-CSCF 30 is the first contact point within the IMS. Its address is discovered by the UE 40 following a PDP (Packet Data Protocol) context activation. The P-CSCF 30 behaves like a proxy, i.e. it accepts requests and services them internally or forwards them on, possibly after translation. The P-CSCF 30 may also behave as a user agent, i.e. in abnormal conditions it may terminate and independently generate transactions. The functions performed by the P-CSCF 30 are forwarding register requests received from the UE 40 to an l-CSCF, e.g. the I- CSCF 50, determined using the home domain name as provided by the UE 40, and forwarding requests or responses to the UE 40.

Further details regarding the functions of the different CSCF elements shown in Fig. 1 can be gathered from the above mentioned 3GPP-specifications.

A 3GPP IMS registration is triggered by the UE 40 and is performed by the IMS core network elements. The S-CSCF 10 and the HSS 20 are the core network elements that are involved in the IMS registration. As part of the registration procedure, the S-CSCF 10 updates its address in the FISS 20 and downloads the service-profile for that subscriber that is provisioned in the HSS 20. The S-CSCF 10 also performs a third-party registration on behalf of UE 40. The IMS core network supports registered and unregistered services to IMS and non-IMS subscribers based on the subscription. The subscriber data is stored in a backend database and the operator manages the user subscription through the front end HSS 20, where the operator is enabled to access and modify the subscriber profile and service-profile. Based on the modification of the subscriber profile, the HSS 20 interacts with the S-CSCF 10 on the so-called Cx interface for any further action based on the Diameter protocol.

The Diameter protocol is used in the IMS architecture for IMS entities to exchange authentication, authorization, and accounting (AAA) related information. A Diameter message is the base unit to send a command or deliver a notification to other Diameter nodes. For different purposes, the Diameter protocol has defined several types of Diameter messages, which are identified by their command code. Because the message exchange style of Diameter is synchronous, each message has its corresponding counterpart, which shares the same command code. The command code is used to identify the intention of a message, but the actual data is carried by a set of attribute value pairs (AVPs). The Diameter protocol has predefined a set of common attributes and imposes each attribute with a corresponding semantic. These AVPs carry the detail of AAA as well as routing, security, and capability information between two Diameter nodes. In embodiments, UE re-registration and/or re-authentication can be triggered at the times of a network-initiated de-registration from the HSS 20. One of the use-cases is where the operator modifies the MSISDN as explained above. Here, the operator intends the UE 40 to re-register immediately after the network- initiated de-registration.

However, in a conventional scenario, the registration termination request (e.g. Cx-RTR) is triggered with the de-registration reason AVP set to“permanent termination”. The S-CSCF 10 reads “permanent termination” as it is and understands that the operator has permanently removed the registration/subscriber from the network. However, in this case, the operator’s intention is to change the MSISDN and the UE 40 is thus expected to perform a re-registration immediately. But here the S-CSCF 10 makes an ambiguous decision of sending a notification request with a reason code that indicates a rejection due to the permanent termination AVP received from the HSS 20. Because of this reason-code, the UE 40 will never retry for a re-registration. Had the S-CSCF 10 communicated“de activated” in the notification request, the UE 40 would have performed a re registration as expected by the operator. Since, there is no trigger for a re registration to the UE 40, the only way to recover is to switch-off and switch-on the device. This is a recent customer scenario.

It is therefore proposed in embodiments to enhance the registration termination request (e.g. Cx-RTR) to carry a specific information of this use-case of temporary termination of a registration. Presently, as per the 3GPP standard 29.229, the de-registration reason AVP can be set to“permanent termination”,“new server assigned”,“server change”, and“remove S-CSCF”. The enhancement can now be achieved by introducing a new value for the de-registration reason AVP that will indicate a“temporary de-registration” of the subscriber, as the subscriber is expected to re-register and/or re-authenticate immediately. Based on the standards, the UE 40 will then trigger re-registration and/or re-authentication on reception of a registration event notification (e.g. reg-event NOTIFY) with the event parameter set to“de-activated” from the S-CSCF 10. The IMS architecture shown in Figure 1 refers to a set of core network entities using the services provided by the packet-switched domain to offer multimedia services. The HSS 20 is the master database for a given user and includes the functions of conventional home location registers (HLRs) as well as new functionalities specified to IP networks, such as the IMS. The HSS 20 is the entity containing the subscription-related information to support the network entities actually handling calls and/or sessions. In the following, an IMS registration procedure is explained based on a schematic signalling diagram shown in Figure 2. It is noted that the IMS registration procedure involves both Session Initiation Protocol (SIP) and Diameter transactions. SIP is a communications protocol for signalling and controlling multimedia communication sessions in applications of Internet telephony for voice and video calls, in private IP telephone systems, as well as in instant messaging over IP networks.

In step S201 , a registration request (Register) is triggered by the UE 40. Based on the authentication scheme, the authorization header of the registration request will be constructed by UE 40. At the l-CSCF 50, based on the IMPU received in the registration request, the best S-CSCF is selected. As part of the server selection, a Diameter authorization transaction which consists of a user authorization request (e.g. Cx-UAR) and a user authorization answer (e.g. Cx-UAA) is exchanged with the HSS 20 in respective steps S202 and S203 to learn the capabilities of the UE 40 and the registration request is then forwarded to the best S-CSCF 10 in step S204.

At the S-CSCF 10, authentication vectors are requested and received through a further diameter transaction with the HSS 20, which consists of a multimedia authentication request (e.g. Cx-MAR) and a multimedia authentication answer (e.g. Cx-MAA) in respective steps S205 and S206. Based on the authentication vectors received, the S-CSCF 10 triggers an authentication procedure, constructs a response (e.g. 401 Unauthorised) with challenge parameters, and sends it in step S207 to the UE 40.

The UE 40 responds in step S208 with a proper challenge response in a second initial registration request (e.g. Register). The second initial registration request follows the same path as the first initial register request to reach the right server, i.e. the S-CSCF 10, after authorization and registration steps S209 to S21 1 . Once authenticated by the S-CSCF 10, the S-CSCF 10 assigns the user at the FISS 20 with Diameter server assignment transactions (e.g. Cx-SAR and Cx-SAA) in steps S212 and S213. Finally, in step S214, completion of the registration request is signalled from the S-CSCF 10 to the UE 40 by a SIP 2000K response.

Figure 3 shows schematically a signalling diagram of an operator-triggered re-registration or re-authentication procedure according to an embodiment. This procedure allows an operator to trigger a subscriber re-registration and/or re authentication, e.g., based on an introduction of a new value of the de-registration- reason AVP in the Cx interface.

As per 3GPP standards 29.228 and 29.229, the de-registration reason AVP is part of the Diameter registration termination request (e.g. Cx-RTR) triggered by the HSS 20 towards the S-CSCF 10. The new AVP value should indicate a temporary termination of the registration and can be inserted by the HSS 20 in the de-registration reason AVP, if there is need for the UE 40 to initiate an immediate re-registration and/or re-authentication procedure.

In case of the above first scenario, if the operator changes in step S301 at the HSS 20 the MSISDN from which the IMPU is derived, the HSS 20 shall create in step S302 a registration termination request (e.g. Cx-RTR) with the de- registration reason AVP set to the new value which indicates “temporary termination” and send it to the S-CSCF 10. Since all the registered UEs for this implicit registration set (IRS) must perform re-registration, the HSS 20 inserts an associated identities AVP along with a user name AVP. In case of the above second scenario, if the operator suspects the subscriber authenticity, he triggers a re-authentication from the HSS 20 in step S301 . In response thereto, the HSS 20 creates the registration termination request (e.g. Cx- RTR) with the de-registration reason AVP set to the new value which indicates “temporary termination” and sends it to the S-CSCF 10 in step S302. Based on the list of UE that need to be re-authenticated, the user name AVP and associated identities AVP of the registration termination request must be filled in.

On receiving the registration termination request from the HSS 20 with the de-registration reason AVP set to “temporary termination”, the S-CSCF 10 processes the registration termination request and triggers in step S303 a notification request (e.g. NOTIFY for reg-event subscription) with the below details as explained in 3GPP specification 24.229, in which the network expects the UE 40 to perform re-registration and/or re-authentication on reception of the notification request. Then, in step S304, the S-CSCF 10 responds to the HSS 20 with a registration termination answer (e.g. Cx-RTA). In step S305, completion of the registration termination request is signalled from the UE 40 to the S-CSCF 10 by a SIP 200OK response.

As expected, the UE 40 now triggers in step S306 a re-registration request (e.g. Re-Register) towards the S-CSCF 10. At the S-CSCF 10, authentication vectors are requested and received through the related Diameter transaction with the HSS 20, which consists of a multimedia authentication request (e.g. Cx-MAR) and a multimedia authentication answer (e.g. Cx-MAA) in respective steps S307 and S308. Based on the authentication vectors received, the S-CSCF 10 triggers an authentication procedure, constructs a response (e.g. 401 Unauthorised) with challenge parameters, and sends it in step S309 to the UE 40.

The UE 40 responds in step S310 with a proper challenge response in a registration request (e.g. Register). Now, the S-CSCF 10 assigns the user at the HSS 20 with Diameter server assignment transactions (e.g. Cx-SAR and Cx-SAA) in steps S31 1 and S312. Finally, in step S313, completion of the re-registration request is signalled from the S-CSCF 10 to the UE 40 by a SIP 200OK response. The notification request of step S303 may be constructed with the following details:

• the body of the notification request may include as many elements as many public user identities the S-CSCF 10 is aware of the user owns;

• an address-of-record (aor) attribute within each element may be set to one public user identity that needs to be de-registered as below:

o the sub-element inside each sub-element of each element may be set to the respective contact address provided by the UE 40;

o the state attribute within the element may be set to "terminated"; o the state attribute within each element belonging to the UE 40 may be set to "terminated";

o the event attribute within each element belonging to the UE 40 may be set to "de-activated" if the S-CSCF 10 expects the UE 40 to re register.

With new de-registration reason AVP value (i.e. “temporary termination”) added, the specific scenarios explained above can be addressed by the S-CSCF 10 without any ambiguity. The proposed solution offers a standard method to trigger a UE re-registration and/or re-authentication procedure from the FISS 20. Moreover, in a multi-vendor scenario where the S-CSCF 10 is from multiple vendors with a common HSS 20, re-authentication trigger from the common HSS 20 would be more efficient than on individual S-CSCF avoiding duplicate proprietary methods to be implemented on different vendor S-CSCFs to accommodate re-authentication functionality.

As the only interface in which the operator manages the subscriber data securely is the HSS 20, the operator can manage the re-registration and re authentication from HSS within a secure channel.

By contrast, the“shortened” attribute for re-authentication, as defined in the 3GPP specification 24.229, requires the S-CSCF to trigger a shortened notification request to the UE. The expiry value is set to a minimum configured expiry value. This approach has a gap since it only shortens the lifespan of a registration and there is no immediate action until the UE re-registers. If there is a service or call triggered by the UE in between the “shortened” notification request and re authentication due to re-registration from the UE, the call is still let to establish and there is a gap for illegal usage of resources from malicious users. Once the call is established in this window, the call can be kept active even after re-registration and re-authentication based on certain service-profile parameters defeating the purpose of re-authentication. The proposed solution fixes this gap by de-registering the current registration immediately and sending a notification request with event attribute set to“de-activated” for the UE to trigger registration immediately.

The present solution addresses such gap in that it requires an administrative method to trigger a subscriber to initiate a re-registration and/or a re-authentication. As part of the de-registration, the S-CSCF clears all authentication vectors that are locally stored along with the registration data. For the re-registration request, the new set of authentication vectors is downloaded from the HSS to perform a fresh authentication procedure.

As an additional aspect, the UE can learn of a change of the IRS via the re registration that is triggered by the FISS. Thus, the proposed solution not only enables an immediate re-registration and/or re-authentication procedure by the HSS, but also pushes information about an IRS change to the UE. For this case, the UE will then initiate a fresh registration and not a re-registration, as the registration was already terminated at the S-CSCF.

It is noted that the present invention is not restricted to the preferred embodiments described above. The present invention may be implemented in any data network, where a subscriber registration can be terminated. The embodiments may thus vary within the scope of the attached claims. In general, the various embodiments of the invention may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The embodiments of this invention may be implemented by computer software executable by a data processor of the flight control unit, or by hardware, or by a combination of software and hardware. Further in this regard it should be noted that any blocks of the logic flow, e.g., as in the Figure 3, may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multi-core processor architecture, as non-limiting examples. Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

The foregoing description has provided by way of exemplary and non- limiting examples a full and informative description of exemplary embodiments of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims.