WO2022021361A1

WO2022021361A1 - Method and network node for facilitating push notification service

Info

Publication number: WO2022021361A1
Application number: PCT/CN2020/106296
Authority: WO
Inventors: Debashish PATTNAIK; Erqun SUN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ); Debashish PATTNAIK
Priority date: 2020-07-31
Filing date: 2020-07-31
Publication date: 2022-02-03

Abstract

The present disclosure provides a method (300) in a network node. The method (300) includes: transmitting (310), to a Push Notification Server, PNS, a request for subscribing to notification of an Internet Protocol 'IP' Multimedia Subsystem, IMS, registration status of a terminal device; and receiving (320), from the PNS, a first notification of a first IMS registration status of the terminal device.

Description

METHOD AND NETWORK NODE FOR FACILITATING PUSH NOTIFICATION SERVICE

TECHNICAL FIELD

The present disclosure relates to communication technology, and more particularly, to a method and a network node for facilitating a push notification service.

BACKGROUND

A push notification, also known as a server push notification, refers to a service to deliver information indicating an incoming request for a transaction from an application server to a terminal device, where the request is initiated by the application server rather than by the terminal device.

In order to save resources, e.g., battery lives, some devices and Operating Systems (OSs) will suspend applications when they are not used. In this case, one way to wake an application is by using a push notification service. Typically, each operating system uses a dedicated push notification service. For example, Apple's iOS devices use Apple Push Notification (APN) services while Android devices use Firebase Cloud Messaging (FCM) services.

Fig. 1 is a schematic diagram showing an implementation of push notification as defined in the 3 ^rd Generation Partnership Project (3GPP) . When there is a terminating request, e.g., a terminating call, targeted to a terminal device that is in a sleeping mode, a Proxy Call Session Control Function (P-CSCF) node may send a push notification request ( “push request” in Fig. 1) to a Push Notification Server (PNS) ( “Push Service” in Fig. 1) . Then, the PNS may forward the request to the terminal device for waking it up. As a result, the terminal device may reregister with an IMS core network so as to receive and handle the terminating request accordingly. On the other hand, the P-CSCF node may send push notification requests to the PNS in a timer-based manner for waking the terminal device to reregister with the IMS core network periodically, even without any terminating requests, in order to keep the terminal device registered with the IMS core network.

However, in Apple's iOS 13 and onwards, applications are only allowed to use push notifications, e.g., Voice over Internet Protocol (VoIP) Push Notifications, for incoming voice/video calls. As a result of such restriction, the timer-based push notifications without terminating calls will be blocked by the OS.

Fig. 2 is a sequence chart showing an exemplary process of push notification and registration. As shown in Fig. 2, at 2.1, a terminal device sends an IMS registration request to a P-CSCF (P-CSCF 1) . At 2.2, the P-CSCF 1 forwards the IMS registration request to an IMS core network. At 2.3, the IMS core network sends an IMS registration success response to the terminal device. Then, the terminal device may enter a sleeping mode for power saving and the P-CSCF 1 will send push notification requests to a PNS (not shown) for waking the terminal device to reregister with the IMS core network periodically. However, in the iOS 13 and upper versions case as described above, the push notifications will be blocked by the terminal device. As another example, the push notifications may not reach the terminal device, e.g., when a related application in the terminal device is killed, or when the terminal device loses its network connection. In this case, the P-CSCF 1 may trigger IMS reregistration on behalf of the terminal device, e.g., by sending reregistration requests to the IMS core network at 2.4, 2.5, 2.6, 2.9, and 2.12, so as to allow the terminal device to remain registered with the IMS core network.

While the P-CSCF 1 keeps sending reregistration requests to the IMS core network on behalf of the terminal device, the terminal device may wake up from the sleeping mode, restart the related application, or reestablish its network connection, and may randomly select another P-CSCF (P-CSCF 2) and send an IMS registration request to the P-CSCF 2 at 2.7. At 2.8, the P-CSCF 2 forwards the IMS registration request to an IMS core network. At 2.10, the IMS core network sends an IMS registration success response to the terminal device. Then, the P-CSCF 2 may keep sending reregistration requests to the IMS core network on behalf of the terminal device periodically, e.g., once the terminal device enters the sleeping mode, and the push notifications towards the terminal device are blocked, as shown at 2.11 and 2.13.

SUMMARY

In the example shown in Fig. 2, the reregistration requests by the P-CSCF 1, especially those at 2.9 and 2.12, would be unnecessary and result in a waste of processing and network resources. In addition, from the perspective of the IMS core network, there are two valid registrations for the terminal device at the same time, one via the P-CSCF 1 and the other via the P-CSCF 2. When there is a terminating call towards the terminal device, the IMS core network does not know which P-CSCF it shall forward the call to. If the IMS core network forwards the call to the wrong P-CSCF (in this case, the P-CSCF 1) , the call will fail and the IMS core network may need to forward it to the other P-CSCF (in this case, the P-CSCF 2) , which is inefficient.

It is an object of the present disclosure to provide a method and a network node for facilitating push notification, capable of eliminating or mitigating at least some of the problems as described above.

According to a first aspect of the present disclosure, a method in a network node is provided. The method includes: transmitting, to a PNS, a request for subscribing to notification of an IMS registration status of a terminal device; and receiving, from the PNS, a first notification of a first IMS registration status of the terminal device.

In an embodiment, the first notification may be received when the network node maintains an IMS registration status indicating that the terminal device has registered with a first IMS core network through the network node, and the first IMS registration status may indicate that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.

In an embodiment, the method may further include: removing, in response to receiving the first notification, contact binding for the terminal device from the network node.

In an embodiment, the method may further include: transmitting, in response to receiving the first notification, to the PNS a request for unsubscribing from the notification.

In an embodiment, the method may further include: prior to receiving the first notification, receiving, from the PNS, a second notification of a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the other network node.

In an embodiment, the method may further include: when the second IMS registration status indicates that the terminal device is registering with the first IMS core network through the other network node, forwarding a call to be terminated at the terminal device to the other network node.

In an embodiment, the method may further include: when the first IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, transmitting, to a core network node in the first IMS core network, a request for IMS deregistration for the terminal device.

In an embodiment, each of the network node and the other network node may be a P-CSCF node.

According to a second aspect of the present disclosure, a method in a network node is provided. The method includes: receiving, from a terminal device, a request for IMS registration; forwarding the request to a core network node in a first IMS core network; receiving, from the core network node, a response to the request, the response indicating that the IMS registration has succeeded; and transmitting, to a PNS, first information on a first IMS registration status indicating that the terminal device has registered with the first IMS core network through the network node.

In an embodiment, the method may further include: subsequent to receiving the request and prior to receiving the response, transmitting, to the PNS, second information on a second registration status indicating that the terminal device is registering with the first IMS core network through the network node.

In an embodiment, the method may further include: subsequent to receiving the request, transmitting, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device; and receiving, from the PNS, a notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.

In an embodiment, the method may further include: when the third IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, prior to transmitting the second information, receiving, from the core network node, information indicating that a porting process for the terminal device has been initiated in the first IMS core network.

In an embodiment, the network node may be a P-CSCF node.

According to a third aspect of the present disclosure, a network node is provided. The network node includes a communication interface, a processor and a memory. The memory stores instructions executable by the processor whereby the network node is operative to perform the method according to the above first or second aspect.

According to a fourth aspect of the present disclosure, a computer readable storage medium is provided. The computer readable storage medium has computer program instructions stored thereon. The computer program instructions, when executed by a processor in a network node, cause the network node to perform the method according to the above first or second aspect.

According to a fifth aspect of the present disclosure, a method in a PNS is provided. The method includes: receiving, from a first network node associated with a first IMS core network, a request for subscribing to notification of an IMS registration status of a terminal device; receiving, from a second network node associated with the first IMS core network or a second IMS core network, first information on a first IMS registration status indicating that the terminal device has registered with the first or second IMS core network through the second network node; and transmitting, to the first network node, a first notification of the first IMS registration status.

In an embodiment, the method may further include: receiving, from the first network node, a request for unsubscribing from the notification.

In an embodiment, the method may further include: prior to receiving the first information, receiving, from the second network node, second information on a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the second network node; and transmitting, to the first network node, a second notification of the second IMS registration status.

In an embodiment, the method may further include: prior to receiving the first information, receiving, from the second network node, a request for subscribing to notification of an IMS registration status of the terminal device; and transmitting, to the second network node, a third notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through the first network node.

In an embodiment, the method may further include: when the second network node is associated with the second IMS core network, transmitting, in response to receiving the request for subscribing from the second network node, to an authentication server a request for provisioning, in the terminal device and in the second IMS core network, authentication parameters required for the terminal device to access the second IMS core network.

In an embodiment, each of the first and second network nodes may be a P-CSCF node.

According to a sixth aspect of the present disclosure, a PNS is provided. The PNS includes a communication interface, a processor and a memory. The memory stores instructions executable by the processor whereby the network node is operative to perform the method according to the above fifth aspect.

According to a seventh aspect of the present disclosure, a computer readable storage medium is provided. The computer readable storage medium has computer program instructions stored thereon. The computer program instructions, when executed by a processor in a PNS, cause the PNS to perform the method according to the above fifth aspect.

With the embodiments of the present disclosure, a P-CSCF can subscribe to notification of an IMS registration status of a terminal device. Once the IMS registration status changes, for example, when the terminal device is registering/has registered through another P-CSCF, a PNS can notify the P-CSCF of the new IMS registration status, such that the P-CSCF can handle the registration of the terminal device at the P-CSCF properly. For example, the P-CSCF can remove contact binding of the terminal device from its local repository and stop triggering reregistration on behalf of the terminal device. In this way, it is possible to save resources which would otherwise be wasted due to unnecessary reregistration requests, while avoiding the call failure issue as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the figures, in which:

Fig. 1 is a schematic diagram showing an implementation of push notification as defined in 3GPP;

Fig. 2 is a sequence chart showing an exemplary process of push notification and registration;

Fig. 3 is a flowchart illustrating a method in a network node according to an embodiment of the present disclosure;

Fig. 4 is a flowchart illustrating a method in a network node according to another embodiment of the present disclosure;

Fig. 5 is a flowchart illustrating a method in a PNS according to an embodiment of the present disclosure;

Figs. 6A-6D are sequence charts showing a process of migration of a terminal device within an IMS core network based on the methods shown in Figs. 3-5;

Figs. 7A-7D are sequence charts showing a process of migration of a terminal device across IMS core networks based on the methods shown in Figs. 3-5;

Fig. 8 is a block diagram of a network node according to an embodiment of the present disclosure;

Fig. 9 is a block diagram of a network node according to another embodiment of the present disclosure;

Fig. 10 is a block diagram of a network node according to yet another embodiment of the present disclosure;

Fig. 11 is a block diagram of a PNS according to an embodiment of the present disclosure; and

Fig. 12 is a block diagram of a PNS according to another embodiment of the present disclosure.

DETAILED DESCRIPTION

In the following, references in the specification to "one embodiment" , "an embodiment" , "an example embodiment" and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed terms. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a" , "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" , "comprising" , "has" , "having" , "includes" and/or "including" , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

Fig. 3 is a flowchart illustrating a method 300 in a network node according to an embodiment of the present disclosure. The method 300 can be performed at, for example, a P-CSCF node (e.g., P-CSCF 1 in Fig. 2) .

At block 310, a request for subscribing to notification of an IMS registration status of a terminal device is transmitted to a PNS. Here, the IMS registration status may indicate whether the terminal device is registering, or has registered, with an IMS core network, and if so, with which IMS core network it is registering or has registered and through which network node (e.g., P-CSCF) it is registering or has registered with the IMS core network.

At block 320, a first notification of a first IMS registration status of the terminal device is received from the PNS.

In an example, the first notification may be received when the network node maintains an IMS registration status indicating that the terminal device has registered with a first IMS core network through the network node. The first IMS registration status may indicate that the terminal device has registered with the first IMS core network through another network node (e.g., another P-CSCF, such as P-CSCF 2 in Fig. 2) . This may be the case when the terminal device has “migrated” to the other network node within the same IMS core network (i.e., the first IMS core network) . In another example, the first IMS registration status may indicate that the terminal device has registered with a second, different IMS core network through another network node (e.g., another P-CSCF, such as P-CSCF 2 in Fig. 2) . This may be the case when the terminal device has “migrated” to a different IMS core network (i.e., the second IMS core network) .

In an example, in response to receiving the first notification, contact binding for the terminal device may be removed from the network node.

In an example, in response to receiving the first notification, a request for unsubscribing from the notification may be transmitted to the PNS.

In an example, prior to receiving the first notification in the block 320, a second notification of a second IMS registration status indicating that the terminal device is registering with the IMS core network through the other network node may be received from the PNS. When the second IMS registration status indicates that the terminal device is registering with the first IMS core network through the other network node, e.g., in a case of migration within the same IMS core network (the first IMS core network) , the network node can forward a call to be terminated at the terminal device to the other network node.

In an example, when the first IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, e.g., in a case of migration across different IMS core networks (e.g., from the first IMS core network to the second IMS core network) , a request for IMS deregistration for the terminal device may be transmitted to a core network node in the first IMS core network. The core network node may be responsible for IMS-related operations such as IMS registration and deregistration. Upon receiving the request for IMS deregistration, the core network node can remove the registration of the terminal device.

Fig. 4 is a flowchart illustrating a method 400 according to another embodiment of the present disclosure. The method 400 can be performed at, for example, a P-CSCF node (e.g., the P-CSCF 2 in Fig. 2) .

At block 410, a request for IMS registration is received from a terminal device.

At block 420, the request is forwarded to a core network node in a first IMS core network. The core network node may be responsible for IMS-related operations such as IMS registration and deregistration.

At block 430, a response to the request is received from the core network node. In an example, the response indicates that the IMS registration has succeeded.

At block 440, first information on a first IMS registration status indicating that the terminal device has registered with the first IMS core network through the network node is transmitted to a PNS.

In an example, subsequent to receiving the request in the block 410 and prior to receiving the response in the block 430, second information on a second registration status indicating that the terminal device is registering with the first IMS core network through the network node may be transmitted to the PNS.

In an example, subsequent to receiving the request in the block 410, a request for subscribing to notification of an IMS registration status of the terminal device may be transmitted to the PNS. A notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through another network node (e.g., another P-CSCF, such as P-CSCF 1 in Fig. 2) may be received from the PNS. This may be the case when the terminal device has “migrated” from the other network node within the same IMS core network (i.e., the first IMS core network) . A notification of a third IMS registration status indicating that the terminal device has registered with a second, different IMS core network through another network node (e.g., another P-CSCF, such as P-CSCF 1 in Fig. 2) may be received from the PNS. This may be the case when the terminal device has “migrated” from a different IMS core network (i.e., the second IMS core network) .

When the third IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, e.g., in a case of migration across different IMS core networks (e.g., from the second IMS core network to the first IMS core network) , prior to transmitting the second information, information indicating that a porting process for the terminal device has been initiated in the first IMS core network may be received from the core network node. Here, the porting process allows the terminal device to retain the current Mobile Station Integrated Services Digital Network (MSISDN) number while changing its subscription permanently to another IMS core network.

Fig. 5 is a flowchart illustrating a method 500 according to an embodiment of the present disclosure. The method 500 can be performed at, for example, a PNS.

At block 510, a request for subscribing to notification of an IMS registration status of a terminal device is received from a first network node (e.g., a P-CSCF, such as P-CSCF 1 in Fig. 2) associated with a first IMS core network.

At block 520, first information on a first IMS registration status is received from a second network node (e.g., a P-CSCF, such as P-CSCF 2 in Fig. 2) associated with the first IMS core network or a second, different IMS core network. The first IMS registration status indicates that the terminal device has registered with the first or second IMS core network through the second network node.

At block 530, a first notification of the first IMS registration status is transmitted to the first network node.

In an example, a request for unsubscribing from the notification may be received from the first network node.

In an example, prior to receiving the first information in the block 520, second information on a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the second network node may be received from the second network node, and a second notification of the second IMS registration status may be transmitted to the first network node.

In an example, prior to receiving the first information in the block 520, a request for subscribing to notification of an IMS registration status of the terminal device may be received from the second network node, and a third notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through the first network node may be transmitted to the second network node.

In an example, when the second network node is associated with the second IMS core network, e.g., in a case of migration across different IMS core networks (e.g., from the first IMS core network to the second IMS core network) , in response to receiving the request for subscribing from the second network node, a request for provisioning, in the terminal device and in the second IMS core network, authentication parameters required for the terminal device to access the second IMS core network may be transmitted to an authentication server.

The

methods

300, 400, and 500 will be explained in further detail below with reference to Figs. 6A-6D and Figs. 7A-7D.

Figs. 6A-6D are sequence charts showing a process of migration of a terminal device within an IMS core network based on the methods shown in Figs. 3-5.

In this example, a terminal device has registered with an IMS core network through a P-CSCF node (P-CSCF 1) in the IMS core network, and is intended to migrate from P-CSCF 1 to another P-CSCF node (P-CSCF 2) in the same IMS core network. Here, P-CSCF 1 may also be referred to as a current P-CSCF, while P-CSCF 2 may also be referred to as a new P-CSCF. Here, an authentication server and a Home Subscriber Server (HSS) may be provisioned with authentication parameters required for the terminal device to access the IMS core network. A PNS is provisioned with projects containing parameters required for push notification services.

At 6.1, the terminal device sends, to the PNS, a push notification subscription request for subscribing to a push notification service provided by a PNS. At 6.2, the PNS sends a subscription success response and provides push service information including push notification parameters such as a Push Resource Identity (PRID) back to the terminal device. At 6.3, the terminal device sends, to P-CSCF 1, an IMS registration request along with all the Push Notification parameters including the PRID provided by the PNS, e.g., in an Initial Session Initiation Protocol (SIP) REGISTER request. At 6.4, P-CSCF 1 sends, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device, so that the PNS shall notify P-CSCF 1 if the IMS registration status of the terminal device gets changed. At 6.5, the PNS accepts the subscription and sends, to P-CSCF 1, a subscription success response. At 6.6, P-CSCF 1 receives, from the PNS, a notification of the IMS registration status of the terminal device. Here, the IMS registration status may indicate whether the terminal device has registered any IMS core network, and if so, with which IMS core network it has registered and through which P-CSCF it has registered with the IMS core network. At 6.7, P-CSCF 1 forwards the received IMS registration request to the IMS core network. At 6.8, the IMS core network verifies the IMS registration request and a corresponding subscriber profile of the terminal device, and sends, to P-CSCF 1, an IMS registration success response. At 6.9, P-CSCF 1 forwards, to the terminal device, the IMS registration success response.

Turning to Fig. 6B, after the terminal device has registered with the IMS core network through P-CSCF 1, it may enter a sleeping mode and be detached from the IMS core network. P-CSCF 1 can re-verify if the terminal device supports the push notification service by verifying the push notification parameters sent by the terminal device at 6.3. If so, P-CSCF 1 will trigger reregistration with the IMS core network on behalf of the terminal device periodically. Thus, the terminal device no longer needs to be woken up by a push notification to trigger reregistration, which can significantly improve the resource efficiency of the terminal device. In particular, at 6.10, P-CSCF 1 sends, to the IMS core network, an IMS reregistration request. At 6.11, the IMS Core network receives the IMS reregistration request and sends a reregistration success response back to P-CSCF 1. P-CSCF 1 shall not forward the reregistration success response to any other node including the PNS or the terminal device. Thereafter, P-CSCF 1 triggers periodical IMS reregistration so as to keep the terminal device registered with the IMS core network.

Then, the terminal device may wake up from the sleeping mode due to various reasons such as restart of the terminal device or auto-upgrade of the OS. Since the deployment is based on dynamic provisioning, when the terminal device wakes up, it is unaware of which P-CSCF node it has previously registered through, which is actually P-CSCF 1. The terminal device cannot have “cache based” P-CSCF mechanism because if the cached P-CSCF is down for any reason, then all calls targeted to the terminal device will fail. Therefore, the terminal device dynamically chooses a P-CSCF node, for example, P-CSCF 2, and performs IMS registration through P-CSCF 2. In particular, at 6.12, the terminal device sends, to P-CSCF 2, an IMS registration request along with all the Push Notification parameters including the PRID provided by the PNS, e.g., in an Initial SIP REGISTER request. At 6.13, P-CSCF 2 sends, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device, so that the PNS shall notify P-CSCF 2 if the IMS registration status of the terminal device gets changed. The PNS receives the request and verifies if P-CSCF 2 belongs to the same IMS core network as P-CSCF 1 or a different IMS core network. In this case, P-CSCF 1 and P-CSCF 2 belong to the same IMS core network. Since the IMS core network has already been provisioned with the authentication parameters, the subscriber provision procedure can be omitted. At 6.14, the PNS accepts the subscription and sends, to P-CSCF 2, a subscription success response. At 6.15, P-CSCF 2 receives, from the PNS, a notification of the IMS registration status of the terminal device, which indicates that the terminal device has registered with the same IMS core network through P-CSCF 1.

Turning to Fig. 6C, at 6.16, P-CSCF 2 forwards the received IMS registration request to the IMS core network. At 6.17, P-CSCF 2 sends, to the PNS, information on an IMS registration status indicating that the terminal device is registering with the IMS core network through P-CSCF 2. At 6.18, the PNS sends, to P-CSCF 1, a notification of the IMS registration status. Then, P-CSCF 1 can forward a call to be terminated at the terminal device to P-CSCF 2. At 6.19, the IMS core network sends, to P-CSCF 2, an IMS registration success response, and now the terminal device is bounded to P-CSCF 2. That is, the terminal device has migrated to P-CSCF 2 belonging to the same IMS core network as P-CSCF 1 successfully. At 6.20, P-CSCF 2 sends, to the PNS, information on an IMS registration status indicating that the terminal device has registered with the IMS core network through P-CSCF 2. At 6.21, the PNS sends, to P-CSCF 1, a notification of the IMS registration status. In response to receiving the notification, P-CSCF 1 removes contact binding for the terminal device from its local repository, and sends, to the PNS, a request for unsubscribing from the notification of the IMS registration status of the terminal device at 6.22. At 6.23, the PNS sends, to P-CSCF 1, an un-subscription success response.

Turning to Fig. 6D, when the terminal device enters a sleeping mode again, P-CSCF 2 will reregister with the IMS core network on behalf of the terminal device periodically. In particular, at 6.24, P-CSCF 2 sends an IMS reregistration request to the IMS core network. At 6.25, the IMS Core network receives the IMS reregistration request and sends a reregistration success response back to P-CSCF 2.

Figs. 7A-7D are sequence charts showing a process of migration of a terminal device across different IMS core networks based on the methods shown in Figs. 3-5.

In this example, a terminal device has registered with an IMS core network (IMS core network 1) through a P-CSCF node (P-CSCF 1) in the IMS core network 1, and is intended to migrate from P-CSCF 1 to another P-CSCF node (P-CSCF 2) in another IMS core network (IMS core network 2) . Here, P-CSCF 1 may also be referred to as a current P-CSCF, while P-CSCF 2 may also be referred to as a new P-CSCF. Correspondingly, the IMS core network 1 may also be referred to as a current IMS core network, while the IMS core network 2 may also be referred to as a new IMS core network. Here, an authentication server and an HSS may be provisioned with authentication parameters required for the terminal device to access the IMS core networks. A PNS can be provisioned with projects belonging to different IMS core networks based on Service Level Agreements (SLAs) and including isolated authentication profiles for each of the IMS core networks. The PNS can ensure that an authentication profile belonging to a particular IMS network cannot be accessed by other IMS networks even though different IMS networks involve in the same project, thereby enabling a terminal device belonging to an IMS core network/operator can seamlessly migrate to another IMS core network/operator dynamically over the wire.

At 7.1, the terminal device sends, to the PNS, a push notification subscription request for subscribing to a push notification service provided by a PNS. At 7.2, the PNS sends a subscription success response and provides push service information including push notification parameters such as a PRID back to the terminal device. Multiple IMS networks/operators may have SLAs to allow migration of the terminal device if it triggers the request for migrating to another IMS core network/operator permanently. In addition, by binding to the same project in the PNS, the IMS core networks/operators also have the agreement to share the push notification parameters including the PRID of the terminal device that's being migrated. At 7.3, the terminal device sends, to P-CSCF 1, an IMS registration request along with all the Push Notification parameters including the PRID provided by the PNS, e.g., in an Initial SIP REGISTER request. At 7.4, P-CSCF 1 sends, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device, so that the PNS shall notify P-CSCF 1 if the IMS registration status of the terminal device gets changed. At 7.5, the PNS accepts the subscription and sends, to P-CSCF 1, a subscription success response. At 7.6, P-CSCF 1 receives, from the PNS, a notification of the IMS registration status of the terminal device. Here, the IMS registration status may indicate whether the terminal device has registered with any IMS core network, and if so, with which IMS core network it has registered and through which P-CSCF it has registered with the IMS core network. At 7.7, P-CSCF 1 forwards the received IMS registration request to the IMS core network 1. At 7.8, the IMS core network verifies the IMS registration request and a corresponding subscriber profile of the terminal device, and sends, to P-CSCF 1 an IMS registration success response. At 7.9, P-CSCF 1 forwards, to the terminal device, the IMS registration success response.

Turning to Fig. 7B, after the terminal device has registered with the IMS core network 1 through P-CSCF 1, it may enter a sleeping mode, and be detached from the IMS core network 1. P-CSCF 1 can re-verify if the terminal device supports push notification service by verifying the push notification parameters sent by the terminal device at 7.3. If so, P-CSCF 1 will trigger reregistration with the IMS core network on behalf of the terminal device periodically. Thus, the terminal device no longer needs to be woken up by a push notification to trigger reregistration, which can significantly improve the y resource efficiency of the terminal device. In particular, at 7.10, P-CSCF 1 sends, to the IMS core network 1, an IMS reregistration request. At 7.11, the IMS core network 1 receives the IMS reregistration request and sends a reregistration success response back to P-CSCF 1. P-CSCF 1 shall not forward the reregistration success response to any other node including the PNS or the terminal device. Thereafter, P-CSCF 1 triggers periodical IMS reregistration so as to keep the terminal device registered with the IMS core network 1.

Then, the terminal device may wake up from the sleeping mode due to various reasons such as restart of the terminal device or auto-upgrade of the OS. Since the deployment is based on dynamic provisioning, when the terminal device wakes up, it is unaware of which P-CSCF node it has previously registered through, which is actually PCSCF 1. The terminal device cannot have “cache based” P-CSCF mechanism because if the cached P-CSCF is down for any reason, then all calls targeted to the terminal device will fail. Therefore, the terminal device dynamically chooses a P-CSCF node, for example, P-CSCF 2, and performs IMS registration through P-CSCF 2. In particular, at 7.12, the terminal device sends, to P-CSCF 2, an IMS registration request along with all the Push Notification parameters including the PRID provided by the PNS, e.g., in an Initial SIP REGISTER request. At 7.13, P-CSCF 2 sends, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device, so that the PNS shall notify P-CSCF 2 if the IMS registration status of the terminal device gets changed. The PNS receives the request and verifies if P-CSCF 2 belongs to the same IMS core network with P-CSCF 1 or a different IMS core network. In this case, P-CSCF 2 belongs to a different IMS core network (the IMS core network 2) , thus a subscriber provision procedure needs to be performed. In particular, at 7.13A, the PNS sends, to the authentication server, a request for provisioning, in the terminal device and in the IMS core network 2, authentication parameters required for the terminal device to access the IMS core network 2. At 7.13B, the authenticating server performs auto-provisioning in the terminal device to ensure the terminal device can access the IMS network 2. At 7.13C, the authentication server performs auto-provisioning of authentication parameters of the terminal device in the IMS core network 2. At 7.14, the PNS accepts the subscription and sends, to P-CSCF 2, a subscription success response. At 7.15, P-CSCF 2 receives, from the PNS, a notification of the IMS registration status of the terminal device, which indicates that the terminal device has registered with the IMS core network 2 through P-CSCF 1.

Turning to Fig. 7C, at 7.16, P-CSCF 2 forwards, to the IMS core network 2, the received IMS registration request. The IMS core network 2 verifies the IMS registration request and a corresponding subscriber profile of the terminal device. At 7.17, the IMS core network 2 sends, to the IMS core network 1, a request for initiation of porting process of the terminal device. Here, the IMS core network 2 may use the authentication parameters provisioned by the authentication server at 7.13C. The porting process may refer to the migration of a terminal device across different IMS core networks. The IMS core network 1 shall activate temporary forwarding/locking option for the terminal device which is being migrated to the IMS core network 2. By enabling temporary forwarding/locking option, the IMS core network 1 ensures that all the new terminating calls towards this terminal device to be forwarded to the IMS core network 2. At 7.18, the IMS core network 1 starts the porting process of the terminal device. It enables the temporary forwarding/locking option so that any call to be terminated at the terminal device will be handled by the new IMS core network, i.e., the IMS core network 2 and informs the IMS core network 2 that the porting process has been initiated successfully. At 7.19, the IMS core network 2 informs P-CSCF 2 that the porting process for the terminal device has been initiated successfully. At 7.20, P-CSCF 2 sends, to the PNS, information indicating that a porting process for the terminal device has been initiated. At 7.21, the PNS sends, to P-CSCF1, a notification of an IMS registration status indicating that the terminal device is registering with the IMS core network 2 through P-CSCF 2, that is, the terminal device is being ported to P-CSCF 2 in the IMS core network 2. At 7.22, the IMS core network 2 sends, to P-CSCF 2, an IMS registration success response, and now the terminal device is bounded to P-CSCF 2. That is, the terminal device has been migrated to P-CSCF 2 in the IMS core network 2 successfully. At 7.23, P-CSCF 2 sends, to the PNS, information on an IMS registration status indicating that the terminal device has registered with the IMS core network 2 through P-CSCF 2, that is the terminal device has been ported to P-CSCF 2 in the IMS core network 2. At 7.24, the PNS sends, to P-CSCF 1, a notification of the IMS registration status indicating that the terminal device has registered with the IMS core network 2 through P-CSCF 2. Then at 7.25, P-CSCF 1 sends, to the IMS core network 1, a request for deregistering the terminal device from the IMS core network 1. In response to receiving the notification of the IMS registration status indicating that the terminal device has registered with the IMS core network 2 through P-CSCF 2, P-CSCF 1 removes contact binding for the terminal device from its local repository. At 7.26, in response to receiving the notification of the IMS registration status indicating that the terminal device has registered with the IMS core network 2 through P-CSCF 2, P-CSCF 1 sends, to the PNS, a request for unsubscribing from the notification of the IMS registration status of the terminal device. At 7.27, the PNS sends, to P-CSCF 1, an un-subscription success response.

Turning to Fig. 7D, when the terminal device enters a sleeping mode again, P-CSCF 2 will reregister with the IMS core network 2 on behalf of the terminal device periodically. In particular, at 7.28, P-CSCF 2 sends an IMS reregistration request to the IMS core network 2. At 7.29, the IMS Core network 2 receives the IMS reregistration request and sends a reregistration success response back to P-CSCF 2.

Correspondingly to the method 300 as described above, a network node is provided. Fig. 8 is a block diagram of a network node 800 according to an embodiment of the present disclosure.

The network node 800 can be, e.g., P-CSCF 1 shown in Fig. 2, 6A-6D, or 7A-7D, and can be configured to perform the method 300 as described above in connection with Fig. 3. As shown in Fig. 8, the network node 800 includes a transmitting unit 810 configured to transmit, to a PNS, a request for subscribing to notification of an IMS registration status of a terminal device. The network node 800 further includes a receiving unit 820 configured to receive, from the PNS, a first notification of a first IMS registration status of the terminal device.

In an example, the first notification may be received when the network node maintains an IMS registration status indicating that the terminal device has registered with a first IMS core network through the network node, and the first IMS registration status may indicate that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.

In an example, the network node 800 may further include a removing unit configured to remove, in response to receiving the first notification, contact binding for the terminal device from the network node.

In an example, the transmitting unit 810 can be further configured to transmit, in response to receiving the first notification, to the PNS a request for unsubscribing from the notification.

In an example, the receiving unit 820 can be further configured to prior to receiving the first notification, receive, from the PNS, a second notification of a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the other network node.

In an example, the network node 800 may further include a forwarding unit configured to when the second IMS registration status indicates that the terminal device is registering with the first IMS core network through the other network node, forward a call to be terminated at the terminal device to the other network node.

In an example, the transmitting unit 810 can be further configured to when the first IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, transmit, to a core network node in the first IMS core network, a request for IMS deregistration for the terminal device.

In an example, each of the network node and the other network node may be a P-CSCF node.

The units 810～820 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing the software, a Programmable Logic Device (PLD) or other electronic component (s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 3.

Correspondingly to the method 400 as described above, a network node is provided. Fig. 9 is a block diagram of a network node 900 according to another embodiment of the present disclosure.

The network node 900 can be, e.g., P-CSCF 2 shown in Fig. 2, 6A-6D, or 7A-7D, and can be configured to perform the method 400 as described above in connection with Fig. 4. As shown in Fig. 9, the network node 900 includes a receiving unit 910 configured to receive, from a terminal device, a request for IMS registration. The network node 900 further includes a forwarding unit 920 configured to forward the request to a core network node in a first IMS core network. The receiving unit 910 is further configured to receive, from the core network node, a response to the request, the response indicating that the IMS registration has succeeded. The network node 900 further includes a transmitting unit 930 configured to transmit, to a PNS, first information on a first IMS registration status indicating that the terminal device has registered with the first IMS core network through the network node.

In an example, the transmitting unit 930 can be further configured to subsequent to receiving the request and prior to receiving the response, transmit, to the PNS, second information on a second registration status indicating that the terminal device is registering with the first IMS core network through the network node.

In an example, the transmitting unit 930 can be further configured to subsequent to receiving the request, transmitting, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device, and the receiving unit 910 can be further configured to receive, from the PNS, a notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.

In an example, the receiving unit 910 can be further configured to when the third IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, prior to transmitting the second information, receive, from the core network node, information indicating that a porting process for the terminal device has been initiated in the first IMS core network.

In an example, each of the network node and the other network node can be a P-CSCF node.

The units 910～930 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing the software, a Programmable Logic Device (PLD) or other electronic component (s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 4.

Fig. 10 is a block diagram of a network node 1000 according to yet another embodiment of the present disclosure.

The network node 1000 includes a communication interface 1010, a processor 1020 and a memory 1030. The memory 1030 contains instructions executable by the processor 1020 whereby the network node 1000 is operative to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 3 or 4.

As an example, the network node 1000 can be P-CSCF 1 shown in Fig. 2, 6A-6D, or 7A-7D. Particularly, the memory 1030 can contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: transmit, to a PNS, a request for subscribing to notification of an IMS registration status of a terminal device; and receive, from the PNS, a first notification of a first IMS registration status of the terminal device.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: remove, in response to receiving the first notification, contact binding for the terminal device from the network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: transmit, in response to receiving the first notification, to the PNS a request for unsubscribing from the notification.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: prior to receiving the first notification, receive, from the PNS, a second notification of a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the other network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: when the second IMS registration status indicates that the terminal device is registering with the first IMS core network through the other network node, forward a call to be terminated at the terminal device to the other network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: when the first IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, transmit, to a core network node in the first IMS core network, a request for IMS deregistration for the terminal device.

As another example, the network node 1000 can be P-CSCF 2 in Fig. 2, 6A-6D or 7A-7D. Particularly, the memory 1030 can contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: receive, from a terminal device, a request for Internet Protocol ‘IP' Multimedia Subsystem, IMS, registration; forward the request to a core network node in a first IMS core network; receive, from the core network node, a response to the request, the response indicating that the IMS registration has succeeded; and transmit, to a PNS, first information on a first IMS registration status indicating that the terminal device has registered with the first IMS core network through the network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: subsequent to receiving the request and prior to receiving the response, transmit, to the PNS, second information on a second registration status indicating that the terminal device is registering with the first IMS core network through the network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: subsequent to receiving the request, transmit, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device; and receive, from the PNS, a notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.

In an embodiment, the memory 1030 can further contain instructions executable by the processor 1020 whereby the network node 1000 is operative to: when the third IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, prior to transmitting the second information, receive, from the core network node, information indicating that a porting process for the terminal device has been initiated in the first IMS core network.

Correspondingly to the method 500 as described above, a PNS is provided. Fig. 11 is a block diagram of a PNS 1100 according to an embodiment of the present disclosure.

The PNS 1100 can be, e.g., a PNS shown in Fig. 2, 6A-6D, or 7A-7D, and can be configured to perform the method 500 as described above in connection with Fig. 5. As shown in Fig. 11, the PNS 1100 includes a receiving unit 1110 configured to receive, from a first network node associated with a first IMS core network, a request for subscribing to notification of an IMS registration status of a terminal device. The receiving unit 1110 is further configured to receive, from a second network node associated with the first IMS core network or a second IMS core network, first information on a first IMS registration status indicating that the terminal device has registered with the first or second IMS core network through the second network node. The PNS 1100 further include a transmitting unit 1120 configured to transmit, to the first network node, a first notification of the first IMS registration status.

In an example, the receiving unit 1110 can be further configured to receive, from the first network node, a request for unsubscribing from the notification.

In an example, the receiving unit 1110 can be further configured to prior to receiving the first information, receive, from the second network node, second information on a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the second network node, and the transmitting unit 1120 can be further configured to prior to receiving the first information, transmit, to the first network node, a second notification of the second IMS registration status.

In an example, the receiving unit 1110 can be further configured to prior to receiving the first information, receive, from the second network node, a request for subscribing to notification of an IMS registration status of the terminal device, and the transmitting unit 1120 can be further configured to prior to receiving the first information, transmit, to the second network node, a third notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through the first network node.

In an example, the transmitting unit 1120 can be further configured to when the second network node is associated with the second IMS core network, transmit, in response to receiving the request for subscribing from the second network node, to an authentication server a request for provisioning, in the terminal device and in the second IMS core network, authentication parameters required for the terminal device to access the second IMS core network.

In an example, each of the first and second network nodes may be a P-CSCF node.

The units 1110～1120 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing the software, a Programmable Logic Device (PLD) or other electronic component (s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 5.

Fig. 12 is a block diagram of a PNS 1200 according to another embodiment of the present disclosure.

The PNS 1200 includes a communication interface 1210, a processor 1220 and a memory 1230. The memory 1230 contains instructions executable by the processor 1220 whereby the PNS 1200 is operative to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 5.

For example, the PNS 1200 can be a PNS in Fig. 2, 6A-6D, or 7A-7D. Particularly, the memory 1230 can contain instructions executable by the processor 1220 whereby the PNS 1200 is operative to: receive, from a first network node associated with a first IMS core network, a request for subscribing to notification of an Internet Protocol ‘IP' Multimedia Subsystem, IMS, registration status of a terminal device; receive, from a second network node associated with the first IMS core network or a second IMS core network, first information on a first IMS registration status indicating that the terminal device has registered with the first or second IMS core network through the second network node; and transmit, to the first network node, a first notification of the first IMS registration status.

In an embodiment, the memory 1230 can further contain instructions executable by the processor 1220 whereby the PNS 1200 is operative to: receive, from the first network node, a request for unsubscribing from the notification.

In an embodiment, the memory 1230 can further contain instructions executable by the processor 1220 whereby the PNS 1200 is operative to: prior to receiving the first information, receive, from the second network node, second information on a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the second network node; and transmit, to the first network node, a second notification of the second IMS registration status.

In an embodiment, the memory 1230 can further contain instructions executable by the processor 1220 whereby the PNS 1200 is operative to: prior to receiving the first information, receive, from the second network node, a request for subscribing to notification of an IMS registration status of the terminal device; and transmit, to the second network node, a third notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through the first network node.

In an embodiment, the memory 1230 can further contain instructions executable by the processor 1220 whereby the PNS 1200 is operative to: when the second network node is associated with the second IMS core network, transmit, in response to receiving the request for subscribing from the second network node, to an authentication server a request for provisioning, in the terminal device and in the second IMS core network, authentication parameters required for the terminal device to access the second IMS core network.

In an example, each of the first and second network nodes may be a P-CSCF node.

The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code/computer readable instructions, which when executed by the processor 1020, causes the network node 1000 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 3 or 4, or code/computer readable instructions, which when executed by the processor 1220, causes the PNS 1200 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 5.

The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in Fig. 3, 4, or 5.

The processor may be a single CPU (Central Processing Unit) , but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs) . The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a non-transitory computer readable storage medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-Access Memory (RAM) , a Read-Only Memory (ROM) , or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories.

The disclosure has been described above with reference to embodiments thereof. It should be understood that various modifications, alternations and additions can be made by those skilled in the art without departing from the spirits and scope of the disclosure. Therefore, the scope of the disclosure is not limited to the above particular embodiments but only defined by the claims as attached.

Claims

A method (300) in a network node, comprising:

- transmitting (310) , to a Push Notification Server, PNS, a request for subscribing to notification of an Internet Protocol ‘IP’ Multimedia Subsystem, IMS, registration status of a terminal device; and

- receiving (320) , from the PNS, a first notification of a first IMS registration status of the terminal device.
The method (300) of claim 1, wherein the first notification is received when the network node maintains an IMS registration status indicating that the terminal device has registered with a first IMS core network through the network node, and wherein the first IMS registration status indicates that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.
The method (300) of claim 2, further comprising:

- removing, in response to receiving the first notification, contact binding for the terminal device from the network node.
The method (300) of claim 2 or 3, further comprising:

- transmitting, in response to receiving the first notification, to the PNS a request for unsubscribing from the notification.
The method (300) of any of claims 2-4, further comprising, prior to receiving the first notification:

- receiving, from the PNS, a second notification of a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the other network node.
The method (300) of claim 5, further comprising, when the second IMS registration status indicates that the terminal device is registering with the first IMS core network through the other network node:

- forwarding a call to be terminated at the terminal device to the other network node.
The method (300) of any of claims 2-6, further comprising, when the first IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node:

- transmitting, to a core network node in the first IMS core network, a request for IMS deregistration for the terminal device.
The method (300) of any of claims 2-7, each of the network node and the other network node is a Proxy Call Session Control Function, P-CSCF, node.
A method (400) in a network node, comprising:

- receiving (410) , from a terminal device, a request for Internet Protocol ‘IP’ Multimedia Subsystem, IMS, registration;

- forwarding (420) the request to a core network node in a first IMS core network;

- receiving (430) , from the core network node, a response to the request, the response indicating that the IMS registration has succeeded; and

- transmitting (440) , to a Push Notification Server, PNS, first information on a first IMS registration status indicating that the terminal device has registered with the first IMS core network through the network node.
The method (400) of claim 9, further comprising, subsequent to receiving the request and prior to receiving the response:

- transmitting, to the PNS, second information on a second registration status indicating that the terminal device is registering with the first IMS core network through the network node.
The method (400) of claim 9, further comprising, subsequent to receiving the request:

- transmitting, to the PNS, a request for subscribing to notification of an IMS registration status of the terminal device; and

- receiving, from the PNS, a notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network or a second IMS core network through another network node.
The method (400) of claim 11, further comprising, when the third IMS registration status indicates that the terminal device has registered with the second IMS core network through the other network node, prior to transmitting the second information:

receiving, from the core network node, information indicating that a porting process for the terminal device has been initiated in the first IMS core network.
The method (400) of any of claims 9-12, the network node is a Proxy Call Session Control Function, P-CSCF, node.
A network node (1000) , comprising a communication interface (1010) , a processor (1020) and a memory (1030) , the memory (1030) comprising instructions executable by the processor (1020) whereby the network node (1000) is operative to perform the method according to any of claims 1-13.
A computer readable storage medium having computer program instructions stored thereon, the computer program instructions, when executed by a processor in a network node, causing the network node to perform the method according to any of claims 1-13.
A method (500) in a Push Notification Server, PNS, comprising:

- receiving (510) , from a first network node associated with a first IMS core network, a request for subscribing to notification of an Internet Protocol ‘IP’ Multimedia Subsystem, IMS, registration status of a terminal device;

- receiving (520) , from a second network node associated with the first IMS core network or a second IMS core network, first information on a first IMS registration status indicating that the terminal device has registered with the first or second IMS core network through the second network node; and

- transmitting (530) , to the first network node, a first notification of the first IMS registration status.
The method (500) of claim 16, further comprising:

- receiving, from the first network node, a request for unsubscribing from the notification.
The method (500) of claim 16 or 17, further comprising, prior to receiving the first information:

- receiving, from the second network node, second information on a second IMS registration status indicating that the terminal device is registering with the first or second IMS core network through the second network node; and

- transmitting, to the first network node, a second notification of the second IMS registration status.
The method (500) of any of claims 16-18, further comprising, prior to receiving the first information:

- receiving, from the second network node, a request for subscribing to notification of an IMS registration status of the terminal device; and

- transmitting, to the second network node, a third notification of a third IMS registration status indicating that the terminal device has registered with the first IMS core network through the first network node.
The method (500) of claim 19, further comprising, when the second network node is associated with the second IMS core network:

- transmitting, in response to receiving the request for subscribing from the second network node, to an authentication server a request for provisioning, in the terminal device and in the second IMS core network, authentication parameters required for the terminal device to access the second IMS core network.
The method (500) of any of claims 16-20, wherein each of the first and second network nodes is a Proxy Call Session Control Function, P-CSCF, node.
A Push Notification Server, PNS, (1200) comprising a communication interface (1210) , a processor (1220) and a memory (1230) , the memory (1230) comprising instructions executable by the processor (1220) whereby the PNS (1200) is operative to perform the method according to any of claims 16-21.
A computer readable storage medium having computer program instructions stored thereon, the computer program instructions, when executed by a processor in a Push Notification Server, PNS, causing the PNS to perform the method according to any of claims 16-21.