CN114175770B - Method for registration by reassignment of access and mobility management functions - Google Patents

Abstract

A system and method terminates a Listen Before Talk (LBT) attempt after it is submitted to the physical layer of a system interconnect model if one or more of any pending LBT attempts are successful. The system and method comprise: a first registration request is received by an initial access and mobility management function (AMF) from a wireless communication device via a Radio Access Network (RAN), the first registration request including a first device identification associated with the wireless communication device. The system and method comprise: a second device identification associated with the wireless communication device is assigned by the initial AMF in response to receiving the registration request. The system and method comprise: a second registration request including a second device identification is generated by the initial AMF.

Description

Method for registration by reassignment of access and mobility management functions

Technical Field

The present disclosure relates generally to wireless communications, and more particularly to a system and method for registration with access and mobility management function reassignment.

Background

The standardization organization third generation partnership project (3 GPP) is currently in the process of specifying a new radio interface called 5G new radio (5G NR) and a next generation packet core network (NG-CN or NGC). The 5G NR will have three main components: a 5G access network (5G-AN), a 5G core network (5 GC) and User Equipment (UE). In order to facilitate the enablement of different data services and requirements, the elements of 5GC (also referred to as network functions) have been simplified, most of which are software-based so that these elements can be adapted as needed.

Disclosure of Invention

The exemplary embodiments disclosed herein are directed to solving problems associated with one or more problems existing in the prior art, and to providing additional features that will become apparent when reference is made to the following detailed description in conjunction with the accompanying drawings. According to various embodiments, example systems, methods, apparatus, and computer program products are disclosed herein. However, it should be understood that these embodiments are presented by way of example, not limitation, and that various modifications of the disclosed embodiments may be made while remaining within the scope of the disclosure, as would be apparent to one of ordinary skill in the art from reading the disclosure.

In one embodiment, a method includes: a first registration request is received by an initial access and mobility management function (AMF) from a wireless communication device via a Radio Access Network (RAN), wherein the first registration request includes a first device identification associated with the wireless communication device. In some embodiments, the method comprises: a second device identification associated with the wireless communication device is assigned by the initial AMF in response to receiving the registration request. In some embodiments, the method comprises: a second registration request including the second device identification is generated by the initial AMF.

In another embodiment, a method includes: a protected registration request is received by a target access and mobility management function (AMF) from an initial AMF via a Radio Access Network (RAN), wherein the protected registration request includes a second device identification, the protected registration request generated by the initial AMF in response to receiving a registration request including a first device identification associated with a wireless communication device and integrity protection by the initial AMF using a security context. In some embodiments, the method comprises: the security context is obtained from the initial AMF by the target AMF in response to receiving the protected registration request. In some embodiments, the method comprises: the wireless communication device is registered with the target AMF using the security context by the target AMF.

The above and other aspects and embodiments thereof are described in more detail in the accompanying drawings, description and claims.

Drawings

Various exemplary embodiments of the present technology are described in detail below with reference to the accompanying drawings. The drawings are provided for illustrative purposes only and depict only example embodiments of the present technology to facilitate the reader's understanding of the present technology. Accordingly, the drawings should not be taken to limit the breadth, scope, or applicability of the present disclosure. It should be noted that for clarity and ease of illustration, the drawings are not necessarily made to scale.

Fig. 1 illustrates an example cellular communication network in which the techniques disclosed herein may be implemented, according to an embodiment of the disclosure;

fig. 2 illustrates a block diagram of an example base station and user equipment device, according to some embodiments of the present disclosure;

FIG. 3 illustrates a block diagram of an exemplary architecture of a 5G system, according to some embodiments of the present disclosure;

FIG. 4 illustrates a flow chart of an example environment of a 5G system with AMF reassignment in accordance with some embodiments of the present disclosure;

fig. 5 illustrates a flow chart of a method of registration with access and mobility management function reassignment from the perspective of an initial AMF in accordance with some embodiments of the present disclosure; and

fig. 6 illustrates a flow chart of a method of registration with access and mobility management function reassignment from the perspective of a target AMF in accordance with some embodiments of the present disclosure.

Detailed Description

Various example embodiments of the present technology are described below with reference to the accompanying drawings to enable one of ordinary skill in the art to make and use the technology. As will be apparent to those of ordinary skill in the art upon reading this disclosure, various changes or modifications may be made to the examples described herein without departing from the scope of the present technology. Thus, the present technology is not limited to the example embodiments and applications described and illustrated herein. Additionally, the particular order or hierarchy of steps in the methods disclosed herein is only an example approach. Based on design preferences, the specific order or hierarchy of steps in the methods or processes disclosed may be rearranged while remaining within the scope of the present disclosure. Accordingly, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in an example order, and that the present technical solution is not limited to the particular order or hierarchy presented, unless specifically stated otherwise.

The following acronyms are used throughout this disclosure:

3GPP: third generation partnership project

5G: 5 th generation mobile network

5G-AN:5G access network

5G gNB: next generation NodeB

5G-GUTI: 5G-globally unique temporary UE identity

AF: application function

AMF: access and mobility management functions

AN: access network

ANDSF: access network discovery and selection functions

AUSF: authentication server function

CM: connection mode

DL: descending downwards

DNN: data network name

DRX: discontinuous reception

ETSI: european telecommunications standards institute

H-PCF: home policy control function

HPLMN: home public land mobile network

GUAMI: globally unique AMF identification

LADN: local area data network

MICO mode preferred: mode preference for mobile originated-only connections

MPS: multimedia priority service

MCS: modulation and coding scheme

N3IWF: non-3 GPP interworking function

NAS: non-access stratum

NF: network function

NG-RAN next generation radio access network

NGAP: NG application protocol

NR: next generation RAN

NSSAI: network slice selection assistance information

NSSF: network slice selection function

OFDM: orthogonal frequency division multiplexing

OFDMA: orthogonal frequency division multiple access

PLMN: public land mobile network

PSI: public service identity

PCF: policy control function

PDU: packet data unit

PEI: permanent device identification

RAN: radio access network

RAN CP: radio access network control plane

RAT: wireless access technology

S-NSSAI: single network slice selection assistance information

SM NAS: session management non-access stratum

SMF: session management function

SUCI: subscription hidden identification

SUPI: subscription permanent identification

TAI: tracking area identification

UDM: unified data management

UDSF: unstructured data storage functionality

UDR: unified data storage

UE: user equipment

UE MM: user equipment mobility management

UE-TNLA: user equipment transport network layer association

UPF: user plane functionality

V-PCF: access policy control function

Clauses 4.2.2.2.2 and 4.2.2.2.3 in ETSI123.502 (which are incorporated herein by reference in their entirety) define a process for registration with AMF reassignment. However, this registration procedure has security drawbacks that may lead to registration failure of the UE. That is, in an idle mobility registration procedure using AMF reassignment, registration may fail when (1) an initial AMF and a UE have established a new NAS security context that is different from an old NAS security context established between the old AMF and the UE, and (2) a target AMF acquires the old NAS security context of the UE from the old AMF and the target AMF has decided to use it. In this case, the NAS security context (including K used by the UE _AMF (e.g., mobility management key)) and the target AMF use (e.g., no match). Thus, the integrity check of the NAS message will fail, which in turn results in registration failure.

Accordingly, the systems and methods discussed herein modify a registration request received by an AMF (e.g., an initial AMF) from a UE to ensure that the UE communicates a registration procedure during a handover to another AMF (e.g., a target AMF). In general, and as discussed in more detail below, when a UE (e.g., UE402 in fig. 4) sends a registration request (also referred to herein as Registration Request or RR message) including a device identification (also referred to herein as UE ID) to an initial AMF (e.g., initial AMF406 in fig. 4), the UE and the initial AMF establish a security association. In response to receiving a registration request from the UE, the initial AMF assigns (e.g., generates, retains, etc.) a new device identification (e.g., 5G-GUTI) and uses the new device identification instead of the UE ID contained in the registration request message. The initial AMF invokes (e.g., operates, performs, etc.) the integrity protection of the registration request using the 5G NAS security context and sends a message to the target AMF (e.g., target AMF410 in fig. 4) that includes (or pairs with) the registration request. In response to receiving the message, the target AMF obtains the security context from the initial AMF by sending a context transfer request to the initial AMF. The context transfer request causes the initial AMF to verify integrity protection of the protected registration request and/or to send a UE context including the UE security context to the target AMF. The target AMF then completes the remaining steps of the registration process.

Mobile communication technology and environment

Fig. 1 illustrates an example wireless communication network and/or system 100 that can implement the techniques disclosed herein, in accordance with embodiments of the present disclosure. In the following discussion, the wireless communication network 100 may be any wireless network, such as a cellular network or a narrowband internet of things (NB-IoT) network, and is referred to herein as "network 100". Such an example network 100 includes base stations 102 (hereinafter referred to as "BSs 102"; also referred to as wireless communication nodes) and user equipment devices 104 (hereinafter referred to as "UEs 104"; also referred to as wireless communication devices) capable of communicating with each other via communication links 110 (e.g., wireless communication channels), and cell clusters 126, 130, 132, 134, 136, 138, and 140 that cover a geographic area 101. In fig. 1, BS102 and UE104 are contained within respective geographic boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station operating under its allocated bandwidth to provide adequate wireless coverage to its intended users.

For example, BS102 may operate under the allocated channel transmission bandwidth to provide adequate coverage to UE 104. BS102 and UE104 may communicate via downlink radio frame 118 and uplink radio frame 124, respectively. Each radio frame 118/124 may be further divided into subframes 120/127, and the subframes 120/127 may include data symbols 122/128. In this disclosure, BS102 and UE104 are described herein as non-limiting examples of "communication nodes," which may generally practice the methods disclosed herein. According to various embodiments of the present technology, such communication nodes are capable of wireless and/or wired communication.

Fig. 2 illustrates a block diagram of an exemplary wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM/OFDMA signals) in accordance with some embodiments of the present technique. The system 200 may include components and elements configured to support known or conventional operational features that do not need to be described in detail herein. In one illustrative embodiment, system 200 may be used to transmit (e.g., send and receive) data symbols in a wireless communication environment (e.g., wireless communication environment 100 of fig. 1), as described above.

The system 200 generally includes a base station 202 (hereinafter "BS 202") and a user equipment device 204 (hereinafter "UE 204"). BS202 includes BS (base station) transceiver module 210, BS antenna 212, BS processor module 214, BS memory module 216, and network communication module 218, each of which are coupled and interconnected to each other as needed via data communication bus 220. The UE204 includes a UE (user equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each coupled and interconnected with each other as needed via a data communication bus 240. BS202 communicates with UE204 via communication channel 250, which communication channel 250 may be any wireless channel or other medium suitable for data transmission as described herein.

As will be appreciated by those of skill in the art, the system 200 may further include any number of modules in addition to the modules shown in fig. 2. Those of skill in the art will appreciate that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein may be implemented as hardware, computer readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software may depend on the particular application and design constraints imposed on the overall system. Those familiar with the concepts described herein may implement these functionalities in a suitable manner for each particular application, but such implementation decisions should not be interpreted as limiting the scope of the present disclosure.

According to some embodiments, UE transceiver 230 may be referred to herein as an "uplink" transceiver 230 that includes a Radio Frequency (RF) transmitter and an RF receiver, each including circuitry coupled to an antenna 232. A duplex switch (not shown) may alternately couple an uplink transmitter or receiver to an uplink antenna in a time duplex manner. Similarly, BS transceiver 210 may be referred to herein as a "downstream" transceiver 210, according to some embodiments, that includes an RF transmitter and an RF receiver, each including circuitry coupled to antenna 212. The downlink duplex switch may alternately couple a downlink transmitter or receiver to the downlink antenna 212 in a time duplex manner. The operation of the two transceiver modules 210 and 230 may be coordinated in time such that the uplink receiver circuitry is coupled to the uplink antenna 232 for receiving transmissions over the wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operation of the two transceivers 210 and 230 may be coordinated in time such that the downstream receiver is coupled to the downstream antenna 212 for receiving transmissions over the wireless transmission link 250 while the upstream transmitter is coupled to the upstream antenna 232. In some embodiments, there is near time synchronization with minimal guard time between changes in duplex direction.

The UE transceiver 230 and the base station transceiver 210 are configured to communicate via a wireless data communication link 250 and cooperate with a suitably configured RF antenna arrangement 212/232 that may support a particular wireless communication protocol and modulation scheme. In some demonstrative embodiments, UE transceiver 210 and base station transceiver 210 are configured to support industry standards, such as Long Term Evolution (LTE) and the emerging 5G standard. However, it should be understood that the present disclosure is not necessarily limited in application to a particular standard and associated protocol. Rather, the UE transceiver 230 and the base station transceiver 210 may be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

According to various embodiments, BS202 may be, for example, an evolved node B (eNB), a serving eNB, a target eNB, a femto (femto) station, or a pico (pico) station. In some embodiments, the UE204 may be embodied in various types of user equipment, such as mobile phones, smart phones, personal Digital Assistants (PDAs), tablet computers, laptop computers, wearable computing devices, and the like. The processor modules 214 and 236 may be implemented or performed with general purpose processors, content addressable memory, digital signal processors, application specific integrated circuits, field programmable gate arrays, any suitable programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In this manner, a processor may be implemented as a microprocessor, controller, microcontroller, state machine, or the like. A processor may also be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

Furthermore, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in firmware, in a software module executed by the processor modules 214 and 236, respectively, or in any practical combination thereof. Memory modules 216 and 234 may be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 may be coupled to processor modules 210 and 230, respectively, such that processor modules 210 and 230 may read information from memory modules 216 and 234 and write information to memory modules 216 and 234, respectively. The memory modules 216 and 234 may also be integrated into their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during execution of instructions by processor modules 210 and 230. Memory modules 216 and 234 may also each include non-volatile memory for storing instructions to be executed by processor modules 210 and 230.

Network communication module 218 generally represents the hardware, software, firmware, processing logic, and/or other components of base station 202 that enable bi-directional communication between base station transceiver 210 and other network components and communication nodes configured to communicate with base station 202. For example, the network communication module 218 may be configured to support internet or WiMAX services. In a typical deployment, but not limited to, the network communication module 218 provides an 802.3 ethernet interface so that the base transceiver station 210 can communicate with a conventional ethernet-based computer network. In this manner, the network communication module 218 may include a physical interface for connecting to a computer network, such as a Mobile Switching Center (MSC). As used herein with respect to a specified operation or function, the terms "configured to," "configured to," and combinations thereof are physically constructed, programmed, formatted and/or arranged to perform the specified operation or function with respect to a device, component, circuit, structure, machine, signal, etc.

The Open Systems Interconnection (OSI) model (referred to herein as the "open systems interconnection model") defines the concept and logical layout of network communications used by systems (e.g., wireless communication devices, wireless communication nodes) that are open to interconnect and communicate with other systems. The model is divided into seven sub-components or layers, each of which represents a collection of concepts that are provided to the services above and below it. The OSI model also defines a logical network and effectively describes computer packet transport through the use of different layer protocols. The OSI model may also be referred to as a seven layer OSI model or a seven layer model. In some embodiments, the first layer may be a physical layer. In some embodiments, the second layer may be a Medium Access Control (MAC) layer. In some embodiments, the third layer may be a Radio Link Control (RLC) layer. In some embodiments, the fourth layer may be a Packet Data Convergence Protocol (PDCP) layer. In some embodiments, the fifth layer may be a Radio Resource Control (RRC) layer. In some embodiments, the sixth layer may be a non-access stratum (NAS) layer or an Internet Protocol (IP) layer, and the seventh layer is the other layer.

Access and mobility management function (AMF) reassignment

Fig. 3 illustrates a block diagram of an exemplary architecture of a 5G system, according to some embodiments of the present disclosure. The 5G system 300 includes various components, such as a UE302 (e.g., UE104 in fig. 1), a 5G-AN304, AN AMF306, a UDM308, a PCF310, AN SMF312, AN AF314, a UPF318, and a data network 316. The AMF306 includes one or more functions such as UE mobility management, reachability management, connection management. Although only one component of each type is shown, as described herein, environment 300 may include any number of components (e.g., multiple UEs 302, multiple 5G-ANs 304, multiple AMFs 306, etc.) interconnected in any arrangement to facilitate operation of the 5G system.

The AMF306 terminates the RAN CP interface (depicted as N2 in fig. 3) and NAS (depicted as N1 in fig. 3), NAS ciphering, and integrity protection. The AMF306 distributes the SM NAS to the appropriate SMF312 via the N11 interface. The SMF312 includes UE IP address allocation and management, UPF318 selection and control, and PDU connection management.

The UPF318 is an anchor point for intra-RAT mobility or inter-RAT mobility and an external PDU session point interconnected to the data network 316. The UPF318 also routes and forwards packets as indicated from the SMF312. The UPF318 also buffers DL data while the UE302 is in idle mode. The UDM308 stores subscription profiles for the UEs 302.

PCF310 generates policies to manage network behavior based on subscriptions and indications from AF 314. PCF310 also provides policy rules to control the surface functions (e.g., AMF306 and SMF 312) to manage.

Fig. 4 illustrates a flow chart of an example environment of a 5G system with AMF reassignment, according to some embodiments of the present disclosure. The example environment 400 includes a UE402, a RAN404 (also referred to herein as (R) AN), AN initial AMF406, AN old AMF408, and a target AMF410. In some embodiments, the UE402 may be the UE104 in fig. 1. In some embodiments, any of the initial AMF406, the old AMF408, and the target AMF410 may be the AMF306 of FIG. 3, or any other AMF (not shown in FIG. 3) that includes some or all of the functionality of the AMF 306.

In step 1 (labeled as registration request in fig. 4), the UE402 sends (e.g., transmits, delivers) AN message to the RAN404 (e.g., 5G nb or BS102 in fig. 1). In some embodiments, the AN message may include AN parameter, a registration request (also referred to herein as AN RR message), and/or a UE policy container. In some embodiments, the registration request may include a registration type sui or 5G-GUTI (e.g., device identification associated with UE 402) or PEI, last accessed TAI (if available), security parameters, requested nsai, [ mapping of requested nsai ], default configured nsai indication, UE wireless capability update, UE MM core network capability, PDU session state, PDU session list to be activated, subsequent request, MICO mode preference, requested DRX parameters, [ LADN DNN(s) or indicator of requested LADN information ], and/or [ NAS message container ]. In some embodiments, a PSI list and/or an indication that the UE supports ANDSP and operating system identification may be included.

In some embodiments, the UE policy container and its use are defined by 3gpp TS 23.503.

For the NG-RAN, the AN parameters may include a 5G-S-TMSI or GUAMI, a selected PLMN ID and a requested nsai, the AN parameters also including the establishment cause. The establishment cause provides a cause for requesting establishment of the RRC connection. Whether and how the UE includes the requested nsai as part of the AN parameters depends on the value of the access stratum connection establishment nsai inclusion mode parameters, as specified in clause 5.15.9 of 3gpp TS 23.501, the entire contents of which are incorporated herein by reference.

Registration type indication: whether the UE402 wishes to perform an initial registration (i.e., the UE402 is in RM-REGISTERED state), a mobility registration update (i.e., the UE402 is in RM-REGISTERED state and either because mobility requires updating its capabilities or protocol parameters or requesting a change to the set of network slices it is allowed to use), a periodic registration update (i.e., the UE402 is in RM-REGISTERED state and initiates a registration procedure due to expiration of a periodic registration update timer, see clause 4.2.2.2.1 of 3gpp TS 23.502, the entire contents of which are incorporated herein by reference), or an emergency registration (i.e., the UE402 is in limited service state).

When the UE402 is performing initial registration, the UE402 indicates its UE identity in the registration request message as follows, listed in descending order of preference:

a) If available, the assigned native 5G-GUTI, through which the UE402 attempts to register;

b) A native 5G-GUTI assigned by the equivalent PLMN to the PLMN the UE is attempting to register, if available; and

c) If available, the native 5G-GUTI assigned by any other PLMN.

In some embodiments, this may be a 5G-GUTI assigned via another access type. In some embodiments, UE402 may include its sui in the registration request, as defined in 3gpp TS 33.501, the entire contents of which are incorporated herein by reference.

If the UE402 is sending a registration request message as the initial NAS message, the UE402 has a valid 5G NAS security context and the UE402 needs to send a non-clear text IE, then a NAS message container may be included, see clause 4.4.6 in 3gpp TS 24.501. If the UE does not need to send a non-clear text IE, the UE402 may send a registration request message without including a NAS message container.

If the UE402 does not have a valid 5G NAS security context, the UE402 may send a registration request message without including a NAS message container. In step 9b in fig. 4, the UE402 may include the entire registration request message (i.e., containing the plain text IE and the non-plain text IE) in a NAS message container that will be sent as part of the security mode complete message.

When the UE402 performs initial registration with a native 5G-GUTI (i.e., the UE402 is in RM-registered state), the UE402 may indicate the relevant GUAMI information in AN parameter. When the UE402 performs initial registration with its sui, the UE402 may not indicate any GUAMI information in the AN parameters.

For emergency registration, if the UE402 does not have a valid 5G-GUTI available, a sui may be included; PEI may be included when the UE402 has no SUPI and no valid 5G-GUTI. In some embodiments, a 5G-GUTI is included, and indicates the last service AMF.

The UE402 may provide usage settings for the UE402 based on its configuration as defined in clause 5.16.3.7 of 3gpp TS 23.501, the entire contents of which clause 5.16.3.7 are incorporated herein by reference. The UE402 provides the requested nsais as described in clause 5.15.5.2.1 of 3gpp TS 23.501 and in the case of initial registration or mobility registration update, the UE402 includes a mapping of the requested nsais (if available) that is a mapping of each S-nsai of the requested nsais to multiple HPLMN S-nsais to ensure that the network is able to verify whether one or more of the requested nsais are allowed based on the subscribed multiple S-nsais.

If the UE402 uses a default configured nsai as defined in 3gpp TS 23.501, the UE402 includes a default configured nsai indication.

In case of a mobility registration update, the UE402 includes in the list of PDU sessions to be activated a PDU session for which there is pending uplink data. When the UE402 includes a list of PDU sessions to be activated, the UE402 indicates PDU sessions associated with only the access to which the registration request relates. As defined in 3gpp TS 24.501, the UE402 may include always-on PDU sessions that are accepted by the network in the list of PDU sessions to be activated, even though there is no pending uplink data for those PDU sessions.

In some embodiments, when the UE402 is outside of the LADN availability region, the PDU session corresponding to the LADN is not included in the PDU session list to be activated.

UE MM core network capabilities are provided by UE402 and handled by AMF as defined in TS 23.501[2] clause 5.4.4a. The UE402 includes in the UE MM core network capability an indication of whether it supports a request type flag "handover" for PDN connectivity requests during the attach procedure as defined in clause 5.17.2.3.1 of 3gpp TS 23.501.

The UE402 may provide one or more LADNs or an indication of a request for LADN information as described in 3gpp TS 23.501 clause 5.6.5.

The last accessed TAI, if available, may be included to assist the AMF in generating the registration area for the UE 402.

The security parameters are used for authentication and integrity protection, see TS 33.501[15]. The requested nsai indicates network slice selection assistance information (as defined in clause 5.15 of 3gpp TS 23.501). The PDU session state indicates a PDU session previously established in the UE 402. When the UE402 connects to two AMFs belonging to different PLMNs via a 3GPP access and a non-3 GPP access, the PDU session state indicates an established PDU session for the current PLMN in the UE 402.

When the UE402 has pending uplink signaling and the UE does not include a list of PDU sessions to be activated or the registration type indicates that the UE402 wants to perform emergency registration, a subsequent (Follow-on) request is included. In the initial registration and mobility registration update, the UE402 provides the DRX parameters requested by the UE, as defined in clause 5.4.5 of 3gpp TS 23.501.

UE402 provides a UE radio capability update indication as described in 3gpp TS 23.501.

In step 2 (labeled AMF selection in FIG. 4), if either 5G-S-TMSI or GUAMI is not included, or does not indicate a valid AMF, the RAN404 selects an AMF based on the (R) AT and the requested NSSAI (if available).

RAN404 selects an AMF as in 3gpp TS 23.501 clause 6.3.5. If the UE402 is in the CM-CONNECTED state, the RAN404 may forward the registration request message to the AMF based on the N2 connection of the UE 402.

If the RAN404 cannot select the appropriate AMF, it forwards the registration request to the AMF that has been configured in the RAN404 to perform the AMF selection.

In step 3 (labeled as registration request in fig. 4), the RAN404 sends (i.e., transmits, delivers) an N2 message and a UE policy container to the initial AMF406. In some embodiments, the N2 message includes an N2 parameter and/or a registration request (as described in step 1 in fig. 4).

When NG-RAN is used, the N2 parameters include the selected PLMN ID, location information and cell identity related to the cell in which the UE402 is camping, a UE context request indicating that security information needs to be set at the NG-RAN.

The N2 parameter also includes the establishment cause when using the NG-RAN.

The requested NSSAI mapping is provided only if available.

Steps 4 to 19 may be omitted if the registration type indicated by the UE402 is a periodic registration update.

When the establishment cause is associated with a priority service (e.g., MPS, MCS), the AMF includes a message priority header to indicate priority information. Other NFs relay priority information by including a message priority header in the service-based interface, as specified in 3gpp ts29.500, the entire contents of which are incorporated herein by reference.

In step 4 (labeled Namf Communication ueContexttransfer in FIG. 4), the initial AMF406 sends Namf Communication ueContexttransfer to the old AMF408 (complete registration request), and/or the initial AMF406 sends Nudsf Unstructured Data Management _Query () to the UDSF (not shown in FIG. 4).

In the case of a deployed UDSF, if the 5G-GUTI of the UE402 is included in the registration request and the serving AMF has changed since the last registration procedure, then the initial AMF406 and the old AMF408 are in the same set of AMFs and the UDSF is deployed, the initial AMF406 retrieves the stored SUPI and UE context of the UE402 directly from the UDSF using nudsf_construction data management_query service operations, or if no UDSF is deployed, they may share the stored UE context via implementation specific means. This also includes event subscription information for each NF consumer for a given UE. In this case, the initial AMF406 performs and verifies the integrity protection using the integrity-protected full registration request NAS message.

Without UDSF deployment, if a 5G-GUTI of UE402 is included in the registration request and the serving AMF has changed since the last registration procedure, initial AMF406 may invoke Namf Communication UEContextTransfer service operation on old AMF408 to request SUPI and UE context of the UE, where old AMF408 includes a full registration request NAS message (which may be integrity protected) and an access type, see clause 5.2.2.2.2 of 3gpp TS 23.502 for details of this service operation. In this case, the old AMF408 uses the 5G-GUTI and the integrity-protected full registration request NAS message, or uses the SUPI and an indication that the UE402 was authenticated from the initial AMF406, to verify integrity protection when the context transfer service operation call corresponds to the requested UE. The old AMF408 also passes to the initial AMF406 per NF consumer event subscription information for the UE 402.

If the old AMF408 has a PDU session for another access type (e.g., different than the access type indicated in this step), and if the old AMF408 determines that there is no possibility to relocate the N2 interface to the initial AMF406, the old AMF408 returns the SUPI of the UE and indicates that the registration request has been verified for integrity protection, but does not include the rest of the UE context.

In some embodiments, in the event that the initial AMF406 performed successful UE authentication after the previous integrity check in the old AMF408 failed, the initial AMF406 sets an indication that the UE402 was verified, according to step 9a in fig. 4.

In some embodiments, after the UE402 successfully registers with the initial AMF406, the NF consumer does not need to subscribe to the initial AMF406 again for events.

Steps 4, 5 and 10 in fig. 4 may be skipped if the initial AMF406 has received the UE context from the old AMF408 during the handover procedure.

For emergency registration, steps 4 and 5 in fig. 4 may be skipped if the UE402 identifies itself with a 5G-GUTI that the AMF does not know, and the AMF immediately requests SUPI from the UE 402. The SUPI request may be skipped if the UE402 identifies itself with PEI. Allowing emergency registration without user identity may depend on local regulations.

In step 5 (labeled Namf Communication ueContexttransfer response in FIG. 4), the old AMF408 sends a response to the Namf Communication ueContexttransfer to the initial AMF406 and/or the UDSF (not shown in FIG. 4) sends a Nudsf Unstructured Data Management _Query () to the initial AMF 406. In some embodiments, the Namf Communication uecontext transfer may include SUPI and/or UE context in AMF (per table 5.2.2.2.2-1 of 3gpp TS 23.502). The old AMF408 may start a dedicated (guard) timer for the UE context.

If a UDSF is queried in step 4 of fig. 4, the UDSF responds to the nudsf_ Unstructured Data Management _query call of the initial AMF406 by including the related context of the established PDU session, the old AMF408 includes SMF information DNN, S-nsai (S) and PDU session ID, active NGAP UE-TNLA bound to N3IWF, the old AMF includes information about NGAP UE-TNLA binding. If the old AMF408 is queried in step 4 of FIG. 4, the old AMF408 responds to the Namf_communication_UEContextTransferCall of the initial AMF406 by including the SUPI of the UE and the UE context.

If the old AMF408 maintains information about the established one or more PDU sessions, the old AMF408 includes SMF information, one or more DNNs, one or more S-NSSAIs, and one or more PDU session IDs.

If the old AMF408 maintains the UE context established through the N3IWF, the old AMF408 includes the CM state of the UE402 connected through the N3 IWF. If the UE402 is in CM connected state through the N3IWF, the old AMF408 includes information about the NGAP UE-TNLA binding.

If the old AMF408 fails the integrity check on the registration request NAS message, the old AMF408 may indicate that the integrity check failed.

If the old AMF408 maintains information about AM policy associations and information about UE policy associations (i.e., policy control request triggers for updating UE policies as defined in 3GPP TS 23.503, which is incorporated herein by reference in its entirety), the old AMF408 includes information about AM policy associations, UE policy associations, and PCF IDs. In the roaming case, a V-PCF ID and an H-PCF ID are included.

In some embodiments, interactions between the old AMF408, the initial AMF406, and the UDSF are implementation issues when the initial AMF406 uses the UDSF for context retrieval due to simultaneous UE signaling on the old AMF 408.

At step 6 (labeled identity request/response in fig. 4), the initial AMF406 sends an identity request () to the UE 402. If the UE402 does not provide the SUCI, nor does the SUCI retrieve from the old AMF408, an identity request procedure is initiated by the AMF sending an identity request message to the UE402 requesting the SUCI.

In step 7 (not shown in fig. 4), the UE402 sends an identity response () to the initial AMF 406. In some embodiments, the UE402 responds with an identity response message that includes a sui. The UE402 derives (e.g., computes, generates) the sui by using the specified public key of the HPLMN, as specified in 3gpp TS 33.501.

At step 8 (labeled AUSF selection in fig. 4), the initial AMF406 may decide to initiate UE authentication by invoking AUSF412. In this case, the AMF selects the AUSF412 based on SUPI or sui as described in 3gpp TS 23.501 clause 6.3.4.

If the initial AMF406 is configured to support emergency registration for unauthenticated SUPI and the UE402 indicates a registration type emergency registration, the initial AMF406 skips authentication, or the initial AMF406 accepts authentication may fail and continues the registration process.

In step 9 (labeled authentication/security in fig. 4), if authentication is required, the initial AMF406 requests the authentication from the AUSF 412; if tracking requirements are available at the initial AMF406 for the UE402, the initial AMF406 sets the tracking requirements in its request to the AUSF412. Upon receiving a request from the initial AMF406, the AUSF412 may perform authentication of the UE 402. Authentication is performed as described in 3gpp TS 33.501. The AUSF412 selects a UDM (e.g., UDM 418) as described in 3gpp TS 23.501, clause 6.3.8, and obtains (e.g., retrieves, queries) authentication data from the UDM (e.g., UDM 418).

Once the UE402 has been authenticated, the AUSF412 provides the initial AMF406 with relevant security related information. In the case where the initial AMF406 provides sui to the AUSF412, the AUSF412 may return sui to the initial AMF406 only after authentication is successful.

After successful authentication in the initial AMF406 (which is triggered by the integrity check failure in the old AMF408 at step 5 in fig. 4), the initial AMF406 again invokes step 4 in fig. 4 and indicates that the UE402 is verified (i.e. by the cause parameters specified in clause 5.2.2.2.2 of 3gpp TS 23.502).

In step 9b, if the NAS security context does not exist, NAS security initiation is performed as described in 3gpp TS 33.501. If the UE402 does not have a NAS security context as in step 1 in fig. 4, the UE402 comprises a full registration request message as defined in 3gpp TS 24.501.

In step 9c, if the 5G-AN has requested a UE context, the initial AMF406 initiates AN NGAP procedure to provide the 5G-AN with a security context as specified in 3gpp ts38.413, which is incorporated herein by reference in its entirety. Furthermore, if the AMF does not support N26 for EPS interworking and it receives UE MM core network capabilities including AN indication of a request type flag "handover" supporting PDN connection requests during the attach procedure as defined in clause 5.17.2.3.1 of 3gpp TS 23.501, the initial AMF406 provides AN indication of "redirection of possible voice EPS fallback" as specified in 3gpp TS38.413 to the 5G-AN. Furthermore, if tracking requirements are available at the initial AMF406 for the UE402, the initial AMF406 provides the 5G-AN with tracking requirements in the NGAP procedure.

In step 9d, the 5G-AN stores the security context and acknowledges to the initial AMF 406. The 5G-AN uses the security context to protect messages exchanged with the UE402, as described in 3gpp TS 33.501.

At step 10 (labeled security mode command/complete in fig. 4), the initial AMF406 sends a NAS Security Mode Command (SMC) to the UE 402. The UE402 replies with a NAS security mode complete message containing a complete registration request message as specified in clause 6.4.6 of 3gpp TS 33.501.

In step 11 (labeled UDM selection in fig. 4), if the initial AMF406 needs subscription information of the UE to decide whether to reroute the registration request and the old AMF408 does not provide slice selection subscription information of the UE, the AMF selects UDM (e.g., UDM 418) as in clause 6.3.8 of 3gpp TS 23.501.

In step 12 (labeled nudm_sdm_get/Response in fig. 4), the initial AMF406 may initiate the nudm_sdm_get procedure with UDM 418.

In some embodiments, the initial AMF406 sends Nudm_SDM_get to the UDM 418. In some embodiments, nudm_sdm_get may include SUPI and/or slice selection subscription data. The initial AMF406 requests slice selection subscription data for the UE from the UDM418 by invoking nudm_sdm_get (see clause 5.2.3.3.1 of 3gpp TS 23.502) service operations. The UDM418 may obtain this information from the UDR by nudr_dm_query. In some embodiments, nudr_DM_Query may include SUPI and/or subscribed S-NSSAI.

In some embodiments, UDM418 may send a response to nudm_sdm_get to initial AMF406. The AMF obtains slice selection subscription data including subscribed S-NSSAI. UDM418 may provide an indication for UE402 to update subscription data for network slices.

In some embodiments, the UDM418 responds to the initial AMF406 with slice selection data.

In step 13 (labeled nssf_nsselection_get/Response in fig. 4), the initial AMF406 may initiate the nssf_nsselection_get procedure with Nssf 414.

In some embodiments, the initial AMF406 may send nnssf_nsselect_get to NSSF 414. The nnssf_nsselect_get may include the requested nsai, [ mapping of the requested nsai ], one or more subscriptions S-nsai with default S-nsai indication, TAI, allowed nsai for other access types (if any), the [ mapping of allowed nsai ], and/or PLMN ID of SUPI.

In some embodiments, if slice selection is required (see clause 5.15.5.2.1 of 3gpp TS 23.501), e.g., the initial AMF406 cannot service all S-nsais from the requested nsais allowed by subscription information, the initial AMF406 invokes the nnssf_nsselect_get service operation from the NSSF414 by including the requested nsais, optionally a mapping of the requested nsais, the subscribed S-nsais with default S-nsais indication, allowed nsais for other access types (if any), a mapping of allowed nsais, PLMN IDs of SUPI, and TAI of the UE 402.

In some embodiments, NSSF414 sends a response to Nnssf_NSSelect_get to initial AMF406 a. The nnssf_nsselect_get includes a set or list of AMF addresses, a permitted nsai for the first access type, [ a mapping of permitted nsais ], [ a permitted nsai for the second access type ], [ a mapping of permitted nsais ], [ one or more NSI IDs ], [ one or more NRFs ], [ a list of rejected (S-nsais, cause value (S) values ], [ a configured nsai for the serving PLMN ], and/or [ a mapping of configured nsais ]).

In some embodiments, NSSF414 performs the steps specified in point (B) in clause 5.15.5.2.1 of 3gpp TS 23.501. NSSF414 returns the allowed nsai of the first access type, the mapping of the optional allowed nsai, the allowed nsai of the second access type (if any), the mapping of the optional allowed nsai and the target AMF set, or the list of candidate AMFs based on the configuration to initial AMF406.NSSF414 may return one or more NSI IDs associated with network slice instances corresponding to certain S-NSSAIs. NSSF414 may return one or more NRFs that are to be used to select NF/services within the selected network slice instance. It may also return information about the reject cause of S-nsai not included in the allowed nsais. The NSSF414 may return the configured nsai of the serving PLMN and possibly the associated mapping of the configured nsai.

In step 14 (labeled as nnrf_nfdiscovery_request/Response in fig. 4), the initial AMF406 may initiate a nnrf_nfdiscovery process with the NRF.

In some embodiments, the initial AMF406 may send an nnrf_nfdiscovery_request to NRF 416. The nnrf_nfdiscovery_request may include NF types and/or AMF sets.

In some embodiments, if the initial AMF406 does not store the target AMF address locally, and if the initial AMF406 intends to include AN AMF address using direct rerouting to the target AMF410 or rerouting of AN message via (NG-R) AN is required, the initial AMF406 invokes AN nnrf_nfdiscover_request service operation from the NRF to find AN appropriate target AMF (e.g., target AMF 410) that requires NF capabilities to service the UE402.NF type is set to AMF. The AMF set is included in the nnrf_nfdiscovery_request.

In some embodiments, NRF416 sends a response to the nnrf_nfdiscovery_request to the AMF. The nrrf_nfdiscovery_request may include an AMF pointer, an AMF address, and/or a list of additional selection rules and NF capabilities.

NRF416 replies with a list of potential target AMFs. NRF416 may also provide details of the services provided by the candidate AMFs and notification endpoints for each type of notification service that the selected AMF has registered (if available) with NRF 416. Instead, it provides a list of potential target AMFs and their capabilities, and optionally additional selection rules. Based on the information about the registered NFs and the required capabilities, the target AMF410 is selected by the initial AMF 406.

If the initial AMF406 is not part of the target AMF set and the list of candidate AMFs cannot be obtained by querying the NRF416 with the target AMF set (e.g., the NRF416, which is locally preconfigured on the AMF, does not provide the requested information, the query provided by the NSSF414 for the appropriate NRF416 is unsuccessful, or the initial AMF406 knows that the initial AMF406 is not authorized as a serving AMF, etc.), the initial AMF406 may perform forwarding the NAS message to the target AMF410 through the RAN 404; as in 3gpp TS 23.501 clause 6.3.5, including the allowed NSSAI and AMF sets to enable the RAN404 to select the target AMF410.

In step 15 (labeled as assigning a new 5G-GUTI in fig. 4), the initial AMF406 assigns (e.g., assigns, reserves, distributes) a new device identification (e.g., 5G-GUTI) for identifying the UE 402. For example, the initial AMF406 may receive a first registration request from a wireless communication device via a Radio Access Network (RAN), the first registration request including a first device identification associated with the wireless communication device. The initial AMF406 may assign a second device identification associated with the wireless communication device in response to receiving the registration request. The first device identification and/or the second device identification may include a 5 th generation globally unique temporary user equipment identification (5G-GUTI). The initial AMF may establish a security context associated with the wireless communication device.

In step 16 (labeled as using 5G-GUTI in fig. 4 instead of the user equipment identity (also referred to herein as UE ID) in the full RR message), the initial AMF406 uses the new device identity (e.g., 5G-GUTI) instead of the device identity (e.g., UE ID) included in the full Registration Request (RR) message in step 1 or step 6 in fig. 4 to identify the UE 402. For example, the initial AMF may generate a second registration request including a second device identification. The initial AMF may generate the second registration request by replacing the device identification of the first registration request with the second device identification. The first device identification may not be in the second registration request.

In step 17 (labeled in fig. 4 as integrity protection RR message using 5G NAS security context), the initial AMF406 invokes (e.g., performs, executes, etc.) the integrity protection of the registration request using the 5G NAS security context. For example, the initial AMF may use the security context to perform integrity protection on the second registration request to generate a protected registration request.

In step 18 (labeled re-route NAS message (RR (new 5G-GUTI)) in fig. 4), if the initial AMF406 decides to forward the NAS message to the target AMF410 via the RAN404 based on the local policy and subscription information, unless one or more target AMFs 410 are returned from the NSSF414 and identified by the list of candidate AMFs, the initial AMF406 sends the re-route NAS message to the RAN404. The reroute NAS message contains information about the target AMF410 and a full registration request message. If the initial AMF406 has obtained information as described at step 13 in FIG. 4, that information is included.

In step 19 (labeled initial UE message (RR (new 5G-GUTI)) in fig. 4), the RAN404 sends an initial UE message to the target AMF410 indicating: rerouting results from the fact that the slice includes the information provided by NSSF414 in step 13 of fig. 4. For example, the initial AMF may send a protected registration request to the target AMF via the RAN, such that the target AMF retrieves a UE context including a security context from the initial AMF using the second device identification, and registers the wireless communication device with the target AMF using the security context. As another example, the initial AMF may send a reroute message to the RAN that includes the protected registration request and a function identification associated with the target AMF. In some embodiments, the rerouting message causes the RAN to send a protected registration request to the target AMF.

As another example, the target AMF may receive a protected registration request including the second device identification from the initial AMF via a Radio Access Network (RAN). The protected registration request may be generated by the initial AMF in response to receiving a registration request including a first device identification associated with the wireless communication device and integrity protection by the initial AMF using the security context. The target AMF may retrieve the UE context including the security context from the initial AMF in response to receiving the protected registration request. The target AMF may register the wireless communication device with the target AMF using the security context.

In step 20 (labeled Namf Communication ueContexttransfer in FIG. 4), the target AMF410 sends Namf Communication ueContexttransfer to the initial AMF 406. The Namf Communication UEContext Transfer may include a full registration request.

In some embodiments, if a new 5G-GUTI (e.g., new device identification) is included in the registration request and the serving AMF has changed since the last registration procedure, the target AMF410 may invoke namf_communication_uecontext_transfer service operation on the initial AMF406, which initial AMF406 includes an integrity-protected registration request NAS message and an access type to request the SUPI and UE context of the UE 402. For details on this service operation see clause 5.2.2.2.2 of 3gpp TS 23.502. In this case, the initial AMF406 uses the new 5G-GUTI and the integrity-protected full registration request NAS message, or SUPI and an indication that the UE402 is authenticated from the target AMF410, to verify integrity protection if the context transfer service operation call corresponds to the requested UE. The initial AMF406 also communicates event subscription information to the target AMF410 for the UE402 through each NF consumer.

In some embodiments, if the initial AMF406 has a PDU session for another access type (different from the access type indicated in this step), and if the initial AMF406 determines that there is no possibility to relocate the N2 interface to the target AMF410, the initial AMF406 returns the SUPI of the UE and indicates that the registration request has been verified for integrity protection, but does not include the rest of the UE context.

In some embodiments, in the event that the target AMF410 has performed successful UE authentication after the previous integrity check in the initial AMF406 fails, the target AMF410 sets an indication that the UE402 is verified according to step 22a in fig. 4.

In some embodiments, after the UE402 successfully registers with the target AMF410, the NF consumer does not need to subscribe to the event again with the target AMF 410.

In step 21 (labeled Namf Communication ueContextTransferResponse in FIG. 4), the initial AMF406 sends a response to the Namf Communication ueContextTransferto the target AMF 410. In some embodiments, the response to Namf Communication uecontext transfer may include SUPI and/or UE context in AMF (per table 5.2.2.2.2-1 of 3gpp TS 23.502). The initial AMF406 may start a dedicated (guard) timer for the UE context.

In some embodiments, if the initial AMF406 maintains information about the established one or more PDU sessions, the initial AMF406 includes SMF information, one or more DNNs, one or more S-NSSAIs, and one or more PDU session IDs.

In some embodiments, if the initial AMF406 maintains the UE context established through the N3IWF, the initial AMF406 includes the CM state of the UE402 connected through the N3 IWF. If the UE402 is in CM connected state through the N3IWF, the initial AMF406 includes information about NGAP UE-TNLA bonding.

In some embodiments, if the initial AMF406 fails the integrity check on the registration request NAS message, the initial AMF406 may indicate that the integrity check failed.

In some embodiments, if the initial AMF406 maintains information about the AM policy association and information about the UE policy association (i.e., policy control request triggers for updating the UE policy as defined in 3gpp TS 23.503), the initial AMF406 includes information about the AM policy association, the UE policy association, and the PCF ID. In the roaming case, a V-PCF ID and an H-PCF ID are included.

For example, the initial AMF may receive a context transfer request to transmit a UE context including a security context to the target AMF. The initial AMF may transmit a UE context including a security context to the target AMF in response to the context transfer request. The initial AMF may use the security context to verify the integrity protection of the protected registration request. The initial AMF may verify integrity protection of the protected registration request in response to receiving a context transfer request from the target AMF. As another example, the target AMF may transmit a context transfer request to the initial AMF such that the initial AMF transmits a UE context including the security context to the target AMF. The context transfer request also causes the initial AMF to verify the integrity protection of the protected registration request using the security context. The target AMF may transmit a first message to the initial AMF indicating that the wireless communication device is registered with the target AMF. The first message may cause the initial AMF to transmit a second message to the old AMF, the second message indicating that the wireless communication device is registered with the target AMF. The initial AMF may generate the protected registration request by replacing the first device identification of the registration request with the second device identification. The first device identification may not be present in the protected registration request. The first device identification and/or the second device identification may include a fifth generation globally unique temporary user equipment identification (5G-GUTI). A security context associated with the wireless communication device may be established by the initial AMF.

In step 22 (labeled authentication/security in fig. 4), the UE402 and the target AMF410 negotiate information associated with authentication and/or security.

In some embodiments, if authentication is required, the target AMF410 requests the authentication from the AUSF 412; if tracking requirements are available at the target AMF410 with respect to the UE402, the target AMF410 provides the tracking requirements in its request to the AUSF 412. Upon request from the target AMF410, the AUSF412 may perform authentication of the UE 402. Authentication is performed as described in 3gpp TS 33.501. The AUSF412 selects the UDM418 as described in 3gpp TS 23.501, clause 6.3.8, and obtains authentication data from the UDM 418.

Once the UE402 has been authenticated, the AUSF412 provides relevant security related information to the target AMF 410.

After successful authentication in the target AMF410 (which is triggered by an integrity check failure in the initial AMF406 at step 21 in fig. 4), the target AMF410 invokes step 20 in fig. 4 again and indicates that the UE402 is verified (i.e. by the cause parameter as specified in clause 5.2.2.2.2 of 3gpp TS 23.502).

In some embodiments, if the 5G-AN has requested a UE context, the target AMF410 initiates AN NGAP procedure to provide the 5G-AN with a security context as specified in 3gpp ts 38.413. If the target AMF410 does not support N26 for EPS interworking and it receives UE MM core network capabilities including the following indications: which supports a request type flag "handover" for a PDN connectivity request during the attach procedure defined in clause 5.17.2.3.1 of 3gpp TS 23.501, the target AMF410 provides AN indication to the 5G-AN that "redirection of EPS fallback for voice is possible" as specified in 3gpp TS 38.413. Furthermore, if tracking requirements are available at the target AMF410 with respect to the UE402, the target AMF410 provides the 5G-AN with tracking requirements in the NGAP procedure.

The 5G-AN stores the security context and acknowledges to the target AMF 410. The 5G-AN uses the security context to protect messages exchanged with the UE402, as in 3gpp TS 33.501.

In step 23 (labeled Namf_communication_RegistrationCompacteNotification in FIG. 4), the target AMF410 sends Namf_communication_RegistrationCompactNotification () to the initial AMF 406.

In some embodiments, if the AMF has changed, the target AMF410 notifies the initial AMF406: registration of the UE402 in the target AMF410 is accomplished by invoking a Namf Communication registration complete notification service operation.

In some embodiments, if the authentication/security procedure fails, registration should be denied and the target AMF410 invokes a Namf_communication_RegistrationCompacteNotification service operation to the initial AMF406, with a denial indicating reason code. The initial AMF406 proceeds as if the UE context transfer service operation was never received.

In some embodiments, if one or more S-nsais used in the old registration area cannot be serviced in the target registration area, the target AMF410 determines which PDU sessions are not supported in the new registration area. The target AMF410 invokes a Namf_communication_RegistrationCompacteNotification service operation to the initial AMF406, including the rejected PDU session ID and reject cause (e.g., S-NSSAI becomes no longer available). The new AMF then modifies the PDU session state accordingly. The initial AMF406 informs the corresponding one or more SMFs of the SM context of the locally released UE by invoking the nsmf_pduse_release mcontext service operation (see namf_communication_registration complex notify service operation details of clause 5.2.2.2.3 of 3gpp TS 23.502).

In some embodiments, if the target AMF410 receives information about the AM policy association and the UE policy association in the UE context transfer of step 20 and decides not to use one or more PCFs identified by one or more PCF IDs for the AM policy association and the UE policy association based on the local policy, it will inform the initial AMF406 that the AM policy association and the UE policy association are no longer used in the UE context and then perform PCF selection.

In step 24 (labeled Namf_communication_RegistrationCompacteNotification in FIG. 4), the initial AMF406 sends Namf_communication_RegistrationCompactNotification () to the old AMF 408.

In some embodiments, if the AMF has changed, the initial AMF406 notifies the old AMF408 by invoking the Namf_communication_RegistrationCompleteNotify service operation: the UE402 completes registration in the initial AMF 406.

In some embodiments, if the authentication/security procedure fails, registration should be denied and the initial AMF406 calls the old AMF408 with a Namf_communication_RegistrationCompacteNotification service operation with a reject indication reason code. The old AMF408 proceeds as if no UE context transfer service operation had been received.

In some embodiments, if one or more S-nsais used in the old registration area cannot be serviced in the target registration area, the initial AMF determines which PDU session is not supported in the new registration area. The initial AMF406 invokes a Namf_communication_RegistrationCompacteNotification service operation to the old AMF408 that includes the rejected PDU session ID and the reject cause (e.g., S-NSSAI becomes no longer available). The new AMF then modifies the PDU session state accordingly. The old AMF408 informs the corresponding one or more SMFs to release the SM context of the UE locally by invoking the nsmf_pduse_release mcontext service operation (see clause 5.2.2.2.3 of 3gpp TS 23.502 for details of namf_communication_ RegistrationComp leteNotify service operation).

In some embodiments, if the initial AMF406 receives information about the AM policy association and the UE policy association in the UE context transfer of step 3 of fig. 4 and decides not to use one or more PCFs identified by one or more PCF IDs for the AM policy association and the UE policy association based on the local policy, it will inform the old AMF408 that the AM policy association and the UE policy association in the UE context are no longer used and then perform PCF selection.

For example, the initial AMF may receive a first message from the target AMF indicating that the wireless communication device is registered with the target AMF. The initial AMF may send a second message to the old AMF indicating that the wireless communication device is registered with the target AMF in response to receiving the first message.

In step 25 (labeled as step 11-22 of fig. 4.2.2.2.2-1 in 3gpp TS 23.502 in fig. 4), after receiving the transmitted registration request message, if a UE context is received from the initial AMF406, the target AMF410 continues the registration procedure from step 11 until step 22 of fig. 4.2.2.2.2-1 of 3gpp TS 23.502.

Fig. 5 depicts a flow chart of a registration method that utilizes access and mobility management functions reassignment from the perspective of an initial AMF, according to some embodiments of the present disclosure. Additional, fewer, or different operations may be performed in the method, depending on the particular embodiment. In some embodiments, some or all of the operations of method 500 may be performed by a wireless communication node, such as BS102 in fig. 1. In some operations, some or all of the operations of method 500 may be performed by a wireless communication device, such as UE104 in fig. 1. In some operations, some or all of the operations of method 500 may be performed by an AMF (such as initial AMF406, old AMF408, and/or target AMF410 in fig. 4). Each operation may be reordered, added, removed, or repeated.

As shown, the method 500 includes an operation 502: a first registration request including a first device identification associated with a wireless communication device is received from the wireless communication device via a Radio Access Network (RAN) by an initial access and mobility management function (AMF). The method further includes an operation 504: a second device identification associated with the wireless communication device is assigned by the initial AMF in response to receiving the registration request. The method further includes an operation 506: a second registration request including a second device identification is generated by the initial AMF.

Fig. 6 depicts a flow chart of a registration method that utilizes access and mobility management functions reassignment from the perspective of a target AMF, according to some embodiments of the present disclosure. Additional, fewer, or different operations may be performed in the method, depending on the particular embodiment. In some embodiments, some or all of the operations of method 600 may be performed by a wireless communication node, such as BS102 in fig. 1. In some operations, some or all of the operations of method 600 may be performed by a wireless communication device, such as UE104 in fig. 1. In some operations, some or all of the operations of method 600 may be performed by an AMF (such as initial AMF406, old AMF408, and/or target AMF410 in fig. 4). Each operation may be reordered, added, removed, or repeated.

As shown, the method 600 includes an operation 602: a protected registration request including a second device identification is received by a target access and mobility management function (AMF) from an initial AMF via a Radio Access Network (RAN), the protected registration request generated by the initial AMF in response to receiving a registration request including a first device identification associated with a wireless communication device and integrity protection by the initial AMF using a security context. The method 600 further includes an operation 604: the UE context including the security context is obtained from the initial AMF by the target AMF in response to receiving the protected registration request. The method 600 further includes an operation 606: the security context is used by the target AMF to register the wireless communication device with the target AMF.

While various embodiments of the present technology have been described above, it should be understood that they have been presented by way of example only, and not limitation. As such, the present technology provides various schematics, which may depict example architectures or configurations that enable those skilled in the art to understand the example features and functionality of the technology. However, they will appreciate that the technical solution is not limited to the illustrated example architecture or configuration, but may be implemented using a variety of alternative architectures and configurations. In addition, one or more features of one embodiment may be combined with one or more features of another embodiment described herein, as will be appreciated by those of ordinary skill in the art. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described illustrative embodiments.

It should also be appreciated that any reference to elements herein using names such as "first," "second," etc. generally does not limit the number or order of those elements. Rather, these designations may be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, reference to first and second elements does not mean that only two elements may be employed, nor that the first element must precede the second element in some way.

In addition, those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols that may be referenced in the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of ordinary skill in the art will further appreciate that any of the various illustrative logical blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein may be implemented with electronic hardware (e.g., digital implementations, analog implementations, or a combination of both), firmware, various forms of program or design code incorporating instructions (which may be referred to herein as "software" or a "software module" for convenience), or any combination of these techniques. To clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these techniques depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions do not result in a departure from the scope of the present disclosure.

Furthermore, those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, devices, components, and circuits described herein may be implemented within or performed by an Integrated Circuit (IC) that may comprise a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, or any combination thereof. Logic blocks, modules, and circuits may also include antennas and/or transceivers to communicate with various components within the network or within the device. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration for performing the functions described herein.

If implemented in software, the functions may be stored on a computer-readable medium as one or more instructions or code. Thus, the steps of a method or algorithm disclosed herein may be implemented as software stored on a computer readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

As used herein, the term "module" refers to software, firmware, hardware, and any combination of these elements for performing the relevant functions described herein. In addition, for purposes of discussion, the various modules are described as discrete modules; however, as will be apparent to one of ordinary skill in the art, two or more modules may be combined to form a single module that performs the relevant functions in accordance with embodiments of the present technology.

In addition, a memory or other storage device and communication components may be employed in embodiments of the present technology. It will be appreciated that for clarity purposes, the above description has described embodiments of the present technology with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the technical solution. For example, functions illustrated as being performed by separate processing logic elements or controllers may be performed by the same processing logic elements or controllers. Thus, references to specific functional units are only references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.

Various modifications to the embodiments described in the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the novel features and principles disclosed herein as recited in the following claims.

Claims (17)

1. A method of registration with access and mobility management function reassignment for communication between a wireless communication node and a wireless communication device, comprising,

receiving, by an initial access and mobility management function, AMF, a first registration request from a wireless communication device via a radio access network, RAN, the first registration request comprising a first device identification associated with the wireless communication device;

assigning, by the initial AMF, a second device identification associated with the wireless communication device in response to receiving the registration request;

generating, by the initial AMF, a second registration request comprising the second device identification, wherein the initial AMF replaces the device identification of the first registration request with the second device identification;

Performing integrity protection on the second registration request by the initial AMF using a security context to generate a protected registration request; and

the protected registration request is sent by the initial AMF to a target AMF via the RAN, such that the target AMF obtains the security context from the initial AMF using the second device identification, and registers the wireless communication device with the target AMF using the security context.

2. The method of claim 1, wherein sending the protected registration request comprises:

a rerouting message is sent by the initial AMF to the RAN, the rerouting message including the protected registration request and a function identification associated with the target AMF, the rerouting message causing the RAN to send the protected registration request to the target AMF.

3. The method of claim 1, further comprising:

receiving, by the initial AMF, a context transfer request for sending the security context to the target AMF; and

the security context is sent by the initial AMF to the target AMF in response to the context transfer request.

4. A method according to claim 3, further comprising:

the security context is used by the initial AMF to verify integrity protection of the protected registration request.

5. The method of claim 4, wherein the initial AMF verifies integrity protection of the protected registration request in response to receiving the context transfer request from the target AMF.

6. The method of claim 1, further comprising:

receiving, by the initial AMF, a first message from the target AMF indicating that the wireless communication device is registered with the target AMF; and

a second message is sent by the initial AMF to an old AMF indicating that the wireless communication device is registered with the target AMF in response to receiving the first message.

7. The method of claim 1, wherein the first device identification is absent from the second registration request.

8. The method of claim 1, wherein at least one of the first device identification and the second device identification comprises a 5G-GUTI of a 5 th generation globally unique temporary user equipment identification.

9. The method of claim 1, further comprising:

a security context associated with the wireless communication device is established by the initial AMF.

10. A method of registration with access and mobility management function reassignment for communication between a wireless communication node and a wireless communication device, comprising,

receiving, by a target access and mobility management function, AMF, a protected registration request comprising a second device identification from an initial AMF via a radio access network, RAN, the protected registration request generated by the initial AMF in response to receiving a registration request comprising a first device identification associated with a wireless communication device and integrity protection by the initial AMF using a security context, wherein the initial AMF generates the protected registration request by replacing the first device identification with the second device identification;

obtaining, by the target AMF, the security context from the initial AMF in response to receiving the protected registration request; and

registering, by the target AMF, the wireless communication device on the target AMF using the security context.

11. The method of claim 10, further comprising:

a context transfer request is sent by the target AMF to the initial AMF, the context transfer request causing the initial AMF to send the security context to the target AMF.

12. The method of claim 11, wherein the context transfer request further causes the initial AMF to use the security context to verify integrity protection of the protected registration request.

13. The method of claim 10, further comprising:

a first message is sent by the target AMF to the initial AMF indicating that the wireless communication device is registered with the target AMF, wherein the first message causes the initial AMF to send a second message to an old AMF indicating that the wireless communication device is registered with the target AMF.

14. The method of claim 10, wherein the first device identification is not present in the protected registration request.

15. The method of claim 10, wherein at least one of the first device identification and the second device identification comprises a 5G-GUTI of a 5 th generation globally unique temporary user equipment identification.

16. The method of claim 10, wherein the security context associated with the wireless communication device is established by the initial AMF.

17. A computer program product comprising computer readable program medium code stored thereon, which when executed by a processor causes the processor to implement the method according to any of claims 1 to 16.