A key management method and communication device

Abstract

The present application discloses a key management method and a communication device, wherein the method comprises: a first RAN device receives a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device. The method can ensure the reliability of communication between the first terminal device and the destination terminal device, while avoiding the problem that the key parameters of any terminal device in the terminal device group are cracked, resulting in the key parameters of all terminal devices in the terminal device group being cracked, thereby improving the security of communication between terminal devices through RAN local forwarding.

Description

Technical Field

[0001] The present application relates to the field of mobile communication technology, and in particular to a key management method and a communication device. Background Art

[0002] At present, the communication between terminal devices can be forwarded locally through the radio access network (RAN) instead of through the core network. In the RAN local forwarding scenario, the user plane encryption of data by the terminal device is mainly completed by the end-to-end packet data convergence protocol (PDCP) layer of the terminal device, and the base station does not need to participate in the encryption of user plane data.

[0003] In the prior art, all the terminal devices in the same terminal device group generate a session group key (Session Group Key) according to the same key parameters provided by the core network, and then use the Session Group Key to encrypt the end-to-end data of the terminal devices. This leads to a problem that once the key parameters of any terminal device in the terminal device group are cracked, the key parameters of all the terminal devices in the terminal device group will be cracked, posing a serious threat to data security. The prior art has the problem of low data security when the communication between terminal devices is forwarded locally through the RAN. Summary of the invention

[0004] The present application provides a key management method and a communication device, which are used to solve the problem of low data security when communicating between terminal devices through RAN local forwarding.

[0005] In a first aspect, an embodiment of the present application provides a key management method, including: a first RAN device receives a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device.

[0006] In an embodiment of the present application, the first RAN device receives a key parameter and an identifier of a destination terminal device from the first terminal device, and then forwards the key parameter to the destination terminal device, so that both the first terminal device and the destination terminal device can encrypt / decrypt data based on the key parameter, thereby ensuring the reliability of communication. At the same time, since the key parameter is provided by the first terminal device, it is different from the prior art that all terminal devices use the same key parameter configured by the core network to encrypt and decrypt data. Therefore, it is possible to avoid the problem that the key parameters of any terminal device in the terminal device group are cracked, resulting in the key parameters of all terminal devices in the terminal device group being cracked, thereby improving the security of the data.

[0007] In a possible implementation manner, the destination terminal device is located within the coverage of the first RAN device. In this case, the first RAN device may directly forward the key parameter sent by the first terminal device to the destination terminal device.

[0008] Through this implementation, the destination terminal device and the first terminal device can both encrypt / decrypt data based on the key parameters, thereby ensuring the reliability of communication.

[0009] In a possible implementation manner, the destination terminal device is located within the coverage of the second RAN device. In this case, the first RAN device may send the key parameter and the identifier of the first terminal device to the destination terminal device through the second RAN device.

[0010] Through this implementation, the destination terminal device and the first terminal device can both encrypt / decrypt data based on the key parameters, thereby ensuring the reliability of communication.

[0011] In a possible implementation manner, the first terminal device and the first RAN device communicate through a first protocol stack, the destination terminal device and the first RAN device communicate through the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer, and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer, and a MAC layer.

[0012] Through this implementation, it can be ensured that a terminal device and a destination terminal device can communicate with the first RAN device through the second protocol stack, and the first terminal device and the destination terminal device can communicate based on the second protocol stack to achieve RAN local forwarding.

[0013] In a possible implementation manner, the first terminal device is a communication initiator, and the destination terminal device is a communication receiver; or, the destination terminal device is a communication initiator, and the first terminal device is a communication receiver.

[0014] Through this implementation, it can be ensured that both the first terminal device and the destination terminal device use the key parameters provided by the communication initiator or the communication receiver to encrypt / decrypt data, thereby ensuring the reliability of communication.

[0015] In a possible implementation manner, the key parameter is a parameter required for the first terminal device and the destination terminal device to respectively generate a session key, such as a count value (count).

[0016] Through this implementation, by transmitting the parameters required to generate the session key, it is possible to avoid the key from being directly transmitted, thereby improving the security of the key.

[0017] In a possible implementation, the above transmission process can be implemented through a control plane transmission scheme. For example, the first RAN device can receive the key parameters and the identifier of the destination terminal device sent by the first terminal device through an uplink RRC message. When the first terminal device and the destination terminal device are both located within the coverage of the first RAN device, the first RAN device can send the key parameters and the identifier of the first terminal device to the destination terminal device through a downlink RRC message. When the first terminal device is located within the coverage of the first RAN device, such as when the destination terminal device is located within the coverage of the second RAN device, the first RAN device can send the key parameters, the identifier of the first terminal device, and the identifier of the destination terminal device to the second RAN device through an interface message between the first RAN device and the second RAN device, and then the second RAN device sends the key parameters and the identifier of the first terminal device to the destination terminal device through a downlink RRC message.

[0018] Through this implementation, the transmission of key parameters and the like can be achieved through a control plane transmission scheme, thereby ensuring the reliability of the scheme.

[0019] In a possible implementation, the above transmission process may be implemented through a data user plane transmission scheme. For example, the first RAN device may receive first data sent by a first terminal device, wherein the encapsulation header encapsulated outside the first data includes the key parameter and the identifier of the destination terminal device. When the first terminal device and the destination terminal device are both located within the coverage range of the first RAN device, the first RAN device may directly send second data to the destination terminal device, wherein the encapsulation header outside the second data includes the key parameter and the identifier of the first terminal device. It should be understood that the first data and the second data here are substantially the same data and are payload data. When the first terminal device is located within the coverage range of the first RAN device, such as when the destination terminal device is located within the coverage range of the second RAN device, the first RAN device may send a GTP-U data packet to the second RAN device, wherein the GTP-U packet header carries the key parameter, the identifier of the first terminal device and the identifier of the destination terminal device, and the GTP-U data packet includes the first data, and then the third data is sent to the destination terminal device through the second RAN device, wherein the encapsulation header outside the third data includes the key parameter and the identifier of the first terminal device. It should be understood that the first data and the third data here are substantially the same data and are payload data.

[0020] Through this implementation, the transmission of key parameters and the like can be achieved through a user plane transmission scheme, thereby ensuring the reliability of the scheme.

[0021] In a possible implementation manner, the encapsulation header of the first data also includes the network slice identifier slice ID and / or the quality of service QoS flow identifier QFI of the destination terminal device.

[0022] Through this implementation, when the first RAN device sends the key parameters and the identifier of the first terminal device to the destination terminal device, the first RAN device quickly determines the DRB of the destination terminal device according to the slice ID and / or QoS flow identifier QFI of the destination terminal device, thereby ensuring the efficiency of communication.

[0023] In a possible implementation manner, the GTP-U data packet may also carry a slice ID and / or QFI of the destination terminal device.

[0024] Through this implementation, when the second RAN device sends the key parameters and the identifier of the first terminal device to the destination terminal device, the first RAN device quickly determines the DRB of the destination terminal device according to the slice ID and / or QoS flow identifier QFI of the destination terminal device, thereby ensuring communication efficiency.

[0025] In a possible implementation, the destination terminal device may be a single device, such as a second terminal device, and the identifier of the destination terminal is the first identifier of the second terminal device. Before the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device, the first RAN device also determines the second identifier of the second terminal device based on the first identifier of the second terminal device; wherein the first identifier includes a device identifier, such as an IP address, a MAC address, or an identifier of the first terminal device in its terminal device group, and the second identifier includes a cell radio network temporary identifier C-RNTI; thereafter, the first RAN device sends the key parameter and the identifier of the first terminal device to the second terminal device based on the second identifier of the second terminal device.

[0026] Through this implementation, the first RAN device can determine the cell radio network temporary identifier C-RNTI of the second terminal device based on the device identifier of the second terminal device, and then send the key parameters and the identifier of the first terminal device to the second network device based on the C-RNTI to ensure communication efficiency.

[0027] In a possible implementation manner, the destination terminal device may be a terminal device group (such as the terminal device group to which the first terminal device belongs), and the identifier of the destination terminal device includes the group identifier of the terminal device group to which the first terminal device belongs. Accordingly, the first RAN device sends the key parameter and the identifier of the first terminal device to the terminal device group via a multicast channel, wherein the multicast channel corresponds to the terminal device group.

[0028] Through this implementation, the first terminal device can provide the key parameters to the entire terminal device group through the first RAN device to achieve multicast communication.

[0029] In a possible implementation, the key parameter may be an initial key parameter assigned by the core network to the first terminal device; or, a key parameter acquired by the first terminal device based on the initial key parameter assigned by the core network.

[0030] Through this implementation, key parameters of different terminal devices in a terminal device group can be different, so that different pairs of terminal devices use different session keys for communication, thereby ensuring the security of data forwarded locally by the RAN.

[0031] In a second aspect, an embodiment of the present application provides a key management method, including: a first terminal device determines a key parameter and an identifier of a destination terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; the first terminal device sends the key parameter and the identifier of the destination terminal device to a first wireless access network RAN ​​device.

[0032] In a possible implementation manner, the destination terminal device is located within the coverage of the first RAN device.

[0033] In a possible implementation manner, the destination terminal device is located within the coverage of the second RAN device.

[0034] In a possible implementation manner, the first terminal device and the first RAN device communicate through a first protocol stack, the destination terminal device and the first RAN device communicate through the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer, and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer, and a MAC layer.

[0035] In a possible implementation manner, the key parameters are parameters required for the first terminal device and the destination terminal device to respectively generate session keys.

[0036] In a possible implementation, the first terminal device sends the key parameter and the identifier of the destination terminal device to the first wireless access network RAN ​​device, including: the first terminal device sends first data to the first wireless access network RAN ​​device, wherein the encapsulation header encapsulated outside the first data contains the key parameter and the identifier of the destination terminal device.

[0037] In a possible implementation manner, the identifier of the destination terminal device includes a first identifier of the second terminal device, and the first identifier includes a device identifier.

[0038] In a possible implementation manner, the identifier of the destination terminal device includes a group identifier of a terminal device group to which the first terminal device belongs.

[0039] In a third aspect, an embodiment of the present application provides a key management method, including: a second RAN device receives a key parameter, an identifier of a first terminal device, and an identifier of a destination terminal device sent by a first RAN device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; and the second RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device.

[0040] In a possible implementation, the destination terminal device and the second RAN device communicate through a first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer and a MAC layer.

[0041] In a possible implementation manner, the key parameters are parameters required for the first terminal device and the destination terminal device to respectively generate session keys.

[0042] In a possible implementation, the second RAN device receives a key parameter, an identifier of a first terminal device, and an identifier of a destination terminal device sent by a first RAN device, including: the second RAN device receives a user plane General Radio Packet Service Tunneling Protocol GTP-U data packet sent by the first RAN device, wherein the GTP-U packet header carries the key parameter, the identifier of the first terminal device, and the identifier of the destination terminal device.

[0043] In a possible implementation manner, the second RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device, including: the second RAN device sends third data to the destination terminal device, wherein the encapsulation header outside the third data contains the key parameter and the identifier of the first terminal device.

[0044] In a possible implementation manner, the identifier of the destination terminal device includes a first identifier of a second terminal device; before the second RAN device sends the key parameters and the identifier of the first terminal device to the destination terminal device, the method further includes: the second RAN device determines the second identifier of the second terminal device based on the first identifier of the second terminal device; wherein the first identifier includes a device identifier, and the second identifier includes a cell radio network temporary identifier C-RNTI; the second RAN device sends the key parameters and the identifier of the first terminal device to the destination terminal device, including: the second RAN device sends the key parameters and the identifier of the first terminal device to the second terminal device based on the second identifier of the second terminal device.

[0045] In a possible implementation manner, the identifier of the destination terminal device includes the group identifier of the terminal device group to which the first terminal device belongs; and the second RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device, comprising: the second RAN device sends the key parameter and the identifier of the first terminal device to the terminal device group through a multicast channel, wherein the multicast channel corresponds to the terminal device group.

[0046] In a fourth aspect, an embodiment of the present application provides a key management method, including: a destination terminal device receives a key parameter sent by a first RAN device or a second RAN device and an identifier of a first terminal device; when the destination terminal device and the first terminal device communicate with each other, the key parameter is used to encrypt and / or decrypt the transmission data.

[0047] In a fifth aspect, an embodiment of the present application provides a communication device, which may be the first RAN device in the first aspect, or a device in the first RAN device, and the device includes a module for executing a method as described in any possible implementation of the first aspect. For example:

[0048] A receiving module, configured to receive a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0049] A sending module is used to send the key parameter and the identifier of the first terminal device to the destination terminal device.

[0050] In a sixth aspect, an embodiment of the present application provides a communication device, which may be the first terminal device in the second aspect, or a device in the first terminal device, and the device includes a module for executing a method as described in any possible implementation of the second aspect. For example:

[0051] a processing module, configured to determine a key parameter and an identifier of a destination terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0052] The sending module is used to send the key parameter and the identifier of the destination terminal device to the first radio access network RAN ​​device.

[0053] In a seventh aspect, an embodiment of the present application provides a communication device, which may be the second RAN device in the third aspect, or a device in the second RAN device, and the device includes a module for executing a method as described in any possible implementation of the third aspect. For example:

[0054] a receiving module, configured to receive a key parameter, an identifier of a first terminal device, and an identifier of a destination terminal device sent by a first RAN device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0055] A sending module is used to send the key parameter and the identifier of the first terminal device to the destination terminal device.

[0056] In an eighth aspect, an embodiment of the present application provides a communication device, which may be the destination terminal device in the fourth aspect, or a device in the destination terminal device, and the device includes a module for executing a method as described in any possible implementation of the fourth aspect. For example:

[0057] A receiving module, configured to receive a key parameter and an identifier of a first terminal device sent by a first RAN device or a second RAN device;

[0058] A processing module is used to encrypt and / or decrypt transmission data using the key parameters when the first terminal device and the destination terminal device communicate with each other.

[0059] In the ninth aspect, an embodiment of the present application provides a communication device, comprising: at least one processor; and a memory and / or a communication interface communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor executes the method described in any possible implementation of the first aspect, the second aspect, the third aspect or the fourth aspect above by executing the instructions stored in the memory.

[0060] In the tenth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a computer, the computer executes a method as described in any possible implementation of the first aspect, the second aspect, the third aspect, or the fourth aspect above.

[0061] In the eleventh aspect, an embodiment of the present application provides a chip, which is coupled to a memory and is used to read and execute program instructions stored in the memory to implement a method described in any possible implementation of the first aspect, the second aspect, the third aspect or the fourth aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 This is a schematic diagram of the current NR system network architecture;

[0063] Figure 2 A flowchart for providing key parameters for the core network to the terminal device 1;

[0064] Figure 3 Schematic diagram for generating Session Group Key for terminal device 1;

[0065] Figure 4A A schematic diagram of a network architecture applicable to an embodiment of the present application;

[0066] Figure 4B A schematic diagram of another network architecture applicable to an embodiment of the present application;

[0067] Figure 5 A flowchart of a key management method provided in an embodiment of the present application;

[0068] Fig. 6A A schematic diagram of a possible user plane protocol stack;

[0069] Figure 6B is a schematic diagram of another possible user plane protocol stack;

[0070] Figure 6C is a schematic diagram of another possible user plane protocol stack;

[0071] Figure 7 When UE1 and UE2 are co-located, UE1 transmits count1 to UE2 through the control plane;

[0072] Figure 8 When UE1 and UE2 are co-located, UE1 transmits count1 to UE2 via the user plane;

[0073] Fig. 9A flowchart provided for UE1 transmitting count1 to UE2 when UE1 and UE2 cross sites;

[0074] Fig.10 A schematic diagram of the structure of a communication device 1100 provided in an embodiment of the present application;

[0075] Fig.11 A schematic diagram of the structure of a communication device 1200 provided in an embodiment of the present application;

[0076] Fig.12 A schematic diagram of the structure of a communication device 1300 provided in an embodiment of the present application;

[0077] Fig.13 A schematic diagram of the structure of a communication device 1400 provided in an embodiment of the present application;

[0078] Fig.14 A schematic diagram of the structure of a communication device 1500 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0079] Figure 1 It is a schematic diagram of the network architecture of the current new radio (NR) system. Figure 1 As shown, the NR system includes the next generation node B (gNB) on the radio access network (RAN) side, the access and mobility management function (AMF) network element, the session management function (SMF) network element, the user plane function (UPF) network element and the data network (DN) network element on the core network (CN) side.

[0080] If terminal device 1 and terminal device 2 communicate, the traditional method is as follows Figure 1 As shown by the middle dotted line, the data of terminal device 1 first passes through RAN, then UPF of the core network, then DN, and then passes through UPF and RAN in sequence to terminal device 2. Among them, UPF can be located at a higher position, such as close to DN, or UPF can be located at a lower position, such as close to RAN. The closer UPF is to RAN, the smaller the delay of data transmission.

[0081] In the NR system, the communication path between terminal device 1 and terminal device 2 may not pass through DN, UPF, etc., for example Figure 1In the path represented by the solid line, the data of terminal device 1 only needs to pass through the physical (PHY) layer, media access control (MAC) layer and radio link control (RLC) layer on the RAN network side to be forwarded to terminal device 2. The above-mentioned method of directly forwarding locally through part of the protocol stack of the base station can be called RAN local switch, or RLCbased local switch. It should be understood that the RAN here may be a base station, that is, terminal device 1 and terminal device 2 belong to the coverage of the same base station; the RAN here may also be multiple base stations, that is, terminal device 1 and terminal device 2 belong to the coverage of different base stations respectively. For example, terminal device 1 corresponds to base station 1, and terminal device 2 corresponds to base station 2, then the data transmission path is terminal device 1->base station 1->base station 2->terminal device 2.

[0082] When terminal device 1 and terminal device 2 transmit data through RAN local forwarding, the user plane encryption of the data is mainly completed by the end-to-end packet data convergence protocol (PDCP) layer of terminal device 1 and terminal device 2, and gNB does not participate in the user plane data encryption. Specifically, terminal device 1 and terminal device 2 belong to the same terminal device group, and each terminal device in the terminal device group generates a common basic key: Session Group Key (Session Group Key) according to the key parameters provided by the core network, and uses the generated Session Group Key to encrypt the data.

[0083] The core network can provide key parameters to the terminal device 1 during the process of the terminal device 1 applying for the PDU session. Figure 2 As shown, the process includes:

[0084] S201. The core network obtains member information of a terminal device group, such as terminal device 1 and terminal device 2.

[0085] S202. Terminal device 1 initiates an application to the core network to establish a PDU session. The application carries indication information, indicating local forwarding by the RAN, or instructing the core network to configure a key parameter for local forwarding for terminal device 1. The key parameter is, for example, a count value (count).

[0086] S203: After receiving the PDU session request sent by terminal device 1, the core network configures count (the count of all terminal devices in the terminal device group is the same) and base station encryption parameters K of other members. AMF or KgNB Generate an intermediate key parameter Derpara for terminal device 1.

[0087] Specifically, the core network can AMF or K gNB and count generate corresponding Ktemp for each terminal device. AMF or K gNB can be different, so the Ktemp of each terminal device can be different; then the core network will XOR the Ktemp values ​​of all other terminal devices except terminal device 1 to generate Derpara, or the core network will directly calculate the Ktemp values ​​of all other terminal devices except terminal device 1. AMF or K gNB The values ​​are XORed to generate Derpara.

[0088] S204. The core network notifies the terminal device of the selected encryption algorithm based on the encryption algorithm supported by all terminal devices in the terminal device group.

[0089] S205. After the core network completes the establishment of the PDU session for the terminal device 1, the above-mentioned count value, Derpara and encryption algorithm are sent to the terminal device 1.

[0090] S206: The non-access stratum (NAS) of the terminal device 1 receives the K AMF 1 or K gNB 1. Count and Derpara generate a Session Group Key, and send the Session Group Key, security algorithm, etc. to the access stratum (AS). At the same time, the encryption algorithm indicated by the core network is sent to the AS layer, and the PDCP security mechanism is activated, so that the terminal device 1 encrypts / decrypts the data based on the Session Group Key and encryption algorithm when communicating end-to-end with members in the terminal device group.

[0091] Figure 3 The schematic diagram of the terminal device 1 generating the Session Group Key is shown. The terminal device 1 sends its own key K AMF 1 or K gNB 1. Based on the base station encryption parameters of other terminal devices in the terminal device group ( Figure 2 China AMF 2 or K gNB 2. K AMF 3 or K gNB3 as an example) and the count provided by the core network are XORed to obtain the Session Group Key.

[0092] In the above encryption scheme, since the core network provides the same value for count to all terminal devices in the terminal device group, the Session Group Key generated by all terminal devices in the terminal device group is the same, and it is only possible to update the Derpara and count of all terminal devices (i.e., update the Session Group Key) when new members join or leave the terminal device group. This leads to a problem: once the key parameter count on any terminal device in the terminal device group is cracked, the key parameter count of all terminal devices in the terminal device group will be cracked, posing a serious threat to data security.

[0093] To this end, an embodiment of the present application provides a key management method: the core network can provide different key parameters (such as count) to different terminal devices in a terminal device group, and / or the terminal device updates the key parameters of the terminal device according to its own mobility. When any terminal device pair in the terminal device group (for the convenience of description, the two communicating terminal devices are referred to as a "terminal device pair" in this article) needs to communicate, one terminal device in the terminal device pair (such as a communication initiator or a communication receiver) provides its own key parameters to the other terminal device, so that the two terminal devices in the terminal device pair use the same key parameters to generate a session key, and then use the same session key to encrypt and decrypt data, thereby ensuring the reliability of communication. At the same time, since different terminal devices can provide different key parameters, the session keys used by different terminal device pairs can be different, thereby avoiding the problem that the key parameters of any terminal device in the terminal device group are cracked, resulting in the key parameters of all terminal devices in the terminal device group being cracked, thereby improving the security of data.

[0094] It should be understood that in this document, the key parameter is taken as count. That is, unless otherwise specified, the key parameter in this document refers to count. That is, "key parameter" and "count" in this document can be replaced with each other.

[0095] Of course, the name count of the key parameter in this article is only an example. In specific implementation, the name of the key parameter may also be replaced with other names.

[0096] The technical solution of the embodiment of the present application can be applied to various communication systems, for example: global system of mobile communication (GSM) system, code division multiple access (CDMA) system, wideband code division multiple access (WCDMA) system, general packet radio service (GPRS), long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD), universal mobile telecommunication system (UMTS), worldwide interoperability for microwave access (WiMAX) communication system, fifth generation (5G) system, such as NR, and future communication systems, such as 6G system, etc. Of course, the technical solution of the embodiment of the present application can also be applied to other communication systems.

[0097] For example, Figure 4A A network architecture diagram applicable to an embodiment of the present application is shown, and the communication system includes: RAN device 1, terminal device 1 and terminal device 2. Among them, terminal device 1 and terminal device 2 belong to the same terminal device group, and terminal device 1 and terminal device 2 are both within the coverage of RAN device 1 (or terminal device 1 and terminal device 2 are both connected to RAN device 1). RAN device 1 can forward data from terminal device 1 to terminal device 2, and can also forward data from terminal device 2 to terminal device 1.

[0098] It should be understood that Figure 4A This is only an example of a communication system and is not limiting. In actual deployment, there may be more RAN devices and terminal devices in the communication system.

[0099] For example, Figure 4BAnother network architecture diagram applicable to an embodiment of the present application, the communication system includes: RAN device 1, RAN device 2, terminal device 1 and terminal device 2. Among them, terminal device 1 and terminal device 2 belong to the same terminal device group, terminal device 1 is within the coverage of RAN device 1 (or terminal device 1 is connected to RAN device 1), and terminal device 2 is within the coverage of RAN device 2 (or terminal device 2 is connected to RAN device 2). RAN device 1 and RAN device 2 can communicate with each other. RAN device 1 can forward data from terminal device 1 to RAN device 2, and then RAN device 2 forwards the data to terminal device 2. RAN device 2 can forward data from terminal device 2 to RAN device 1, and then RAN device 1 forwards the data to terminal device 1.

[0100] It should be understood that Figure 4B This is only an example of a communication system and is not limiting. In actual deployment, the communication system may have more RAN devices and terminal devices. For example, RAN device 1 and RAN device 2 may also have RAN device 3, and the communication between RAN device 1 and RAN device 2 is forwarded through RAN device 3. For example, the above communication system may also include a core network device.

[0101] Below, in conjunction with the drawings in the embodiments of the present application, the technical solutions in the embodiments of the present application are clearly and completely described. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0102] In order to make the embodiments of the present application clearer, some contents and concepts related to the embodiments of the present application are uniformly introduced here below.

[0103] 1) The terminal device involved in the embodiments of the present application, also referred to as a terminal, is an entity on the user side for receiving or transmitting signals, and is used to send uplink signals to network devices, or receive downlink signals from network devices. It includes devices that provide voice and / or data connectivity to users, for example, it may include a handheld device with a wireless connection function, or a processing device connected to a wireless modem. The terminal device can communicate with the core network via a radio access network (RAN) and exchange voice and / or data with the RAN. The terminal device may include user equipment (UE), V2X terminal equipment, wireless terminal equipment, mobile terminal equipment, device-to-device (D2D) terminal equipment, machine-to-machine / machine-type communications (M2M / MTC) terminal equipment, Internet of Things (IoT) terminal equipment, subscriber unit, subscriber station, mobile station, remote station, access point (AP), remote terminal, access terminal, user terminal, user agent, or user equipment, etc. For example, it may include a mobile phone (or "cellular" phone), a computer with a mobile terminal device, a portable, pocket-sized, handheld, or computer-built-in mobile device, etc. For example, personal communication service (PCS) phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDA), and other devices. It also includes limited devices, such as devices with low power consumption, or devices with limited storage capacity, or devices with limited computing power, etc. For example, it includes information sensing devices such as barcodes, radio frequency identification (RFID), sensors, global positioning systems (GPS), laser scanners, etc.

[0104] As an example but not limitation, in the embodiments of the present application, the terminal device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices or smart wearable devices, etc., which are a general term for the application of wearable technology to intelligently design and develop wearable devices for daily wear, such as glasses, gloves, watches, clothing and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also powerful functions achieved through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include full-featured, large-size, and independent of smartphones to achieve complete or partial functions, such as smart watches or smart glasses, etc., as well as those that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various types of smart bracelets, smart helmets, and smart jewelry for vital sign monitoring.

[0105] The various terminal devices introduced above, if located on a vehicle (eg, placed in or installed in a vehicle), can be considered as vehicle-mounted terminal devices, which are also called on-board units (OBU).

[0106] 2) The RAN device involved in the embodiment of the present application is a device that connects the terminal device to the wireless network in the communication system. The RAN device is a node in the wireless access network, which can also be called a base station or a wireless access network device. The RAN device may include an evolved base station (NodeB or eNB or e-NodeB, evolved NodeB) in a long term evolution (LTE) system or an advanced long term evolution (LTE-A), or may also include a next generation node B (next generation node B, gNB) or a next generation evolved base station (next generation evolvednodeB, ng-eNB), en-gNB (enhanced next generation node B, gNB) in a fifth generation mobile communication technology (the 5th generation, 5G) NR system: an enhanced next generation base station;

[0107] It may also include a centralized unit (CU) and a distributed unit (DU) in a cloud radio access network (Cloud RAN) system, or it may also include a relay device, which is not limited in the embodiments of the present application.

[0108] 3) The data network element involved in the embodiment of the present application may be the Internet, IP Multimedia Service (IMS) network, regional network (i.e., local network, such as mobile edge computing (MEC) network), etc. The data network includes an application server, and the application server provides business services to the terminal device by transmitting data with the terminal device.

[0109] 4) The access and mobility management function network element involved in the embodiment of the present application can be used to manage the access control and mobility of the terminal device. In practical applications, it includes the mobility management function in the mobility management entity (MME) in the network framework in long term evolution (LTE), and adds the access management function, which can be responsible for the registration of the terminal device, mobility management, tracking area update process, reachability detection, selection of session management function network element, mobile state transition management, etc. For example, in 5G, the access and mobility management function network element is an AMF (access and mobility management function) network element. In future communications, such as 6G, the access and mobility management function network element of the core network can still be AMF, or have other names, which is not limited in this application. When the core network access and mobility management function network element is AMF, the AMF can provide Namf services.

[0110] 5) The user plane function network element involved in the embodiment of the present application can be used for packet routing and forwarding, supporting uplink classifiers to route service flows to instances of data networks, supporting branch points to support multi-host packet data unit (PDU) sessions, user plane quality of service (QoS) processing, downlink data packet buffering and downlink data notification triggering, etc. For example, in 5G, the user plane function network element can be a UPF network element. In future communications, such as 6G, the user plane function network element can still be a UPF network element, or have other names, which are not limited in this application.

[0111] 6) The session management function network element involved in the embodiment of the present application can be used to be responsible for the session management of the terminal device (including the establishment, modification and release of the session), the selection and reselection of the user plane function network element, the allocation of the Internet Protocol (IP) address of the terminal device, QoS control, etc. For example, in 5G, the session management function network element is an SMF (session management function) network element. In future communications, such as 6G, the session management function network element can still be an SMF network element, or have other names, which are not limited in this application. When the session management function network element is an SMF network element, the SMF can provide Nsmf services.

[0112] 7) The terms "system" and "network" in the embodiments of the present application can be used interchangeably. The term "multiple" can be two, three or more, which is not limited in the embodiments of the present application. A positive integer can be one or more.

[0113] In addition, the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article, unless otherwise specified, generally means that the associated objects before and after are in an "or" relationship.

[0114] Unless otherwise specified, the ordinal numbers such as "first", "second", "third" and "fourth" mentioned in the embodiments of the present application are used to distinguish multiple objects and are not used to limit the order, timing, priority or importance of the multiple objects.

[0115] Figure 5 A key management method provided in the embodiment of the present application can be applied to Figure 4A or Figure 4B The wireless communication system shown in FIG. Figure 5 , the method comprising:

[0116] S501: A first terminal device determines a key parameter and an identifier of a destination terminal device.

[0117] S502: The first terminal device sends a key parameter and an identifier of a destination terminal device to the first RAN device, and the first RAN device receives the key parameter of the first terminal device and the identifier of the destination terminal device.

[0118] The key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other.

[0119] In the embodiment of the present application, the first terminal device may have multiple sets of key parameters at the same time, one of which is the key parameters provided by itself (key parameters used when it is a transmitter), and the others are provided to the first terminal device by other terminal devices (key parameters used when it is a receiver). In specific implementation, the first terminal device sends the key parameters provided by itself to the first RAN device.

[0120] In one possible implementation, the first terminal device is the communication initiator, and the destination terminal device is the communication receiver, that is, when two terminal devices that communicate with each other need to communicate, the communication initiator provides key parameters for both parties to encrypt / decrypt data. In another possible implementation, the destination terminal device is the communication initiator, and the first terminal device is the communication receiver, that is, when two terminal devices that communicate with each other need to communicate, the communication receiver provides key parameters for both parties to encrypt / decrypt data. The above two implementations can both ensure that the first terminal device and the destination terminal device use unified key parameters to encrypt / decrypt the transmitted data, thereby ensuring the reliability of communication. In the following description of this article, the technical solution of this application is mainly explained by taking the first terminal device as the communication initiator as an example.

[0121] In a possible implementation, the key parameter may be the key itself, or an encrypted key. In this way, after receiving the key parameter, the destination terminal device may directly obtain the key to encrypt / decrypt data, thereby improving communication efficiency.

[0122] In one possible implementation, the key parameters may be parameters required for the first terminal device and the destination terminal device to respectively generate session keys. In this way, the keys generated by the first terminal device and the destination terminal device may be unified by transmitting the key parameters, while at the same time directly transmitting the keys may be avoided, thereby improving the security of the keys.

[0123] Exemplarily, the first terminal device and the destination terminal device belong to the same terminal device group, the session key is specifically the Session Group Key, and the key parameter is a count value count used for the first terminal device and the destination terminal device to generate the Session Group Key respectively. It should be understood that in this article, the Session Group Key is only an example of a session key. In a specific implementation, the session group key may also have other forms or names, which are not limited in the embodiments of the present application. Similarly, for the key parameter, count is also only an example of a key parameter. In a specific implementation, it may also have other forms or names, which are not limited in the embodiments of the present application.

[0124] In one possible implementation, the core network may allocate an initial key parameter (such as an initial value of count) to the first terminal device, and the core network may allocate different initial key parameters to different terminal devices in the terminal device group where the first terminal device is located. In addition, the core network may also configure corresponding Derpara parameters for all terminal devices in the terminal device group.

[0125] For example, suppose the terminal device group includes UE1, UE2, UE3, and UE4. The core network allocates count 1 to UE1, count 2 to UE2, count 3 to UE3, and count 4 to UE4. The core network configures Derpara1 / Derpara2 / Derpara3 / Derpara4 for UE1 / UE2 / UE3 / UE4 respectively, where Derpara1 is based on the K of UE2. AMF 2 or K gNB 2. UE3's K AMF 3 or K gNB 3. UE4's K AMF 4 or K gNB 4, Derpara2 is generated based on UE1's K AMF 1 or K gNB 1.UE3 K AMF 3 or K gNB 3. UE4's K AMF 4 or K gNB 4, Derpara3 is based on UE1's K AMF 1 or K gNB 1. UE2 K AMF 2 or K gNB 2. UE4's K AMF 4 or K gNB 4, Derpara4 is based on UE1's K AMF 1 or K gNB 1. UE2 K AMF 2 or K gNB 2. UE3's K AMF 3 or K gNB 3. When UE1 and UE2 (the destination terminal device) communicate later, UE1 uses its own K AMF 1 or K gNB 1. The key parameter (count1) provided by itself and the Derpara parameter provided by the core network generate SessionGroup key1. UE2 generates SessionGroup key1 based on its own K AMF 2 or K gNB2. The key parameter (count value 1) provided by UE1 and the Derpara2 parameter provided by the core network generate Session Group key 2. According to the above principle of key generation, it can be ensured that Session Group key 1 and Session Group key 2 are the same, thereby ensuring normal communication between UE1 and UE2.

[0126] Similarly, when UE3 and UE4 (destination terminal device) communicate later, UE3 uses its own K AMF 3 or K gNB 3. The key parameter (count3) provided by itself and the Derpara parameter provided by the core network generate Session Group key3. UE4 generates Session Group key3 based on its own K AMF 4 or K gNB 4. The key parameter (count3) provided by UE3 and the parameter Derpara4 provided by the core network generate Session Group key4. According to the principle of key generation, it can be ensured that Session Group key3 and Session Group key4 are the same, thereby ensuring the normal communication between UE3 and UE4.

[0127] The above method can make the Session Group Key used by UE1 and UE2 different from the Session Group Key used by UE3 and UE4. In this way, different pairs of terminal devices in the same terminal device group can use different keys to communicate, which can improve data security.

[0128] In another possible implementation, the first terminal device may obtain the key parameters according to the initial key parameters assigned by the core network. For example, the first terminal device may update the key parameters according to its own mobility. For example, when the moving distance of the first terminal device exceeds a threshold (such as 500 meters), the value of the count of the first terminal device is +1, or, when a switch occurs to the base station / cell to which the first terminal device belongs, the value of the count of the first terminal device is +1. In this way, not only can the key parameters of different terminal device pairs in the terminal device group be different, but it can also avoid the same terminal device pair from using a key for a long time, which can further improve the security of the data.

[0129] S503: The first RAN device sends a key parameter and an identifier of the first terminal device to the destination terminal device.

[0130] Specifically, after the first RAN device receives the key parameter and the identifier of the destination terminal device from the first terminal device, it finds the destination terminal device according to the identifier of the destination terminal device and sends the key parameter to the destination terminal device, so that when the destination terminal device subsequently receives encrypted data from the first terminal device, it can generate a corresponding Session Group key based on the key parameter to decrypt the encrypted transmission data, or when subsequently sending data to the first terminal device, it can encrypt the transmission data based on the key parameter to ensure the security of the data communicated with the first terminal device.

[0131] In a specific implementation, in addition to the first terminal device, there may be other terminal devices that provide key parameters to the destination terminal device. Therefore, in order to enable the destination terminal device to distinguish these key parameters, when the first RAN sends the key parameters of the first terminal device (for the sake of ease of description, the key parameters provided by the first terminal device are referred to as first key parameters in this document), the first RAN may also send the identifier of the first terminal device to the destination terminal device, so that the destination terminal device can recognize that the first key parameters correspond to the first terminal device.

[0132] In a possible implementation, the terminal device may also save the first key parameter after receiving it, so that when the destination terminal device subsequently communicates with the first terminal device, the first terminal device does not need to repeatedly provide the first key parameter, thus saving system overhead.

[0133] As mentioned above, in a communication system, each terminal device may act as a communication initiator or a communication receiver, so the non-access layer of each terminal device may need to maintain multiple sets of key parameters, one of which is the key parameters when acting as a communication initiator, and the other sets are the key parameters when acting as communication receivers (i.e., terminal devices of other communication initiators). For example, assuming that UE1 communicates with UE2 as a communication initiator, and at the same time communicates with UE3 and UE4 as a communication receiver, UE1 not only needs to maintain count1 as a communication initiator, but also count3 as a communication initiator of UE3 and count4 as a communication initiator of UE4. Therefore, the destination terminal can sequentially save the first key parameter and the identifier of the first terminal device to distinguish which key parameters are provided by which terminal devices.

[0134] In a specific example, the destination terminal device may maintain a mapping table locally, in which the corresponding relationship between each terminal device and the key parameter provided by each terminal device is stored.

[0135] For example, as shown in Table 1, the key parameter provided by UE1 is count1, the key parameter provided by UE2 is count2, and the key parameter provided by UE3 is count3.

[0136] Table 1

[0137] Terminal equipment identification Key parameters UE1 count1 UE2 count2 UE3 count3 ...... ......

[0138] In the embodiment of the present application, the destination terminal device may be a single device or multiple terminal devices, and the embodiment of the present application does not impose any specific limitation.

[0139] The first type is that the destination terminal device is a single terminal device, such as the second terminal device.

[0140] The identifier of the destination terminal may be a first identifier of the second terminal device, where the first identifier includes a device identifier, such as an IP address, a MAC address, or an identifier of the first terminal device in its terminal device group.

[0141] Before the first RAN device sends the first key parameter and the identifier of the first terminal device to the destination terminal device, the first RAN device needs to determine the second identifier of the second terminal device according to the first identifier of the second terminal device, where the second identifier includes a cell-radio network temporary identifier (C-RNTI). Optionally, when each terminal device accesses the base station, it can send its own first identifier to the base station. After the base station assigns the second identifier to the terminal device, the base station and the terminal device respectively save the mapping relationship between the first identifier and the second identifier of the terminal device, so that when the first RAN device determines the second identifier of the second terminal device according to the first identifier of the second terminal device, it can quickly determine the second identifier of the second terminal device based on the mapping relationship.

[0142] After the first RAN device determines the second identifier of the second terminal device according to the first identifier of the second terminal device, the first RAN device sends the first key parameter and the identifier of the first terminal device to the second terminal device according to the C-RNTI of the second terminal device, where the identifier of the first terminal device can be the first identifier of the first terminal device.

[0143] The second type is that the destination terminal device is multiple terminal devices.

[0144] Correspondingly, the identifier of the destination terminal may include the first identifier of each terminal device among the multiple terminal devices. The first RAN device converts the first identifier of each terminal device among the multiple terminal devices into a second identifier, and then sends the first key parameter and the identifier of the first terminal device to each terminal device among the multiple terminal devices.

[0145] In a specific example, the multiple terminal devices may also be a terminal device group, and the identifier of the destination terminal may be the group identifier of the terminal device group. The first RAN device may send the first key parameter and the identifier of the first terminal device to the terminal device group via a multicast channel, wherein the multicast channel corresponds to the terminal device group.

[0146] In an embodiment of the present application, the destination terminal device and the first terminal device may be located within the coverage of the same RAN device (i.e., the first RAN device) (i.e., the co-site situation), or the destination terminal device and the first terminal device may be located within the coverage of different RAN devices (i.e., the cross-site situation).

[0147] The first type is that when the destination terminal device and the first terminal device are located at the same site, the first RAN device may directly send the first key parameter and the identifier of the first terminal device to the destination terminal device.

[0148] The second type is that when the destination terminal device and the first terminal device cross sites, the first RAN device needs to send the first key parameter and the identifier of the first terminal device to the destination terminal device via other RAN devices.

[0149] In a possible example, the first RAN device may send the identifier of the target terminal device to the surrounding RAN devices (i.e., the RAN devices in the neighboring area) and inquire which RAN device the target terminal device is located within the coverage area of. Assuming that the target terminal device is located within the coverage area of ​​the second RAN device, the second RAN device responds to the inquiry of the first RAN device. After the first RAN device learns that the target terminal device is located within the coverage area of ​​the second RAN device, the first RAN device sends the first key parameter, the identifier of the first terminal device, and the identifier of the target terminal device to the second RAN device, and then the second RAN device sends the first key parameter and the identifier of the first terminal device to the target terminal device. In this case, the coverage area of ​​the first RAN device and the coverage area of ​​the second RAN device at least partially overlap.

[0150] In another possible example, the first RAN device can periodically exchange the first identification of the terminal device it serves with the second RAN device. Then, when the first RAN device receives the first identification of the terminal device, it can determine the second RAN device corresponding to the first identification according to the content of the previous interaction between the devices. Of course, the above is only an example and not a limitation. In a specific implementation, the first RAN device can also send the first key parameter to the destination terminal device through more RAN devices.

[0151] In the embodiment of the present application, the terminal device and the RAN device communicate through a first protocol stack, and there is an end-to-end second protocol stack between the terminal devices.

[0152] Specifically, the first terminal device and the first RAN device communicate through the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack. If the first terminal device and the destination terminal device are in the same station, the destination terminal device and the first RAN device also communicate through the first protocol stack. If the first terminal device and the destination terminal device are across stations, such as the destination terminal device is located within the coverage of the second RAN device, the destination terminal device and the second RAN device also communicate through the first protocol stack. The first protocol stack includes at least a PHY layer, and may further include a MAC layer, an RLC layer, an adaptation layer, etc. The second protocol stack includes at least a PDCP layer, and may further include a service data adaptation protocol (SDAP) layer, an RLC layer or a MAC layer, etc. One possible scenario is that the first protocol stack includes a PHY layer, a MAC layer, an RLC layer, an adaptation layer, and the second protocol stack includes a PDCP layer.

[0153] In an embodiment of the present application, the process of the first terminal device transmitting the first key parameter to the destination terminal device through the RAN device can be implemented through a control plane (CP) transmission scheme or a user plane (UP) transmission scheme, which is not limited here.

[0154] Type 1: CP transmission solution

[0155] Exemplarily, the first terminal device first sends the first key parameter and the identifier of the destination terminal device to the first RAN device through an uplink RRC message. Of course, the uplink RRC message is only an example and not a limitation. In specific implementation, the first key parameter and the identifier of the destination terminal device can also be sent to the base station through other control plane transmission methods, such as carrying the first key parameter and the identifier of the destination terminal device in a MAC control element (CE), a PHY header, a MAC header, or an RLC header.

[0156] If the destination terminal device and the first terminal device are co-located, the first RAN device sends the first key parameter and the identifier of the first terminal device to the destination terminal device via a downlink RRC message.

[0157] If the destination terminal device and the first terminal device are across sites, for example, the destination terminal device is within the coverage of the second RAN device, the first RAN device may first send the key parameters, the identifier of the first terminal device, and the identifier of the destination terminal device to the second RAN device via an interface message (e.g., an XnAP message) between the first RAN device and the second RAN device, and then the second RAN device may send the key parameters and the identifier of the first terminal device to the destination terminal device via a downlink RRC message.

[0158] Type 2: UP transmission solution

[0159] Exemplarily, the first terminal device may send first data to the first RAN device, and the first encapsulation header encapsulated outside the first data includes a key parameter and an identifier of the destination terminal device, that is, the first data includes payload data and the first encapsulation header.

[0160] The first RAN receives the first data, parses the first data to obtain the key parameter and the identifier of the destination terminal device, and if the destination terminal device and the first terminal device are co-located, the first RAN device sends the second data to the destination terminal device, and the second data includes the payload data and the second encapsulation header. It should be understood that the first data and the second data here include the same payload data. The difference is that the encapsulation headers outside the first data and the second data are different, the first encapsulation header outside the first data includes the key parameter and the identifier of the destination terminal device, and the second encapsulation header outside the second data includes the key parameter and the identifier of the first terminal device.

[0161] If the destination terminal device and the first terminal device cross-site, such as the destination terminal device is within the coverage of the second RAN device, the first RAN device sends a user-side GPRS tunneling protocol user (GTP-U) data packet to the second RAN device, and the GTP-U packet header encapsulates the first key parameter, the identifier of the first terminal device and the identifier of the destination terminal device. The GTP-U data packet contains the payload data, and then the third data is sent to the destination terminal device through the second RAN device, and the third data contains the payload data and the third encapsulation header. The third encapsulation header outside the third data contains the first key parameter and the identifier of the first terminal device. It should be understood that the first data and the third data here contain the same payload data.

[0162] In specific implementation, both the control plane transmission solution and the user plane transmission solution may be implemented, but in different transmission phases.

[0163] Exemplarily, assuming that UE1 wants to communicate with the destination UE, and UE1 and the destination UE are covered by the same base station, UE1 can first send the first identifier and key parameters of the destination UE to the base station through an uplink RRC message; then the base station determines the second identifier of the destination UE (such as C-RNTI) according to the first identifier of the destination UE, and sends a downlink RRC message (or other MAC CE, or PHY header, MAC header or RLC header, etc.) according to the second identifier to tell the first identifier and key parameters of the first UE to the destination UE, and then the first UE can send a data packet to the destination UE. When UE1 sends a data packet to the destination UE through the base station, UE1 can carry the key parameters in each data packet, or send one or more data packets to carry the updated key parameters after the key parameters are updated, which is not limited in the embodiments of the present application.

[0164] When UE1 sends a data packet to the base station, the data packet may include the first identifier of the destination UE, and may also include the network slice identifier (ID) and / or QFI of the destination UE, and may also include the first identifier of the first UE.

[0165] See also Fig. 6A , is a schematic diagram of a possible user plane protocol stack. The protocol layers of the data packet include the PDCP layer, the adaptation layer, the RLC layer, the MAC layer, and the PHY layer from top to bottom. Among them, the adaptation layer can be used by the sending end to notify the receiving end which node the data packet comes from (such as the source UE identifier carried in the adaptation layer) and which node it needs to be sent to (such as the destination UE identifier carried in the adaptation layer). Optionally, the adaptation layer can also carry the network slice identifier (sliceID) of the destination node, the quality of service flow identifier (Quality of Service Flow ID, QFI), etc.

[0166] See also Figure 6B , is a schematic diagram of another possible user plane protocol stack, where the protocol layers of the data packet include, from top to bottom, an SDAP layer, a PDCP layer, an adaptation layer, an RLC layer, a MAC layer, and a PHY layer. Fig. 6A and Figure 6B The main difference is whether the adaptation layer of the data packet processed by the RAN device needs to carry QFI. In the case of no SDAP, QFI may be carried, such as Fig. 6A However, in the case of SDAP, since SDAP itself contains QFI, it does not need to be carried in the adaptation layer, such as Figure 6B shown.

[0167] It should be understood that the contents included in the adaptation layer of the first terminal device, the adaptation layer of the RAN device, and the adaptation layer of the destination terminal device may be different. For example: when the first terminal device sends a data packet to the RAN device, the first identifier, slice ID, QFI, etc. of the destination terminal device are all included in the adaptation layer of the data packet. The RAN device determines the C-RNTI based on the first identifier of the destination terminal device, and then determines the DRB based on the slice ID and / or QFI. Assuming that before this, the RAN device can send an RRC reconfiguration message to the destination terminal device, which includes a mapping relationship between slice ID and DRB, or a mapping relationship between QFI and DRB, or a mapping relationship between slice ID, QFI and DRB, then the RAN device here can determine the C-RNTI or DRB based on the above mapping relationship. When forwarding a data packet, the RAN device may delete the identifier of the destination terminal device in the data packet adaptation layer, retain the first identifier of the first terminal device (if the data packet sent by the first terminal device does not contain its own first identifier, the RAN device can find the first identifier corresponding to the first terminal device according to the C-RNTI of the first terminal device when forwarding, and add the first identifier of the first terminal device in the adaptation layer). It may also delete the slice ID in the adaptation layer and retain the QFI. The slice ID is deleted because the RAN device will tell the destination terminal device in the RRC configuration message which QFI of which slice corresponds to which DRB, so the destination terminal device may be able to determine which slice the data packet comes from. Retaining the QFI may be because the base station configures the reflective QoS mechanism for the destination terminal device at the beginning, that is, the destination terminal device needs to determine which QFI corresponds to which DRB based on the QFI contained in the downlink data packet. The destination terminal device can then determine which DRB the uplink data packet belongs to based on the mapping relationship between the QFI obtained in the downlink and the DRB.

[0168] See also Figure 6C , is a schematic diagram of another possible user plane protocol stack, such as Figure 6C As shown, above the PDCP layer is the application (APP) layer, which is used to generate the payload data that UE1 wants to send to UE2. The protocol layer between UE1 and gNB is the adaptation / RLC / MAC / PHY layer, and the protocol layer between UE2 and gNB is the adaptation / RLC / MAC / PHY layer. When UE1 sends a data packet to gNB, it encapsulates the adaptation / RLC / MAC / PHY header outside the data packet in sequence.

[0169] In one possible design, the first terminal device can obtain the first key parameter in the process of applying for a PDU session from the core network.

[0170] For example, UE1 may apply to the core network for a PDU session, which is subsequently used for RAN local forwarding communications. When UE1 initiates a PDU session application to the core network, the application may include one or more of a UE group identifier, a slice identifier, and a RAN local forwarding identifier. After receiving the application, the core network identifies that UE1 belongs to a certain UE group or a certain slice based on the RAN local forwarding identifier, and then forwards the K of other UEs in the UE group or applying for the slice service. AMF or K gNB XOR synthesizes Derpara, and sends Derpara, count1, security algorithm, etc. to UE1. It should be understood that count1 here can be configured by the core network specifically for UE1, and the count value configured by the core network for other UEs can be different from count1. UE2 applies to the core network to establish a PDU session application, and the core network performs similar operations.

[0171] After UE1 receives the key parameters (such as Derpara, count1, and security algorithm) provided by the core network, the non-access layer of UE1 converts UE1's K AMF 1 or K gNB 1. Send Derpara, count1, etc. to the AS layer of UE1, or send K AMF 1 or K gNB 1 and Derpara are XORed and the parameters and count values ​​are sent to the AS layer, or they can be sent as Figure 3 After the Session Group Key is generated by the method shown, the Session Group Key is directly sent to the AS layer. In addition, the NAS layer of UE1 can also provide the corresponding PDU session identifier to the AS layer, so that UE1 knows which PDU session needs to use the key or key parameter provided by the above NAS layer. When UE1 subsequently receives the RRC reconfiguration message of the base station, the RRC reconfiguration message may include DRB and the SDAP-Config corresponding to the DRB, and the SDAP-Config may include the PDU session identifier, so that UE1 can obtain the PDU session identifier corresponding to the DRB according to the RRC reconfiguration message. When UE1 conducts a subsequent PDU session, the PDU session identifier of this session is compared with the PDU session identifier provided by the previous NAS layer. If they are the same, the end-to-end key or key parameter provided by the NAS layer is used, otherwise the traditional encryption mechanism is executed (for example, the key parameter agreed upon by UE1 and the base station is used for encryption / decryption). In addition, UE1 can determine which DRBs use the end-to-end key or key parameter provided by the NAS layer and which DRBs use the traditional encryption mechanism based on the mapping relationship between the PDU session identifier and the DRB.

[0172] The above implementation modes can be combined with each other to achieve different technical effects.

[0173] In order to better understand the technical solutions of the embodiments of the present application, two specific embodiments are listed below to provide a more detailed description of the technical solutions of the present application.

[0174] Example 1

[0175] This embodiment describes a process in which UE1 provides count1 to UE2 when UE1 and UE2 are located at the same station.

[0176] Solution 1: See Figure 7 , UE1 transmits count1 to UE2 through the CP plane.

[0177] S701, UE1 notifies gNB through an uplink RRC message which target UE (such as UE2) it wants to communicate with, and the specific method may be to send the target UE identifier (target ID) and UE1's key parameter count1 to gNB. Optionally, the uplink RRC message may also carry slice ID, QoS flow identifier QFI, etc., so that gNB does not need to initiate an additional process to obtain information such as slice ID, QoS flow identifier QFI, etc., which can help gNB more quickly determine which bearer to forward the subsequent data transmitted through the user plane to UE2, thereby improving data transmission efficiency.

[0178] The target ID may be an IP address, a MAC address, etc. of UE2, and the target ID is referred to herein as the first identifier for RAN local forwarding. If UE1 wishes to communicate with a group of UEs, the target ID may also be a UE group identifier.

[0179] S702. The gNB determines the C-RNTI and DRB identifier corresponding to the target UE according to the target UE identifier and the slice identifier. Optionally, the gNB may also need to identify the identifier of the source UE.

[0180] In an embodiment of the present application, all UEs can first report the first identifier to the gNB when accessing the gNB, and then the gNB can assign a second identifier, such as a C-RNTI, to each UE. The gNB can thereby obtain and save the mapping relationship between the first identifier and the second identifier of each UE. When the gNB receives a message sent by UE1, it can determine the first identifier of UE1 based on the C-RNTI of UE1. When UE1 informs the gNB that it hopes to communicate with UE2 (the first identifier of UE2), the gNB can find the second identifier corresponding to UE2, and then send the data packet to UE2 of the second identifier through the air interface.

[0181] In the case where UE1 communicates with a UE group, when the UE accesses the gNB, it not only sends the first identifier to the gNB, but also sends the UE group identifier to which the UE belongs to the gNB, or the operation, administration and maintenance (OAM) sends the UE group identifier and the first identifier of each member of the UE group to the gNB, or the AMF of the core network sends the UE group identifier and the first identifier of each member of the UE group to the gNB. In this way, when UE1 notifies the gNB that it wants to communicate with a UE group, the gNB can send the data of UE1 to all members in the UE group by unicast or multicast.

[0182] After the gNB determines that the target UE that UE1 needs to communicate with is UE2, it also needs to determine which data radio bearer DRB of UE2 to send the data packet from UE1. Specifically, the gNB can determine which DRB of UE2 based on information such as the UE group identifier, slice identifier, or QFI. Optionally, when UE2 establishes a DRB, the mapping relationship between the DRB and the UE group identifier, or the mapping relationship between the DRB and the slice, or the mapping relationship between the DRB and the QFI list can be specified in the RRC reconfiguration message of the gNB, so that the gNB can directly determine the DRB of UE2 based on the mapping relationship.

[0183] S703. gNB notifies UE2 of count1 and the first identifier of UE1 through a downlink RRC reconfiguration message or downlink control information (DCI) or other protocol layer messages.

[0184] Option 2: See Figure 8 , UE1 transmits count1 to UE2 through the UP plane.

[0185] S801. UE1 sends a data packet to gNB, which carries count1, the identifier of the target UE with which UE1 wishes to communicate (such as the identifier of UE2), etc.

[0186] When UE1 sends a data packet to gNB, it can follow Figure 6C The protocol stack shown in the figure encapsulates the adaptation / RLC / MAC / PHY header outside the data packet in sequence. Optionally, the first identifier of UE2 and the value of the key parameter count1 may be included in the adaptation layer, and other parameters such as slice identifier, QFI, etc. may also be included.

[0187] S802. After receiving the data packet sent by UE1, gNB obtains the first identifier of UE2 from the adaptation layer of the data packet. Optionally, if there are other parameters such as slice identifier and QFI in the adaptation layer, the C-RNTI of UE2 and the corresponding DRB can be determined according to the slice identifier and QFI.

[0188] S803. When gNB forwards the data packet from UE1 to UE2, it removes the identifier of UE2 in the original adaptation layer (optionally, if the original adaptation layer still contains slice identifier, QFI, etc., it can also remove the slice identifier, QFI, etc.); it encapsulates the new adaptation / RLC / MAC / PHY layers in sequence outside, and includes the first identifier of UE1 and the key parameter count1 in the new adaptation layer.

[0189] S804. When UE2 receives the data packet forwarded by the gNB, it obtains the first identifier of UE1 as count1 from the adaptation layer.

[0190] In this embodiment, UE1 may carry count1 in each data packet sent to UE2, or send one or more count values ​​when count1 changes, or stop carrying count1 in the data packet when receiving feedback from UE2 indicating that UE2 has received count1.

[0191] Example 2

[0192] This embodiment describes the process in which UE1 provides count1 to UE2 when UE1 and UE2 cross sites. Assume that UE1 is within the coverage of gNB1 and UE2 is within the coverage of gNB2. UE1 wants to communicate with UE2. Fig. 9 As shown, the method includes:

[0193] S901, UE1 sends the first identifier of UE2, count1, etc. to gNB1 through the CP plane or the UP plane. For the specific implementation method, please refer to the specific implementation method of S701 or S801 in Example 1, which will not be repeated here.

[0194] S902. gNB1 sends the first identifier of UE1, the first identifier of UE2, and count1 to gNB2 through the CP plane or the UP plane.

[0195] First, based on the first identifier of UE2, gNB1 finds that UE2 is not in its coverage area, but in the coverage area of ​​gNB2. One possible scenario is that gNB1 sends the first identifier of UE2 to the surrounding neighboring cells for inquiry, and finally determines that UE2 is in the coverage area of ​​gNB2; another possible scenario is that gNBs regularly exchange the first identifiers of UEs in their coverage areas, and finally determine that UE2 is in the coverage area of ​​gNB2. Another possibility is that the gNB reports the first identifiers of UEs in its coverage area to the core network. When the gNB wants to obtain the gNB where a certain UE is located, it initiates an inquiry to the core network.

[0196] Then, gNB1 encapsulates the GTP-U header outside the data packet from UE1, and finally sends the entire GTP-U data packet to gNB2 through the GTP-U tunnel between gNB1 and gNB2. The above-mentioned first identifier of UE1, first identifier of UE2, count1, etc. can all be encapsulated in the header of the GTP-U data packet. Of course, gNB1 can also inform gNB2 of the first identifier of UE1, first identifier of UE2, count1, etc. through the CP plane message between gNB1 and gNB2, such as XnAP message. For example, gNB1 sends an XnAP message such as a direct communication request message to gNB2, which contains the first identifier of UE1, the first identifier of UE2, count1, etc.

[0197] It should be understood that the information sent by gNB1 to gNB2 may also include the slice ID, UE group identifier, QFI, etc. provided by UE1, which is not limited here.

[0198] S903, after receiving the above information through the CP plane or UP plane message, gNB2 transmits the first identifier of UE1, count1, etc. to UE2 through the CP plane or UP plane. The specific implementation method can refer to the specific implementation method of S703 or S803 in Example 1, which will not be repeated here.

[0199] The key management method provided in the embodiment of the present application is introduced above, and the communication device used to implement the above method in the embodiment of the present application is introduced below in conjunction with the accompanying drawings. Therefore, the above contents can be used in subsequent embodiments, and repeated contents will not be repeated.

[0200] Based on the same technical concept, see Fig.10 The embodiment of the present application provides a communication device 1000, which may be the first RAN device in the above method embodiment, or a device in the first RAN device, and the device 1000 includes:

[0201] The receiving module 1001 is used to receive a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0202] The sending module 1002 is used to send the key parameter and the identifier of the first terminal device to the destination terminal device.

[0203] In a possible implementation manner, the destination terminal device is located within the coverage of the first RAN device.

[0204] In a possible implementation manner, the destination terminal device is located within the coverage of a second RAN device; and the sending module 1002 is specifically configured to: send the key parameter and the identifier of the first terminal device to the destination terminal device through the second RAN device.

[0205] In a possible implementation manner, the first terminal device and the first RAN device communicate through a first protocol stack, the destination terminal device and the first RAN device communicate through the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer, and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer, and a MAC layer.

[0206] In a possible implementation manner, the key parameters are parameters required for the first terminal device and the destination terminal device to respectively generate session keys.

[0207] In a possible implementation manner, the receiving module 1001 is specifically configured to: the first RAN device receives first data sent by a first terminal device, wherein an encapsulation header encapsulated outside the first data includes the key parameter and an identifier of the destination terminal device.

[0208] In a possible implementation manner, the sending module 1002 is specifically configured to: send second data to the destination terminal device, wherein an encapsulation header outside the second data includes the key parameter and an identifier of the first terminal device.

[0209] In a possible implementation, the sending module 1002 is specifically used to: send a user-plane General Radio Packet Service Tunneling Protocol GTP-U data packet to a second RAN device, wherein the GTP-U packet header carries the key parameters, the identifier of the first terminal device, and the identifier of the destination terminal device, and the GTP-U data packet contains the first data, and the key parameters and the identifier of the first terminal device are sent to the destination terminal device through the second RAN device.

[0210] In a possible implementation manner, the identifier of the destination terminal device includes a first identifier of the second terminal device;

[0211] The device 1000 further includes:

[0212] The processing module 1003 is used to determine the second identifier of the second terminal device according to the first identifier of the second terminal device before the sending module 1002 sends the key parameter and the identifier of the first terminal device to the destination terminal device; wherein the first identifier includes a device identifier, and the second identifier includes a cell radio network temporary identifier C-RNTI;

[0213] The sending module 1002 is specifically configured to send the key parameter and the identifier of the first terminal device to the second terminal device according to the second identifier of the second terminal device.

[0214] In a possible implementation manner, the identifier of the destination terminal device includes a group identifier of a terminal device group to which the first terminal device belongs;

[0215] The sending module 1002 is specifically configured to: the first RAN device sends the key parameter and the identifier of the first terminal device to the terminal device group through a multicast channel, wherein the multicast channel corresponds to the terminal device group.

[0216] Based on the same technical concept, see Fig.11 The present application embodiment provides a communication device 1100, which may be the first terminal device in the above method embodiment, or a device in the first terminal device, and the device 1100 includes:

[0217] The processing module 1101 is used to determine a key parameter and an identifier of a destination terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0218] The sending module 1102 is configured to send the key parameter and the identifier of the destination terminal device to the first radio access network RAN ​​device.

[0219] In a possible implementation manner, the destination terminal device is located within the coverage of the first RAN device.

[0220] In a possible implementation manner, the destination terminal device is located within the coverage of the second RAN device.

[0221] In a possible implementation manner, the first terminal device and the first RAN device communicate through a first protocol stack, the destination terminal device and the first RAN device communicate through the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer, and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer, and a MAC layer.

[0222] In a possible implementation manner, the key parameters are parameters required for the first terminal device and the destination terminal device to respectively generate session keys.

[0223] In a possible implementation manner, the sending module 1102 is specifically configured to: send first data to a first radio access network RAN ​​device, wherein an encapsulation header encapsulated outside the first data includes the key parameter and an identifier of the destination terminal device.

[0224] In a possible implementation manner, the identifier of the destination terminal device includes a first identifier of the second terminal device, and the first identifier includes a device identifier.

[0225] In a possible implementation manner, the identifier of the destination terminal device includes a group identifier of a terminal device group to which the first terminal device belongs.

[0226] Based on the same technical concept, see Fig.12 The embodiment of the present application provides a communication device 1200, which may be the second RAN device in the above method embodiment, or a device in the second RAN device, and the device 1200 includes:

[0227] The receiving module 1201 is configured to receive a key parameter, an identifier of a first terminal device, and an identifier of a destination terminal device sent by a first RAN device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other;

[0228] The sending module 1202 is used to send the key parameter and the identifier of the first terminal device to the destination terminal device.

[0229] In a possible implementation, the destination terminal device and the second RAN device communicate through a first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; wherein the first protocol stack includes a physical PHY layer, a medium access control MAC layer and a radio link control RLC layer; and the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer and a MAC layer.

[0230] In a possible implementation manner, the key parameters are parameters required for the first terminal device and the destination terminal device to respectively generate session keys.

[0231] In a possible implementation, the receiving module 1201 is specifically used to: receive a user-plane General Radio Packet Service Tunneling Protocol GTP-U data packet sent by a first RAN device, wherein the GTP-U packet header carries the key parameters, the identifier of the first terminal device, and the identifier of the destination terminal device.

[0232] In a possible implementation manner, the sending module 1202 is specifically configured to: send third data to the destination terminal device, wherein an encapsulation header outside the third data includes the key parameter and an identifier of the first terminal device.

[0233] In a possible implementation manner, the identifier of the destination terminal device includes a first identifier of the second terminal device;

[0234] The apparatus 1200 further includes a processing module 1203, which is used to determine a second identifier of the second terminal device according to the first identifier of the second terminal device before the sending module 1202 sends the key parameter and the identifier of the first terminal device; wherein the first identifier includes a device identifier, and the second identifier includes a cell radio network temporary identifier C-RNTI;

[0235] The sending module 1202 is specifically configured to send the key parameter and the identifier of the first terminal device to the second terminal device according to the second identifier of the second terminal device.

[0236] In one possible implementation, the identifier of the destination terminal device includes the group identifier of the terminal device group to which the first terminal device belongs; the sending module 1202 is specifically used to: send the key parameters and the identifier of the first terminal device to the terminal device group via a multicast channel, wherein the multicast channel corresponds to the terminal device group.

[0237] Based on the same technical concept, see Fig.13The present application embodiment provides a communication device 1300, which may be the destination terminal device in the above method embodiment, or a device in the destination terminal device, and the device 1300 includes:

[0238] The receiving module 1301 is configured to receive a key parameter and an identifier of a first terminal device sent by a first RAN device or a second RAN device;

[0239] The processing module 1302 is used to encrypt and / or decrypt the transmission data using the key parameters when the destination terminal device and the first terminal device communicate with each other.

[0240] Based on the same technical concept, see Fig.14 , an embodiment of the present application provides a communication device 1400, including:

[0241] at least one processor 1401; and

[0242] A memory 1402 is communicatively connected to the at least one processor 1401; wherein the memory 1402 stores instructions that can be executed by the at least one processor 1401, and the at least one processor 1401 executes the instructions stored in the memory 1402 to perform the following steps: Figure 5 , Figure 7 , Figure 8 or Fig. 9 The method of the embodiment shown in .

[0243] Among them, the processor 1401 can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware processor to be executed, or can be executed by a combination of hardware and software modules in the processor.

[0244] Among them, the memory 1402 can be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., and can also be a volatile memory (volatile memory), such as a random access memory (RAM). The memory is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this. The memory in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0245] Optionally, the apparatus 1400 may further include a communication interface 1403. The communication interface 1403 is used for the apparatus 1400 to communicate with other modules, and may be a circuit, a device, an interface, a bus, a software module, a transceiver or any other device capable of implementing communication.

[0246] It should be noted that the specific connection medium between the communication interface 1403, the processor 1401 and the memory 1402 is not limited in the embodiment of the present application. Fig.14 The communication interface 1403, the processor 1401 and the memory 1402 are connected via a bus 1404. Fig.14 The connections between the other components are shown in bold lines, which are only for illustration and are not intended to be limiting. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.14 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0247] Based on the same technical concept, the embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a computer, the computer executes the following Figure 5 , Figure 7 , Figure 8 or Fig. 9 The method of the embodiment shown in .

[0248] Based on the same technical concept, the embodiment of the present application further provides a chip, which is coupled to a memory and is used to read and execute program instructions stored in the memory to implement the following Figure 5 , Figure 7 , Figure 8 or Fig. 9 The method of the embodiment shown in .

[0249] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0250] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0251] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0252] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0253] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0254] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of protection of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A key management method, characterized in that: include: The first radio access network RAN ​​device receives a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; wherein the key parameter is determined by the first terminal device; The first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device.

2. The method according to claim 1, characterized in that The destination terminal device is located within the coverage area of ​​the first RAN device.

3. The method according to claim 1, characterized in that The destination terminal device is located within the coverage of the second RAN device; The first RAN device sending the key parameter and the identifier of the first terminal device to the destination terminal device includes: The first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device through the second RAN device.

4. The method according to claim 1, characterized in that The first terminal device and the first RAN device communicate via a first protocol stack, the destination terminal device and the first RAN device communicate via the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; The first protocol stack includes a physical PHY layer, a medium access control MAC layer and a radio link control RLC layer; the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer and a MAC layer.

5. The method according to claim 1, characterized in that The key parameters are parameters required for the first terminal device and the destination terminal device to generate session keys respectively.

6. The method according to claim 1, characterized in that The first RAN device receives the key parameter and the identifier of the destination terminal device sent by the first terminal device, including: The first RAN device receives first data sent by a first terminal device, wherein an encapsulation header encapsulated outside the first data includes the key parameter and an identifier of the destination terminal device.

7. The method according to claim 6, characterized in that The first RAN device sending the key parameter and the identifier of the first terminal device to the destination terminal device includes: The first RAN device sends second data to the destination terminal device, wherein an encapsulation header outside the second data includes the key parameter and an identifier of the first terminal device.

8. The method according to claim 6, characterized in that The first RAN device sending the key parameter and the identifier of the first terminal device to the destination terminal device includes: The first RAN device sends a user plane General Radio Packet Service Tunneling Protocol GTP-U data packet to the second RAN device, wherein the GTP-U packet header carries the key parameters, the identifier of the first terminal device and the identifier of the destination terminal device, and the GTP-U data packet contains the first data, and the key parameters and the identifier of the first terminal device are sent to the destination terminal device through the second RAN device.

9. The method according to any one of claims 1 to 8, characterized in that: The identifier of the destination terminal device includes the first identifier of the second terminal device; Before the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device, the method further includes: Determine a second identifier of the second terminal device according to the first identifier of the second terminal device; wherein the first identifier includes a device identifier, and the second identifier includes a cell radio network temporary identifier C-RNTI; The first RAN device sending the key parameter and the identifier of the first terminal device to the destination terminal device includes: The first RAN device sends the key parameter and the identifier of the first terminal device to the second terminal device according to the second identifier of the second terminal device.

10. The method according to any one of claims 1 to 8, characterized in that The identifier of the destination terminal device includes a group identifier of a terminal device group to which the first terminal device belongs; The first RAN device sending the key parameter and the identifier of the first terminal device to the destination terminal device includes: The first RAN device sends the key parameter and the identifier of the first terminal device to the terminal device group through a multicast channel, wherein the multicast channel corresponds to the terminal device group.

11. A key management method, characterized in that: include: The first terminal device determines a key parameter and an identifier of a destination terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; The first terminal device sends the key parameter and the identifier of the destination terminal device to a first radio access network RAN ​​device, so that the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device.

12. The method according to claim 11, characterized in that The destination terminal device is located within the coverage area of ​​the first RAN device.

13. The method according to claim 11, characterized in that The destination terminal device is located within the coverage area of ​​the second RAN device.

14. The method according to claim 11, characterized in that The first terminal device and the first RAN device communicate via a first protocol stack, the destination terminal device and the first RAN device communicate via the first protocol stack, and the first terminal device and the destination terminal device have an end-to-end second protocol stack; The first protocol stack includes a physical PHY layer, a medium access control MAC layer and a radio link control RLC layer; the second protocol stack includes a packet data convergence protocol PDCP layer, a service data adaptation protocol SDAP layer, an RLC layer and a MAC layer.

15. The method according to claim 11, characterized in that The key parameters are parameters required for the first terminal device and the destination terminal device to generate session keys respectively.

16. The method according to claim 11, characterized in that The first terminal device sends the key parameter and the identifier of the destination terminal device to the first radio access network RAN ​​device, including: The first terminal device sends first data to a first radio access network RAN ​​device, wherein an encapsulation header encapsulated outside the first data includes the key parameter and an identifier of the destination terminal device.

17. The method according to any one of claims 11 to 16, characterized in that: The identifier of the destination terminal device includes a first identifier of a second terminal device, and the first identifier includes a device identifier.

18. The method according to any one of claims 11 to 16, characterized in that: The identifier of the destination terminal device includes the group identifier of the terminal device group to which the first terminal device belongs.

19. A key management method, characterized in that: include: The destination terminal device receives the key parameter and the identifier of the first terminal device sent by the first RAN device or the second RAN device; wherein the key parameter is determined by the first terminal device; When the destination terminal device and the first terminal device communicate with each other, the key parameters are used to encrypt and / or decrypt the transmission data.

20. A communication device, characterized in that: include: A receiving module, configured to receive a key parameter and an identifier of a destination terminal device sent by a first terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; wherein the key parameter is determined by the first terminal device; A sending module is used to send the key parameter and the identifier of the first terminal device to the destination terminal device.

21. A communication device, characterized in that: include: a processing module, configured to determine a key parameter and an identifier of a destination terminal device, wherein the key parameter is used to encrypt and / or decrypt transmission data when the first terminal device and the destination terminal device communicate with each other; The sending module is used to send the key parameter and the identifier of the destination terminal device to a first radio access network RAN ​​device, so that the first RAN device sends the key parameter and the identifier of the first terminal device to the destination terminal device.

22. A communication device, characterized in that: include: A receiving module, configured to receive a key parameter and an identifier of a first terminal device sent by a first RAN device or a second RAN device; wherein the key parameter is determined by the first terminal device; A processing module is used to encrypt and / or decrypt transmission data using the key parameters when the first terminal device and the communication apparatus communicate with each other.

23. A communication device, characterized in that: include: at least one processor; as well as a memory and / or a communication interface communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the at least one processor executes the method as described in any one of claims 1-10, 11-18, and 19 by executing the instructions stored in the memory.

24. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a computer, the computer executes the method according to any one of claims 1-10, 11-18, and 19.

25. A chip, characterized in that: The chip is coupled to the memory and is used to read and execute program instructions stored in the memory to implement the method as described in any one of claims 1-10, 11-18, and 19.

Images