Related Application

[0001] This application claims the benefit of provisional patent application serial number 62/465558, filed March 1 ^st , 2017, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

[0002] This disclosure relates generally to simultaneous registration of a user equipment to different mobility management entities.

Background

Next Generation Core Network, NGCN

[0003] Third Generation partnership project, 3GPP, is currently working on a specifying a new core network architecture for Next Generation System (3GPP TS 23.501) herein referred to as 5 Generation Core Network, 5G CN. 5GCN must support:

the new 5G radio access network, New RAN (also known as G-UTRAN or NextGen RAN or NG RAN), that supports the Evolved Long-Term Evolution, eLTE eNBs and/or the new radio access network technology, NR (also known as G-UTRA) base stations, BS, also referred to as 5G NodeB, or gNB, and/or, other non-3GPP access network such as Wireless Local Area Network, WLAN.

[0004] Figure 1 (prior art) illustrates one example of a point to point functional 5GCN architecture that supports 3GPP and non-3GPP access network as currently being specified in 3GPP. 5GCN is based on few principles which include but not limited to:

Separation of control and user plane functions.

- Access common Core network, CN, design: which consist of defining unified authentication

framework, common NAS protocol for 3GPP and non-3GPP accesses and a common (R)AN-5GCN interface to all the accesses. Thus, N1 , N2 and N3 interfaces of Figure 1 (prior art) should be common to the 3GPP (NR, eLTE) as well as non-3GPP accesses (e.g., WiFi).

Single termination-point for N1 interface (See Figure 1) in the NGCN, for a given access: This also allows a single security association between the UE and the NGCN for a given access.

Support for roaming with both Home routed traffic as well as Local breakout traffic in the visited

PLMN.

[0005] Figure 1 (prior art) illustrates a roaming architecture for non-3GPP accesses introduces a Non- 3GPP next generation Packet Data Gateway, ngPDG or N3IWF, as an evolution of the ePDG introduced in the Evolved Packet Core, EPC, as described in 3GPP TS 23.402. The N3IWF interfaces to the 5GCN via N2 and N3 interfaces. Namely, it interfaces to the Access Mobility function, AMF, via the N2 interface and to the user plane function, UPF, via the N3 interface. Additionally, the 5GCN as currently being specified in 3GPP specifies:

- A UE, which accesses the 5GCN over a non-3GPP access, shall support NAS signalling with 5GCN control-plane functions using N1 interface after UE attachment.

When a UE is connected via a 3GPP RAN and via standalone non-3GPP accesses, multiple N1 interfaces shall exist for the UE i.e. one N1 interface over 3GPP RAN and one N1 interface over non-3GPP access.

When a UE is simultaneously connected to the same PLMN of 5G core network over 3GPP access and non-3GPP access, the UE shall be served by a single AMF.

[0006] A UE establishes an Internet Protocol Security, IPSec tunnel with a N3IWF to attach to 5GCN over untrusted non-3GPP access. The UE is authenticated by and attached to the 5GCN during the IPSec tunnel establishment procedure. Figure 2 (Prior art) from 3GPP TS 23.502 illustrates a UE registration with authentication via untrusted non-3GPP access, i.e., via N3IWF.

[0007] Figure 2 (Prior art) describes the following steps:

1. The UE connects to an untrusted non-3GPP access network using WiFi access technology and it is assigned an IP address by the local WLAN. Any non-3GPP authentication method can be used, e.g. no authentication (in case of a free WLAN), EAP with pre-shared key, username/password, etc. When the UE decides to attach to 5G core network, the UE discovers the IP address of N3IWF in a 5G public Land Mobile Network, PLMN.

2. The UE proceeds with the establishment of an IPsec security Association, SA, with the N3IWF by initiating the IKEv2 signalling procedure according to IETF RFC 7296 and RFC 5998. The N3IWF behaves as EAP authenticator and retrieves the Network Access Identifier (NAI) of the UE in steps 2c, 2d. If the UE supports network slice selection over untrusted non-3GPP access, the UE may provide network slice selection assistance information, NSSAI, to N3IWF. The NSSAI is specified in 3GPP

TS 23.501.

3. The N3IWF shall select an AMF based on the NSSAI (if provided) and based on local policy. Then it shall create a Registration Request (Registration type, EAP-RES/ldentity) message on behalf of the UE and send this message to AMF over the N2 interface. The Registration type shall indicate the type of the requested registration (e.g. "initial registration"). The Registration Request shall include also the EAP-RES/ldentity message received by N3IWF in step 2d, which contains the NAI of UE. The Registration Request is encapsulated in a N2 message that sets up a N2 relationship between the AMF and the N3IWF for this UE and that contains the Access Type (AT), i.e. "untrusted non-3GPP access".

4. The AMF shall select an Authentication Server function, AUSF and shall request from AUSF to authenticate the UE by sending an Auth_Req (EAP-RES/ldentity) to AUSF. The AUSF shall operate as an EAP server and shall choose an EAP method to authenticate the UE, e.g. based on UE subscription information and information included in the NAI of UE. The AUSF may retrieve UE subscription information from Unified Data Management, UDM.

5. An EAP-based mutual authentication procedure takes place between the UE and AUSF. Several EAP request/ response messages may be required between the UE and AUSF depending on the chosen EAP authentication method. Between the UE and N3IWF the EAP messages are encapsulated within IKEv2 messages. Between the N3IWF and AMF the EAP messages are encapsulated within NAS Authentication Request/Response messages which, in turn, are encapsulated in a N2 NAS Downlink/uplink, DL/UL, transport messages. Between AMF and AUSF the EAP messages are encapsulated within Auth_Req/Res messages.

6a. When the EAP-based mutual authentication procedure is successfully completed, the AUSF shall send an Auth_Res(EAP-Success, Security keys) to AMF. The Security keys shall contain one or more master session keys which are used by AMF to derive NAS security keys and security key(s) for N3IWF.

6b. In turn, the AMF shall send a DL NAS Transport message to N3IWF. This message includes the EAP-Success message, the security key(s) for N3IWF and a NAS Security Mode Command (SMC) Request. After this step the N3IWF shall create a UE Context which stores UE-specific information such as the UE identity, the associated N2 connection, etc.

6c-6d. The N3IWF shall send an IKE_AUTH Response (EAP-Success) message to UE, which completes the establishment of the IPsec SA between the UE and N3IWF. This IPsec SA, referred to as the "signalling IPsec SA", shall further be used to securely transport NAS messages over IP between the UE and N3IWF. After step 6c further IKEv2 messages are exchanged (not shown in Figure 2 (prior art)) according to RFC 7296 in order to complete the establishment of the signalling IPsec SA.

7. Via the established signalling IPsec SA, the N3IWF shall send to UE the NAS SMC Request received from AMF in step 6b. The UE responds with a NAS SMC Complete message, which shall be forwarded by N3IWF to AMF within an N2 UL NAS Transport message.

8. The AMF shall send a NAS Registration Accept message to N3IWF, within an N2 Initial Context Setup Request, which shall be forwarded to UE via the established signalling IPsec SA. Finally, the UE shall respond with a NAS Registration Complete message which shall be forwarded by N3IWF to AMF within an N2 Initial Context Setup Response.

Summary:

[0008] The current 5GCN architecture as specified in 3GPP TS 23.501 and the corresponding

procedures as specified in 3GPP TS 23.502 assume that when a UE is simultaneously connected to the same PLMN of 5G core network over 3GPP access and non-3GPP access, the UE shall be served by a single AMF. However, it does not address the problem when a UE is simultaneously connected to a visited PLMN (AMF in visited PLMN) and its home PLMN (AMF in home PLMN), in which case it is not possible to select the same AMF. [0009] It is very possible for a UE to be connected to a visited PLMN and a home PLMN

simultaneously. A roaming UE may attach to a visited AMF in a visited 5GCN belonging to a visited PLMN when it roams and attaches via 3GPP 5G NR/5G RAN to the visited AMF using the N1 interface. The visited AMF is selected by the 5G NR/5G RAN. The UE is thus authenticated by and attached to the visited PLMN over the 5G NR/RAN. The UE may also connect to Wireless local access network if available to access home services. The UE selects an N3IWF that may be preconfigured in the UE or configured by the user's home operator. The N3IWF that is selected is very likely an N3IWF in the user's home network. The UE will then attempt to establish an IPSec tunnel with the N3IWF in the home network to connect to the home network's 5GCN. The N3IWF selects an AMF in the home network, authenticates and attaches the UE in the 5G CN. This leads to a situation where the UE may end up with 2 AMFs, one in the visited PLMN and one in the home PLMN/home network. However, such configuration will require the UE to support two 5G NAS states, one towards the visited AMF over the 5G NR/RAN and another one to the home AMF over the WLAN access. In this specification home network, home PLMN and home domain are used interchangeably and are used to indicate the home network owning the UE subscription. Similarly, visited domain, visited network and visited PLMN are used interchangeably and are used to indicate the network visited by a roaming UE. Some UEs may be able to handle such capabilities, but other UEs may not be able to support such capability.

[0010] Some embodiments proposed herein consists of when the UE or the network does not support multiple registrations over different networks (e.g., home and visited), the AMF is relocated to the last/new AMF the UE has last connected to. For example, if the UE is attached to a visited AMF over 3GPP RAN in the visited network, then connects to the home AMF over the WLAN network via the N3IWF in the home network, then the home AMF would determine if it should relocate the AMF to the home network in accordance with the UE and network capability supporting multiple registrations over multiple networks. For example, when necessary, the UE will be home routed to a home AMF to enable the UE to transfer sessions between 3GPP and non-3GPP access, which is not possible in case the UE is in Local Break out, LBO, in the visited domain when connected over the 3GPP access (i.e., an AMF in visited domain is assigned) while at the same time the UE is home connected to a home AMF when connected over the non-3GPP access, e.g., WLAN.

[0011] According to another embodiment, If the UE and the network support multiple registrations over different networks (3GPP and non-3GPP access networks), the UE would then be allowed to maintain multiple registrations, in which case the UE does not need to transfer sessions between 3GPP Access and non-3GPP access.

[0012] The embodiments are mainly described with a V-AMF in the visited network and a H-AMF in the home network, however similar embodiments will apply if two AMF instances or two different AMFs are selected in the same network when the UE accesses each AMF instance via a 3GPP access network and a non-3GPP access network to the same 5GCN network. [0013] In accordance with one aspect, a method of attaching a user equipment to a newly selected mobility management entity in a network and over a new access network is provided and performed at the newly selected mobility management entity. The method comprises receiving at the newly selected mobility management entity (e.g., H-AMF) an identity of a previous mobility management entity (e.g., V- AMF) to which the user equipment has previously registered over a first access network, such as 3GPP access. The method further comprises the step of determining whether relocation from the previous mobility management entity to the newly selected mobility management entity is to be performed and in response to determining the relocation is to be performed, the newly selected mobility management entity executes the step of sending a message to the previous mobility management entity indicating the user equipment has attached over the new access network and may indicate if the user equipment supports simultaneous registration to different access networks, or whether a deregistration from the first access network should be performed. The message may comprise an identity of the network hosting the newly selected mobility management entity, such as a PLMN identity.

[0014] In one aspect, the receiving step further comprises receiving by the newly selected mobility management entity the user equipment authorization to maintain multiple simultaneous registrations over multiple access networks.

[0015] In another aspect, the step of determining the relocation is to be performed is based on at least one of an authorization to maintain multiple simultaneous registrations over multiple access networks, the user equipment capability to support multiple simultaneous registration and/or the network capability to support multiple simultaneous registration.

[0016] In an aspect, the new access network is a non-3GPP access network such as wireless fidelity, WiFi, access network.

[0017] In one aspect, the identity of the previous mobility management entity is received at the newly selected mobility management entity from at least one of a unified data management entity or the user equipment.

[0018] In one aspect, the previous mobility management entity is in a visited network and the newly selected mobility management entity is the user equipment home network (or vice versa)

[0019] In accordance with another aspect, a method of relocating a previous mobility management entity in a first network to which a user equipment is registered to through a first access network is provided. The method is executed at the previous mobility management entity and comprises the step of receiving from a new mobility management entity in a second network, a request message for relocation indicating the user equipment has attached to the new mobility management entity over a second access network and may comprise instruction to deregister the user equipment from the first network. The request for relocation may also comprise a network identity of the new mobility management entity which may be a public land mobile network, PLMN, identity. [0020] The method further comprises the steps of determining whether deregistration of the user equipment is to be performed over the first access network and sending a relocation response message indicating the result of the relocation and of the deregistration of the user equipment from the first network.

[0021] In one aspect, the step of determining at the previous mobility management entity whether deregistration of the user equipment is to be performed is based on the capability of the user equipment to support multiple simultaneous registration and/or based on authorization of the user equipment to maintain multiple simultaneous registration. If deregistration is to be performed, the previous mobility management entity performs sending a deregistration message to the user equipment over the first access network and indicating to the new mobility management entity that relocation is completed. However, if the previous mobility management entity executes the step of determining that deregistration of the user equipment is not to be performed, it indicates to the new mobility management entity that registration of the user equipment is to be maintained at the previous mobility management entity.

[0022] In one aspect, the previous mobility management entity may maintain mobility management context of the user equipment if the user equipment is deregistered.

[0023] In one aspect, the first access network is a cellular radio access network or 3GPP access network and the the second access network is a non-3GPP access network such as wireless fidelity, WiFi, access network.

[0024] In another aspect, the previous mobility management entity is in a visited network (e.g., Visited PLMN) and the new mobility management entity is the user equipment home network (e.g., Home PLMN).

[0025] In another aspect, a network entity that implements a newly mobility management entity selected for a new access by a user equipment when the user equipment has previously registered over a previous access network to a previous mobility management entity is provided and is configured with one or more modules, where the one or more modules perform any of the embodiments herein.

[0026] In another aspect, a network entity that implements the previous mobility management entity is provided and is configured with one or more modules, where the one or more modules perform any of the embodiments herein.

[0027] In another aspect, a network entity comprises at least one one processor; and memory that comprises instructions executable by the at least one processor whereby the network entity is operable to perform any of the embodiments provided herein wherein the network entity implements either a new mobility management or a previous mobility management entity.

[0028] This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

Brief Description of the Drawings

[0029] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serves to explain the principles of the disclosure.

[0030] Figure 1 (prior art) illustrates one example of a 5GCN roaming architecture for non 3GPP access as specified in 3GPP TS 23.501.

[0031] Figure 2 (prior art) illustrates a flow diagram for a UE registration via untrusted non-3GPP access.

[0032] Figure 3 illustrates an example of a 5GCN roaming architecture for non-3GPP access for a UE connected to VPLMN over 3GPP RAN access and is configured to connect to a N3IWF over untrusted

WLAN in the home network, according to an embodiment.

[0033] Figure 4 illustrates a flow diagram for a UE previously connected to VPLMN over 3GPP RAN access and requesting a registration via untrusted non-3GPP access to its home network where the

Home AMF requests relocation from the visited AMF, according to an embodiment.

[0034] Figure 5 illustrates a method in the new AMF selected by the N3IWF in the home network, according to an embodiment.

[0035] Figure 6 illustrates a method in the previous/visited AMF selected by the 3GPP RAN in the visited network when the UE is requesting an attach in the home network over untrusted WLAN, according to an embodiment.

[0036] Figure 7 illustrates a circuitry of a network node implementing AMF, according to an

embodiment.

[0037] Figure 8 illustrates a circuitry of a network node implementing AMF, according to another embodiment.

[0038] Figure 9 illustrates a virtualization environment in which mobility management functions according to some embodiment(s) may be implemented.

Detailed Description

[0039] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. [0040] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0041] References in the specification to "one embodiment," "an embodiment," "an example

embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include 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 implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0042] 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," "includes," and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

1. Generalizations

[0043] In the present disclosure, a UE, which is a non-limiting term refers to any type of wireless device communicating over one or more wireless radio interfaces simultaneously with radio access nodes such as eLTE eNB, LTE eNB, 5G/NR gNB, WiFi Access point, AP. The UE also connects with the 5GCN, namely AMF/SMF over a network interface (e.g., non-access stratum, NAS, or N1). The UE may also communicate with another UE in a cellular or mobile communication system and may communicate with one or more loT devices which use the UE as a relay or gateway to the 5GCN. Examples of a UE are a Personal Digital Assistant (PDA), a tablet, mobile terminals, a smart phone, Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), Universal Serial Bus (USB) dongles, etc.

[0044] When the UE is simultaneously connected to different radio access networks, embodiments in this specification assume a UE that supports one and common NAS protocol state for the different radio access networks and that allows the UE to connect to a single AMF. The UE may also have different NAS protocol states, one for each radio access network where the UE may be connected to different AMFs in different networks.

2. Description of a 5GCN roaming architecture for non-3GPP access [0045] Figure 3 illustrates an embodiment of a 5GCN roaming architecture for non-3GPP access for a UE 100 connected to VPLMN over 3GPP RAN access and is configured to connect to a N3IWF 101 over untrusted WLAN in the home network. As stated earlier, the current 3GPP specification 3GPP TS 23.501 and 3GPP TS 23.502 assumes that a roaming UE 100 connected simultaneously to 3GPP RAN/5G RAN and WLAN, the UE 100 selects or is assigned a N3IWF in the visited network, or PLMN as illustrated in Figure 1 (prior art). However, it is also very likely as per the proposed embodiment, that a UE 100 attached to visited PLMN via 3GPP RAN or 5G RAN, prefers to connect to its home network/PLMN over untrusted WLAN and selects instead a N3IWF 101 in the home network instead of an N3IWF in the visited network. The home N3IWF 101 may be preconfigured in the UE 100, or may be configured at the UE 100 during local authentication in the WLAN or via UE device management procedure by the home PLMN. The N3IWF is used in this disclosure to refer to a security gateway over which the UE accesses the core network services. The security gateway establishes an IPSec tunnel with the UE after the UE is authenticated by the core network.

[0046] Figure 3 illustrates a UE 100 attached to a visited AMF 103 via the 3GPP RAN or 5G RAN and connects to the home PLMN via untrusted WLAN, mainly connected to a home AMF 102 via the N3IWF 101 in the home PLMN. Although Figure 3 shows untrusted WLAN in the home PLMN or home network, it is not limited thereof as the untrusted non-3GPP network (e.g., untrusted WLAN) may also belong to the visited PLMN. Alternatively, the untrusted non-3GPP network may not belong to any particular PLMN and may instead be a WLAN in a public hotspot, such as airport, hotel, etc. operated by a WLAN provider which may or may not have service agreements with either the visited PLMN or the home PLMN.

[0047] The UE 100 accesses the home PLMN by establishing an IPSec tunnel with the N3IWF 101 over the NWu interface. The H-AMF 102 supports authentication of the UE 100 connected over N3IWF 101. The authentication carried out over IKE v2 signaling on the NWu interface prior to establishment of the IPSec tunnel is relayed over the N2 interface to the H-AMF 102 for further authentication with the AUSF 105. The N3IWF 101 relays over the N2 interface the uplink and downlink control-plane NAS (N1) signaling between the UE 100 and H-AMF 102 once the IPSec tunnel is established and handles management of mobility and authentication/security context state(s) of the UE 100 connected via the non-3GPP access. Additionally, Figure 3 illustrates an interface Nx between the H-AMF 102 and the V- AMF 103. The UE is already attached to a visited PLMN, namely a V-AMF 103, over a 3GPP RAN/5G RAN. The UE 100 subsequently performs another attach over the untrusted non-3GPP access (i.e., untrusted WLAN) to the H-AMF 102 in the home PLMN while maintaining the attach in the visited PLMN. The H-AMF 102 obtains the identity of the V-AMF 103 from either the UDM 104, or the AUSF 105 or even the UE 100 assuming the UE 100 appends the identity of the V-AMF 103 in a configuration payload within the IKE messages (e.g., IKE_AUTH message).

[0048] During authentication phase of the UE 100 by the H-AMF 102, the H-AMF 102 obtains the

identity of the V-AMF 103, and may also obtain UE capability and/or network capabilities and user authorization for the UE 100 to maintain simultaneous registration over two different access networks, i.e., with two different AMFs. The UE capability may be obtained from the UE 100 or from the profile information from the UDM 104. The network capability and user authorization may be obtained from the UDM 104 or may also be obtain from a policy server entity (not shown in the Figure).

[0049] The H-AMF 102 uses the Nx interface when it needs to communicate with the V-AMF 103 to indicate that the UE has registered over the untrusted WLAN access and requests relocation of the AMF to the home PLMN. The H-AMF 102 may not send a message to the V-AMF 103 if the UE capability, network capability and user authorization indicate support for simultaneous registration and that there is no need to transfer the session between 3GPP access or RAN and non-3GPP access. If the V-AMF 103 accepts the relocation, it deregisters the UE over the 3GPP RAN but may maintain the attach state in the V-AMF for a certain duration in case the UE 100 decides to re-register again over the 3GPP RAN. The V-AMF 103 may also deny the relocation, in which case the UE 100 remains attached to V-AMF 103. If the V-AMF 103 informed the H-AMF 102 that relocation is denied, the H- AMF 102 reports to the UDM 104 or the policy server in the home network. The H-AMF 102 may then be authorized to maintain the registration or detach/deny the UE 100 access to the home PLMN. The UDM 104 or policy server in the home may also force deregister the UE 100 in the visited PLMN if configured to do so.

3. Description of a registration procedure in the home network over an untrusted non-3GPP access for a UE that is previously connected to a VPLMN over 3GPP RAN access

[0050] Figure 4 illustrates a flow diagram for a UE 100 previously connected/ attached to a V-AMF in a VPLMN over 3GPP RAN access and requesting a registration via untrusted non-3GPP access to its home network, according to an embodiment.

[0051] At step 401, the UE 100 selects a 3GPP RAN belonging to a visited network/domain or PLMN, and starts a registration procedure. The UE 100 sends to the 3GPP RAN in the visited domain/PLMN an access network, AN, message which includes a Registration Request which comprises a

Registration type, Subscriber Permanent Identifier or Temporary User identifier, Security parameters, network slice selection assistance information, NSSAI, UE 5GCN Capability, etc. The Registration type indicates the UE wants to perform an "initial registration" (i.e. the UE is in non-registered state), a "mobility registration" (i.e. the UE is in registered state and initiates a registration due to mobility) or a "periodic registration". The Security parameters are used for Authentication and integrity protection. NSSAI indicates the Network Slice Selection Assistance Information as specified in 3GPP TS 23.501.

[0052] At step 402, the 3GPP RAN selects an AMF; in this case it selects a V-AMF 103 in the visited domain or visited PLMN. At step 403, the 3GPP RAN sends an N2 message to the V-AMF 103 comprising N2 parameters, the Registration Request which comprises the Registration type, Permanent User ID or Temporary User ID, Security parameters, NSSAI as received by 3GPP RAN. At step 404, the V-AMF 103 stores its identity in the AUSF 105 and/or UDM 104 as part of initiating and completing the authentication and attachment procedure at step 405 of the UE 100 over the 3GPP RAN/5G RAN. Note that the details of the attach/registration and authentication procedure is well known as specified in 3GPP 23.502, clause 4.2.2 "Registration procedures".

[0053] At step 406, the UE 100 connects to an untrusted non-3GPP access network using WiFi access technology and it is assigned an IP address by the local WLAN. Any non-3GPP authentication method can be used, e.g. no authentication (in case of a free WLAN), EAP with pre-shared key, username/password, etc. At step 407, when the UE decides to attach to 5GCN, the UE discovers or selects the IP address of the N3IWF 101 in a 5G PLMN. In this embodiment, the address of the N3IWF 101 is either preconfigured in the UE 100 or may be assigned by the AAA in the WLAN network or may have been previously configured in the UE by the home domain/home PLMN. The UE 100 selects the N3IWF 101 in the home domain.

[0054] At step 408a, the UE 100 proceeds with the establishment of an IPsec security Association, SA, with the N3IWF 101 in the home domain/home PLMN by initiating the IKEv2 signalling procedure according to IETF RFC 7296 and RFC 5998. The N3IWF 101 behaves as EAP authenticator and retrieves the Network Access Identifier, NAI, of the UE in steps 408c, 408d. If the UE 100 supports network slice selection over untrusted non-3GPP access, the UE 100 may provide network slice selection assistance information, NSSAI, to N3IWF 101. The UE 100 may also provide the identity of the V-AMF 103 to which it is attached on the 3GPP RAN and may also provide the status of the registration over the 3GPP RAN. This information may be included in IKEv2 configuration payload of the IKE_AUTH message or other appropriate IKE message.

[0055] At step 409a, the N3IWF 101 shall select an AMF in the home domain (H-AMF 102) based on the NSSAI (if provided) and based on local policy. Then it shall create a Registration Request (Registration type, EAP-RES/ldentity) message on behalf of the UE 100 and send this message to the H-AMF 102 over the N2 interface at step 409b. The Registration type shall indicate the type of the requested registration (e.g., initial registration or simultaneous registration) and may be received by the UE 100 in the IKE message. The Registration Request shall include also the EAP-RES/ldentity message received by N3IWF 101 at step 408d, and which contains the NAI of UE. The Registration Request is encapsulated in a N2 message that sets up a N2 relationship between the H-AMF 102 and the N3IWF 101 for the UE 100 and that contains the Access Type, AT, i.e. "untrusted non-3GPP access". At step 410, the H-AMF 102 shall select an Authentication Server function, AUSF 105 and shall request from the AUSF 105 to authenticate the UE 100 by sending an Auth_Req (EAP- RES/ldentity) to AUSF 105 as shown at step 411. The H-AMF 102 may send a separate registration message to the AUSF 105 or UDM 104 in order to register the identity of the selected H-AMF 102 and to indicate that the UE 100 is registering via the untrusted non-3GPP WLAN network. Alternatively, the H-AMF 102 may append its identity in the AUTH-Request at step 411 to the AUSF 105, and the AUSF 105 sends it to the Unified Data Management, UDM 104, when retrieving the UE subscription information, in which case step 410 is omitted. The AUSF 105 shall operate as an EAP server and shall choose an EAP method to authenticate the UE 100, e.g. based on UE subscription information and information included in the NAI of UE 100. The AUSF 105 may retrieve UE subscription information from the UDM 104 to provide it to the H-AMF 102.

[0056] At steps 412a-412f, an EAP-based mutual authentication procedure takes place between the UE 100 and the AUSF 105. Several EAP request/ response messages may be required between the UE 100 and the AUSF 105 depending on the chosen EAP authentication method. Between the UE and N3IWF the EAP messages are encapsulated within IKEv2 messages. Between the N3IWF101 and the H-AMF 102 the EAP messages are encapsulated within NAS Authentication Request/Response messages which, in turn, are encapsulated in a N2 NAS Downlink/uplink, DL/UL, transport messages. Between the H-AMF 102 and AUSF 105 the EAP messages are encapsulated within Auth_Req/Res messages. At step 413a, when the EAP-based mutual authentication procedure is successfully completed, the AUSF 105 shall send an Auth_Res(EAP-Success, Security keys) to the H-AMF 102. The Security keys shall contain one or more master session keys which are used by AMF to derive NAS security keys and security key(s) for N3IWF. The AUSF 105 may at step 413a include the identity of the V-AMF 103 that may have been received by the UDM 104, in which case step 414 is omitted. At step 413b, the H-AMF 102 shall send a DL NAS Transport message to N3IWF 101. This message includes the EAP-Success message, the security key(s) for N3IWF 101 and a NAS Security Mode Command, SMC, Request. After this step the N3IWF 101 shall create a UE Context which stores UE- specific information such as the UE identity, the associated N2 connection, etc.

[0057] At steps 413c-413d, the N3IWF 101 shall send an IKE_AUTH Response (EAP-Success) message to the UE 100, which completes the establishment of the IPsec SA between the UE 100 and the N3IWF 101. This IPsec SA, referred to as the "signalling IPsec SA", shall further be used to securely transport NAS messages over IP between the UE 100 and the N3IWF 101. After step 413c, further IKEv2 messages are exchanged (not shown in Figure 4) according to RFC 7296 in order to complete the establishment of the signalling IPsec SA.

[0058] If the H-AMF 102 has sent its identity in the registration request at step 410 or appended its identity in the AUTH Request at step 411 , the H-AMF 102 receives a response from the

AUSF105/UDM104 at step 413a in the AUTH Response or at step 414 if a standalone registration is sent to UDM 104 at step 410 which may comprise the V-AMF 103 identity. If the V-AMF 103 identity is received at step 413a, step 414 is omitted. Note that the message at step 414 may be received at any time after step 410. The Registration response at step 414 (or the AUTH response at step 413a) could comprise the identity of the V-AMF 103, and may comprise the network capability for supporting simultaneous registration for the UE 100, the UE capability for simultaneous registrations if not received from the UE 100, and an authorization code indicating the user is allowed/not allowed to maintain simultaneous registrations over multiple and different access networks. The H-AMF 103 may receive the identity of the V-AMF 103 from the UE 100 as an alternative to receiving it from the AUSF/104/UDM105 or the likes (e.g., a policy server not shown). At step 415, the H-AMF 102 uses the information received from the AUSF105/UDM104 at step 414 or 413a to determine if it should send a relocation message to the V-AMF 103. If the H-AMF 102 only receives an identity of the V-AMF 103, it may immediately trigger a relocation message to the V-AMF 103 indicating a request for relocation due to UE registration in the home network as shown at step 415 and may include an instruction (action) to deregister the UE 100. The identity of the home domain or home PLMN identity may be included if it cannot be inferred from the identity/address of the H-AMF 102. If in addition the H-AMF 102 receives one or more of:

the home network policy for supporting simultaneous registration for the UE 100 (if one is not configured in the H-AMF),

the UE capability for simultaneous registrations (which may also be provided by the UE 100), and/or

an authorization code indicating the user is allowed/not allowed to maintain simultaneous registrations over multiple and different access networks,

the H-AMF 102 could use the received information to determine if a relocation request to the V-AMF 103 is required. If the user is not authorized to maintain simultaneous registration, or the network policy does not allow simultaneous registration or the UE capability indicate that the UE 100 does not support simultaneous registration, the H-AMF 102 sends a relocation message to the V-AMF 103 at step 415 and the message may include an instruction (Action) to the V-AMF 103 to deregister the UE from the VPLMN or visited domain and may include the identity of the home domain. The instruction (Action) to deregister is optional because the relocation message when received can be used as an implicit indication to deregister the UE after reallocating the AMF to the home and maintain a single AMF for the UE 100.

[0059] In another embodiment, if the user is authorized to maintain simultaneous registration, and the home network policy allows simultaneous registration and the UE capability indicate that the UE 100 supports simultaneous registration, the H-AMF 102 may not send a relocation request to the V-AMF 103.

In one embodiment, the H-AMF 102 may receive the identity of the V-AMF 103 and/or the UE capability to support multiple simultaneous registration over different access networks from the UE 100 during the IPSec SA establishment in for example an IKE configuration payload.

[0060] At step 416, upon receiving the relocation message from the H-AMF 102 instructing the V-AMF 103 to deregister the UE 100, the V-AMF 103 performs its own determination to maintain or deregister the UE 100 in accordance with one or more of the following:

- if the V-AMF 103 determines the request to deregister the UE 100 is from the trusted home network of the UE100, it deregisters the UE 100 by sending a detach to the UE 100 and 3GPP RAN without keeping any UE registration context. The V-AMF 103 sends at step 416 a response message to the H-AMF 102 indicating the relocation and deregistration is completed or accepted.

- the V-AMF 103 initiates a UE de-registration and disconnection from the 3GPP RAN, may update the record in the AUSF 105/UDM 104 and informs the H-AMF 103 at step 416 that the relocation and UE deregistration has been completed or accepted. Note that the V-AMF 103 may not purge the UE registration context and instead maintains the context temporarily in case the UE 100 re-attaches to the V-PLMN.

- the V-AMF 103 does not initiate a UE de-registration and disconnection from the 3GPP RAN and sends at step 416 to the H-AMF 102 a relocation response with a result code indicating that the relocation/UE deregistration is not performed. The V-AMF 103 may also inform the UDM 104 that the UE 100 stays registered in the V-AMF 103 as an indication that UE may be maintaining multiple or dual registrations.

[0061] At step 417, if the H-AMF 102 receives a relocation response from V-AMF 103 with the result code indicating UE deregistration not performed, the H-AMF 102 may inform the AUSF 105/UDM 104 or the home policy server (not shown) to determine if the registration to the home network over the non 3GPP untrusted access should be maintained if the UE is already registered through the 3GPP RAN or if simultaneous registration should be maintained (explicit message not shown in Figure 4). This query to the AUSF 105/UDM 104 or policy server may be performed if the H-AMF 102 has not previously received any information about the UE or home network policy (if home network policy not preconfigured in H-AMF 102) for simultaneous registrations. Alternatively, the H-AMF 102 may make that determination on its own if configured with the corresponding network policies.

[0062] At step 418a, the N3IWF shall send to the UE 100 the NAS SMC Request received from H- AMF102 at step 413b. The UE 100 responds with a NAS SMC Complete message at step 418b, which shall be forwarded by N3IWF 101 to the H-AMF102 within an N2 UL NAS Transport message at step 418c.

At step 419a, assuming the H-AMF 102 received the relocation response from the V-AMF 103 indicating relocation and deregistration is completed, the H-AMF102 shall send a NAS Registration Accept message to N3IWF 101 within an N2 Initial Context Setup Request, which shall be forwarded to the UE 100 via the established signalling IPsec SA as shown at step 419b. Finally, the UE 100 shall respond with a NAS Registration Complete message at step 419c which shall be forwarded by the N3IWF 101 to the H-AMF 102 within an N2 Initial Context Setup Response at step 419d.

[0063] On the other hand, if the H-AMF 102 received the relocation response from the V-AMF 103 prior to the H-AMF 102 sending the registration response to the UE 100 and the relocation message indicates that relocation and UE deregistration are not performed by the V-AMF 103, and the H-AMF 102 determined the UE 100 should not maintain simultaneous registration over different access networks (or two AMFs), the H-AMF 102 could send a Registration reject to the UE 100.

[0064] In another embodiment, If the UE 100 has already completed its registration with the H-AMF 102 when the relocation response message from the V-AMF 103 is received indicating no UE deregistration and or failed relocation, the H-AMF 102 may then abort the ongoing registration in the home network and sends a NAS detach to the UE 100 through the N3IWF 101 over the established IPSec tunnel and the untrusted non-3GPP access network.

[0065] The embodiments of Figure 4 are mainly described with a V-AMF in the visited network and a H- AMF in the home network, however similar embodiments will apply if two AMF instances or two different AMFs are selected in the same network when the UE accesses each AMF instance via a 3GPP access network and a non-3GPP access network to the same 5GCN network.

4. Description of exemplary method at a home AMF or new AMF for registering a UE over a non-3PP access when the UE is already attached to a visited network/visited PLMN over a different access network.

[0066] Figure 5 illustrates a method 50 in a newly selected mobility management entity, also referred to as the home Access and Mobility function, AMF, in the UE's home network/domain/PLMN according to some embodiments. In this method, the UE is already attached to a visited AMF in a visited network/domain/PLMN over a first access network (i.e., 3GPP RAN/5G RAN) and simultaneously requests registration to its home network over a second access network (i.e., WLAN). To access the home network over the WLAN, if the WLAN is untrusted (e.g., public cafe, hotel, airport), the UE initiates authentication over IKEv2 signalling to setup an IPSec security association, SA, with an N3IWF in the home network. When the N3IWF receives the IKEv2 authentication message from the UE, it selects a mobility management entity or function, H-AMF, to register and authenticate the UE with the authentication server function. Method 50 is performed in the H-AMF when upon it receives the registration/authentication message from the UE via the N3IWF it sends a message to the authentication server function or subscriber server (e.g., UDM) to provide the identity of the H-AMF for storage.

[0067] Step 51 consists of the H-AMF receiving the identity of the visited AMF (to which the UE is attached over the first access network). The H-AMF may receive the identity of the V-AMF using different options:

- provided by the UE in the IKE message and forwarded to H-AMF by N3IWF. Additionally, the UE may provide its capability to support multiple simultaneous registration over different access networks. - Provided by the authentication server function or subscriber management (e.g., UDM) in a message. The message may be a response message to an authentication message sent to the authentication server or to a registration message if previously sent to the subscriber server (e.g., UDM). Additionally, the message may comprise the home network policy for supporting simultaneous registration for the UE, the UE capability for simultaneous registrations (or provided by the UE as per above), and an authorization code indicating the user is allowed/not allowed to maintain simultaneous registrations over multiple and different access networks.

[0068] At step 52, the H-AMF executes the step of determining if relocation of the AMF to a single AMF should be performed. Relocation allows the UE to use one NAS interface with a single mobility management entity/function or AMF. If the H-AMF does not receive the V-AMF identity (either from the UE or the authentication server/subscriber server (UDM), it does not proceed with relocating the mobility management entity/function. If on the other hand the H-AMF only receives the V-AMF identity, the H-AMF proceeds with step 53 of sending a relocation message to the V-AMF. The relocation may include the following information:

a. an instruction (action) to deregister the UE.

b. It may also include the identity of the home domain or home PLMN identity. Note that if the UE has instead registered to two AMF instances or two different AMFs in the same 5GCN network (i.e., no roaming scenario) and the UE accesses a first AMF instance via a 3GPP access network and the second AMF instance over non-3GPP access network, the identity of the network does not need to be transmitted to the first AMF when requesting relocation.

[0069] If the H-AMF receives in addition to the V-AMF, the home network policy for supporting

simultaneous registration (if none preconfigured in the H-AMF), the UE capability for simultaneous registrations, and an authorization code indicating the user is allowed/not allowed to maintain simultaneous registrations over multiple and different access networks, the H-AMF further uses the information to determine if it a relocation message ought to be sent to the V-AMF. If the user is not authorized to maintain simultaneous registration, or the network does not support simultaneous registration or the UE capability indicate that the UE does not support simultaneous registration, the H- AMF proceeds with step 53 of sending a relocation message to the V-AMF where the message may further include the identity of the home domain and an instruction (Action) to the V-AMF to deregister the UE from the VPLMN or visited domain.

[0070] On the other hand, if the user is authorized to maintain simultaneous registration, and the network policy allows simultaneous registration and the UE capability indicates that the UE supports simultaneous registrations, the H-AMF would not send a relocation request to the V-AMF.

[0071] If upon receiving a response from the V-AMF indicating that the V-AMF wishes to maintain the UE registered in the first access network, i.e., relocation to the H-AMF is not accepted by the V-AMF, the H-AMF could proceed and maintain the UE registered in the home network while the UE is also registered in the visited PLMN. In this case, the response message from the V-AMF is merely a notification/information message from the visited network. In another aspect, the H-AMF could determine if it should keep the UE registered in the home network if the V-AMF did not deregister the UE in the visited network. If the H-AMF has not previously received any information on the UE and/or network policy allowing for multiple simultaneous registration and/or the authorization for the UE to use multiple simultaneous registration, the H-AMF may inform the home subscriber server or the home policy server about the V-AMF response and request instruction from either the home policy server or the home subscriber server (e.g., UDM) or the like, or may be configured with operator policy to determine if it should deregister the UE from the home PLMN or allow the UE to continue with simultaneous registration in both the home and the visited network. If the H-AMF determines the UE should be deregistered from the home network instead, the H-AMF initiates deregistration of the UE from the home network. The Home policy server or home subscriber server may trigger forced deregistration in the visited network if it prefers to maintain a single registration in the home network.

5. Description of exemplary method at the visited or previous AMF to which a UE is attached over a 3GPP access and receiving a relocation request for relocating the AMF to the home

domain/network/PLMN.

[0072] Figure 6 illustrates embodiments of a method 60 in the previous/visited mobility management entity/function herein also referred to as visited V-AMF selected by a first access network (3GPP RAN) in the visited network when the UE is requesting an attach in the home network over a second access network (untrusted WLAN) to a home H-AMF selected by the N3IWF. Step 61 describes the step at the V-AMF receiving the relocation message from the H-AMF requesting AMF relocation to the home network of the UE because the UE is registered to the home network via another access network, namely an untrusted WLAN over which the UE has established an IPsec based Virtual private network, VPN, tunnel to a security gateway (e.g., an N3IWF or ngPDG) in the home network. The relocation message may include an instruction to the V-AMF to deregister the UE and may include the home network identity (PLMN identity) as well. Note that if the UE has instead registered to two AMF instances or two different AMFs in the same 5GCN network (i.e., no roaming scenario) and the UE accesses a first AMF instance via a 3GPP access network and the second AMF instance over non- 3GPP access network, the identity of the network does not need to be transmitted to the first AMF when requesting relocation.

[0073] At step 62, the V-AMF performs the step of determining whether UE deregistration as a result of relocation or explicit instruction to deregister the UE (if one is received) in accordance with one or more of the following:

- in one aspect, if the V-AMF determines the request to deregister the UE is from the trusted home network of the UE, it deregisters the UE by sending a detach to the UE over the first access network (3GPP RAN) but may keep UE registration context temporarily in case the UE re-attaches to the visited network. The V-AMF at step 63 performs sending a relocation response message to the H-AMF indicating the relocation and deregistration is completed or accepted.

- in another aspect, the V-AMF initiates a UE de-registration and disconnection from the first access network (3GPP RAN), may initiate updating the record in the home subscriber server or policy server. The V-AMF then initiates sending to the H-AMF at step 63 a relocation response message that indicates the relocation and the UE deregistration has been completed or accepted. In this example, the V-AMF does not purge the UE registration context and instead maintains the context temporarily in case the UE re-attaches to the visited network or V-PLMN.

-In another aspect, the V-AMF does not initiate a UE de-registration and disconnection from the 3GPP RAN and responds to the H-AMF by sending at step 63 a relocation response comprising a result code indicating that the relocation and UE deregistration are not performed by the V-AMF. The V-AMF may also inform the home subscriber server or policy server that the UE stays registered in the V-AMF as an indication that UE may be maintaining multiple active registrations.

The embodiments herein assume the UE is registered first in the V-AMF (103) then registers to the H- AMF (102) as the new selected mobility management entity. However the embodiments described herein apply if the user equipment is first registered to a H-AMF via a non-3GPP access then registers to the V-AMF via the 3GPP access, in which case the H-AMF (102) becomes the previous mobility management entity. In that case, the request for relocation may be triggered by the V-AMF (103) or the H-AMF (102) is notified of the access over the 3GPP access in the visited network and determines if should trigger a relocation as described herein.

] Figure 7 illustrates an aspect of a network node implementing a home AMF 102 or the newly selected mobility management entity or a V-AMF103 or the previous mobility management entity. The network node comprises a circuitry 70 which executes the method steps according to the embodiments as described in Figure 5 for the H-AMF 102 and Figure 6 for the V-AMF 103, along with steps 409b, 410-416, 417-419 for H-AMF 102 and steps 415-416 for the V-AMF 103, in addition to other embodiments described herein. The circuitry 70 may comprise one or more processors 71 and a storage 72 (also referred to as memory) containing instructions, which when executed, cause the one or more processors 71 to perform the steps according to the methods of Figure 5 and Figure 6 as described herein. The circuitry 70 may further comprise a communication interface 73 to communicate with external entities such as with UE devices using NAS protocol (over for e.g., N1 interface) and with other network nodes in the same network and other networks (such as N3IWF or 3GPP RAN over an N2 interface, other AMF entities in other network over Nx interface as per embodiments described herein, etc.). The embodiments described herein can also be executed in virtualized embodiments of the home AMF 102 and of the V-AMF 103. As used herein, a "virtualized" home AMF (H-AMF) 102/V- AMF 103 is an implementation of the H-AMF 102/V-AMF 103 in which at least a portion of the functionality of the H-AMF 102/V-AMF 103 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).

[0075] The one or more processors may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of the network node implementing the H-AMF 102 or the V-AMF 103. In some embodiments, the one or more processors may include, for example, one or more computers, one or more central processing units (CPUs), one or more processors, one or more applications, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic. In certain embodiments, the one or more processors may comprise one or more modules implemented in software. The module(s) provide functionality of the network node implementing the H-AMF 102 or the V-AMF 103 in accordance with the embodiments described herein, and in accordance with the steps executed at the network node implementing the H-AMF 102 or the V- AMF 103 as shown in Figure 4, Figure 5 and Figure 6. In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the H-AMF 102 or the V-AMF 103 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0076] The memory is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by one or more processors. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer- readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the one or more processors of the network node implementing either the H-AMF 102 or the V-AMF 103.

[0077] Figure 8 illustrates another aspect of a network node implementing a home AMF 102 or the newly selected mobility management entity or a V-AMF103 or the previous mobility management entity. The network node comprises a processing module 81 which executes the method steps according to the embodiments as described in Figure 5 for the H-AMF 102 and Figure 6 for the V-AMF 103, along with steps 409b, 410-416, 417-419 for H-AMF 102 and steps 415-416 for the V-AMF 103, in addition to other embodiments described herein. For example, the processing module 81 for the H- AMF 102 receives via the communication module 83 an identity of a previous mobility management entity (V-AMF) to which the user equipment has previously registered over a first access network. The processing module 81 stores in the memory module 82 the received identity and determines whether relocation from the previous mobility management entity (V-AMF) to the newly selected mobility management entity (H-AMF) should be be performed. If the processing module 81 determines relocation to H-AMF should be performed it sends via the communication module 83 a message to the previous mobility management entity indicating the user equipment has attached over the new access network. The memory module 83 maintains the identity of the previous AMF or V-AMF and may maintain other information including network policy, UE capability or UE authorization for simultaneous registration if provided by the processing module 81 and which may be received via the communication module 83.

[0078] Figure 9 is a schematic block diagram illustrating a virtualization environment 1400 in which functions such as implemented by some embodiment(s) may be virtualized. As used herein, virtualization can be applied to a network node implementing a previous/first mobility management/V- AMF (103) and a mobility management entity/newly selected mobility management entity/H-AMF (102) as described herein (may also include the other functions such as AUSF 105, UDM 104 or other functions of the core network) and relates to an implementation in which at least a portion of the functionality is implemented as a virtual component(s) (e.g., via application(s)/component(s)/function(s) or virtual machine(s) executing on a physical processing node(s) in a network(s)).

[0079] In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the hardware node(s) 1430. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), then the network node may be entirely virtualized.

[0080] The functions may be implemented by an application 1420 (which may alternatively be called a software instance, a virtual appliance, a network function, a virtual node, or a virtual network function) operative to implement steps of some method(s) according to some embodiment(s). The application 1420 runs in a virtualization environment 1400 which provides hardware 1430 comprising processing circuitry 1460 and memory 1490. The memory contains instructions 1495 executable by the processing circuitry 1460 whereby the application 1420 is operative to execute the method(s) or steps of the method(s) previously described in relation with some embodiment(s).

[0081] The virtualization environment 1400, comprises a general-purpose or special-purpose network hardware device(s) 1430 comprising a set of one or more processor(s) or processing circuitry 1460, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. The hardware device(s) comprises a memory 1490-1 which may be a transitory memory for storing instructions 1495 or software executed by the processing circuitry 1460. The hardware device(s) comprise network interface controller(s) 1470 (NICs), also known as network interface cards, which include physical Network Interface 1480. The hardware device(s) also includes non-transitory machine-readable storage media 1490-2 having stored therein software 1495 and/or instruction executable by the processing circuitry 1460. Software 1495 may include any type of software including software for instantiating the virtualization layer or hypervisor, software to execute virtual machines 1440 as well as software allowing to execute functions described in relation with some embodiment(s) described previously.

[0082] Virtual machines 1440, implement virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by the virtualization layer or hypervisor 1450. Different embodiments of the instance or virtual appliance 1420 may be implemented on one or more of the virtual machine(s) 1440, and the implementations may be made in different ways.

[0083] During operation, the processing circuitry 1460 executes software 1495 to instantiate the hypervisor or virtualization layer, which may sometimes be referred to as a virtual machine monitor (V120). The hypervisor 1450 may present a virtual operating platform that appears like networking hardware to virtual machine 1440. As shown in the figure 14, hardware 1430 may be a standalone network node, with generic or specific hardware. Hardware 1430 may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 14100, which, among others, oversees lifecycle management of applications 1420.

[0084] Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in Data centers, and customer premise equipment.

[0085] In the context of NFV, a virtual machine 1440 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the virtual machines 1440, and that part of the hardware 1430 that executes that virtual machine, be it hardware dedicated to that virtual machine and/or time slices of hardware temporally shared by that virtual machine with others of the virtual machine(s) 1440, forms a separate virtual network element(s) (VNE). [0086] Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines on top of the hardware networking infrastructure and corresponds to application 1420 in Figure 14.

[0087] In some embodiments, some signaling can be effected with the use of a control system 14230 which may alternatively be used for communication between the hardware node(s) 1430 and between the hardware units 1430 and external unit(s).

[0088] While not being limited thereto, some example embodiments of the present disclosure are provided below. embodiment 1. A method of attaching a user equipment to a newly selected mobility management entity in a network and over a new access network, the method executed at the newly selected mobility management entity comprising: receiving the identity of a previous mobility management entity to which the user equipment has previously registered over a first access network; determining whether relocation from the previous mobility management entity to the newly selected mobility management entity is to be performed; and upon determining the relocation is to be performed, sending a message to the previous mobility management entity indicating the user equipment has attached over the new access network. embodiment 2. The method of embodiment 1, wherein the receiving step further comprises receiving the user equipment authorization to maintain multiple simultaneous registrations over multiple access networks. embodiment 3. The method of embodiments 1 and 2, wherein determining the relocation is to be performed is based on at least one of an authorization to maintain multiple simultaneous registrations over multiple access networks, user equipment capability to support multiple simultaneous registration or network capability to support multiple simultaneous registration. embodiment 4. The method of embodiment 1 , where in the first access network is a cellular radio access network. embodiment 5. The method of embodiment 1 , wherein the new access network is a wireless fidelity, WiFi, access network. embodiment 6. The method of embodiment 1 , wherein the identity of the previous mobility management entity is received from at least one of a unified data management entity or the user equipment. embodiment 7. The method of embodiment 1 , wherein the message further comprises an identity of the network hosting the newly selected mobility management entity. embodiment 8. The method of embodiment 7, where in the identity is a public land mobile network, PLMN, identity. embodiment 9. The method of embodiment 1 , wherein the previous mobility management entity is in a visited network and the newly selected mobility management entity is the user equipment home network. embodiment 10. A method of relocating a previous mobility management entity in a first network to which a user equipment is registered to through a first access network, the method executed at the previous mobility management entity and comprising: receiving from a new mobility management entity in a second network, a request message for relocation indicating the user equipment has attached to the new mobility management entity over a second access network;

determining whether deregistration of the user equipment is to be performed; and

sending a relocation response message indicating result of relocation and deregistration of the user equipment from the first network. embodiment 11. The method of embodiment 10, wherein determining whether deregistration of the user

equipment is to be performed is based on capability of the user equipment to support multiple simultaneous registration. embodiment 12. The method of embodiment 10, wherein the request message for relocation further comprises instruction to deregister the user equipment from the first network. embodiment 13. The method of embodiment 10 or 11, wherein determining whether deregistration of the user equipment is to be performed is based on authorization of the user equipment to maintain multiple simultaneous registration. embodiment 14. The method of embodiments 10, 11 or 13, wherein upon determining deregistration of the user equipment is to be performed further comprises sending a deregistration message to the user equipment over the first access network and indicating to the new mobility management entity that relocation is completed. embodiment 15. The method of embodiment 14, further comprising temporarily maintaining mobility

management context of the user equipment. embodiment 16. The method of embodiments 10, 11 or 13, wherein upon determining deregistration of the user equipment is not to be performed further comprises indicating to the new mobility management entity that registration of the user equipment is to be maintained at the previous mobility management entity. embodiment 17. The method of embodiment 10 wherein the request for relocation message further comprises a network identity of the new mobility management entity. embodiment 18. The method of embodiment 17, where in the network identity is a public land mobile network, PLMN, identity. embodiment 19. The method of embodiment 10, where in the first access network is a cellular radio access network. embodiment 20. The method of embodiment 10, wherein the second access network is wireless fidelity, WiFi, access network. embodiment 21. The method of embodiment 1 , wherein the previous mobility management entity is in a visited network and the new mobility management entity is the user equipment home network. embodiment 22. A Computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 21. embodiment 23. A c6zarrier containing the computer program of claim 22, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. embodiment 24. A network entity (102) implementing a mobility management function adapted to: receive the identity of a previous mobility management entity to which the user equipment has previously registered over a first access network; determine whether relocation from the previous mobility management entity to the newly selected mobility management entity is to be performed; and upon determining the relocation is to be performed, send a message to the previous mobility management entity indicating the user equipment has attached over the new access network. embodiment 25. A network node of embodiment 24 wherein the network node (102) is further adapted to

operate according to the method of any one of embodiments 2-9. embodiment 26. The network entity (102) implementing a mobility management function comprising: at least one processor; and memory comprising instructions executable by the at least one processor whereby the network node (102) is operable to:

receive the identity of a previous mobility management entity to which the user equipment has previously registered over a first access network;

determine whether relocation from the previous mobility management entity to the newly selected mobility management entity is to be performed; and

upon determining the relocation is to be performed, send a message to the previous mobility management entity indicating the user equipment has attached over the new access network. embodiment 27. The network node of embodiment 26 wherein the network node (102) is further adapted to operate according to the method of any one of embodiments 2-9. embodiment 28. A network entity (103) implementing a mobility management function adapted to:

receive from a new mobility management entity in a second network, a request message for relocation indicating the user equipment has attached to the new mobility management entity over a second access network;

determine whether deregistration of the user equipment is to be performed; and

sending a relocation response message indicating result of relocation and deregistration of the user equipment from the first network.

embodiment 29. The network node of embodiment 26 wherein the network node (103) is further adapted to operate according to the method of any one of embodiments 11-21.

Acronyms and definitions:

[0089] The following acronyms and definitions are used throughout this disclosure.

3GPP Third Generation Partnership Project

5G Fifth Generation

AMF Access and Mobility Function

AUSF Authentication server function

CPU Central Processing Unit

CN Core Network

CP Control plane

EAP Extended Authentication Protocol

eNB Enhanced or Evolved Node B

ESP Encapsulating Security Payload EUTRAN Evolved Universal Terrestrial Radio Access Network

FPGA Field Programmable Gate Array

gNB next generation NodeB

IKEv2 Internet Key Exchange Protocol version 2

IPSec Internet Protocol Security

NG Next Generation

ngPDG Next Generation Packet Data gateway

NR New Radio

5GCN Fifth Generation Core network

RAN Radio Access Network

RAT Radio Access Technology

SA Security Association

UE User Equipment

UP User Plane

USB Universal Serial Bus

UDM Unified Data Management

WiFi Wireless Fidelity

WLAN Wireless Local Area Network 0] Modifications and other embodiments will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that modifications and other embodiments, such as specific forms other than those of the embodiments described above, are intended to be included within the scope of this disclosure. The described embodiments are merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than the preceding description, and all variations and equivalents that fall within the range of the claims are intended to be embraced therein. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.