Method and apparatus for adaptive registration of a communication device

Abstract

This disclosure relates to a method and apparatus for adaptive registration of communication devices. A security mechanism for communication networks is provided. In one embodiment, an apparatus is configured to derive a local authentication key for local authentication of a 6G device by: identifying input parameters of a key deriving function configured to generate the local authentication key, and inputting the input parameters into the key deriving function to derive the local authentication key. The input parameters include at least: a long-term key for the 6G device, a service network name for the serving network of the 6G device, a device identifier for the 6G device, and an identifier for the local authentication entity performing local authentication of the 6G device.

Description

Technical Field

[0001] This disclosure relates to the field of communication networks, and particularly to security in communication networks. Background Technology

[0002] Mobile telecommunications networks or cellular networks (generally referred to herein as communication networks or mobile networks) enable communication between two or more communication devices, provide communication devices with access to data networks, deliver services provided by third-party applications to communication devices, and / or provide services provided by the communication network to communication devices. Communication networks and communication devices can operate according to cellular technologies (also known as radio access technologies), such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UTMS), Long Term Evolution (LTE or LTE-A), and New Radio (NR). Cellular technologies are standardized by various standards organizations, such as the 3rd Generation Partnership Project (3GPP) or ETSI (European Telecommunications Standards Institute). 3GPP is currently developing fifth-generation cellular technologies (generally referred to as 5G or NR standards) and sixth-generation cellular technologies (generally referred to as 6G or NR standards). Communication networks operating according to 5G or NR standards are generally referred to as 5G networks or 5G systems, while communication networks operating according to 6G standards are generally referred to as 6G networks or 6G systems; both can generally be referred to as next-generation networks (i.e., networks following the fourth-generation (4G) standard).

[0003] Communication networks (e.g., 5G or 6G networks) include access networks (e.g., radio access networks), which can wirelessly communicate with one or more communication devices by sharing the available resources (e.g., bandwidth, transmit power, etc.) of the access network. Communication networks can also establish reliable and secure connections between communication devices and the core network of the communication network via the access network. With the widespread use of communication networks across countries and around the world, communications may be intercepted or subjected to other types of attacks. To ensure security and privacy, 3GPP and / or other organizations have defined security mechanisms for communication networks and the security procedures performed within them. Due to the importance of security in communication networks, there is a desire to continue developing improved security mechanisms. Summary of the Invention

[0004] This paper describes enhancements to the security mechanisms of communication networks. As an overview, the communication network provides adaptive registration for communication devices (e.g., 6G devices). As part of adaptive registration, communication devices and the network can perform local authentication, where a serving network entity authenticates the communication device to the network. For example, the serving network entity can include radio access network (RAN) nodes such as 6G NodeBs, 6G Mobility Management (MM) network functions, 6G Session Management (SM) network functions, and 6G User Plane (UP) network functions. Therefore, the nearest or closest network entity authorized to perform authentication can participate in local authentication, rather than solely relying on the communication device's home network. One technical advantage is that the home network does not need to assume authentication responsibility for every type of communication device or use case. This reduces the workload of the home network and lowers the signaling overhead between the serving and home networks. Furthermore, local authentication can be assigned to different serving network entities to distribute the workload associated with device authentication within the network.

[0005] In one embodiment (also referred to as an aspect), an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least perform the following: derive a local authentication key for local authentication of a 6G device by identifying input parameters of a key deriving function configured to generate the local authentication key, and inputting the input parameters into the key deriving function to derive the local authentication key. The input parameters include at least: a long-term key for the 6G device, a service network name for the serving network of the 6G device, a device identifier for the 6G device, and an identifier for a local authentication entity performing local authentication of the 6G device.

[0006] In one embodiment, a method includes deriving a local authentication key for local authentication of a 6G device by: identifying input parameters of a key deriving function configured to generate the local authentication key, and inputting the input parameters into the key deriving function to derive the local authentication key. The input parameters include at least: a long-term key for the 6G device, a service network name for the serving network of the 6G device, a device identifier for the 6G device, and an identifier for the local authentication entity performing local authentication of the 6G device.

[0007] Other embodiments may include computer-readable media, other systems or apparatuses, or other methods or means as described below. Furthermore, one or more embodiments as described above may be combined as illustrated herein.

[0008] The foregoing summary provides a basic understanding of some aspects of this specification. This summary is not a comprehensive overview of the specification. It is not intended to identify key or essential elements of the specification, nor to define any scope of any particular embodiment or claim. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to a more detailed description later. Attached Figure Description

[0009] Some embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings. Throughout the drawings, the same reference numerals denote the same elements or elements of the same type.

[0010] Figure 1 The diagram illustrates the high-level architecture of a 5G system.

[0011] Figure 2 The diagram illustrates the non-roaming architecture of a 5G system.

[0012] Figure 3 The diagram illustrates the NG-RAN architecture.

[0013] Figure 4 The diagram illustrates the security mechanisms within a 5G system.

[0014] Figures 5A-5B The diagram illustrates the main authentication process that provides mutual authentication between the UE and the network.

[0015] Figure 6 This is a block diagram illustrating the 5G NR radio protocol stack.

[0016] Figure 7 The diagram illustrates the high-level architecture of a 6G system.

[0017] Figure 8 This is a block diagram of a system for providing security management in an exemplary embodiment.

[0018] Figure 9 This is a block diagram of a UE device in an exemplary embodiment.

[0019] Figure 10 This is a diagram illustrating part of the 5G registration process for a UE.

[0020] Figure 11A This is a diagram illustrating the adaptive registration of a 6G device in an exemplary embodiment.

[0021] Figure 11B This is a diagram illustrating the local authentication process in an exemplary embodiment.

[0022] Figure 11C This is a diagram illustrating home authentication and local authentication in an exemplary embodiment.

[0023] Figures 12A-12D The illustration shows local authentication in an exemplary embodiment.

[0024] Figure 13 The illustration depicts a registration request in an exemplary embodiment.

[0025] Figure 14 This is a diagram illustrating the definition of device types in an exemplary embodiment.

[0026] Figure 15 This is a diagram illustrating the definition of mobility types in an exemplary embodiment.

[0027] Figure 16 Different use cases in exemplary embodiments are illustrated.

[0028] Figures 17A-17B This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0029] Figures 18A-18C This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0030] Figures 19A-19D This is a block diagram illustrating the local authentication key derived in an exemplary embodiment.

[0031] Figure 20 This is a flowchart illustrating a method for deriving a local authentication key in an exemplary embodiment.

[0032] Figure 21 This is a flowchart illustrating a method for deriving a local authentication key in an exemplary embodiment.

[0033] Figure 22A The illustration shows a traditional SUPI in 5G.

[0034] Figure 22B An extended SUPI for next-generation networks is illustrated in an exemplary embodiment.

[0035] Figure 23A The illustration shows a traditional SUCI in 5G.

[0036] Figure 23B An extended SUCI for next-generation networks is illustrated in an exemplary embodiment.

[0037] Figure 24 This is a diagram illustrating the definition of network types in an exemplary embodiment.

[0038] Figures 25A-25B The illustrations show the hiding and unhiding of SUPI in the exemplary embodiments.

[0039] Figure 26This is a flowchart illustrating a method for hiding SUPI in an exemplary embodiment.

[0040] Figure 27 This is a diagram illustrating adaptive registration in an exemplary embodiment.

[0041] Figures 28A-28B This is a diagram illustrating adaptive registration in an exemplary embodiment.

[0042] Figure 29 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0043] Figure 30 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0044] Figure 31 This is a diagram illustrating integrity protection in an exemplary embodiment.

[0045] Figures 32A-32B This is a diagram illustrating adaptive registration in an exemplary embodiment.

[0046] Figure 33 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0047] Figure 34 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0048] Figure 35 This is a diagram illustrating integrity protection in an exemplary embodiment.

[0049] Figure 36 This is a diagram illustrating adaptive registration in an exemplary embodiment.

[0050] Figure 37 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0051] Figure 38 This is a flowchart illustrating an exemplary embodiment of a method for performing adaptive registration.

[0052] Figure 39 This is a diagram illustrating integrity protection in an exemplary embodiment. Detailed Implementation

[0053] The accompanying drawings and the following description illustrate specific exemplary embodiments. Therefore, it should be understood that those skilled in the art will be able to design various arrangements, which, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments and should be construed as not being limited to these specifically referenced examples and conditions. Consequently, the inventive concept is not limited to the specific embodiments or examples described below, but is defined by the claims and their equivalents.

[0054] Figure 1 The diagram illustrates the high-level architecture of a 5G system 100. The 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) that includes an access network ((R)AN) 102 (also referred to herein as RAN, 5G access network, etc.) and a core network 104 (also referred to herein as 5G core network or 5GC) that communicate with user equipment (UE) 106 (e.g., a 5G-enabled UE). RAN 102 and core network 104 together may be referred to as a 5G network 101, a 5G mobile network, a 5G communication network, a next-generation network, etc.

[0055] RAN 102 provides radio or wireless connectivity to UE 106 and connects UE 106 to core network 104. RAN 102 may include a Next Generation Radio Access Network (NG-RAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Non-3GPP Access Network (N3AN), Non-Terrestrial Access Network (NTN), and / or another type of RAN connected to core network 104. RAN 102 may support access via at least one RAN node, such as a gNodeB (gNB), ng-eNodeB (ng-eNB), eNodeB (eNB), and / or a Wireless Local Area Network (WLAN) access point. RAN 102 may support satellite radio access, New Radio Access Technology (RAT), etc. 5G access networks may also support fixed access. Core network 104 interconnects RAN 102 with data network (DN) 108. The core network 104 comprises network functions (NFs) 110, which can be implemented as network elements on dedicated hardware, chips or chipsets included in network elements, software instances running on dedicated hardware, virtualized network functions (VNFs) instantiated on dedicated or general virtualization platforms (e.g., cloud infrastructure), etc. The data network 108 can be a public or private data network outside the operator, or a data network within the operator (e.g., for IP Multimedia Subsystem (IMS) services). The UE 106 (also referred to as a mobile terminal) includes a 5G-enabled device configured to register with the core network 104 to access services. The UE 106 can include end-user equipment such as mobile phones (e.g., smartphones), tablets, computers with mobile broadband adapters, etc. The UE 106 can be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, and / or other services.

[0056] Figure 2 The diagram illustrates the non-roaming architecture 200 of a 5G system. Figure 2Architecture 200 is a service-based representation, as further described in 3GPP TS 23.501 (Release 19) (incorporated herein by reference as if fully included herein). Architecture 200 consists of network functions (NFs) of core network 104, with the NFs of the control plane (CP) separated from the user plane (UP). The control plane of core network 104 includes Authentication Server Function (AUSF) 210, Access and Mobility Management Function (AMF) 212, Session Management Function (SMF) 214, Policy Control Function (PCF) 216, Unified Data Management (UDM) 218, Network Slice Selection Function (NSSF) 220, and Application Function (AF) 222. The control plane of core network 104 also includes Network Open Function (NEF) 224, NF Repository Function (NRF) 226, Serving Communication Agent (SCP) 228, Network Slice Admission Control Function (NSACF) 230, Network Slice Specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and Edge Application Server Discovery Function (EASDF) 234. The user plane of core network 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108. UE 106 can access the control plane and user plane of core network 104 through RAN 102.

[0057] Figure 3 The NG-RAN architecture 300 is illustrated. The NG-RAN architecture 300 is further described in 3GPP TS 38.300 (Release 18) (incorporated herein by reference as if fully included herein). NG-RAN 302 is an example of RAN 102 as described above and includes multiple RAN nodes 304 (also referred to as NG-RAN nodes). RAN nodes 304 can be gNB 306, configured to provide new radio user plane and control plane protocol termination to UE 106; or ng-eNB 308, configured to provide E-UTRA user plane and control plane protocol termination to UE 106. gNB 306 and ng-eNB 308 are interconnected to each other via Xn interfaces. gNB 306 and ng-eNB 308 are also connected to core network 104 via NG interfaces, more specifically, to AMF 212 via NG-C interfaces, and to UPF 240 via NG-U interfaces.

[0058] Typically, UE 106 can have service availability when it connects to a Home Public Land Mobile Network (HPLMN) via one or more access types (such as 3GPP access and non-3GPP access (trusted or untrusted)). UE 106 can also have service availability when it connects to a Visited Public Land Mobile Network (VPLMN) or a serving network via one or more access types (again, such as 3GPP access and non-3GPP access (trusted or untrusted)).

[0059] A large number of subscribers are able to access services from operators or home / mobile network operators that implement mobile networks including 5G System 100, such as Figures 1-2 As shown in the diagram, communication between the user or subscriber (i.e., via the UE) and the mobile network is protected by security mechanisms, such as those standardized by 3GPP. Subscribers and operators expect these security mechanisms to provide security guarantees.

[0060] Figure 4 The diagram illustrates security mechanisms 400 within the 5G system 100. One of the security mechanisms 400 is master authentication and key negotiation between the network (e.g., AMF212 / UDM 218) and UE 106. Other security mechanisms 400 are used to protect signaling between the network and UE 106. For example, security mechanism 400 is used to protect non-access stratum (NAS) signaling between AMF 212 and UE 106. Other security mechanisms 400 are used to protect access stratum (AS) communication between RAN node 304 (e.g., gNB 306) and UE 106, such as radio resource control (RRC) signaling between gNB 306 and UE 106, and user plane (UP) traffic (also known as UP data) between gNB 306 and UE 106. Within the network, security mechanisms 400 can be used to protect IP connections between gNB 306 and core network 104 (e.g., AMF 212 / UPF 240), such as Internet Protocol Security (IPSec). Another security mechanism 400 is used for roaming and interconnection security, such as protecting control plane signaling between the Security Edge Protection Agent (SEPP) 410 and other networks 401 (e.g., the visited 5G network), and / or protecting user plane data between the UPF 240 and other networks 401. Another security mechanism 400 can be used to protect the IP connection between the gateway 420 (e.g., Non-3GPP Interoperability Function (N3IWF) in the case of untrusted non-3GPP access) and the UE 106. Additional security mechanisms 400 can be defined or used; for the sake of brevity, they will not be discussed here.

[0061] Figures 5A-5BThe diagram illustrates the master authentication process that provides mutual authentication between UE 106 and a network (e.g., AMF 212 / UDM 218). The purpose of the master authentication and key negotiation process is to enable mutual authentication between UE 106 and its home network 504, and to provide key material that can be used between UE 106 and the serving network 506 in subsequent security processes (e.g., NAS and AS security processes). Home network 504 (e.g., HPLMN) represents an operator network or carrier network through which subscribers (e.g., UE 106) subscribe to services. Serving network 506 is a network that allows users (e.g., via UE 106) to connect to their home network 504 and may have radio access devices capable of communicating with UE 106 via radio signals. The key material generated by the master authentication and key negotiation process produces an anchor key (called K). SEAF The anchor key (K) is provided by AMF 210 of home network 504 to the security anchor function (SEAF) 502 of serving network 506. SEAF 502 provides authentication via AMF 212 in serving network 506 and supports primary authentication using a Subscription Hidden Identifier (SUCI) containing a Hidden Subscription Persistent Identifier (SUPI). SUPI is a globally unique 5G identifier assigned to each subscriber in 5G system 100. SUCI consists of SUPI type, Home Network Identifier (HN-ID) identifying the subscriber's home network, Routing Indicator (RID) assigned to the subscriber by the home network operator and pre-configured in the Universal Subscriber Identifier Module (USIM) of UE 106, Protection Scheme Identifier, Home Network Public Key Identifier, and Scheme Output. SEAF From what is called K AUSF The intermediate key of the key is derived. K AUSF The key is established between UE 106 and home network 504 (AUSF 210), which is generated by the master authentication process.

[0062] Figure 5AThis is a signaling diagram illustrating the initiation of primary authentication as described in 3GPP TS 33.501 (Revision 19) (incorporated herein by reference as if fully included herein). UE 106 sends an N1 message 511 (i.e., an initial NAS message), such as a registration request, to serving network 506 (e.g., AMF 212 of serving network 506). In roaming scenarios, serving network 506 may also be referred to as serving PLMN, visited PLMN (VPLMN), etc. UE 106 uses SUCI or 5G Globally Unique Temporary Identifier (5G-GUTI) in the registration request. SEAF 502 of AMF 212 can initiate authentication with UE 106 at any stage of establishing a signaling connection with UE 106. SEAF 502 invokes the Nausf_UEAuthentication service to home network 504 (e.g., HPLMN) by sending a Nausf_UEAuthentication_Authenticate request message 512 to AMF 210 to initiate authentication. The Nausf_UEAuthentication_Authenticate request message 512 includes either SUCI or SUPI and the service network name (SN name or SNN). Upon receiving the Nausf_UEAuthentication_Authenticate request message 512, AUSF 210 checks whether the requesting SEAF 502 in service network 506 is authorized to use the service network name in the Nausf_UEAuthentication_Authenticate request message 512 by comparing the service network name with the expected service network name. When service network 506 is authorized to use the service network name, AUSF 210 sends a Nudm_UEAuthentication_Get request message 513 to the UDM 218 of home network 504. The Nudm_UEAuthentication_Get request message 513 includes either SUCI or SUPI and the service network name. Upon receiving the Nudm_UEAuthentication_Get request message 513, UDM 218 identifies the SUPI (if received) or invokes the Subscription Identifier De-Hide Function (SIDF), which de-hides the SUPI from the SUCI (if received). UDM 218 (or UDM 218’s Authentication Credentials Repository and Processing Function (ARPF)) uses SUPI to select or pick the authentication method for primary authentication.

[0063] Figure 5BThis is a signaling diagram illustrating the main authentication process described in 3GPP TS 33.501. In this example, 5G authentication and key negotiation (AKA) are depicted, but similar concepts also apply to the Extensible Authentication Protocol AKA Prime (EAP-AKA`). For Nudm_UEAuthentication_Get request 513, UDM 218 creates a 5G Home Environment Authentication Vector (5G HE AV) for the selected authentication method. UDM 218 derives K AUSF The key is used to calculate the expected response to the challenge (XRES). UDM218 creation includes an authentication token (AUTN) and an expected response (XRES). ), K AUSF The 5G HE AV key and random challenge (RAND). UDM 218 then sends a Nudm_UEAuthentication_Get response message 514 to AUSF 210, which contains the 5G HE AV key to be used for authentication (e.g., Figure 5B (5G AKA in the context of this). If the SUCI is included in the Nudm_UEAuthentication_Get request 513, the UDM 218 includes the SUPI in the Nudm_UEAuthentication_Get response message 514 after dehisting the SUPI from the SUCI. If the subscriber has an Authentication and Key Management (AKMA) subscription for the application, the UDM 218 may include the AKMA indication and RID in the Nudm_UEAuthentication_Get response message 514.

[0064] In response to Nudm_UEAuthentication_Get response message 514, AUSF 210 Temporary Storage Expected Response (XRES) ) and the received SUCI or SUPI. Then, AUSF 210 generates a 5G authentication vector (5G AV) based on the 5G HEAV received from UDM 218 using the following items: based on the expected response (XRES) Calculate the expected hash response (HXRES) And according to K AUSF Key computation K SEAF Key, and HXRES in 5G HE AV Replace XRES And use K SEAF Key replacement K AUSF Key. AUSF 210 removes K SEAFThe key is used to generate a 5G Service Environment Authentication Vector (5G SE AV), which includes an Authentication Token (AUTN) and a Hash Expected Response (HXRES). The AUSF 210 sends a Nausf_UEAuthentication_Authenticate response message 515, which includes the 5G SEAV, to the SEAF 502. In response, the SEAF 502 sends an authentication token (AUTN) and a random challenge (RAND) to the UE 106 in a NAS message authentication request message 516.

[0065] although Figure 5B Not shown, but UE 106 includes a mobile device (ME) and a USIM. The ME receives an authentication token (AUTN) and a random challenge (RAND) in NAS message authentication request message 516, and forwards the AUTN and RAND to the USIM. The USIM of UE 106 verifies the validity of the received value by checking if the AUTN is acceptable. If so, the USIM calculates the response (RES), cryptographic key (CK), and integrity key (IK) based on the RAND, and returns the RES, CK key, and IK key to the ME. The ME of UE 106 calculates RES based on RES. Calculate K based on CK||IK AUSF Key, according to K AUSF Key computation K SEAF Key.

[0066] UE 106 sends RES to SEAF 502 The NAS message authentication response message 517. In response, SEAF502 is based on RES... Calculate HRES And compare HRES and HXRES If they match, SEAF 502 considers authentication successful from the perspective of the serving network. SEAF 502 sends the RES received from UE 106 to AUSF 210 in the Nausf_UEAuthentication_Authenticate request message 518. When AUSF 210 receives RES When Nausf_UEAuthentication_Authenticate request message 518 is used for authentication confirmation, AUSF 210 is based on the policy storage K of the home network operator. AUSF The key, and the received RES With the stored XRES Compare. If RES and XRES If they are equal, AUSF 210 considers authentication successful from the perspective of the home network. AUSF 210 notifies UDM 218 of the authentication result (not shown). AUSF 210 also sends Nausf_UEAuthentication_Authenticate response message 519 to SEAF 502 to indicate whether authentication was successful from the perspective of the home network. If authentication is successful, then K... SEAF The key is sent to SEAF 502 in Nausf_UEAuthentication_Authenticate response message 519. If AUSF 210 receives SUCI from SEAF 502 in the authentication request, AUSF 210 includes SUPI in Nausf_UEAuthentication_Authenticate response message 519 if authentication is successful.

[0067] Figure 6 This is a block diagram illustrating the 5G NR radio protocol stack 600. The RAN protocol architecture is further described in 3GPP TS 38.300. The radio protocol stack 600 is divided into a protocol stack for the control plane 601 and a protocol stack for the user plane 602. The radio protocol stack 600 is mainly divided into three layers: the physical (PHY) layer 604 (L1), the data link layer (L2), and the network layer (L3). The data link layer (L2) includes the following layers or sublayers: the media access control (MAC) layer 610, the radio link control (RLC) layer 612, and the packet data convergence protocol (PDCP) layer 614. In the protocol stack of the control plane 601, the network layer (L3) includes the radio resource control (RRC) layer 616 (or a sublayer). The protocol stack of the control plane 601 also includes the non-access stratum (NAS) layer 618 (i.e., the NAS control protocol), which terminates at the network-side AMF 212. The RRC layer 616, PDCP layer 614, RLC layer 612, and MAC layer 610 terminate at the network-side gNB 306. In the protocol stack of the user plane 602, the network layer (L3) includes the Service Data Adaptation Protocol (SDAP) layer 620 (or a sublayer). The SDAP layer 620, PDCP layer 614, RLC layer 612, and MAC layer 610 terminate at the network-side gNB 306.

[0068] 6G is the next generation of cellular networks built on 5G learning and technology, such as supporting new and expanded use cases and new and enhanced capabilities. Figure 7The diagram illustrates the high-level architecture of the 6G system 700. The 6G system (6GS) 700 is a communication system (e.g., a 3GPP system) that includes a 6G access network (AN) 702 and a 6G core network 704 (often also referred to as 6GC) that communicate with one or more 6G devices 706. Together, the 6G AN 702 and the 6G core network 704 can be referred to as the 6G network 701, the 6G mobile network, the 6G communication network, etc.

[0069] 6G AN 702 may include a 6G radio access network (RAN) 703 that provides radio or wireless connectivity for 6G devices 706 and connects the 6G devices 706 to the 6G core network 704. The 6G RAN 703 may include one or more 6G NodeBs (NBs) 708, which are RAN nodes (e.g., radio base stations) responsible for the radio link between mobile users and the fixed portion of the network. The 6G core network 704 consists of 6G network functions (NFs) 705 for the control plane 601 and the user plane 602. The 6G NFs 705 may be implemented as network elements on dedicated hardware, chips or chipsets included in network elements, software instances running on dedicated hardware, virtualized network functions (VNFs) instantiated on dedicated or general virtualization platforms (e.g., cloud infrastructure), etc. As an example of control plane 601, 6G NF 705 may include a 6G Mobility Management (MM) NF 712 configured to manage the mobility of devices within 6G network 701. The 6G MM NF 712 may provide functionality similar to the AMF 212 described for 5G. Although not specifically shown, the 6G MM NF 712 may include a 6G Security Anchor Function (SEAF) providing authentication functionality in the serving network of 6G device 706. 6G NF 705 may include a 6G Session Management (SM) NF 714 configured to perform session management within 6G network 701. The 6G SM NF 714 may provide functionality similar to the SMF 214 described for 5G. 6G NF 705 may include a 6G Authentication Server (AUS) NF 710 configured to perform 6G authentication within 6G network 701. The 6G AUS NF 710 may provide functionality similar to the AUSF 210 described for 5G. 6G NF 705 may include a 6G Unified Data Management (UDM) NF 718 configured to manage user data within the 6G network 701. The 6G UDM NF 718 can provide functionality similar to the UDM 218 described for 5G. As an example of user plane 602, 6G NF 705 may include a 6G User Plane (UP) NF 740 configured to perform packet routing and forwarding, packet inspection, QoS (Quality of Service) processing, etc., within the 6G network 701. The 6G UP NF 740 can provide functionality similar to the UPF 240 described for 5G.

[0070] 6G device 706 (also referred to as 6G-enabled device, 6G-capable device, 6G communication device, etc.) is configured to register with 6G network 701 to access services. As will be described in further detail below, 6G device 706 may include different types of devices or apparatuses, such as user equipment (UE) devices 720 (e.g., mobile devices (ME) and universal subscriber identification modules (USIM)), Internet of Things (IoT) devices 722, gaming devices 724, unmanned aerial vehicle (UAV) devices 726, industrial devices 728 (e.g., industrial robots), cloud data center devices 730 (e.g., data storage devices, cloud gateways, load balancers, etc.), although other types of devices are considered herein. Furthermore, the labels provided for different types of devices are merely examples, and different labels may be used (e.g., a UAV device may be an unmanned aerial vehicle system (UAS), a drone, etc.).

[0071] Since 6G can be developed or evolved from 5G, some of the 5G concepts or systems described in this article can be incorporated into the discussion of 6G. Furthermore, although this article uses "6G" as an example, any next-generation or other generation of networks other than 5G is also considered.

[0072] With the advent of 6G networks and their unique requirements, such as supporting a large number of connected devices, ultra-low latency, high-throughput connections, and non-terrestrial network (NTN) integration, traditional registration processes may face significant challenges. While effective for their intended purpose, traditional registration processes are inherently static. For example, UE 106's home network 504 (e.g., AUSF 210 and UDM218) authenticates UE 106 using a traditional registration process. Therefore, every layer in the 5G protocol stack is initialized regardless of the specific use case. This can lead to inefficient resource utilization, processing overhead, and energy consumption. The inefficiency of static registration processes may be even more pronounced in NTN scenarios, where dynamic environments such as low Earth orbit (LEO) satellites impose constraints on bandwidth, latency, and power consumption. Furthermore, the increasing diversity of 6G use cases, encompassing extended reality (XR), IoT, autonomous systems, mission-critical communications, and more, necessitates adaptive, context-aware device registration mechanisms tailored to the requirements of each application.

[0073] This article describes adaptive registration in 6G networks. In adaptive registration, the registration process for 6G devices 706 dynamically adapts based on factors or considerations such as device type, mobility type, use case, and resource requirements. By leveraging context awareness, adaptive registration can intelligently identify and activate only the necessary protocol stack layers required for device operation, while disabling other protocol stack layers to minimize overhead and power consumption. Therefore, real-time decision-making is integrated into the registration process, providing technical advantages in scalability, resource efficiency, and sustainability.

[0074] Figure 8 This is a block diagram of a system 800 for providing security management in an exemplary embodiment. More specifically, Figure 8 System 800 includes at least one 6G device 706, at least one 6G RAN node 804, and multiple 6G network elements / functions 705 (i.e., first network element / function 705-1 and second network element / function 705-N). It should be understood that the 6G device 706, 6G RAN node 804, and network elements / functions 705 are configured to interact to provide security management (also known as protection management). Examples of network elements / functions 705 (typically referred to as core NFs) may include, but are not limited to, 6G AUS NF 710, 6G MM NF 712, 6G SM NF 714, 6G UDM NF 718, 6G UP NF 740, etc. The 6G RAN node 804 is an access network element / function configured to provide the 6G device 706 with access to the 6G core network 704, such as via 3GPP access or non-3GPP access. Therefore, the 6G RAN node 804 is configured to be communicatively coupled to the 6G device 706 via an air interface. An example of the 6G RAN node 804 is the 6G NB 708.

[0075] Network element / function 705-1 includes a processor 822-1 coupled to memory 826-1 and interface circuitry system 820-1. The processor 822-1 of network element / function 705-1 includes a security management processing module 824-1, which can be implemented at least partially in the form of software executed by the processor 822-1. The security management processing module 824-1 performs security management as described in conjunction with the following figures and other methods herein. Memory 826-1 includes a security management storage module 828-1 storing data generated or otherwise used during security management operations.

[0076] Network element / function 705-N includes a processor 822-N coupled to a memory 826-N and an interface circuitry system 820-N. The processor 822-N of network element / function 705-N includes a security management processing module 824-N, which can be implemented at least partially in the form of software executed by the processor 822-N. The security management processing module 824-N performs security management as described in conjunction with the following figures and other methods herein. The memory 826-N includes a security management storage module 828-N storing data generated or otherwise used during security management operations.

[0077] The processors 822-1 and 822-N of the corresponding network elements / functions 705-1 and 705-N may include, for example, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or other types of processing devices or integrated circuits, as well as portions or combinations of these elements. Such integrated circuit devices and portions or combinations thereof are examples of the "circuit system" used herein. Various other arrangements of hardware and associated software or firmware may be used in implementing exemplary embodiments.

[0078] The memories 826-1 and 826-N of the corresponding network elements / functions 705-1 and 705-N can be used to store one or more software programs executed by the corresponding processors 822-1 and 822-N to implement at least a portion of the functions described herein. For example, security management operations and other functions, in conjunction with the following figures and otherwise described herein, can be implemented directly using software code executed by processors 822-1 and 822-N.

[0079] Therefore, a given memory in memories 826-1 and 826-N can be considered as an example of the content more generally referred to herein as a computer program product, or more generally as a processor-readable storage medium in which executable program code is embodied. Other examples of processor-readable storage media may include any combination of magnetic disks or other types of magnetic or optical media. Exemplary embodiments may include: products comprising such computer program products or other processor-readable storage media.

[0080] For example, memories 826-1 and 826-N may more specifically include electronic random access memory (RAM), such as static RAM (SRAM), dynamic RAM (DRAM), or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memory, such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM), or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be interpreted broadly and may additionally or alternatively include, for example, read-only memory (ROM), disk-based memory, or other types of storage devices, and portions or combinations thereof.

[0081] The interface circuitry systems 820-1 and 820-N of the corresponding network elements / functions 705-1 and 705-N illustratively include transceivers or other communication hardware or firmware, application programming interfaces (APIs), etc., which allow associated system elements to communicate with each other in the manner described herein.

[0082] Network element / function 705-1 is configured to communicate with network element / function 705-N via its respective interface circuit systems 820-1 and 820-N, and vice versa. This communication involves network element / function 705-1 sending data to network element / function 705-N, and network element / function 705-N sending data to network element / function 705-1. However, in alternative embodiments, other network elements may be operatively coupled between network elements / functions 705-1 and 705-N. The term "data" as used herein is intended to be interpreted broadly to encompass any type of information that can be sent between network elements / functions (and between 6G device 706 and 6G core network 704), including but not limited to messages, identifiers, keys, indicators, user data, control data, etc.

[0083] The 6G RAN node 804 includes a processor 812 coupled to a memory 816 and an interface circuitry 810. The processor 812 of the 6G RAN node 804 includes a security management processing module 814, which can be implemented at least partially in the form of software executed by the processor 812. The security management processing module 814 performs security management as described in conjunction with the following figures and other methods herein. The memory 816 includes a security management storage module 818 storing data generated or otherwise used during security management operations. The 6G RAN node 804 is configured to communicate with one or more 6G devices 706 and one or more network elements / functions 705 via the interface circuitry 810. For example, the interface circuitry 810 may be configured to communicate radioly with the 6G devices 706 via an air interface and may be configured to communicate backhaul with one or more network elements / functions 705 of the 6G core network 704.

[0084] The 6G device 706 includes a processor 832 coupled to a memory 836 and an interface circuitry 830. The processor 832 of the 6G device 706 includes a security management processing module 834, which can be implemented at least partially in the form of software executed by the processor 832. The security management processing module 834 performs security management as described in conjunction with the following figures and other methods herein. The memory 836 includes a security management storage module 838 storing data generated or otherwise used during security management operations. The 6G device 706 is configured to communicate with one or more 6G RAN nodes 804 via the interface circuitry 830. For example, the interface circuitry 830 may be configured to communicate radioly with the 6G RAN nodes 804 via an air interface.

[0085] It should be understood that Figure 8The specific arrangement of the components shown is an example, and many alternative configurations can be used in other embodiments. For example, any given network element / function can be configured to include additional or alternative components and support other communication protocols.

[0086] Other system components can also be configured individually to include components such as processors, memory, and network interfaces. These components do not need to be implemented on separate, independent processing platforms, but can represent different functional parts of a single general-purpose processing platform.

[0087] An example of the 6G device 706 described in this article is a user equipment (UE) device 720. Figure 9 This is a block diagram of a UE device 720 in an exemplary embodiment. From a functional perspective, the UE device 720 comprises at least two parts: a mobile device (ME) 900 and a Universal Subscriber Identity Module (USIM) 960. The ME 900 includes a radio interface component 902, one or more processors 904, and a memory 906, and may also include a user interface component 908. The UE device 720 may also include a battery 910. The radio interface component 902 is a hardware component or part representing the local radio resources of the UE device 720, such as a radio frequency (RF) unit 920 (e.g., one or more radio transceivers) and one or more antennas 922. The radio interface component 902 can be configured for 6G radio, 5G New Radio (NR), Long Term Evolution (LTE), WiFi, Bluetooth, etc. The processor 904 represents the internal circuitry, logic, hardware, components, etc., that provide the functionality of the UE device 720. The processor 904 can be configured to execute instructions 940 of software loaded into the memory 906. Processor 904 may execute an operating system (OS) 934 for managing hardware and software resources of the UE device 720, and one or more application clients 935 for applications. Processor 904 may also execute a security controller 936, which includes components or parts for implementing security mechanisms (such as integrity protection mechanisms and / or encryption mechanisms) within the UE device 720 (i.e., within the ME 900). User interface component 908 is a hardware component for interacting with an end user. For example, user interface component 908 may include a display 950, a screen, a touchscreen, etc. (e.g., a liquid crystal display (LCD), a light-emitting diode (LED) display, etc.). User interface component 908 may include a keyboard or numeric keypad, a tracking device (e.g., a trackball or trackpad), a speaker, a microphone, etc.

[0088] The USIM 960 is an integrated circuit that provides security and integrity functions for the UE device 720. The USIM 960 includes, or is pre-configured with, a subscription profile associated with the subscriber's subscription. The subscription profile may include various information, such as subscription credentials used to uniquely identify the subscription and mutually authenticate the UE device 720 and the network.

[0089] UE device 720 may include Figure 9 Various other components not specifically illustrated.

[0090] 3GPP and / or other standards organizations may define network access control for 6G, such as in 3GPP TS 23.501. Network access is a method for a 6G device 706 to connect to the core network. Network access control may include the authentication of the 6G device 706 to the network. The network may authenticate the 6G device 706 at any time during the establishment of a signaling connection with the 6G device 706. Registration management is used to register (re-register) or deregister the 6G device 706 with the network and establish a device context (also known as a device security context) in the network. The 6G device 706 needs to register with the network to obtain authorization to receive services that require registration. As described further in detail below, 6G registration management may include adaptive registration.

[0091] Adaptive registration can build upon or extend 5G registration as described in 3GPP TS 23.502 (version 19) (incorporated herein by reference as if fully included herein). Figure 10This diagram illustrates a portion of the 5G registration process for UE 106. For registration, as part of the registration process, UE 106 sends a registration request 1001 to RAN 102 (not shown). RAN 102 selects AMF 212 in serving network 506 and sends a registration request to the selected AMF 212. If authentication is required, AMF 212 contacts the home network authentication entity 1020. The home network authentication entity 1020 includes one or more functions, devices, servers, etc., of the home network 504 configured to perform authentication of communication devices. In 5G, the home network authentication entity 1020 includes AUSF 210, UDM 218, and / or other network functions 110 of the home network 504, such as the Unified Data Repository (UDR). Examples of authentication performed by the home network authentication entity 1020 are 5G AKA, EAP-AKA, etc. Typically, as part of the authentication process, the home network authentication entity 1020 generates an authentication vector referred to herein as the home authentication vector 1022 (or home environment authentication vector). The home authentication vector 1022 includes a challenge to the UE 106 to prove possession of a shared secret also held by the home network authentication entity 1020. Based on the home authentication vector 1022, the home network authentication entity 1020 performs an authentication process 1004 for mutual authentication between the home network 504 and the UE 106, as described in 3GPP TS 33.501. Upon successful authentication, the home network authentication entity 1020 and the UE 106 maintain a device context 1006, which indicates, for example, the authentication status of the UE 106.

[0092] Figure 11AThis diagram illustrates adaptive registration 1100 for a 6G device 706 in an exemplary embodiment. In adaptive registration 1100, different entities can be responsible for the 6G registration process 1102 and the authentication of the 6G device 706, such as in response to registration request 1101. Similar to 5G, the home network 1104 (also referred to as the 6G home network) of the 6G device 706 can perform mutual authentication with the 6G device 706. The home network 1104 of the 6G device 706 implements a home network authentication entity 1120, which includes one or more functions, devices, servers, etc., of the home network 1104 configured to perform authentication of 6G devices. In one embodiment, the home network authentication entity 1120 may include a 6G AUS NF 710, a 6G UDM NF 718, and / or other 6G NF 705 of the home network 1104. The authentication performed by the home network authentication entity 1120 is referred to herein as home authentication 1110. As part of Home Authentication 1110, Home Network Authentication Entity 1120 generates an authentication vector referred to herein as Home Authentication Vector 1114 (or Home Environment Authentication Vector). Home Authentication Vector 1114 includes a challenge to 6G device 706 to prove possession of a shared secret also held by Home Network Authentication Entity 1120. Home Network Authentication Entity 1120 performs Home Authentication Process 1124 based on Home Authentication Vector 1114 for mutual authentication between Home Network Authentication Entity 1120 and 6G device 706. Upon successful authentication, Home Network Authentication Entity 1120 and 6G device 706 maintain a device context 1126, which indicates, for example, the authentication status of 6G device 706, device type, connectivity / mobility type, device ID, supported algorithms(s), authentication keys(s), policies, security configurations, etc. An example of Home Authentication 1110 may be similar to... Figure 5B The 5GAKA described in the text.

[0093] In one embodiment, an entity outside the home network 1104 may perform mutual authentication with the 6G device 706. For example, the serving network 1106 of the 6G device 706 may implement a local authentication entity 1122. The local authentication entity 1122 includes one or more functions, devices, servers, etc., configured to perform authentication of the 6G device between the home network 1104 and the 6G device 706. In other words, the local authentication entity 1122 is an intermediary entity between the 6G device 706 and the 6G AUS NF 710 and / or 6G UDM NF 718 of the home network 1104. In one embodiment, the local authentication entity 1122 may include a 6G RAN node 804 (e.g., a 6G NB 708), a 6G MM NF 712 (or a 6G SEAF), a 6G SM NF 714, and / or a 6G UP NF 740. The authentication performed by the local authentication entity 1122 is referred to herein as local authentication 1112. As part of local authentication 1112, local authentication entity 1122 generates an authentication vector referred to herein as local authentication vector 1116. Local authentication vector 1116 includes a challenge to the 6G device 706 generated by local authentication entity 1122 to prove possession of a shared secret also held by local authentication entity 1122. Based on local authentication vector 1116, local authentication entity 1122 performs a local authentication process 1128 for mutual authentication between local authentication entity 1122 and 6G device 706. Upon successful authentication, local authentication entity 1122 and 6G device 706 maintain a device context 1126, which indicates, for example, the authentication status of 6G device 706, device type, connectivity / mobility type, device ID, supported algorithms(s), authentication keys(s), policies, security configurations, etc.

[0094] Figure 11BThis is a diagram illustrating the local authentication process 1128 in an exemplary embodiment. The local authentication process 1128 may be based on a newly defined key referred to herein as the local authentication key 1140 (AUTH key). The local authentication key 1140 (also referred to as the root key, local authentication root key, 6G local authentication anchor key, etc.) is generated or derived by the 6G device 706 and its home network 1104. The home network 1104 (e.g., 6G AUS NF 710 and / or 6G UDM NF 718) stores multiple long-term keys associated with the 6G device 706 for authentication and security association establishment purposes, as the home network 1104 is considered a secure environment. The local authentication key 1140 is derived for local authentication 1112. Therefore, the local authentication entity 1122 obtains, receives, or otherwise acquires the local authentication key 1140 from the home network 1104. The local authentication entity 1122 may then generate or derive the local authentication vector 1116. The local authentication vector 1116 may include a challenge to the 6G device 706 to prove possession of the shared secret. For example, the local authentication entity 1122 may use the local authentication key 1140 as an input parameter to a key derivation function (KDF), and other input parameters (as needed), to generate an expected response (XRES) 1142 from the 6G device 706. The expected response 1142 may represent a challenge 1146 to the 6G device 706. The local authentication entity 1122 may send a local authentication request 1152 to the 6G device 706. The 6G device 706 derives the local authentication key 1140 in the same manner as the home network 1104. The 6G device 706 may use the local authentication key 1140 as an input parameter to the KDF, and other input parameters (as needed), to generate a response (RES) 1144 from the 6G device 706. Response 1144 can represent a challenge response 1148 from 6G device 706. 6G device 706 can send a local authentication response 1153 containing response 1144 to local authentication entity 1122. Local authentication entity 1122 compares response 1144 with the expected response 1142 and considers local authentication successful if the values ​​are equal. While an example of local authentication process 1128 is provided above, other local authentication processes are also considered in this document.

[0095] Figure 11CThis diagram illustrates home authentication 1110 and local authentication 1112 in an exemplary embodiment. The node, server, network function, device, etc., that operates as local authentication entity 1122 to perform local authentication 1112 may depend on one or more factors, as will be described in more detail below. In one embodiment, a 6G RAN node 804 may act as or serve as local authentication entity 1122 for a 6G device 706. In one embodiment, a 6G MM NF 712 may act as or serve as local authentication entity 1122 for a 6G device 706. In one embodiment, a 6G SM NF 714 may act as or serve as local authentication entity 1122 for a 6G device 706. In another embodiment, a 6G UP NF 740 may act as or serve as local authentication entity 1122 for a 6G device 706. The 6G device 706 stores subscription credentials 1132, such as a device identifier (ID) 1130, a long-term key 1134, etc., as well as other credentials used for local authentication 1112. Similarly, the local authentication entity 1122 can be pre-configured or obtained by the 6G device 706 for local authentication 1112. In some scenarios, the home network authentication entity 1120 can perform home authentication 1110 for the 6G device 706.

[0096] Figures 12A-12D The illustration shows local authentication 1112 in an exemplary embodiment. Local authentication 1112, or more specifically, the authentication process used for local authentication 1112, may depend on local authentication entity 1122. The 6G device 706 may be configured or pre-configured to perform multiple local authentication processes 1128. Local authentication processes 1128 may be different or dependent on local authentication entity 1122. Figure 12A In this context, the local authentication entity 1122 includes the 6G RAN node 804. Therefore, the local authentication process 1128 may include a 6G RAN node authentication process 1202 performed between the 6G RAN node 804 and the 6G device 706. The 6G RAN node authentication process 1202 can be customized or tailored for authentication of the 6G RAN node 804. Figure 12B In this context, the local authentication entity 1122 includes a 6G MM NF 712. Therefore, the local authentication process 1128 may include a 6G MM NF authentication process 1204 performed between the 6G MM NF 712 and the 6G device 706. The 6G MM NF authentication process 1204 can be customized or tailored for authentication of the 6G MM NF 712. Figure 12CIn this context, the local authentication entity 1122 includes a 6G SM NF 714. Therefore, the local authentication process 1128 may include a 6G SM NF authentication process 1206 performed between the 6G SM NF 714 and the 6G device 706. The 6G SM NF authentication process 1206 can be customized or tailored for authentication of the 6G SM NF 714. Figure 12D In this context, the local authentication entity 1122 includes a 6G UP NF 740. Therefore, the local authentication process 1128 may include a 6G UP NF authentication process 1208 performed between the 6G UP NF 740 and the 6G device 706. The 6G UP NF authentication process 1208 may be customized or tailored for authentication of the 6G UP NF 740. Although the local authentication processes 1128 may differ as described above, in some embodiments, there may be overlap or similarity between local authentication processes 1128.

[0097] Figure 13 The illustration shows a registration request 1101 in an exemplary embodiment. Registration request 1101 may include information about the 6G device, device capability information, supported network features, etc. The message content 1302 of registration request 1101 includes multiple information elements (IEs) 1304. Information elements 1304 of registration request 1101 may be defined to be used to hide a device identifier (ID) 1310. The hidden device ID 1310 is an identifier designed to protect the privacy of the device ID 1130 of the 6G device 706. In one embodiment, device ID 1130 may include the SUPI of the 6G device 706 (also known as extended SUPI, 6G SUPI, etc.), and hidden device ID 1310 may include extended SUCI 1320 (also known as 6G SUCI). Information elements 1304 of hidden device ID 1310 may be mobile identification information elements or newly defined information elements for registration request 1101.

[0098] In one embodiment, information element 1304 of registration request 1101 may be defined for or include a device type indicator 1312. Device type indicator 1312 (also called product type indicator or device type indicator) is data, information, etc., indicating the type of 6G device. Information element 1304 of device type indicator 1312 may be a newly defined information element for registration request 1101, and registration request 1101 may be extended to include this information element 1304. The device type indicator 1312 in registration request 1101 can be selected from multiple predefined or enumerated device types. Figure 14This diagram illustrates the definition of device type 1400 in an exemplary embodiment. The definition of device type 1400 may include type name 1402, type definition 1404, description 1406, etc. In one embodiment, device type 1400 may include one or more of the following: 6GUE device type 1412, 6G IoT device type 1414, 6G gaming device type 1416, 6G UAV device type 1418, 6G industrial device type 1420, and 6G cloud data center device type 1422. However, alternative or additional device / product / device types may be included as needed.

[0099] In one embodiment, the information element 1304 of the registration request 1101 may be defined for or include a mobility type indicator 1314 (also referred to herein as a connection type indicator). The mobility type indicator 1314 is data, information, etc., indicating the mobility type of the 6G device or the registration of the 6G device. The mobility type of the 6G device is a characteristic indicating the device mobility level for registration of the 6G device.

[0100] Information element 1304 for mobility type indicator 1314 can be a newly defined information element for registration request 1101, and registration request 1101 can be extended to include information element 1304. Mobility type indicator 1314 in registration request 1101 can be selected from multiple predefined or enumerated mobility types. Figure 15This diagram illustrates the definition of mobility type 1500 in an exemplary embodiment. The definition of mobility type 1500 may include type name 1502, type definition 1504, description 1506, etc. In one embodiment, mobility type 1500 may include one or more of the following: fixed mobility type 1512, restricted mobility type 1514, high mobility type 1516, and variable mobility type 1518. However, alternative or additional mobility types may be included as needed. Different mobility types 1500 may be distinguished based on the movement of the 6G device 706 between different nodes or network functions. For example, fixed mobility type 1512 may indicate that the 6G device 706 is connected to the same 6G RAN node 804 (e.g., 6G NB 708). In other words, the 6G device 706 registers an indication that the device's location is limited to the service or coverage area of ​​the 6G RAN node 804 and that it will not move between 6G RAN nodes 804. Restricted mobility type 1514 indicates that 6G device 706 can move between 6G RAN nodes 804, but is connected to the same 6G MM NF 712. In other words, 6G device 706 registers an indication that even if it moves between 6G RAN nodes 804, the movement is limited to the service or coverage area of ​​6G MM NF 712. High mobility type 1516 indicates that 6G device 706 can move between 6G RAN nodes 804 and 6G MM NF 712 in the same PLMN or different PLMNs. In other words, 6G device 706 registers an indication that the movement will not be limited to the service or coverage area of ​​6G RAN nodes 804, nor to the service or coverage area of ​​6G MM NF 712. Variable mobility type 1518 indicates that 6G device 706 can register as fixed mobility type 1512 or non-fixed mobility type (e.g., restricted mobility type 1514 or high mobility type 1516).

[0101] Figure 16Different use cases 1600 in an exemplary embodiment are illustrated. The 6G network can serve different types of 6G devices 706, each with specific use cases and different resource requirements. For example, a UE device 720 (e.g., a smartphone) can have various use cases. The UE device 720 can be considered a highly mobile device that can connect to different 6G RAN nodes 804 or 6G MM NF 712 while on the move. Therefore, the local authentication entity 1122 may not be applicable to the UE device 720. The UE device 720 can authenticate to the home network authentication entity 1120 of the 6G home network (HN) 1104. An IoT device 722 (such as a sensor, a remote patient monitoring system, etc.) can have use cases involving limited data transmission (no large amounts of data transmission). The IoT device 722 can be considered a fixed device connected to the same 6G RAN node 804. Therefore, the local authentication entity 1122 of the IoT device 722 can include the 6G RAN node 804. Gaming device 724, such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and / or other types of XR or online gaming headsets, can have use cases involving low-latency, high-bandwidth communication. Gaming device 724 can be considered a variable connectivity device, meaning that gaming device 724 can have fixed mobility or restricted / high mobility. For example, gaming device 724 used at home can be registered as fixed mobility type 1512. When gaming device 724 is used outside the home (e.g., travel, treasure hunt, or treasure hunt games) and may frequently move between different 6G RAN nodes 804, gaming device 724 can be registered as a restricted or high mobility type. Therefore, the local authentication entity 1122 of gaming device 724 can include 6G SM NF 714 or 6G UP NF 740. UAV device 726 can be considered a restricted mobility device that can move between different 6G RAN nodes 804 but is typically connected to the same 6G MM NF 712. Therefore, the local authentication entity 1122 of UAV device 726 may include 6G MM NF 712. Industrial device 728 (such as an industrial robot) may have use cases involving industrial automation for controlling manufacturing processes and / or infrastructure. Industrial device 728 can be considered as a restricted mobility device that can move between different 6G RAN nodes 804 but is typically connected to the same 6G MM NF 712. Therefore, the local authentication entity 1122 of industrial device 728 may include 6G MM NF 712.

[0102] Figures 17A-17BThis is a flowchart illustrating a method 1700 for performing adaptive registration in an exemplary embodiment. The steps of method 1700 will be described with reference to 6G device 706, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc. The steps in the flowchart described herein are not exhaustive, but may include other steps not shown, and these steps may be performed in an alternative order.

[0103] exist Figure 17A In this process, 6G device 706 performs registration procedure 1102 (i.e., adaptive registration 1100) to register with home network 1104 to access the services of home network 1104 (step 1702). To this end, 6G device 706 formats registration request 1101, which includes at least a hidden device ID 1310 and also includes a device type indicator 1312 and / or a mobility type indicator 1314 (step 1704). Then, 6G device 706 sends registration request 1101 to home network 1104 (step 1706). For example, 6G device 706 sends registration request 1101 to serving 6G RAN node 804. In response to registration request 1101, the network determines or identifies the authentication type for 6G device 706. For example, the network may decide to perform home authentication 1110 for 6G device 706, such as based on device type indicator 1312 and / or mobility type indicator 1314. In another example, the network may decide to perform local authentication 1112 on the 6G device 706, such as based on the device type indicator 1312 and / or mobility type indicator 1314. The 6G device 706 may have similar logic to determine the authentication type of the 6G device 706 based on the device type indicator 1312 and / or mobility type indicator 1314 (step 1708). When local authentication 1112 is not selected or determined, the 6G device 706 performs the authentication of the registration process 1102 by performing home authentication 1110 with the home network authentication entity 1120 (step 1710). When local authentication 1112 is selected or determined, the 6G device 706 performs the authentication of the registration process 1102 by performing local authentication 1112 with the local authentication entity 1122 (i.e., in the serving network 1106) rather than the home network authentication entity 1120 in the home network 1104 (step 1712).

[0104] For local authentication 1112, 6G device 706 can select a local authentication process 1128 (optional step 1714) for local authentication entity 1122. For example, depending on the type of network entity acting as local authentication entity 1122, 6G device 706 can select 6G RAN node authentication process 1202, 6G MM NF authentication process 1204, 6G SM NF authentication process 1206, 6G UP NF authentication process 1208, etc. Therefore, 6G device 706 can select local authentication process 1128 based on at least one of device type indicator 1312 and mobility type indicator 1314. 6G device 706 derives or generates a local authentication key 1140 (step 1716). 6G device 706 can derive several keys as part of a security mechanism. Local authentication key 1140 is derived for authentication with local authentication entity 1122 (rather than home network authentication entity 1120). Examples of deriving local authentication key 1140 are provided in more detail below. The 6G device 706 responds to a challenge 1146 from the local authentication entity 1122 (step 1718) based on the local authentication key 1140. For example, the local authentication process 1128 may include a challenge 1146 from the local authentication entity 1122 to prove possession of the shared secret (e.g., as...). Figure 11B (As shown in response 1144). The 6G device 706 provides a challenge response 1148 to the local authentication entity 1122 based on the local authentication key 1140 to authenticate itself to the local authentication entity 1122. As part of the local authentication 1112, the 6G device 706 can also issue a challenge to the local authentication entity 1122 to perform mutual authentication based on the local authentication key 1140.

[0105] In one embodiment, the 6G device 706 can perform integrity protection and / or integrity verification of data exchanged with the local authentication entity 1122 based on one or more integrity protection keys derived from the local authentication key 1140 (optional step 1720). For example, if a NAS context is established, the 6G device 706 can derive K NASint Keys, etc., are used for integrity protection of NAS signaling with the 6GMM NF 712. The 6G device 706 can derive K... RRCint Keys, etc., are used for integrity protection of RRC signaling with 6G RAN node 804. 6G device 706 can derive K. UPint Keys, etc., are used for integrity protection of UP traffic with 6G RAN node 804. After local authentication 1112, 6G device 706 can perform encryption and / or decryption of data exchanged with the network based on one or more encryption keys derived from local authentication key 1140.

[0106] In one embodiment, the 6G device 706 maintains a device context 1126 with the local authentication entity 1122 (step 1722). The device context 1126 may include the registration status of the 6G device 706 (e.g., registration or deregistration), the authentication status of the 6G device 706 for local authentication 1112, a local authentication key 1140, an integrity protection key, etc. For example, the 6G device 706 may store the local authentication key 1140 in the device context 1126 for a configurable period of time, after which the 6G device 706 may derive a new or fresh local authentication key 1140.

[0107] One technical advantage is that the 6G device 706 is able to perform local authentication 1112 with the local authentication entity 1122, which reduces the load on the home network 1104 and reduces signaling overhead.

[0108] exist Figure 17B In this context, performing local authentication 1112 with local authentication entity 1122 (see step 1712) can depend on the entity type of local authentication entity 1122. For example, when device type indicator 1312 indicates that 6G device 706 includes 6G IoT device 722 and / or mobility type indicator 1314 indicates that 6G device 706 has a fixed mobility type 1512, 6G device 706 can perform local authentication 1112 with 6G RAN node 804 (optional step 1732). When device type indicator 1312 indicates that 6G device 706 includes 6G UAV device 726 and / or mobility type indicator 1314 indicates that 6G device 706 has a restricted mobility type 1514, 6G device 706 can perform local authentication 1112 with 6G MM NF 712 (optional step 1734). When device type indicator 1312 indicates that 6G device 706 includes 6G gaming device 724 and / or mobility type indicator 1314 indicates the variable mobility type 1518 of 6G device 706, 6G device 706 can perform local authentication 1112 with 6G SM NF 714 (optional step 1736). When device type indicator 1312 indicates that 6G device 706 includes 6G gaming device 724 and / or mobility type indicator 1314 indicates the variable mobility type 1518 of 6G device 706, 6G device 706 can perform local authentication 1112 with 6G UP NF 740 (optional step 1738). One technical advantage is that 6G device 706 can adapt to different types of local authentication 1112.

[0109] Figures 18A-18CThis is a flowchart illustrating an exemplary embodiment of a method 1800 for performing adaptive registration. The steps of method 1800 will be described with reference to 6G network entities, 6G network nodes, 6G devices, such as 6G RAN node 804, 6G MM NF 712, 6G SM NF 714, 6G UP NF 740, etc. A network entity (i.e., the network entity serving network 1106) receives a registration request 1101 initiated by 6G device 706 for accessing services of the home network 1104 of 6G device 706 (step 1802). In response to the registration request 1101, the network entity determines whether to operate as a local authentication entity 1122 of 6G device 706 (step 1804). When it is determined that it is not necessary to operate as a local authentication entity 1122, the network entity does not perform local authentication 1112 (step 1806). When it is determined that the network entity will operate as a local authentication entity 1122, the network entity initiates local authentication 1112 (step 1808) for the 6G device 706.

[0110] For local authentication 1112, local authentication entity 1122 removes the hidden device ID 1310 for the 6G device 706 included in registration request 1101 (step 1810). Based on the removed device identifier 1130, local authentication entity 1122 obtains the local authentication key 1140 from the home network authentication entity 1120 in the home network 1104 of the 6G device 706 (step 1812). Based on the local authentication key 1140, local authentication entity 1122 performs local authentication 1112 for the 6G device 706 (step 1814). For example, local authentication entity 1122 may issue a challenge 1146 to the 6G device 706 based on the local authentication key 1140 (step 1816). Local authentication entity 1122 verifies the challenge response 1148 from the 6G device 706 to authenticate the 6G device 706 (step 1818). As part of local authentication 1112, 6G device 706 can also send a challenge to local authentication entity 1122 for mutual authentication.

[0111] In one embodiment, local authentication entity 1122 may perform integrity protection and / or integrity verification of data exchanged with 6G device 706 based on one or more integrity protection keys derived from local authentication key 1140 (optional step 1820). For example, local authentication entity 1122 may derive K NASint Keys, etc., are used for integrity protection of NAS signaling, such as when local authentication entity 1122 includes 6G MM NF 712. Local authentication entity 1122 can derive K. RRCint Keys, etc., are used for integrity protection of RRC signaling, and / or to derive K. UPintKeys, etc., are used for integrity protection of UP traffic, such as when the local authentication entity 1122 includes 6G RAN node 804.

[0112] In one embodiment, the local authentication entity 1122 maintains a device context 1126 with the 6G device 706 (step 1822). The device context 1126 may include the registration status of the 6G device 706 (e.g., registration or deregistration), the authentication status of the 6G device 706 used for local authentication 1112, a local authentication key 1140, an integrity protection key, etc. For example, the local authentication entity 1122 may store the local authentication key 1140 in the device context 1126 for a configurable period of time, after which the local authentication entity 1122 may obtain a new or updated local authentication key 1140.

[0113] One technical advantage is that the local authentication entity 1122 is able to perform local authentication 1112 for the 6G device 706, which reduces the load on the home network 1104 and reduces signaling overhead.

[0114] exist Figure 18B In this process, determining whether to act as the local authentication entity 1122 may depend on one or more factors (see step 1804). In one embodiment, the network entity may store determination logic pre-configured on the network entity (step 1832). The determination logic may allow the network entity to determine whether it is authorized or qualified to act as the local authentication entity 1122 of the 6G device 706. The network entity may use the determination logic to determine whether to operate as the local authentication entity 1122 based on the device type indicator 1312 and / or mobility type indicator 1314 contained in the registration request 1101 (step 1834). Alternatively or additionally, the network entity may send an authorization request to another network function containing the de-hidden device ID 1130 of the 6G device 706 and an identifier for the requesting network entity (step 1836), and receive an authorization response from the network function containing authorization to perform local authentication 1112 of the 6G device 706 (step 1838). For example, assume the network entity includes a 6G RAN node 804. In determining whether a 6G RAN node 804 should act as a local authentication entity 1122, the 6G RAN node 804 may send an authorization request to the 6G MM NF 712, which includes the dehidden device ID 1130 of the 6G device 706 and the node identifier of the 6G RAN node 804, and receive an authorization response from the 6G MM NF 712, which includes authorization to perform local authentication 1112 for the 6G device 706. Although some examples are given, network entities may determine whether to act as a local authentication entity 1122 in other ways.

[0115] exist Figure 18C In this process, the local authentication entity 1122 can obtain the local authentication key 1140 through various methods (see step 1812). In one embodiment, the local authentication entity 1122 can send a key request to the home network authentication entity 1120 in the home network 1104, the key request containing information such as the dehidden device ID 1130 of the 6G device 706 (step 1842), and receive a key response containing the local authentication key 1140 derived by the home network authentication entity 1120 (step 1844). As described above, the network entity can send an authorization request to another network function, the authorization request containing the dehidden device ID 1130 of the 6G device 706 and an identifier for the requesting network entity (see step 1844). Figure 18B (Step 1836 in the original text). In one embodiment, the local authentication entity 1122 may receive the local authentication key 1140 derived by the home network authentication entity 1120 in the authorization response (step 1846). Although some examples are given, the local authentication entity 1122 may obtain the local authentication key 1140 in other ways.

[0116] The following describes how the local authentication key 1140 is derived. Figures 19A-19D This is a block diagram illustrating the generation of the local authentication key 1140 (AUTH key) in an exemplary embodiment. As described above, the home network authentication entity 1120 (e.g., 6G AUSNF 710 and / or 6G UDM NF 718) and the 6G device 706 are configured to generate or derive the local authentication key 1140. The home network authentication entity 1120 may derive the local authentication key 1140 in response to a request from the 6G RAN node 804 or 6G NF 705, which acts as the local authentication entity 1122. The 6G device 706 may derive the local authentication key 1140 for the registration process in response to a challenge from a network entity, etc. Typically, the local authentication key 1140 is derived based on one or more newly defined key derivation functions (KDFs), as described herein. Figure 19AThe diagram illustrates a KDF1900 configured to generate a local authentication key 1140. The input parameters 1902 of the KDF 1900 may include at least the long-term key 1134 of the 6G device 706, the serving network name (SNN) 1906, the device ID 1130 of the 6G device 706, and the entity ID 1910 of the local authentication entity 1122. The long-term key 1134(K) is a key stored in the 6G device 706 and the home network 1104 for the subscriber, also known as a permanent subscriber key, subscriber master key, operator-configured subscriber key, etc. The SNN 1906 is the name or identifier of the serving network 1106, such as the 6G:PLMN-ID of the serving PLMN, although other network identifiers are considered herein. Device ID 1130 can be, for example, IoT Device ID 1922 for IoT device 722, Game Device ID 1924 for gaming device 724, UAV Device ID 1926 for UAV device 726, or some other identifier for 6G device 706. Entity ID 1910 can include the entity type or identifier of locally authenticated entity 1122. A technical advantage is that a local authentication key 1140 specific to local authentication 1112 can be derived.

[0117] exist Figure 19B In the KDF1900, when the 6G RAN node 804 (e.g., 6G NB 708) acts as the local authentication entity 1122, the input parameters 1902 may include at least: a long-term key 1134, an SNN 1906, a device ID 1130 for the 6G device 706, and a 6G NB ID 1912 for the 6G NB 708. The 6G NB ID 1912 may include the entity type or identifier for the 6G NB 708 acting as the local authentication entity 1122. A technical advantage is that a local authentication key 1140 can be derived for the case where the 6G NB 708 acts as the local authentication entity 1122.

[0118] exist Figure 19C In the context of the 6G MM NF 712 acting as the local authentication entity 1122, the input parameters 1902 of the KDF 1900 can include at least the long-term key 1134, the SNN 1906, the device ID 1130 of the 6G device 706, and the 6G MMNF ID 1914 of the 6G MM NF 712. The 6G MM NF ID 1914 can include the entity type or identifier of the 6G MM NF 712 acting as the local authentication entity 1122. A technical advantage is that a local authentication key 1140 can be derived for the case where the 6G MM NF 712 acts as the local authentication entity 1122.

[0119] exist Figure 19DIn the context of the KDF 1900, when the 6G SM NF 714 or 6G UP NF 740 acts as the local authentication entity 1122, the input parameters 1902 may include at least a long-term key 1134, an SNN 1906, a device ID 1130 for the 6G device 706, and a 6G SM NF ID 1916 for the 6G SM NF 714 or a 6G UP NF ID 1918 for the 6G UP NF 740. The 6G SM NF ID 1916 may include the entity type or identifier for the 6G SM NF 714 acting as the local authentication entity 1122. The 6G UP NF ID 1918 may include the entity type or identifier for the 6G UP NF 740 acting as the local authentication entity 1122. One technical advantage is that a local authentication key 1140 can be derived for cases where the 6G SM NF 714 or 6G UP NF 740 acts as the local authentication entity 1122.

[0120] Figure 20 This is a flowchart illustrating a method 2000 for generating or deriving a local authentication key 1140 in an exemplary embodiment. The steps of method 2000 will be described with reference to 6G device 706, but it should be understood that this method can be performed in other devices, components, functions, systems, etc.

[0121] The 6G device 706 derives a local authentication key 1140 (step 2002). When deriving the local authentication key 1140, the 6G device 706 identifies the input parameter 1902 configured to generate the local authentication key 1140 using the KDF 1900 (step 2004). As described above, the 6G device 706 can identify the input parameter 1902 as at least the long-term key 1134, the SNN 1906, the device ID 1130 of the 6G device 706, and the entity ID 1910 of the local authentication entity 1122 (optional step 2006). In other embodiments, other input parameters 1902 can be used. The 6G device 706 inputs the input parameter 1902 into the KDF 1900 to generate or derive the local authentication key 1140 (step 2008). After generating the local authentication key 1140, the 6G device 706 can use the local authentication key 1140 to perform local authentication 1112 with the local authentication entity 1122 (step 2010). For example, 6G device 706 can respond to a challenge 1146 from local authentication entity 1122 based on local authentication key 1140. Local authentication process 1128 may include a challenge 1146 from local authentication entity 1122 to prove possession of the shared secret. 6G device 706 can provide a challenge response 1148 to local authentication entity 1122 based on local authentication key 1140 to authenticate itself to local authentication entity 1122. As part of local authentication 1112, 6G device 706 can also issue a challenge to local authentication entity 1122 for mutual authentication based on local authentication key 1140. 6G device 706 can perform integrity protection and / or integrity verification of data exchanged with local authentication entity 1122 based on one or more integrity protection keys derived from local authentication key 1140 (optional step 2012). One technical advantage is that 6G device 706 is able to derive the local authentication key 1140 involved in local authentication 1112.

[0122] Figure 21 This is a flowchart illustrating an exemplary embodiment of a method 2100 for generating or deriving a local authentication key 1140. The steps of method 2100 will be described with reference to a home network authentication entity 1120 (such as a 6G AUS NF 710 and / or a 6G UDM NF 718), but it should be understood that the method can be performed in other devices, components, functions, systems, etc.

[0123] Home network authentication entity 1120 receives a request for local authentication key 1140 for 6G device 706 (step 2102), such as a request initiated by local authentication entity 1122. In one embodiment, home network authentication entity 1120 may receive a request for local authentication key 1140 initiated by 6G RAN node 804 (e.g., 6G NB 708) operating as local authentication entity 1122 for 6G device 706 (optional step 2104). In one embodiment, home network authentication entity 1120 may receive a request for local authentication key 1140 initiated by 6G MM NF 712 operating as local authentication entity 1122 for 6G device 706 (optional step 2106). In one embodiment, home network authentication entity 1120 may receive a request for local authentication key 1140 initiated by 6G SM NF 714 operating as local authentication entity 1122 for 6G device 706 (optional step 2108). In another embodiment, the home network authentication entity 1120 may receive a request for the local authentication key 1140 initiated by the 6G UP NF 740, which operates as the local authentication entity 1122 for the 6G device 706 (optional step 2110).

[0124] In response to the request, Home Network Authentication Entity 1120 derives a local authentication key 1140 (step 2112). When deriving the local authentication key 1140, Home Network Authentication Entity 1120 is identified as input parameter 1902 of the KDF 1900 used to generate the local authentication key 1140 (step 2114). As described above, Home Network Authentication Entity 1120 may identify input parameter 1902 as at least a long-term key 1134, an SNN 1906, a device ID 1130 for the 6G device 706, and an entity ID 1910 for the local authentication entity 1122 (optional step 2116). In other embodiments, other input parameters 1902 may be used. Home Network Authentication Entity 1120 inputs input parameter 1902 into the KDF 1900 to generate or derive the local authentication key 1140 (step 2118). The home network authentication entity 1120 can then send a response with the local authentication key 1140 to the local authentication entity 1122 (step 2120). As mentioned above, the home network authentication entity 1120 does not maintain the device context 1126 regarding the local authentication 1112. Therefore, after sending the response, the home network authentication entity 1120 can delete the local authentication key 1140 (optional step 2122). One technical advantage is that the home network authentication entity 1120 can derive the local authentication key 1140 for other entities acting as the local authentication entity 1122 without further involvement in authentication, thus saving bandwidth and computing resources.

[0125] The following describes the extended device ID of the 6G device 706 in the exemplary embodiment, which may be referred to as extended SUPI and extended SUCI 1320 (see also...). Figure 13 ). Figure 22A The illustration shows the traditional SUPI 2200 in 5G. SUPI 2200 is a globally unique, permanent 5G subscription identifier assigned to each subscriber in a 5G system. The traditional SUPI 2200 is defined as SUPI type 2202, and a subscription or device identifier 2204 depending on the value of SUPI type 2202. Identifier 2204 can include the International Mobile Subscription Identifier (IMSI) 2206, a Network Specific Identifier (NSI) in the form of a Network Access Identifier (NAI) 2208, a Global Line Identifier (GLI) 2210, or a Global Cable Identifier (GCI) 2212. SUPI type 2202 is a value 2224 in the range of "0 to 7". The value 2224 for SUPI type 2202 is as follows: “0”: IMSI; “1”: NSI; "2": GLI; "3": GCI; and "4 to 7": Reserved values ​​for future use.

[0126] This article describes globally unique subscription identifiers for next-generation networks such as 6G. Figure 22BAn extended SUPI 2230 for next-generation networks is illustrated in an exemplary embodiment. The extended SUPI 2230 may be an extension of the conventional SUPI 2200 as described above, and may also be referred to as an enhanced SUPI, 6G SUPI, etc. The extended SUPI 2230 is an example of the device ID 1130 described above. In one embodiment, the extended SUPI 2230 is defined as SUPI type 2202 and a subscription or device identifier 2204 depending on the value of SUPI type 2202. In this embodiment, identifier 2204 may also include an IoT device identifier (ID) 1922, a gaming device ID 1924, and / or a UAV device ID 1926, but other identifiers 2204 are also considered herein. IoT device ID 1922, gaming device ID 1924, and UAV device ID 1926 may include an extension 2228 of the conventional SUPI 2200. IoT device ID 1922 includes an identifier defined for IoT device 722. Game Device ID 1924 includes an identifier defined for Game Device 724. UAV Device ID 1926 includes an identifier defined for UAV Device 726. The formats of IoT Device ID 1922, Game Device ID 1924, and / or UAV Device ID 1926 can be varied as needed.

[0127] As mentioned above, as an example, SUPI type 2202 can be a value 2224 within the range of "0 to 7". The value 2224 of SUPI type 2202 can be as follows: “0”: IMSI; “1”: NSI; "2": GLI; “3”: GCI; “4”: IoT device ID; "5": UAV device ID; "6": Game device ID; and "7": Reserved.

[0128] The value 2224 for IoT Device ID 1922, Gaming Device ID 1924, and UAV Device ID 1926 is provided as an example and can be selected as needed. When SUPI type 2202 is a value 2224 in the range of "0 to 7", any of the IoT Device ID 1922, Gaming Device ID 1924, and UAV Device ID 1926 can be in the range of "4 to 7" 2226. One technical advantage is that SUPI 2230 is extended to include identifiers for other types of devices.

[0129] Figure 23AThe illustration shows a legacy SUCI 2300 in 5G. A SUCI is a privacy-preserving identifier that contains a hidden SUPI. A legacy SUCI 2300 includes a SUPI type 2202 identifying the type of SUPI hidden within the SUCI 2300 and a Home Network Identifier 2304 identifying the subscriber's home network. The legacy SUCI 2300 also includes a routing indicator 2306, which includes one to four decimal numbers assigned by the home network operator and supplied in the USIM, allowing network signaling with the SUCI 2300, along with the Home Network Identifier 2304, to be routed to AUSF 210 and UDM 218 instances capable of serving the subscriber. The traditional SUCI 2300 also includes a protection scheme identifier 2308 and a home network public key identifier 2310. The protection scheme identifier includes values ​​in the range of "0 to 15", and the home network public key identifier includes values ​​in the range of "0 to 255". The home network public key identifier represents the public key supplied by an HPLMN or Independent Non-Public Network (SNPN) and used to identify the key used for SUPI protection. The traditional SUCI 2300 also includes a scheme output 2312, which includes a string of variable-length or hexadecimal numbers, depending on the protection scheme used. Scheme output 2312 represents the output of a protection scheme (e.g., a public key protection scheme) that is cryptographically or cryptographically protected SUPI 2200.

[0130] This article describes a hidden subscription identifier for next-generation networks, such as 6G. Figure 23BThe illustration shows an extended SUCI 1320 for a next-generation network in an exemplary embodiment. The extended SUCI 1320 can be an extension of the conventional SUCI 2300 as described above, and may also be referred to as an enhanced SUCI, 6G SUCI, etc. In one embodiment, similar to the conventional SUCI 2300, the extended SUCI 1320 may consist of the following components: SUPI type 2202, home network identifier 2322, routing indicator 2324, protection scheme identifier 2326, and scheme output 2330. In this embodiment, the extended SUCI 1320 may also consist of a network type indicator 2320 and a network public key identifier 2328, but other components are also considered herein. The network type indicator 2320 identifies the type of network entity, network node, or network targeted for or authorized to de-hide the extended SUCI 1320. The network type indicator 2320 may be an enumeration value (e.g., 0, 1, 2, 3, ...) specifying the network entity to be de-hidden in the extended SUCI 1320. For example, when 6G RAN node 804 is authorized to hide extended SUCI 1320, network type indicator 2320 can be a value indicating 6G RAN node 804 (e.g., SUCI-gNB="1"). When 6G MM NF 712 is authorized to hide extended SUCI 1320, network type indicator 2320 can be a value indicating 6G MM NF 712 (e.g., SUCI-MM NF="2"). When 6G SM NF 714 is authorized to hide extended SUCI 1320, network type indicator 2320 can be a value indicating 6GSM NF 714 (e.g., SUCI-SM NF="3"). When 6G UP NF 740 is authorized to hide extended SUCI 1320, network type indicator 2320 can be a value indicating 6G UP NF 740 (e.g., SUCI-UP NF="4"). When the 6G SEAF is authorized to hide the extended SUCI 1320, the network type indicator 2320 can be a value indicating the 6G SEAF (e.g., SUCI-SEAF="5"). When the 6G HN 1104 is authorized to hide the extended SUCI 1320, the network type indicator 2320 can be a value indicating the 6G HN 1104 (e.g., SUCI-HN="0"). Alternatively, the network type indicator 2320 can identify the type of network, such as an access network or RAN, a serving network, a home network, etc., and the determination of which specific network entity is authorized to hide the extended SUCI 1320 is made on the network side. The network public key identifier 2328 (which can replace the home network public key identifier 2310) includes a value representing the public key of the network entity used for SUPI protection (e.g., in the range of "0 to 255").This means that the corresponding private key can be used to authenticate entities to hide SUPI. One technical advantage is that SUCI 1320 has been extended to include identifiers for other types of devices.

[0131] Figure 24 This diagram illustrates the definition of network type 2400 in an exemplary embodiment. The definition of network type 2400 may include type name 2402, type definition 2404, description 2406, etc. In one embodiment, network type 2400 may include one or more of the following: RAN node type 2412 (e.g., SUCI-gNB), 6G MM NF type 2414 (e.g., SUCI-MM NF), 6G SM NF type 2416 (e.g., SUCI-SM NF), 6G UP NF type 2418 (e.g., SUCI-UPNF), and 6G Home Network (HN) type 2420 (e.g., SUCI-HN). However, alternative or additional network types (e.g., 6G security anchor function (e.g., SUCI-SEAF)) or generic network entity types (e.g., SUCI-AN, SUCI-SN, SUCI-HN, etc.) may be included as needed.

[0132] exist Figure 23B In this embodiment, the output 2330 may consist of a temporary public key 2332, a ciphertext value 2334, and a MAC tag value 2336. The ciphertext value 2334 contains more information than the information encrypted in a conventional SUCI 2300. In a conventional SUCI 2300, the ciphertext value is an encrypted SUPI 2200. In the embodiments described herein, the ciphertext value 2334 may include at least the following encrypted data: an extended SUPI 2230, and one or both of a device type indicator 1312 and a mobility type indicator 1314. However, other data may be encrypted in the ciphertext value 2334 as needed.

[0133] Figures 25A-25B The SUPI hiding and unhiding in exemplary embodiments are illustrated separately. For example, in Figure 25AIn the 6G device 706, a key pair (temporary public key 2332 and private key 2532) is generated using key pair generation primitives. Based on Diffie-Hellman primitives, a shared key 2536 is derived from the network entity's public key 2534 and the generated temporary private key 2532. Subsequently, a key data K is generated using a key derivation function (KDF), which includes an encryption key (EK), an initial counter block (ICB) key, and a MAC key. Using the derived keys EK and ICB, symmetric encryption is performed to encrypt a plaintext block 2502 to generate a ciphertext value 2334. The MAC scheme's tagging operation is used to calculate the MAC tag value 2336 of the encrypted text using the generated MAC key. In the conventional SUCI 2300, only SUPI will be included in the encrypted plaintext block 2502. In this embodiment, the extended SUPI 2230, and one or both of the device type indicator 1312 and mobility type indicator 1314 are also included in the plaintext block 2502 and encrypted to generate the ciphertext value 2334.

[0134] For example, in Figure 25B In this process, the de-hiding function (e.g., in local authentication entity 1122 or home network authentication entity 1120) uses the received temporary public key 2332 and the network entity's private key 2538 to generate a temporary shared key 2536. A KDF is used to generate key data K, which includes a decryption key (DK), an ICB key, and a MAC key. The generated DK and ICB keys are used to decrypt the ciphertext value 2334 using symmetric decryption. A temporary MAC key is used on the encrypted text to generate a MAC tag value 2336 (i.e., the expected MAC), which is compared with the received MAC to verify the integrity of the extended SUPI 2230. Therefore, only the entity possessing the network entity's private key 2538 can decrypt the ciphertext value 2334 and de-hid the extended SUPI 2230, as well as one or both of the device type indicator 1312 and mobility type indicator 1314.

[0135] Figure 26This is a flowchart illustrating a method 2600 for hiding a SUPI in an exemplary embodiment. The steps of method 2600 will be described with reference to a 6G device 706, but it should be understood that this method can be performed in other devices, components, functions, systems, etc. The 6G device 706 identifies the SUPI (step 2602), such as the extended SUPI 2230 described above for the 6G device 706. The 6G device 706 hides the SUPI in an extended SUCI 1320, which includes at least a SUPI type 2202, a network type indicator 2320, a network public key identifier 2328, and a scheme output 2330 (step 2604). The 6G device 706 derives the scheme output 2330 (i.e., ciphertext value 2334) by encrypting the SUPI and at least one of the device type indicator 1312 and mobility type indicator 1314 (step 2606). One technical advantage is that the extended SUCI 1320 allows hiding the identifiers of different types of 6G devices 706.

[0136] In the following examples, other processes, systems, and methods can be described within the context of use cases in a 6G environment. The processes, systems, and methods described in these examples can be incorporated into the embodiments described above as needed.

[0137] User equipment

[0138] The following embodiments illustrate a scenario where a 6G device 706 includes a UE device 720 (e.g., a smartphone). Figure 27 This is a diagram illustrating adaptive registration in an exemplary embodiment. Initially, UE device 720 is not registered or authenticated in the network. UE device 720 sends a registration request 2701 to 6G NB 708. Registration request 2701 includes a hidden device ID 1310, which protects the identity of UE device 720 for enhanced privacy. Registration request 2701 also includes one or both of UE device 720's device type indicator 1312 and mobility type indicator 1314. In this example, device type indicator 1312 indicates that the registered 6G device 706 is UE device type 1412, and mobility type indicator 1314 indicates that the registered 6G device 706 is registering as a high mobility type 1516.

[0139] In response to registration request 2701, 6G NB 708 determines whether to act as local authentication entity 1122 for UE device 720 by processing at least one of device type indicator 1312 and mobility type indicator 1314. In this example, a UE device 720 with high mobility means that UE device 720 can connect to different 6G NB 708 when moving. Therefore, 6G NB 708 determines that it will not act as local authentication entity 1122. 6G NB 708 forwards registration request 2701 to 6G MM NF 712 for processing. In response to registration request 2701, 6G MM NF 712 determines whether to act as local authentication entity 1122 for UE device 720 by processing at least one of device type indicator 1312 and mobility type indicator 1314. In this example, a UE device 720 with high mobility means that UE device 720 can connect to different 6G MM NF 712 when moving. Therefore, 6G MM NF 712 determines that it will not act as a local authentication entity 1122. The registration process follows a procedure similar to that of existing 5G systems (5GS), where 6G HN 1104 controls the registration. 6G HN 1104 manages the authentication, authorization, and configuration of UE device 720. 6G HN 1104 maintains the device context 1126 of UE device 720, such as by storing the authentication status, SUPI, authentication result, timestamp, serving network name, etc. of UE device 720.

[0140] IoT devices

[0141] The following embodiments illustrate a scenario where 6G device 706 includes 6G IoT device 722. Figures 28A-28B This is a diagram illustrating adaptive registration in an exemplary embodiment. Figure 29 This is a flowchart illustrating a method 2900 for performing adaptive registration in an exemplary embodiment. The steps of method 2900 will be described with reference to a 6G IoT device 722, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc. Figure 30 This is a flowchart illustrating an exemplary embodiment of a method 3000 for performing adaptive registration. The steps of method 3000 will be described with reference to 6G RAN node 804, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc.

[0142] Initially, the 6G IoT device 722 is not registered or authenticated in the network. Therefore, the 6G IoT device 722 performs a registration process 1102 (i.e., adaptive registration 1100) to register with its home network 1104 (see [link to relevant documentation]). Figure 29Step 2902 in the document. To this end, the 6G IoT device 722 formats a registration request 2801, which includes at least a hidden device ID 1310 (i.e., IoT device ID 1922), and also includes a device type indicator 1312 and / or a mobility type indicator 1314 (see step 2902 in the document). Figure 29 (Step 2904 in the example). In this example, the device type indicator 1312 indicates that the registered 6G device 706 is an IoT device type 1414, and the mobility type indicator 1314 indicates that the registered 6G device 706 is registering as a fixed mobility type 1512. Then, the 6G IoT device 722 sends a registration request 2801 to the serving 6G RAN node 804 (see step 2904 in the example). Figure 29 Step 2906 in the middle.

[0143] The 6G NB 708 receives registration request 2801 sent by the 6G IoT device 722 (see...). Figure 30 Step 3002 in the process. In response to registration request 2801, 6G NB 708 determines whether to operate as a local authentication entity 1122 of 6G IoT device 722 (see step 3002 in the process). Figure 30 Step 3004 in the process). When it is determined that it is not necessary to operate as a local authentication entity 1122, the 6G NB 708 does not perform local authentication 1112 (see step 3004 in the process). Figure 30 Step 3006 in the process). When it is determined that the 6G NB708 will operate as the local authentication entity 1122, the 6G NB708 initiates local authentication 1112 for the 6G IoT device 722 (see step 3006 in the process). Figure 30 (Step 3008 in the example). In this example, the 6G IoT device 722 with fixed mobility indicates that the 6G IoT device 722 will connect to the same 6G NB 708. Therefore, the 6G NB 708 assumes the role of local authentication entity 1122.

[0144] For local authentication 1112, the 6G NB 708 acting as local authentication entity 1122 hides the hidden IoT device ID 1922 of the 6G IoT device 722 contained in registration request 2801 (see [link]). Figure 30 (Step 3010 in the above). For example, IoT device ID 1922 may include the extended SUPI 2230 as described above, and IoT device ID 1922 as extended SUPI 2230 may be hidden in extended SUCI 1320. 6G NB 708 is configured to dehide extended SUPI 2230 from extended SUCI 1320. 6GNB 708 obtains the local authentication key 1140 of 6G IoT device 722 from home network authentication entity 1120 in home network 1104 based on the dehideable IoT device ID 1922 (see step 3010 in the above). Figure 30 (Step 3012 in the document). The process for obtaining the local authentication key 1140 can vary depending on the implementation.

[0145] exist Figure 28AIn this context, the 6G NB 708 can send an authorization request 2802 to the 6G MM NF 712. This authorization request includes the IoT device ID 1922 of the 6G IoT device 722 and network-related identifiers, such as the entity ID 1910 of the 6G NB 708 (e.g., 6G NB ID 1912). In response to authorization request 2802, 6G MM NF 712 can determine whether 6G NB 708 is authorized to act as a local authentication entity 1122 based on IoT device ID 1922, 6G NB ID 1912, configuration parameters, etc. 6G MM NF 712 can also determine whether 6G IoT device 722 is authorized to perform local authentication 1112 based on IoT device ID 1922, 6G NB ID 1912, configuration parameters, etc. 6G MM NF 712 forwards authorization request 2802 (or another type of message) to 6G HN 1104, which contains IoT device ID 1922 and network-related identifiers (e.g., 6G NB ID 1912 and 6G MM NF ID 1914). The message given to 6G HN 1104 is to obtain the local authentication key 1140 when local authentication 1112 is authorized. In response to authorization request 2802, 6G HN 1104 (i.e., home network authentication entity 1120) can determine whether 6G NB 708 is authorized to act as local authentication entity 1122 based on IoT device ID 1922, 6G NB ID 1912, configuration parameters, etc. 6G HN 1104 can also determine whether 6G IoT device 722 is authorized to perform local authentication 1112 based on IoT device ID 1922, 6G NB ID 1912, configuration parameters, etc. When authorized, 6G HN 1104 derives a local authentication key 1140 (AUTH key) and sends an authorization response 2803 to 6G MM NF 712 as needed. This authorization response contains the local authentication key 1140 and any other authorization information from 6G HN 1104. The 6G MM NF 712 forwards an authorization response 2803 to the 6G NB 708. This authorization response contains a local authentication key 1140 and any other authorization information (as needed) from the 6G MM NF 712 and / or the 6G HN 1104. For example, the authorization response 2803 may contain authorization for performing local authentication 1112 for the 6G IoT device 722. The 6G NB 708 receives and stores the local authentication key 1140 derived from the 6G HN 1104. This allows the 6G NB 708 to complete the local authentication 1112 for the 6G IoT device 722. One technical advantage is that this eliminates the need for frequent communication with the centralized 6G HN 1104, saving bandwidth and computing resources.

[0146] exist Figure 28B In this context, when acting as the local authentication entity 1122 for the 6G IoT device 722, the 6G NB 708 has pre-configured access, thus eliminating the need for explicit authorization from the core network. The 6G NB 708 sends a key request 2804 to the 6G HN 1104, containing the IoT device ID 1922 of the 6G IoT device 722. In response to the key request 2804, the 6G HN 1104 derives a local authentication key 1140 (AUTH key) and sends a key response 2805 containing the local authentication key 1140 to the 6G NB 708. The 6G NB 708 receives and stores the local authentication key 1140 derived by the 6G HN 1104. This allows the 6G NB 708 to complete the local authentication 1112 of the 6G IoT device 722. One technical advantage is that this eliminates the need for frequent communication with the centralized 6G HN 1104, saving bandwidth and computing resources.

[0147] After obtaining the local authentication key 1140, the 6G NB 708 performs local authentication 1112 for the 6G IoT device 722 based on the local authentication key 1140 (see...). Figure 30 (Step 3014 in the original text). The local authentication process 1128 may include a customized or custom 6G RAN node authentication process 1202 for authentication between the 6G IoT device 722 and the 6G RAN node 804. As part of the local authentication 1112, the 6G NB 708 may generate a local authentication vector 1116 based on the local authentication key 1140, which includes a challenge 1146 to the 6G IoT device 722 to prove possession of the shared key. The 6G NB 708 issues the challenge 1146 to the 6G IoT device 722 (see step 3014 in the original text). Figure 30 (Optional step 3016 in the text), and verify the challenge response 1148 from the 6G IoT device 722 to authenticate the 6G IoT device 722 (see...). Figure 30 (Optional step 3018). As part of local authentication 1112, the 6G IoT device 722 can also send a challenge to the 6G NB 708 for mutual authentication.

[0148] In one embodiment, the 6G NB 708 can perform integrity protection and / or integrity verification of data exchanged with the 6G IoT device 722 based on one or more integrity protection keys derived from the local authentication key 1140 (see [link to documentation]). Figure 30 (Optional step 3020). Figure 31This is a diagram illustrating integrity protection 3100 in an exemplary embodiment. The 6G IoT device 722 and the 6G NB 708 can use the local authentication key 1140 as an input parameter to the KDF, and other input parameters (as needed), to generate one or more integrity protection keys 3102 (KDF). INT For example, the 6G IoT device 722 and the 6G NB708 can derive K. RRCint Keys, etc., are used for integrity protection of RRC signaling, and / or to derive K. UPint Keys, etc., are used for integrity protection of UP traffic. 6G IoT devices 722 and 6G NB 708 can use (multiple) integrity protection keys 3102 to perform integrity protection and / or integrity verification on access layer (AS) data or messages 3104.

[0149] In one embodiment, the 6G NB 708 maintains device context 1126 with the 6G IoT device 722 (see [link]). Figure 30 (Step 3022 in the process). Device context 1126 may include the registration status of 6G IoT device 722 (e.g., registration or deregistration), the authentication status of 6G IoT device 722 for local authentication 1112, local authentication key 1140, integrity protection key 3102, etc.

[0150] One technological advantage is that the 6G NB 708 is able to perform local authentication 1112 for 6G IoT devices 722, which reduces the load on the home network 1104 and reduces signaling overhead.

[0151] On the device side, the 6G IoT device 722 uses or selects the local authentication process 1128 of the 6G NB 708 (i.e., the 6G RAN node authentication process 1202) to perform local authentication 1112 with the 6G NB 708 (see [link to relevant documentation]). Figure 29 Step 2908 in the process. 6G IoT device 722 derives or generates a local authentication key 1140 (see step 2908 in the process). Figure 29 (Step 2910 in the above). As described above, the 6G NB 708 can issue a challenge 1146 to the 6G IoT device 722 (see step 2910 in the above). Figure 30 (Optional step 3016 in the text). Therefore, the 6G IoT device 722 calculates a challenge response 1148 from the 6G NB 708 to the challenge 1146 based on the local authentication key 1140, and sends the challenge response 1148 to the 6G NB 708 (see [link to relevant documentation]). Figure 29 (Step 2912 in the process). As part of local authentication 1112, the 6G IoT device 722 can also challenge the 6G NB 708 to perform mutual authentication based on the local authentication key 1140.

[0152] In one embodiment, the 6G IoT device 722 may perform integrity protection and / or integrity verification of data exchanged with the 6G NB 708 based on one or more integrity protection keys 3102 derived from the local authentication key 1140 (see [link to documentation]). Figure 29 Optional step 2914), which is in Figure 31 Further details are provided below.

[0153] In one embodiment, the 6G IoT device 722 maintains device context 1126 with the 6G NB 708 (see [link]). Figure 29 (Step 2916 in the process). Device context 1126 may include the registration status of 6G IoT device 722 (e.g., registration or deregistration), the authentication status of 6G IoT device 722 for local authentication 1112, local authentication key 1140, integrity protection key 3102, etc.

[0154] One technological advantage is that the 6G IoT device 722 is able to perform local authentication 1112 with the 6G NB 708, which reduces the load on the home network 1104 and reduces signaling overhead.

[0155] UAV equipment

[0156] The following embodiments illustrate a scenario where the 6G device 706 includes a 6G UAV device 726. Figures 32A-32B This is a diagram illustrating adaptive registration in an exemplary embodiment. Figure 33 This is a flowchart illustrating a method 3300 for performing adaptive registration in an exemplary embodiment. The steps of method 3300 will be described with reference to a 6G UAV device 726, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc. Figure 34 This is a flowchart illustrating an exemplary embodiment of a method 3400 for performing adaptive registration. The steps of method 3400 will be described with reference to 6G MM NF 712, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc.

[0157] Initially, the 6G UAV device 726 was not registered or certified in the network, such as Figure 32A As shown. Therefore, the 6G UAV device 726 performs the registration process 1102 (i.e., adaptive registration 1100) to register with the home network 1104 (see...). Figure 33 (Step 3302 in the previous section). To this end, the 6G UAV device 726 formats a registration request 3201, which includes at least a hidden device ID 1310 (i.e., UAV device ID 1926), and also includes a device type indicator 1312 and / or a mobility type indicator 1314 (see step 3302 in the previous section). Figure 33 (Step 3304 in the example). In this example, the device type indicator 1312 indicates that the registered 6G device 706 is a UAV device type 1418, and the mobility type indicator 1314 indicates that the registered 6G device 706 is registering as a restricted mobility type 1514. Then, the 6G UAV device 726 sends a registration request 3201 to the home network 1104 (see step 3304 in the example). Figure 33 Step 3306 in the process.

[0158] The 6G NB 708 receives a registration request 3201 sent by the 6G UAV device 726. In response to the registration request 3201, the 6G NB 708 can determine whether to operate as a local authentication entity 1122 for the 6G UAV device 726. In this example, the 6G UAV device 726 with restricted mobility indicates that the 6G UAV device 726 can connect to different 6G NBs 708. Therefore, the 6G NB 708 does not assume the role of local authentication entity 1122 and forwards the registration request 3201 to the 6G MM NF 712.

[0159] The 6G MM NF 712 receives a registration request 3201 initiated by the 6G UAV device 726 (see [link]). Figure 34 Step 3402 in the process. In response to registration request 3201, 6G MM NF 712 determines whether to operate as a local authentication entity 1122 of 6G UAV device 726 (see step 3402 in the process). Figure 34 Step 3404 in the document). When it is determined that no local authentication entity 1122 operation is required, 6GMM NF 712 does not perform local authentication 1112 (see step 3404 in the document). Figure 34 Step 3406 in the process. When it is determined that the 6G MM NF 712 is to operate as a local authentication entity 1122, the 6G UAV device 726 initiates local authentication 1112 (see step 3406 in the process). Figure 34 (Step 3408 in the example). In this example, the 6G UAV device 726 with restricted mobility means that even when moving between different 6G NBs 708, the 6G UAV device 726 will connect to the same 6G MM NF 712. Therefore, the 6G MM NF 712 assumes the role of the local authentication entity 1122.

[0160] For local authentication 1112, the 6G MM NF 712 acting as local authentication entity 1122 hides the hidden UAV device ID 1926 of the 6G UAV device 726 contained in the registration request 3201 (see [link]). Figure 34(Step 3410 in the above). For example, UAV device ID 1926 may include extended SUPI 2230 as described above, and UAV device ID 1926 as extended SUPI 2230 may be hidden in extended SUCI 1320. 6G MM NF 712 is configured to dehide extended SUPI 2230 from extended SUCI 1320. 6G MM NF 712 obtains the local authentication key 1140 of 6G UAV device 726 based on the dehiden UAV device ID 1926, such as from the home network authentication entity 1120 in home network 1104 (see step 3410). Figure 34 (Step 3412 in the document). The process for obtaining the local authentication key 1140 can vary depending on the implementation.

[0161] exist Figure 32A In this context, when acting as the local authentication entity 1122 for the 6G UAV device 726, the 6G MM NF 712 can send a key request 3202 to the 6G HN 1104, which includes the UAV device ID 1926 of the 6G UAV device 726. In response to the key request 3202, the 6G HN 1104 derives a local authentication key 1140 (AUTH key) and sends a key response 3203 containing the local authentication key 1140 to the 6G MM NF 712. The 6G MM NF 712 receives and stores the local authentication key 1140 derived by the 6G HN 1104. This allows the 6G MM NF 712 to complete the local authentication 1112 of the 6G UAV device 726. One technical advantage is that this eliminates the need for frequent communication with the centralized 6G HN 1104, saving bandwidth and computing resources.

[0162] exist Figure 32B In this configuration, when acting as the local authentication entity 1122 for the 6G UAV device 726, the 6G MM NF 712 can send a key request 3202 to an external server (such as a UAV service provider (USS) server 3230), which includes the UAV device ID 1926 of the 6G UAV device 726. In response to the key request 3202, the USS server 3230 derives a local authentication key 1140 (AUTH key) and sends a key response 3203 containing the local authentication key 1140 to the 6G MM NF 712. The 6G MM NF 712 receives and stores the local authentication key 1140 derived by the USS server 3230. This allows the 6G MM NF 712 to complete the local authentication 1112 of the 6G UAV device 726. One technical advantage is that this eliminates the need for frequent communication with the USS server 3230, saving bandwidth and computing resources.

[0163] After obtaining the local authentication key 1140, the 6G MM NF 712 performs local authentication 1112 of the 6G UAV device 726 based on the local authentication key 1140 (see [link]). Figure 34 (Step 3414 in the original text). The local authentication process 1128 may include a customized or custom 6G MM NF authentication process 1204 for authentication between the 6G UAV device 726 and the 6G MM NF 712. As part of the local authentication 1112, the 6G MM NF 712 may generate a local authentication vector 1116 based on the local authentication key 1140, which includes a challenge 1146 to the 6G UAV device 726 to prove possession of the shared secret. The 6G MM NF 712 issues the challenge 1146 to the 6G UAV device 726 (see step 3414 in the original text). Figure 34 (Optional step 3416 in the text), and verify the challenge response 1148 from the 6G UAV device 726 to authenticate the 6G UAV device 726 (see...). Figure 34 (Optional step 3418 in the process). As part of local authentication 1112, the 6G UAV device 726 can also challenge the 6G MM NF 712 for mutual authentication.

[0164] In one embodiment, the 6G MM NF 712 can perform integrity protection and / or integrity verification of data exchanged with the 6G UAV device 726 based on one or more integrity protection keys derived from the local authentication key 1140 (see [link to documentation]). Figure 34 (Optional step 3420). Figure 35 This is a diagram illustrating integrity protection 3500 in an exemplary embodiment. The 6G UAV device 726 and the 6G MM NF 712 can use the local authentication key 1140 as an input parameter to the KDF, and other input parameters (as needed), to generate one or more integrity protection keys 3502 (KDF). INT For example, K can be derived from 6G UAV devices 726 and 6GMM NF 712. NASint Keys, etc., are used for integrity protection of NAS signaling. The 6G UAV device 726 and 6G MM NF712 can use (multiple) integrity protection keys 3502 to perform integrity protection and / or integrity verification on non-access stratum (NAS) data or messages 3504.

[0165] In one embodiment, the 6G MM NF 712 maintains the device context 1126 of the 6G UAV device 726 (see [link]). Figure 34(Step 3422 in the process). Device context 1126 may include the registration status of 6G UAV device 726 (e.g., registration or deregistration), the authentication status of 6G UAV device 726 for local authentication 1112, local authentication key 1140, integrity protection key 3502, etc.

[0166] One technical advantage is that the 6G MM NF 712 is able to perform local authentication 1112 for the 6G UAV device 726, which reduces the load on the home network 1104 and reduces signaling overhead.

[0167] On the device side, the 6G UAV device 726 uses or selects the local authentication process 1128 (i.e., 6G MM NF authentication process 1204) for 6G MM NF 712 to perform local authentication 1112 with 6G MM NF 712 (see [link to relevant documentation]). Figure 33 Step 3308 in the process. The 6G UAV device 726 derives or generates a local authentication key 1140 (see step 3308 in the process). Figure 33 (Step 3310 in the above). As described above, the 6G MM NF 712 can issue a challenge 1146 to the 6G UAV device 726 (see step 3310 in the above). Figure 34 (Optional step 3416 in the text). Therefore, the 6G UAV device 726 calculates the challenge response 1148 from the 6G MM NF 712 to the challenge 1146 based on the local authentication key 1140, and sends the challenge response 1148 to the 6G MM NF 712 (see optional step 3416 in the text). Figure 33 (Step 3312 in the process). As part of local authentication 1112, the 6G UAV device 726 can also challenge the 6G MM NF 712 to perform mutual authentication based on the local authentication key 1140.

[0168] In one embodiment, the 6G UAV device 726 may perform integrity protection and / or integrity verification of data exchanged with the 6G MM NF 712 based on one or more integrity protection keys 3502 derived from the local authentication key 1140 (see [link to documentation]). Figure 33 Optional step 3314), which in Figure 35 Further details are provided below.

[0169] In one embodiment, the 6G UAV device 726 maintains device context 1126 with the 6G MM NF 712 (see [link]). Figure 33 (Step 3316 in the process). Device context 1126 may include the registration status of 6G UAV device 726 (e.g., registration or deregistration), the authentication status of 6G UAV device 726 for local authentication 1112, local authentication key 1140, integrity protection key 3502, etc.

[0170] One technical advantage is that the 6G UAV device 726 is able to perform local authentication 1112 with the 6G MM NF 712, which reduces the load on the home network 1104 and reduces signaling overhead.

[0171] gaming devices

[0172] The following embodiments illustrate a scenario where a 6G device 706 includes a 6G gaming device 724. Figure 36 This is a diagram illustrating adaptive registration in an exemplary embodiment. Figure 37 This is a flowchart illustrating an exemplary embodiment of a method 3700 for performing adaptive registration. The steps of method 3700 will be described with reference to a 6G gaming device 724, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc. Figure 38 This is a flowchart illustrating an exemplary embodiment of a method 3800 for performing adaptive registration. The steps of method 3800 will be described with reference to 6G SM NF 714 or 6G UP NF 740, but it should be understood that these methods can be performed in other devices, components, functions, systems, etc.

[0173] Initially, the 6G gaming device 724 was not registered or authenticated on the network. Therefore, the 6G gaming device 724 performs registration process 1102 (i.e., adaptive registration 1100) to register with its home network 1104 (see [link to relevant documentation]). Figure 37 Step 3702 in the process. For this purpose, the 6G gaming device 724 formats a registration request 3601, which includes at least a hidden device ID 1310 (i.e., gaming device ID 1924), and also includes a device type indicator 1312 and / or a mobility type indicator 1314 (see step 3702 in the process). Figure 37 (Step 3704 in the example). In this example, the device type indicator 1312 indicates that the registered 6G device 706 is a gaming device type 1416, and the mobility type indicator 1314 indicates that the registered 6G device 706 is registering as a variable mobility type 1518. The 6G gaming device 724 then sends a registration request 3601 to its home network 1104 (see step 3704 in the example). Figure 37 Step 3706 in the middle.

[0174] The 6G NB 708 receives a registration request 3601 sent by the 6G gaming device 724. In response to the registration request 3601, the 6G NB 708 can determine whether to operate as a local authentication entity 1122 for the 6G gaming device 724. In this example, the 6G gaming device 724 with variable mobility means that it can connect to different 6G NBs 708. Therefore, the 6G NB 708 does not assume the role of local authentication entity 1122 and forwards the registration request 3601 to the 6G MM NF 712.

[0175] The 6G MM NF 712 receives a registration request 3601 from the 6G NB 708. In response to the registration request 3601, the 6G MM NF 712 can determine whether to operate as a local authentication entity 1122 for the 6G gaming device 724. In this example, the 6G gaming device 724 with variable mobility means that the 6G gaming device 724 can connect to different 6G MM NF 712s. Therefore, the 6G MM NF 712 does not assume the role of local authentication entity 1122 and forwards the registration request 3601 (or another type of message) to the 6G SM NF 714 or the 6G UP NF 740. In the following text, reference will be made to the 6G SM NF 714, but similar concepts apply to the 6G UP NF 740.

[0176] The 6G SM NF 714 receives registration request 3601 initiated by the 6G gaming device 724 (see [link]). Figure 38 Step 3802 in the process. In response to registration request 3601, 6G SM NF 714 determines whether to operate as a local authentication entity 1122 of 6G gaming device 724 (see step 3802 in the process). Figure 38 Step 3804 in the document). When it is determined that local authentication entity 1122 is not required, the 6GSM NF 714 does not perform local authentication 1112 (see step 3804 in the document). Figure 38 Step 3806 in the process). When it is determined that the 6G SM NF 714 will operate as the local authentication entity 1122, the 6G gaming device 724 initiates local authentication 1112 (see step 3806 in the process). Figure 38 (Step 3808 in the example). In this example, the 6G gaming device 724 with variable mobility means that the 6G gaming device 724 can connect to different 6G MMNF 712 and different 6G NB 708. Therefore, the 6G SMNF 714 assumes the role of local authentication entity 1122.

[0177] For local authentication 1112, the 6G SM NF 714, acting as the local authentication entity 1122, hides the hidden game device ID 1924 of the 6G game device 724 contained in the registration request 3601 (see [link]). Figure 38 (Step 3810 in the above). For example, the game device ID 1924 may include the extended SUPI 2230 as described above, and the game device ID 1924 as the extended SUPI 2230 can be hidden in the extended SUCI 1320. The 6G SM NF 714 is configured to dehide the extended SUPI 2230 from the extended SUCI 1320. The 6G SM NF 714 obtains the local authentication key 1140 of the 6G game device 724 from the home network authentication entity 1120 in the home network 1104 based on the dehideable game device ID 1924 (see step 3810 in the above). Figure 38 (Step 3812 in the document). The process for obtaining the local authentication key 1140 can vary depending on the implementation.

[0178] exist Figure 36 In this process, when acting as the local authentication entity 1122 for the 6G gaming device 724, the 6G SM NF 714 sends a key request 3602 to the 6G HN 1104, which contains the game device ID 1924 of the 6G gaming device 724. In response to the key request 3602, the 6G HN 1104 derives a local authentication key 1140 (AUTH key) and sends a key response 3603 containing the local authentication key 1140 to the 6G SM NF 714. The 6G SM NF 714 receives and stores the local authentication key 1140 derived by the 6G HN 1104. This allows the 6G SM NF 714 to complete the local authentication 1112 of the 6G gaming device 724. One technical advantage is that this eliminates the need for frequent communication with the centralized 6G HN 1104, saving bandwidth and computing resources.

[0179] After obtaining the local authentication key 1140, the 6G SM NF 714 performs local authentication 1112 for the 6G gaming device 724 based on the local authentication key 1140 (see...). Figure 38 (Step 3814 in the original text). The local authentication process 1128 may include a customized or custom 6G SM NF authentication process 1206 or 6G UP NF authentication process 1208 for authentication between the 6G gaming device 724 and the 6G SM NF 714 or 6G UP NF 740. As part of local authentication 1112, the 6G SM NF 714 may generate a local authentication vector 1116 based on the local authentication key 1140, which includes a challenge 1146 to the 6G gaming device 724 to prove possession of the shared secret. The 6G SM NF 714 issues the challenge 1146 to the 6G gaming device 724 (see step 3814 in the original text). Figure 38(Optional step 3816 in the text), and verify the challenge response 1148 from the 6G gaming device 724 to authenticate the 6G gaming device 724 (see...). Figure 38 (Optional step 3818). As part of local authentication 1112, the 6G gaming device 724 can also challenge the 6G SM NF 714 for mutual authentication.

[0180] In one embodiment, the 6G SM NF 714 can perform integrity protection and / or integrity verification of data exchanged with the 6G gaming device 724 based on one or more integrity protection keys derived from the local authentication key 1140 (see [link to documentation]). Figure 38 (Optional step 3820). Figure 39 This is a diagram illustrating integrity protection 3900 in an exemplary embodiment. The 6G gaming device 724 and the 6G SM NF 714 can use the local authentication key 1140 as an input parameter to the KDF, and other input parameters (as needed), to generate one or more integrity protection keys 3902 (KDF). INT The 6G gaming device 724 and the 6G SMNF 714 can use (multiple) integrity protection keys 3902 to perform integrity protection and / or integrity verification on data or messages 3904.

[0181] In one embodiment, the 6G SM NF 714 maintains the device context 1126 of the 6G gaming device 724 (see [link]). Figure 38 (Step 3822 in the process). Device context 1126 may include the registration status of 6G gaming device 724 (e.g., registration or deregistration), the authentication status of 6G gaming device 724 for local authentication 1112, local authentication key 1140, integrity protection key 3902, etc.

[0182] One technical advantage is that the 6G SM NF 714 is able to perform local authentication 1112 for 6G gaming devices 724, which reduces the load on the home network 1104 and reduces signaling overhead.

[0183] On the device side, the 6G gaming device 724 uses the local authentication process 1128 of the 6G SM NF 714 (i.e., the 6G SM NF authentication process 1206) or the local authentication process 1128 of the 6G UP NF 740 (e.g., the 6G UP NF authentication process 1208) to perform local authentication 1112 (see Figure 37 Step 3708 in the process. 6G gaming device 724 derives or generates local authentication key 1140 (see step 3708 in the process). Figure 37 (Step 3710 in the above). As described above, the 6G SM NF 714 can issue a challenge 1146 to the 6G gaming device 724 (see step 3710 in the above). Figure 38 (Optional step 3816 in the process). Therefore, the 6G gaming device 724 calculates a challenge response 1148 from the 6GSM NF 714 to the challenge 1146 based on the local authentication key 1140, and sends the challenge response 1148 to the 6GSM NF 714 (see optional step 3816 in the process). Figure 37 (Step 3712 in the process). As part of local authentication 1112, the 6G gaming device 724 can also challenge the 6G SM NF 714 to perform mutual authentication based on the local authentication key 1140.

[0184] In one embodiment, the 6G gaming device 724 may perform integrity protection and / or integrity verification of data exchanged with the 6G SM NF 714 based on one or more integrity protection keys 3902 derived from the local authentication key 1140 (see [link to documentation]). Figure 37 Optional step 3714), which in Figure 39 Further details are provided below.

[0185] In one embodiment, the 6G gaming device 724 maintains device context 1126 with the 6G SM NF 714 (see [link]). Figure 37 (Step 3716 in the process). Device context 1126 may include the registration status of 6G gaming device 724 (e.g., registration or deregistration), the authentication status of 6G gaming device 724 for local authentication 1112, local authentication key 1140, integrity protection key 3902, etc.

[0186] One technological advantage is that the 6G gaming device 724 is able to perform local authentication 1112 with the 6G SM NF 714 or 6G UP NF 740, which reduces the load on the home network 1104 and reduces signaling overhead.

[0187] Any of the various elements or modules shown in the figures or described herein can be implemented as hardware, software, firmware, or some combination thereof. For example, an element can be implemented as dedicated hardware. A dedicated hardware element may be referred to as a “processor,” a “controller,” or some similar term. When provided by a processor, functionality can be provided by a single dedicated processor, a single shared processor, or multiple individual processors, some of which may share resources. Furthermore, the explicit use of the terms “processor” or “controller” should not be construed as referring only to hardware capable of executing software, but may implicitly include, but is not limited to, digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs) or other circuit systems, field-programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random access memory (RAM), non-volatile memory, logic, or some other physical hardware component or module.

[0188] Furthermore, an element can be implemented as instructions that can be executed by a processor or computer to perform the element's functions. Some examples of instructions are software, program code, and firmware. When executed by a processor, instructions are operable to instruct the processor to perform the element's functions. Instructions can be stored on processor-readable storage devices. Some examples of storage devices are digital or solid-state memories, magnetic storage media such as disks and tapes, hard disk drives, or optically readable digital data storage media.

[0189] The term "circuit system" as used in this application may refer to one or more or all of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuit systems only); (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits with software / firmware; and (ii) Any part of a hardware processor (including digital signal processors), software, and memory (including multiple memory) that works together to enable a device such as a mobile phone or server to perform various functions; and (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or portions of (multiple) microprocessors, which require software (e.g., firmware) to function, but may be absent when not in use.

[0190] This definition of circuit system applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term circuit system also covers only hardware circuitry or a processor (or multiple processors) or portions of hardware circuitry or a processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuit also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0191] Although specific embodiments have been described herein, the scope of this disclosure is not limited to these specific embodiments. The scope of this disclosure is defined by the following claims and any equivalents thereof.

Claims

1. An apparatus for communication, the apparatus comprising: At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the device to perform at least the following: Determine a local authentication key for local authentication of the device, the determination including: The identifier is configured as an input parameter of a key derivation function that generates the local authentication key, wherein the input parameter includes at least: a long-term key for the device, a service network name for the device's service network, a device identifier for the device, and an identifier for the local authentication entity performing the local authentication of the device; and The input parameters are fed into the key deriving function to obtain the local authentication key.

2. The apparatus of claim 1, wherein the local authentication entity comprises a radio access network node, and the identifier for the local authentication entity comprises an identifier for the radio access network node.

3. The apparatus of claim 1, wherein the local authentication entity includes a mobility management network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the mobility management network function.

4. The apparatus of claim 1 or 2, wherein the local authentication entity includes a session management network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the session management network function.

5. The apparatus of claim 1, wherein the local authentication entity includes a user plane network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the user plane network function.

6. The apparatus according to any one of claims 1 to 5, wherein the apparatus includes an Internet of Things (IoT) device, and the apparatus identifier includes an identifier specific to the IoT device.

7. The apparatus according to any one of claims 1 to 5, wherein the apparatus comprises an unmanned aerial vehicle (UAV), and the apparatus identifier comprises an identifier for the UAV.

8. The apparatus according to any one of claims 1 to 5, wherein the apparatus includes a gaming device, and the apparatus identifier includes an identifier specific to the gaming device.

9. A method performed by a means for communication, the method comprising: Determine a local authentication key for local authentication of the device, the determination including: The identifier is configured as an input parameter of a key derivation function that generates the local authentication key, wherein the input parameter includes at least: a long-term key for the device, a service network name for the device's service network, a device identifier for the device, and an identifier for the local authentication entity performing the local authentication of the device; and The input parameters are fed into the key deriving function to obtain the local authentication key.

10. The method of claim 9, wherein the local authentication entity comprises a radio access network node, and the identifier for the local authentication entity comprises an identifier for the radio access network node.

11. The method of claim 9, wherein the local authentication entity includes a mobility management network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the mobility management network function.

12. The method of claim 9, wherein the local authentication entity includes a session management network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the session management network function.

13. The method of claim 9, wherein the local authentication entity includes a user plane network function of a cellular network, and the identifier for the local authentication entity includes an identifier for the user plane network function.

14. The method according to any one of claims 9 to 13, wherein the device includes an Internet of Things (IoT) device, and the device identifier includes an identifier specific to the IoT device.

15. The method according to any one of claims 9 to 13, wherein the device comprises an unmanned aerial vehicle (UAV), and the device identifier comprises an identifier for the UAV.

16. The method according to any one of claims 9 to 13, wherein the apparatus includes a gaming device, and the apparatus identifier includes an identifier specific to the gaming device.

17. A computer-readable medium comprising instructions that, when executed by at least one processor of a device, cause the device to perform the method according to any one of claims 9 to 16.

18. A computer program product, when executed by at least one processor of a device, causes the device to perform the method according to any one of claims 9 to 16.

Images