A method for registration through dual radio network

Abstract

This disclosure generally relates to wireless communication. Performed by a UE, one method includes: transmitting, to a first network element, a first message requesting a radio access operation, wherein the UE is connected to a network via at least one radio access, and wherein the radio access operation comprises one of: an add operation for adding a target radio access; or a replace operation for replacing a first radio access of the at least one radio access with a target radio access; and adding a target UE security context associated with the target radio access, the target UE security context comprising at least one of: a KSI associated with the target radio access; a target AMF key associated with an AMF serving the target radio access; a key associated with the first network element; or an identifier of the UE assigned by a second network element.

Description

A METHOD FOR REGISTRATION THROUGH DUAL RADIO NETWORKTECHNICAL FIELD

[0001] This disclosure relates to wireless communication including 5G and 6G technologies, and in particular, for a User Equipment (UE) to securely registering and communicating with wireless communication network (s) via multiple radio connections each corresponding to a radio access point.BACKGROUND

[0002] In a communication network, the mutual authentication of a UE and the communication network may be performed to allow only authenticated UE and the authenticated communication network to communicate with each other. Efficient and robust authentication mechanism involving various network elements is critical to provide secure communication between UE and the wireless network.SUMMARY

[0003] This disclosure discloses methods, systems, devices, and storage medium relates to wireless communication. Embodiments are described for a UE to securely registering and communicating with wireless communication network (s) via multiple radio connections each corresponding to a radio access point.

[0004] In one embodiment, the present disclosure describes a method for wireless communication. Performed by a wireless device, the method includes: transmitting, to a first network element, a first message requesting a radio access operation, wherein the wireless device is connected to a network via at least one radio access, and wherein the radio access operation comprises one of: an add operation for adding a target radio access; or a replace operation for replacing a first radio access of the at least one radio access with a  target radio access; and adding a target UE security context associated with the target radio access, the target UE security context comprising at least one of: a Key Set Identifier (KSI) associated with the target radio access; a target Access and Mobility Management Function (AMF) key associated with an AMF serving the target radio access; a key associated with the first network element; or an identifier of the wireless device assigned by a second network element.

[0005] In one embodiment, the present disclosure describes a method for wireless communication. Performed by a first network element, the method includes: receiving, from a second network element serving a target radio access for a wireless device, a first message requesting a radio access operation, wherein the wireless device is connected to a network via at least one radio access, and wherein the radio access operation comprises one of:an add operation for adding the target radio access; or a replace operation for replacing a first radio access of the at least one radio access with the target radio access, the first message carrying an identifier of the wireless device associated with the first radio access; and transmitting, to the wireless device, a second message comprising at least one of: a Key Set Identifier (KSI) associated with the target radio access; UE security capability information of the wireless device; or an AMF key changing flag indicating whether a target AMF key associated with the first network element for the target radio access needs to be updated.

[0006] In another embodiment, a network element or wireless device comprising a processor and a memory is disclosed. The processor may be configured to read computer code from the memory to implement any of the methods above.

[0007] In yet another embodiment, a computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon is disclosed. The computer code, when executed by a processor, may cause the processor to implement any one of the methods above.

[0008] The above embodiments and other aspects and alternatives of their implementations are explained in greater detail in the drawings, the descriptions, and the  claims below.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 shows an exemplary communication network including various terminal devices, a carrier network, data network, and service applications.

[0010] FIG. 2 shows exemplary network functions or network nodes in a communication network.

[0011] FIG. 3 shows exemplary network functions or network nodes in a wireless communication network.

[0012] FIG. 4 shows an example wireless network node (or network element, network entity, entity) .

[0013] FIG. 5 shows an example user equipment.

[0014] FIG. 6 shows an exemplary UE with dual radio accesses to wireless network (s) .

[0015] FIGs. 7-14b show various exemplary logic flows for adding or replacing a radio access under various network deployments.DETAILED DESCRIPTION

[0016] An exemplary communication network, shown as 100 in FIG. 1, may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102, for example, may include access networks 120 and a core network 130. The carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among terminal devices 110 and 112, between the terminal devices 110 and 112 and the service applications 140, or between the terminal devices 110 and 112 and the other data networks 150. Communication sessions and corresponding data paths may be established and  configured for such data transmission. The Access networks 120 may be configured to provide terminal devices 110 and 112 network access to the core network 130. The Access network 120 may, for example, support wireless access via radio resources, or wireline access. The core network 130 may include various network nodes or network functions configured to control the communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers that are accessible by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. A service application 140 may be deployed as a data network outside of the core network 130. Likewise, the other data networks 150 may be accessible by the terminal devices 110 and 112 through the core network 130 and may appear as either data destination or data source of a particular communication session instantiated in the carrier network 102.

[0017] The core network 130 of FIG. 1 may include various network nodes or functions geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or as software entities. A network node may each be configured with one or more types of network functions. These network nodes or network functions may collectively provide the provisioning and routing functionalities of the core network 130. The term “network nodes” and “network functions” are used interchangeably in this disclosure.

[0018] FIG. 2 further shows an exemplary division of network functions in the core network 130 of a communication network 200. While only single instances of network nodes or functions are illustrated in FIG. 2, those having ordinary skill in the art readily understand that each of these network nodes may be instantiated as multiple instances of network nodes that are distributed throughout the core network 130. As shown in FIG. 2, the core network 130 may include but is not limited to network nodes such as access management network node (AMNN) 230, authentication network node (AUNN) 260,  network data management network node (NDMNN) 270, session management network node (SMNN) 240, data routing network node (DRNN) 250, policy control network node (PCNN) 220, and application data management network node (ADMNN) 210. Exemplary signaling and data exchange between the various types of network nodes through various communication interfaces are indicated by the various solid connection lines in FIG. 2. Such signaling and data exchange may be carried by signaling or data messages following predetermined formats or protocols.

[0019] The implementations described above in FIGs. 1 and 2 may be applied to both wireless and wireline communication systems. FIG. 3 illustrates an exemplary cellular wireless communication network 300 based on the general implementation of the communication network 200 of FIG. 2. FIG. 3 shows that the wireless communication network 300 may include user equipment (UE) 310 (functioning as the terminal device 110 of FIG. 2) , radio access network (RAN) 320 (functioning as the access network 120 of FIG. 2) , data network (DN) 150, and core network 130 including access management function (AMF) 330 (functioning as the AMNN 230 of FIG. 2) , session management function (SMF) 340 (functioning as the SMNN 240 of FIG. 2) , application function (AF) 390 (functioning as the ADMNN 210 of FIG. 2) , user plane function (UPF) 350 (functioning as the DRNN 250 of FIG. 2) , policy control function 322 (functioning as the PCNN 220 of FIG. 2) , authentication server function (AUSF) 360 (functioning as the AUNN 260 of FIG. 2) , and universal data management (UDM) function 370 (functioning as the UDMNN 270 of FIG. 2) . Again, while only single instances for some network functions or nodes of the wireless communication network 300 (the core network 130 in particular) are illustrated in FIG. 3, those of ordinary skill in the art readily understand that each of these network nodes or functions may have multiple instances that are distributed throughout the wireless communication network 300. While the AF 390 is depicted as part of the core network 130 in FIG. 3, they may be considered as associated with particular service applications 140 and may be considered as being outside of the core network 140. In this disclosure, various functions deployed in the wireless network as described above may also be referred to as function entities, which may be implemented as a network node, a network element, a logical  function, via hardware, software, or a combination thereof.

[0020] In FIG. 3, the UE 310 may be implemented as various types of mobile devices that are configured to access the core network 130 via the RAN 320. The UE 310 may include but is not limited to mobile phones, laptop computers, tablets, Internet-Of-Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The UE may also be Multi-access Edge Computing (MEC) capable UE that supports edge computing. The RAN 320 for example, may include a plurality of radio base stations distributed throughout the service areas of the carrier network. The communication between the UE 310 and the RAN 320 may be carried in over-the-air (OTA) radio interfaces as indicated by 311 in FIG. 3.

[0021] Continuing with FIG. 3, the UDM 370 may form a permanent storage or database for user contract and subscription data. The UDM may further include an authentication credential repository and processing function (ARPF, as indicated in 370 of FIG. 3) for storage of long-term security credentials for user authentication, and for using such long-term security credentials as input to perform computation of encryption keys as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, the UDM / ARPF 370 may be located in a secure network environment of a network operator or a third-party.

[0022] The AMF / SEAF 330 may communicate with the RAN 320, the SMF 340, the AUSF 360, the UDM / ARPF 370, and the Policy Control Function (PCF) 322 via communication interfaces indicated by the various solid lines connecting these network nodes or functions. The AMF / SEAF 330 may be responsible for UE to non-access stratum (NAS) signaling management, and for provisioning registration and access of the UE 310 to the core network 130 as well as allocation of SMF 340 to support communication need of a particular UE. The AMF / SEAF 330 may be further responsible for UE mobility management. The AMF may also include a security anchor function (SEAF, as indicated in 330 of FIG. 3) that, as described in more detail below, and interacts with AUSF 360 and UE 310 for user authentication and management of various levels of encryption / decryption keys. The AUSF 360 may terminate user registration / authentication / key generation requests from the  AMF / SEAF 330 and interact with the UDM / ARPF 370 for completing such user registration / authentication / key generation.

[0023] The SMF 340 may be allocated by the AMF / SEAF 330 for a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for allocating UPF 350 to support the communication session and data flows therein in a user data plane and for provisioning / regulating the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350) . Alternative to being allocated by the SMF 340, the UPF 350 may be allocated by the AMF / SEAF 330 for the particular communication session and data flows. The UPF 350 allocated and provisioned by the SMF 340 and AMF / SEAF 330 may be responsible for data routing and forwarding and for reporting network usage by the particular communication session. For example, the UPF 350 may be responsible for routing end-end data flows between UE 310 and the DN 150, between UE 310 and the service applications 140. The DN 150 and the service applications 140 may include but are not limited to data network and services provided by the operator of the wireless communication network 300 or by third-party data network and service providers.

[0024] The PCF 322 may be responsible for managing and providing various levels of policies and rules applicable to a communication session associated with the UE 310 to the AMF / SEAF 330 and SMF 340. As such, the AMF / SEAF 330, for example, may assign SMF 340 for the communication session according to policies and rules associated with the UE 310 and obtained from the PCF 322. Likewise, the SMF 340 may allocate UPF 350 to handle data routing and forwarding of the communication session according to policies and rules obtained from the PCF 322.

[0025] While FIGs. 1-3 and the various exemplary implementations described below are based on cellular wireless communication networks, the scope of this disclosure is not so limited and the underlying principles are applicable to other types of wireless and wireline communication networks.

[0026] Network identity and data security in the wireless communication network 300 of FIG. 3 may be managed via user authentication processes provided by the AMF / SEAF 330, the AUSF 360, and the UDM / ARPF 370. In particularly, the UE 310 may first communicate with AMF / SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM / ARPF 370. Communication sessions established for the UE 310 after user authentication to the wireless communication network 300 may then be protected by the various levels of encryption / decryption keys. The generation and management of the various keys may be orchestrated by the AUSF 360 and other network functions in the communication network 300.

[0027] In the wireless communication network, the Application Function (AF, or application function entity) may provide application service to a UE. The AF may be deployed in various locations, such as a Home Public Land Mobile Network (HPLMN) of the UE, a Visited Public Land Mobile Network (VPLMN) of the UE (e.g., when the UE roams to the VPLMN) , or a Data Network (DN) which is external to the HPLMN and the VPLMN. Secure or encrypted data communication between the AF and the UE may be implemented under an Authentication and Key Management for Applications (AKMA) framework. The AKMA framework may be based on various authentication procedures such as the 5G Authentication and Key Agreement (5G-AKA) method, the Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') method, the Extensible Authentication Protocol –Transport Layer Security (EAP-TLS) method, or the like.

[0028] FIG. 4 shows an example of electronic device 500 to implement various network nodes, network elements, network entities, such as a network base station (e.g., a radio access network node) , a core network (CN) , a core network element / entity (e.g., an AMF, a UDM, an AAnF, etc. ) , an operation and maintenance (OAM) , and the like. Optionally in one implementation, the example electronic device 500 may include radio transmitting / receiving (Tx / Rx) circuitry 508 to transmit / receive communication with UEs and / or other base stations.  Optionally in one implementation, the electronic device 500 may also include network interface circuitry 509 to communicate the base station with other base stations and / or a core network, e.g., optical or wireline interconnects, Ethernet, and / or other data transmission mediums / protocols. The electronic device 500 may optionally include an input / output (I / O) interface 506 to communicate with an operator or the like.

[0029] The electronic device 500 may also include system circuitry 504. System circuitry 504 may include processor (s) 521 and / or memory 522. Memory 522 may include an operating system 524, instructions 526, and parameters 528. Instructions 526 may be configured for the one or more of the processors 521 to perform the functions of the network node. The parameters 528 may include parameters to support execution of the instructions 526. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and / or other parameters.

[0030] In this disclosure, a network function / network entity / entity, such as an AMF, an AUSF, a UDM, an AAnF, an NEF, an AF, may be implemented in hardware, software, a combination of hardware and software, and may be implemented or integrated in the electronic device 500. They may also be implemented as a logical entity hosted by the electronic device 500.

[0031] FIG. 5 shows an example of an electronic device to implement a terminal device 600 (for example, a UE) . The UE 600 may be a mobile device, for example, a smart phone or a mobile communication module disposed in a vehicle. The UE 600 may include a portion or all of the following: communication interfaces 602, a system circuitry 604, an input / output interfaces (I / O) 606, a display circuitry 608, and a storage 609. The display circuitry may include a user interface 610. The system circuitry 604 may include any combination of hardware, software, firmware, or other logic / circuitry. The system circuitry 604 may be implemented, for example, with one or more systems on a chip (SoC) , application specific integrated circuits (ASIC) , discrete analog and digital circuits, and other circuitry. The system circuitry 604 may be a part of the implementation of any desired functionality in the UE 600. In that regard, the system circuitry 604 may include logic that facilitates, as examples,  decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface 610. The user interface 610 and the inputs / output (I / O) interfaces 606 may include a graphical user interface, touch sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I / O interfaces 606 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input  / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors) , and other types of inputs.

[0032] Referring to FIG. 5, the communication interfaces 602 may include a Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 616 which handles transmission and reception of signals through one or more antennas 614. The communication interface 602 may include one or more transceivers. The transceivers may be wireless transceivers that include modulation  / demodulation circuitry, digital to analog converters (DACs) , shaping tables, analog to digital converters (ADCs) , filters, waveform shapers, filters, pre-amplifiers, power amplifiers and / or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium. The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM) , frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 602 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) +, 4G  / Long Term Evolution (LTE) , 5G and 6G standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP) , GSM Association, 3GPP2, IEEE, or other  partnerships or standards bodies.

[0033] Referring to FIG. 5, the system circuitry 604 may include one or more processors 621 and memories 622. The memory 622 stores, for example, an operating system 624, instructions 626, and parameters 628. The processor 621 is configured to execute the instructions 626 to carry out desired functionality for the UE 600. The parameters 628 may provide and specify configuration and operating options for the instructions 626. The memory 622 may also store any BT, WiFi, 3G, 4G, 5G, 6G or other data that the UE 600 will send, or has received, through the communication interfaces 602. In various implementations, a system power for the UE 600 may be supplied by a power storage device, such as a battery or a transformer.

[0034] UE Security Parameters and Dual Radio Accesses

[0035] When a UE employs multiple radio connections via multiple radio access points, for each radio connection, the UE needs to register with an AMF associated or allocated to the radio access point (i.e., the AMF serves the radio access point) . In this disclosure, a radio access point may be referred to as a radio for simplicity. For each successful registration (i.e., for each radio connection, or for each radio) , the UE may maintain a security context which includes a set of security parameters such as: Key Set Identifier (KSI) (e.g., ngKSI (next generation KSI) , 5G-GUTI (5G Globally Unique Temporary Identifier) , KAMF (AMF key, may also be noted as KAMF, the prefix K means “Key” ) , and KgNB (i.e., key for gNB) .

[0036] In some example implementations, KAMF is a key derived by the ME (Mobile Equipment, which refers to a portion of a UE along with other portions of UE such as a Universal Subscriber Identity Module (USIM) ) and SEAF from KSEAF. KAMF may be used to generate, for example, the integrity keys such as KNASint, and encryption keys such as KNASenc for non-access stratum (NAS) signaling, keys for RAN (e.g., KgNB) , and keys for non3GPP access such as KKN3IWF.

[0037] In some example implementations, KgNB is used to derive a new KgNB when performing horizontal or vertical key derivation during handovers, and the keys KUPenc, KUPint, KRRCenc, KRRCint, which are respectively used for the confidentiality and integrity protection of user plane (UP) traffic and radio resource control (RRC) signaling. As described above, KgNB may be derived from KAMF.

[0038] In some example implementations, the key set identifier ngKSI is assigned by the AMF either during the primary authentication and key agreement procedure or, for the mapped 5G NAS security context, during the inter-system change. The ngKSI may include a value and a type of security context parameter indicating whether a 5G NAS security context is a native 5G NAS security context or a mapped 5G NAS security context. Exemplarily, when the 5G NAS security context is a native 5G NAS security context, the ngKSI has the value of KSIAMF, and when the current 5G NAS security context is of type mapped, the ngKSI has the value of KSIASME.

[0039] As an example, when a UE registers with the AMF 1 through radio access point 1 (hereinafter radio 1) , the UE stores security context information associated with radio 1 and AMF 1. The security context may include parameters such as ngKSI1, 5G-GUTI1, KAMF1, and KgNB1. Meanwhile, for this UE, AMF 1 stores the ngKSI1, 5G-GUTI1, and KAMF1, and UDM stores the UE context for radio 1 and AMF 1, and the correspondence between radio 1 and AMF 1. That is, from UDM perspective, this UE is using radio 1 and is served by AMF 1. Further, the UDM may also stores security context information for the pair of (AMF 1, radio 1) . Note that the security context information may be stored at a granularity of per UE per radio level, such that for each radio access of each UE, there may be a security context. In this case, radio 1 utilizes a radio access technology, such as a 3GPP or a non-3GPP Radio Access Technology. The UE may add another radio access, such as another 3GPP Radio Access, via radio access point 2 (hereinafter radio 2) to access the wireless network. Therefore, UE may have a dual connection via 2 radios (radio 1 and radio 2) . Radio 1 and radio 2 may or may not be in a same core network, and may or may not belonging to a same access technology. The selection of radio 1 and / or radio 2 may be  determined by, for example, user preference, UE capabilities, service agreement, service profile, etc. For example, user preference may favor a lower fee rate in which case a radio connection with lower cost may be selected; the user preference may also favor higher data speed / throughput and radio 2 may be added on top of radio 1, to achieve goal; the user preference may also favor a better signal quality and a radio with better coverage may be selected; the user preference may also favor power efficiency and a radio with less power consumption may be selected. In some example implementations, multiple user preferences may be combined and considered jointly.

[0040] Radio 1 and radio 2 may use same or difference access technologies. For example, radio 1 and radio 2 may be part of a terrestrial communication network (TN network) , a non-terrestrial communication network (NTN network) , or a non-public network (NPN network, or a private network) . The access technologies may be based on cellular access, or wireless local-area network (WLAN) access, or a Wireless Fidelity (Wi-Fi) access. In this disclosure, various combinations of radio 1 and radio 2 are supported. For example, both radio 1 and radio 2 may be 3GPP based access network, such as gNB, eNB, ng-eNB, and the like; or radio 1 uses 3GPP based access technology, and radio 2 uses WLAN based access technology. In some example implementations, radio 1 and radio 2 may both belong to a same vendor or service provider. In some example implementations, they may belong to different vendors. In some example implementations, radio 1 and radio 2 may each belong to a different Public Land Mobile Network (PLMN) . In some example implementations, radio 1 and radio 2 may each belong to a different Radio Access Network (RAN) . In some example implementations, radio 1 may belong to a PLMN, and radio 2 may belong to a private network.

[0041] FIG. 6 shows a UE with exemplary dual radio accesses. In this example, the UE establishes two radio connections 710 and 712 destined to the Data Network (DN) 720 and both radio connections are 3GPP accesses. Radio 712 connects to a PLMN2. Radio 710, on the other hand, may connect to a different PLMN (PLMN1) , or Non-public network (NPN) such as a Standalone NPN (SNPN) . In some example implementations, radio 710 and radio  712 are served by a same core network (CN) . In some example implementations, radio 810 and radio 812 are served by different core networks.

[0042] There are special challenges in a dual access mode. Firstly, different radio accesses may belong to different core networks, different PLMNs. The network may have a heterogeneous architecture. Secondly, radio accesses may utilize different access technologies, such as 3GPP, WLAN, Wi-FI. Even under 3GPP, UE may use technologies under different generations (e.g., 4G, 5G, and 6G) . One special challenge comes from a security perspective, as different vendors, different networks are involved. Different vendors may have different security policies and different security requirements. Different vendors may or may not have a service agreement and the level of information (such as UE security context) exchange may vary, for example, context transfer may be allowed or prohibited between two vendors.

[0043] Challenges may also come from the detailed radio access operation –such as adding a radio access, or replacing a current radio access with a new radio access. For example, UE may already have two radio accesses, and may attempt to replace one of them with a different radio access. To securely add a new radio access, and clean up the replaced radio access, special design may be desired.

[0044] In this disclosure, various embodiments are described, in order to address certain security concerns under dual access deployment. The embodiments deal with various scenarios for adding a new radio access, and replacing one of two or more existing radio accesses. From A UE perspective, UE may maintain security context for each radio access. From an AMF perspective, each AMF may maintain security context for the particular radio access it serves or is responsible for. The radio accesses may be served by a same AMF, or different AMFs belonging to a same core network, or different AMFs belonging to different core networks. From a UDM perspective, for each radio access, the UDM maintains a record that stores information for the radio access, and its associated AMF.

[0045] The various embodiments also address the issue for AMF key sharing. In some  scenarios, the AMF key may not be shared when adding a radio access. For example, AMF key for radio access 1 may not be shared with to-be-added radio access 3. In some scenarios, the AMF key may be shared, based on a local policy of AMF, and / or UDM, and / or UE.

[0046] Examples in the disclosure may use two radio accesses for exemplary purpose. The same principle and concept may also apply to a UE with two or more radio accesses.

[0047] Embodiment 1: Radio 1 and Radio 2 Belong to Same Core Network (CN) –Adding Radio 2

[0048] In this embodiment, a UE already has a radio access via radio 1 (e.g., gNB1) , and attempts to add a new radio access via radio 2 (e.g., gNB2) . Both radio 1 and radio 2 belong to a same CN. Exemplarily, radio 1 and radio 2 may be gNBs in 3GPP network (s) . Radio 1 and radio 2 may also include other type of wireless access points.

[0049] After performing a normal registration process by using radio 1, UE stores a security context for radio 1, which may include ngKSI1, 5G-GUTI1, KAMF1, and KgNB1; AMF1 stores a security context for the UE, which may include ngKSI1, 5G-GUTI1, and KAMF1; and UDM stores parameters for radio 1 / AMF1, and a correspondence between radio 1 and AMF1. The stored context for AMF may include an AMF address. In this disclosure, an AMF address may include a parameter such as an amfInstanceId of the AMF, or a Globally Unique AMF Identifier (GUAMI) of the AMF. In this disclosure, a radio access corresponds to a wireless access point, or a radio access point. In this disclosure, unless otherwise specified, a key may be noted in following format: K+ [entity name] + [radio access number] . For example, KAMF1 denotes the key for AMF corresponding to radio access 1; KgNB2 denote the key for gNB corresponding to radio access 2.

[0050] FIG. 7 illustrates an example flow chart for a UE to add a radio 2 on top of radio 1.

[0051] Step 1: UE sends a Registration Request message (RR message) to a wireless access point 2  (as compared with wireless access point 1) , such as a base station (e.g., gNB2) , with which radio 2 access is to be established. The RR message may carry the 5G-GUTI1 of the UE, and a radio indication =add, indicating that the UE is requesting to add an access network (i.e., add radio 2) for an additional radio access. With such indication, the gNB2 may determine its role as an addition to an existing radio access. Such indication may be referred as a radio indication. In this case, the RR message may set the radio indication to “add” .

[0052] Step 2: gNB2 forwards the Registration Request message to AMF1.

[0053] Step 3: After obtaining the context of the UE based on the 5G-GUTI1 and verifying the integrity of the Registration Request message, depending on a local policy, the AMF1 may calculate a new AMF key, KAMF2, for radio 2, by using a Key Derivation Function (KDF) , such as KAMF2=KDF (DIRECTION, COUNT, and KAMF1) . The DIRECTION may be set to 0x00, COUNT may be the uplink NAS COUNT based on the radio indication and local policy. For radio 2, AMF1 allocates ngKSI2 to the UE, and stores the ngKSI2 and the KAMF2. The AMF1 calculates an integrity protection key and a ciphering key for the Non Access Stratum (NAS) by using the KAMF2, calculates a KgNB2, and sends an NAS Security Mode Command message to the UE. This message may carry the ngKSI2, and UE security capability information. This message may further carry an NAS MAC (Message Authentication Code) check value which may be calculated by using the integrity protection key of the NAS MAC. In addition, according to whether the KAMF2 is newly calculated, a K_AMF_change_flag is further carried in the message, which in this case indicates whether KAMF2 is new / changed for radio 2, as compared with KAMF1 for radio 1. Note that whether a new AMF key (KAMF2) needs to be created for adding radio 2 may depend on a local policy. For example, radio 2 may be independent with radio 1, and they may be provided by different vendors (e.g., radio 1 belongs to a PLMN, and radio 2 belong to a private network) . In this case, an AMF key may not be shared by radio 1 and radio 2, therefore a new AMF key for radio 2 (KAMF2) is required. For another example, radio 1 and radio 2 may belong to a same vendor, or different vendors with service agreement. In this case, the AMF key used for  radio 1 may be shared with radio 2 (KAMF2 does not need to be calculated) , and K_AMF_change_flag will be set to false (no change, or no need for a new calculation) . Optionally, this message may carry an explicit radio operation indication (e.g., radio indication = add, may be referred to as radio indication for simplicity) , to indicate that this operation relates to adding a new radio on top of an existing radio. In some scenarios, as the UE initiates this radio addition session, the UE may determine the radio indication based on the session context, so an explicit radio indication may not need to be carried in the message.

[0054] In some example implementations, AMF key changing flag is set based on a policy in the AMF, wherein the policy is based on at least one of: whether the target radio access and the first radio access belong to a same core network; a security level of at least one of: the target radio access and the first radio access; an application hosted by the UE and associated with the target radio access; a vertical industry policy; or a service sharing policy of at least one of: the AMF, an AMF serving the first radio access.

[0055] Step 4: The UE determines, according to the K_AMF_change_flag, whether there is a need to calculate KAMF2, or KAMF1 may be re-used as KAMF2 (i.e., radio 1 and radio 2 share the same AMF key) . The UE may calculate KAMF2 by using a same manner as the AMF1 does. UE may simultaneously calculate a corresponding integrity protection key and a corresponding ciphering key according to KAMF2, and calculate the KgNB2. UE then checks the NAS MAC by using the integrity key of the NAS. If the integrity check succeeds, UE returns an NAS Security Mode Complete message to the AMF1, where the message carries a check value NAS MAC of the integrity key of the NAS for integrity protection of the NAS Security Mode Complete message.

[0056] In this case, the UE stores a set of security parameters for each radio: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, KAMF2, KgNB2. Note that no 5G-GUTI for radio 2 has been assigned / allocated to the UE yet.

[0057] Step 5: After verifying integrity of the NAS Security Mode Complete message, the AMF1 initiates a registration procedure with the UDM. The registration request message may be,  for example, a UDM registration service message Nudm_UECM_Registration, or a newly defined UDM service message (e.g., Nudm_UECM_Add) . The message may carry an AMF1 address, a radio access identifier (or access mode) identifying the radio for the registration (in this case, radio 2) , and a radio indication indicating the registration / operation is for adding a radio identified by the radio access identifier to the UE (e.g., radio indication =add) . In this disclosure, a radio indication is an operation indication indicating whether to add, replace, update, or delete a radio.

[0058] UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2. In this case, (radio1, AMF1) and (radio2, AMF1) are stored.

[0059] Step 6: After establishing a Packet Data Network (PDN) connection for radio 2, the AMF1 allocates a 5G-GUTI2 for the UE (to be used with radio 2) and returns a Registration Accept message to the UE indicating the request for adding radio 2 is accepted. The message may carry the newly assigned 5G-GUTI2. After receiving the Registration Accept message, the UE stores the 5G-GUTI2.

[0060] At this step, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2. Note that 5G-GUTI for radio 2 is now assigned / allocated to the UE.

[0061] The AMF1 stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1; radio2: ngKSI2, 5G-GUTI2 and KAMF2.

[0062] UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2.

[0063] Step 7: The UE returns a Registration Complete message to the AMF1.

[0064] Embodiment 2: Replacing A Radio for UE Having Dual Radio Access –Same Core Network

[0065] In this embodiment, a UE already has two radio accesses, radio 1 and radio 2. UE attempts to replace radio 1 with radio 3. Radio 1 and radio 3 are in a same core network.

[0066] After the UE performs a normal registration process by using the wireless network radio 1, radio 2 is added (e.g., as other access type) by using, for example, the procedure described in embodiment 1.

[0067] In this case, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0068] The AMF1 stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1; radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0069] UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2 (radio1: AMF1 and radio2: AMF1) .

[0070] FIG. 8 shows example steps for replacing radio 1 with radio 3.

[0071] Step 1: UE sends a Registration Request message to a wireless access point for radio 3 (e.g., gNB3) , where the message carries a 5G-GUTI1 and a radio indication=replace, indicating that the UE intends to use radio 3 to replace radio 1.

[0072] Step 2: gNB3 selects the same AMF serving radio 1 (in this case, AMF1) and forward the Registration Request message to AMF1.

[0073] Step 3: After obtaining the context of the UE according to 5G-GUTI1 and verifying the integrity of the Registration Request message, the AMF1 may calculate a new AMF key, KAMF3, for radio 3, by using a KDF, such as KAMF3=KDF (DIRECTION, COUNT, and KAMF1) . The DIRECTION may be set to 0x00, COUNT may be the uplink NAS COUNT based on the radio indication and local policy. For radio 3, AMF1 may allocate ngKSI3 to the UE, and store ngKSI3 and KAMF3.

[0074] The AMF1 calculates an integrity protection key and a ciphering key for the NAS by using the KAMF3, calculates a KgNB3, and sends an NAS Security Mode Command message to the UE. This message may carry the ngKSI3, and UE security capability information. This message may further carry an NAS MAC (Message Authentication Code) check value which may be calculated by using the integrity protection key of the NAS MAC. In addition, according to whether the KAMF3 is newly calculated, a K_AMF_change_flag may be further carried in the message, which in this case indicates whether KAMF3 is new / changed for radio 3, as compared with KAMF1 for radio 1. Note that whether a new AMF key (KAMF3) needs to be created for radio 3 may depend on a local policy, the details on such local policy may be found in embodiment 1. For example, in case radio 1 and radio 3 may belonging to a same vendor, or different vendors with service agreement, the AMF key used for radio 1 may be shared with radio 3 (KAMF3 does not need to be calculated) , and K_AMF_change_flag will be set to false (no change) .

[0075] Step 4: The UE determines, according to the K_AMF_change_flag, whether there is a need to calculate KAMF3, or KAMF1 may be re-used as KAMF3 (i.e., radio 1 and radio 3 share the same AMF key) . The UE may calculate KAMF3 by using a same manner as the AMF1 does. UE may simultaneously calculate a corresponding integrity protection key and a corresponding ciphering key according to KAMF3, and calculate the KgNB3. UE then checks the NAS MAC by using the integrity key of the NAS. If the integrity check succeeds, the UE returns an NAS Security Mode Complete message to the AMF1, where the message carries a check value NAS MAC of the integrity key of the NAS for integrity protection of the NAS Security Mode Complete message.

[0076] In this case, the UE stores a set of security parameters for each radio: radio3: ngKSI3, 5G-GUTI1, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0077] Step 5: After verifying integrity of the NAS Security Mode Complete message, the AMF1 initiates a registration procedure with the UDM. The registration request message may be, for example, a UDM registration service message Nudm_UECM_Registration, or a newly defined UDM service message (e.g., Nudm_UECM_Replace) . The message may carry an  AMF1 address, and a radio indication indicating the registration / operation is for replacing radio 1 with radio 3 (e.g., radio indication = replace radio 1 with radio 3) .

[0078] The UDM may then store a record that links radio 3 with AMF1, and radio 2 with AMF1. Therefore, association between a radio and a corresponding AMF is established.

[0079] In this particular example implementation, because the AMF serving radio 3 is not changed (AMF1 also serves radio 1) , the UDM may not need to send a Nudm_UECM_DeregistrationNotification message to the AMF1 to delete the UE-related contexts.

[0080] Step 6: After establishing a PDN connection to the radio3, the AMF1 allocates a 5G-GUTI3 for the UE and returns a Registration Accept message to the UE, indicating the request for replacing radio 1 with radio 3 is accepted. The message may carry the newly assigned 5G-GUTI3. After receiving the Registration Accept message, the UE stores the 5G-GUTI3.

[0081] At this step, the UE stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0082] The AMF1 stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3; radio2: ngKSI2, 5G-GUTI2 and KAMF2.

[0083] The UDM stores (radio3, AMF1) and (radio2, AMF1) .

[0084] Step 7, the UE returns a Registration Complete message to the AMF1.

[0085] Embodiment 3: Replacing A Radio for UE Having Dual Radio Access –Different Core Network

[0086] This embodiment describes another example for replacing a radio access for a UE having dual radio accesses (radio 1 and radio 2) . Radio 1 is replaced with radio 3 and radio 3 is served by a different AMF compared with radio 1. For example, radio 1 and radio 3 are served by AMF1 and AMF3, respectively. In this embodiment, AMF3 is able to get UE  context from AMF1.

[0087] After the UE performs a normal registration process by using the wireless network radio 1, radio 2 is added (e.g., as other access type) by using, for example, the procedure described in embodiment 1.

[0088] In this case, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0089] The AMF1 stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1; radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0090] The UDM stores a record that links radio 1 with AMF1, and radio 2 with AMF1 (radio1: AMF1 and radio2: AMF1) .

[0091] FIG. 9 shows example steps for replacing radio 1 with radio 3.

[0092] Step 1: UE sends a Registration Request message to a wireless access point for radio 3 (e.g., gNB3) , where the message carries a 5G-GUTI1 and a radio indication=replace, indicating that the UE intends to use radio 3 to replace radio 1.

[0093] Step 2: gNB3 selects a different AMF (AMF3) compared with the AMF serving radio 1 (AMF1) , and forwards the Registration Request message to AMF3.

[0094] Step 3: AMF3 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating replacing radio 1 with radio 3 (e.g., radio indication=replace) .

[0095] Step 4: AMF1 retrieves the UE context based on 5G-GUTI1, verifies the integrity of the Registration Request message. Depending on a local policy, a new AMF key (compared with KAMF1) for AMF3 may be required, or the AMF key for AMF1 may be shared and  reused for AMF3. In case a new AMF key is required, the AMF1 calculates the key for AMF3 using a KDF, such as KAMF3=KDF (DIRECTION, COUNT, KAMF1) according to the radio indication and the local policy. The DIRECTION may be set to 0x00, COUNT may be the uplink NAS COUNT based on the radio indication and local policy.

[0096] AMF1 returns a response message to AMF3, such as an Namf_Communication_UEContextTransfer Resp message. The message may carry KAMF3 and a K_AMF_change_flag indicating whether the AMF key for AMF3 is changed from an existing AMF key (in this case, KAMF1 for radio 1) . In this example, as KAMF3 is derived based on KAMF1 and is different, K_AMF_change_flag is set to 1. In other example implementations, based on local policy, the key for AMF1 and AMF3 may be shared, then there is no need to derive / calculate KAMF3, and K_AMF_change_flag is set to 0.

[0097] Step 5: AMF3 allocates / assigns a new ngKSI3 to the UE, stores the ngKSI3 and KAMF3, calculates the integrity protection key and encryption key, calculates the KgNB3, and sends an NAS Security Mode Command message to the UE. The message may carry ngKSI3, UE security capability information, and a NAS MAC check value calculated by using a NAS MAC integrity protection key. The K_AMF_change_flag may also be carried, to indicate whether KAMF3 is newly derived or shared. The message may also carry a radio indication (radio indication =replace) , indicating that the network successfully replaces radio 1 with radio 3.

[0098] Step 6: The UE determines, according to the K_AMF_change_flag, whether there is a need to calculate KAMF3, or KAMF1 may be re-used as KAMF3 (i.e., radio 1 and radio 3 share the same AMF key) . The UE may calculate KAMF3 by using a same manner as the AMF3. UE may simultaneously calculate a corresponding integrity protection key and a corresponding ciphering key according to KAMF3, and calculate the KgNB3. UE then checks the NAS MAC by using the integrity key. If the integrity check succeeds, UE returns an NAS Security Mode Complete message to the AMF3, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0099] In this case, the UE stores a set of security parameters for each of radio 2 and radio 3: radio3: ngKSI3, 5G-GUTI1, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0100] The AMF3 stores following security parameters for radio 3: ngKSI3, KAMF3.

[0101] Step 7: After verifying integrity of the NAS Security Mode Complete message, the AMF3 sends an Namf_Communication_RegistrationStatusUpdate message to the AMF1, where the message carries Radio indication=replace and radio1, indicating or instructing that the parameters corresponding to radio 1 (radio1: ngKSI1, 5G-GUTI1, KAMF1) in the AMF1 should be deleted (due to radio 1 being replaced with another radio) .

[0102] At this time the AMF1 stores the security parameters for radio 2: ngKSI2, 5G-GUTI2 and KAMF2. Note that security parameters for radio 1 is deleted.

[0103] Step 8a: the AMF3 initiates a registration procedure with the UDM. The registration request message may include a Nudm_UECM_Registration message, or a newly created message (e.g., Nudm_UECM_Replace message) not yet defined in current technology. The message may carry an AMF3 address and a radio indication=replace, indicating that radio 1 is being replaced with radio 3 for the UE. The message may further indicate that there is AMF change due to radio replacement. Therefore, AMF information on UDM side needs to be updated accordingly. As a result, UDM stores a record that links radio 3 with AMF3, and radio 2 with AMF1.

[0104] In the same registration request message or via another message, AMF3 may send to the UDM the access type it provides to the UE, for example, the access type may be “3GPP access” . In this case, UDM may also store the access type in the record. For example, the record may show radio 3: AMF3 (3GPP access) . That is, radio 3 is served by AMF3 and uses 3GPP access.

[0105] Step 8b: When the UDM stores the associated Access Type (e.g., 3GPP access) together with AMF3 as indicated in step 8a, it will cause the UDM to initiate a de-registration procedure  with AMF1, such that AMF1 will de-register the UE’s radio access with the same access type. For example, for this UE, AMF1 will de-register radio 1 which has same access type (3GPP access) , and remove the UE context associated with radio 1. The de-registation procedure may be achieved via a Nudm_UECM_DeregistrationNotification message to AMF1, and the message may carry an indication of radio 1.

[0106] After the de-registration, AMF1 stores radio2: ngKSI2, KAMF2, and the record for radio 1 is deleted.

[0107] Step 9: After established the PDN connection for radio 3, the AMF3 allocates an 5G-GUTI3 for the UE, and returns a Registration Accept message to the UE, carrying the 5G-GUTI3. After receiving the Registration Accept message, the UE stores the 5G-GUTI3.

[0108] At this step, the UE stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0109] The AMF1 stores radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0110] The AMF3 stores radio3: ngKSI3, 5G-GUTI3, KAMF3.

[0111] Step 10: the UE return Registration Complete messages to AMF3.

[0112] Embodiment 4: Replacing A Radio for UE Having Dual Radio Access –Different Core Network

[0113] This embodiment describes another example for replacing a radio access for a UE having dual radio accesses (radio 1 and radio 2) . Radio 1 is replaced with radio 3 and radio 3 is attached to or associated with a different AMF compared with radio 1. For example, radio 1 and radio 3 are served by AMF1 and AMF3, respectively. In this embodiment, AMF3 is not able to get UE context from AMF1.

[0114] FIGs. 10a-10b show example steps for replacing radio 1 with radio 3.

[0115] Step 1: UE sends a Registration Request message to a wireless access point for radio 3 (e.g.,  gNB3) , where the message carries a 5G-GUTI1 and a radio indication=replace, indicating that the UE intends to use radio 3 to replace radio 1.

[0116] Step 2: gNB3 selects a different AMF (AMF3) compared with the AMF serving radio 1 (AMF1) , and forwards the Registration Request message to AMF3.

[0117] Step 3: AMF3 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating replacing radio 1 with radio 3 (e.g., radio indication=replace) .

[0118] Step 4: AMF1 returns a Namf_Communication_UEContextTransfer Resp message to the AMF3 if the AMF1 fails to find the context of the UE based on the 5G-GUTI1. The message may carry the failure cause. Alternatively, AMF1 may not send back any response, for example, due to a link disconnection, or AMF3 is not permitted to obtain the UE context from the AMF1 based on a local policy. The local policy may be slice isolation or a vertical industry security policy.

[0119] Step 5: AMF3 sends an Identity Request message to the UE, where the message carries the acquired user identifier type about Subscription Concealed Identifier (SUCI) , and the message may further carry a radio indication=replace.

[0120] Step 6: UE returns an Identity Response message to AMF3, where the message carries the SUCI.

[0121] From step 7 to step 14, a UE primary authentication is performed.

[0122] Step 7: AMF3 selects an AUSF on the home network according to the mobile country codes (MCCs) , mobile network code (MNCs) , and the routing indicator in the SUCI, and sends a Nausf_UEAuthentication_Authenticate Request message to the AUSF, where the message carries the SUCI and a Service Network Name.

[0123] Step 8: The AUSF selects UDMs based on the SUCI, and the AUSF sends Nudm_UEAuthentication_Get Request to the UDM. The message carries the SUCI and the Service Network Name.

[0124] Step 9: UDM uses the private key to decrypt the SUCI to obtain an SUPI, and selects an authentication method 5G-AKA (5G Authentication and Key Agreement) (or an EAP-AKA'-Improved Extensible Authentication Protocol Method for Authentication and Key Agreement, or another manner, description below using the 5G-AKA as an example) according to the SUPI. The UDM will then compute CK'a nd IK'a nd replace CK and IK by CK'a nd IK' (that is, UDM update cipher key CK and integrity key IK) . The UDM will then return the 5G HE AV (5G Home Environment Authentication Vector) to the AUSF together with an indication that the 5G HE AV is to be used for 5G AKA in a Nudm_UEAuthentication_Get Response. In case SUCI was included in the Nudm_UEAuthentication_Get Request, UDM will include the SUPI in the Nudm_UEAuthentication_Get Response after de-concealment of SUCI by SIDF.

[0125] Step 10: The AUSF stores the XRES*temporarily together with the received SUCI or SUPI. The AUSF shall then generate the 5G AV from the 5G HE AV received from the UDM by computing the HXRES*from XRES*and KSEAF from KAUSF, and replacing the XRES*with the HXRES*and KAUSF with KSEAF in the 5G HE AV. The AUSF may then remove the KSEAF and return the 5G SE AV (RAND, AUTN, HXRES*) to the AMF3 in a Nausf_UEAuthentication_Authenticate Response.

[0126] Step 11: AMF3 sends RAND, AUTN to the UE in a NAS message Authentication Request. This message may also include the ngKSI3 that will be used by the UE and AMF3 to identify the KAMF3 and the partial native security context that is created if the authentication is successful. This message shall also include the ABBA parameter.

[0127] Step 12: The ME may forward the RAND and AUTN received in NAS message Authentication Request to the USIM. At receipt of the RAND and AUTN, the USIM shall verify the freshness of the received values by checking whether AUTN can be accepted. If so,  the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then shall compute RES*from RES. The ME then calculates KAUSF from CK||IK. The ME shall calculate KSEAF from KAUSF. An ME accessing 5G shall check during authentication that the "separation bit" in the AMF field of AUTN is set to 1. The "separation bit" is bit 0 of the AMF field of AUTN. The UE returns RES*to the AMF3 in a NAS message Authentication Response.

[0128] Step 13: AMF3 may then compute HRES*from RES*, and the AMF3 may compare HRES*and HXRES*. If they coincide, the AMF3 considers the authentication successful from the serving network point of view. The AMF3 may send RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF.

[0129] Step 14: When the AUSF receives as authentication confirmation the Nausf_UEAuthentication_Authenticate Request message including a RES*it may verify whether the 5G AV has expired. If the 5G AV has expired, the AUSF may consider the authentication as unsuccessful from the home network point of view. Upon successful authentication, the AUSF stores the KAUSF based on the home network operator's policy. AUSF shall compare the received RES*with the stored XRES*. If the RES*and XRES*are equal, the AUSF may consider the authentication as successful from the home network point of view. AUSF shall inform UDM about the authentication result. The may shall indicate to the AMF3 in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful or not from the home network point of view. If the authentication was successful, the KSEAF may be sent to the SEAF in the Nausf_UEAuthentication_Authenticate Response. If the authentication was successful, then the AUSF may also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.

[0130] Step 15: AMF3 uses the KSEAF to calculate the KAMF3, uses the KAMF3 to calculate the integrity protection key and encryption key, calculates the KgNB3, and sends an NAS Security  Mode Command message to the UE. The message carries an ngKSI3, UE security capability information, and a NAS MAC check value calculated by using a NAS integrity protection key. The radio indication =replace may also be carried, indicating that the operation is for replacing radio 1 with radio 3 and / or that the network successfully replaces radio 1 with radio 3.

[0131] Step 16: UE calculates the KAMF3 by using the KSEAF, calculates the corresponding integrity protection key and encryption key at the same time according to the KAMF3, calculates the KgNB3, and checks the NAS MAC by using the integrity key. If the integrity check succeeds, the NAS Security Mode Complete message is returned to the AMF1, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0132] In this case, the UE stores a set of security parameters for each radio: radio3: ngKSI3, 5G-GUTI1, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0133] AMF3 stores following security parameters for radio 3: ngKSI3, KAMF3.

[0134] Step 17a: After successfully verifying integrity of the NAS Security Mode Complete message, the AMF3 initiates a registration procedure to the UDM. The registration request message may include a Nudm_UECM_Registration message, or a newly created message (e.g., Nudm_UECM_Replace message) not yet defined in current technology. The message may carry an AMF3 address and a radio indication=replace, indicating that radio 1 is being replaced with radio 3 for the UE. The message may further indicate that there is AMF change due to radio replacement. Therefore, AMF information on UDM side needs to be updated accordingly. As a result, UDM stores a record that links radio 3 with AMF3, and radio 2 with AMF1.

[0135] Step 17b: After AMF3 has successfully completed the Nudm_UECM_Registration operation and if AMF3 does not have subscription data for the UE, AMF3 retrieves the Access and Mobility Subscription data, SMF Selection Subscription data, UE context in SMF data and LCS mobile origination using Nudm_SDM_Get. If the AMF3 already has subscription data  for the UE, but the Steering of Roaming (SoR) Update Indicator in the UE context requires the AMF3 to retrieve SoR information depending on the NAS Registration Type ( "Initial Registration" or "Emergency Registration" ) , the AMF3 retrieves the Steering of Roaming information using, for example, Nudm_SDM_Get. Note that UDM may retrieve SoR information from UDR by Nudr_DM_Query.

[0136] Step 17c: After a successful response is received, AMF3 subscribes with UDM in order to be notified when the data requested is modified using Nudm_SDM_Subscribe. UDM may subscribe to UDR by using Nudr_DM_Subscribe. The Generic Public Subscription Identifier (GPSI) is provided to AMF3 in the Access and Mobility Subscription data from the UDM if the GPSI is available in the UE subscription data.

[0137] The AMF3 provides the Access Type it serves for the UE (for radio 3) to the UDM and the Access Type may be set to, for example, "3GPP access” .

[0138] Step 17d: In previous step, AMF3 provides the Access Type to UDM. When the UDM stores the associated Access Type (e.g., 3GPP access) together with AMF3, it will cause the UDM to initiate a de-registration procedure with AMF1, such that AMF1 will de-register the UE’s radio access with the same access type. For example, for this UE, AMF1 will de-register radio 1 which has same access type (3GPP access) , and remove the UE context associated with radio 1. The de-registration procedure may be achieved via a Nudm_UECM_DeregistrationNotification message to AMF1, and the message may carry an indication of radio 1.

[0139] After the de-registration, AMF1 stores radio2: ngKSI2, KAMF2, and the record for radio 1 is deleted.

[0140] Step 17e: (optional) If AMF1 does not have UE context for another access type (e.g., non-3GPP access) , the AMF1 unsubscribes with the UDM for subscription data using Nudm_SDM_unsubscribe.

[0141] Till now, UDM stores parameters for radio 3 / AMF3, radio 2 / AMF1, and a  correspondence between radio 3 and AMF3, radio 2 and AMF1.

[0142] Step 18: After established the PDN connection for the radio 3, AMF3 allocates a 5G-GUTI3 corresponding to radio 3 for the UE, and returns a Registration Accept message to the UE, carrying the 5G-GUTI3. After receiving the Registration Accept message, the UE stores the 5G-GUTI3.

[0143] At this step, the UE stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0144] The AMF1 stores radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0145] The AMF3 stores radio3: ngKSI3, 5G-GUTI3, KAMF3.

[0146] Step 19: UE return Registration Complete messages to the AMF3.

[0147] Embodiment 5: Adding A Radio for UE –Different Core Network

[0148] In this embodiment, a UE already has a radio access via radio 1 (e.g., gNB1) , and attempts to add a new radio access via radio 2 (e.g., gNB2) . Radio 1 and radio 2 belong to different core networks and are served by AMF1 (e.g., core network 1) and AMF2 (e.g., core network 2) , respectively. In this embodiment, AMF2 is able to get UE context from AMF1.

[0149] After performing a normal registration process by using radio 1, UE stores a security context for radio 1, which may include ngKSI1, 5G-GUTI1, KAMF1, and KgNB1; AMF1 stores a security context for the UE, which may include ngKSI1, 5G-GUTI1, and KAMF1; and UDM stores a record that links radio 1 with AMF1. For example, the record may include correspondence between radio 1 and AMF1 address / identifier.

[0150] FIG. 11 shows example steps for adding a radio 2 access for the UE.

[0151] Step 1: UE sends a Registration Request message to a wireless access point 2 (as compared with wireless access point 1) , such as a base station (e.g., gNB2) , with which radio 2 access is to be established. The RR message may carry the 5G-GUTI1 of the UE, and a radio  indication =add, indicating that the UE is requesting to add an access network (i.e., add radio 2) for an additional radio access. With such indication, the gNB2 may determine its role as an addition to an existing radio access. Such indication may be referred as a radio indication. In this case, the RR message may set the radio indication to “add” . This message may further carry an indication of existing radio access –radio 1.

[0152] Step 2: gNB2 forwards the Registration Request message to the AMF2.

[0153] Step 3: AMF2 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating adding radio 2 (e.g., radio indication=add) .

[0154] Step 4: AMF1 retrieves the UE context based on 5G-GUTI1, verifies the integrity of the Registration Request message. Depending on a local policy, a new AMF key (compared with KAMF1) for AMF2 may be required, or the AMF key for AMF1 may be shared and reused for AMF2. In case a new AMF key is required, the AMF1 calculates the key for AMF2 using a KDF, such as KAMF2=KDF (DIRECTION, COUNT, KAMF1) according to the radio indication and the local policy. The DIRECTION may be set to 0x00, COUNT may be the uplink NAS COUNT based on the radio indication and local policy.

[0155] AMF1 returns a response message to AMF2, such as an Namf_Communication_UEContextTransfer Resp message. The message may carry KAMF2 and a K_AMF_change_flag indicating whether the AMF key for AMF2 is changed from an existing AMF key (in this case, KAMF1 for radio 1) . In this example, as KAMF2 is derived based on KAMF1 and is different, K_AMF_change_flag is set to 1. In other example implementations, based on local policy, the key for AMF1 and AMF2 may be shared, then there is no need to derive / calculate KAMF2, and K_AMF_change_flag is set to 0.

[0156] Step 5: AMF2 allocates / assigns a new ngKSI2 to the UE, stores the ngKSI2 and KAMF2, calculates the integrity protection key and encryption key by using the KAMF2, calculates the  KgNB2, and sends an NAS Security Mode Command message to the UE. The message may carry ngKSI2, UE security capability information, and a NAS MAC check value calculated by using a NAS MAC integrity protection key of the NAS MAC. The K_AMF_change_flag may also be carried, to indicate whether KAMF2 is newly derived or can be shared. The message may also carry a radio indication (radio indication =add) , indicating that the network successfully add radio 2.

[0157] Step 6: The UE determines, according to the K_AMF_change_flag, whether there is a need to calculate KAMF2, or KAMF1 may be re-used as KAMF2 (i.e., radio 1 and radio 2 share the same AMF key) . The UE may calculate KAMF2 by using a same manner as the AMF1. UE may simultaneously calculate a corresponding integrity protection key and a corresponding ciphering key according to KAMF2, and calculate the KgNB2. UE then checks the NAS MAC by using the integrity key. If the integrity check succeeds, UE returns an NAS Security Mode Complete message to the AMF2, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0158] In this case, the UE stores a set of security parameters for each of radio 1 and radio 2: radio1: ngKSI1, 5G-GUTI1, KAM1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0159] The AMF1 stores following security parameters for radio 1: ngKSI1, KAMF1. AMF2 stores following security parameters for radio 2: ngKSI2, KAMF2.

[0160] Step 7: After verifying integrity of the NAS Security Mode Complete message, the AMF1 initiates a registration procedure with the UDM. The registration request message may be, for example, a UDM registration service message Nudm_UECM_Registration, or a newly defined UDM service message (e.g., Nudm_UECM_Add) . The message may carry an AMF2 address, a radio access identifier (or access mode) identifying the radio for the registration (in this case, radio 2) , and a radio indication indicating the registration / operation is for adding a radio identified by the radio access identifier to the UE (e.g., radio indication =add) .

[0161] At this step, The UDM stores (radio1, AMF1) and (radio2, AMF2) .

[0162] Step 8: After establishing a PDN connection for radio 2, the AMF2 allocates a 5G-GUTI2 for the UE and returns a Registration Accept message to the UE indicating the request for adding radio 2 is accepted. The message may carry the newly assigned 5G-GUTI2. After receiving the Registration Accept message, the UE stores the 5G-GUTI2.

[0163] At this step, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0164] The AMF1 stores one set of parameters for radio1: ngKSI1, 5G-GUTI1, KAMF1; The AMF1 stores one set of parameters for radio2: ngKSI2, 5G-GUTI2, and KAMF2.

[0165] The UDM stores (radio1, AMF1) and (radio2, AMF1) .

[0166] Step 9, the UE returns a Registration Complete message to the AMF2.

[0167] Embodiment 6: Adding A Radio for UE –Different Core Network

[0168] In this embodiment, a UE already has a radio access via radio 1 (e.g., gNB1) , and attempts to add a new radio access via radio 2 (e.g., gNB2) . Radio 1 and radio 2 belong to different core networks and are served by AMF1 (core network 1) and AMF2 (core network 2) , respectively. In this embodiment, AMF2 is not able to get UE context from AMF1.

[0169] After performing a normal registration process by using radio 1, UE stores a security context for radio 1, which may include ngKSI1, 5G-GUTI1, KAMF1, and KgNB1; AMF1 stores a security context for the UE, which may include ngKSI1, 5G-GUTI1, and KAMF1; and UDM stores a record that links radio 1 with AMF1. For example, the record may include correspondence between radio 1 and AMF1 address / identifier.

[0170] FIGs. 12a-12b show example steps for adding a radio 2 access for the UE.

[0171] Step 1: UE sends a Registration Request message to a wireless access point 2 (as compared with wireless access point 1) , such as a base station (e.g., gNB2) , with which radio 2 access is  to be established. The RR message may carry the 5G-GUTI1 of the UE, and a radio indication =add, indicating that the UE is requesting to add an access network (i.e., add radio 2) for an additional radio access. With such indication, the gNB2 may determine its role as an addition to an existing radio access. Such indication may be referred as a radio indication. In this case, the RR message may set the radio indication to “add” . This message may further carry an indication of existing radio access –radio 1.

[0172] Step 2: gNB2 forwards the Registration Request message to the AMF2.

[0173] Step 3: AMF2 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating adding radio 2 (e.g., radio indication=add) .

[0174] Step 4: AMF1 returns a Namf_Communication_UEContextTransfer Resp message to the AMF2 if the AMF1 fails to find the context of the UE based on the 5G-GUTI1. The message may carry the failure cause. Alternatively, AMF1 may not send back any response, for example, due to a link disconnection, or AMF2 is not permitted to obtain the UE context from the AMF1 based on a local policy. The local policy may be slice isolation or a vertical industry security policy.

[0175] Step 5: AMF2 sends an Identity Request message to the UE, where the message carries the acquired user identifier type about SUCI, and the message may further carry a radio indication=add.

[0176] Step 6: UE returns an Identity Response message to AMF2, where the message carries the SUCI.

[0177] Steps 7 to 14: a UE primary authentication is performed. The primary authentication is similar to the primary authentication as described in embodiment 4, steps 7-14, except AMF3 in steps 7-14 of embodiment 4 is replaced with AMF2. That is, AMF2 is involved in the primary authentication in the current embodiment. The detailed description for the primary  authentication is thus skipped herein.

[0178] Step 15: AMF2 uses the KSEAF to calculate the KAMF2, uses the KAMF2 to calculate the integrity protection key and encryption key, calculates the KgNB2, and sends an NAS Security Mode Command message to the UE. The message carries an ngKSI2, UE security capability information, and a NAS MAC check value calculated by using a NAS integrity protection key. The radio indication =add may be carried, indicating that the operation is for adding radio 2 and / or that the network successfully adds radio 2.

[0179] Step 16: UE calculates the KAMF2 by using the KSEAF, calculates the corresponding integrity protection key and encryption key at the same time according to the KAMF2, calculates the KgNB2, and checks the NAS MAC by using the integrity key. If the integrity check succeeds, the NAS Security Mode Complete message is returned to the AMF2, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0180] In this case, the UE stores a set of security parameters for each radio: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, KAMF2, KgNB2.

[0181] AMF2 stores following security parameters for radio 2: ngKSI2, KAMF2.

[0182] Step 17a: After successfully verifying integrity of the NAS Security Mode Complete message, the AMF2 initiates a registration procedure to the UDM. The registration request message may include a Nudm_UECM_Registration message, or a newly created message (e.g., Nudm_UECM_Add message) not yet defined in current technology. The message may carry an AMF2 address and a radio indication=add, indicating that radio 2 is being added for the UE. UDM stores a record that links radio 1 with AMF1, and radio 2 with AMF2.

[0183] Step 17b: After AMF2 has successfully completed the Nudm_UECM_Registration operation and if AMF2 does not have subscription data for the UE, AMF2 retrieves the Access and Mobility Subscription data, SMF Selection Subscription data, UE context in SMF data and LCS mobile origination using Nudm_SDM_Get. If the AMF2 already has subscription data for the UE, but the Steering of Roaming (SoR) Update Indicator in the UE context requires  the AMF2 to retrieve SoR information depending on the NAS Registration Type ( "Initial Registration" or "Emergency Registration" ) , the AMF2 retrieves the Steering of Roaming information using, for example, Nudm_SDM_Get. Note that UDM may retrieve SoR information from UDR by Nudr_DM_Query.

[0184] Step 17c: After a successful response is received, AMF2 subscribes with UDM in order to be notified when the data requested is modified using Nudm_SDM_Subscribe. UDM may subscribe to UDR by using Nudr_DM_Subscribe. The

[0185] GPSI is provided to AMF2 in the Access and Mobility Subscription data from the UDM if the GPSI is available in the UE subscription data.

[0186] The AMF2 may provide the Access Type it serves for the UE (for radio 2) to the UDM and the Access Type may be set to, for example, "3GPP access” .

[0187] Till now, UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2.

[0188] Step 18: After established the PDN connection for the radio 2, AMF2 allocates a 5G-GUTI2 corresponding to radio 2 for the UE, and returns a Registration Accept message to the UE, carrying the 5G-GUTI2. After receiving the Registration Accept message, the UE stores the 5G-GUTI2 (which is allocated / assigned for radio 2) .

[0189] At this step, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0190] The AMF1 stores radio1: ngKSI1, 5G-GUTI1, KAMF1.

[0191] The AMF2 stores radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0192] Step 19: UE return Registration Complete messages to the AMF2.

[0193] Embodiment 7: Replacing A Radio for UE Having Dual Radio Access –Different Core Network

[0194] This embodiment describes another example for replacing a radio access for a UE having dual radio accesses (radio 1 and radio 2) . In this example, radio 1 and radio 2 are served by different AMFs (e.g., AMF1 and AMF2) . Radio 1 is replaced with radio 3 which is served by a different AMF compared with radio 1 and radio 2 (e.g., AMF3) . In this embodiment, AMF3 is able to get UE context from AMF1.

[0195] After the UE performs a normal registration process by using the wireless network radio 1, radio 2 is added (e.g., as a same or another access type) by using, for example, the procedure described in embodiment 5 or 6.

[0196] In this case, the UE stores two sets of parameters: radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0197] AMF1 stores one set of parameters for radio1: ngKSI1, 5G-GUTI1, KAMF1.

[0198] AMF2 stores one set of parameters for radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0199] UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2.

[0200] FIG. 13 shows example steps for replacing radio 1 with radio 3.

[0201] Step 1: UE sends a Registration Request message to a wireless access point for radio 3 (e.g., gNB3) , where the message carries a 5G-GUTI1 and a radio indication=replace, indicating that the UE intends to use radio 3 to replace radio 1.

[0202] Step 2: gNB3 selects a different AMF (AMF3) compared with the AMF serving radio 1 (AMF1) , and forwards the Registration Request message to AMF3.

[0203] Step 3: AMF3 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating replacing radio 1 with radio 3 (e.g., radio  indication=replace) .

[0204] Step 4: AMF1 retrieves the UE context based on 5G-GUTI1, verifies the integrity of the Registration Request message. Depending on a local policy, a new AMF key (compared with KAMF1) for AMF3 may be required, or the AMF key for AMF1 may be shared and reused for AMF3. In case a new AMF key is required, the AMF1 calculates the key for AMF3 using a KDF, such as KAMF3=KDF (DIRECTION, COUNT, KAMF1) according to the radio indication and the local policy. The DIRECTION may be set to 0x00, COUNT may be the uplink NAS COUNT based on the radio indication and local policy.

[0205] AMF1 returns a response message to AMF3, such as an Namf_Communication_UEContextTransfer Resp message. The message may carry KAMF3 and a K_AMF_change_flag indicating whether the AMF key for AMF3 is changed from an existing AMF key (in this case, KAMF1 for radio 1) . In this example, as KAMF3 is derived based on KAMF1 and is different, K_AMF_change_flag is set to 1.

[0206] In other example implementations, based on local policy, the key for AMF1 and AMF3 may be shared, then there is no need to derive / calculate KAMF3, and K_AMF_change_flag is set to 0.

[0207] Step 5: For radio 3, AMF3 allocates / assigns a new ngKSI3 to the UE, stores the ngKSI3 and KAMF3, calculates the integrity protection key and encryption key, calculates the KgNB3, and sends an NAS Security Mode Command message to the UE. The message may carry ngKSI3, UE security capability information, and a NAS MAC check value calculated by using a NAS MAC integrity protection key. The K_AMF_change_flag may also be carried, to indicate whether KAMF3 is newly derived or shared. The message may also carry a radio indication (radio indication =replace) , indicating that the network successfully replaces radio 1 with radio 3.

[0208] Step 6: The UE determines, according to the K_AMF_change_flag, whether there is a need to calculate KAMF3, or KAMF1 may be re-used as KAMF3 (i.e., radio 1 and radio 3 share the same  AMF key) . The UE may calculate KAMF3 by using a same manner as the AMF3. UE may simultaneously calculate a corresponding integrity protection key and a corresponding ciphering key according to KAMF3, and calculate the KgNB3. UE then checks the NAS MAC by using the integrity key. If the integrity check succeeds, UE returns an NAS Security Mode Complete message to the AMF3, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0209] In this case, the UE stores a set of security parameters for each of radio 2 and radio 3: radio3: ngKSI3, 5G-GUTI1, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0210] The AMF3 stores following security parameters for radio 3: ngKSI3, KAMF3.

[0211] Step 7: After verifying integrity of the NAS Security Mode Complete message, the AMF3 sends an Namf_Communication_RegistrationStatusUpdate message to the AMF1, where the message carries Radio indication=replace and radio1, indicating or instructing that the parameters corresponding to radio 1 (radio1: ngKSI1, 5G-GUTI1, KAMF1) in the AMF1 should be deleted (due to radio 1 being replaced with another radio) .

[0212] At this time the AMF1 deletes security parameters for radio 1, therefore AMF1 does not have any security context for the UE.

[0213] Step 8a: the AMF3 initiates a registration procedure with the UDM. The registration request message may include, for example, a Nudm_UECM_Registration message, or a newly created message (e.g., Nudm_UECM_Replace message) not yet defined in current technology. The message may carry an AMF3 address and a radio indication=replace, indicating that radio 1 is being replaced with radio 3 for the UE. The message may further indicate that there is AMF change due to radio replacement. Therefore, AMF information on UDM side needs to be updated accordingly.

[0214] As a result, in the UDM, context for radio 3 is added and context for radio 1 is deleted. UDM now stores parameters for radio 2 / AMF2, radio 3 / AMF3, and a  correspondence between radio 2 and AMF2, radio 3 and AMF3.

[0215] In the same registration request message or via another message, AMF3 may send to the UDM the access type it provides to the UE, for example, the access type may be “3GPP access” . In this case, UDM may also store the access type in the record. For example, the record may indicate radio 3: AMF3 (3GPP access) .

[0216] Step 8b: This step provides an alternative for AMF1 cleanup after radio 1 is replaced, and may be skipped if AMF1 cleanup is performed in step 7.

[0217] When the UDM stores the associated Access Type (e.g., 3GPP access) together with AMF3 as indicated in step 8a, it will cause the UDM to initiate a de-registration procedure with AMF1, such that AMF1 will de-register the UE’s radio access with the same access type. For example, for this UE, AMF1 will de-register radio 1 which has same access type (3GPP access) , and remove the UE context associated with radio 1. The de-registation procedure may be achieved via a Nudm_UECM_DeregistrationNotification message to AMF1, and the message may carry an indication of radio 1.

[0218] After the de-registration, AMF1 does not have any security context for the UE.

[0219] Step 9: After established the PDN connection for radio 3, the AMF3 allocates an 5G-GUTI3 for the UE, and returns a Registration Accept message to the UE, carrying the 5G-GUTI3. After receiving the Registration Accept message, the UE stores the 5G-GUTI3.

[0220] At this step, the UE stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0221] The AMF2 stores radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0222] The AMF3 stores radio3: ngKSI3, 5G-GUTI3, KAMF3.

[0223] Step 10: the UE return Registration Complete messages to AMF3.

[0224] Embodiment 8: Replacing A Radio for UE Having Dual Radio Access –Different Core Network

[0225] This embodiment describes another example for replacing a radio access for a UE having dual radio accesses (radio 1 and radio 2) . In this example, radio 1 and radio 2 are served by different AMFs (e.g., AMF1 and AMF2) . Radio 1 is replaced with radio 3 which is served by a different AMF compared with radio 1 and radio 2 (e.g., AMF3) . In this embodiment, AMF3 is not able to get UE context from AMF1.

[0226] After performing a normal registration process by using radio 1 (e.g., gNB1) , radio 2 is added as a new access type by using, for example, the procedure described in embodiment 5 or 6.

[0227] In this case, the UE stores the UE stores two sets of parameters -radio1: ngKSI1, 5G-GUTI1, KAMF1, KgNB1; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0228] AMF1 stores a set of parameters for radio 1 -radio1: ngKSI1, 5G-GUTI1, KAMF1.

[0229] AMF2 stores a set of parameters for radio 2 –radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0230] UDM stores parameters for radio 1 / AMF1, radio 2 / AMF2, and a correspondence between radio 1 and AMF1, radio 2 and AMF2.

[0231] Note that records stored in AMF / UDM as mentioned above are in a UE level.

[0232] FIGs. 14a-14b show example steps for replacing radio 1 with radio 3.

[0233] Step 1: UE sends a Registration Request message to a wireless access point for radio 3 (e.g., gNB3) , where the message carries a 5G-GUTI1 and a radio indication=replace, indicating that the UE intends to use radio 3 to replace radio 1.

[0234] Step 2: gNB3 selects a different AMF (AMF3) compared with the AMF serving radio 1 (AMF1) , and forwards the Registration Request message to AMF3.

[0235] Step 3: AMF3 determines the AMF serving radio 1 (AMF1) according to the 5G-GUTI1, and  sends a message, such as an Namf_Communication_UEContextTransfer message, to AMF1 requesting UE context transfer, where the message may carry the 5G-GUTI1, and may further carry a radio indication indicating replacing radio 1 with radio 3 (e.g., radio indication=replace) .

[0236] Step 4: AMF1 returns a Namf_Communication_UEContextTransfer Resp message to the AMF3 if the AMF1 fails to find the context of the UE based on the 5G-GUTI1. The message may carry the failure cause. Alternatively, AMF1 may not send back any response, for example, due to a link disconnection, or AMF3 is not permitted to obtain the UE context from the AMF1 based on a local policy. The local policy may be slice isolation or a industry security policy.

[0237] Step 5: AMF3 sends an Identity Request message to the UE, where the message carries the acquired user identifier type about SUCI, and the message may further carry a radio indication=replace.

[0238] Step 6: UE returns an Identity Response message to AMF3, where the message carries the SUCI.

[0239] Steps 7 to 14: A UE primary authentication is performed. The primary authentication is similar to the primary authentication as described in embodiment 4, steps 7-14. The detailed description for the primary authentication is thus skipped herein.

[0240] Step 15: AMF3 uses the KSEAF to calculate the KAMF3, uses the KAMF3 to calculate the integrity protection key and encryption key, calculates the KgNB3, and sends an NAS Security Mode Command message to the UE. The message carries an ngKSI3, UE security capability information, and a NAS MAC check value calculated by using a NAS integrity protection key. The radio indication =replace may be carried, indicating that the operation is for replacing radio 1 with radio 3 and / or that the network successfully replaces radio 1 with radio 3.

[0241] Step 16: UE calculates the KAMF3 by using the KSEAF, calculates the corresponding integrity  protection key and encryption key at the same time according to the KAMF3, calculates the KgNB3, and checks the NAS MAC by using the integrity key. If the integrity check succeeds, the NAS Security Mode Complete message is returned to the AMF1, where the message carries a check value NAS MAC for integrity protection by using the integrity key.

[0242] In this case, the UE stores a set of security parameters for each radio: radio3: ngKSI3, 5G-GUTI1, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0243] AMF3 stores following security parameters for radio 3: ngKSI3, KAMF3.

[0244] Step 17a: After successfully verifying integrity of the NAS Security Mode Complete message, the AMF3 initiates a registration procedure to the UDM. The registration request message may include a Nudm_UECM_Registration message, or a newly created message (e.g., Nudm_UECM_Replace message) not yet defined in current technology. The message may carry an AMF3 address and a radio indication=replace, indicating that radio 1 is being replaced with radio 3 for the UE. The message may further indicate that there is AMF change due to radio replacement (i.e., AMF3 is used for radio 3) . Therefore, AMF information on UDM side needs to be updated accordingly. As a result, UDM stores a record that links radio 3 with AMF3, and radio 2 with AMF2.

[0245] Step 17b: After AMF3 has successfully completed the Nudm_UECM_Registration operation and if AMF3 does not have subscription data for the UE, AMF3 retrieves the Access and Mobility Subscription data, SMF Selection Subscription data, UE context in SMF data and LCS mobile origination using Nudm_SDM_Get. If the AMF3 already has subscription data for the UE, but the Steering of Roaming (SoR) Update Indicator in the UE context requires the AMF3 to retrieve SoR information depending on the NAS Registration Type ( "Initial Registration" or "Emergency Registration" ) , the AMF3 retrieves the Steering of Roaming information using, for example, Nudm_SDM_Get. Note that UDM may retrieve SoR information from UDR by Nudr_DM_Query.

[0246] Step 17c: After a successful response is received, AMF3 subscribes with UDM in order to be  notified when the data requested is modified using Nudm_SDM_Subscribe. UDM may subscribe to UDR by using Nudr_DM_Subscribe. The Generic Public Subscription Identifier (GPSI) is provided to AMF3 in the Access and Mobility Subscription data from the UDM if the GPSI is available in the UE subscription data.

[0247] The AMF3 provides the Access Type it serves for the UE (for radio 3) to the UDM and the Access Type may be set to, for example, "3GPP access” .

[0248] Step 17d: In previous step, AMF3 provides the Access Type to UDM. When the UDM stores the associated Access Type (e.g., 3GPP access) together with AMF3, it will cause the UDM to initiate a de-registration procedure with AMF1, such that AMF1 will de-register the UE’s radio access with the same access type. For example, for this UE, AMF1 will de-register radio 1 which has same access type (3GPP access) , and remove the UE context associated with radio 1. The de-registration procedure may be achieved via a Nudm_UECM_DeregistrationNotification message to AMF1, and the message may carry an indication of radio 1.

[0249] In some example implementations, in step 17d, UE may identify the radio to be replace based on access type. For example, the de-registration message may carry the access type for UE’s reference.

[0250] In some example implementations, in step 17d, UE may identify the radio to be replace based on an identifier of the radio access, such as radio 1.

[0251] In some example implementations, UE may identify the radio to be replace based on the session context, as the UE itself imitates the session as illustrated in FIGs. 14a-14b.

[0252] After the de-registration, AMF1 no longer has a context for the UE (as the context associated with radio 1 is deleted) .

[0253] Step 17e: (optional) If AMF1 does not have UE context for another access type (e.g., non-3GPP access) , the AMF1 unsubscribes with the UDM for subscription data using  Nudm_SDM_unsubscribe.

[0254] Till now, UDM stores parameters for radio 3 / AMF3, radio 2 / AMF2, and a correspondence between radio 3 and AMF3, radio 2 and AMF2.

[0255] Step 18: After established the PDN connection for the radio 3, AMF3 allocates a 5G-GUTI3 corresponding to radio 3 for the UE, and returns a Registration Accept message to the UE, carrying the 5G-GUTI3. After receiving the Registration Accept message, the UE stores the 5G-GUTI3.

[0256] At this step, the UE stores two sets of parameters: radio3: ngKSI3, 5G-GUTI3, KAMF3, KgNB3; radio2: ngKSI2, 5G-GUTI2, KAMF2, KgNB2.

[0257] The AMF1 has no UE context for the UE.

[0258] The AMF2 stores radio2: ngKSI2, 5G-GUTI2, KAMF2.

[0259] The AMF3 stores radio3: ngKSI3, 5G-GUTI3, KAMF3.

[0260] Step 19: UE return Registration Complete messages to the AMF3.

[0261] In this disclosure, a UE may choose to add a radio access or replace a radio access based on various considerations including at least one of: a UE preference which may include, for example, a service fee preference; a data speed preference; a service quality preference; or a network preference; a service requirement of an application running on the wireless device; a UE capability; a security requirement of the UE; or a service agreement between the UE and vendor (s) , service provider (s) .

[0262] In this disclosure, message types and / or message names (e.g., as shown in FIGs. 7-14b) are for exemplary purpose only. Different message types and / or message names may be chosen in implementation, and should still be covered by this disclosure, as far as the underlying principle is the same, for example, if the messages are used for a same purpose.

[0263] In this disclosure, a single message may be split into multiple sub-messages. Multiple messages may also be combined and sent in one message.

[0264] In this disclosure, a single information element in a message may be split into multiple information elements. Multiple information element may also be combined into a single information element.

[0265] In this disclosure, the steps in each embodiment are for illustration purposes only and other alternatives may be derived based on the disclosed embodiments as desired. For example, only part of the steps may need to be performed. For another example, the sequence of the steps may be adjusted. For another example, several steps may be combined (e.g., several messages may be combined in one message) . For another example, a single step may be split (e.g., one message may be sent via two sub-messages) . For another example, embodiments (or portions of embodiments) may be combined, if there is no conflict.

[0266] The accompanying drawings and description above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0267] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

[0268] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0269] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0270] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method for wireless communication, performed by a wireless device, the method comprising:transmitting, to a first network element, a first message requesting a radio access operation, wherein the wireless device is connected to a network via at least one radio access, and wherein the radio access operation comprises one of: an add operation for adding a target radio access; or a replace operation for replacing a first radio access of the at least one radio access with a target radio access; andadding a target UE security context associated with the target radio access, the target UE security context comprising at least one of: a Key Set Identifier (KSI) associated with the target radio access; a target Access and Mobility Management Function (AMF) key associated with an AMF serving the target radio access; a key associated with the first network element; or an identifier of the wireless device assigned by a second network element.2.The method of claim 1, wherein each of the first radio access and the target radio access belongs to a corresponding radio access category, wherein a radio access category comprises:a 3rd Generation Partnership Project (3GPP) radio access;a Public Land Mobile Network (PLMN) radio access;a private network radio access;a Wireless Local Area Network (WLAN) radio access; ora Wireless Fidelity (WiFi) radio access.3.The method of claim 2, wherein the first radio access and the target radio access  belong to a same radio access category or a different radio access category.4.The method of claim 1, wherein the at least one radio access comprises the first radio access and a second radio access, the method further comprising:in response to the radio access operation being the replace operation, deleting a UE security context associated with the first radio access.5.The method of claim 1, wherein before adding the target UE security context, the method further comprises:receiving, from the AMF, a second message comprising at least one of:the KSI associated with the target radio access;UE security capability information of the wireless device; oran AMF key changing flag indicating whether the target AMF key needs to be calculated by the wireless device.6.The method of claim 5, wherein the AMF key changing flag is set based on a policy in the AMF, wherein the policy is based on at least one of:whether the target radio access and the first radio access belong to a same core network;a security level of at least one of: the target radio access and the first radio access;an application hosted by the wireless device and associated with the target radio access;a vertical industry policy; ora service sharing policy of at least one of: the AMF, an AMF serving the first radio access.7.The method of claim 5, further comprising:in response to the AMF key changing flag indicating that the target AMF key needs to be calculated, calculating the target AMF key using a key derivation function; andderiving the key associated with the first network element, wherein the key associated with the first network element is also derived by the AMF.8.The method of claim 5, further comprising:in response to the AMF key changing flag indicating that the target AMF key does not need to be calculated, using an AMF key associated with the first radio access as the target AMF key.9.The method of claim 5, wherein the second message comprises a Non-Access Stratum (NAS) security mode command.10.The method of claim 1, further comprising:receiving, from the second network element, a third message indicating that the radio access operation is successful and carrying the identifier of the UE.11.The method of claim 10, wherein:the third message comprises a registration accept message;the second network element comprises an Access and Mobility Management Function (AMF) ; andthe identifier of the UE comprises a 5G Global Unique Temporary Identifier (5G-GUTI) .12.The method of claim 1, wherein the first radio access and the target radio access belong to a same core network, the first radio access is served by the AMF serving the target radio access.13.The method of claim 1, wherein the first radio access and the target radio access belong to a same core network, and an AMF serving the first radio access being different from the AMF serving the target radio access.14.The method of claim 1, wherein the first radio access and the target radio access belong to different core networks, and an AMF serving the first radio access being different from the AMF serving the target radio access.15.The method of claim 14, wherein:the first message comprises a first registration request message;in response to receiving the first registration request message, the first network element sends a second registration request message to the AMF serving the target radio access, the second registration request message being based on the first registration request message; andin response to receiving the second registration request message, the AMF serving the target radio access requests UE context associated with the target radio access from the AMF serving the first radio access.16.The method of claim 1, wherein the first network element comprises a wireless access point, the wireless access point comprising at least one of:a base station comprising one of: a gNodeB (gNB) , an eNodeB (eNB) , an ng-eNodeB (ng-eNB) ; or a NodeB; ora wireless access point to a WLAN or a Wi-Fi network.17.The method of claim 1, wherein the first message comprises a registration message.18.The method of claim 1, further comprising determining the radio access operation based on at least one of:a preference of the wireless device, the preference comprising at least one of: a service fee preference; a data speed preference; a service quality preference; or a network preference;a service requirement of an application running on the wireless device;a security requirement of the wireless device;a capability of the wireless device; ora service agreement of the wireless device.19.A method for wireless communication, performed by a first network element, the method comprising:receiving, from a second network element serving a target radio access for a wireless device, a first message requesting a radio access operation, wherein the wireless device is connected to a network via at least one radio access, and wherein the radio access operation comprises one of: an add operation for adding the target radio access; or a replace operation for replacing a first radio access of the at least one radio access with the target radio access, the first message carrying an identifier of the wireless device associated with the first radio access; andtransmitting, to the wireless device, a second message comprising at least one of:a Key Set Identifier (KSI) associated with the target radio access;UE security capability information of the wireless device; oran AMF key changing flag indicating whether a target AMF key associated with the first network element for the target radio access needs to be updated.20.The method of claim 19, wherein:the first network element serves both the first radio access and the target radio access; andthe method further comprises deriving the target AMF key based on an AMF key associated with first network element for the first radio access.21.The method of claim 19, wherein:the first network element serves the target radio access;a third network element different from the first network element serves the first radio access; andthe method further comprises:transmitting, to the third network element, a UE context request for requesting UE context of the wireless device.22.The method of claim 21, wherein each of the first network element and the second  network element comprises an AMF.23.The method of claim 21, further comprising:receiving, from the third network element, a UE context request response message, the UE context request response message comprising at least one of:the target AMF key; orthe AMF key changing flag,wherein the target AMF key is derived by the third network element.24.The method of claim 21, further comprising:receiving, from the third network element, a UE context request response message indicating a UE context request failure;transmitting an identity request to the wireless device to request an identity of the wireless device;receiving an identity response from the wireless device, the identity response carrying a Subscription Concealed Identifier (SUCI) of the wireless device;performing a primary authentication procedure for the wireless device based on the SUCI, to obtain a Security Anchor Function (SEAF) key for deriving the target AMF key; andderiving the target AMF key based on the SEAF key.25.The method of claim 24, wherein the UE context request failure is based on a policy in the third network element, wherein the policy is based on at least one of:whether the target radio access and the first radio access belonging to a same core network;a security level of at least one of: the target radio access and the first radio access;an application hosted by the wireless device and associated with the target radio access;a vertical industry policy; ora service sharing policy of at least one of: the first network element; or the third network element.26.The method of claim 19, further comprising:transmitting, to a Unified Data Management (UDM) , a registration message registering the first network element as an entity serving the target radio access.27.The method of claim 26, wherein:the at least one radio access comprises the first radio access and a second radio access;the radio access operation is the replace operation;the registration message indicates that the first radio access is to be replaced by the target radio access;the registration message carries a radio indicator that indicates the first radio access via at least one of: an identifier of the first radio access; or a radio access type of the first radio access; andthe registration message triggers the UDM to de-register a third network element as a serving entity for the first radio access, wherein the third network element comprises an AMF.28.The method of claim 27, wherein a de-registration of the third network element as the serving entity for the first radio access triggers the third network element to delete its UE context for the first radio access.29.The method of claim 19, further comprising:allocating an identifier for the wireless device associated with the target radio access; andtransmitting, to the wireless device, a third message indicating the radio access operation is successful, the third message carrying the identifier for the wireless device associated with the target radio access.30.The method of claim 29, wherein the identifier for the wireless device associated with the target radio access comprises a 5G Global Unique Temporary Identifier (5G-GUTI) assigned for the target radio access.31.The method of claim 29, further comprising storing a UE context associated with the target radio access, the UE context comprising at least one of:the identifier of the wireless device;the KSI associated with the target radio access; orthe target AMF key.32.The method of any of claims 19-31, wherein the second network element comprises a wireless access point, the wireless access point comprising at least one of:a base station comprising one of: a gNodeB (gNB) , an eNodeB (eNB) , an ng-eNodeB (ng-eNB) ; or a NodeB; ora wireless access point to a WLAN or a Wi-Fi network.33.The method of any of claims 19-31, wherein the first NE comprises an AMF.34.A device comprising a memory for storing computer instructions and a processor in communication with the memory, wherein the processor, when executing the computer instructions, is configured to implement a method in any one of claims 1-33.35.A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of any one of claims 1-33.

Images