Communication methods and communication devices

Abstract

A communication method is provided, including: in an authentication procedure between a terminal device and a first gateway, the terminal device sends a message to the first gateway indicating whether the terminal device supports the first key hierarchy, and as a result the first gateway can accurately determine whether the terminal device supports the first key hierarchy and report to the network side whether the terminal device supports the first key hierarchy, and the terminal device can derive a first key to be used for security based on whether the terminal device supports the first key hierarchy, and the network side can also derive a first key. The method for deriving the first key when the terminal device supports the first key hierarchy is different from the method for deriving the first key when the terminal device does not support it. The terminal device may report whether it supports the first key hierarchy, and as a result the terminal device and the network side can select an appropriate derivation method to generate the necessary key and improve communication security.

Description

Technical Field

[0001] This application claims the priority of Chinese Patent Application No. 202310539755.8, titled "COMMUNICATION METHOD AND COMMUNICATION APPARATUS", filed with the China National Intellectual Property Administration on May 12, 2023, and the entire content thereof is incorporated herein by reference.

[0002] Technical Field This application relates to the field of communications, and more specifically, to a communication method and a communication apparatus.

Background Art

[0003] After an authenticable non-the 3rd generation partnership project (AUN3) device establishes a connection to a 5th generation (5G) residential gateway (5G-RG), the AUN3 device can access a 5G core network (5GC) via the 5G-RG. To improve communication security, the AUN3 device and the 5G-RG can use keys to perform security protection on the established connection. The keys used by the AUN3 device and the 5G-RG can be generated by different derivation methods based on whether the AUN3 device supports the 5G key hierarchy. Therefore, the correct key can only be generated by the corresponding derivation method when it is determined whether the AUN3 device supports the 5G key hierarchy. Otherwise, secure communication between the AUN3 device and the 5G-RG cannot be achieved.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Embodiments of this application provide a communication method for improving communication security. [Means for solving the problem]

[0005] According to the first embodiment, a communication method is provided. This method may be performed by a terminal device, or by a component of the terminal device (e.g., a chip or circuit), but is not limited to this. The terminal device includes a terminal device or another device that needs to access a core network via a first gateway.

[0006] The communication method includes: receiving a first request message from a first gateway, the first request message being used to request identification information for a terminal device, the terminal device accessing the core network via a connection between the terminal device and the first gateway, and the identification information being used by the core network to perform identification authentication against the terminal device; sending a first response message to the first gateway, the first response message including identification information, and indicating whether the terminal device supports a first key hierarchy; receiving a message from the first gateway indicating that the identification authentication was successful; and generating a first key based on whether the terminal device supports a first key hierarchy, the first key being used to perform security protection over the connection between the terminal device and the first gateway.

[0007] Based on the above solution, the terminal device can report whether it supports the first key hierarchy by using a first response message. As a result, the 5G-RG can learn whether the terminal device supports the first key hierarchy based on the first response message and report this to the network side. The corresponding method for deriving the key when the terminal device supports the first key hierarchy is different from the corresponding method for deriving the key when the terminal device does not support the first key hierarchy. When the network side learns whether the terminal device supports the first key hierarchy, it can select an appropriate derivation method to generate the necessary key, and the terminal device can also improve communication security by deriving a first key used for security protection based on whether the terminal device supports the first key hierarchy.

[0008] According to the first aspect, in some implementations of the first aspect, generating a first key based on whether a terminal device supports a first key hierarchy includes generating a first key using a first key derivation method when the terminal device supports a first key hierarchy, and generating a first key using a second key derivation method when the terminal device does not support a first key hierarchy.

[0009] The first key derivation method is different from the second key derivation method. Thus, when determining whether a terminal device supports the first key hierarchy, the terminal device can generate the correct key using the corresponding derivation method.

[0010] According to the first embodiment, in some implementations of the first embodiment, the first response message indicates whether the terminal device supports the first key hierarchy; this includes the identification information indicating whether the terminal device supports the first key hierarchy. In this way, by using the identification information, information transmission efficiency can be improved by directly indicating whether the terminal device supports the first key hierarchy.

[0011] According to the first embodiment, in some implementations of the first embodiment, the identification information indicates whether the terminal device supports the first key hierarchy: when the identification information is a first identifier, the identification information indicates that the terminal device does not support the first key hierarchy, or when the identification information is a second identifier, the identification information indicates that the terminal device supports the first key hierarchy.

[0012] For example, the identification information is the subscriber persistent identifier of the terminal device, indicating that the terminal device does not support the first key hierarchy, while the identification information is the confidential subscriber identifier of the terminal device, indicating that the terminal device supports the first key hierarchy.

[0013] According to the first embodiment, in some implementations of the first embodiment, the identification information indicates whether the terminal device supports the first key hierarchy: when the identification information is a first identifier of the first type, the identification information indicates that the terminal device does not support the first key hierarchy, or when the identification information is a first identifier of the second type, the identification information indicates that the terminal device supports the first key hierarchy.

[0014] For example, the identification information is a concealed subscriber identifier of the terminal device. When the type of the concealed subscriber identifier is an International Mobile Subscriber Identification Number, it indicates that the terminal device does not support the first key hierarchy, or when the type of the concealed subscriber identifier is a Network Access Identifier, it indicates that the terminal device supports the first key hierarchy.

[0015] According to the first embodiment, in some implementations of the first embodiment, the identification information indicates whether the terminal device supports the first key hierarchy: the identification information includes a field indicating whether the terminal device supports the first key hierarchy.

[0016] For example, the identification information is the subscriber persistent identifier of the terminal device, and the username portion or area portion of the subscriber persistent identifier indicates whether the terminal device supports the first key hierarchy.

[0017] For example, the identification information is a confidential join identifier for the terminal device, and the confidential join identifier includes a field indicating whether the terminal device supports the first key hierarchy.

[0018] According to the first aspect, in some implementations of the first aspect, the first response message further includes first instruction information, the first response message includes indicating whether the terminal device supports the first key hierarchy; the first instruction information includes indicating whether the terminal device supports the first key hierarchy.

[0019] For example, the first instruction information includes at least one of the following: namely, string information, bit information, or non-access layer protocol data units.

[0020] Thus, explicit first directive information helps the message recipient quickly and accurately know whether the terminal device supports the first key hierarchy. In addition, multiple possible forms of the first directive information may exist, which increases the flexibility of the solution.

[0021] According to the first aspect, in some implementations of the first aspect, the first response message further includes second instruction information, the second instruction information indicating whether the terminal device supports the non-accessible tier NAS protocol, and the terminal device supporting the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0022] Based on the above solution, the serving network name determined by the terminal device may be a value that the terminal device can determine, such as a preset fixed value, the terminal device's home PLMN ID, or the PLMN ID of the access and mobility management network elements serving the first gateway, thereby enabling smooth bidirectional authentication procedures between the terminal device and the core network.

[0023] According to the first aspect, in some implementations of the first aspect, before the step of receiving, from the first gateway, a message indicating successful identification and authentication, the method further includes: determining a serving network name, where the serving network name is used for identification and authentication, and the serving network name includes at least one of the following, namely, a preset fixed value, the home public land mobile network identifier (PLMN ID) of the terminal device, or the PLMN ID of the access and mobility management network element serving the first gateway, and the step of, further including.

[0024] Based on the above solution, the serving network name determined by the terminal device may be a value that the terminal device can determine, such as a preset fixed value, the home PLMN ID of the terminal device, or the PLMN ID of the access and mobility management network element serving the first gateway. As a result, the terminal device executes a mutual authentication procedure.

[0025] According to the first aspect, in some implementations of the first aspect, before the step of receiving, from the first gateway, a first request message, the method further includes determining an access method for accessing the first gateway, where the access method includes reliable non-3rd Generation Partnership Project (3GPP) access or unreliable non-3GPP access.

[0026] According to the first aspect, in some implementations of the first aspect, the first gateway includes a 5th Generation Residential Gateway (5G-RG), and the first key hierarchy includes a 5G key hierarchy.

[0027] According to the second aspect, a communication method is provided. The method may be executed by the first gateway or by a component (such as a chip or a circuit) of the first gateway. This is not limited. For the sake of convenience of explanation, an example where the method is executed by the first gateway is used for explanation below.

[0028] The communication method includes: a step of sending a first request message to a terminal device, the first request message being used to request identification information of the terminal device, the terminal device accessing the core network via a connection between the terminal device and a first gateway, and the identification information being used by the core network to perform identification authentication on the terminal device; a step of receiving a first response message from the terminal device, the first response message including identification information, and indicating whether the terminal device supports a first key hierarchy; a step of sending the identification information and instructional information indicating whether the terminal device supports a first key hierarchy to an access and mobility management network element, the access and mobility management network element being located within the core network; a step of receiving a fifth key and a message indicating successful identification authentication from the access and mobility management network element, the fifth key being generated based on whether the terminal device supports a first key hierarchy; a step of sending a message indicating successful identification authentication to the terminal device; and a step of generating a first key based on the fifth key, the first key being used to perform security protection of the connection between the terminal device and the first gateway.

[0029] According to the second aspect, in some implementations of the second aspect, the generation of the fifth key based on whether the terminal device supports the first key hierarchy includes: generating the fifth key using the first key derivation method when the terminal device supports the first key hierarchy; and generating the fifth key using the second key derivation method when the terminal device does not support the first key hierarchy.

[0030] According to the second aspect, in some implementations of the second aspect, transmitting identification information and instructional information indicating whether the terminal device supports the first key hierarchy (hereinafter abbreviated as fourth instructional information, where the fourth instructional information may be the identification information of the terminal device or the first instructional information) to an access and mobility management network element includes: transmitting identification information and instructional information indicating whether the terminal device supports the first key hierarchy to an access and mobility management network element by using a non-access tier NAS registration request message, wherein the first response message includes a NAS registration request message, or the NAS registration request message is generated by the first gateway based on the first response message.

[0031] According to a second aspect, in some implementations of the second aspect, the method further includes the step of having the first gateway transmit instructional information to an access and mobility management network element indicating a device that initiates a registration request to access the core network via a connection between the device and the first gateway.

[0032] According to the second aspect, in some implementations of the second aspect, the first response message includes indicating whether the terminal device supports the first key hierarchy: the identification information includes indicating whether the terminal device supports the first key hierarchy.

[0033] According to a second aspect, in some implementations of the second aspect, the first response message further includes first instruction information, the first response message includes indicating whether the terminal device supports a first key hierarchy; the first instruction information includes indicating whether the terminal device supports a first key hierarchy.

[0034] According to the second aspect, in some implementations of the second aspect, the NAS registration request message further includes fifth directive information, which indicates whether the terminal device supports the NAS protocol, and the fact that the terminal device supports the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0035] According to the second aspect, in some implementations of the second aspect, the first gateway includes a fifth-generation residential gateway 5G-RG, and the first key hierarchy includes a 5G key hierarchy.

[0036] For the technical effects of the method shown in the second embodiment and possible designs of the second embodiment, please refer to the technical effects of the first embodiment and possible designs of the first embodiment.

[0037] According to a third aspect, a communication system is provided, which includes a first gateway sending a first request message to a terminal device, where the first request message is used to request identification information of the terminal device, the terminal device accessing the core network via a connection between the terminal device and the first gateway, and the identification information being used by the core network to perform identification authentication against the terminal device. The terminal device sends a first response message to the first gateway, where the first response message includes identification information and indicates whether the terminal device supports a first key hierarchy. The first network element receives a fifth key and a message indicating that the identification authentication was successful, where the fifth key is generated based on whether the terminal device supports a first key hierarchy. The first gateway sends a message indicating that the identification authentication was successful to the terminal device. The terminal device generates a first key based on whether the terminal device supports a first key hierarchy, where the first key is used to perform security protection over the connection between the terminal device and the first gateway. The first gateway generates a first key based on the fifth key.

[0038] According to a third aspect, in some implementations of the third aspect, the method further includes an access and mobility management network element receiving identification information and instructional information indicating whether a terminal device supports the first key hierarchy from a first gateway. The access and mobility management network element generates a fifth key based on whether the terminal device supports the first key hierarchy. The access and mobility management network element transmits the fifth key to the first gateway.

[0039] According to a fourth aspect, a communication system is provided. The communication system includes terminal devices and a first gateway.

[0040] The first gateway is configured to send a first request message to a terminal device, which is used to request the terminal device's identity information. The terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identity information is used by the core network to perform identity authentication against the terminal device. The terminal device is configured to send a first response message to the first gateway, which contains the identity information and indicates whether the terminal device supports the first key hierarchy. The first network element is further configured to obtain a fifth key and a message indicating that identity authentication was successful, with the fifth key being generated based on whether the terminal device supports the first key hierarchy. The first gateway is further configured to send a message indicating that identity authentication was successful to the terminal device. The terminal device is further configured to generate a first key based on whether the terminal device supports the first key hierarchy, with the first key being used to perform security protection over the connection between the terminal device and the first gateway. The first gateway is further configured to generate a first key based on the fifth key.

[0041] According to a fourth aspect, in some implementations of the fourth aspect, the system further includes an access and mobility management network element. The access and mobility management network element is configured to receive identification information and instructional information indicating whether a terminal device supports a first key hierarchy from a first gateway. The access and mobility management network element is further configured to generate a fifth key based on whether a terminal device supports a first key hierarchy. The access and mobility management network element is further configured to transmit the fifth key to the first gateway.

[0042] According to the fourth aspect, in some implementations of the fourth aspect, the authentication request message includes a serving network name, which is used for identification authentication, and the serving network name includes at least one of the following: a preset fixed value, the home public land mobile network identifier PLMN ID of the terminal device, or the PLMN ID of an access and mobility management network element serving the first gateway.

[0043] According to the fourth aspect, in some implementations of the fourth aspect, the NAS registration request message further includes fifth directive information, which indicates whether the terminal device supports the NAS protocol, and the fact that the terminal device supports the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0044] According to the fourth aspect, in some implementations of the fourth aspect, when fifth instruction information indicates that a terminal device supports the NAS protocol, the access and mobility management network element is further configured to generate a NAS key based on the fifth key and the identifier of the terminal device, and the access and mobility management network element is further configured to perform a NAS SMC procedure with the terminal device based on the NAS key.

[0045] According to the fourth aspect, in some implementations of the fourth aspect, the authentication request message further includes sixth directive information, which indicates that the device to be authenticated is a terminal device that accesses the core network via a connection between the terminal device and the first gateway.

[0046] According to a fourth aspect, in some implementations of the fourth aspect, the authentication network element is further configured to send a retrieve request message to a data management network element, where the retrieve request message is used to request the retrieval of an authentication vector required for authentication, and the retrieve request message includes an identifier for a terminal device. The authentication network element is further configured to receive a retrieve response message from the data management network element, where the retrieve response message includes information about the authentication vector.

[0047] According to the fourth aspect, in some implementations of the fourth aspect, the first gateway includes a fifth-generation residential gateway 5G-RG, and the first key hierarchy includes a 5G key hierarchy.

[0048] For the technical effects of the method shown in the fourth embodiment and possible designs of the fourth embodiment, please refer to the technical effects of the first embodiment and possible designs of the first embodiment.

[0049] According to a fifth aspect, a communication method is provided. This method may be performed by a data management network element or by a component of the data management network element (e.g., a chip or circuit), but is not limited to this. For convenience of explanation, the following examples will use the method performed by a data management network element.

[0050] This communication method involves a data management network element receiving a retrieval request message from an authentication network element, the retrieval request message being used to request the acquisition of an authentication vector necessary for authentication, the retrieval request message including an identifier of an authenticateable non-third-generation partnership project terminal device, and the data management network element sending a retrieval response message to the authentication network element, the retrieval response message including information about the authentication vector and seventh-instruction information, the seventh-instruction information indicating whether the terminal device supports the first key hierarchy, and the information about the authentication vector and the seventh-instruction information being acquired based on the identifier of the terminal device.

[0051] According to the above solution, the data management network element can provide instructional information indicating whether the terminal device supports the first key hierarchy. As a result, the network can learn whether the terminal device supports the first key hierarchy and select an appropriate derivation method to generate the necessary keys, thereby improving communication security.

[0052] In relation to the fifth aspect, in some implementations of the fifth aspect, the method further includes a data management network element selecting an authentication method based on an identifier of a terminal device and determining an authentication vector corresponding to the authentication method.

[0053] In relation to the fifth aspect, in some implementations of the fifth aspect, the method comprises a data management network element determining enrollment data for a terminal device based on an identifier for the terminal device, wherein the enrollment data for the terminal device includes seventh instruction information, or further comprising the data management network element determining enrollment data for a terminal device based on an identifier for the terminal device and determining, based on the enrollment data for the terminal device, whether the terminal device supports the first key hierarchy.

[0054] Based on the above solution, the data management network element can determine in different ways whether a terminal device supports the first key hierarchy, thereby increasing the flexibility of the solution.

[0055] In relation to the fifth aspect, in some implementations of the fifth aspect, the acquired response message further includes eighth instruction information, which indicates whether the terminal device supports the non-accessible hierarchical NAS protocol, and the fact that the terminal device supports the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0056] According to the above solution, the data management network element may indicate whether the terminal device supports the NAS protocol by using the eighth instruction information, and as a result, the network side can learn whether the terminal device supports the NAS protocol based on the eighth instruction information, and then the mobility management network element on the network side decides whether to perform the NAS SMC procedure with the terminal device.

[0057] According to the sixth aspect, a communication method is provided. This method may be performed by an access and mobility management network element, or by a component of the access and mobility management network element (e.g., a chip or circuit), but is not limited to this. For convenience of explanation, the following examples will use the method performed by an access and mobility management network element.

[0058] The communication method is as follows: The access and mobility management network element receives a NAS registration request message from the first gateway, the NAS registration request message including third instruction information, the third instruction information including indicating that the device initiating the registration request is an authenticated non-third-generation partnership project terminal device. Based on the third instruction information, the access and mobility management network element determines that the registration request is initiated by a terminal device. The access and mobility management network element sends an authentication request message to the authentication network element, the authentication request message is used to request the authentication network element to perform authentication on the terminal device. The access and mobility management network element receives an authentication response message from the authentication network element, the authentication response message including a third key and ninth instruction information, the ninth instruction information indicating whether the terminal device supports the first key hierarchy. Based on the third key and whether the terminal device supports the first key hierarchy, the access and mobility management network element generates a fifth key. The access and mobility management network element transmits the fifth key to the first gateway, where the corresponding generation method for the fifth key when the terminal device supports the first key hierarchy is different from the corresponding generation method for the fifth key when the terminal device does not support the first key hierarchy.

[0059] In relation to the sixth aspect, in some implementations of the sixth aspect, the authentication request message further includes a serving network name, which is used for identification authentication, and which includes at least one of a preset fixed value, the terminal device's home public land mobile network identifier (PLMN ID), or the PLMN ID of an access and mobility management network element serving the first gateway.

[0060] In relation to the sixth aspect, in some implementations of the sixth aspect, the authentication request message further includes sixth directive information, which indicates that the device to be authenticated is a terminal device that accesses the core network via a connection between the terminal device and the first gateway.

[0061] In relation to the sixth aspect, in some implementations of the sixth aspect, the first gateway includes a fifth-generation residential gateway 5G-RG, and the first key hierarchy includes a 5G key hierarchy.

[0062] In relation to the sixth aspect, in some implementations of the sixth aspect, the authentication response message further includes a tenth directive, the tenth directive indicating whether the terminal device supports the NAS protocol, and the terminal device supporting the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0063] In relation to the sixth aspect, in some implementations of the sixth aspect, when the tenth instruction information indicates that the terminal device supports the NAS protocol, the access and mobility management network element generates a NAS key based on the fifth key and the terminal device identifier. Based on the NAS key, the access and mobility management network element performs a NAS SMC procedure with the terminal device.

[0064] For the technical effects of the method shown in the sixth aspect and possible designs of the sixth aspect, please refer to the technical effects of the fourth aspect and possible designs of the fourth aspect.

[0065] According to the seventh aspect, a communication method is provided. This method may be performed by an authentication network element or by a component of the authentication network element (e.g., a chip or circuit), but is not limited to this. For convenience of explanation, the following examples will use the method performed by an authentication network element.

[0066] The communication method is as follows: The authentication network element receives an authentication request message from the access and mobility management network element, where the authentication request message is used to request the authentication network element to perform authentication on an authenticateable non-third-generation partnership project terminal device, and the authentication request message includes the identifier of the terminal device. The authentication network element sends an retrieve request message to the data management network element, where the retrieve request message is used to request the retrieval of the authentication vector required for authentication, and the retrieve request message includes the identifier of the terminal device. The authentication network element receives a retrieve response message from the data management network element, where the retrieve response message includes information about the authentication vector and seventh instruction information, the seventh instruction information indicating whether the terminal device supports the first key hierarchy. The authentication network element generates a third key based on the identifier of the terminal device and whether the terminal device supports the first key hierarchy. The authentication network element sends an authentication response message to the access and mobility management network element, where the authentication response message includes a third key and nine instruction information, the nine instruction information indicating whether the terminal device supports the first key hierarchy, and the corresponding method for generating the third key when the terminal device supports the first key hierarchy differs from the corresponding method for generating the third key when the terminal device does not support the first key hierarchy.

[0067] In relation to the seventh aspect, in some implementations of the seventh aspect, the method enables an authentication network element to perform bidirectional authentication with a terminal device based on an authentication vector.

[0068] In relation to the seventh aspect, in some implementations of the seventh aspect, the authentication request message further includes sixth directive information, which indicates that the device to be authenticated is a terminal device that accesses the core network via a connection between the terminal device and the first gateway.

[0069] In relation to the seventh aspect, in some implementations of the seventh aspect, the acquired response message further includes eighth directive information, which indicates whether the terminal device supports the non-accessible hierarchical NAS protocol, and the fact that the terminal device supports the NAS protocol indicates that the terminal device can generate and process NAS messages.

[0070] In relation to the seventh aspect, in some implementations of the seventh aspect, the authentication response message further includes tenth instruction information, which indicates whether the terminal device supports the NAS protocol.

[0071] According to the eighth aspect, a communication system is provided which includes a data management network element, an access and mobility management network element, and an authentication network element, wherein the data management network element is configured to perform the method shown in the fifth aspect, the access and mobility management network element performs the method shown in the sixth aspect, and the authentication network element performs the method shown in the seventh aspect.

[0072] According to the ninth aspect, a communication device is provided. The device includes a transceiver unit and a processing unit. The transceiver unit is configured to perform the steps of receiving and transmitting information in the manner provided in the above aspect, and the processing unit is configured to perform the processing steps in the manner provided in the above aspect.

[0073] According to a tenth aspect, a communication device is provided. The device includes a memory configured to store a program and a processor configured to execute the program stored in the memory. When the program stored in the memory is executed, the processor is configured to perform the method provided in the above aspect.

[0074] According to an eleventh aspect, the present application provides a processor configured to perform the methods provided in the above aspects. In the process of performing these methods, the process of transmitting the above information in the above methods and the process of acquiring / receiving the above information may be understood as the process of outputting the above information by the processor and the process of receiving the above input information by the processor. When outputting information, the processor outputs the information to a transceiver, and as a result the transceiver transmits the information. After the above information is output by the processor, there may be further cases where other processing needs to be performed on the above information before it reaches the transceiver. Similarly, when the processor receives the above input information, the transceiver acquires / receives the above information and inputs it to the processor. Furthermore, after the transceiver receives the above information, there may be further cases where other processing needs to be performed on the above information before it is input to the processor.

[0075] Based on the above principles, receiving a request message as described above can be understood as receiving information input by the processor.

[0076] Unless otherwise stated, or unless the operations related to the processor, such as transmission, transmission, and acquisition / reception, are consistent with the actual function or internal logic of the operations in the relevant description, all operations may be understood more generally as the outputs, receptions, and inputs of the processor, rather than the transmission, transmission, and reception operations performed directly by the radio frequency circuit and antenna.

[0077] In the implementation process, the processor may be a processor specifically configured to perform these methods, or a processor that executes computer instructions in memory to perform these methods, such as a general-purpose processor. The memory may be non-transitory memory, such as read-only memory (ROM). The memory and processor may be integrated on the same chip or located separately on different chips. The type of memory, and the method of arranging the memory and processor, are not limited to this embodiment of the present application.

[0078] According to a twelfth aspect, a computer-readable storage medium is provided. The computer-readable medium stores program code to be executed by a device, and the program code is used to execute the method provided in the above aspect.

[0079] According to the 13th aspect, a computer program product including instructions is provided. When the computer program product is executed on a computer, the computer becomes capable of performing the method provided in the above aspects.

[0080] According to a fourteenth aspect, a chip is provided. The chip includes a processor and a communication interface, the processor reading instructions stored in memory via the communication interface and performing the method provided in the above embodiment.

[0081] Optionally, in one implementation, the chip may further include memory. The memory stores instructions. The processor is configured to execute instructions stored in memory. When an instruction is executed, the processor is configured to perform the method provided in the above embodiment. [Brief explanation of the drawing]

[0082] [Figure 1] This is a diagram of the network architecture 100 according to this application.

[0083] [Figure 2] Figures 2(a) and 2(b) illustrate non-3GPP access according to embodiments of this application.

[0084] [Figure 3] This diagram shows a registration procedure performed by a terminal device via an untrusted non-3GPP network, according to an embodiment of this application.

[0085] [Figure 4] This diagram shows a registration procedure performed by a terminal device via a reliable 3GPP network, according to an embodiment of this application.

[0086] [Figure 5] This figure shows how an AUN3 device that does not support the 5G key hierarchy accesses 5GC according to an embodiment of this application.

[0087] [Figure 6] This figure shows how an AUN3 device supporting a 5G key hierarchy, according to an embodiment of this application, accesses 5GC.

[0088] [Figure 7] This is a diagram of a non-5G key hierarchy according to an embodiment of this application.

[0089] [Figure 8] This is a diagram of the 5G key hierarchy according to an embodiment of this application.

[0090] [Figure 9] This is a schematic flowchart of the communication method described in this application.

[0091] [Figure 10] This is a schematic flowchart of another communication method according to this application.

[0092] [Figure 11] This is a block diagram of a communication device 10 according to an embodiment of the present application.

[0093] [Figure 12] This is a diagram of another communication device 20 according to an embodiment of the present application.

[0094] [Figure 13] This is a diagram of a chip system 30 according to an embodiment of the present application. [Modes for carrying out the invention]

[0095] The following describes the technical solutions in the embodiments of this application with reference to the drawings.

[0096] The technical solutions in the embodiments of this application may be applied to various communication systems, such as fifth-generation (5G) systems, new radio (NR) systems, long-term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, and LTE time division duplex (TDD) systems. The technical solutions provided in this application may also be applied to future communication systems, such as sixth-generation mobile communication systems.

[0097] To facilitate understanding of the communication method provided below, we will first describe a communication scenario to which the communication method provided in the embodiments of this application is applicable, with reference to Figure 1.

[0098] Figure 1 is a diagram of the network architecture 100 according to this application. It includes the following devices: namely, AUN3 devices, 5G-RG, wireline access gateway function (W-AGF), and core network (CN) (in other words, gateways, nodes, network elements, etc.).

[0099] The core network includes, but is not limited to, the following network functions (also called devices, gateways, network elements, network function network elements, or nodes): namely, access and mobility management function (AMF), session management function (SMF), user plane function (UPF), unified data management (UDM), authentication server function (AUSF), etc. UDM and AUSF are not shown in the diagram. The functions of the devices are briefly described below.

[0100] 1. AUN3 devices: As shown in Figure 1, devices that access the core network via 5G-RG are collectively referred to as AUN3 devices. When an AUN3 device needs to access the core network, it first connects to the 5G-RG and then accesses the core network via the 5G-RG.

[0101] The AUN3 device in the embodiment of this application is a device having wireless transceiver functionality and may indirectly use one or more CN devices (sometimes also called access devices) for communication via 5G-RG.

[0102] For example, an AUN3 device may be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc.

[0103] 2.5G-RG: It is both a fixed network device and a terminal device. 5G-RG is a Residential Gateway (RG) that can register with the core network. From the perspective of the core network, 5G-RG plays the role of a terminal device. 5G-RG communicates with the core network via a communication interface (for example, the N1 interface shown in Figure 1).

[0104] For example, 5G-RG may also be called an access terminal, terminal, subscriber unit, subscriber station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent, user equipment, etc. 5G-RG may be deployed on land, including indoor or outdoor devices, or handheld or in-vehicle devices, on water (e.g., on ships), or in the air (e.g., on airplanes, balloons, and satellites). 5G-RG may be a cellular phone, cordless phone, session initiation protocol (SIP) phone, smartphone, mobile phone, wireless local loop (WLL) station, personal digital assistant (PDA), etc. Alternatively, 5G-RG may be a mobile terminal with wireless communication capabilities, computing device, another device connected to a wireless modem, in-vehicle device, wearable device, unmanned aerial vehicle device, terminal in the Internet of Things or the Internet of Car, any form of terminal in 5G networks and future networks, terminal in future evolving 6G networks, etc.

[0105] 3. W-AGF: Access Gateway Function, sometimes called AGF. A connection exists between the 5G-RG and the W-AGF, and this connection is used to transmit control plane packets and user plane packets exchanged between the AUN3 device and the core network. Control plane packets are sometimes called non-access stratum (NAS) messages.

[0106] For example, after receiving an uplink user plane packet from an AUN3 device via 5G-RG, the W-AGF identifies the Protocol Data Unit (PDU) session and Quality of Service (QoS) flow corresponding to the uplink user plane packet and sends the uplink user plane packet to the UPF via the N3 interface. It identifies the PDU session and QoS flow corresponding to the uplink user plane packet, determines the processing rule corresponding to the packet, and processes the downlink user plane packet.

[0107] In another example, after receiving a downlink user plane packet from the core network, the W-AGF may add an identifier to the downlink user plane packet, so that the AUN3 device can identify the PDU session and QoS flow to which the downlink user plane packet belongs, and then process the downlink user plane packet based on the processing rules corresponding to the PDU session and QoS flow.

[0108] 4. AMF: Responsible for access control and mobility management of terminal devices (e.g., the aforementioned 5G-RG) to access the operator network, such as mobility status management, temporary user identity assignment, and user authentication and authorization. For example, in the embodiments of this application, the AMF can determine, based on information transmitted by the 5G-RG, whether the AUN3 device initiating the registration request supports the 5G key hierarchy, and if it determines that the AUN3 device supports the 5G key hierarchy, it can generate the correct key using the corresponding derivation method.

[0109] 5. SMF: Responsible for managing PDU sessions on the 5G-RG, such as establishing, maintaining, and deleting PDU sessions. A PDU session is a channel used to transmit PDUs, and the 5G-RG and the data network transmit PDUs to each other via the PDU session. The SMF includes session-related functions such as session management (session establishment, modification, and release, etc.), service and session continuity (SSC) mode selection, and roaming. In the scenario shown in Figure 1, a PDU session established between the 5G-RG and the SMF may be used to transfer data from an AUN3 device.

[0110] 6. UPF: UPF includes user plane-related functions such as data packet routing and transmission, data packet detection, traffic usage reporting, QoS processing, legitimate interception, uplink data packet detection, and downlink data packet storage.

[0111] 7. UDM: The UDM is responsible for storing subscribers' subscription permanent identifiers (SUPI), generic public subscription identifiers (GPSI), credentials, and other information within the operator network. The SUPI is initially encrypted during transmission, and the encrypted SUPI is called the subscription concealed identifier (SUCI). Information stored by the UDM may be used for authentication and authorization of terminal devices for access to the operator network. Specifically, a subscriber in the operator network may be a user who uses services provided by the operator network, for example, a user who uses a China Telecom subscriber identity module (SIM) card, or a user who uses a China Mobile SIM card. The subscriber's credentials may be a long-term key stored on the SIM card, or a small file stored, for example, information related to the encryption of the SIM card, and may be used for authentication and / or authorization. For the sake of clarity, it should be noted that information such as persistent identifiers, credentials, security context, authentication data (cookies), and tokens related to verification / authentication and authorization are not limited to or distinguished in the embodiments of this application.

[0112] 8. AUSF: Typically used for primary authentication, i.e., authentication between the terminal device (subscriber) and the operator network. After receiving an authentication request initiated by the subscriber, the AUSF may perform authentication and / or authorization on the subscriber by using the authentication and / or authorization information stored in the UDM, or it may generate the subscriber's authentication and / or authorization information by using the UDM. The AUSF may also feed the authentication and / or authorization information back to the subscriber.

[0113] It can be understood that the aforementioned network elements or functions may be physical entities within a hardware device, software instances running on dedicated hardware, or virtualization functions instantiated on a shared platform (e.g., a cloud platform). In other words, network functions (NFs) may be implemented in hardware or software.

[0114] In Figure 1, N1, N2, N3, N4, and N6 are interface sequence numbers. For the meaning of interface sequence numbers, see, for example, the meanings defined in the 3rd Generation Partnership Project (3GPP) standard protocol. The meaning of interface sequence numbers is not limited in this application. Note that the names of the interfaces between network functions in the figure are examples only. During a particular implementation, the interface names of the system architecture may be alternatively named. This is not limited in this application. In addition, the names of the messages (or signaling) transmitted between the above network elements are also examples only and do not constitute a limitation on the function of the messages.

[0115] For the sake of clarity, in the embodiments of this application, network functions (such as AMF, SMF, or UPF) are collectively / briefly referred to as NF. In other words, in the embodiments of this application, the NF described below may be replaced with any network function. In addition, Figure 1 is merely an example illustrating some network functions, and the network functions described below are not limited to those shown in Figure 1.

[0116] The illustrated AMF, SMF, and UPF may be understood as network elements configured to implement different functions in a core network, and may be combined as needed to form, for example, network slices. These core network elements may be independent devices or integrated into the same device to implement different functions. The specific forms of the network elements described above are not limited in this application.

[0117] It should be further understood that the aforementioned names are defined solely to distinguish different functions and do not constitute any limitation to this application. This application does not preclude the possibility that different names may be used in 5G networks and other future networks. For example, in a 6G network, some or all of the aforementioned network elements may continue to use the term 5G, or other names may be used.

[0118] It should be further understood that Figure 1 merely illustrates an example of a scenario to which the communication method provided herein may be applied, and does not constitute any limitation to the scenarios to which the communication method provided herein may be applied. Alternatively, in this application, access by an authenticated non-3GPP device to a network may be equivalent to an authenticated non-3GPP device accessing the network via another type of RG (e.g., 6G-RG). We will not describe each embodiment individually here.

[0119] To facilitate understanding of the embodiments of this application, some basic concepts in this application will be briefly explained.

[0120] 1. Non-3GPP access: This means that technologies other than 3GPP access technologies, such as Wireless Fidelity (Wi-Fi), Bluetooth, or ZigBee, are used to access the network. 3GPP access means that 3GPP access technologies are used to access the mobile network. 3GPP access technologies include technologies such as 5G or LTE. Generally, with 3GPP access technologies, access can be understood as being provided by base station types such as next-generation node base stations (gNBs) in 5G systems or evolved NodeBs (eNBs) in long-term evolution (LTE).

[0121] 2. Non-3GPP access types: including untrusted non-3GPP access and trusted non-3GPP access, where untrusted non-3GPP access may be access by a terminal device through a wireless access node purchased by an individual, and trusted non-3GPP access may be access by a terminal device through a wireless access node deployed by an operator, or wireline access.

[0122] 3. Non-3GPP access network devices: including, but not limited to, non-3GPP interworking function (N3IWF), trusted non-3GPP gateway function (TNGF), trusted non-3GPP access point (TNAP), trusted wireless local area network interworking function (TWIF), or W-AGF.

[0123] The N3IWF may be configured to enable interconnection and interworking between terminal devices and the 3GPP core network by using non-3GPP technologies. The N3IWF supports communication with mobility management devices via the N2 interface and communication with user plane devices via the N3 interface.

[0124] TNAP may be configured to transmit authentication, authorization, and accounting (AAA) messages, for example, by encapsulating extensible authentication protocol (EAP) data packets into AAA messages and interacting with TNGF to forward EAP messages.

[0125] TNGF may be configured to support N2 and N3 interfaces, implement N2 signaling processing using AMF selection and SMF (relayed by AMF), and may support functions such as sessions, QoS, and transparent relaying of PDUs between terminal devices and user plane devices.

[0126] 4. Non-3GPP access procedures: If the non-3GPP access technology is an unreliable non-3GPP access technology, the non-3GPP access network device corresponding to the unreliable non-3GPP access technology may include an N3IWF, and the network topology structure may be equivalent to that of a radio access network (RAN) in a 3GPP access network, and N2 and N3 interfaces may be supported.

[0127] If the non-3GPP access technology is a reliable non-3GPP access technology, the non-3GPP access network device corresponding to the reliable non-3GPP access technology may include a TNGF, the network topology structure is equivalent to the RAN in a 3GPP access network, and N2 and N3 interfaces may be supported.

[0128] For ease of understanding, untrusted non-3GPP access procedures and trusted non-3GPP procedures will be described separately below, with reference to Figures 2(a) and (b).

[0129] Figure 2(a) shows an untrusted non-3GPP access architecture. A terminal device can access an untrusted non-3GPP device via a communication interface (e.g., the Y1 interface shown in Figure 2(a)). The untrusted non-3GPP device accesses the gateway N3IWF via a communication interface (e.g., the Y2 interface shown in Figure 2(a)). The N3IWF is connected to the AMF via a communication interface (e.g., the N2 interface shown in Figure 2(a)).

[0130] Figure 2(b) shows a trusted non-3GPP access architecture. Terminal devices can access a trusted non-3GPP access point via a communication interface (e.g., the Yt interface shown in Figure 2(b)). The trusted non-3GPP access point accesses a trusted non-3GPP gateway function via a communication interface (e.g., the Ta interface shown in Figure 2(b)). The trusted non-3GPP gateway function is connected to the AMF via a communication interface (e.g., the N2 interface shown in Figure 2(b)).

[0131] In addition, terminal devices may alternatively connect to the AMF by using 3GPP access technology. In other words, terminal devices may access the same AMF or different AMFs by using both 3GPP access technology and non-3GPP access technology. Alternatively, terminal devices may access the AMF by using only 3GPP access technology or by using only non-3GPP access technology.

[0132] 5. Procedure for registering terminal devices via untrusted non-3GPP: As shown in Figure 3, the procedure for registering terminal devices via untrusted non-3GPP includes the following steps.

[0133] S310:UE connects to an untrusted non-3GPP access network.

[0134] Specifically, the UE is connected to an untrusted, non-3GPP access device and assigned an IP address.

[0135] S320:UE selects N3IWF.

[0136] Specifically, the UE selects N3IWF and retrieves the address information for N3IWF.

[0137] S330:UE triggers the establishment of an Internet Protocol Security (IPSec) Security Association (IPSec SA) with N3IWF.

[0138] Specifically, the UE triggers the establishment of an IPSec SA with the N3IWF by initiating an initial exchange of Internet Key Exchange (IKE).

[0139] S340:UE sends request message #1 to N3IWF.

[0140] Request message #1 does not contain an authorized (AUTH) payload. Request message #1 can be understood as being used in an extensible authentication protocol (EAP) signaling dialogue. Optionally, request message #1 is called an IKE_AUTH request message.

[0141] S350:N3IWF sends response message #1 to the UE.

[0142] Response message #1 contains an EAP-Request / 5G-Start data packet. The EAP-Request / 5G-Start data packet is used to notify the UE about initiating an EAP-5G session. For example, response message #1 is used to notify the UE to begin sending a NAS message (the NAS message is encapsulated in the EAP-5G data packet).

[0143] Optionally, response message #1 is called the IKE_AUTH response message.

[0144] S360:UE sends request message #2 to N3IWF.

[0145] Request message #2 includes an EAP-response / 5G-NAS data packet, which contains access network (AN) parameters and a Non-Access Stratum-Protocol Data Unit (NAS-PDU), the NAS PDU carrying the registration request message. The AN parameters include parameter information used by N3IWF to select the AMF, such as a Globally Unique AMF Identifier (GUAMI), a selected Public Land Mobile Network (PLMN) identifier (ID) (or PLMN ID and NID), etc.

[0146] Optionally, request message #2 is called the IKE_AUTH request message.

[0147] If the UE has previously accessed a 3GPP system, for example by using 3GPP technology, the UE will include a 5G Globally Unique Temporary Identifier (5G-GUTI) in its registration request message.

[0148] If the UE has not previously accessed the 3GPP system, the registration request message may carry a concealed subscriber identifier (SUCI).

[0149] S370:N3IWF performs AMF selection.

[0150] S380:N3IWF sends a registration request message to AMF.

[0151] In possible implementations, if the registration request message does not carry the SUCI, or if the AMF is unable to verify the integrity protection of the registration request message, the AMF may obtain the UE's SUCI by sending request message #3 to the UE. In this implementation, the procedure of the method shown in Figure 3 further includes the following steps:

[0152] S381:AMF sends request message #3 to the UE via N3IWF. Request message #3 is used to request the UE to obtain SUCI.

[0153] Optionally, request message #3 is called a NAS identification request. For example, the AMF sends a NAS identification request to the N3IWF via the N2 communication interface, and the N3IWF encapsulates the NAS identification request in an EAP / 5G-NAS data packet and sends the EAP / 5G-NAS data packet to the UE. The data packet sent to the UE by the N3IWF is sometimes called an IKE_AUTH request message.

[0154] S382:UE sends response message #3 to AMF via N3IWF. Response message #3 carries UE's SUCI.

[0155] Optionally, response message #3 is called the NAS Identification Response. For example, the UE encapsulates the NAS Identification Response in an EAP / 5G-NAS data packet and sends the EAP / 5G-NAS data packet to the N3IWF, which then sends the NAS Identification Response to the AMF via the N2 communication interface. The data packet sent by the UE to the N3IWF is sometimes called the IKE_AUTH response message.

[0156] In another possible implementation, when the registration request message carries the SUCI, or when the AMF successfully verifies the integrity protection of the registration request message, or when the AMF obtains the SUCI from response message #3, the AMF may initiate the procedure to perform authentication with the UE. In this implementation, the procedure of the method shown in Figure 3 further includes the following steps:

[0157] S391:AMF selects the Authentication Server Function (AUSF) network element.

[0158] S392: The AMF sends an authentication request message to the AUSF. Optionally, the authentication request message is called an AAA Key Request message. The authentication request message carries either a SUCI or a SUPI.

[0159] S393: AUSF performs certification to the UE. The specific procedure for AUSF to perform certification to the UE is not described in detail in this embodiment. For details, please refer to the description of the relevant technology in step 7 of section 7.2.1 of the current 3GPP standard TS33.501.

[0160] S394: AUSF sends the Security Anchor function (SEAF) key to AMF.

[0161] After authentication is complete, AUSF sends the SEAF key to AMF, for example, in an AAA key response message, which in turn carries the EAF key.

[0162] AMF can derive the NAS security key and the N3IWF security key by using the SEAF key. The N3IWF key is used by the UE and N3IWF to establish an IPSec SA.

[0163] S395:AMF sends a NAS security mode command to the UE via N3IWF. NAS security is activated. The NAS security mode command includes EAP-success, indicating that the EAP-AKA' authentication performed by the core network was successful.

[0164] S396:UE sends a Security Mode Complete message to the AMF via N3IWF.

[0165] Specifically, the N3IWF forwards the NAS security mode command sent by the AMF to the UE, and then sends the NAS security mode completion message sent by the UE back to the AMF.

[0166] S397: AMF sends request message #4 to N3IWF. Request message #4 contains the N3IWF key.

[0167] Optionally, request message #4 is sometimes referred to as the Protocol for NG Interface (NGAP) Initial Context Setup Request message.

[0168] Specifically, after the AMF receives a NAS security mode completion message from the UE, the AMF sends an NGAP initial context setup request to the N3IWF, where the NGAP initial context setup request includes the N3IWF key.

[0169] S398:N3IWF sends EAP-Success to the UE. Once the UE receives EAP-Success, this indicates that the EAP-5G session is complete, and no further EAP-5G data packets are exchanged.

[0170] In yet another possible implementation, if the registration request message carries 5G-GUTI and the AMF successfully verifies the integrity protection of the registration request message, the AMF may decide not to initiate authentication. In this case, steps S381, S382, S391-S398 may not be performed.

[0171] Furthermore, the UE and N3IWF establish an IPSec SA using the acquired N3IWF key described above. The procedure for the method shown in Figure 3 further includes the following steps:

[0172] S301: An IPSec SA is established between the UE and N3IWF by using the N3IWF key.

[0173] The IPSec SA is called a signaling IPSec SA. After the signaling IPSec SA is established, N3IWF notifies AMF that the UE's context has been created by using the NGAP initial context setup response. In this case, the signaling IPSec SA is configured to run in tunnel mode, and N3IWF assigns the UE an "internal" IP address and NAS_IP_ADDRESS. All subsequent NAS messages are sent via the signaling IPSec SA. For uplink NAS messages sent by the UE to AMF, the source address is the UE's "internal" IP address and the destination address is NAS_IP_ADDRESS. For downlink NAS messages sent by AMF to the UE, the source address is NAS_IP_ADDRESS and the destination address is the UE's "internal" IP address.

[0174] S302: The AMF sends an N2 message to the N3IWF. The N2 message includes a NAS Registration Accept message that is sent to the UE. Subsequently, when the AMF registers with the UDM, the AMF must provide the UDM with the access type for non-3GPP access.

[0175] S303:N3IWF sends a NAS registration request to the UE via the signaling IPSec SA.

[0176] 6. Procedure for registering terminal devices via trusted non-3GPP: As shown in Figure 4, the procedure for registering terminal devices via trusted non-3GPP includes the following steps.

[0177] S410: The UE selects the PLMN and a Trusted Non-3GPP Access Network (TNAN) connected to the PLMN. The UE establishes a Layer-2 connection to the Trusted Non-3GPP Access Point (TNAP).

[0178] S420:TNAP initiates the EAP procedure. The EAP message is encapsulated in an L2 data packet, for example, an IEEE 802.3 or 802.1x, or a Point-to-Point Protocol (PPP) data packet.

[0179] Optionally, TNAP may send an EAP request or identification message (EAP-Req / Identity) to the UE to request the UE's identification information.

[0180] S430:UE sends the Network Access Identifier (NAI) to TNAP.

[0181] NAI indicates that 5G connectivity (5G bandwidth) to a specific PLMN is being requested.

[0182] Optionally, the UE sends an EAP-Res / Identity message to the TNAP, where the EAP-Res / Identity message includes a NAI.

[0183] For example, NAI="<any_username> @nai.5gc.mnc <mnc>.mcc <mcc>The URL is ".3gppnetwork.org". The NAI triggers TANP to send an AAA request to TNGF.

[0184] S440:TANP sends an AAA request to TNGF. EAP data packets between TNAP and TNGF are encapsulated via an AAA message. The AAA request further includes a TNAP identifier, which may be used as User Location Information (ULI).

[0185] S450:TNGF initiates an EAP-5G session. Specifically, TNGF sends an EAP-request / 5G-initiate data packet to the UE. The EAP-request / 5G-initiate data packet is used to notify the UE about initiating an EAP-5G session, for example, by instructing the UE to begin sending NAS messages (by encapsulating NAS messages in the EAP-5G data packet).

[0186] S460:UE sends an EAP response data packet / 5G-NAS data packet to TNGF, where the data packet contains AN parameters and a NAS-PDU, and the NAS PDU carries the registration request message. The AN parameters contain parameter information used by TNGF to select an AMF, e.g., GUAMI, and a selected PLMN ID (or PLMN ID and NID).

[0187] Optionally, if the UE has previously accessed a 3GPP system, for example by using 3GPP technology, the UE may include 5G-GUTI in the registration request message. If the UE has not previously accessed a 3GPP system, the registration request message will carry SUCI.

[0188] S470:TNGF performs AMF selection.

[0189] S480:TNGF sends a registration request message to AMF.

[0190] In possible implementations, if the registration request message does not carry the SUCI, or if the AMF successfully verifies the integrity protection of the registration request message, the AMF may obtain the UE's SUCI by sending request message #5 to the UE. In this implementation, the procedure of the method shown in Figure 4 further includes the following steps:

[0191] S481:AMF sends request message #5 to the UE via N3IWF. Request message #5 is used to request the UE to obtain SUCI.

[0192] Optionally, request message #5 is called a NAS identification request. For example, the AMF sends the NAS identification request to the N3IWF via the N2 communication interface, and the N3IWF encapsulates the NAS identification request in an EAP / 5G-NAS data packet and sends the EAP / 5G-NAS data packet to the UE. The data packet sent to the UE by the N3IWF is sometimes called an IKE_AUTH request message.

[0193] S482:UE sends response message #5 to AMF via N3IWF. Response message #5 carries the UE's SUCI.

[0194] Optionally, response message #5 is called the NAS Identification Response. For example, the UE encapsulates the NAS Identification Response in an EAP / 5G-NAS data packet and sends the EAP / 5G-NAS data packet to the N3IWF, which then sends the NAS Identification Response to the AMF via the N2 communication interface. The data packet sent by the UE to the N3IWF is sometimes called the IKE_AUTH response message.

[0195] In another possible implementation, when the registration request message carries the SUCI, or when the AMF successfully verifies the integrity protection of the registration request message, the AMF may initiate a procedure to perform authentication with the UE. In this embodiment, the procedure of the method shown in Figure 4 further includes the following steps:

[0196] S491: AMF selects AUSF.

[0197] S492:AMF sends an authentication request message to AUSF.

[0198] S493: AUSF performs authentication to the UE. In particular, the procedure by which AUSF performs authentication to the UE is not described in detail in this embodiment. For details, please refer to the description of the relevant technology.

[0199] S494: AUSF sends the SEAF key to AMF.

[0200] After authentication is complete, AUSF sends the SEAF key to AMF, which uses this key to derive the NAS security key and the TNGF security key.

[0201] S495:AMF sends a NAS security mode command to the UE via TNGF. NAS security is activated. The NAS security mode command includes EAP-success, indicating that the EAP-AKA' authentication performed by the core network was successful.

[0202] S496:UE sends a Security Mode Complete message to AMF via TNGF.

[0203] Specifically, the TNGF forwards the NAS security mode command sent by the AMF to the UE, and then sends the NAS security mode completion message sent by the UE back to the AMF.

[0204] S497: AMF sends request message #6 to TNGF. Request message #6 contains the TNGF key.

[0205] Optionally, request message #6 is sometimes referred to as the NGAP initial context setup request message.

[0206] Specifically, after the AMF receives a NAS security mode completion message from the UE, the AMF sends an NGAP initial context setup request message to the TNGF, where the NGAP initial context setup request message includes the TNGF key.

[0207] S498:TNGF sends an EAP request / 5G notification to the UE.

[0208] Specifically, the EAP-Response / 5G-Notification includes the TNGF's address information, which the UE later uses to establish an IPSec SA with the TNGF. The UE sends the EAP-Response / 5G-Notification to the TNGF.

[0209] S499:TNGF sends an AAA message to TNAP.

[0210] The AAA message includes the EAP success message sent to the UE and the TNAP key derived by TNGF and sent to TNAP by TNGF.

[0211] S401:TNAP sends EAP-Success to the UE. Upon receiving EAP-Success, the UE indicates that the EAP-5G session is complete and no further EAP-5G data packets will be exchanged.

[0212] In yet another possible implementation, if the registration request message carries 5G-GUTI and the integrity protection of the registration request message is successfully verified, the AMF may decide not to initiate authentication. In this case, steps S481, S482, S491-S401 do not need to be performed.

[0213] S402: Establish L2 security between UE and TNAP.

[0214] S403: The UE receives the TNAN's IP configuration, for example, according to the Dynamic Host Configuration Protocol (DHCP), that is, the UE obtains its own IP address.

[0215] S404: The UE initiates the establishment of a secure NWt connection to the TNGF (the connection interface between the UE and the TNGF is defined as NWt by default). The UE successfully connects to the TNGF and obtains an IP configuration. The UE initiates an IKE_INIT dialogue by using the TNGF's address. In this dialogue, the UE identifier (ID) provided by the UE is the same as the UE ID included in step S460. This allows the TNGF to determine the TNGF key corresponding to the UE. The TNGF key is used for bidirectional authentication. Transmission between the UE and the TNGF is not encrypted because the network is trusted (the transmission is not encrypted because it is deployed by the operator and considered trusted).

[0216] The TNGF assigns the UE an "internal" IP address, TCP port, NAS_IP_ADDRESS, and differentiated services code point (DSCP) value. All IP data packets transmitted between the UE and the TNGF are marked with the DSCP value. The UE and TNGF can map the DSCP value to the corresponding QoS class. After the signaling IPSec SA is established, the UE establishes a TCP connection to the TNGF using the NAS_IP_ADDRESS and TCP port. All subsequent NAS messages are sent via the signaling IPSec SA. For uplink NAS messages sent by the UE to the AMF, the source address is the UE's "internal" IP address and the destination address is NAS_IP_ADDRESS. For downlink NAS messages sent by the AMF to the UE, the source address is NAS_IP_ADDRESS and the destination address is the UE's "internal" IP address.

[0217] S405:TNGF sends a notification message to AMF. After the NWT connection is successfully established, TNGF notifies AMF that the UE context has been created by using a notification message (e.g., NGAP initial context setup response message).

[0218] S406: AMF sends an N2 message to TNGF.

[0219] The N2 message includes a NAS Registration Accept message sent to the UE. Subsequently, when the AMF registers with the UDM, the AMF must provide the UDM with an access type for non-3GPP access. The TNGF sends the NAS registration request to the UE via the newly established signaling IPSec SA.

[0220] 7. AUN3 devices that do not support the 7.5G key hierarchy access the 5GC: As shown in Figure 5, an AUN3 device that does not support the 5G key hierarchy accesses the 5GC, which involves the following steps.

[0221] S510: The AUN3 device attempts to establish an L2 connection to the RG by using Ethernet or Wi-Fi.

[0222] S520:RG sends the EAP request / identity to the AUN3 device. The EAP authentication process is initiated using the EAP request / identity.

[0223] Optionally, the RG sends EAP requests / identifications to the AUN3 device in a layer frame (e.g., Extensible Authentication Protocol Over LAN (EAPOL)).

[0224] S530: The AUN3 device sends an EAP response / identification to the RG.

[0225] Specifically, the AUN3 device returns an EAP response / identification in the format username@realm, where the EAP response / identification includes the AUN3 device's Network Access Identifier (NAI). If the AUN3 device supports SUPI protection, the username portion of the NAI may be encrypted.

[0226] Optionally, if the RG is FN-RG, the FN-RG sends an EAP response / identity containing the NAI to the W-AGF. The W-AGF uses a NULL scheme to construct a SUCI based on the SUPI in the NAI and sends a NAS registration request message containing the SUCI and AUN3 device instructions to the AMF.

[0227] Optionally, if the RG is a 5G-RG, the 5G-RG constructs a SUCI based on the SUPI in the NAI and sends a NAS registration request message to the AMF containing the SUCI and AUN3 device instructions.

[0228] S540:RG sends a registration request message to AMF / SEAF.

[0229] For S550:AMF / SEAF, select AUSF.

[0230] S560:AMF / SEAF sends an authentication request message to AUSF.

[0231] Specifically, AMF / SEAF selects AUSF based on the SUCI in the received registration request and sends an authentication request message (e.g., Nausf_UEAuthentication_Authentication request message) to AUSF. The authentication request message includes the SUCI of the AUN3 device and the AUN3 device instruction.

[0232] S570: AUSF sends a Get Request message (Nudm_UEAuthentication_Get request) to the UDM, which includes the SUCI and AUN3 device directive for the AUN3 device.

[0233] S580: The UDM selects the authentication method. Specifically, the UDM calls the SIDF to decrypt the SUCI, obtains the SUPI, and selects the authentication method based on the SUPI.

[0234] S590: The UDM sends an Get Response message (Nudm_UEAuthentication_Get response) to the AUSF, which includes the SUPI of AUN3 and instructions for the selected authentication method, for example, instructions for the selected EAP-AKA.

[0235] S591: The AUSF and AUN3 devices perform the selected authentication method.

[0236] If EAP authentication between AUSF and the AUN3 device is successfully completed, the procedure shown in Figure 5 further includes the following steps:

[0237] S592:AUSF sends an EAP-Success message to AMF / SEAF and includes SUPI and MSK in the Nausf_UEAuthentication_Authentication response message.

[0238] S593: AMF / SEAF sends an authentication result message to the RG. AMF / SEAF sends an authentication result message including the EAP success message and MSK to the 5G-RG.

[0239] S594: The RG sends an EAP success message to the AUN3 device. Specifically, the RG sends an EAP success message to the AUN3 device in a Layer 2 frame.

[0240] S595: The AUN3 and RG perform a four-way handshake to establish a WLAN security connection. The AUN3 device and RG use the first 256 bits of the MSK as the PMK. The WLAN key is obtained from the PMK.

[0241] 8. AUN3 device supporting the 5G key hierarchy accesses the 5GC: As shown in Figure 6, an AUN3 device supporting the 5G key hierarchy accesses the 5GC, which involves the following steps.

[0242] S610:AUN3 establishes a wireless LAN connection with an access point (AP) (e.g., an RG shown in Figure 6) of the wireless LAN access network (AN). Optionally, the AUN3 device establishes a WLAN connection to the RG based on the WLAN connection establishment procedure specified in the current protocol (e.g., IEEE 802.11). The specific WLAN connection establishment procedure is not limited to this embodiment.

[0243] S620:RG sends the EAP request / identity to the AUN3 device. The EAP request / identity is used to initiate the EAP authentication process.

[0244] Optionally, the RG sends EAP requests / identifications to the AUN3 device in a layer frame (e.g., Extensible Authentication Protocol Over LAN (EAPOL)).

[0245] S630: The AUN3 device sends an EAP response / identification to the RG.

[0246] Specifically, the AUN3 device returns an EAP response / identification in the format username@realm, where the EAP response / identification includes the AUN3 device's Network Access Identifier (NAI) or SUCI of the 5G-GUTI.

[0247] Optionally, if the RG is FN-RG, the FN-RG sends an EAP response / identification including the NAI to the W-AGF. The W-AGF creates a registration request on behalf of the AUN3 device, indicating that registration will be performed on behalf of the AUN3 device, and at this point, the interface between the AUN3 device and the RG needs to be secured. The W-AGF selects AMF / SEAF, and the W-AGF sends the registration request to AMF / SEAF on behalf of the AUN3 device. The registration request includes the NAI SUCI, the wired network name (if available), and new instructions. The same message content is forwarded from AMF to AUSF, and then from AUSF to UDM.

[0248] Optionally, if the RG is a 5G-RG, the 5G-RG sends a NAS registration request message to the AMF, which includes the SUCI and encryption instructions required by the AUN3 device.

[0249] S640:RG sends a registration request message to AMF / SEAF. The registration request message includes the received SUCI and the encryption instructions required by the AUN3 device.

[0250] S641: For AMF / SEAF, select AUSF.

[0251] S642: AMF / SEAF sends an authentication request message to AUSF.

[0252] S643: AUSF sends a request message to the UDM.

[0253] S644: UDM selects the authentication method.

[0254] S645: The UDM sends an acquisition response message to the AUSF.

[0255] For steps S641 to S645, please refer to the explanation of steps S550 to S590 in Figure 5. Further details will not be explained here.

[0256] S650: Perform EAP-AKA' authentication. Optionally, the EAP-AKA' authentication process is performed according to the definition of the current protocol (e.g., section 6.1.3.1 of TS33.501[4]).

[0257] S660: The AMF derives the WAGF key. Specifically, in step S640, the AMF derives the WAGF key based on the new cryptographic instructions required by the AUN3 device.

[0258] S670:AMF provides the WAGF key (KWAGF') to W-AGF. Optionally, AMF sends a NAS security mode command mode to provide the WAGF key to W-AGF.

[0259] S680:W-AGF derives KRG as the PMK key. Specifically, W-AGF derives KRG from the WAGF key (KWAGF') and uses KRG as the PMK key.

[0260] S690:RG and AUN3 devices derive the WLAN key. Specifically, RG and AUN3 devices obtain the WLAN key from the PMK key.

[0261] S691: RG establishes a secure connection to the AUN3 device. Optionally, RG and the AUN3 device perform a four-way handshake to establish a secure connection to the WLAN AN.

[0262] 9. Non-5G Key Hierarchy: In Figure 5, the above procedure for the AUN3 device to access 5GC is shown, and the UE and network-side key hierarchy is shown in Figure 7.

[0263] Figure 7 shows that the long-term key is stored in the AUN3 device and the UDM. When the CK and IK appear in both the UDM and the AUSF, this indicates that the CK and IK are sent from the UDM to the AUSF. The MSK is generated by the AUSF and sent to the WAGF via the AMF. The WAGF then generates the PMK based on the MSK and sends the PMK to the AP. The AP then generates its own key, and the UE generates the same key according to the procedure. In this case, the AP may correspond to the 5G-RG described in the procedure above.

[0264] 10.5G Key Hierarchy: In Figure 6, the above procedure for the AUN3 device to access 5GC is shown, and the UE and network-side key hierarchy is shown in Figure 8.

[0265] Figure 8 shows that the long-term key is stored in the AUN3 device and the UDM. When CK and IK appear in both the UDM and AUSF, this indicates that the key is sent from the UDM to the AUSF. Kausf or Kseaf is generated by the AUSF and sent to the AMF. The AMF then generates Kamf based on Kausf or Kseaf and sends Kamf to the WAGF. Next, the WAGF generates PMK based on Kamf and sends PMK to the AP. The AP then generates an AP key, and the UE generates the same key according to the procedure. In this case, the AP may correspond to 5G-RG as described in the procedure above.

[0266] In addition, several explanations are provided below to facilitate understanding of the embodiments of this application.

[0267] Firstly, in the embodiments of this application, “indicate” may include “directly indicate” and “indirectly indicate.” When it is stated that the reference information indicates A, the reference information may indicate A directly or indirectly, but it does not necessarily mean that the reference information includes A.

[0268] The information indicated by the instruction information is called the instruction target information. In a specific implementation process, there are multiple ways to indicate the instruction target information. Furthermore, the instruction information may be transmitted as a whole, or it may be divided into multiple sub-information parts for individual transmission. In addition, the transmission cycle and / or transmission opportunities of these sub-information parts may be the same or different. The specific transmission method is not limited herein. The transmission cycle and / or transmission opportunities of these sub-information may be predetermined, for example, predetermined according to a protocol, or configured by the transmitting end device transmitting configuration information to the receiving end device.

[0269] Secondly, “at least one” as used in the embodiments of this application means one or more, and “multiple” means two or more. In addition, in the embodiments of this application, “first,” “second,” and various numbers (e.g., “#1,” “#2”) are used merely for illustrative purposes and not to limit the scope of the embodiments of this application. The sequence numbers of the following processes do not imply execution order. The execution order of the processes should be determined based on the function and internal logic of the processes and should not constitute any limitation on the implementation process of the embodiments of this application. It should be understood that the objects described in this manner may be interchangeable where appropriate, and therefore other solutions besides the embodiments of this application can be described. In addition, in the embodiments of this application, words such as “910” and “920” are merely identifiers for ease of explanation and do not restrict the order in which the steps are performed.

[0270] Thirdly, in embodiments of this application, words such as “example” or “for example” are used to give examples, illustrations, or explanations. Any embodiment or design scheme described as “example” or “for example” in embodiments of this application should not be described as being preferable or having more advantages than another embodiment or design scheme. More precisely, the use of words such as “example” or “for example” is intended to present a relative concept in a particular way.

[0271] Fourth, “storage” in the embodiments of this application may be storage in one or more memories. One or more memories may be separately located or integrated into an encoder, decoder, processor, or communication device. Alternatively, a portion of one or more memories may be located separately, or a portion of one or more memories may be integrated into a decoder, processor, or communication device. The type of memory may be any form of storage medium; this is not limited to this application.

[0272] Fifth, “protocol” in the embodiments of this application refers to a standard protocol in the field of communications, including, for example, the LTE protocol, the NR protocol, and related protocols applicable to future communications systems. This is not limited to the present application.

[0273] Sixth, in the embodiments of this application, "in a case of," "when," and "if" may be used interchangeably. Note that unless the differences between these three are emphasized, they express the same meaning.

[0274] Seventh, in embodiments of this application, all terms and English abbreviations are examples given for the sake of clarity and should not constitute any limitation to this application. This application does not preclude the possibility of defining other terms that may implement the same or similar functions in existing or future protocols.

[0275] Eighth, in this specification, “and / or” is simply a relation to describe related objects, and indicates that three such relations may exist. For example, A and / or B may represent the following three cases: that only A exists, that both A and B exist, or that only B exists. In addition, in this specification, the letter “ / ” indicates an “or” relationship between related objects.

[0276] Referring to Figure 1, a scenario in which the communication method provided in embodiments of this application can be applied is briefly described, and the basic concepts that may be used in embodiments of this application are described, in which the procedure for an AUN3 device that does not support the 5G key hierarchy to access the 5GC and the procedure for an AUN3 device that supports the 5G key hierarchy to access the 5GC are described. Based on the description of the procedure for an AUN3 device to access the 5GC in Figures 5 and 6, the AMF and AUSF mainly use an identifier, i.e., an encryption instruction used in the procedure for an AUN3 device to access the GC shown in Figure 6, to determine whether the AUN3 device supports the 5G key hierarchy. When an encryption instruction is present, the AMF and AUSF generate the relevant key based on the 5G key hierarchy. When there is no encryption instruction, the AMF and AUSF generate the relevant key based on a non-5G key hierarchy. Specifically, the encryption instruction is added by the 5G-RG when the 5G-RG sends a NAS registration request message to the AMF.

[0277] A problem in the procedure for an AUN3 device to access 5GC is how 5G-RG determines and confirms whether the AUN3 device supports the 5G key hierarchy. Therefore, this application primarily addresses a method for determining whether an AUN3 device supports the 5G key hierarchy.

[0278] This application provides a communication method which may be applied to the communication scenario shown in Figure 1. The application scenario is not limited to this application.

[0279] The specific structure of the implementer of the method provided in the embodiments of this application is not particularly limited in the following embodiments, provided that communication can be performed in accordance with the method provided in the embodiments of this application by executing a program that records the code of the method provided in the embodiments of this application. For example, the method provided in the embodiments of this application may be executed by a network element or a functional module that can call and execute a program within the network element.

[0280] FIG. 9 is a schematic flowchart of the communication method according to the present application. The following steps are included.

[0281] S911: The first gateway registers with the core network.

[0282] In this embodiment, the first gateway is a gateway that can be connected to the core network, plays a role in assisting the AUN3 device to access the core network, and may be another network element that can implement the functions of 5G-RG or 5G-RG. For the convenience of description, hereinafter, an example in which the first gateway is 5G-RG is used for explanation. When the first gateway is another device (node or network element), the following 5G-RG is replaced by the corresponding device. Details will not be described again.

[0283] In this embodiment, for 5GC, 5G-RG may be regarded as a terminal device. For the procedure of 5G-RG registering with 5GC, refer to the description of the procedure of a terminal device in the current related technology registering with 5GC. In this embodiment, how 5G-RG registers with 5GC will not be described in detail.

[0284] S910: The AUN3 device establishes a connection with the 5G-RG.

[0285] In this embodiment, the AUN3 device is a terminal device connected to the core network via 5G-RG and may be understood as a terminal device that supports non-3GPP communication (for example, Wi-Fi communication).

[0286] Specifically, after establishing a connection to the 5G-RG, the AUN3 device can access the core network via that connection. The AUN3 device can initiate the registration procedure to the core network via the 5G-RG. For example, the AUN3 device can send a registration request to the 5G-RG by using the EAP authentication procedure, and then the 5G-RG forwards the registration request to the core network to initiate the registration procedure between the AUN3 device and the 5G-RG.

[0287] The procedure of the method shown in FIG. 9 further includes the following steps.

[0288] S921: The 5G-RG sends a first request message to the AUN3 device, or in other words, the AUN3 device receives the first request message from the 5G-RG.

[0289] Specifically, the first request message is used to request identification information from the AUN3 device, and the identification information is used by the core network to perform identification authentication on the AUN3 device. For example, the first request message is used to initiate an authentication procedure. In this case, the first request message may be an EAP request / identification message. It should be understood that the first request message may alternatively be another message that can request the identification information of the AUN3 device. The specific message type of the first request message is not limited in this embodiment of the present application as long as the corresponding function can be implemented. For the sake of convenience of description, hereinafter, an example where the first request message is an EAP-request / identification message is used for the purpose of description.

[0290] Another message may be sent between step S910 and step S921. This is not particularly limited in this embodiment of the present application.

[0291] S920: AUN3 sends a first response message to 5G-RG, in other words, 5G-RG receives a first response message from the AUN3 device. The first response message contains the identification information of the AUN3 device and indicates whether the AUN3 device supports the first key hierarchy.

[0292] Optionally, when the first request message is an EAP response / identification request message, the first response message further includes an EAP response message to respond to the first request message.

[0293] In this embodiment, the first key hierarchy may be any key hierarchy. For example, the first key hierarchy may be a 5G key hierarchy, a non-5G key hierarchy, a 4G 3GPP key hierarchy (see the relevant definition in TS33.401), a 4G non-3GPP key hierarchy (see the relevant definition in TS33.402), or one of the other key hierarchies.

[0294] The method for deriving the keys necessary for security protection on the network side when an AUN3 device supports the first key hierarchy is different from the method for deriving the keys necessary for security protection on the network side when an AUN3 device does not support the first key hierarchy.

[0295] Specifically, the AUN3 device and network derive the key required for security protection based on whether the AUN3 device supports the first key hierarchy. When the AUN3 device supports the first key hierarchy, the AUN3 device and network derive the key required for security protection using the first key derivation method. When the AUN3 device does not support the first key protection method, the AUN3 device and network derive the key required for security protection using the second key derivation method. The first key derivation method may be understood as the AUN3 device and network performing key derivation based on the first key hierarchy, and the second key derivation method may be understood as the AUN3 device and network performing key derivation based on the second key hierarchy. The second key hierarchy is a different key generation method from the first key hierarchy. For the definition of the second key hierarchy, please refer to the relevant explanation of the first key hierarchy. For example, if the 5G key hierarchy is the first key hierarchy, then the non-5G key hierarchy is the second key hierarchy.

[0296] For example, the first key hierarchy may be the 5G key hierarchy described in the basic concepts above (illustrated in Figure 8), or it may be a key hierarchy defined in a future 3GPP standard. This embodiment will be explained using the 5G key hierarchy described in the basic concepts as an example. When the AUN3 device supports the 5G key hierarchy, the procedure for deriving keys on the network side is as follows: AUSF generates Kausf based on CK and IK. AUSF uses Kausf or Kseaf and sends Kseaf to AMF. AMF generates Kamf based on Kseaf, further generates Kwagf, and transmits Kwagf to WAGF. WAGF generates PMK based on Kwagf and transmits PMK to 5G-RG. 5G-RG generates the keys necessary for security protection based on PMK. The procedure for deriving keys on the AUN3 device is as follows: The AUN3 device derives CK and IK based on the locally stored long-term key, generates Kausf based on CK and IK, generates Kseaf based on Kausf, generates Kamf based on Kseaf, generates Kwagf based on Kamf, then generates PMK based on Kwagf, and finally generates the key required for security protection based on PMK.

[0297] Alternatively, if the AUN3 device does not support the 5G key hierarchy, the procedure for deriving keys on the network side is as follows: The AUSF generates an MSK based on the CK and IK, and transmits the MSK to the WAGF via the AMF. The WAGF generates a PMK based on the MSK and transmits the PMK to the 5G-RG. The 5G-RG generates the keys necessary for security protection based on the PMK. The procedure for deriving keys on the AUN3 device side is as follows: The AUN3 device derives the CK and IK based on the locally stored long-term key, generates an MSK based on the CK and IK, then generates a PMK based on the MSK, and finally generates the keys necessary for security protection based on the PMK.

[0298] The security protections described above may be understood as encryption and integrity protection for the connection between the AUN3 device and the 5G-RG. For example, the sender performs encryption and integrity protection on the message based on the generated key, and the receiver performs decryption and integrity verification on the message based on the key.

[0299] In this embodiment, the AUN3 device sends a first response message to the 5G-RG to help the 5G-RG determine whether the AUN3 device supports the first key hierarchy. As a result, subsequent core network elements can determine whether the AUN3 device currently requesting access supports the first key hierarchy, select an appropriate key derivation method, and generate a key, thereby improving communication security.

[0300] Optionally, in this embodiment, the first response message transmitted by the AUN3 device to the 5G-RG includes an EAP response message and information indicating whether the AUN3 device supports the first key hierarchy, which may be understood as the AUN3 device transmitting the EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG. The AUN3 device transmitting the EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG includes, but is not limited to, the following possible implementations.

[0301] In a possible implementation, the AUN3 device sending an EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG is: the AUN3 device sends an EAP response message to the 5G-RG, where the EAP response message includes first instruction information. In this implementation, the information indicating whether the AUN3 device supports the first key hierarchy may be understood as an information element (IE) in the EAP response message, in addition to the AUN3 identifier, carrying information indicating whether the AUN3 device supports the first key hierarchy. For example, the first response message is EAP-Response / Identifier (AUN3 ID, information indicating whether the AUN3 device supports the first key hierarchy).

[0302] In another possible implementation, the AUN3 device sends an EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG: The AUN3 device sends an EAP response message to the 5G-RG, where the EAP response message includes information indicating whether the AUN3 device supports the first key hierarchy. In this implementation, the information indicating whether the AUN3 device supports the first key hierarchy may be understood as the EAP response message containing only the AUN3 identifier, in which case the AUN3 identifier has an indicative function. For example, the first response message is EAP-Response / Identifier (AUN3 ID).

[0303] In yet another possible implementation, the AUN3 device sending the EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG is: the AUN3 device separately sends the EAP response message and information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG. In this implementation, the information indicating whether the AUN3 device supports the first key hierarchy may be understood as a newly added IE outside of the EAP response message.

[0304] In this embodiment, it should be understood that the method of transmitting information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG is not limited. Existing messages or existing IEs may be reused to transmit the first instruction information, or newly added signaling or newly added IEs may be used to transmit information indicating whether the AUN3 device supports the first key hierarchy. Further details will not be described here. For example, the first response message may be an EAP response / identification and information indicating whether the AUN3 device supports the first key hierarchy.

[0305] As an example, and not an exhaustive one, the procedure in which the 5G-RG sends a first request message to the AUN3 device in step S921, and the AUN3 device sends a first response message to the 5G-RG in step S920, is a set of messages that must be sent between the AUN3 device and the 5G-RG to perform the EAP authentication procedure. For example, the first request message includes an EAP request message, and the first response message includes an EAP response message. For a description of the EAP request message and EAP response message, please refer to the description of the mentioned messages for initiating the EAP authentication procedure in the current relevant technology. Descriptions of the EAP request message and EAP response message are provided in the following three implementations (e.g., Implementation A, Implementation B, and Implementation C below).

[0306] Implementation A: In this embodiment, if an unreliable non-3GPP technology is used for access between the AUN3 device and the 5G-RG, refer to the description of response message #1 in the registration procedure in Figure 3 for a relevant explanation of the first request message, and refer to the description of request message #2 in the registration procedure in Figure 3 for a relevant explanation of the first response message. Further details will not be explained here again.

[0307] When implemented as Implementation A, by transmitting IKE_AUTH request messages and IKE_AUTH response messages between the AUN3 device and the 5G-RG, the AUN3 device is notified regarding the start of an EAP-5G session. After receiving an EAP-Request / 5G-Start data packet, the AUN3 device transmits an EAP response message. For specific procedures, refer to the descriptions of steps S330 to S360 of the registration procedure shown in FIG. 3. The AUN3 device is regarded as the UE in FIG. 3, and the 5G-RG is regarded as the N3IWF in FIG. 3. Details will not be explained again here.

[0308] Implementation B: In this embodiment, when a reliable non-3GPP technology is used for access between the AUN3 device and the 5G-RG, for the related description of the mentioned first request message, refer to the description of the EAP-Request / Identity message in the registration procedure of FIG. 4, and for the related description of the first response message, refer to the description of the EAP Response Data Packet / 5G-NAS Data Packet in the registration procedure of FIG. 4. Details will not be explained again here.

[0309] When implemented as Implementation B, the AUN3 device is notified regarding the start of an EAP-5G session by transmitting an EAP-Request / Identity message, an EAP-Response / Identity message, and an EA Request / 5G-Start data packet between the AUN3 device and the 5G-RG. For specific procedures, refer to the descriptions of steps S420 to S460 of the registration procedure shown in FIG. 4. The AUN3 device is regarded as the UE in FIG. 4, and the 5G-RG is regarded as the TNAP and TNGF in FIG. 4. Details will not be explained again here.

[0310] For example, the first response message mentioned in implementations A and B includes EAP-Response / 5G-NAS data packet #1, which includes AN parameters and a registration request message. The AN parameters include parameter information used by 5G-RG to select the AMF, such as GUAMI, the selected PLMN ID (or PLMN ID and NID), etc.

[0311] If an AUN3 device has previously accessed a 3GPP system, for example by using 3GPP technology, the AUN3 device may include a 5G-GUTI in the registration request message. If an AUN3 device has not previously accessed a 3GPP system, the registration request message will carry a SUCI.

[0312] In the case shown in Implementation C, if a conventional access method is used between the AUN3 device and the 5G-RG in this embodiment, for example, in relation to the access method referred to in IEEE 802.1x, see the description of steps S520 and S530 of the procedure shown in Figure 5, or the description of steps S620 and S630 of the procedure shown in Figure 6, for a relevant explanation of the first request message.

[0313] In the three implementations described above, regarding the method of sending the first response message, the first request message may be understood to be an EAP-request / identification message or an EAP-request / 5G-start message, and the first response may be understood to be an EAP-response / identification message or an EAP-response / 5G-NAS message. When the first response is an EAP-response / 5G-NAS message, according to the above description, information indicating whether the AUN3 device supports the first key hierarchy may be carried within the EAP-response / 5G-NAS message or outside the EAP-response / 5G-NAS message. When information indicating whether the AUN3 device supports the first key hierarchy may be carried in the EAP-response / 5G-NAS message, the AN parameter portion of the EAP-response / 5G-NAS message may carry information indicating whether the AUN3 device supports the first key hierarchy. Specifically, an IE is added to the AN parameter to carry information indicating whether the AUN3 device supports the first key hierarchy, or whether the UE ID portion of the AN parameter has an indicative function. When information indicating whether the AUN3 device supports the first key hierarchy can be carried outside of the EAP-response / 5G-NAS message, a new IE is sent to the 5G-RG along with the EAP-response / 5G-NAS message.

[0314] From the three implementations described above, it can be seen that the AUN3 device of this embodiment may access 5G-RG by using different procedures.

[0315] For example, in this embodiment, before accessing the 5G-RG, the AUN3 device may determine a specific procedure to be used between the AUN3 device and the 5G-RG based on a decision criterion or a predefined access method. The predefined access method may be understood as a pre-agreed access procedure. The decision criterion includes, but is not limited to, determining whether the AUN3 device and the first gateway belong to the same user (or owner), or determining whether the user is making a choice.

[0316] If the decision criterion is that the AUN3 device and the first gateway do not belong to the same user, or if the user confirms that the AUN3 device and the first gateway do not belong to the same user, the AUN3 device decides to access the first gateway by using the procedure corresponding to Implementation A.

[0317] If the decision condition is that the AUN3 device and the first gateway belong to the same user, or if the user confirms that the AUN3 device and the first gateway belong to the same user, the AUN3 device decides to access the first gateway by using the procedure corresponding to Implementation B.

[0318] If a predefined access method is to prioritize access by using the procedure corresponding to implementation A, the AUN3 device will first decide to attempt to access the first gateway by using the procedure corresponding to an untrusted non-3GPP access technique.

[0319] If a predefined access method is to prioritize access by using the procedure corresponding to implementation B, the AUN3 device will first decide to attempt to access the first gateway by using the procedure corresponding to a trusted non-3GPP access technique.

[0320] If a predefined access method is to prioritize access by using the procedure corresponding to implementation C, the AUN3 device will first attempt to access the first gateway by using the procedure specified in 802.1x and related protocols.

[0321] It should be noted that the criteria for judgment are merely examples and do not constitute any limitation on the scope of protection of this application. AUN3 may alternatively determine how 5G-RG is accessed by other means, for example, by determining the communication quality or communication distance of 5G-RG. Examples will not be explained one by one here.

[0322] Alternatively, the AUN3 device may first search for a specific type of 5G-RG and, based on the 5G-RG, determine which implementation to use. Specifically, the AUN3 selects a 5G-RG based on its implementation, configuration, the capabilities of the AUN3, or the capabilities of the 5G-RG, and based on the selected 5G-RG, decides to use implementation A, implementation B, or implementation C. For example, if the UE finds a nearby 5G-RG that can use a trusted non-3GPP access procedure, after the UE decides to select this 5G-RG, the AUN3 device will perform access with implementation A. As another example, if the UE finds a 5G-RG that can use an untrusted non-3GPP access procedure, after the UE decides to select this 5G-RG, the AUN3 device will perform access with implementation B. As yet another example, if the UE finds a 5G-RG that can use an 802.1x access procedure, after the UE decides to select this 5G-RG, the AUN3 device will perform access with implementation C.

[0323] Specifically, in this embodiment, the information indicating whether an AUN3 device supports the first key hierarchy includes several possible implementations, as follows:

[0324] In possible implementations, information indicating whether an AUN3 device supports the first key hierarchy will indicate that the AUN3 device supports the first key hierarchy.

[0325] In this implementation, when an AUN3 device supports the first key hierarchy, the AUN3 device sends information to the 5G-RG indicating whether or not it supports the first key hierarchy. When an AUN3 device does not support the first key hierarchy, the AUN3 device does not need to send information to the 5G-RG indicating whether or not it supports the first key hierarchy.

[0326] In another possible implementation, the information indicating whether the AUN3 device supports the first key hierarchy would instead indicate that the AUN3 device does not support the first key hierarchy. In this implementation, when the AUN3 device does not support the first key hierarchy, the AUN3 device sends information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG. When the AUN3 device does support the first key hierarchy, the AUN3 device does not need to send information indicating whether the AUN3 device supports the first key hierarchy to the 5G-RG.

[0327] In yet another possible implementation, if the AUN3 device supports the first key hierarchy, the AUN3 device sets the first value to information indicating whether the AUN3 device supports the first key hierarchy. If the AUN3 device does not support the first key hierarchy, the AUN3 device sets the second value to information indicating whether the AUN3 device supports the first key hierarchy.

[0328] For example, in this embodiment of the present application, the first response message indicating whether the AUN3 device supports the first key hierarchy includes two possible methods:

[0329] Method #1: The first response message includes identification information for the AUN3 device, which indicates whether the AUN3 device supports the first key hierarchy.

[0330] In possible implementations, when the identifier is a first identifier, it indicates that the terminal device does not support the first key hierarchy, or when the identifier is a second identifier, it indicates that the terminal device supports the first key hierarchy. The first identifier is different from the second identifier.

[0331] For example, the identification information is either SUPI or SUCI. When the identification information of an AUN3 device carried in the EAP response message (i.e., the first response message) is SUPI, this indicates that the AUN3 device does not support the first key hierarchy. When the identification information of an AUN3 device carried in the EAP response message is SUCI, this indicates that the AUN3 device supports the first key hierarchy.

[0332] In response to this, 5G-RG can distinguish whether a SUPI or SUCI is received based on a specific format of the AUN3 device's identification information. For example, suppose the SUPI of an AUN3 device is 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org. If the AUN3 device does not support the first key hierarchy, the identification information of the AUN3 device being transmitted is a SUPI, i.e., 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org is transmitted. If the AUN3 device supports the first key hierarchy, the AUN3 device identifier sent will be a SUCI, i.e., type3.rid0.schid0.userid00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org, or an anonymous SUCI will be sent, i.e., anonymous@5gc.mnc012.mcc345.3gppnetwork.org.

[0333] In another possible implementation, when the identifier is a first identifier of type 1, the identifier indicates that the terminal device does not support the first key hierarchy.

[0334] Alternatively, when the identification information is a first identifier of type 2, the identification information indicates that the terminal device supports the first key hierarchy.

[0335] For example, identification information is in the form of SUCIs in different formats. Different SUPI formats on an AUN3 device correspond to different SUCI formats. For example, the type of SUPI that supports the first key hierarchy is the SUPI in the International Mobile Subscriber Identification Number (IMSI) format, while the type of SUPI that does not support the first key hierarchy is the SUPI in the NAI format. The format of the IMSI format SUCI is different from the format of the NAI format SUCI. Therefore, when 5G-RG receives a SUCI in the NAI format, it determines that the AUN3 device does not support the first key hierarchy. When 5G-RG receives a SUCI in the IMSI format, it determines that the AUN3 device supports the first key hierarchy. As another example, SUCIs that do not support the first key hierarchy are calculated using a null algorithm, while SUCIs that support the first key hierarchy are calculated using a non-null algorithm.

[0336] In yet another possible implementation, the identification information includes a field indicating whether the terminal device supports the first key hierarchy.

[0337] For example, the identification information may be a field carried in the SUPI or SUCI of the AUN3 device, or in the username or area portion of the SUPI or SUCI. The identification information may also be at least one bit of information in the username or area portion. For example, the username or area portion carries information such as AUN3 or 5GK. The username or area portion of the SUPI or SUCI carries identification information to indicate that the first key hierarchy is supported, and does not carry identification information to indicate that the first key hierarchy is not supported; or the username or area portion of the SUPI or SUCI does not carry identification information to indicate that the first key hierarchy is supported, and carries identification information to indicate that the first key hierarchy is not supported; or the username or area portion of the SUPI or SUCI carries a first value to indicate that the first key hierarchy is supported, and carries a second value to indicate that the first key hierarchy is not supported.

[0338] In another example, suppose the SUPI of an AUN3 device is 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org. When the AUN3 device supports the first key hierarchy, the SUPI carrying the field may be 00-00-5E-00-53-00.5G key hierarchy@5gc.mnc012.mcc345.3gppnetwork.org. In this case, the first response message is EAP-Identification / Response(00-00-5E-00-53-00.5G key hierarchy@5gc.mnc012.mcc345.3gppnetwork.org).

[0339] Alternatively, the SUPI carrying the field may be 00-00-5E-00-53-00@5G key.5gc.mnc012.mcc345.3gppnetwork.org. In this case, the first response message is EAP-Identification / Response(00-00-5E-00-53-00@5G key hierarchy.5gc.mnc012.mcc345.3gppnetwork.org). If the AUN3 device does not support the first key hierarchy, the SUPI may be 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org. In this case, the first response message is EAP-Identification / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org).

[0340] For example, the SUPI for an AUN3 device is the network-specific identifier user17@example.com, and the corresponding SUCI is type1.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key> .cip<encryption of user17>.mac<MAC tag value> Assume the domain is @example.com. When the AUN3 device supports the first key hierarchy, the SUCI carrying the field is type1.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key> .cip<encryption of user17>.mac<MAC tag value> @AUN3.example.com,type1.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key> .cip<encryption of user17>.mac<MAC tag value> @AUN3-5GK.example.com,type1.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key> .cip<encryption of user17>.mac<MAC tag value> @AUN3-N5GK.example.com. In this case, if the field is AUN3 or AUN3-5GK, it indicates that the 5G key hierarchy is supported; or if the field is not carried or is AUN3-N5GK, it indicates that the 5G key hierarchy is not supported.

[0341] Method #2: The first response message further includes first instruction information, which indicates whether the AUN3 device supports the first key hierarchy. Possible forms of the first instruction information include, but are not limited to, string information, bit information, or non-access layer protocol data unit NAS-PDU.

[0342] For example, the first instruction information may be string instruction information (e.g., "5G Key Hierarchy", "5G NAS", "5GK", "N5GK", "AUN3-5GK", "AUN3-N5GK"). When string instruction information is always carried, the 5G-RG (including subsequent AMF and AUSF) may determine, based on the string information, that the AUN3 device supports the first key hierarchy. When string instruction information is not always carried, the 5G-RG (including subsequent AMF and AUSF) may determine, based on the first instruction information, that the AUN3 device supports the first key hierarchy if string instruction information exists; or, if string instruction information does not exist, that the AUN3 device does not support the first key hierarchy. This string may be placed in SUCI or SUPI as part of SCUI or SUPI, or it may be transmitted as a separate IE. For an example of transmission as part of SUCI or SUPI, please refer to the example above. Further details will not be explained again here.

[0343] For example, when sending is performed as an independent IE, suppose the SUPI of the AUN3 device is 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org. When the AUN3 device supports the first key hierarchy, the first response message is either EAP-Identifier / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org, "5G Key Hierarchy") or the first response message is "5G Key Hierarchy" and EAP-Identifier / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org). When an AUN3 device supports the first key hierarchy, the first response message is either EAP-Identifier / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org, "Non-5G Key Hierarchy") (in this case, indicating that the 5G key hierarchy is not supported) or the first response message is EAP-Identifier / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org, "NULL") (in this case, indicating that the first key hierarchy is not supported and that the default key hierarchy may be used based on preconfiguration). Alternatively, the first response message is EAP-Identifier / Response(00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org) (in this case, it indicates that the first key hierarchy is not supported and the default key hierarchy may be used based on preconfiguration).

[0344] In another example, the first indicator information may be bit information, and may include one or more bits, for example, 0, 00, or 01. When a bit is set to a specific value, it indicates that the first key hierarchy is supported; when the value is set to another specific value, it indicates that the second key hierarchy is supported or that the first key hierarchy is not supported; or when bit information is carried, it indicates that the first key hierarchy is supported, and when bit information is not carried, it indicates that the first key hierarchy is not supported; or when bit information is carried, it indicates that the first key hierarchy is not supported, and when bit information is not carried, it indicates that the first key hierarchy is supported. When there are multiple bits, different bits may indicate different key hierarchies. For example, 00 indicates that the first key hierarchy is supported, and 01 indicates that a key hierarchy other than the first key hierarchy is supported.

[0345] As another example, the first instruction information may be a NAS-PDU. If the first response message carries a NAS-PDU, it indicates that the AUN3 device supports the first key hierarchy. Alternatively, if the first instruction information is a NAS-PDU, it may be understood as indicating that the AUN3 device supports the NAS protocol, and indirectly as indicating that the first key hierarchy is supported. The first instruction information may alternatively indicate that the AUN3 device supports the first key hierarchy by indicating that the AUN3 device supports the NAS protocol (e.g., the 5G NAS protocol). The AUN3 device supporting the 5G NAS protocol indicates that the AUN3 device can generate and process 5G NAS messages (e.g., registration request messages, NAS SMC messages, or PDU session establishment request messages).

[0346] The function of the identification or first instruction information carried in the first response message is to indicate whether the AUN3 device supports the first key hierarchy. Therefore, identification information may be understood as a type of first instruction information. For the sake of explanation, the information carried in the first response message indicating whether the AUN3 device supports the first key hierarchy will be collectively referred to as first instruction information below. However, it should be noted below that the format of first instruction information includes identification information.

[0347] Optionally, the first response message may include second directive information, which indicates whether the AUN3 device supports the Non-Accessible Tier NAS protocol. Similar to the first directive information, possible forms of the second directive information include a specific format for the AUN3 device's identification information, a special format SUPI, a special format SUCI, string information, bit information, or NAS-PDU. Further details are not provided here. Note that either the first or second directive information may be transmitted alone.

[0348] The second instruction information is sometimes referred to as 5G NAS instruction information #1. 5G NAS instruction information #1 indicates that the NAS registration request message sent to the AMF by the 5G-RG is generated by the AUN3 device. Alternatively, 5G NAS instruction information #1 may be used to inform the AMF that the AUN3 device supports the 5G NAS protocol, and that the NAS SMC procedure may be performed between the AMF and the AUN3 device.

[0349] In addition, when an AUN3 device transmits the first instruction information to the 5G-RG but does not transmit the second instruction information, the first instruction information may also indicate that the AUN3 device supports the 5G NAS protocol, and it should be noted that supporting the 5G NAS protocol may be understood as supporting the first key hierarchy.

[0350] In this embodiment, after receiving the first response message, the 5G-RG may decide to request the AUN3 device that sent the first response message to initiate the registration procedure. In this case, the 5G-RG initiates the registration procedure on behalf of the AUN3 device. The procedure of the method shown in Figure 9 further includes the following steps.

[0351] S930:5G-RG sends a NAS registration request message to the access and mobility management network element; in other words, the access and mobility management network element receives the NAS registration request message from 5G-RG.

[0352] In this embodiment, the access and mobility management network element may be an access and mobility management function network element. The network element is responsible for access control and mobility management for AUN3 devices to access the operator network and may be an AMF or another network element capable of implementing AMF functions. For convenience of explanation, the following example will use an AMF as the access and mobility management network element.

[0353] For example, when a 5G-RG sends a message to an AMF via a W-AGF, the 5G-RG sending a NAS registration request message to the AMF includes the 5G-RG sending a second request message to the W-AGF, where the second request message carries the NAS registration request message. After receiving the second request message, the W-AGF forwards the NAS registration request message contained within the second request message to the AMF.

[0354] In possible implementations, when the 5G-RG sends the NAS registration request message to the W-AGF, it also sends to the W-AGF whether the AUN3 device supports the first key hierarchy. See the relevant explanation for step S920. Specifically, the EAP authentication response message in the first response message may be replaced with the NAS registration request message, and the first response message may be replaced with the second response message.

[0355] In possible implementations, if the AUN3 device supports the 5G NAS protocol, the registration request message carried in the first response message is a NAS registration request message.

[0356] In this implementation, the 5G-RG forwards the NAS registration request message, which was carried in the first response message, to the AMF.

[0357] In another possible implementation, if the AUN3 device does not support the 5G NAS protocol, the first response message does not carry the NAS registration request message.

[0358] In this implementation, the 5G-RG generates a NAS registration request message on behalf of the AUN3 device and sends the generated NAS registration request message to the AMF.

[0359] Specifically, the NAS registration request message includes third-indication information, which indicates that the type of device initiating the registration request is an AUN3 device. The third-indication information may be an AUN3 device identifier, bit indication information, or string indication information.

[0360] Optionally, the NAS registration request message may further include a fourth directive. This fourth directive indicates whether the AUN3 device supports the first key hierarchy.

[0361] In possible implementations, the NAS registration request message always carries fourth instruction information indicating whether the AUN3 device supports the first key hierarchy or not.

[0362] In another possible implementation, when an AUN3 device supports the first key hierarchy, the NAS registration request message carries fourth instruction information. In this case, the NAS registration request message carrying fourth instruction information indicates that the AUN3 device supports the first key hierarchy, while the NAS registration request message not carrying fourth instruction information indicates that the AUN3 device does not support the first key hierarchy.

[0363] In yet another possible implementation, if the AUN3 device does not support the first key hierarchy, the NAS registration request message carries fourth instruction information. In this case, the NAS registration request message carrying fourth instruction information indicates that the AUN3 device does not support the first key hierarchy, and the NAS registration request message not carrying fourth instruction information indicates that the AUN3 device supports the first key hierarchy.

[0364] From the description of the first instruction information in step S920, it can be seen that the first instruction information indicates whether the AUN3 device supports the first key hierarchy. Therefore, after receiving the first instruction information, the 5G-RG may determine, based on the first instruction information, whether the AUN3 device supports the first key hierarchy, and thus determine that the NAS registration request message contains the value or type of the fourth instruction information, and can implement a function to indicate to the AMF and / or AUSF whether the AUN3 device supports the first key hierarchy.

[0365] For example, when the first key hierarchy is a 5G key hierarchy, if the first instruction indicates that the AUN3 device supports the 5G key hierarchy, and the 5G-RG determines that the AUN3 device supports the 5G key hierarchy, the NAS registration request message does not carry the fourth instruction; or, if the first instruction indicates that the AUN3 device does not support the 5G key hierarchy, and the 5G-RG determines that the AUN3 device does not support the 5G key hierarchy, the NAS registration request message carries the fourth instruction. In this case, the fourth instruction indicates that the AUN3 device does not support the 5G key hierarchy. Optionally, the first instruction is identical to the fourth instruction. For example, the 5G-RG directly includes the received first instruction in the NAS registration request message and forwards the NAS registration request message to the AMF.

[0366] Optionally, the first and fourth instruction information may have the same meaning but be in different formats. In this case, the 5G-RG processes the received first instruction information to obtain the fourth instruction information. For example, the first instruction information may be a specific format for the identification information of the AUN3 device, and the fourth instruction information may be bit instruction information.

[0367] Regardless of whether the format of the first directive is the same as that of the fourth directive, please understand that the meanings represented by the first and fourth directives are the same. Therefore, the fourth directive will not be explained again. For an explanation of the fourth directive, please refer to the explanation of the first directive.

[0368] Optionally, the NAS registration request message may further include a fifth directive, which indicates whether the AUN3 device supports the NAS protocol. For example, 5G-RG receives a second directive, and based on that, learns whether the AUN3 device supports the NAS protocol, and as a result, the fifth directive may be carried in the NAS registration request message. The fifth directive and the second directive have the same meaning and may be in the same or different format. In another example, 5G-RG, based on the received registration request message, determines that the registration request message is a NAS registration request message, and as a result, determines that the AUN3 device supports the NAS protocol, and may include the fifth directive in the NAS registration request message.

[0369] When a NAS registration request message carries fifth instruction information indicating that the AUN3 device supports the 5G NAS protocol, fourth instruction information does not need to be carried. In this case, AMF may determine whether or not the AUN3 device supports the first key hierarchy based on the fact that the AUN3 device supports the 5G NAS protocol.

[0370] For example, the third and fourth instruction information may be represented as the same instruction information. For example, when the first instruction information is SUPI or SUCI, and the first instruction information is carried in the username or domain portion, the first instruction information may function as both the third and fourth instruction information. Specifically, when the first instruction information is "AUN3-5GK" and "AUN3-N5GK", the first instruction information indicates an AUN3 device that supports the 5G key hierarchy, or an AUN3 device that does not support the 5G key hierarchy. In another example, when 5G-RG determines that an AUN3 device supports the 5G key hierarchy, 5G-RG uses the instruction information "AUN3-5GK" to indicate both the AUN3 device and devices that support the 5G key hierarchy. When 5G-RG determines that an AUN3 device does not support the 5G key hierarchy, 5G-RG uses the instruction information "AUN3-N5GK" to indicate both the AUN3 device and devices that do not support the 5G key hierarchy. Therefore, one instruction information may be used as it includes the functions of both the third and fourth instruction information. The instruction information may be added by the 5G-RG or from the AUN3 device. If the instruction information from the AUN3 device already has the functions of the third and fourth instruction information, the AMF does not need to add any further instruction information, or it may add the third and fourth instruction information redundantly as required.

[0371] Specifically, in this embodiment, after receiving a NAS registration request message, the AMF may determine whether the AUN3 device supports the first key hierarchy based on the information carried in the NAS registration request message. The procedure of the method shown in Figure 9 further includes the following steps.

[0372] S940:AMF determines whether the AUN3 device supports the first key hierarchy.

[0373] Based on the third instruction in the NAS registration request message, AMF decides to register the AUN3 device, and based on the fourth or fifth instruction in the NAS registration request message, it decides whether the AUN3 device supports the first key hierarchy.

[0374] In possible implementations, when a NAS registration request message carries fifth instruction information, the AMF determines, based on the fifth instruction information, that the AUN3 device supports the first key hierarchy.

[0375] In this implementation, the AMF may determine, based on the fifth instruction information, that the AUN3 device supports the 5G NAS protocol and may exchange NAS messages with the AUN3 device. It can also be understood that the AMF may determine, based on the fifth instruction information, that the NAS registration request message was sent by the AUN3 device and may consider the AUN3 device to be a common terminal device (i.e., a UE that can exchange NAS messages). For example, the AMF generates a 5G NAS key and performs a NAS SMC procedure with the AUN3 device based on the 5G NAS key.

[0376] In another possible implementation, the AMF determines whether the AUN3 device supports the first key hierarchy based on the fourth directive information. For example, if the fourth directive information indicates that the 5G key hierarchy is not supported, and the NAS registration request message does not carry the fourth directive information, the AMF determines that the AUN3 device supports the 5G key hierarchy. Alternatively, the AMF may be understood not to determine whether the AUN3 device supports the 5G key hierarchy and to generate a key according to the existing key generation method, or if the NAS registration request message carries the fourth directive information, the AMF determines that the AUN3 device does not support the 5G key hierarchy and generates a key based on the non-5G key hierarchy. In another example, if the fourth directive information indicates whether the 5G key hierarchy is supported, the AMF determines whether the AUN3 device supports the 5G key hierarchy based on a specific value of the fourth directive information and then determines the subsequent key derivation method based on that determination.

[0377] In yet another implementation, the AMF determines, based on the fourth and fifth directives, whether the AUN3 device supports the first key hierarchy and key usage method. For example, if the fourth directive indicates that the AUN3 device supports the first key hierarchy, and the fifth directive indicates that the NAS protocol is not supported, the AMF determines, based on the fourth directive, that the AUN3 device supports the first key hierarchy, but based on the fifth directive, that the 5G NAS protocol is not supported, and generates a 5G NAS key. The 5G NAS key is used to derive keys between the 5G-RG and the AUN3 device, and the AMF may either not exchange NAS messages with the AUN3 device, or the AMF may perform NAS exchange with the 5G-RG by using the 5G NAS key, or the AMF may determine that the target of the NAS message exchange is the 5G-RG and therefore decide on a different NAS message processing method. Different NAS message processing methods include, but are not limited to, the common 5G UE (sometimes called a Type 1 terminal device) and terminal devices that can access 5GC but have only some functionality (sometimes called a Type 2 terminal device). For example, in the case of a Type 1 terminal device, the 5G UE and AMF perform the normal NAS SMC procedure and activate NAS security after the NAS SMC procedure. In the case of a Type 2 terminal device, NAS security is not activated after the device or the device sending the registration request on behalf of the device interacts with AMF by using the NAS SMC procedure.

[0378] In possible implementations, in this case, the AMF can only determine that the device is an AUN3 device, and does not determine whether the AUN3 device supports the first key hierarchy. That is, the determination of whether the AUN3 device supports the first key hierarchy does not need to be performed in this step, but is performed in step 993.

[0379] Furthermore, the AMF sends an authentication request message to the authentication network element, which then performs authentication on the AUN3 device. The procedure for the method shown in Figure 9 further includes the following steps:

[0380] S950: The AMF sends an authentication request message to the authentication network element; in other words, the authentication network element receives an authentication request message from the AMF.

[0381] In this embodiment, the authentication network element is responsible for authentication between the AUN3 device and the operator network and may be AUSF, or another network element capable of implementing AUSF functionality. For convenience of explanation, the following example will use AUSF as the authentication network element.

[0382] The authentication request message is used to request AUSF to perform authentication on the AUN3 device, and the authentication request message includes the identifier and SN name of the AUN3 device. The identifier of the AUN3 device may be the SUCI or SUPI of the AUN3 device. The value of the SN name may include, but is not limited to, a preset fixed value (e.g., 5G:AUN3, where the fixed value may be a value predefined or preconfigured by the protocol), the PLMN ID of the network to which the AMF belongs, or the home PLMN ID of the SUCI of the AUN3 device (e.g., the home PLMN ID of the 5G:AUN3 device).

[0383] Optionally, the authentication request message may further include a sixth instruction, which indicates that the device to be authenticated is an AUN3 device. Note that the sixth instruction and the third instruction carried in the NAS registration request message in step S930 have the same meaning and indicate an AUN3 device, but their specific representations may be the same or different. For example, if the sixth instruction is that the AMF directly forwards the third instruction to the AUSF, then the representations of the sixth instruction and the first instruction are the same. In another example, if the sixth instruction is that the AMF performs processing (e.g., repadding) based on the received third instruction and then sends the processed third instruction to the AUSF, then the representations of the sixth instruction and the third instruction may be different; in other words, even if the representations are the same, the AMF does not directly forward the received third instruction to the AUSF.

[0384] Optionally, the authentication request message may further include 11th instruction information, which indicates whether the AUN3 device supports the first key hierarchy. For example, if the 11th instruction information is that the AMF directly forwards the 4th instruction information to the AUSF, then the representations of the 11th and 4th instruction information are the same. In another example, if the 11th instruction information is that the AMF performs processing (e.g., repadding) based on the received 4th instruction information and then sends the processed 4th instruction information to the AUSF, then the representations of the 11th and 4th instruction information may be different; in other words, even if the representations are the same, the AMF does not directly forward the received 4th instruction information to the AUSF. In yet another example, the 11th instruction information may be directly the 1st instruction information or directly the 4th instruction information.

[0385] In possible implementations, the authentication request message always carries 11th instruction information to indicate whether the AUN3 device supports the first key hierarchy or not.

[0386] In another possible implementation, when an AUN3 device supports the first key hierarchy, the authentication request message carries eleventh instruction information. In this case, the presence of the eleventh instruction information in the authentication request message indicates that the AUN3 device supports the first key hierarchy, while the absence of the eleventh instruction information in the authentication request message indicates that the AUN3 device does not support the first key hierarchy.

[0387] In yet another possible implementation, if the AUN3 device does not support the first key hierarchy, the authentication request message carries eleventh instruction information. In this case, the presence of the eleventh instruction information in the authentication request message indicates that the AUN3 device does not support the first key hierarchy, while the absence of the eleventh instruction information in the authentication request message indicates that the AUN3 device supports the first key hierarchy.

[0388] In possible implementations, AUSF does not determine in this step whether the AUN3 device supports the first key hierarchy. That is, AUSF does not need to determine in this step whether the AUN3 device supports the first key hierarchy, but does so in step 991. For example, a message requesting authentication is called Nausf_UEAuthentication_AuthenticateRequest.

[0389] In this embodiment, after receiving an authentication request message, AUSF sends a request to retrieve the authentication credentials required for authentication to the data management network element. The procedure of the method shown in Figure 9 further includes the following steps:

[0390] S960: AUSF sends a retrieval request message to the data management network element; in other words, the data management network element receives a retrieval request message from AUSF.

[0391] In this embodiment, the data management network element is responsible for storing subscriber data within the operator network and may be a UDM, or another network element capable of implementing UDM functionality. For ease of explanation, the following example will use a data management network element that is a UDM.

[0392] Specifically, the retrieval request message is used to request the retrieval of authentication parameters necessary for authentication, and is used in subsequent authentication procedures. The retrieval request message includes the SUCI or SUPI of the AUN3 device and its SN name.

[0393] Optionally, the acquisition request message may further include instruction information for the AUN3 device, such as sixth instruction information, or instruction information with a function.

[0394] Optionally, the acquisition request message may further include instruction information of the first key hierarchy, such as 11th instruction information, or instruction information with a function.

[0395] For example, the retrieval request message is called Nudm_UEAuthentication_GetRequest.

[0396] If the SN name is not transmitted in step S950, the AUN3 device is determined based on the AUN3 device instruction information, and then the AUSF generates the SN name according to the method in step S950 and transmits the SN name to the UDM in step S960.

[0397] S970:UDM generates an authentication vector.

[0398] For example, when a UDM receives the SUCI of an AUN3 device, the UDM obtains the SUPI of the AUN3 device based on the SUCI. Furthermore, the UDM determines the authentication method based on the SUPI or AUN3 device information of the AUN3 device.

[0399] Specifically, the UDM may determine subscriber data based on the SUPI of the AUN3 device and further determine the authentication method based on the subscriber data.

[0400] Alternatively, the UDM determines the AUN3 device based on the sixth instruction information of the AUN3, and then determines the authentication method.

[0401] Furthermore, the UDM generates a corresponding authentication vector (AV) according to the authentication method.

[0402] For example, UDM decides to use the EAP-AKA' authentication method based on AUN3 device information and generates an EAP-AKA' authentication vector by using the received SN name.

[0403] If the SUCI type is anonymous SUCI, the authentication method is determined based on the region portion within the SUCI, and an authentication vector corresponding to the authentication method is further generated.

[0404] S980: The UDM sends an acquisition response message to the AUSF; in other words, the AUSF receives an acquisition response message from the UDM.

[0405] The retrieved response message includes an authentication vector.

[0406] For example, the Get Response message is called the Nudm_UEAuthentication_GetResponse message. Optionally, when the UDM receives a SUCI, the Get Response message carries the SUPI for the AUN3 device.

[0407] S990: The AUN3 device and AUSF perform bidirectional authentication.

[0408] The procedure for bidirectional authentication between the AUN3 device and AUSF is not limited to this embodiment. For details, please refer to the description of the procedure for bidirectional authentication between the AUN3 device and AUSF in the current related technologies.

[0409] Note that during the authentication process, the AUN3 device further determines the SN name. Specifically, the AUN3 device generates the same SN name by using the method of step S950. In this embodiment, the specific time at which the AUN3 device generates the SN name is not limited. For example, the AUN3 device may generate the SN name after receiving the authentication vector, or it may generate the SN name before receiving the authentication vector. The AUN3 device uses the SN name and the parameters in the authentication vector to verify the reliability of the network side.

[0410] S991:AUSF determines the key generation method and generates the key.

[0411] Specifically, if AUSF makes a decision after receiving a message in step S950, AUSF does not need to make another decision. If AUSF does not make a decision after receiving a message in step S950, AUSF determines whether the AUN3 device supports the first key hierarchy and determines the key generation method based on that determination. For example, AUSF may determine the key generation method based on the received instruction information (e.g., the 11th instruction information or the 6th instruction information). The 11th instruction information may be directly the 1st instruction information or directly the 4th instruction information, and the 6th instruction information may be directly the 3rd instruction information. For the sake of explanation, the following example will use AUSF determining the key generation method based on the 11th instruction information.

[0412] In possible implementations, when an authentication request message indicates that the AUN3 device does not support the 5G key hierarchy by using 11th directive information, if the authentication request message does not carry 11th directive information, AUSF will determine that the AUN3 device supports the 5G key hierarchy. Alternatively, AUSF may not determine whether the AUN3 device supports the 5G key hierarchy and generate a key according to an existing key generation method, in which case a third key (denoted as Kseaf) may be generated; or if the authentication request message carries 11th directive information, AUSF may determine that the AUN3 device does not support the 5G key hierarchy and generate a key based on a non-5G key hierarchy, in which case a fourth key (denoted as MSK) may be generated.

[0413] In possible implementations, when an authentication request message indicates whether an AUN3 device supports the 5G key hierarchy by using 11th directive information, it can be understood that if the authentication request message carries 11th directive information indicating that the AUN3 device supports the 5G key hierarchy, AUSF will generate a third key (denoted as Kseaf); if the 11th directive information indicates that the 5G key hierarchy is not supported, AUSF will determine that the AUN3 device does not support the 5G key hierarchy and generate a key based on a non-5G key hierarchy, in which case it will generate a fourth key (denoted as MSK).

[0414] S992: AUSF sends an authentication response message to AMF; in other words, AMF receives an authentication response message from AUSF.

[0415] For example, the authentication response message is called the Nausf_UEAuthentication_AuthenticateResponse message. The Nausf_UEAuthentication_AuthenticateResponse message carries EAP success, the SUPI for the AUN3 device, the third key, or the fourth key.

[0416] S993:AMF determines the second key.

[0417] In possible implementations, if the AMF performs the decision in step S940, the AMF determines how to generate the second key based on the decision result in S940, and then generates the second key. If the AMF does not perform the decision in step S940, based on the decision method in step S940, the AMF first determines whether the AUN3 device supports the first key hierarchy or whether the AUN3 device does not support the first key hierarchy, and then determines how to obtain the second key. If it is necessary to generate a second key, the AMF further generates the second key.

[0418] This implementation uses an example where the first key hierarchy is a 5G key hierarchy for illustrative purposes. When an AUN3 device supports a 5G key hierarchy, the AMF generates the second key by using the third key.

[0419] In possible implementations, AMF directly generates the second key by using the third key. For example, if the second key is K 5G-RG In this case, the generation method may be 2nd key = KDF(3rd key, 1st parameter, 2nd parameter). At least one of the 1st parameter and the 2nd parameter will be used. The 1st parameter and the 2nd parameter may be values ​​in the form of strings, numbers, etc. For example, the 1st parameter may be all values ​​of 0, 2 32 The value is -1, or a fixed value such as SQN in the authentication vector. The second parameter is, for example, the string "AUN3", or, for example, the distinguishing identifier 0x02. This embodiment does not restrict the use of more input parameters in the DKF function.

[0420] In an alternative implementation, AMF may first generate the sixth key by using the third key, and then generate the second key by using the sixth key. For example, if the second key is Kwagf, the generation method may be second key = KDF(sixth key, first parameter, second parameter). The sixth key is generated based on the third key. For example, the sixth key is Kamf. For specific generation methods, please refer to the prior art. At least one of the first and second parameters is used. The first and second parameters may be values ​​in the form of strings or numbers, etc. For example, the first parameter may be all zeros, 2 32 This is a value of -1, or a fixed value such as SQN in the authentication vector. In another example, the first parameter is the string "AUN3". The second parameter is, for example, the string "AUN3", and for example, the distinguishing identifier 0x02. This embodiment does not limit the use of more input parameters in the DKF function.

[0421] In addition, AMF optionally generates NAS encryption keys and NAS integrity protection keys by using a sixth key.

[0422] When the AUN3 device does not support the 5G key hierarchy, the AMF, after receiving the fourth key, no longer generates a new key and determines the fourth key to be the second key. Alternatively, the AMF generates the NAS encryption key and NAS integrity protection key by using the fourth key.

[0423] In yet another implementation, if AMF determines that the AUN3 device supports the first key hierarchy by determining that the AUN3 device supports 5G NAS, AMF may further generate NAS encryption keys and NAS integrity keys by using a sixth key, and optionally initiate a NAS SMC procedure with the AUN3 device based on the NAS keys. The procedure of the method shown in Figure 9 may further include the following steps.

[0424] S994: ​​Perform the NAS SMC procedure between AMF and the AUN3 device.

[0425] If AMF determines that the AUN3 device supports the first key hierarchy, AMF sends a NAS SMC message to 5G-RG. A null integrity protection algorithm is used for the NAS SMC message. After receiving the NAS SMC message, 5G-RG returns a NAS SMP message to AMF. A null encryption algorithm and a null integrity protection algorithm are used for the NAS SMP message.

[0426] If AMF determines that the AUN3 device supports the NAS protocol, AMF sends a NAS SMC message to the AUN3 device. The NAS SMC message is protected using a non-null integrity protection algorithm and a NAS integrity protection key. After receiving the NAS SMC message, the AUN3 device verifies the integrity of the NAS SMC message using the same NAS key and non-null integrity protection algorithm. After successful verification, the AUN3 device returns a NAS SMP message to AMF. Security protection is applied to the NAS SMP message using a non-null encryption algorithm, a non-null integrity protection algorithm, a NAS integrity protection key, and a NAS encryption key.

[0427] If AMF determines that the AUN3 device does not support the first key hierarchy, AMF sends a NAS SMC message to 5G-RG. A null integrity protection algorithm is used for the NAS SMC message. After receiving the NAS SMC message, 5G-RG returns a NAS SMP message to AMF. A null encryption algorithm and a null integrity protection algorithm are used for the NAS SMP message.

[0428] S995: The AMF sends the fifth key and a message indicating that the authentication was successful to the 5G-RG; in other words, the 5G-RG receives the fifth key from the AMF.

[0429] For example, AMF sends a NAS security mode command to 5G-RG. NAS security is activated. The NAS security mode command includes EAP-success, which indicates that authentication performed by the core network was successful, and that identity authentication was successful.

[0430] In possible implementations, the AMF may use the second key as the fifth key and send the fifth key (e.g., K5G-RG) to 5G-RG using a NAS message or an N2 message. For example, the AMF sends the fifth key using a NAS Downlink Transport (NAS DL Transport) message or an N2 Initial Context Setup Request message.

[0431] In another possible implementation, the AMF sends the second key to the W-AGF, which then determines how to obtain the fifth key based on whether the AUN3 device supports the first key hierarchy. Specifically, for the method the W-AGF uses to determine whether the AUN3 device supports the first key hierarchy, see the AMF's determination in step S940, or the relevant description of the AMF sending 12th instruction information to the W-AGF and the W-AGF determining whether the AUN3 device supports the first key hierarchy based on the 12th instruction information. If the W-AGF determines that the AUN3 device does not support the first key hierarchy, it sends the second key directly to the 5G-RG as the fifth key; or, if it determines that the first key hierarchy is supported, the W-AGF generates the fifth key based on the second key and sends the fifth key to the 5G-RG using the second response message.

[0432] The S996:5G-RG establishes a secure connection to AUN3 devices.

[0433] Specifically, the 5G-RG establishes a secure connection to the AUN3 device based on the fifth key. For example, the 5G-RG and the AUN3 device establish a secure connection by performing a four-way handshake.

[0434] Before establishing a secure connection, the AUN3 device generates key #1 based on the fifth key, which is used to generate the first key required for security protection. The first key is used to perform security protection in the secure connection established between the 5G-RG and the AUN3. For example, the first key is used to perform encryption and integrity protection in the connection between the AUN3 device and the 5G-RG. For example, the sender performs encryption and integrity protection on the message based on the first key, and the receiver performs decryption and integrity protection verification on the message based on the first key. If the AUN3 device supports the first key hierarchy (using the example where the first key hierarchy is the 5G key hierarchy for illustration purposes), the AUN3 device generates key #1 by using the fifth key. Specifically, key #1 is the PMK, the fifth key is the Kwagf, and the first key is a key further generated based on the PMK.

[0435] In possible implementations, the AUN3 device and 5G-RG each generate key #1 directly by using the fifth key. For example, if key #1 is K 5G-RG In this case, the generation method may be key#1=KDF(5th key, 1st parameter, 2nd parameter). At least one of the 1st parameter and the 2nd parameter will be used. The 1st parameter and the 2nd parameter may be values ​​in the form of strings, numbers, etc. For example, the 1st parameter may be all values ​​of 0, 2 32 The value is -1, or a fixed value such as SQN in the authentication vector. The second parameter is, for example, the string "AUN3", or, for example, the distinguishing identifier 0x02. This embodiment does not restrict the use of more input parameters in the DKF function. After key #1 is generated, the first key is generated based on key #1.

[0436] In an alternative implementation, the AUN3 device and 5G-RG may each generate the sixth key by using the fifth key, generate the second key by using the sixth key, and then generate key #1 based on the second key. For example, the second key might be a Kwagf, and then the PMK might be generated based on the Kwagf.

[0437] If the AUN3 device does not support the first key hierarchy (using the example where the first key hierarchy is the 5G key hierarchy for illustrative purposes), the fifth key is the MSK.

[0438] Optionally, in possible implementations, after the 5G-RG establishes a secure connection to the AUN3 device, the 5G-RG returns a message to the AMF to notify it that the secure connection has been established. For example, the notification may be sent using a NAS message or an N2 message, such as a NAS uplink transport (NAS UL transport) message or an N2 initial context setup acknowledgment message.

[0439] In yet another possible implementation, after the 5G-RG establishes a secure connection to the AUN3 device, the 5G-RG sends a message back to the W-AGF, which then notifies the AMF that the secure connection has been established.

[0440] In the embodiment shown in Figure 9, the 5G-RG determines whether the AUN3 device supports the first key hierarchy based on information transmitted by the AUN3 device, and the AMF determines whether the AUN3 device supports the first key hierarchy based on information reported by the 5G-RG. The present application further provides a communication method in which the AMF and AUSF can determine whether the AUN3 device supports the first key hierarchy based on information received from the UDM. The communication method will be described in detail below with reference to Figure 10.

[0441] Figure 10 is a schematic flowchart of the communication method according to this application. The following steps are included.

[0442] S1011:5G-RG registers with 5GC.

[0443] For details, please refer to the explanation of step S911 in Figure 9. Further details will not be explained here.

[0444] S1010: The AUN3 device establishes a connection to the first gateway.

[0445] For details, please refer to the explanation of step S910 in Figure 9. Further details will not be explained here.

[0446] S1021: 5G-RG sends a first request message to the AUN3 device; in other words, the AUN3 device receives the first request message from 5G-RG.

[0447] For details, please refer to the explanation of step S921 in Figure 9. Further details will not be explained here.

[0448] S1020: AUN3 sends a first response message to 5G-RG, in other words, 5G-RG receives a first response message from AUN3.

[0449] For a description of the first response message, please refer to the description of the first response message in step S920 of Figure 9. The difference is that the first response message in this embodiment does not need to indicate whether the AUN3 device supports the first key hierarchy, and this will not be explained in detail again here.

[0450] S1030: 5G-RG sends a NAS registration request message to AMF; in other words, AMF receives a NAS registration request message from 5G-RG.

[0451] For a description of the NAS registration request message, please refer to the description of the NAS registration request message in step S930 of Figure 9. The difference is that the NAS registration request message in this embodiment does not need to include the fourth instruction information, and this will not be explained in detail again here. For ease of distinction, in this embodiment the NAS registration request message will be referred to as NAS registration request message #1.

[0452] S1040: AMF sends an authentication request message to AUSF; in other words, AUSF receives an authentication request message from AMF.

[0453] For an explanation of the authentication request message, please refer to the explanation of the authentication request message in step S950 of Figure 9. In this embodiment, the authentication request message does not need to carry the 11th instruction information, and the details will not be explained again here. For ease of distinction, in this embodiment, the NAS registration request message is referred to as authentication request message #1.

[0454] S1050: The AUSF sends a GET request message to the UDM; in other words, the UDM receives a GET request message from the AUSF.

[0455] For details, please refer to the explanation of step S960 in Figure 9. Further details will not be explained here.

[0456] S1060: The UDM determines the authentication vector and obtains whether the AUN3 device supports the first key hierarchy.

[0457] Specifically, for the method of determining the authentication vector by the UDM, please refer to the explanation of the authentication vector determination method in step S970 of Figure 9. Further details will not be explained again here. This embodiment mainly concerns how the UDM obtains information on whether the AUN3 device supports the first key hierarchy, and how it indicates to the AMF and AUSF whether the AUN3 device supports the first key hierarchy.

[0458] In a possible implementation, the UDM may obtain the SUPI of the AUN3 device in step S1060, determine the subscription data based on the SUPI of the AUN3 device, and then, based on the subscription data, determine whether the AUN3 device supports the first key tier and / or 5G NAS, and obtain the seventh instruction information and / or the eighth instruction information, where the seventh instruction information indicates whether the AUN3 device supports the first key tier and the eighth instruction information indicates whether the AUN3 device supports 5G NAS.

[0459] In another possible implementation, the AUN3 device's join data includes seventh instruction information.

[0460] In another possible implementation, the UDM may obtain the SUPI of the AUN3 device in step 1060. The SUPI is a special form of SUPI (e.g., the aforementioned <5G_device_unique_identity>@AUN3-5GC.mnc). <mnc>.mcc <mcc>(.3gppnetwork.org). For the UDM to obtain the SUPI is equivalent to obtaining information about whether the AUN3 device supports the first key hierarchy and / or 5G NAS. In this case, the AUN3-5GC is sent to the AUSF as part of the SUPI. Therefore, the seventh directive information may be the SUPI or the AUN3-5GC field within the SUPI.

[0461] It should be understood that the aforementioned implementations are merely examples illustrating how a UDM might obtain whether an AUN3 device supports the first key tier and / or 5G NAS, and do not constitute any limitation on the scope of protection of this application. Alternatively, the UDM may obtain information regarding whether an AUN3 device supports the first key tier and / or 5G NAS in a different manner. For example, whether an AUN3 device supports the first key tier and / or 5G NAS is determined based on the SUCI of the AUN3 device. Another example is obtaining historical communication data from a 5G-RG accessed by the AUN3 device, and determining whether an AUN3 device supports the first key tier and / or 5G NAS based on this historical communication data. Further details are not provided here.

[0462] Furthermore, after the UDM obtains information regarding whether the AUN3 device supports the first key tier and / or 5G NAS, the UDM may send seventh instruction information to the AUSF, which then determines how to generate the key, i.e., how to generate the key based on whether the AUN3 device supports the first key tier and / or 5G NAS. The procedure of the method shown in Figure 10 further includes the following steps.

[0463] S1070: The UDM sends an acquisition response message to the AUSF; in other words, the AUSF receives an acquisition response message from the UDM.

[0464] To facilitate distinction, in this embodiment, the acquired response message is denoted as acquired response message #1. Acquired response message #1 includes information about the authentication vector and optional seventh instruction information, where the seventh instruction information indicates whether the AUN3 device supports the first key hierarchy.

[0465] For example, possible formats for the seventh instruction information include, but are not limited to, a special format of SUPI, a special format of SUCI, string information, or at least one bit of information. For a specific explanation, please refer to the description of the first instruction information in the communication method shown in Figure 9. Further details will not be explained here.

[0466] Optionally, when the UDM receives a SUCI, the Acquisition Response message #1 carries the SUPI of the AUN3 device. If the SUPI of the AUN3 device indicates whether the AUN3 device supports the first key hierarchy (for example, if the SUPI is in a special format), then the seventh instruction information may be understood as a field indicating the SUPI of the AUN3 device, or whether the first key hierarchy is supported in the SUPI.

[0467] Optionally, when the UDM determines whether the AUN3 device supports 5G NAS, the acquired response message #1 carries the eighth instruction information, which indicates whether the AUN3 device supports 5G NAS.

[0468] S1080: The AUN3 device and AUSF perform bidirectional authentication.

[0469] For details, please refer to the explanation of step S990 in Figure 9. Further details will not be explained here.

[0470] Furthermore, in this embodiment, after receiving the acquisition response message #1, AUSF may determine whether the AUN3 device supports the first key hierarchy.

[0471] The procedure for the method shown in Figure 10 further includes the following steps:

[0472] S1090:AUSF determines the key generation method and generates the key.

[0473] For details, please refer to the explanation of step S991 in Figure 9. Details will not be explained again here. It should be further noted that when it is necessary to transmit the seventh instruction information, AUSF determines in step S1010 whether the AUN3 device supports the first key hierarchy based on the seventh instruction information and determines the key generation method. When the seventh instruction information is transmitted optionally, AUSF determines in step S1010 whether the AUN3 device supports the first key hierarchy based on whether the seventh instruction information is present and determines the key generation method.

[0474] S1091: AUSF sends an authentication response message to AMF; in other words, AMF receives an authentication response message from AUSF.

[0475] To facilitate distinction, the authentication response message in this embodiment is denoted as authentication response message #1. Authentication response message #1 carries ninth instruction information indicating whether the AUN3 device supports the first key hierarchy.

[0476] Optionally, the 9th instruction information and the 7th instruction information are the same. For example, AUSF forwards the received 7th instruction information to AMF.

[0477] Optionally, the 9th instruction information and the 7th instruction information have the same meaning but are in different formats. For example, 5G-RG processes the received 7th instruction information to obtain the 9th instruction information.

[0478] Regardless of whether the ninth and seventh directives are in the same format, they represent the same meaning. Therefore, the ninth directive will not be explained again. Please refer to the explanation of the seventh directive for information on the ninth directive.

[0479] For example, authentication response message #1 may further include a tenth instruction, which indicates whether the AUN3 device supports the NAS protocol. For example, AUSF may receive an eighth instruction, and based on that instruction, AUSF may learn whether the AUN3 device supports the NAS protocol, and as a result, the tenth instruction may be carried in authentication response message #1. The tenth instruction and the eighth instruction may have the same meaning and be in the same format, or they may be in different formats.

[0480] S1092:AMF determines whether the AUN3 device supports the first key hierarchy.

[0481] After receiving authentication response message #1, AMF may determine whether the AUN3 device supports the first key hierarchy.

[0482] For specific determination methods, please refer to the explanation of step S940 in Figure 9. Details will not be explained again here. When it is necessary to transmit the ninth instruction information, the AMF determines whether the AUN3 device supports the first key hierarchy and determines the key generation method based on the ninth instruction information in step S1010. When the ninth instruction information is transmitted optionally, the AMF determines whether the AUN3 device supports the first key hierarchy and determines the key generation method based on whether the ninth instruction information is present in step S1010.

[0483] In a possible implementation, the AMF determines, based on the decision in step S1092, that the AUN3 device supports the first key tier and 5G NAS.

[0484] Optionally, in this implementation, if AMF determines that an AUN3 device supports the first key hierarchy by deciding that the AUN3 device supports 5G NAS, AMF may further generate a NAS key and initiate a NAS SMC procedure with the AUN3 device based on the NAS key.

[0485] The procedure of the method shown in Figure 10 may further include the following steps:

[0486] S1094: Perform the NAS SMC procedure between AMF and AUN3 device.

[0487] In another possible implementation, the AMF determines, based on the decision in step S1092, that the AUN3 device supports the first key hierarchy.

[0488] In this implementation, AMF generates a Kamf using the third key and the SUPI of the AUN3 device, and then uses the Kamf to further generate a key K5G-RG or Kwagf.

[0489] In yet another possible implementation, the AMF determines, based on the decision in step S1092, that the AUN3 device supports the first key hierarchy.

[0490] In this implementation, the AMF does not generate a second key; it simply needs to send the received third key to the 5G-RG.

[0491] The procedure for the method shown in Figure 10 further includes the following steps:

[0492] S1093: AMF determines the second key.

[0493] S1095: The AMF sends the fifth key to the 5G-RG; in other words, the 5G-RG receives the fifth key from the AMF.

[0494] For details, please refer to the explanation of step S995 in Figure 9. Further details will not be explained here.

[0495] S1096:5G-RG establishes a secure connection to the AUN3 device.

[0496] For details, please refer to the explanation of step S996 in Figure 9. Further details will not be explained here.

[0497] In the embodiment shown in Figure 10, the AMF and AUSF determine, based on the UDM's instruction information, whether the AUN3 device supports 5G NAS or the first key hierarchy. As a result, subsequent core network elements can determine whether the AUN3 device currently requesting access supports the first key hierarchy, select an appropriate key derivation method to generate a key, and improve communication security.

[0498] It should be understood that the sequence numbers of the processes described above do not indicate the order of execution. The execution order of the processes should be determined based on the function and internal logic of the processes and should not be interpreted as any restriction on the implementation processes of the embodiments of this application.

[0499] In the embodiments of this application, unless otherwise stated or unless there is a logical inconsistency, the terminology and / or descriptions in different embodiments are consistent and may be mutually referenced, and the technical features in different embodiments may be combined based on their internal logical relationships to form new embodiments.

[0500] In some of the embodiments described above, devices in existing network architectures (e.g., AUN3 devices, 5G-RG, AMF, AUSF, and UDM) are used primarily as illustrative examples. It should be understood that the specific form of the device is not limited in the embodiments of this application. For example, all devices that can implement the same functionality in the future are applicable to the embodiments of this application.

[0501] In the embodiments of the above-described method, the methods and operations implemented by the device (e.g., AUN3 device, 5G-RG, AMF, AUSF, and UDM) may alternatively be implemented by the device components (e.g., chips or circuits).

[0502] The communication method provided in embodiments of this application is described in detail above with reference to Figures 9 and 10. The above communication method is described primarily in terms of interaction between the protocol layers of terminal devices. To implement the above functions, it may be understood that the terminal device includes a corresponding hardware structure and / or a software module for performing the functions.

[0503] Those skilled in the art will recognize, by referring to the examples described in the embodiments disclosed herein, that units and algorithmic steps can be implemented in hardware or in combination of computer software and hardware as described in this application. Whether a function is performed by hardware or by hardware driven by computer software depends on the specific application and the design constraints of the technical solution. Those skilled in the art may use different methods to implement the functions described for each specific application, and such implementations should not be considered beyond the scope of this application.

[0504] The communication device provided in this application will be described in detail below with reference to Figures 11 to 13. Please understand that the description of the device's embodiments corresponds to the description of the method's embodiments. Therefore, for details not described in detail, please refer to the previously described method embodiments. For the sake of brevity, some details will not be explained again.

[0505] In embodiments of this application, a transmitter device or a receiver device may be divided into functional modules based on the examples of the methods described above. For example, each functional module may be obtained by a division based on its respective corresponding function, or two or more functions may be integrated into a single processing module. The integrated module may be implemented in hardware form or in the form of a software functional module. It should be noted that in embodiments of this application, the division into modules is merely an example and is a division of logical functions, and other divisions may be used in actual implementations. The following explanation will be provided using examples in which each functional module is obtained by a division based on its respective corresponding function.

[0506] Figure 11 is a block diagram of a communication device 10 according to an embodiment of this application. The device 10 includes a transceiver module 11 and a processing module 12. The transceiver module 11 may implement corresponding communication functions. The processing module 12 is configured to perform data processing. In other words, the transceiver module 11 is configured to perform transmission and reception operations. The processing module 12 is configured to perform operations other than reception and transmission. The transceiver module 11 is sometimes referred to as a communication interface or communication unit.

[0507] Optionally, the device 10 may further include a storage module 13. The storage module 13 may be configured to store instructions and / or data. The processing module 12 may read instructions and / or data from the storage module, enabling the device to implement the operation of the device in the embodiments of the method described above.

[0508] In one design, the device 10 may correspond to the AUN3 device or a component of the AUN3 device (e.g., a chip) in the embodiment of the method described above.

[0509] The device 10 may implement the corresponding steps or procedures performed by the AUN3 device in the embodiments of the method described above. The transceiver module 11 may be configured to perform the transmit / receive related operations of the AUN3 device in the embodiments of the method described above. The processing module 12 may be configured to perform the processing related operations of the AUN3 device in the embodiments of the method described above.

[0510] In a possible implementation, the transceiver module 11 is configured to receive a first request message from the first gateway, which is used to request identification information for a terminal device. The terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identification information is used by the core network to perform identity authentication against the terminal device. The transceiver module 11 is configured to send a first response message to the first gateway, which contains the identification information and indicates whether the terminal device supports the first key hierarchy. The transceiver module 11 is configured to receive a message from the first gateway indicating that identity authentication was successful. The processing module 12 is configured to generate a first key based on whether the terminal device supports the first key hierarchy, and the first key is used to perform security protection over the connection between the terminal device and the first gateway.

[0511] When the device 10 is configured to perform the method shown in Figure 9, the transceiver module 11 may be configured to perform the steps of sending and receiving information in this method, for example, steps S910, S921, S920, S994 and S996, and the processing module 12 may be configured to perform the processing steps in this method.

[0512] When the device 10 is configured to perform the method shown in Figure 10, the transceiver module 11 may be configured to perform steps of sending and receiving information in this method, for example, steps S1010, S1021, S1020, S1094 and S1096, and the processing module 12 may be configured to perform processing steps in this method.

[0513] It should be understood that the specific process by which the unit performs the corresponding steps described above is described in detail in the embodiments of the method described above. For the sake of brevity, the details will not be described here.

[0514] In an alternative design, device 10 may correspond to the first gateway or a component of the first gateway (e.g., a chip) in the embodiment of the method described above.

[0515] The device 10 may implement the corresponding steps or procedures performed by the first gateway in the embodiments of the method described above. The transceiver module 11 may be configured to perform the transmit / receive related operations of the first gateway in the embodiments of the method described above. The processing module 12 may be configured to perform the processing related operations of the first gateway in the embodiments of the method described above.

[0516] In a possible implementation, the transceiver module 11 is configured to send a first request message to a terminal device, which is used to request the terminal device's identification information. The terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identification information is used by the core network to perform identity authentication on the terminal device. The transceiver module 11 is configured to receive a first response message from the terminal device, which includes the identification information and indicates whether the terminal device supports the first key hierarchy. The transceiver module 11 is configured to send the identification information and instructional information indicating whether the terminal device supports the first key hierarchy to an access and mobility management network element, which is located within the core network. The transceiver module 11 is configured to send a message to the terminal device indicating that identity authentication was successful. The processing module 12 generates a first key based on the fifth key, which is used to perform security protection on the connection between the terminal device and the first gateway.

[0517] When the device 10 is configured to perform the method shown in Figure 9, the transceiver module 11 may be configured to perform the steps of sending and receiving information in this method, for example, steps S910, S921, S920, S930, S995 and S996, and the processing module 12 may be configured to perform the processing steps in this method, for example, step S911.

[0518] When the device 10 is configured to perform the method shown in Figure 10, the transceiver module 11 may be configured to perform the steps of sending and receiving information in this method, for example, steps S1010, S1021, S1020, S1030, S1095 and S1096, and the processing module 12 may be configured to perform the processing steps in this method, for example, step S1011.

[0519] It should be understood that the specific process by which the unit performs the corresponding steps described above is described in detail in the embodiments of the method described above. For the sake of brevity, the details will not be described here.

[0520] In yet another design, the device 10 may correspond to an access and mobility management network element, or a component (e.g., a chip) of an access and mobility management network element, in the embodiment of the method described above.

[0521] Device 10 may implement corresponding steps or procedures performed by the access and mobility management network element in the embodiments of the method described above. The transceiver module 11 may be configured to perform the transmit / receive related operations of the access and mobility management network element in the embodiments of the method described above. The processing module 12 may be configured to perform the processing related operations of the access and mobility management network element in the embodiments of the method described above.

[0522] In a possible implementation, the transceiver module 11 is configured to receive identification information and instruction information from the first gateway indicating whether the terminal device supports the first key hierarchy. The processing module 12 is configured to generate a fifth key based on whether the terminal device supports the first key hierarchy. The transceiver module 11 is configured to send the fifth key and a message indicating that the identification authentication was successful.

[0523] When the device 10 is configured to perform the method shown in Figure 9, the transceiver module 11 may be configured to perform the steps of sending and receiving information in this method, for example, steps S930, S950, S992, and S994, and the processing module 12 may be configured to perform the processing steps in this method, for example, steps S940 and S993.

[0524] When the device 10 is configured to perform the method shown in Figure 10, the transceiver module 11 may be configured to perform the steps of sending and receiving information in this method, for example, steps S1091 and S1094, and the processing module 12 may be configured to perform the processing steps in this method, for example, steps S1092 and S1093.

[0525] It should be understood that the specific process by which the unit performs the corresponding steps described above will be described in detail in the embodiments of the method described above. For the sake of brevity, the details will not be described here.

[0526] In one design, the device 10 may correspond to a data management network element or a component of a data management network element (e.g., a chip) in the embodiment of the method described above.

[0527] The device 10 may implement the corresponding steps or procedures performed by the data management network element in the embodiments of the method described above. The transceiver module 11 may be configured to perform the transmit / receive related operations of the data management network element in the embodiments of the method described above. The processing module 12 may be configured to perform the processing related operations of the data management network element in the embodiments of the method described above.

[0528] In a possible implementation, the transceiver module 11 is configured to receive an Acquisition Request message from an authentication network element, which is used to request the acquisition of an authentication vector required for authentication, and which includes an identifier for an authenticateable non-third-generation partnership project AUN3 device. The transceiver module 11 is configured to send an Acquisition Response message to the authentication network element, which includes information about the authentication vector and seventh-indication information, the seventh-indication information indicating whether the AUN3 device supports the first key hierarchy, and the information about the authentication vector and the seventh-indication information are acquired based on the identifier of the AUN3 device.

[0529] When the device 10 is configured to perform the method shown in Figure 9, the transceiver module 11 may be configured to perform the steps of sending and receiving information in the method, for example, steps S960 and S980, and the processing module 12 may be configured to perform the processing steps in the method, for example, step S970.

[0530] When the device 10 is configured to perform the method shown in Figure 10, the transceiver module 11 may be configured to perform the steps of sending and receiving information in the method, for example, steps S1050 and S1070, and the processing module 12 may be configured to perform the processing steps in the method, for example, step S1060.

[0531] It should be understood that the specific process by which the unit performs the corresponding steps described above will be described in detail in the embodiments of the method described above. For the sake of brevity, the details will not be described here.

[0532] In one design, the device 10 may correspond to an authentication network element or a component of an authentication network element (e.g., a chip) in the embodiment of the method described above.

[0533] The device 10 may implement the corresponding steps or procedures performed by the authentication network element in the embodiments of the method described above. The transceiver module 11 may be configured to perform the transmit / receive operations of the authentication network element in the embodiments of the method described above. The processing module 12 may be configured to perform the processing operations of the authentication network element in the embodiments of the method described above.

[0534] In a possible implementation, transceiver module 11 is configured to receive authentication request messages from access and mobility management network elements, which are used to request authentication network elements to perform authentication for authenticateable non-third-generation partnership project AUN3 devices, and the authentication request messages include the identifier of the AUN3 device. Transceiver module 11 is configured to send retrieve request messages to data management network elements, which are used to request the retrieval of the authentication vector required for authentication, and the retrieve request messages include the identifier of the AUN3 device. Transceiver module 11 is configured to receive retrieve response messages from data management network elements, which include information about the authentication vector and seventh instruction information, the seventh instruction information indicating whether the AUN3 device supports the first key hierarchy. Processing module 12 is configured to generate a third key based on the identifier of the AUN3 device and whether the AUN3 device supports the first key hierarchy. The transceiver module 11 is configured to send an authentication response message to an access and mobility management network element, the authentication response message including a third key and a ninth instruction information, the ninth instruction information indicating whether the AUN3 device supports the first key hierarchy, and the corresponding method for generating the third key when the AUN3 device supports the first key hierarchy is different from the corresponding method for generating the third key when the AUN3 device does not support the first key hierarchy.

[0535] When the device 10 is configured to perform the method shown in Figure 9, the transceiver module 11 may be configured to perform the steps of sending and receiving information in the method, for example, steps S950, S960, S980, and S992, and the processing module 12 may be configured to perform the processing steps in the method, for example, step S991.

[0536] When the device 10 is configured to perform the method shown in Figure 10, the transceiver module 11 may be configured to perform the steps of sending and receiving information in the method, for example, steps S1040, S1050, S1070, and S1091, and the processing module 12 may be configured to perform the processing step in the method, for example, step S1090.

[0537] It should be understood that the specific process by which the unit performs the corresponding steps described above is described in detail in the embodiments of the method described above. For the sake of brevity, the details will not be described here.

[0538] It should be further understood that in this specification, the device 10 is presented in the form of a functional module. The term “module” as used herein may be an application-specific integrated circuit (ASIC), an electronic circuit, a processor (such as a shared processor, a dedicated processor, or a group processor) configured to run one or more software or firmware programs, memory, a combinational logic circuit, and / or another suitable component that supports the function described. In any example, those skilled in the art will understand that the device 10 may specifically be a mobility management network element in the embodiments described above and may be configured to perform procedures and / or steps corresponding to a mobility management network element in the embodiments of the methods described above. Alternatively, the device 10 may specifically be a terminal device in the embodiments described above and may be configured to perform procedures and / or steps corresponding to a terminal device in the embodiments of the methods described above. To avoid repetition, further details will not be described here.

[0539] Each of the above solutions has a function to implement the corresponding steps performed by the device (AUN3 device, 5G-RG, AMF, AUSF, UDM, etc.) in the above method. This function may be implemented by hardware, or by the hardware running the corresponding software. The hardware or software includes one or more modules corresponding to the above function. For example, a transceiver module may be replaced by a transceiver (for example, a transmitting unit in a transceiver module may be replaced by a transmitter, and a receiving unit in a transceiver module may be replaced by a receiver), and another unit such as a processing module may be replaced by a processor, each capable of performing the transmit / receive operation and associated processing operation in the embodiment of the method.

[0540] In addition, the transceiver module 11 may be a transceiver circuit (for example, the transceiver module may include a receiving circuit and a transmitting circuit), and the processing module may be a processing circuit.

[0541] Figure 12 is a diagram of another communication device 20 according to an embodiment of the present application. The device 20 includes a processor 21. The processor 21 is configured to execute computer programs or instructions stored in memory 22, or to read data / signaling stored in memory 22 to execute the method in the embodiment of the method described above. Optionally, there may be one or more processors 21.

[0542] Optionally, as shown in Figure 12, the device 20 further includes a memory 22, which is configured to store computer programs or instructions and / or data. The memory 22 and the processor 21 may be integrated or located separately. Optionally, one or more memories 22 may be present.

[0543] Optionally, the device 20 further includes a transceiver 23, as shown in Figure 12. The transceiver 23 is configured to receive and / or transmit signals. For example, a processor 21 is configured to control the transceiver 23 to receive and / or transmit signals.

[0544] In one solution, the device 20 is configured to implement the operations performed by the AUN3 device in the embodiment of the method described above.

[0545] In an alternative solution, the device 20 is configured to implement the operations performed by 5G-RG in the embodiments of the method described above.

[0546] In yet another solution, the device 20 is configured to implement the operations performed by the AMF in the embodiments of the method described above.

[0547] In yet another solution, the device 20 is configured to implement the operations performed by AUSF in the embodiments of the method described above.

[0548] In yet another solution, the device 20 is configured to implement the operations performed by the UDM in the embodiments of the method described above.

[0549] It should be understood that the processor referred to in the embodiments of this application may be a central processing unit (CPU), and may also be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc.

[0550] It should be further understood that the memory referred to in this embodiment of the present application may be volatile memory and / or non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). For example, RAM may be used as an external cache. As an example, rather than an exhaustive list, RAM includes several forms such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchlink dynamic random access memory (synchlink DRAM, SLDRAM), and direct rambus random access memory (direct rambus RAM, DR RAM).

[0551] Note that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, memory (storage module) may be integrated into the processor.

[0552] It should be further noted that the memories described herein are intended to include, but are not limited to, these memories and any other suitable type of memory.

[0553] Figure 13 is a diagram of a chip system 30 according to an embodiment of the present application. The chip system 30 (sometimes also called a processing system) includes a logic circuit 31 and an input / output interface 32.

[0554] The logic circuit 31 may be a processing circuit within the chip system 30. The logic circuit 31 may be coupled to a memory unit and call instructions within the memory unit, so that the chip system 30 can implement the methods and functions of the embodiments of this application. The input / output interface 32 may be an input / output circuit within the chip system 30 that outputs information processed by the chip system 30 or inputs data or signaling information to be processed into the chip system 30 for processing.

[0555] As a solution, the chip system 30 is configured to implement the operations performed by the AUN3 device, 5G-RG, AMF, AUSF, or UDM in the embodiment of the method described above.

[0556] For example, the logic circuit 31 is configured to implement processing-related operations performed by the AUN3 device, 5G-RG, AMF, AUSF, or UDM in the embodiment of the method described above. The input / output interface 32 is configured to implement transmit and / or receive-related operations performed by the AUN3 device, 5G-RG, AMF, AUSF, or UDM in the embodiment of the method described above.

[0557] Embodiments of this application further provide a computer-readable storage medium that stores computer instructions used to implement a method performed by an AUN3 device, 5G-RG, AMF, AUSF, or UDM in embodiments of the methods described above.

[0558] For example, when a computer program is executed by a computer, the computer can implement the method executed by an AUN3 device, 5G-RG, AMF, AUSF, or UDM, as described in the embodiments of the method described above.

[0559] Embodiments of this application further provide a computer program product including instructions. When the instructions are executed by a computer, embodiments of the above-described method implement a method that is executed by an AUN3 device, 5G-RG, AMF, AUSF, or UDM.

[0560] Embodiments of this application further provide a communication system including the AUN3 device, 5G-RG, AMF, AUSF, and UDM described above.

[0561] For a description of the relevant content in any of the devices provided above and its effects, please refer to the corresponding embodiment of the method provided above. Further details will not be explained again here.

[0562] In some embodiments provided in this application, it should be understood that the disclosed apparatus and methods may be implemented in other ways. For example, the embodiments of the apparatus described are merely examples. For example, the division into units is merely a logical functional division, and in actual implementation, other divisions may be used. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or omitted. In addition, the mutual coupling, direct coupling, or communication connection shown or discussed may be implemented through some interfaces. Indirect coupling or communication connection between apparatus or units may be implemented electrically, mechanically, or in other forms.

[0563] All or part of the embodiments described above may be implemented using software, hardware, firmware, or any combination thereof. When an embodiment is implemented using software, all or part of the embodiment may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When a computer program instruction is loaded into a computer and executed, all or part of the procedures or functions according to the embodiments of this application are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable device. For example, the computer may be a personal computer, a server, a network device, etc. Computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio, or microwave). Computer-readable storage media may be any usable media accessible by a computer, or a data storage device that integrates one or more usable media, such as a server or data center. Usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), semiconductor media (e.g., solid-state disks, SSDs), etc. For example, usable media may include, but are not limited to, any media capable of storing program code, such as USB flash drives, removable hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0564] The foregoing description is merely a specific implementation of the present application and is not intended to limit the scope of protection of this application. All modifications or substitutions readily understood by those skilled in the art within the scope of the technical scope disclosed in this application shall be included within the scope of protection of this application. Accordingly, the scope of protection of this application shall be subject to the scope of protection of the claims.< / mcc> < / mnc> < / mcc> < / mnc>

Claims

1. A method of communication, The steps include: receiving an authentication request message from an access and mobility management network element via an authentication network element, wherein the authentication request message is used to request the authentication network element to perform authentication on a terminal device; The steps include: sending a retrieval request message from the authentication network element to a data management network element, wherein the retrieval request message includes an identifier for the terminal device, and the retrieval request message is used to request the retrieval of the authentication vector necessary for the authentication; A step of receiving an acquisition response message from the data management network element via the authentication network element, wherein the acquisition response message includes the authentication vector, The authentication network element performs the authentication on the terminal device based on the authentication vector, The steps include: the authentication network element sending an authentication response message to the access and mobility management network element, wherein the authentication response message indicates that the authentication was successful, and the authentication response message includes a key; Includes, When the terminal device does not support the first key hierarchy, the key is an MSK key, and the acquired response message further includes a seventh instruction information indicating that the terminal device does not support the first key hierarchy, and the method In response to the seventh instruction information, the authentication network element generates the MSK key based on a key hierarchy other than the first key hierarchy. A communication method that further includes the above.

2. If the terminal device does not support the first key hierarchy, the authentication network element will not generate a Kausf key. The method according to claim 1.

3. When the terminal device supports the first key hierarchy, the key is a Ksef key, and the method is The authentication network element generates the Ksef key based on the first key hierarchy. The method according to claim 1 or 2, further comprising:

4. When the terminal device supports the first key hierarchy, the acquisition response message further includes information indicating that the terminal device supports the first key hierarchy, and the authentication network element generates the Ksef key based on the first key hierarchy. The authentication network element generates the Ksef key based on the first key hierarchy in response to the information indicating that the terminal device supports the first key hierarchy. The method according to claim 3.

5. The authentication network element generates the Ksef key based on the first key hierarchy, The authentication network element includes generating a Kausf key and generating a Ksef key based on the Kausf key, The method according to claim 3 or 4.

6. A method of communication, A data management network element receives a retrieval request message from an authentication network element, wherein the retrieval request message includes an identifier for a terminal device, and the retrieval request message is used to request the retrieval of an authentication vector necessary to perform authentication on the terminal device. The steps include: sending an acquisition response message to the authentication network element via the data management network element, wherein the acquisition response message includes the authentication vector; Includes, When the terminal device does not support the first key hierarchy, the acquired response message further includes a seventh instruction information indicating that the terminal device does not support the first key hierarchy. Communication method.

7. The subscriber data of the terminal device includes instruction information indicating whether the terminal device supports the first key hierarchy. When the terminal device does not support the first key hierarchy, the acquired response message further includes the seventh instruction information indicating that the terminal device does not support the first key hierarchy. When the instruction information indicates that the terminal device does not support the first key hierarchy, the acquired response message further includes the seventh instruction information indicating that the terminal device does not support the first key hierarchy. The method according to claim 6.

8. When the terminal device supports the first key hierarchy, the retrieval response message further includes information indicating that the terminal device supports the first key hierarchy, or the retrieval response message does not include information indicating whether the terminal device supports the first key hierarchy. The method according to claim 6 or 7.

9. The subscriber data of the terminal device includes instruction information indicating whether the terminal device supports the first key hierarchy. When the terminal device supports the first key hierarchy, the acquired response message further includes information indicating that the terminal device supports the first key hierarchy, or the acquired response message does not include information indicating whether the terminal device supports the first key hierarchy. When the instruction information indicates that the terminal device supports the first key hierarchy, the acquired response message further includes the information indicating that the terminal device supports the first key hierarchy, or the acquired response message does not include the information indicating whether the terminal device supports the first key hierarchy. The method according to claim 8.

10. A method of communication, The steps include: an access and mobility management network element sending an authentication request message to an authentication network element, the authentication request message being used to request the authentication network element to perform authentication on a terminal device; The access and mobility management network element receives an authentication response message from the authentication network element, wherein the authentication response message indicates that the authentication was successful, and the authentication response message includes a key. When the terminal device does not support the first key hierarchy, the access and mobility management network element transmits an MSK key to the first network element, wherein the key is an MSK key, and the MSK key is used to establish a secure connection between the terminal device and the first network element. A communication method that includes this.

11. If the terminal device does not support the first key hierarchy, the Kamf key will not be generated by the access and mobility management network element. The method according to claim 10.

12. When the terminal device supports the first key hierarchy, the key is a Ksef key, and the method is A step comprising: an access and mobility management network element generating a second key based on the Kseaf key and transmitting the second key to the first network element, wherein the second key is used to establish a secure connection between the terminal device and the first network element. The method according to claim 10 or 11, further comprising:

13. The authentication response message further includes the subscriber persistent identifier of the terminal device, and the access and mobility management network element generates the second key based on the Ksef key, The access and mobility management network element includes generating a Kamf key based on the Kseaf key and the subscriber persistence identifier, and generating the second key based on the Kamf key, The method according to claim 12.

14. A method of communication, The steps include: an access and mobility management network element sending an authentication request message to an authentication network element, the authentication request message being used to request the authentication network element to perform authentication on a terminal device; The authentication network element receives the authentication request message from the access and mobility management network element, The steps include: sending a retrieval request message from the authentication network element to a data management network element, wherein the retrieval request message includes an identifier for the terminal device, and the retrieval request message is used to request the retrieval of the authentication vector necessary for the authentication; The data management network element receives the acquisition request message from the authentication network element, The steps include: sending an acquisition response message to the authentication network element via the data management network element, wherein the acquisition response message includes the authentication vector; The authentication network element receives the acquisition response message from the data management network element and performs the authentication on the terminal device based on the authentication vector. The steps include: the authentication network element sending an authentication response message to the access and mobility management network element, wherein the authentication response message indicates that the authentication was successful, and the authentication response message includes a key; The access and mobility management network element receives the authentication response message from the authentication network element. Includes, When the terminal device does not support the first key hierarchy, the key is an MSK key, and the acquired response message further includes a seventh instruction information indicating that the terminal device does not support the first key hierarchy, and the method The steps include: generating the MSK key based on a key hierarchy other than the first key hierarchy using the authentication network element in response to the seventh instruction information; The steps include: transmitting the MSK key to a first network element via the access and mobility management network element, wherein the MSK key is used to establish a secure connection between the terminal device and the first network element; A communication method that further includes the above.

15. The subscriber data of the terminal device includes instruction information indicating whether the terminal device supports the first key hierarchy. When the terminal device does not support the first key hierarchy, the acquired response message further includes the seventh instruction information indicating that the terminal device does not support the first key hierarchy. When the instruction information indicates that the terminal device does not support the first key hierarchy, the acquired response message further includes the seventh instruction information indicating that the terminal device does not support the first key hierarchy. The method according to claim 14.

16. When the terminal device does not support the first key hierarchy, the authentication network element will not generate a Kausf key, and the access and mobility management network element will not generate a Kamf key. The method according to claim 14 or 15.

17. When the terminal device supports the first key hierarchy, the key is a Ksef key, and the method is The authentication network element generates the Ksef key based on the first key hierarchy, The access and mobility management network element generates a second key based on the Kseaf key and transmits the second key to the first network element, wherein the second key is used to establish a secure connection between the terminal device and the first network element. The method according to any one of claims 14 to 16, further comprising:

18. The authentication network element generates the Ksef key based on the first key hierarchy, The authentication network element includes the step of generating a Kausf key and generating a Ksef key based on the Kausf key, The method according to claim 17.

19. The authentication response message further includes the subscriber persistent identifier of the terminal device, and the access and mobility management network element generates the second key based on the Ksef key, The access and mobility management network element includes generating a Kamf key based on the Kseaf key and the subscriber persistence identifier, and generating the second key based on the Kamf key, The method according to claim 17 or 18.

20. When the terminal device supports the first key hierarchy, the retrieval response message further includes information indicating that the terminal device supports the first key hierarchy, or the retrieval response message does not include information indicating whether the terminal device supports the first key hierarchy. The method according to any one of claims 14 to 19.

21. The subscriber data of the terminal device includes instruction information indicating whether the terminal device supports the first key hierarchy. When the terminal device supports the first key hierarchy, the acquired response message further includes information indicating that the terminal device supports the first key hierarchy, or the acquired response message does not include information indicating whether the terminal device supports the first key hierarchy. When the instruction information indicates that the terminal device supports the first key hierarchy, the acquired response message further includes the information indicating that the terminal device supports the first key hierarchy, or the acquired response message does not include the information indicating whether the terminal device supports the first key hierarchy. The method according to claim 20.

22. When the acquired response message further includes the information indicating that the terminal device supports the first key hierarchy, the authentication network element generates the Ksef key based on the first key hierarchy. The authentication network element generates the Ksef key based on the first key hierarchy in response to the information indicating that the terminal device supports the first key hierarchy. The method according to claim 20 or 21.

23. The second key is a Kwagf key. The method according to claim 12 or 13, or any one of claims 17 to 19.

24. The aforementioned first key hierarchy is a fifth-generation 5G key hierarchy. The method according to any one of claims 1 to 23.

25. The aforementioned terminal device is an authenticated non-third-generation partnership project AUN3 device. The method according to any one of claims 1 to 24.

26. The aforementioned first gateway is a fifth-generation residential gateway 5G-RG. The method according to any one of claims 1 to 25.

27. A communication system including an authentication network element, a data management network element, and an access and mobility management network element, The authentication network element is configured to perform the method described in any one of claims 1 to 5, The data management network element is configured to perform the method described in any one of claims 6 to 9, The access and mobility management network element is configured to perform the method described in any one of claims 10 to 13. Communication system.

28. A method of communication, A step of receiving a first request message from a first gateway, wherein the first request message is used to request identification information for a terminal device, the terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identification information is used by the core network to perform identification authentication on the terminal device. A step of sending a first response message to the first gateway, wherein the first response message includes the identification information and indicates whether the terminal device supports the first key hierarchy. The steps include receiving a message from the first gateway indicating that the identification authentication was successful, A step of generating a first key based on whether the terminal device supports the first key hierarchy, wherein the first key is used to perform security protection over the connection between the terminal device and the first gateway. A communication method that includes this.

29. Generating the first key based on whether the terminal device supports the first key hierarchy is: When the terminal device supports the first key hierarchy, the first key is generated by the first key derivation method, When the terminal device does not support the first key hierarchy, the first key is generated by the second key derivation method, The method according to claim 28, including the method described in claim 28.

30. The first response message indicates whether the terminal device supports the first key hierarchy. The identification information includes indicating whether the terminal device supports the first key hierarchy, The method according to claim 28 or 29.

31. The identification information indicates whether the terminal device supports the first key hierarchy. When the identification information is a first identifier, the identification information indicates that the terminal device does not support the first key hierarchy, or When the identification information is a second identifier, the identification information indicates that the terminal device supports the first key hierarchy. The method according to claim 30.

32. The identification information indicates whether the terminal device supports the first key hierarchy. When the identification information is a first identifier of a first type, the identification information indicates that the terminal device does not support the first key hierarchy, or When the identification information is a first identifier of a second type, the identification information indicates that the terminal device supports the first key hierarchy. The method according to claim 30.

33. The identification information indicates whether the terminal device supports the first key hierarchy. The identification information includes a field indicating whether the terminal device supports the first key hierarchy, The method according to claim 30.

34. The first response message further includes first instruction information, The first response message indicates whether the terminal device supports the first key hierarchy. The first instruction information includes indicating whether the terminal device supports the first key hierarchy, The method according to claim 28 or 29.

35. The first instruction information includes at least one of the following: namely, string information, bit information, or non-access layer protocol data unit, The method according to claim 34.

36. Prior to the step of receiving a message from the first gateway indicating that the identification authentication was successful, the method: The step further includes determining a serving network name, the serving network name being used for the identification authentication, and the serving network name being at least one of the following: a preset fixed value, the home public land mobile network identifier (PLMN) ID of the terminal device, or the PLMN ID of an access and mobility management network element serving the first gateway; The method according to any one of claims 28 to 35, further comprising:

37. Prior to the step of receiving the first request message from the first gateway, the method: A step of determining an access method for accessing the first gateway, wherein the access method includes trusted non-Third Generation Partnership Project 3GPP access or untrusted non-3GPP access. The method according to any one of claims 28 to 36, further comprising:

38. The first gateway includes a fifth-generation residential gateway 5G-RG, and the first key hierarchy includes a 5G key hierarchy. The method according to any one of claims 28 to 37.

39. A method of communication, A step of sending a first request message to a terminal device, wherein the first request message is used to request identification information of the terminal device, the terminal device accesses the core network via a connection between the terminal device and a first gateway, and the identification information is used by the core network to perform identification authentication on the terminal device. A step of receiving a first response message from the terminal device, wherein the first response message includes the identification information and indicates whether the terminal device supports a first key hierarchy. A step of transmitting the identification information and instruction information indicating whether the terminal device supports the first key hierarchy to an access and mobility management network element, wherein the access and mobility management network element is located within the core network. A step of receiving a fifth key and a message indicating that the identity authentication was successful from the access and mobility management network element, wherein the fifth key is generated based on whether the terminal device supports the first key hierarchy. The steps include sending the message indicating that the authentication was successful to the terminal device, A step of generating a first key based on the fifth key, wherein the first key is used to secure the connection between the terminal device and the first gateway, A communication method that includes this.

40. The fifth key is generated based on whether the terminal device supports the first key hierarchy. When the terminal device supports the first key hierarchy, the fifth key is generated by the first key derivation method. When the terminal device does not support the first key hierarchy, the fifth key is generated by the second key derivation method. The method according to claim 39, including the act of

41. Transmitting the aforementioned identification information and the instruction information indicating whether the terminal device supports the first key hierarchy to the access and mobility management network element is: This includes transmitting the identification information and the instruction information indicating whether the terminal device supports the first key hierarchy to the access and mobility management network element by using a non-access tier NAS registration request message. The first response message includes the NAS registration request message, or the NAS registration request message is generated by the first gateway based on the first response message. The method according to claim 39 or 40.

42. This method is The first gateway transmits instructional information to the access and mobility management network element indicating the device that initiates a registration request to access the core network via the connection between the device and the first gateway. The method according to claim 41, further comprising:

43. The first response message indicates whether the terminal device supports the first key hierarchy. The identification information includes indicating whether the terminal device supports the first key hierarchy, The method according to any one of claims 39 to 42.

44. The first response message further includes first instruction information, The first response message indicates whether the terminal device supports the first key hierarchy. The first instruction information includes indicating whether the terminal device supports the first key hierarchy, The method according to any one of claims 39 to 42.

45. The first gateway includes a fifth-generation residential gateway 5G-RG, and the first key hierarchy includes a 5G key hierarchy. The method according to any one of claims 39 to 44.

46. A method of communication, A step of sending a first request message to a terminal device via a first gateway, wherein the first request message is used to request identification information for the terminal device, the terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identification information is used by the core network to perform identification authentication on the terminal device. The steps include: the terminal device sending a first response message to the first gateway, wherein the first response message includes the identification information and indicates whether the terminal device supports a first key hierarchy; A first network element obtains a fifth key and a message indicating that the authentication was successful, wherein the fifth key is generated based on whether the terminal device supports the first key hierarchy. The first gateway sends the message indicating that the identification authentication was successful to the terminal device, The steps include: generating a first key based on whether the terminal device supports the first key hierarchy, wherein the first key is used to perform security protection for the connection between the terminal device and the first gateway; The first gateway generates the first key based on the fifth key, A communication method that includes this.

47. This method is The access and mobility management network element receives from the first gateway the identification information and instruction information indicating whether the terminal device supports the first key hierarchy. The access and mobility management network element generates the fifth key based on whether the terminal device supports the first key hierarchy, The access and mobility management network element transmits the fifth key to the first gateway, The method according to claim 46, further comprising:

48. A communication system comprising a terminal device and a first gateway, The first gateway is configured to send a first request message to the terminal device, the first request message is used to request identification information for the terminal device, the terminal device accesses the core network via a connection between the terminal device and the first gateway, and the identification information is used by the core network to perform identification authentication on the terminal device. The terminal device is configured to send a first response message to the first gateway, the first response message includes the identification information, and the first response message indicates whether the terminal device supports the first key hierarchy. The first network element is further configured to obtain a fifth key and a message indicating that the identity authentication was successful, the fifth key being generated based on whether the terminal device supports the first key hierarchy. The first gateway is further configured to send the message indicating that the identification authentication was successful to the terminal device. The terminal device is further configured to generate a first key based on whether the terminal device supports the first key hierarchy, and the first key is used to perform security protection over the connection between the terminal device and the first gateway. The first gateway is further configured to generate the first key based on the fifth key. Communication system.

49. The system further includes access and mobility management network elements, The access and mobility management network element is configured to receive the identification information and instruction information indicating whether the terminal device supports the first key hierarchy from the first gateway. The access and mobility management network element is further configured to generate the fifth key based on whether the terminal device supports the first key hierarchy, The access and mobility management network element is further configured to transmit the fifth key to the first gateway. The system according to claim 48.

50. A communication device comprising a unit configured to perform the method described in any one of claims 1 to 13 or any one of claims 28 to 45.

51. A communication device, Memory configured to store computer programs, A processor configured to execute the computer program stored in the memory, thereby causing the communication device to perform the method described in any one of claims 1 to 13 or any one of claims 28 to 45, A communication device equipped with the following features.

52. A computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on the computer, the computer performs the method according to any one of claims 1 to 13 or any one of claims 28 to 45.

53. A computer program product comprising a computer instruction, wherein, when the computer instruction is executed on a computer, the instruction is used to perform a step performed by a memory function network element in the method of any one of claims 1 to 13 or any one of claims 28 to 45.

Images