Method, device and system for AKMA roaming control in communication networks

Abstract

This disclosure generally relates to enabling AKMA in wireless communication. Performed by first network element, the method includes: receiving, from a second network element, a first message carrying at least one of: a SUPI of a wireless device; a SUCI of the wireless device; or a Serving Network (SN) name of an SN serving the wireless device; and determining whether an AKMA service is allowed for the wireless device in the SN.

Description

METHOD, DEVICE AND SYSTEM FOR AKMA ROAMING CONTROL IN COMMUNICATION NETWORKSTECHNICAL FIELD

[0001] This disclosure relates to wireless communication, and in particular, to verifying and enabling AKMA (Authentication and Key Management for Applications) service in a wireless communication network, such as 4G, 5G, and 6G wireless communication network.BACKGROUND

[0002] In a communication network, the mutual authentication of a User Equipment (UE) and the communication network may be performed to allow only authenticated UE and the authenticated communication network to communicate with each other. Application Function (AF) entities may provide various application services to the UE once authenticated. Efficient and robust authentication mechanism involving various network elements is critical to provide secure communication between Application Function entity and the UE, and to protect the credentials of the UE and the Application Function entity.SUMMARY

[0003] This disclosure discloses methods, systems, devices, and storage medium relates to wireless communication, and in particular, to determining whether AKMA service may be employed in a wireless communication network, such as 4G, 5G, and 6G wireless communication network, when a UE is roaming.

[0004] 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, a first message carrying at least one of: a Subscription Permanent Identifier (SUPI) of a wireless device; a Subscription Concealed Identifier (SUCI) of the wireless device; or a Serving Network (SN) name of an SN serving the wireless device;  and determining whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in the SN.

[0005] In another embodiment, a method for wireless communication is disclosed. Performed by a first network element, the method includes: transmitting, to a second network element, a first message carrying at least one of: a Subscription Permanent Identifier (SUPI) of a wireless device; a Subscription Concealed Identifier (SUCI) of the wireless device; or a Serving Network (SN) name of an SN serving the wireless device, wherein the SN name is used by the second network element to determine whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in the SN.

[0006] In another embodiment, a method for wireless communication is disclosed. Performed by a first network element, the method includes: receiving, from a second network element, a first message for registering a wireless device, the first message carrying a Globally Unique AMF Identifier (GUAMI) of the second network element; and determining, based on the GUAMI, whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in a Serving Network (SN) serving the wireless device.

[0007] 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.

[0008] 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.

[0009] 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

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

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

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

[0013] FIG. 4 shows an exemplary network model for implementing an AKMA framework.

[0014] FIG. 5 shows an example wireless network node (or network element, network function, network entity, entity, application function) .

[0015] FIG. 6 shows an example user equipment.

[0016] FIG. 7 shows an exemplary key hierarchy under the AKMA framework.

[0017] FIG. 8 shows an exemplary logic flow for establishing an application session between a UE and an AF, including deriving AKMA application key for the AF.

[0018] FIG. 9 shows an exemplary logic flow for deriving KAKMA after a primary authentication.

[0019] FIG. 10 shows an exemplary logic flow for primary authentication according to an embodiment with AKMA service permission check.

[0020] FIG. 11 shows an exemplary logic flow for AKMA service permission check when UE is in a handover procedure.

[0021] FIG. 12 shows another exemplary logic flow for AKMA service permission check when UE is in a handover procedure.

[0022] FIG. 13 shows another exemplary logic flow for primary authentication according to an embodiment with AKMA service permission check.

[0023] FIG. 14 shows an exemplary logic flow for AKMA service permission check when UE is in a handover procedure and a re-authentication is required.

[0024] FIG. 15 shows an exemplary logic flow for a primary authentication with AMKA check and the primary authentication is triggered by a registration request.

[0025] FIG. 16 shows an exemplary dual registration scenario.DETAILED DESCRIPTION

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] AKMA Framework

[0038] 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.

[0039] FIG. 4 illustrates an exemplary network model 400 for implementing an AKMA framework. This model includes various network elements. Each network element may be implemented as a physical entity, or a logical entity providing a particular set of network functions. A logical entity may be based on software, hardware, firmware, of any combination thereof. For example, a logical entity may include a server providing the function. For another example, a logical entity may be implemented based on cloud-based service or platform, such as Software as a service (SaaS) , Platform as a service (PaaS) , etc.

[0040] The AKMA Anchor Function (AAnF) 412 provides a security anchor function in the HPLMN. The AAnF stores the AKMA Anchor Key (KAKMA) for AKMA service associated with UE 424, which is received from the Authentication Server Function (AUSF) 416 after the UE 424 completes a successful primary authentication. The AAnF may also generate the key material to be used between the UE and the Application Function (AF) 420 and maintains UE AKMA context (also referred to as AKMA security context) .

[0041] The AF 420 may provide application service to the UE. Under the AKMA  framework, the AF may request for its AKMA Application Key, denoted as KAF, from the AAnF using an identifier for the KAKMA. The identifier may include an AKMA Key Identifier (A-KID) . The AAnF may only provide the KAF to the AF after the AF is authenticated and authorized by the operator network. The AF may be located inside or outside the operator's network. In this disclosure, for simplicity, the AKMA Application Key (denoted as KAF, or KAF) may also be referred to as the AF key.

[0042] In some example implementations, the A-KID may include: A-TID (AKMA Temporary UE Identifier) , and HN-ID (identity of home network) . A-KID identifies the KAKMA key of the UE. A-KID may be in a Network Access Identifier (NAI) format, i.e., username@realm. Specifically, the username part may include the Routing Identifier (RID) of the UE and the AKMA Temporary UE Identifier (A-TID) , and the realm part may include Home Network Identifier.

[0043] A-TID may be derived from KAUSF and SUPI (Subscription Permanent Identifier) of the UE. For example, A-TID = KDF ( "A-TID" , SUPI, KAUSF) , where KDF is the key derivation function.

[0044] The Network Exposure Function (NEF) 410 may be configured to enable and authorize external AFs to access the AKMA service and forward the AKMA service request towards the AAnF. The NEF may also perform the AAnF selection in case there are multiple AAnFs.

[0045] The AUSF 416 may provide the Subscription Permanent Identifier (SUPI) and AKMA key material (e.g., A-KID, KAKMA) of the UE to the AAnF. The AUSF may also perform the AAnF selection.

[0046] The UDM may store AKMA subscription data of the subscriber (or the UE subscribed to the wireless communication network) .

[0047] Referring to FIG. 4, various interfaces may be involved in the AKMA framework. These interfaces may include Nnef, Naanf, Nudm, Uausf, and Namf and may be referred to  as Service Based Interface (SBI) , as each interface corresponds to a service provided by a network element. For example, Nnef represnets the SBI utilized by the NEF; Naanf represents the SBI utilized by the AAnF; and Nudm represents the SBI utilized by the UDM. The network elements may interact with each other via the various SBIs. The SBI may provide security protection. For example, the SBI may be confidentiality, integrity and replay protected.

[0048] FIG. 4 shows the implementation where the AAnF is deployed as a standalone function. Other deployment options may be chosen. For example, the AAnF may be co-located with the AUSF, or the AAnF may be co-located with the NEF.

[0049] FIG. 5 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.

[0050] 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.

[0051] 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.

[0052] FIG. 6 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.

[0053] Referring to FIG. 6, 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.

[0054] Referring to FIG. 6, 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.

[0055] Under the AKMA framework, there may be various keys involved, and these keys may be organized in a hierarchical structure as shown in FIG. 7. The example key hierarchy  of FIG. 7 may include the following keys at different level: KAUSF, KAKMA, and KAF. These keys may be derived and stored in parallel on both the network side and the Mobile Equipment (ME) side. The ME refers to a portion of a UE along with other portions of UE such as a Universal Subscriber Identity Module (USIM) .

[0056] After a successful primary authentication between the UE and the wireless communication network (e.g., UE authenticated by the operator) , the AUSF and / or the UE may derive the KAUSF based on an Integrity Key (IK) of the UE, and a Cipher Key (CK) of the UE. AUSF may alternatively derive the KAUSF based on a transformation of the Integrity Key (denoted as IK') of the UE, and a transformation of the Cipher Key (denoted as CK') of the UE.

[0057] Based on the KAUSF, the ME and the AUSF may each derive the KAKMA based on the KAUSF, and the SUPI of the UE, by using a Key Derivation Function (KDF) . Note that KAKMA is UE specific.

[0058] Then based on the KAKMA, the ME and the AAnF may each derive the KAF based on the KAKMA, and an identifier of the AF, also similarly by using a KDF. It is to be noted that a UE may store multiple KAF, each corresponding to an AF. Likewise, an AF may store multiple KAF, each corresponding to a UE.

[0059] The various keys described herein may each have a lifetime. For example, the KAKMA may be refreshed until the next successful primary authentication. For another example, the KAF may be provisioned with a lifetime (or expiration time) , for example, by the AAnF. In some embodiments, the lifetime of a key may be associated with a timer, such that the timer is started once a key is commissioned, and once the timer expires, the key is refreshed.

[0060] In a wireless communication network, a UE may subscribe to various application services from an AF. When invoking services provided by the AF, secure communication link needs to be established and maintained. An encryption key may be used to encrypt the data flow between the UE and the AF. Depending on use case scenarios, different key may  be selected.

[0061] In one scenario, the UE is roaming in a VPLMN, and needs to invoke application service from an AF in its HPLMN. AKMA application key (KAF) may be used for encryption. Alternatively, an encryption key derived or transformed from KAF may be used.

[0062] In another scenario, the UE is roaming in a VPLMN, and needs to invoke application service from an AF in a data network external to the HPLMN and VPLMN. In this case, KAF, encryption key derived from KAF may be used. The AF may also choose its own encryption key which is independent of KAF.

[0063] The above scenarios impose special challenges to regulatory control. When a UE is roaming in a VPLMN, AKMA service may or may not be allowed. Therefore, new mechanisms need to be implemented with consideration of whether the AKMA service is allowed or not. These new mechanisms should engage checks to determine the AKMA service eligibility before enabling the related procedures, ensuring adherence to regulatory controls in roaming scenarios.

[0064] In this disclosure, various embodiments are described, aiming to add AKMA service check in various scenarios.

[0065] Deriving AKMA Application Key for an AF

[0066] In this embodiment, before UE can start communication with an AF (e.g., start an application session, a Packet Data Unit (PDU) session, etc. ) , the UE may need to finish a primary authentication with the network.

[0067] FIG. 8 illustrates an example flow chart for an AF to request application function specific AKMA keys from an AAnF. An exemplary method may include a portion or all of the following steps.

[0068] Step 1: UE may generate the AKMA Anchor Key (KAKMA, or KAKMA) and the A-KID (AKMA Key Identifier) from the KAUSF before initiating communication with the AF. When the UE initiates communication with the AF, it may include the derived A-KID in the  Application Session Establishment Request message. The UE may derive KAF (also denoted as KAF) before or after sending the message.

[0069] Step 2: If the AF does not have a context, or an active context associated with the A-KID, the AF may select an AAnF, and send a message, such as an Naanf_AKMA_ApplicationKey_Get request message to AAnF with the A-KID, to request the KAF for the UE. The AF may also include its identity (AF_ID) in the request message.

[0070] In some example implementations, the AF_ID may include the Fully Qualified Domain Name (FQDN) of the AF and a security protocol identifier that the AF will use with the UE. As an example, the security protocol may include a Ua*security protocol.

[0071] In some example implementations, the AAnF may check whether the AAnF can provide the service to the AF based on, for example, the configured local policy, or the authorization information available in the signaling (e.g., Oauth2.0 token) . If the check fails, the AAnF may reject the request.

[0072] If the check succeeds, the AAnF may further verify whether the UE (subscriber) is authorized to use AKMA based on the presence of the UE specific KAKMA key identified by the A-KID.

[0073] If KAKMA is present in AAnF, the AAnF may continue with step 3.

[0074] If KAKMA is not present in the AAnF, the AAnF may continue with step 6 with an error response.

[0075] Step 3: After receiving the Application Session Establishment Request from the AF, if according to its local policy, the AAnF determines that this specific AF needs the Generic Public Subscription Identifier (GPSI) of the UE, the AAnF may send a request, such as an Nudm_SDM_Get Request message to the UDM, to fetch the GPSI of the UE. If the specific AF does not need GPSI, the AAnF may continue with step 5.

[0076] Step 4: The UDM responds with the GPSI of the UE. The AAnF may then store the received GPSI as part of UE’s AKMA context.

[0077] Step 5: The AAnF may derive the AKMA Application Key (KAF, or KAF) from KAKMA if it does not already have KAF.

[0078] Step 6: The AAnF may send a response message, such as an Naanf_AKMA_ApplicationKey_Get response to the AF with at least one of: SUPI / GPSI of the UE, KAF, or the KAF expiration time. In some example implementations, whether to send SUPI or GPSI may be determined by AAnF based on its local policy.

[0079] If there is a failure in this step, AAnF may send a response message indicating the failure, and the response message may further carry a failure cause.

[0080] Step 7: The AF may send a response, such as an Application Session Establishment Response message to the UE. If there is failure in step 6 (e.g., when handling AKMA key request) , the AF may reject the Application Session Establishment by including a failure cause. Afterwards, UE may trigger a new Application Session Establishment request with the latest A-KID to the AF.

[0081] Local Breakout (LBO) Roaming UE

[0082] When a UE roams in a visited network (e.g., a VPLMN) , end to end (e2e) traffic delay may be an important factor to consider for certain type of application, such as delay-sensitive applications, which may include, for example, vehicle-to-vehicle (V2V) communications, vehicle-to-everything (V2X) communications, machine-type communications, etc. Local breakout (LBO) is a technique that may be implemented to reduce end to end delay. In LBO, the core network can be bypassed for local packets, thereby avoiding additional transport delay and cost associated with backhauling traffic to the home network.

[0083] In some example implementations, an LBO roaming UE may have dual accesses / connections simultaneously. For example, UE may connect to a VPLMN via a 3GPP access, and simultaneously connect to its HPLMN via a Non-3GPP access. When the UE establishes an application session, such as a Packet Data Unit (PDU) session via the  3GPP access, the AMF / SMF of the VPLMN is selected, and the application session is treated as a roaming session. Whereas when the UE establishes an application session via a Non-3GPP access, AMF / SMF of the HPLMN is selected, and the application session is treated as a non-roaming session.

[0084] Embodiments in this disclosure apply to a UE operating in LBO mode and having dual accesses –one via its HPLMN, and another via a VPLMN. These embodiments also apply to UE operating in other modes and having dual accesses.

[0085] UE Dual Registration

[0086] In this disclosure, a UE may have dual registrations with the network (s) . FIG. 16 shows an exemplary dual registration scenario. In this example, the UE has a 3GPP access and a non 3GPP access to the network (s) . The UE connects to a gNB (or other types of base station) using a 3GPP access, and connects to a Non-3GPP Interworking Function (N3IWF) using a non 3GPP access. In some example implementations, the two accesses may connect to two different AMFs (e.g., AMF1 and AMF2 as shown in FIG. 16) . In some example implementations, the two accesses may connect to a same AMF. In some example implementations, the two accesses belong to a same PLMN, and the serving network for the UE is the same. In some other example implementations, the two accesses belong to two different PLMNs (e.g., a HPLMN and a VPLMN) , and there are two different serving networks serving the UE. In some example implementations, it is possible that both accesses are 3GPP accesses.

[0087] The AMF (s) may connect to a UDM, which may maintain a UE context, including the specific AMF associated with each registration. Each AMF may be identified by, for example, a Globally Unique AMF Identifier (GUAMI) of the AMF.

[0088] Embodiment 1: Deriving AKMA key after primary authentication

[0089] In some example implementations, no separate authentication of the UE is needed to support AKMA functionality. AKMA may reuse the 5G primary authentication  procedure executed during, for example, a UE registration, to authenticate the UE. A successful 5G primary authentication results in KAUSF (or noted as KAUSF) being securely stored at both the AUSF and the UE. FIG. 9 shows an exemplary procedure to derive KAKMA after a successful primary authentication.

[0090] Step 1: During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication information such as subscription credentials (e.g., Authentication and Key Agreement (AKA) Authentication vectors) and the authentication method using the Nudm_UEAuthentication_Get Request service operation. The Nudm_UEAuthentication_Get Request may carry SUPI or SUCI of the UE.

[0091] Step 2: In the response, the UDM may include an AKMA indication which indicates to the AUSF whether the AKMA Anchor key needs to be generated for the UE. If the AKMA indication is included, the UDM may also include the RID of the UE.

[0092] Step 3: If the AUSF receives the AKMA indication from the UDM, the AUSF will store the AUSF key, KAUSF, and generate the AKMA Anchor Key (KAKMA) and the A-KID from KAUSF after the primary authentication procedure is successfully completed.

[0093] The UE will generate its AKMA Anchor Key (KAKMA) and the A-KID from the KAUSF before initiating communication with an AKMA Application Function (i.e., AF support or is capable of using AKMA service) .

[0094] Step 4: After AKMA key material is generated, the AUSF may select an AAnF, and send the generated A-KID and KAKMA to the AAnF together with the SUPI of the UE using the Naanf_AKMA_KeyRegistration Request service operation. The AAnF shall store the latest information sent by the AUSF.

[0095] In some example implementations, the AUSF does not need to store any AKMA key material after delivery to the AAnF.

[0096] During a re-authentication procedure, the AUSF may generate a new A-KID, as  well as a new KAKMA, and send the newly generated A-KID and KAKMA to the AAnF. After receiving the newly generated A-KID and KAKMA, the AAnF may update its security context by deleting the old A-KID and KAKMA, and storing the newly generated A-KID and KAKMA.

[0097] 5) The AAnF sends the response to the AUSF using the Naanf_AKMA_AnchorKey_Register Response service operation.

[0098] In this embodiment, the AUSF may use the RID received from the UDM as described in step 2 to derive A-KID, and generate KAKMA based on KAUSF. As KAKMA and A-TID in A-KID are both derived from KAUSF which is acquired from the primary authentication, this implies that the KAKMA and A-KID can only be refreshed by a new successful primary authentication.

[0099] Embodiment 2: Checking AKMA Service for Roaming UE in Primary Authentication

[0100] In this embodiment, a UE is roaming in a visitor network, (e.g., UE is served by a VPLMN) . In this case, the Serving Network (SN) of the UE is in the VPLMN. When the UE performs primary authentication with the network, additional check needs to be performed by the UDM, to check whether AKMA service is allowed when the UE is roaming. This check by the UDM aims to assess whether the security protection offered by the AKMA framework can be utilized for the roaming UE or if certain restrictions apply based on the roaming agreements and policies.

[0101] As the UE is roaming in the VPLMN (served by a serving network that is in the VPLMN) , although AKMA protection is preferred due to the enhanced security it provides, the AKMA service (i.e., using security protection provided under the AKMA framework) may or may not be allowed or supported between the UE and various network elements, such as the AF responsible for providing application services. For example, a roaming policy does not grant UE with AKMA service while roaming, or the roaming policy does not grant AKMA service to the particular application running on the UE, or the roaming policy does  not allow roaming service for the UE in the VPLMN at all. In this case, roaming agreement checking is performed first, to determine whether the AKMA service is allowed based on, for example, the roaming policy (or regulatory policy, etc. ) associated with the UE. The exemplary steps of a primary authentication procedure for a roaming UE are described in details below with reference to FIG. 10. An exemplary method may include a portion or all of the following steps.

[0102] Step 1: During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication information, such as subscription credentials (e.g., AKA Authentication vectors) , authentication method, etc. The AUSF may send a request, such as an Nudm_UEAuthentication_Get Request message to the UDM. The request may include at least one of: the SUPI of the UE, the SUCI (Subscription Concealed Identifier) of the UE, or the Serving Network (SN) name of UE’s serving network.

[0103] Step 2: Based on the SN name, the UDM may determine the serving network (SN) for the UE. Note that the UE initiates the current primary authentication via the SN. If the SN of the UE is located in a roaming network (e.g., a VPLMN) , then the UDM may further check if the UE is allowed to use AKMA service while roaming in the roaming network. The check may be based on, for example, a local policy which may include, for example, a roaming agreement, a regulatory control policy for the UE, or an AKMA policy.

[0104] The check may be performed at various levels. For example, the check may be performed at the SN level (i.e., whether UE is allowed to use AKMA service in the whole SN) . The check may also be performed at an AF level, that is, within the same SN, UE is allowed to use AKMA service with some AFs but is not allowed to use AKMA service with other AFs.

[0105] In some example implementations, the UE may have a dual registration (e.g., as shown in FIG. 16) . In this case, if any one of the networks (for dual registration) does not comply with the regulatory control for AKMA service, then the current serving network is considered as not satisfying the roaming agreement for AKMA service.

[0106] Based on the AKMA service permission check result, subsequent steps may have two branches, with a first branch handling the scenario that AKMA service is allowed, and a second branch handling the scenario that AKMA service is not allowed.

[0107] The first branch switches back to FIG. 9 and starts at step 2 in FIG. 9. That is, UDM may respond to the AUSF with, for example, an Nudm_UEAuthentication_Get response message (as a response to the Nudm_UEAuthentication_Get Request message in FIG. 10 step 1) . The response message may carry an AKMA indicator and the RID of the UE. Note that the AKMA indicator and the RID may serve as an implicit indicator indicating that AKMA service is allowed, as these two parameters may trigger the AUSF to conduct further AKMA context derivation / generation. As shown in FIG. 9, in step 3a, the AUSF generates the KAKMA key, while in step 3b, it generates the A-KID. The remaining steps under the first branch are described in detail as part of Embodiment 1, and are skipped here for the sake of simplicity.

[0108] The steps described below correspond to the second branch, which is the scenario where the AKMA service is not allowed.

[0109] Step 3: The UDM may respond to the AUSF with, for example, an Nudm_UEAuthentication_Get response message. The response message does not include the AKMA indication and the RID of the UE. The message may include an Authentication Vector (AV) .

[0110] In this step, as the AKMA indication and RID are not sent to the AUSF, this serves as an implicit indication to AUSF that the AKMA service is not allowed. Upon receiving this response message, the AUSF will not proceed to generate KAKMA for the UE and the corresponding A-KID, and AKMA service will not be used.

[0111] Step 4: As the UE is not allowed to use AKMA service in the serving network, the UDM may proceed to perform some additional clean up tasks related to AKMA service. Specifically, the UDM may send a message, such as an Naanf_AKMA_Context_Remove  request message to the AAnF, to request the AAnF to delete AKMA context associated with the UE. The request message may carry an identifier of the UE, such as the SUPI. This helps to free up memory and / or storage resources at the AAnF by purging the AKMA context when the AKMA service is not permitted for the UE in the serving network.

[0112] Step 5: The AAnF, upon receiving the request message for purging AKMA context for the UE, may further request AF (s) associated with the UE to delete its AKMA context specific to the UE. The AAnF may send a notification to the AF via, for example, an Naanf_AKMA_ServiceDisableNotification message carrying the A-KID. The AF may be addressed by its Uniform Resource Identifier (URI) or its ID. In some example implementations, the UE may have previous interactions with an AF, and the AF may register itself with the AAnF using its URI or its ID. The AAnF may have its internal mechanism to keep track the binding of the UE and the AF.

[0113] Step 6: Based on the notification, the AF may stop the AKMA service of the UE, and / or delete the AKMA context associated with the A-KID. The AF sends a response back to the AAnF.

[0114] Step 7: AAnF deletes AKMA Context associated with the UE (e.g., SUPI, A-KID and KAKMA) from its local database identified by SUPI of the UE. AAnF may further send an Naanf_AKMA_Context_Remove response to UDM, to acknowledge the AKMA context removal request.

[0115] Embodiment 3: Checking AKMA Service during UE Mobility -without Primary Authentication

[0116] In this embodiment, when a UE roams from one network to another network, or is handed over from one network to another network, the UE initiates a registration procedure with the network, and the registration procedure will not invoke a primary authentication procedure. Similar to embodiment 2, the UDM will perform extra check to determine whether AKMA service is allowed for the UE in the serving network (i.e., the network UE  roams to, or handed over to) .

[0117] The exemplary steps of the registration procedure are described in details below with reference to FIG. 11. An exemplary method may include a portion or all of the following steps.

[0118] Step 1: UE sends a registration request to the AMF, to register with the core network.

[0119] Step 2: The AMF sends an Nudm_UECM_Registration message to UDM carrying the Globally Unique AMF Identifier (GUAMI) of the AMF.

[0120] Step 3: The GUAMI is a concatenation of the PLMN identity and the AMF identifier. For example, <GUAMI> = <MCC><MNC><AMF Identifier> (MCC: Mobile Country Code;

[0121] MNC: Mobile Network Code) . Based on the GUAMI, the UDM is able to determine the serving network (SN) for the UE from which the registration request is sent.

[0122] If the SN of the UE is located in a roaming network (e.g., a VPLMN) , then the UDM may further check if the UE is allowed to use AKMA service while roaming in the roaming network. The check may be based on, for example, a local policy which may include a roaming agreement, a regulatory control policy for the UE, or an AKMA policy.

[0123] The check may be at various levels. For example, the check may be performed at the SN level (i.e., UE is allowed or not allowed to use AKMA service in the whole SN) . The check may also be performed at an AF level, that is, within the same SN, UE is allowed to use AKMA service with some AFs but is not allowed to use AKMA service with other AFs.

[0124] In some example implementations, the UE may have a dual registration (e.g., as shown in FIG. 16) . In this case, if any one of the networks for dual registration does not comply with the regulatory control for AKMA service, then the current serving network is considered as not satisfying the roaming agreement for AKMA service.

[0125] Step 4: The UDM sends an Nudm_UECM_Registration response message to the AMF.

[0126] Depending on the AKMA service check result in step 3, if AKMA service is allowed for the UE in the SN, then the remaining steps in this embodiment may be skipped. The remaining steps are only required if AKMA service is not allowed for the UE.

[0127] Step 5: As the UE is not allowed to use AKMA service in the serving network, the UDM may proceed to perform some clean up tasks related to AKMA service. The clean up tasks may ensure that AKMA service will not be granted to the UE. Specifically, the UDM may send a message, such as an Naanf_AKMA_Context_Remove request message to the AAnF, to request the AAnF to delete AKMA context associated with the UE. The request message may carry an identifier of the UE, such as the SUPI. This helps to free up memory and / or storage resources at the AAnF by purging the AKMA context when the AKMA service is not permitted for the UE in the serving network.

[0128] Step 6: The AAnF, upon receiving the request message for purging AKMA context for the UE, may further request AF (s) associated with the UE to delete its AKMA context specific to the UE. The AAnF may send a notification to the AF via, for example, an Naanf_AKMA_ServiceDisableNotification message carrying the A-KID. The AF may be addressed by its Uniform Resource Identifier (URI) or its ID. In some example implementations, the UE may have previous interactions with an AF, and the AF may register itself with the AAnF using its URI or its ID. The AAnF may have its internal mechanism to keep track the binding of the UE and the AF.

[0129] Step 7: Based on the notification, the AF may stop the AKMA service of the UE, and / or delete the AKMA context associated with the A-KID. The AF sends a response back to the AAnF.

[0130] Step 8: AAnF deletes AKMA Context associated with the UE (e.g., SUPI, A-KID and KAKMA) from its local database identified by SUPI of the UE. AAnF may further send an Naanf_AKMA_Context_Remove response to UDM, to acknowledge the AKMA context removal request.

[0131] In this embodiment, when the UE initiates a registration with the network, if AKMA service is not allowed in the serving network of the UE, the AKMA context related to the UE is deleted from AAnF and AF, and AF may further stop AKMA service for the UE. By this implementation, even the UE updates / refreshes its AKMA context (on UE side) , the AKMA service will still be blocked by the core network, as network side AKMA context is deleted (no matching AKMA context) .

[0132] Embodiment 4: Checking AKMA Service during UE Mobility -with Primary Authentication

[0133] In this embodiment, when a UE roams from one network to another network, or is handed over from one network to another network, the UE initiates a registration procedure with the network, and the registration procedure will further trigger a primary authentication procedure. As part of the primary authentication, there are steps to check whether AKMA service is allowed for the UE in the serving network (i.e., the network UE roams to, or handed over to) .

[0134] The exemplary steps of the registration procedure are described in details below with reference to FIG. 12. An exemplary method may include a portion or all of the following steps.

[0135] Step 1a: UE sends a registration request to the AMF, to register with the core network.

[0136] Step 1b: A primary authentication with AKMA service check may be triggered by, for example, the AMF. The detailed description for the primary authentication with AKMA check may be found in embodiment 2, which is omitted herein for the sake of simplicity.

[0137] Step 2: AMF proceeds to send a registration message, such as an Nudm_UECM_Registration message to the UDM. The registration message may carry GUAMI of the AMF.

[0138] After the primary authentication, there are two options:

[0139] Option 1: The procedure will follow existing wireless technology, such the procedure as defined in 3GPP TS 23.502, v18.4.0, section 4.2.2.2.2. For example, the procedure may continue at step 14b in section 4.2.2.2.2.

[0140] In this option, the UDM will not perform further check on whether AKMA service is allowed for the UE in the serving network.

[0141] Option 2: The UDM will still perform check on whether AKMA service is allowed for the UE in the serving network, adding an extra layer of security.

[0142] Steps 3-8 focus on option 2, and are corresponding to steps 3-8 outlined in embodiment 3 above. Note that in this embodiment, steps 5-8 may be optional. For example, if in step 1b primary authentication, the AKMA context for the UE is not deleted from AAnF and / or AF, the steps 5-8 may be performed here. Otherwise, if the primary authentication in step 1b already cleaned up AKMA context for the UE in AAnF and AF, then steps 5-8 may be skipped. Descriptions for these steps may be found in embodiment 3, and are omitted here for the sake of simplicity.

[0143] Embodiment 5: Checking AKMA Service for Roaming UE in Re-authentication

[0144] In this embodiment, a UE is roaming in a visitor network, (e.g., UE is served by a VPLMN) . In this case, the Serving Network (SN) of the UE is in the VPLMN. When the UE performs re-authentication with the network, additional check needs to be performed by the UDM, to check whether AKMA service is allowed when the UE is roaming. This check by the UDM aims to assess whether the security protection offered by the AKMA framework can be utilized for the roaming UE or if certain restrictions apply based on the roaming agreements and policies.

[0145] As the UE is roaming in the VPLMN (served by a serving network that is in the VPLMN) , although AKMA protection is preferred due to the enhanced security it provides, the AKMA service (i.e., using security protection provided under the AKMA framework) may or may not be allowed or supported between the UE and various network elements, such  as the AF responsible for providing application services. For example, a roaming policy does not grant UE with AKMA service, or the roaming policy does not grant AKMA service to the particular application running on the UE, or the roaming policy does not allow roaming service for the UE in the VPLMN at all. In this case, roaming agreement checking is performed first, to determine whether the AKMA service is allowed based on, for example, the roaming policy associated with the UE. The exemplary steps of a primary authentication procedure for a roaming UE are described in details below with reference to FIG. 13. An exemplary method may include a portion or all of the following steps.

[0146] Step 1: During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication information, such as subscription credentials (e.g., AKA Authentication vectors) , authentication method, etc. The AUSF may send a request, such as an Nudm_UEAuthentication_Get Request message to the UDM. The request may include at least one of: the SUPI of the UE, the SUCI of the UE, or the Serving Network (SN) name of UE’s serving network.

[0147] Step 2: Based on the SN name, the UDM may determine the serving network (SN) for the UE. Note that the UE initiates the current primary authentication via the SN. If the SN of the UE is located in a roaming network (e.g., a VPLMN) , then the UDM may further check if the UE is allowed to use AKMA service while roaming in the roaming network. The check may be based on, for example, a local policy which may include a roaming agreement, a regulatory control policy for the UE, or an AKMA policy.

[0148] The check may be at various levels. For example, the check may be performed at the SN level (i.e., UE is allowed or not allowed to use AKMA service in the whole SN) . The check may also be performed at an AF level, that is, within the same SN, UE is allowed to use AKMA service with some AFs but is not allowed to use AKMA service with other AFs.

[0149] In some example implementations, the UE may have a dual registration. In this case, if any one of the networks (for dual registration) does not comply with the regulatory  control for AKMA service, then the current serving network is considered as not satisfying the roaming agreement for AKMA service.

[0150] Based on the AKMA service permission check result, subsequent steps may have two branches, with a first branch handling the scenario that AKMA service is allowed, and a second branch handling the scenario that AKMA service is not allowed.

[0151] The first branch switches back to FIG. 9 and starts at step 2 in FIG. 9. That is, UDM may respond to the AUSF with, for example, an Nudm_UEAuthentication_Get response message (as a response to the Nudm_UEAuthentication_Get Request message in FIG. 10 step 1) . The response message may carry an AKMA indicator and the RID of the UE. Note that the AKMA indicator and the RID may serve as an implicit indicator indicating that AKMA service is allowed, as these two parameters may trigger the AUSF to conduct further AKMA context derivation / generation. As shown in FIG. 9, in step 3a, the AUSF generates the KAKMA key, while in step 3b, it generates the A-KID. The remaining steps under the first branch are described in detail as part of Embodiment 1, and are skipped here to avoid redundancy.

[0152] The steps described below correspond the second branch, which is the scenario where the AKMA service is not allowed.

[0153] Step 3: The UDM may respond to the AUSF with, for example, an Nudm_UEAuthentication_Get response message. The response message does not include the AKMA indication and the RID of the UE. The message may only include an Authentication Vector (AV) .

[0154] In this step, the AKMA indication and RID are not sent to the AUSF, which serves as an implicit indication to AUSF that the AKMA service is not allowed. Upon receiving this response message, the AUSF will not proceed to generate KAKMA for the UE and the corresponding A-KID, and therefore, AKMA service will not be used for the UE, even UE may have its local AKMA context.

[0155] In this embodiment, there are no extra steps to clean up AKMA context at core network side (e.g., AAnF, AF) , aiming to streamline the message flow.

[0156] Embodiment 6: Checking AKMA Service during UE Mobility -UDM Triggered Re-authentication

[0157] In this embodiment, when a UE roams from one network to another network, or is handed over from one network to another network, the UE initiates a registration procedure with the network. Once the AMF registers with UDM as the AMF serving the UE, the UDM will perform extra check to determine whether AKMA service is allowed for the UE in the serving network (i.e., the network UE roams to, or handed over to) . If AKMA service is allowed, the UDM will trigger a primary authentication.

[0158] The exemplary steps of the registration procedure are described in details below with reference to FIG. 14. An exemplary method may include a portion or all of the following steps.

[0159] Step 1: UE sends a registration request to the AMF, to register with the core network. The registration message is sent during, for example, a handover procedure.

[0160] Step 2: The AMF sends an Nudm_UECM_Registration message to UDM carrying the Globally Unique AMF Identifier (GUAMI) of the AMF, to register with the UDM.

[0161] Step 3: The GUAMI is a concatenation of the PLMN identity and the AMF identifier. For example, <GUAMI> = <MCC><MNC><AMF Identifier> (MCC: Mobile Country Code; MNC: Mobile Network Code) . Based on the GUAMI, the UDM is able to determine the serving network (SN) for the UE from which the registration request is sent.

[0162] If the SN of the UE is located in a roaming network (e.g., a VPLMN) , then the UDM may further check if the UE is allowed to use AKMA service while roaming in the roaming network. The check may be based on, for example, a local policy which may include a roaming agreement, a regulatory control policy for the UE, or an AKMA policy.

[0163] The check may be at various levels. For example, the check may be performed at the SN level (i.e., UE is allowed or not allowed to use AKMA service in the whole SN) . The check may also be performed at an AF level, that is, within the same SN, UE is allowed to use AKMA service with some AFs but is not allowed to use AKMA service with other AFs.

[0164] In some example implementations, the UE may have a dual registration. In this case, if any one of the networks (for dual registration) does not comply with the regulatory control for AKMA service, then the current serving network is considered as not satisfying the roaming agreement for AKMA service.

[0165] If AKMA service is allowed for the UE in the serving network, or if AKMA service is allowed for the UE for the specific AF in the serving network, the following steps will be performed.

[0166] Step 4: There are two options for this step.

[0167] Option 1: The UDM may send an Nudm_UECM_Re-AuthenticationNotification message to the AMF / SEAF with the UE’s SUPI. This message will trigger a UE re-authentication by performing a primary authentication with AKMA check.

[0168] Option 2: The UDM may send an Nudm_UECM_Registration response message, carry an indication (e.g., REAUTHENTICATION_REQUIRED) , to indicate to the UDM that a re-authentication is required. The Nudm_UECM_Registration response message may be the response of Nudm_UECM_Registration message in step 2. This option is not shown in FIG. 14. After this step, the procedure will jump to step 6, to execute primary authentication with AKMA service check.

[0169] Detailed description for the primary authentication with AKMA service check may be referred to embodiment 2.

[0170] Step 5: The AMF / SEAF may send an authentication response message to the UDM to  acknowledge the re-authentication request.

[0171] Step 6: The AMF may initiate the primary authentication procedure.

[0172] Embodiment 6: UE Registration Triggering Primary Authentication with AKMA Service Check

[0173] In this embodiment, when a UE roams from one network to another network, or is handed over from one network to another network, the UE initiates a registration procedure with the network. The UE registration will trigger a primary authentication with AKMA service check, as described in embodiment 2. The primary authentication is relied upon to either allow or prohibit AKMA service. After the primary authentication, no further AKMA service check is needed.

[0174] The exemplary steps of the registration procedure are described in details below with reference to FIG. 15. An exemplary method may include a portion or all of the following steps.

[0175] Step 1: UE sends a registration request to the AMF, to register with the core network. The registration message is sent during, for example, a handover procedure.

[0176] Step 2: A primary authentication with AKMA service check (e.g., as described in embodiment 2) is triggered.

[0177] Step 3: The AMF sends an Nudm_UECM_Registration message to UDM carrying the Globally Unique AMF Identifier (GUAMI) of the AMF, to register with the UDM.

[0178] Step 4: The UDM respond back with an Nudm_UECM_Registration response message to the AMF.

[0179] In this disclosure, various methods are described to control and enable AKMA service when the UE is served by a roaming network. In one aspect, the core network does not need to derive / refresh AKMA context for a UE during a primary authentication, to cause AKMA context mismatch between UE and the core network and block the AKMA service.  In another aspect, if AKMA service is not allowed, the AKMA context for the UE is deleted from various network elements, such as AAnF, AF, etc. This will at least release the memory and / or storage needed for storing the AKMA context.

[0180] Performed by a first network element, an exemplary method according to embodiments in this disclosure may include a portion or all of the following steps: step 1: receiving, from a second network element, a first message carrying at least one of: a Subscription Permanent Identifier (SUPI) of a wireless device; a Subscription Concealed Identifier (SUCI) of the wireless device; or a Serving Network (SN) name of an SN serving the wireless device; and step 2: determining whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in the SN.

[0181] In any portion or combination of the implementations above, the first network element comprises a Unified Data Management (UDM) , and wherein the second network element comprises an Authentication Server Function (AUSF) .

[0182] In any portion or combination of the implementations above, determining whether the AKMA service is allowed for the wireless device in the SN comprises determining, based on the SN name, whether the SN is in a roaming network for the wireless device; and in response to the SN being in the roaming network, determining, based on a predefined policy, whether the AKMA service is allowed for the wireless device in the SN.

[0183] In any portion or combination of the implementations above, the first message is triggered by a primary authentication procedure for the wireless device.

[0184] In any portion or combination of the implementations above, the primary authentication procedure is triggered by a registration request from the wireless device during a hand over procedure to hand over the wireless device to the SN.

[0185] In this disclosure, message types and / or message names (e.g., as shown in FIGs. 8-141) 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.

[0186] 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.

[0187] 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 yet another example, a single step may be split (e.g., one message may be sent via two sub-messages) .

[0188] The embodiments described in this disclosure are for exemplary purpose. Multiple embodiments may be combined, to form a new embodiment. For example, after UE performs primary authentication in embodiment 2, embodiment 3 may be added to handle UE mobility scenario (e.g., handover) .

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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 first network element, comprising:receiving, from a second network element, a first message carrying at least one of:a Subscription Permanent Identifier (SUPI) of a wireless device;a Subscription Concealed Identifier (SUCI) of the wireless device; ora Serving Network (SN) name of an SN serving the wireless device; anddetermining whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in the SN.2.The method of claim 1, wherein the first network element comprises a Unified Data Management (UDM) , and wherein the second network element comprises an Authentication Server Function (AUSF) .3.The method of claim 1, wherein determining whether the AKMA service is allowed for the wireless device in the SN comprises:determining, based on the SN name, whether the SN is in a roaming network for the wireless device; andin response to the SN being in the roaming network, determining, based on a predefined policy, whether the AKMA service is allowed for the wireless device in the SN.4.The method of claim 1, wherein:the wireless device has a dual registration, with a first registration via the SN and a second registration via another network, and the SN is in a roaming network for the wireless device; anddetermining whether the AKMA service is allowed for the wireless device comprises:determining that the AKMA service is allowed for the wireless device in the SN only if: a local policy is satisfied such that the AKMA service is allowed in both the SN and the another network.5.The method of claim 1, wherein the first message is triggered by a primary authentication procedure for the wireless device.6.The method of claim 5, wherein the primary authentication procedure is triggered by a registration request from the wireless device during a hand over procedure to hand over the wireless device to the SN.7.The method of any one of claims 1-6, wherein it is determined that the AKMA service is not allowed for the wireless device in the SN.8.The method of claim 7, further comprising:transmitting, to the second network element, a second message as a response to the first message, wherein the second message does not carry 1) an AKMA indication; and 2) a Routing Indicator (RID) of the wireless device.9.The method of claim 8, wherein the first message comprises an Nudm_UEAuthentication_Get request message requesting authentication information for the wireless device, and wherein the second message comprises an Nudm_UEAuthentication_Get response message.10.The method of any one of claims 7-9, further comprising:transmitting, to a third network element, a third message requesting the third network element to delete AKMA context for the wireless device that is stored in the third network element, the third message comprising the SUPI of the wireless device.11.The method of claim 10, wherein the third message triggers the third network element to send a fourth message to an Application Function (AF) associated with the wireless device to request the AF to perform at least one of: deleting AKMA context for the wireless device that is stored in the AF; or stopping the AKMA service for the wireless device, the fourth message carrying an AKMA Key Identifier (A-KID) specific to the wireless device.12.The method of any one of claims 1-6, wherein it is determined that the AKMA service is allowed for the wireless device in the SN, the method further comprising:transmitting, to the second network element, a fourth message as a response to the first message, wherein the fourth message carries at least one of: an AKMA indication; or an RID of the wireless device.13.The method of any one of claims 1-12, wherein before receiving the first message, the method further comprising:receiving, from the third network element, a fifth message for registering the wireless device, the first message carrying a Globally Unique AMF Identifier (GUAMI) of the second network element; anddetermining, based on the GUAMI, whether the AKMA service is allowed for the wireless device in the SN serving the wireless device.14.The method of claim 13, wherein the third network element comprises an Access and Mobility Management Function (AMF) .15.The method of claim 13, wherein determining whether the AKMA service is allowed for the wireless device in the SN comprises:determining, based on the GUAMI, whether the SN is in a roaming network for the wireless device; andin response to the SN being in the roaming network, determining, based on a predefined policy, whether the AKMA service is allowed for the wireless device in the SN.16.The method of claim 13, wherein the fifth message is triggered by a registration procedure initiate by the wireless device during a hand over procedure to hand over the wireless device to the SN.17.The method of any one of claims 13-16, wherein the fifth message comprises an Nudm_UECM_Registration message.18.The method of any one of claims 13-16, further comprising:in a determination that the AKMA service is not allowed for the wireless device in the SN, transmitting, to the third network element, a sixth message requesting re-authenticating the wireless device, the sixth message carrying at least one of: a SUPI of the wireless device; or a re-authentication indication.19.The method of claim 18, wherein the sixth message comprises an Nudm_UECM_Re-AuthenticationNotification message and triggers the first message, the sixth message carrying the SUPI of the wireless device.20.The method of claim 18, wherein the sixth message comprises an Nudm_UECM_Registration response message and triggers the first message, the sixth message carrying the re-authentication indication.21.A method for wireless communication, performed by a first network element, comprising:transmitting, to a second network element, a first message carrying at least one of:a Subscription Permanent Identifier (SUPI) of a wireless device;a Subscription Concealed Identifier (SUCI) of the wireless device; ora Serving Network (SN) name of an SN serving the wireless device, wherein the SN name is used by the second network element to determine whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in the SN.22.The method of claim 21, wherein the first network element comprises an Authentication Server Function (AUSF) , and wherein the second network element comprises a Unified Data Management (UDM) .23.The method of claim 21, wherein the first message is triggered by a primary authentication procedure for the wireless device.24.The method of claim 23, wherein the primary authentication procedure is triggered by a registration request from the wireless device during a hand over procedure to hand over the wireless device to the SN.25.The method of any one of claims 21-24, wherein:it is determined by the second network element that the AKMA service is not allowed for the wireless device in the SN;the method further comprising:receiving, from the second network element, a second message as a response to the first message, wherein the second message does not carry 1) an AKMA indication; and 2) a Routing Indicator (RID) of the wireless device.26.The method of any one of claims 21-24, wherein it is determined that the AKMA service is allowed for the wireless device in the SN, the method further comprising:it is determined by the second network element that the AKMA service is allowed for the wireless device in the SN;the method further comprising:receiving, from the second network element, a second message as a response to the first message, wherein the second message carries at least one of: an AKMA indication; or an RID of the wireless device.27.The method of any one of claims 25-26, wherein the first message comprises an Nudm_UEAuthentication_Get request message requesting authentication information for the wireless device, and wherein the second message comprises an  Nudm_UEAuthentication_Get response message.28.A method for wireless communication, performed by a first network element, comprising:receiving, from a second network element, a first message for registering a wireless device, the first message carrying a Globally Unique AMF Identifier (GUAMI) of the second network element; anddetermining, based on the GUAMI, whether an AKMA (Authentication and Key Management for Applications) service is allowed for the wireless device in a Serving Network (SN) serving the wireless device.29.The method of claim 28, wherein the first network element comprises a Unified Data Management (UDM) , and wherein the second network element comprises an Access and Mobility Management Function (AMF) .30.The method of claim 28, wherein determining whether the AKMA service is allowed for the wireless device in the SN comprises:determining, based on the GUAMI, whether the SN is in a roaming network for the wireless device; andin response to the SN being in the roaming network, determining, based on a predefined policy, whether the AKMA service is allowed for the wireless device in the SN.31.The method of claim 28, wherein:the wireless device has a dual registration, with a first registration via the SN and a second registration via another network, and the SN is in a roaming network for the wireless device; anddetermining whether the AKMA service is allowed for the wireless device comprises:determining that the AKMA service is allowed for the wireless device in the SN only if: a local policy is satisfied such that the AKMA service is allowed in both the SN and the another network.32.The method of claim 28, wherein the first message is triggered by a registration procedure initiate by the wireless device during a hand over procedure to hand over the wireless device to the SN.33.The method of any one of claims 28-32, wherein the first message comprises an Nudm_UECM_Registration message.34.The method of any one of claims 28-33, wherein it is determined that the AKMA service is not allowed for the wireless device in the SN.35.The method of claim 34, further comprising:transmitting, to a third network element, a second message requesting the third network element to delete AKMA context for the wireless device that is stored in the third network element, the second message comprising Subscription Permanent Identifier (SUPI) of the wireless device.36.The method of claim 35, wherein the second message triggers the third network element to send a third message to an Application Function (AF) associated with the wireless device to request the AF to perform at least one of: deleting AKMA context for the wireless  device that is stored in the AF; or stopping the AKMA service for the wireless device, the third message carrying an AKMA Key Identifier (A-KID) specific to the wireless device.37.The method of any one of claims 28-33, further comprising:in a determination that the AKMA service is allowed for the wireless device in the SN, transmitting, to the second network element, a fourth message requesting re-authenticating the wireless device.38.The method of claim 37, wherein the fourth message comprises an Nudm_UECM_Re-AuthenticationNotification message, the fourth message carrying the SUPI of the wireless device.39.The method of claim 37, wherein the fourth message comprises an Nudm_UECM_Registration response message, the fourth message carrying the re-authentication indication.40.A device or a network element 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-39.41.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-39.

Images