Entities, methods and data structure for identifying a personal IoT network in a communication network

Abstract

The disclosure relates to identifying a personal internet of things network (PIN). The disclosure provides an entity for a PIN, a control plane (CP) network entity for managing a PIN, a radio access network (RAN) entity for managing a CP network entity transfer of a PIN element (PINE), a data structure for identifying a PIN. The entity for a PIN sends a PIN registration request to the CP network entity, the request comprising an ID of the entity. The entity receives a response message from the CP network entity, the response message requesting a respective ID of each of one or more PINEs. The entity sends an identification message to the CP network entity, the identification message comprising the respective IDs of the one or more PINEs. Then entity further receives a data structure from the CP network entity for identifying the PIN during a service operation.

Description

[0001] ENTITIES, METHODS AND DATA STRUCTURE FOR IDENTIFYING A PERSONAL IOT NETWORK IN A COMMUNICATION NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to communication networks and personal internet of things (loT) networks. The disclosure is concerned with identifying a personal loT network (PIN) in a communication network. The disclosure provides, to this end, an entity for a PIN, a control plane (CP) network entity for managing a PIN, a radio access network (RAN) entity for managing a CP network entity transfer of a PIN element (PINE) of the PIN, a data structure for identifying a PIN, and methods corresponding to the entities.

[0004] BACKGROUND

[0005] Today, many people have more than one digital device, and most devices nowadays have networking capability, so as to access network services from remote. For example, a person may have a smartphone, a smart watch, and several smart home kits. Another example is a farming field, which is monitored by a set of narrow-band cellular sensors. With more powerful on-device capability, it becomes increasingly popular, and even inevitable, that future services are provided with multiple personal loT devices as a whole. In 3 GPP, such a multi-device composition is called a PIN service, and a device that is part of the PIN is called a PINE.

[0006] With the ubiquitous coverage of cellular networks (e.g., 4thgeneration long-term evolution (4G- LTE) and 5thgeneration (5G) networks), PIN services may no longer be limited to a local network service. Instead, a PIN service can be provided via a cellular network even on mobility. This opens a new door, where a PIN service potentially can be operated by carrier network operators together with 3rd-party service providers. For this new service paradigm, however, the operator network side has to be enhanced accordingly, which is still under studies.

[0007] Herein, an example is given to show a potential deficiency. A user may have already created a PIN consisting of several digital devices at home, such as: smart TVs in different rooms, smart phones, and smart watches. Some of these devices may have 3GPP radio access technology (RAT) capability (e.g., the smart phone and smart watch). The user may now be watching a live broadcasting (e.g., a football match) at home on the TV (e.g., being a PINE 1) streamed from a content provider. The user may leave the living room while wanting to continue watching on another TV in another room, or on his smart phone undergo (e.g., being a PINE 2, to which the streaming may be switched). The user can resume the service by manually instructing the devices. When the user turns on the device, at the best situation, the application providing the service may notify the end user by asking him if he would like to continue watching the live broadcast.

[0008] The user experience could be further improved, if the second device (the PINE 2) could automatically resume the live broadcast when the user approaches (or activates) it. Specifically, if the operator network could be aware of the correlation of the PINEs and especially the ongoing service status, it could better operate the ongoing session service. Technically, one reason causing the inconvenience or complexity is that relevant network entities in the operator network cannot properly identify a PIN when operating a service to a PINE in the PIN.

[0009] A PIN typically consists of several PINEs, where at least one of the PINEs has gateway capability and is also referred to as PEGC, and another PINE has a management capacity and is referred to as PEMC. Note that the PEGC and PEMC can be physically one PINE in the PIN. An operator-managed PIN at least contains a PEGC with 3 GPP RAT, wherein among the PINEs also non-3GPP RAT can be used (e.g., WiFi and Bluetooth) for direct communications. At the operator network side, depending on different ways of network architecture enhancement, there may or may not be a dedicated network function (NF) to support the PIN management. Therefore, conventional ways for PIN identification are also different.

[0010] SUMMARY

[0011] This disclosure and its solutions are based further on the following considerations, and specifically on three different conventional approaches that could be used for PIN identification in an operator network.

[0012] A first conventional approach is a mixed way collaborating with a 3rd-party service provider. This approach relies on an application server (AS) to assign a PIN identifier for the operator network. As a service provider locating in a data network (such as datacenters over internet), the AS is the actual entity providing services to the PINEs in a PIN. Therefore, it is a natural way that an AS can provide an identifier for the whole PIN. Specifically, with the information provided by a PEGC of the PIN, which uses 3 GPP RAT, an AS can be aware of the members in the PIN, i.e., the PINEs. The AS can compose a PIN identifier and can provide it over an interface to a network exposure function (NEF) of an operator network. Thereafter, the NEF may trigger a subscription profile creation in user data repository (UDR).

[0013] A second conventional approach is a more specialized approach. A new NF may be responsible for the PIN management and control functions, and may be referred to as P-NF. A session can be established between a PEGC and / or PEMC of a PIN and the P-NF. Based on the information provided by the PEGC about the PINEs of the PIN, the P-NF may trigger a subscription profile creation at UDR, which is similar to the first approach.

[0014] A third conventional approach is in between the first and the second approach. This third approach neither relies on a 3rd-party nor on a new NF entity in the core network (CN). Instead, an access management function (AMF) delegates the role of responsible NFs, as in the previous two approaches. Specifically, after the AMF establishes a session with the PEGC and / or PEMC of a PIN, the AMF can trigger a subscription profile creation at the UDR, with the member information of the PIN (i.e., information regarding the PINEs) provided by the PEGC and / or PEMC.

[0015] Though the conventional approaches enable a PIN identification in an operator network, the assigned PIN identifier is only a subscription profile stored statically in the UDR. For operation and control purposes, such as mobility management and service continuity, the conventional approaches are not sufficient. The reason is that in addition to the subscription profile data, a user entity (UE) typically uses another set of identifiers for accessing the network services. For example, in a 5G communication system, CP NFs use a global unique temporal identifier (GUTI) to identify a UE. Similar temporal identifiers also exist in 4G-LTE communication systems.

[0016] A temporal identifier for a UE is created in runtime and will be updated due to many events, rather than a static subscription profile stored in UDR (e.g., as in a conventional approach). The events leading the temporal identifier (re-)assignment include: initial registration, mobility registration update, periodical registration update and so on. In a 5G communication system, for instance, this temporal identifier for a UE is created by the AMF in the CN. The following disadvantages may be attributed to the conventional approaches.

[0017] First of all, at the network side, it may not be efficient to provision services for a PIN in a unified manner. A typical scenario will be a PIN’s PEGC, which has 3GPP RAT capability, disconnecting to the operator network. In this case, if the network side (e.g., AMF) cannot immediately re-establish the connection via an alternative PEGC, the service will be interrupted. Finding out an alternative PEGC can be done by checking the PIN subscription profile data in the UDR, which is enabled by the conventional approachesintroduced above. However, this will take a longer time for first retrieving such an information, and then reestablishing a connection to the alternative PEGC, in order to resume the services.

[0018] Secondly, at the AS provider side, it may not be efficient to interfere in the service provisioning with customized requirements. An AS provider can interact with the NEF, and provide customized policies for its own applications. To an application of a PIN, an AS can define, for example, specialized traffic steering policies for the PIN. However, a prerequisite is that AS and NEF are able to have a common identifier for operations to identify a PIN managed by the operator. Though this can be indirectly achieved if the NEF and the AS interact based on the subscription profile data, this will introduce extra delays, because for the operational CP NFs, additional queries have to be made to the UDR, so that the queried NF can identify a specific PINE, to which defined policies from the AS can be correctly applied.

[0019] Thirdly, at the PIN side, it may not be convenient to customize the service from the user perspective. Often, special requirements come from the end users of a service provider. The owner (or the PEMC) of a PIN can specify how services should be provided (for both operator networks and AS). Though an end user can define for every PINE one-by-one (with or without 3 GPP capability), it will be complicated and less friendly for a user to handle such a complexity.

[0020] In view of the above-described issues of the conventional approaches, this disclosure aims to mitigate the complexity. An objective is to provide methods and entities that provide a functionality to generate a data structure that can identify a PIN during a service operation. Thus, an objective is also to facilitate the service provisioning for a PIN. Another objective is to enable this functionality by a series of enhancements on different entities both at the PIN and the network side. Overall, an objective is to smooth the service continuity concerned with PIN identification issues, and to solve the problem of how a PIN can be properly identified when a service is provisioned, so that PIN services (e.g., provisioning, or quality-of-services (QoS), lifecycle management, etc.) can be built on top of it.

[0021] These and other objectives are achieved by the solutions of this disclosure as described in the independent claims. Advantageous implementations are further described in the dependent claims.

[0022] A first aspect of this disclosure provides an entity for a PIN, the entity being configured to: send a PIN registration request to a CP network entity, the PIN registration request comprising an identifier (ID) of the entity; receive a response message from the CP network entity, the response message requesting a respective ID of each of one or more PINEs of the PIN; send an identification message to the CP network entity, the identification message comprising the respective IDs of the one or more PINEs of the PIN; and receive a data structure from the CP network entity, the data structure being for identifying the PIN during a service operation.

[0023] The entity of the first aspect enables the generation of the data structure by the CP network entity, wherein the data structure can identify the PIN during a service operation. This may facilitate the service provisioning for the PIN, particularly, this may smooth the service continuity concerned with PIN identification issues.

[0024] Notably, in this disclosure, a PIN may include various PINEs. These PINEs may include the PEGC and / or the PEMC and other PINEs without such functionality. The PECG and / or PEMC are thus also as PINEs. The PINEs may also be referred to as PIN members and of the PIN.

[0025] In an implementation form of the first aspect, the data structure comprises a first data field indicating a group ID of the PIN; a second data field indicating a number of one or more PINEs of the PIN; a third data field for each PINE of the PIN, the third data field indicating a type of the PINE.

[0026] The data structure may thus be as described below in the fourth aspect, and may further have any of the implementation forms described below. The data structures is designed to identify the PEST during a service operation. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues

[0027] In an implementation form of the first aspect, the entity is further configured to provide the data structure to the one or more PINEs of the PIN.

[0028] Thus, each PINE of the PIN is aware of how its PIN is identified during a service operation.

[0029] In an implementation form of the first aspect, the PIN registration request further comprises a requested type of the data structure, the requested type being selected from one or more available types for the data structure.

[0030] Different types of the data structures may have different advantages, e.g., compatibility with a UE-GUTI and / or smaller size. The entity can chose the desired type and the associated advantages.

[0031] In an implementation form of the first aspect, the registration request further comprises a list including a respective ID and / or a respective type of each PINE of the PIN.

[0032] If the respective IDs and / or types are included, the procedure can be accelerated.

[0033] In an implementation form of the first aspect, the entity is further configured to send an update registration request, the update registration request requesting a registration with a new CP network entity to serve the PIN.

[0034] This is beneficial in case of a transfer of the PIN or a PINE of the PIN. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues in case of such a transfer.

[0035] A second aspect of this disclosure provides CP network entity for managing a PIN, the CP network entity being configured to: receive a PIN registration request from a PINE of the PIN, the PIN registration request comprising an ID of the PINE; send a response message to the PINE, the response message requesting a respective ID of each of one or more PINEs of the PIN; receive an identification message from the PINE, the identification message comprising the respective IDs of the one or more PINEs of the PIN; generate a data structure for identifying the PIN during a service operation; and send the data structure to the PINE.

[0036] The data structure may, in particular, be sent to the PEMC of the PIN. The CP network entity of the second aspect implements the generation of the data structure, wherein the data structure can identify the PIN during a service operation. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues.

[0037] In an implementation form of the second aspect, the data structure comprises a first data field indicating a group ID of the PIN; a second data field indicating a number of one or more PINEs of the PIN; a third data field for each PINE of the PIN, the third data field indicating a type of the PINE.

[0038] The data structure may thus be as described below in the fourth aspect, and may further have any of the implementation forms described below.

[0039] The data structures is designed to identify the PIN during a service operation. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues.

[0040] In an implementation form of the second aspect, the CP network entity is further configured to: send an authentication and authorization request, which includes the respective IDs of the one or more PINEs of the PIN, to at least one authentication network entity; and receive an authentication and authorization result, which indicates which of the one or more PINEs of the PIN is authorized to access the service operation, from the at least one authentication network entity.

[0041] This serves the benefit of authenticating the PINEs of the PIN.

[0042] In an implementation form of the second aspect, the CP network entity is further configured to, when generating the data structure, select one of a plurality of available coding methods to code the data included in the data structure. The available coding methods may, for example, be agreed in advance between the entity and the operator network (e.g., CP network entity). As an exemplary advantage of a specific coding method, the length of the data structure could be shortened, and thus the efficiency of the transmission of the data structure could be improved. This is especially helpful when the number of PINEs is large and the data structure type includes a complete list of the PINEs.

[0043] In an implementation form of the second aspect, the CP network entity is further configured to: receive a transfer request from a second CP network entity, the transfer request requesting context information of the PIN; and send the context information of the PIN to the second CP network entity.

[0044] This serves to prepare for a transfer of a PINE or the PIN, for instance, from one CP network entity to another.

[0045] In an implementation form of the second aspect, the context information of the PIN comprises the data structure.

[0046] This allows identifying the PIN during the transfer.

[0047] In an implementation form of the second aspect, the CP network entity is further configured to: receive an update registration request from a PINE of a second PIN, the update registration request requesting a registration with the CP network entity to serve the second PIN; send a transfer request to a third CP network entity, the transfer request requesting context information of the second PIN; receive the context information of the second PIN from the third CP network entity; generate a second data structure for identifying the second PIN during a service operation; and send the second data structure to the PINE of the second PIN.

[0048] With the second data structure, the PIN can be identified during a service operation after the transfer of a PINE of a PIN or the PIN to a new CP network entity. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues.

[0049] A third aspect of this disclosure provides a RAN entity for managing a CP network entity transfer of a PINE of a PIN, the RAN entity being configured to: receive an update registration request from the PINE of the PIN, the update registration request requesting a registration with a new CP network entity for one or more PINEs of the PIN; wherein the PIN is associated with a first CP network entity; select a second CP network entity as the new CP network entity based on the update registration request; and forward the update registration request to the second CP network entity.

[0050] The RAN entity of the third aspect enables the generation of one or more data structures which can respectively identify the PIN during a service operation, even in case of a handover or another mobility event experienced by the PIN or by a PINE of the PIN. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues.

[0051] A fourth aspect of this disclosure provides a data structure for identifying a PIN during a service operation, the data structure comprising: a first data field indicating a group ID of the PIN; a second data field indicating a number of one or more PINES of the PIN; a third data field for each PINE of the PIN, the third data field indicating a type of the PINE.

[0052] The data structures of the fourth aspect is designed to identify the PIN during a service operation. This may facilitate the service provisioning for the PIN, particularly, may smooth the service continuity concerned with PIN identification issues.

[0053] In an implementation form of the fourth aspect, the data structure further comprises an association of the PIN with one or more CP network entities or NFs related to the service operation.

[0054] This makes the service operation even more efficient.

[0055] In an implementation form of the fourth aspect, the data structure is a UE-GUTI, which is extended with the first data field indicating the group ID of the PIN, the second data field indicating the number of PINE elements, and the third data fields indicating respectively a type of the PINE.

[0056] This is beneficial, as it may provide compatibility with the existing UE-GUTI format. In an implementation form of the fourth aspect, the data structure further comprises a public land mobile network (PLMN) ID, wherein at least two third data fields are associated the PLMN ID.

[0057] This association may make the data structure more compact.

[0058] A fifth aspect of this disclosure provides a method for managing a PIN, the method comprising: sending a PIN registration request to a CP network entity, the PIN registration request comprising an ID; receiving a response message from the CP network entity, the response message requesting a respective ID of each of one or more PINEs, of the PIN; sending an identification message to the CP network entity, the identification message comprising the respective IDs of the one or more PINEs of the PIN; and receiving a data structure from the CP network entity, the data structure being for identifying the PIN during a service operation.

[0059] The method of the fifth aspect may be performed by the entity of the first aspect. The method of the fifth aspect may have implementation forms that correspond to the implementation forms of the entity of the first aspect. The method of the fifth aspect and its implementation forms may achieve the advantages described above for the entity of the first aspect and its respective implementation forms.

[0060] A sixth aspect of this disclosure provides a method for managing a PIN, the method comprising: receiving a PIN registration request from a PINE, of the PIN, the PIN registration request comprising an ID of the PINE; sending a response message to the PINE, the response message requesting a respective ID of each of one or more PINEs of the PIN; receiving an identification message from the PINE, the identification message comprising the respective IDs of the one or more PINEs of the PIN; generating a data structure for identifying the PIN during a service operation; and sending the data structure to the PINE.

[0061] The data structure may, in particular, be set to the PEMC of the PIN. The method of the sixth aspect may be performed by the CP network entity of the second aspect. The method of the fifth aspect may have implementation forms that correspond to the implementation forms of the CP network entity of the second aspect. The method of the fifth aspect and its implementation forms may achieve the advantages described above for the CP network entity of the second aspect and its respective implementation forms. A seventh aspect of this disclosure provides a method for managing a CP network entity transfer of a PINE of a PIN, the method comprising: receiving an update registration request from the PINE of the PIN, the update registration request requesting a registration with a new CP network entity for one or more PINEs of the PIN; wherein the PIN is associated with a first CP network entity; selecting a second CP network entity as the new CP network entity based on the update registration request; and forwarding the update registration request to the second CP network entity.

[0062] The method of the seventh aspect may be performed by the RAN entity of the third aspect. The method of the seventh aspect may have implementation forms that correspond to the implementation forms of the RAN entity of the third aspect. The method of the seventh aspect and its implementation forms may achieve the advantages described above for the RAN entity of the third aspect and its respective implementation forms.

[0063] An eighth aspect of this disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to one of the fifth, sixth, and seventh aspect or any of their implementation forms.

[0064] An eighths aspect of this disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the fifth, sixth, and sevenths aspect or any of their implementation forms to be performed.

[0065] In summary of the above-mentioned aspects and implementation forms, this disclosure defines and provides a new data structure (e.g., referred to as a PIN global unique temporal identifier (PIN-GUTI)) to identify a PIN as a whole in a communication network, for example, in a 3 GPP network. Unlike a PIN identifier created and stored in the UDR, the PIN-GUTI is an identifier that can be used to identify a PIN during service operation. Specifically, similar to the UE- GUTI, the PIN-GUTI of this disclosure aims to preserve the permanent identity of a PIN for privacy considerations. In addition, the PIN-GUTI of this disclosure may associate the PIN with CP network entities, which are closely relevant to the service provisioning and run-time operations (such as AMF, service management function (SMF), and so on). Only with the subscription profile data, which is created in the UDR by the conventional approachesdescribed above, the operator network can just authenticate and authorize the access from a PINE of a PIN, but it cannot directly operate the network service for the PIN. This disclosure, for example, proposes extending the data structure of a UE-GUTI to design the PIN-GUTI, which will be assigned by the operator network side.

[0066] Further, this disclosure provides a registration procedure to create the defined PIN-GUTI, which comprises interactions between several PINEs and NF entities in the network. The procedure of creating the PIN-GUTI may be compatible with existing registration procedures for a single UE. This disclosure, for example, extends the existing registration procedures by adding new features on relevant NFs.

[0067] The above-described realizes the creation of the PIN-GUTI for a PIN. This may not necessarily lead to the improved PIN service continuity in a direct manner. However, a PIN-GUTI created according to the present disclosure is a precondition for such further enhancements of the PIN service continuity.

[0068] It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

[0069] BRIEF DESCRIPTION OF DRAWINGS

[0070] The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

[0071] FIG. 1 shows various entities according to this disclosure for identifying a PIN and management of the PIN. FIG. 2 shows a system architecture and scenario of a PIN service via a 3 GPP network.

[0072] FIG. 3 shows a complete PIN-GUTI format as data structure according to this disclosure.

[0073] FIG. 4 shows a compact PIN-GUTI format as data structure according to this disclosure.

[0074] FIG. 5 shows a short PIN-GUTI format as data structure according to this disclosure.

[0075] FIG. 6 shows a PIN registration procedure performed by various entities according to this disclosure.

[0076] FIG. 7 shows a PIN registration update procedure performed by various entities according to this disclosure.

[0077] FIG. 8 shows a method for managing a PIN according to this disclosure.

[0078] FIG. 9 shows another method for managing a PIN according to this disclosure.

[0079] FIG. 10 shows a method for managing a CP network entity transfer of a PINE of a PIN.

[0080] DETAILED DESCRIPTION OF EMBODIMENTS

[0081] FIG. 1 shows an entity 100 for a PIN, a CP network entity 110 for managing the PIN, another CP network entity 130, and a RAN entity 120 for managing a CP network entity transfer of a PINE of the PIN. The RAN entity 120 may manage a CP network entity transfer of the entity 100. The entity 100 may itself be a PINE of the PIN, for instance, it may be the PEMC and / or the PEGC of the PIN. However, the entity 100 could also be an entity external the PIN but closely related to the PIN and attributed to coordinating the PIN.

[0082] The entity 100 is configured to send a PIN registration request 101 to the CP network entity 110. Accordingly, the CP network entity 110 is configured to receive the PIN registration request 101 from the entity 100 (e.g., being a PINE of the PIN). The PIN registration request 101 comprises an ID of the entity 100. The CP network entity 110 is further configured to send a response message 102 to the entity 100. Accordingly, the entity 100 is configured to receive the response message 102 from the CP network entity 110. The response message 102 requests a respective ID of each of one or more PINEs of the PIN from the entity 100. The response message 102 may, to this end, comprise an indication that is interpreted by the entity 100 as such a request.

[0083] The entity 100 is further configured to send an identification message 103 to the CP network entity 110. Accordingly, the CP network entity 110 is configured to receive the identification message 103 from the entity 100. The identification message 103 comprising the respective IDs of the one or more PINEs of the PIN, which were requested.

[0084] Further, the CP network entity 110 is configured to generate a data structure 104 (e.g., a PIN- GUTI) for identifying the PIN during a service operation, and then to send the data structure 104 to the entity 100. Accordingly, the entity 100 is configured to receive the data structure 104 from the CP network entity 110.

[0085] The entity 100 (e.g., being a PINE of the PIN) can further be configured to send an update registration request 105 to the RAN entity 120. Accordingly, the RAN entity 120 is configured to receive the update registration request 105. The update registration request 105 requests a registration with a new CP network entity for one or more PINEs of the PIN, which is currently associated with the first CP network entity 110. The update registration request 105 may, to this end, comprise an indication that is interpreted by the RAN entity 120 as such a request.

[0086] The RAN entity 120 is further configured to select a second CP network entity, in this case the other CP network entity 130 shown in FIG. 1, as the new CP network entity, based on the update registration request 105. The RAN entity 120 is then further configured to forward the update registration request 105 to the selected CP network entity 130.

[0087] Accordingly, the other CP network entity 130 is configured to receive the update registration request 105. The other CP network entity 130 may be further configured to send a transfer request to the CP network entity 110 shown in FIG. 1, wherein the transfer request is for requesting context information of the PIN. The other CP network entity 130 may be configured to receive the context information of the PIN from the CP network entity 110, may generate a second data structure for identifying the PIN during a service operation, and may send the second data structure to the RAN entity 120. The RAN entity 120 may forward the second data structure to a PINE of the PIN, for instance, to the entity 100.

[0088] Each of the entities 100, 110, 120, 130 shown in FIG. 1 may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the respective entity 100, 110, 120, 130 described in this disclosure. The processing circuitry may comprise hardware and / or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. Each of the entities 100, 110, 120, 130 shown in FIG. 1 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the respective entity 100, 110, 120, 130 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the respective entity 100, 110, 120, 130 to perform, conduct or initiate the operations or methods described in this disclosure.

[0089] FIG. 2 shows a system architecture and / or scenario, to which the solutions of the present disclosure are applicable, in particular, shows an architecture or scenario for a PIN service via a 3 GPP network 210.

[0090] This disclosure considers an end user consuming a service via a local PIN 200 including PINEs 201 over the 3 GPP network 210 (including RAN and CN, wherein the RAN may comprise the RAN entity 120), which is used to access the service provided locating at a data network (DN) or mobile edge computing (MEC). A packet data unit (PDU) session is established from a PINE 1 of the PIN 200, going over the PEGC 202 (a special PINE 201 of the PIN 200, another special PINE 201 is the PEMC, which may be implemented by the entity 100 of FIG. 1), which has 3GPP RAT capability, accessing the RAN part and UPFs to the DN / MEC. This can represent the scenario introduced with the example in the background section above, wherein an end user will switch from PINE 1 to PINE 2 for continuing the live broadcasting. It can also technically explain why for the conventional operator network it is difficult to smooth such a switching, because if the PDU session to the PINE 1 stops, the operator network cannot be aware of the situation where the PDU session should be switched to PINE 2 immediately.

[0091] In fact, one root cause of this is that the CN, or more specifically, the AMF and SMF of conventional approaches do not realize the existence of the PIN instance and its correlation of the ongoing service among various PINEs 201 of the PIN 200. With the solutions of the present disclosure, the data structure 104 creation (e.g., also referred to as PIN-GUTI creation) as the first step may potentially improve the service continuity and the user experience. Notably, the scenario introduced in FIG. 2 is just one example where there are benefits of having such a PIN- GUTI in the operator network. In other words, there could be many other use cases or scenarios where a data structure 104 or PIN-GUTI may be beneficial, which are not exhausted in this disclosure.

[0092] Two exemplary PIN-GUTI creation embodiments are provided below, for two different scenarios. The first embodiment is for a PIN initialization registration scenario in operator networks. The second embodiment is for a PIN update registration scenario. Before introducing the two PIN-GUTI creation embodiments, however, exemplary designs of the data structure 104 are introduced first.

[0093] Generally, the data structure 104 for identifying a PIN 200 during a service operation according to this disclosure comprises at least a first data field, a second data field, and one or more third data fields. The first data field indicates a group ID of the PIN 200. The second data field 302 indicates a number of one or more PINEs 201 of the PIN 200, i.e. how many PINEs 201 the PIN 200 has. Each third data field 303 corresponds to one of the PINEs 201 of the PIN 200, and each third data field 303 indicates a type of the PINE 201 to which it corresponds.

[0094] FIG. 3 shows, as a first example of the data structure 104, a complete PIN-GUTI format. The data structure 104 of FIG. 3 is based on a UE-GUTI, which is extended with the first data field 301 indicating the group ID of the PIN 200, with the second data field 302 indicating the number of PINEs 201 of the PIN 200, and with the one or more third data fields 303 indicating respectively a type of a PINE 201. The PIN-GUTI of this disclosure may be a temporal identifier that is assigned to a PIN 200 (or PIN instance). Different from a UE-GUTI (e.g., a 5G-GUTI in 5GS), the PIN-GUTI can not only identify the PIN 200, but also the PINEs 201 in the PIN 200. Several options are provided for the PIN-GUTI structure as follows.

[0095] In a 5GS, a UE-GUTI is an 80-bit long identifier. Its format consists of three parts:

[0096] • PLMN ID: 24 bits, further splits into two segments: MCC (12 bits) and MNC (12 bits)

[0097] • AMF ID: 24 bits, further splits into three segments: AMF Region ID (8 bits), AMF Set ID (8 bits) and AMF Pointer (6 bits)

[0098] • TMSI: 32 bits, a temporal identifier for a mobile subscriber, based on the identifier provided by the UE.

[0099] The first exemplary data structure 104 of FIG. 3 is a complete form that is a direct extension from such a UE-GUTI format. In addition to the similar fields as in the UE-GUTI (e.g., as above), there are several new fields in the PIN-GUTI as follows and as shown in FIG. 3 :

[0100] • SIZE: X bits, the number of PINEs 201 in the PIN 200 (i.e., the second data field 302).

[0101] • PIN ID: Y bits, the group ID of the PIN 200 (i.e., the first data field 301).

[0102] • PINE TYPE: Z bits, the type of a PINE 201 in the PIN 201 (i.e. the third data field 303).

[0103] Its value is assigned to be one of 0-PINE, 1-PEMC and 2-PEGC

[0104] FIG. 4 shows, as a second example of the data structure 104, a compact PIN-GUTI format.

[0105] The second option is a compact form, if some PINEs 201 are with the same PLMN and AMF ID. The data structure 104 comprises one or more PLMN IDs 304, wherein at least two third data fields 303 are associated with at least one, or more than one, of the PLMN IDs 304. Notably, also the data structure 104 of FIG. 3 comprises one or more PLMN IDs 304, however, one third data fields 303 is associated with each PLMN ID 304.

[0106] FIG. 5 shows, as a third example of the data structure 104, a short PIN-GUTI format. This is a possible short form, if a full PIN membership cannot be accommodated by the system with a consideration on overhead efficiency. With this format, the PIN-GUTI only contains the current active PINE TMSI and its PEGC TMSI. At the PEGC 202 of a PIN 201, it may maintain a routing table addressing individual PINEs 201 in the PIN 200.

[0107] The decision of choosing a specific type of the data structure 104 from, for example, the three PIN-GUTIs of FIGs. 3, 4 and 5, can be made by either the PIN side (e.g., the PEMC, which may be implemented by the entity 100) or by the operator network side when a registration or update event happens. For instance, the PIN registration request 101 of the entity 100 may further comprise a requested type of the data structure 104, wherein the requested type is selected from one or more available types for the data structure 104.

[0108] FIG. 6 shows the exemplary first (PIN-GUTI creation) embodiment of a PIN registration procedure performed by entities according to this disclosure. The first embodiment is for the initial registration scenario, when a PIN 200 registers itself to an operator network 210 (including RAN and CN). The method to realize this may be described as follows.

[0109] 0. PIN formation phase. a. A PINE 201 interacts with a PEMC (which in this case is the entity 100 of FIG. 1) to join in a PIN 200 under the management of the PEMC 100. b. A PEGC 202 (which could also be implemented by the entity 100) interacts with the PEMC 100 to join in a PIN 200 under the management of the PEMC 100.

[0110] Of note, any two or three types of nodes could physically be one node. For example, a PEMC 100 could act as a regular PINE 201 as well and / or as a PEGC node 202 at the same time. Further of note, the PINE / PEGC 201 / 202 can join in a PIN 200 in either a passive or a proactive way. A passive way means that the PINE / PEGC 201 / 202 was requested to join in a PIN 200 by the PEMC 100. A proactive way means that a PINE / PEGC 201 / 202 discovers and requests the PEMC 100 to join in a PIN 200.

[0111] 1. The PEMC 100 sends the PIN registration request 101 to the serving operator network. The PIN registration 101 request may contain the basic information of the PIN 200 that is under the management of the PEMC 100. This registration request 101 includes the identifier of the PEMC 100 itself. The registration request 101 may or may not directly include a member list of PINEs 201 of the PIN 200, particularly, their IDs. Of note, the PEST registration request 101 can be sent directly from the PEMC 100 by using its own 3 GPP RAT over RAN (in this case the RAN entity 120) to an AMF (in this case the CP network entity 110) of the operator network. The PIN registration request 101 can also be relayed via the PEGC 202. In the latter case, it requires that a 3GPP connectivity between the PEGC 202 and the operator network is established. This 3GPP connectivity can be an individual 3 GPP connectivity between the PEGC 202 and the operator network.

[0112] 2. The AMF 110 sends a response 102 to the PEMC 100 where the PIN registration request 101 was initiated. The response message 101 asks the PEMC 100 to provide identity information of its PINEs 201 (including the PECG 202) for authentication and authorization purposes of the operator network.

[0113] 3. The PEMC 100 forwards the response message 102 from the AMF 110 with an identity request to every PINE 201.

[0114] Of note, the identity request 102 can be broadcast to all PINEs 201, or the identity request 102 can be unicast to an individual PINE 201.

[0115] 4. The PINEs 201 provide their identities back to the PEMC 100 by replying to the identity request 102 from the PEMC 100. The identity of a PINE 201 may be not its permanent identifier but a concealed identifier that is generated from its permanent identifier for privacy protection purpose. However, this concealed identifier shall be verifiable by the operator network.

[0116] Of note, the way how a PINE 201 replies to the PEMC 100 depends on how the identity request 102 was sent in the previous step. If the identity request 102 from the PEMC 100 was a broadcast request, every PINE 201 may also reply with a broadcast message to the entire PIN 200. Instead, a PINE 201 can reply with a unicast message directed to the PEMC 100.

[0117] 5. The PEMC 100 replies 102 the identity request message 102 from the AMF with the collected identifier information of its PINEs 201.

[0118] Of note, there can be a PINE 201 who does not subscribe a 3GPP network service. For example, a Bluetooth loudspeaker may not have a 3GPP RAT capability to access a 3GPP RAN. In this case, its identifier may be not identifiable in the operator network. For such a PINE 201, the PEMC 100 may also inform the type of the PINE 201 , so that the operator network can correctly handle the provided identifier.

[0119] 6. The AMF 110 requests authentication and authorization for the PINEs 201 with other CP- NFs. For example, in a 5G system, the authentication and authorization will be done by requesting PCF and UDM entities. With the identifier information, the subscription profile data are verified and corresponding service policies can be checked in order to determine whether a PINE 201 in the PIN 200 is legible to access the operator network service.

[0120] OF note, for those PINEs 201 that do not have subscriptions to the operator network service, the authentication and authorization results will be neither a success nor a failure, instead, the result will be “not applicable” so that the AMF entity can handle properly in following steps.

[0121] 7. The AMF 110 generates a data structure 104, here the PIN-GUTI, for the PIN 200. After receiving the authentication and authorization result, the AMF 110 generates the PIN- GUTI 104 according to the PIN-GUTI type that was requested in the initial PIN registration request message 101. The type of a PIN-GUTI 104 can be one of the three options described above with respect to FIGs. 3, 4, and 5.

[0122] Of note, different coding methods and / or formats of the PIN-GUTI 104 can be applied when the AMF entity 110 generates the PIN-GUTI 104. The coding method and / or format can be agreed in advance between the PEMC node 100 and the operator network. With a specific coding method and / or format, the length of the PIN-GUTI 104 could be shorter thus improving the efficiency of the PIN-GUTI 104 transmission especially when the number of PIN members is large while the PIN-GUTI type is a complete list option as described above.

[0123] 8. The AMF 101 sends the generated PIN-GUTI 104 to the PEMC 100, which initially sent the PIN registration request 101.

[0124] 9. The PEMC 100 further provides the PIN-GUTI 104 that was generated by the AMF entity 110 to its PINEs 201. Similarly, this can be done with a broadcast message or a unicast message individually to every PINE 201. FIG. 7 shows the second exemplary (PIN-GUTI creation) embodiment, which is for a PIN update registration scenario, when the serving AMF entity 110 has to be changed. This scenario typically considers the possibility of a PIN mobility event. A PIN 200 may also consist of PINEs 201 with mobility capability. For example, several vehicles can be organized as a PIN 200 and collaboratively provide certain services. For instance, when vehicles are moving (i.e., the PIN 200 is moving), the serving AMF entity 100 may change due to handover events. In this situation, the new AMF entity (in this case the other CP network entity 130) may have to interact with the old AMF entity (the CP network entity 110) for a PIN-GUTI update.

[0125] 0. A PEMC (here again the entity 100) of a PIN 200 sends a PIN registration request 105 to the RAN (here the RAN entity 120). The PEMC 100 of the PIN 200 sends a PIN registration request 105 to the RAN entity 120 of the operator network, which is an update request caused under a handover situation. The request 105 from the PEMC 100 may or may not contain the existing PIN-GUTI (data structure 104) assigned from the old AMF entity 110.

[0126] 1. The RAN entity 120 makes AMF selection. According to the current serving domains, the RAN entity 120 selects the new AMF entity 130 to serve the registration request 105.

[0127] 2. The PIN registration request 150 is sent to the selected (new) AMF 130. The RAN entity 120 sends the registration request 105 to the selected new AMF entity 130 with all information provided by the PEMC 100 of the PIN 200.

[0128] 3. The new AMF 130 requests a PIN context transfer from the old AMF 110, and the old AMF 110 provides the existing PIN context back to the new AMF 130. Given the registration request 105 from the PEMC 100, the new AMF entity 130 first locates the old AMF entity 110 and sends the old AMF entity 110 a request to transfer the current PIN context data. After receiving the transfer request, the old AMF entity 110 looks up and returns the PIN context data with the provided PIN information, which could be the PIN-GUTI 104 that was originally assigned by the old AMF entity 110 itself. If the PIN- GUTI information is not provided, the new AMF entity 130 is responsible for providing an alternative way, so that the old AMF entity 110 can identify the corresponding context data. 4. The new AMF 130 requests authentication and authorization for the PINEs 201. The new AMF entity 130 may further proceed an authentication step by requesting the PIN members’ identities, which is similar to the authentication and authorization steps in the initial registration request in FIG. 6.

[0129] 5. The new AMF 130 sends a registration status update to the old AMF 110. The new AMF entity 130 (after successfully authenticating the PINEs 201 if necessary) sends a status update message to the old AMF entity 110. The old AMF entity 110 may accordingly update (such as remove, store or archive) its local context records.

[0130] 6. The new AMF 130 generates a new PIN-GUTI for the PIN registration request 105. The new AMF 130 generates a new PIN-GUTI for the PIN 200. With the identifier information of the new AMF entity 130 (e.g., GUAMI), the new AMF 130 generates a PIN-GUTI according to the PIN-GUTI type that was requested in the initial PIN registration request message. The type of the PIN-GUTI can be one of the three options shown in FIGs. 3, 4 and 5.

[0131] 7. The new AMF 130 sends a PIN registration accept message back to the PEMC 100 of the PIN 200. This step is similar to the step 9 in FIG. 6.

[0132] FIG. 8 shows a method 800 for managing a PIN 200. The method 800 may be performed by the entity 100. The method 800 comprises a step 801 of sending a PIN registration request 101 to a CP network entity 110. The PIN registration request 101 comprises an ID, for instance, of the entity 100. The method 800 further comprises a step 802 of receiving a response message 102 from the CP network entity 110, wherein the response message 102 requests a respective ID of each of one or more PINEs 201 of the PIN 200. The method 800 further comprises a step 803 of sending an identification message to the CP network entity 110, the identification message 103 comprising the respective IDs of the one or more PINEs 201 of the PIN 200. The method 800 then comprises a step 804 of receiving a data structure 104 from the CP network entity 110, the data structure 104 being for identifying the PIN 200 during a service operation.

[0133] FIG. 9 shows a method 900 for managing a PIN 200. The method 900 may be performed by the CP network entity 110. The method 900 comprises a step 901 of receiving a PIN registration request 101 from a PINE 201 of the PIN 200, wherein the PINE 201 may be the entity 100. The PIN registration request 101 comprises an ID of the PINE 100 / 201. The method 900 further includes a step 902 of sending a response message 102 to the PINE 100 / 201, the response message 102 requesting a respective ID of each of one or more PINEs 201 of the PIN 200. The method 900 further comprises a step 903 of receiving an identification message 103 from the PINE 100 / 201, the identification message 103 comprising the respective IDs of the one or more PINEs 201 of the PIN 200. The method 900 then comprises a step 904 of generating a data structure 104 for identifying the PIN 200 during a service operation, and a step 905 of sending the data structure 104 to the PINE 100 / 201.

[0134] FIG. 10 shows a method 1000 for managing a CP network entity transfer of a PINE 201 of a PIN 200, for instance, the entity 100, which may be PEMC and / or PECG. The method 1000 may be performed by the RAN entity 120. The method 1000 comprises a step 1001 of receiving an update registration request 105 from the PINE 100 / 201 of the PIN 200, the update registration request 105 requesting a registration with a new CP network entity for one or more PINEs 201 of the PIN 200. The PIN 200 is associated with a first CP network entity 110. The method 1000 further comprises a step 1002 of selecting a second CP network entity 130 as the new CP network entity based on the update registration request 105, and a step 1003 of forwarding the update registration request to the second CP network entity.

[0135] The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

Claims1. An entity (100) for a personal internet of things network, PIN, (200) the entity (100) being configured to: send a PIN registration request (101) to a control plane, CP, network entity (110), the PIN registration request (101) comprising an identifier, ID, of the entity (100); receive a response message (102) from the CP network entity (110), the response message requesting a respective ID of each of one or more PIN elements, PINEs, (201) of the PIN (200); send an identification message (103) to the CP network entity (110), the identification message (103) comprising the respective IDs of the one or more PINEs (201) of the PIN(200); and receive a data structure (104) from the CP network entity (110), the data structure (104) being for identifying the PIN (200) during a service operation.

2. The entity (100) according to claim 1, wherein the data structure (104) comprises: a first data field (301) indicating a group identifier, ID, of the PIN (200); a second data field (302) indicating a number of one or more PIN elements, PINEs,(201) of the PIN (200); a third data field (303) for each PINE (201) of the PIN (200), the third data field (303) indicating a type of the PINE (201).

3. The entity (100) according to claim 1 or 2, further configured to provide the data structure (104) to the one or more PINEs (201) of the PIN (200).

4. The entity (100) according to one of the claims 1 to 3, wherein the PIN registration request (101) further comprises a requested type of the data structure (104), the requested type being selected from one or more available types for the data structure (104).

5. The entity (100) according to one of the claims 1 to 4, wherein PIN registration request (101) further comprises a list including a respective ID and / or a respective type of each PINE (201) of the PIN (200).

6. The entity (100) according to one of the claims 1 to 5, further configured to send an update registration request (105), the update registration request (105) requesting a registration with a new CP network entity (130) to serve the PIN (200).

7. A control plane, CP, network entity (110) for managing a personal internet of things network PIN, the CP network entity (110) being configured to: receive a PIN registration request (101) from a PIN element, PINE, (100, 201) of the PIN (200), the PIN registration request (101) comprising an identifier, ID, of the PINE (100); send a response message (102) to the PINE (100, 201), the response message (102) requesting a respective ID of each of one or more PINEs (201) of the PIN (200); receive an identification message (103) from the PINE (100, 201), the identification message (103) comprising the respective IDs of the one or more PINEs (201) of the PIN(200); generate a data structure (104) for identifying the PIN (200) during a service operation; and send the data structure (104) to the PINE (100, 201).

8. The CP network entity (110) according to claim 7, wherein the data structure (104) comprises: a first data field (301) indicating a group identifier, ID, of the PIN (200); a second data field (302) indicating a number of one or more PIN elements, PINEs,(201) of the PIN (200); a third data field (303) for each PINE (201) of the PIN (200), the third data field (303) indicating a type of the PINE (201).

9. The CP network entity (110) according to claim 7 or 8, further configured to: send an authentication and authorization request, which includes the respective IDs of the one or more PINEs (201) of the PIN (200), to at least one authentication network entity; and receive an authentication and authorization result, which indicates which of the one or more PINEs (201) of the PIN (200) is authorized to access the service operation, from the at least one authentication network entity.

10. The CP network entity (110) according to one of the claims 7 to 9, further configured to, when generating the data structure (104), select one of a plurality of available coding methods to code the data included in the data structure.

11. The CP network entity (110) according to one of the claims 7 to 10, further configured to: receive a transfer request from a second CP network entity, the transfer request requesting context information of the PIN (200); and send the context information of the PIN (200) to the second CP network entity.

12. The CP network entity (110) according to claim 11, wherein the context information of the PIN (200) comprises the data structure (104).

13. The CP network entity (110) according to one of the claim 7 to 10, further configured to: receive an update registration request (105) from a PINE of a second PIN, the update registration request (105) requesting a registration with the CP network entity (110) to serve the second PIN; send a transfer request to a third CP network entity, the transfer request requesting context information of the second PIN; receive the context information of the second PIN from the third CP network entity; generate a second data structure for identifying the second PIN during a service operation; and send the second data structure to the PINE of the second PIN.

14. A radio access network, RAN, entity (120) for managing a core plane, CP, network entity transfer of a PIN element, PINE, (100, 201) of a personal internet of things network, PIN, (200) the RAN entity (120) being configured to: receive an update registration request (105) from the PINE (100, 201) of the PIN (200), the update registration request (105) requesting a registration with a new CP network entity for one or more PINEs (201) of the PIN (200); wherein the PIN (200) is associated with a first CP network entity (110); select a second CP network entity (130) as the new CP network entity based on the update registration request (105); andforward the update registration request (105) to the second CP network entity (130).

15. A data structure (104) for identifying a personal internet of things network, PIN, (200) during a service operation, the data structure (104) comprising: a first data field (301) indicating a group identifier, ID, of the PIN (200); a second data field (302) indicating a number of one or more PIN elements, PINEs, (201) of the PIN (200); a third data field (303) for each PINE (201) of the PIN (200), the third data field (303) indicating a type of the PINE (201).

16. The data structure (104) according to claim 15, further comprising an association of the PIN (200) with one or more control plane, CP, network entities (110) or network functions, NFs, related to the service operation.

17. The data structure (104) according to claim 15 or 16, wherein the data structure (104) is a user entity global unique temporal identifiers, UE-GUTI, which is extended with the first data field (301) indicating the group ID of the PIN (200), the second data field (302) indicating the number of PINEs (201), and the third data fields (303) indicating respectively a type of the PINE (201).

18. The data structure (104) according to claim 15 or 16, further comprising a public land mobile network, PLMN, ID, (304) wherein at least two third data fields (303) are associated wwith the PLMN ID (304).

19. A method (800) for managing a personal internet of things network, PIN, (200) the method (800) comprising: sending (801) a PIN registration request (101) to a core plane, CP, network entity (110), the PIN registration request (101) comprising an identifier, ID; receiving (802) a response message (102) from the CP network entity (110) , the response message (102) requesting a respective ID of each of one or more PIN elements, PINEs, (201) of the PIN (200; sending (803) an identification message (103) to the CP network entity (110), the identification message (103) comprising the respective IDs of the one or more PINEs (201) of the PIN (200); andreceiving (804) a data structure (104) from the CP network entity (110), the data structure being (104) for identifying the PIN (200) during a service operation.

20. A method (900) for managing a personal internet of things network, PIN, (200) the method (900) comprising: receiving (901) a PIN registration request (101) from a PIN element, PINE, (100, 201) of the PIN (200), the PIN registration request (101) comprising an identifier, ID, of the PINE (100); sending (902) a response message (102) to the PINE (100, 201), the response message requesting a respective ID of each of one or more PINEs (201) of the PIN (200); receiving (903) an identification message (103) from the PINE (100, 201), the identification message (103) comprising the respective IDs of the one or more PINEs (201) of the PIN (200); generating (904) a data structure (104) for identifying the PIN (200) during a service operation; and sending (905) the data structure (104) to the PINE (100).

21. A method (1000) for managing a control plane, CP, network entity transfer of a PIN element, PINE, (100, 201) of a personal internet of things network, PIN, (200) the method (1000) comprising: receiving (1000) an update registration request (105) from the PINE (100, 201) of the PIN (200), the update registration request (105) requesting a registration with a new CP network entity for one or more PINEs (201) of the PIN (200); wherein the PIN (200) is associated with a first CP network entity (110); selecting (1002) a second CP network entity (130) as the new CP network entity based on the update registration request (105); and forwarding (1003) the update registration request (105) to the second CP network entity (130).

22. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method (800, 900, 1000) according to one of the claims 19 to 21.

Images