CN116634426A - Communication method and device - Google Patents

Abstract

The application relates to the technical field of wireless communication, and provides a communication method and device for avoiding security verification errors. The terminal equipment in the inactive state determines a first key under the condition that the first type of data arrives; the first key is used for transmitting the first type of data by the terminal device in an inactive state. Under the condition that the second type data arrives is determined, a second key is determined, and an RRC request message is sent to the access network equipment; the second key is used for transmitting the second type of data in the connected state by the terminal device. Before receiving the RRC response message from the access network device, the terminal device receives first-class data from the access network device, and performs security verification on the first-class data by adopting a first key. Since the first key is still used to perform security verification on the downlink data before the response message of the second RRC request message is received, no security verification error occurs if the downlink first type data is received.

Description

Communication method and device

Technical Field

The present application relates to the field of wireless communications, and in particular, to a method and apparatus for communication.

Background

When the terminal device in an inactive (inactive) state has uplink data to be transmitted, the terminal device initiates a radio resource control (radio resource control, RRC) recovery procedure. After receiving the RRC restoration message, the terminal device restores the RRC connection, and changes from the Inactive state to the Connected state, and performs uplink data transmission, which results in lower service data transmission efficiency. Based on this, further discussed in the standard, no transition from the Inactive state to the Connected state is required for small data transfers (small data transmission, SDT) in the Inactive state; however, for non-SDT (non-SDT) data, the terminal device still needs to switch from the Inactive state to the Connected state to perform data transmission.

When the terminal equipment in the Inactive state has SDT data to be sent, the terminal equipment triggers a first RRC connection recovery process. In the first RRC connection recovery process, the terminal device and the base station derive a first key to perform security protection on uplink and downlink data. If the terminal device has non-SDT data to send before receiving the RRC release message, the terminal device can trigger a second RRC connection recovery process. In the second RRC connection recovery process, the terminal device and the base station derive a new second key to perform security protection on uplink and downlink data.

However, if the terminal device sends the RRC connection resume request message for the second time, the access network device has cached some downlink data, which may be security protected using the first key that was pushed during the first RRC connection resume procedure. After receiving the downlink data, the terminal device performs security verification by using the second key newly generated in the second RRC connection recovery process, so that security verification errors may be caused.

Disclosure of Invention

The embodiment of the application provides a communication method and a communication device, which are used for avoiding security verification errors.

In a first aspect, a communication method is provided, where the method may be performed by a terminal device, or may be a component applied in the terminal device, such as a chip, a processor, or the like. The following describes an example in which the execution subject is a terminal device. Firstly, under the condition that the terminal equipment in an inactive state determines that first type data arrives, determining a first key; the first key is used for transmitting the first type of data under the inactive state by the terminal equipment. Then, the terminal equipment determines a second key and sends an RRC request message to the access network equipment under the condition that the second class data arrives; the second key is used for transmitting the second type of data by the terminal equipment in a connection state; the RRC request message is used to request recovery of the RRC connection. Then, before receiving the RRC response message from the access network equipment, the terminal equipment receives first-class data from the access network equipment, and performs security verification on the first-class data by adopting the first key; the RRC response message is used for responding to the RRC request message.

After the terminal device sends the second RRC request message, before receiving a response message (e.g., RRC restore or RRC release message) of the second RRC request message, if the downlink first type data is received, the terminal device still uses the first key to perform security verification on the downlink first type data, so that security verification errors cannot occur, and further, wrong data can be prevented from being delivered to an upper layer.

In a second aspect, a communication method is provided, where the method may be performed by a terminal device, or may be a component applied in the terminal device, such as a chip, a processor, or the like. The following describes an example in which the execution subject is a terminal device. Firstly, under the condition that the terminal equipment in an inactive state determines that first type data arrives, determining a first key; the first key is used for transmitting the first type of data under the inactive state by the terminal equipment. Then, the terminal equipment determines a second key and sends an RRC request message to the access network equipment under the condition that the second class data arrives; the second key is used for transmitting the second type of data by the terminal equipment in a connection state; the RRC request message is used to request recovery of the RRC connection. In this way, before receiving the RRC response message from the access network device, the terminal device receives first type data from the access network device, and discards the first type data; the RRC response message is used for responding to the RRC request message.

If the terminal device receives the downlink data after sending the second RRC request message and before receiving the response message of the second RRC request message, the terminal device directly discards the downlink data, so that security verification errors do not occur, and further, wrong data can be prevented from being delivered to an upper layer.

In a third aspect, a communication method is provided, where the execution subject of the method may be a centralized unit CU, or may be a component, such as a chip, a processor, etc., applied in the centralized unit CU. The following describes an example in which the execution subject is a centralized unit CU. First, the centralized unit CU determines a first key in case of receiving a first RRC request message from the DU; the first RRC request message is from a terminal device in an inactive state, the first RRC request message is used for requesting to recover RRC connection, and the first key is used for transmitting first type data with the terminal device in the inactive state. Then, the centralized unit CU receives a second RRC request message from the DU, determining a second key; the second RRC restoration request message is from the terminal device in the inactive state, the second RRC request message is used for requesting restoration of RRC connection, and the second key is used for transmitting second class data with the terminal device in the connected state. Next, after sending the first indication information to the DU, the centralized unit CU sends an RRC response message of the second RRC request message to the DU; the first indication information is used for indicating the DU to clear the first type of data.

In the prior art, if there is buffered downlink data on the DU side, the data will be sent to the terminal device in the inactive state. However, since the buffered downlink data is secured by the first key, and the UE has determined the second key before sending the second RRC request message, if the buffered downlink data is continued to be sent to the UE, a security verification error on the UE side may be caused. In this example, after receiving the second RRC request message, the CU instructs the DU to delete the buffered downlink data, avoiding wasting transmission resources, and also avoiding UE security verification errors.

In one possible implementation, the CUs include a control plane CU and a user plane CU; transmitting first indication information to the DU includes: the user plane CU sends first indication information to the DU; or, the control plane CU sends first indication information to the DU.

In one possible implementation, the user plane CU sends first indication information to the DU, including: the user plane CU sends a downlink user data message to the DU, wherein the downlink user data message comprises the first indication information.

In one possible implementation, the control plane CU sends first indication information to the DU, including: the control plane CU sends a UE context setup request message to the DU, the UE context setup request message including the first indication information.

In a fourth aspect, a communication method is provided, where the method may be implemented by a new service access network device, or by a component, such as a chip, a processor, etc., applied in the new service access network device. The following description will take an example in which the execution subject is a new service access network device. First, the new serving access network device receives a first radio resource control RRC request message from the terminal device in an inactive state, the first RRC request message being for requesting recovery of an RRC connection. Then, the new service access network device receives a second RRC request message from the terminal device in the inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in an inactive state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message. And then, the new service access network equipment sends a request message to the anchor access network equipment, wherein the request message is used for requesting to acquire the context of the terminal equipment. Next, the new serving access network device receives a response message to the request message from the anchor access network device. And then, before the new service access network equipment sends a response message of the second RRC recovery request message to the terminal equipment, clearing the cached first type data.

In the prior art, if the new service access network device has cached downlink data, the new service access network device will continue to send to the UE. However, since the buffered downlink data is secured by using the first key, and the UE has determined the second key before sending the second RRC request message, if the UE continues to send the downlink data secured by using the first key to the UE, a security verification error on the UE side may be caused. In this example, after the anchor access network device learns that the second RRC recovery procedure initiated by the same UE through the I-RNTI, the anchor access network device instructs the new serving access network device to delete the buffered downlink data, avoiding wasting transmission resources, and avoiding occurrence of security verification errors by the UE.

In one possible implementation, the response message includes second indication information; wherein: the second indication information is used for indicating the new service access network equipment to clear all cached downlink data, and the cached downlink data is the first type data; or the second indication information is used for indicating the identification information of the downlink data to be cleared, the downlink data to be cleared is data in the downlink data cached by the new service access network device, and the cached downlink data is the first type data.

In one possible implementation, the response message is a UE context failure acquisition message; or, the response message is a downlink user data message.

In a fifth aspect, a communication method is provided, where the method may be implemented by a new service access network device, or by a component, such as a chip, a processor, etc., applied in the new service access network device. The following description will take an example in which the execution subject is a new service access network device. First, the new serving access network device receives a first radio resource control RRC request message from the terminal device in an inactive state, the first RRC request message being for requesting recovery of an RRC connection. Then, the new service access network device receives a second RRC request message from the terminal device in the inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message; the second RRC request message comprises a first identifier, wherein the first identifier is used for determining the context of the terminal equipment; the first identity may be an I-RNTI. Next, the new service access network device determines the context of the terminal device based on the first identifier, where the context of the terminal device is the context of the terminal device from the anchor access network device received by the new service access network device in the first type data transmission process; the new service access network device determines a second key based on information in the context of the terminal device, the second key being used for transmitting second class data with the terminal device in a connected state.

The method can be suitable for the anchor point relocation, and after receiving the first RRC request message from the terminal equipment, the new service access network equipment can also receive a context response message of the terminal equipment from the anchor point access network equipment before receiving the second RRC request message from the terminal equipment, wherein the context response message of the terminal equipment comprises all the contexts of the terminal equipment.

The new service access network device replaces the anchor access network device to determine the second key without the anchor access network device determining the second key, so that the security problem caused by the fact that the same key is used in different access network devices can be avoided, and the storage resources of the anchor access network device can be saved.

In a possible implementation, the new serving access network device may further receive the first identifier from the anchor access network device after receiving the first RRC request message from the terminal device and before receiving the second RRC request message from the terminal device, and associate the first identifier with the context of the terminal device. For example, the new serving access network device may receive, when receiving the first identifier from the anchor access network device, an acquire terminal device context response (RETRIEVE UE CONTEXT RESPONSE) message from the anchor access network device, where the acquire terminal device context response message includes the first identifier. Or send the first identification to the new serving access network device in a new message.

In one possible implementation, the new serving access network device may also send an RRC restore message to the UE after determining the second key.

In a possible implementation, the first identifier (e.g., I-RNTI) is included in the first RRC request message; the new serving access network device may further receive a get terminal device context response (RETRIEVE UE CONTEXT RESPONSE) message from the anchor access network device after receiving the first RRC request message from the terminal device and before receiving the second RRC request message from the terminal device, triggering associating the first identity with the context of the terminal device. For example, the context response message of the terminal equipment includes third indication information, where the third indication information is used to indicate that identity verification is performed on the terminal equipment, or is used to indicate the first identifier stored in the first RRC request message, or is used to indicate that the first identifier is associated with the context of the terminal equipment.

In a sixth aspect, a communication method is provided, where the method may be implemented by a new service access network device, or by a component, such as a chip, a processor, etc., applied in the new service access network device. The following description will take an example in which the execution subject is a new service access network device. Firstly, a new service access network device receives a first Radio Resource Control (RRC) request message from a terminal device in a non-activated state, wherein the first RRC request message is used for requesting to recover RRC connection; the first RRC request message includes a first identifier, where the first identifier is used to determine a context of the terminal device, and the first identifier may be an I-RNTI. Then, the new service access network device sends a second identifier to the terminal device, wherein the second identifier is used for determining the context of the terminal device; the second identity may be a new I-RNTI. The new I-RNTI may be carried in the rrcrecon configuration message or in a new RRC message. Then, the new service access network device receives a second RRC request message from the terminal device in the inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message; the second RRC request message includes the second identifier. And then, the new service access network equipment determines the context of the terminal equipment based on the second identification, wherein the context of the terminal equipment is sent by the anchor access network equipment in the small data transmission process. Next, the new serving access network device determines a second key based on information in the context of the terminal device, the second key being used for transmitting second class data with the terminal device in a connected state.

The new service access network device replaces the anchor access network device to determine the second key without the anchor access network device determining the second key, so that the security problem caused by the fact that the same key is used in different access network devices can be avoided, and the storage resources of the anchor access network device can be saved.

The new serving access network device may also send an RRC restore message to the UE after determining the second key.

In one possible implementation, when the new serving access network device sends the second identifier to the terminal device, the next hop chain count NCC value may also be sent to the terminal device.

In a seventh aspect, there is provided a communications device having functionality to implement any one of the above aspects and any one of the possible implementations of any one of the aspects. These functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more functional modules corresponding to the functions described above.

The apparatus, when having the functions of implementing the implementation of the first aspect, includes:

the processing module is used for determining a first key under the condition that the device in the inactive state determines that the first type of data arrives; wherein the first key is used for transmitting the first type of data by the device in an inactive state; and determining a second key if it is determined that the second class of data arrives; a sending module, configured to send an RRC request message to an access network device; wherein the second key is used for transmitting the second class data by the device in a connected state; the RRC request message is used for requesting to recover the RRC connection; a receiving module, configured to receive first type data from the access network device before receiving an RRC response message from the access network device; the processing module is further used for carrying out security verification on the first type of data by adopting the first secret key; the RRC response message is used for responding to the RRC request message.

The apparatus, when having the functions in implementing the second aspect, includes:

the processing module is used for determining a first key under the condition that the device in the inactive state determines that the first type of data arrives; wherein the first key is used for transmitting the first type of data by the device in an inactive state; and determining a second key if it is determined that the second class of data arrives; a sending module, configured to send an RRC request message to an access network device; wherein the second key is used for transmitting the second class data by the device in a connected state; the RRC request message is used for requesting to recover the RRC connection; a receiving module, configured to receive first type data from the access network device before receiving an RRC response message from the access network device; wherein, the RRC response message is used for responding to the RRC request message; the processing module is further configured to discard the first type of data.

The apparatus, when having the functionality to implement the third aspect and any possible implementation of the third aspect, comprises:

a processing module for determining a first key in case of receiving a first RRC request message from the DU; the first RRC request message is from a terminal device in an inactive state, the first RRC request message is used for requesting to recover RRC connection, and the first key is used for transmitting first type data with the terminal device in the inactive state; a receiving module, configured to receive a second RRC request message from the DU; the second RRC restoration request message is from the terminal device in the inactive state, where the second RRC request message is used to request restoration of RRC connection; the processing module is further configured to determine a second key, where the second key is used to transmit second class data with the terminal device in a connected state; a sending module, configured to send an RRC response message of the second RRC request message to the DU after sending the first indication information to the DU; the first indication information is used for indicating the DU to clear the first type of data.

For example, the apparatus comprises a control plane CU and a user plane CU.

The apparatus, when having the functionality to implement any one of the possible implementations of the fourth aspect and the fourth aspect, comprises:

a receiving module, configured to receive a first radio resource control RRC request message from a terminal device in an inactive state, where the first RRC request message is used to request recovery of RRC connection; and receiving a second RRC request message from the terminal device in an inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message; a sending module, configured to send a request message to an anchor access network device, where the request message is used to request to obtain a context of the terminal device; the receiving module is further configured to receive a response message for the request message from the anchor access network device; and the processing module is used for clearing the cached first type data before sending a response message of the second RRC recovery request message to the terminal equipment.

For example, the response message includes second indication information; wherein: the second indication information is used for indicating the new service access network equipment to clear all cached downlink data, and the cached downlink data is the first type data; or the second indication information is used for indicating the identification information of the downlink data to be cleared, the downlink data to be cleared is data in the downlink data cached by the new service access network device, and the cached downlink data is the first type data.

For example, the response message is a UE context acquisition failure message; or, the response message is a downlink user data message.

In an eighth aspect, a communications apparatus is provided that includes a processor, optionally, a memory; the processor and the memory are coupled; the memory is used for storing a computer program or instructions; the processor is configured to execute part or all of the computer program or instructions in the memory, which when executed, is configured to implement the functions in the method of any one of the above aspects and any one of the possible implementations of any one of the above aspects.

In one possible implementation, the apparatus may further include a transceiver for transmitting the signal processed by the processor or receiving a signal input to the processor. The transceiver may perform the transmitting or receiving actions of any aspect and any possible implementation of any aspect.

In a ninth aspect, the present application provides a chip system comprising one or more processors (which may also be referred to as processing circuits) electrically coupled between the processors and a memory (which may also be referred to as storage medium); the memory may or may not be located in the chip system; the memory is used for storing a computer program or instructions; the processor is configured to execute part or all of the computer program or instructions in the memory, which when executed, is configured to implement the functions in the method of any one of the above aspects and any one of the possible implementations of any one of the above aspects.

In one possible implementation, the chip system may further include an input/output interface (may also be referred to as a communication interface), which is configured to output a signal processed by the processor or receive a signal input to the processor. The input-output interface may perform the sending or receiving actions of any aspect and any possible implementation of any aspect. Specifically, the output interface performs a transmission action, and the input interface performs a reception action.

In one possible implementation, the chip system may be formed of a chip, or may include a chip and other discrete devices.

In a tenth aspect, there is provided a computer readable storage medium storing a computer program comprising instructions for implementing the functions of any aspect and any possible implementation of any aspect.

Alternatively, a computer readable storage medium storing a computer program which, when executed by a computer, may cause the computer to perform any of the above aspects and any possible implementation of the method of any of the above aspects.

In an eleventh aspect, there is provided a computer program product comprising: computer program code which, when run on a computer, causes the computer to perform the method of any one of the above aspects and any one of the possible implementations of any one of the above aspects.

Technical effects of the seventh to eleventh aspects described above may be referred to the description in the first to sixth aspects, and the repetition is not repeated.

Drawings

Fig. 1 is a schematic diagram of a communication system according to an embodiment of the present application;

FIG. 2a is a schematic diagram of a communication system according to an embodiment of the present application;

FIG. 2b is a schematic diagram of a communication system according to an embodiment of the present application;

fig. 3, fig. 4, fig. 5, fig. 6, fig. 7, fig. 8, fig. 9, fig. 10, fig. 11, fig. 12, and fig. 13 are schematic diagrams of a communication flow provided in an embodiment of the present application;

fig. 14 and fig. 15 are respectively block diagrams of a communication device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

In order to facilitate understanding of the technical solution of the embodiments of the present application, a system architecture of the method provided by the embodiments of the present application will be briefly described below. It can be understood that the system architecture described in the embodiments of the present application is for more clearly describing the technical solutions of the embodiments of the present application, and does not constitute a limitation on the technical solutions provided by the embodiments of the present application.

The technical scheme of the embodiment of the application can be applied to various communication systems, such as: satellite communication system, conventional mobile communication system. Wherein the satellite communication system may be integrated with a conventional mobile communication system, i.e. a terrestrial communication system. A communication system such as: wireless local area network (wireless local area network, WLAN) communication systems, wireless fidelity (wireless fidelity, wiFi) systems, long term evolution (long term evolution, LTE) systems, LTE frequency division duplex (frequency division duplex, FDD) systems, LTE time division duplex (time division duplex, TDD), fifth generation (5th generation,5G) systems or New Radio (NR), sixth generation (6th generation,6G) systems, and other future communication systems, and the like, and also support communication systems in which multiple wireless technologies are integrated, for example, systems in which non-terrestrial networks (non-terrestrial network, NTN) such as unmanned aerial vehicles, satellite communication systems, high altitude platform (high altitude platform station, HAPS) communication are integrated.

In order to facilitate understanding of the embodiments of the present application, the following description will describe application scenarios of the present application, where the network architecture and the service scenario described in the embodiments of the present application are for more clearly describing the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application, and as a person of ordinary skill in the art can know that, with the appearance of a new service scenario, the technical solutions provided by the embodiments of the present application are applicable to similar technical problems.

As in the communication system shown in fig. 1, a terminal device (e.g., the terminal device 1301 or the terminal device 1302) can access to a wireless network to acquire services of an external network (e.g., a Data Network (DN)) through the wireless network or communicate with other devices through the wireless network, such as can communicate with other terminal devices. The wireless network includes a radio access network (radio access network, RAN) and a Core Network (CN). The RAN may also be referred to as AN Access Network (AN) for accessing the terminal devices to the wireless network, and the CN is used to manage the terminal devices and provide a gateway for communicating with the DN.

One or more access network devices, such as access network device 1101, access network device 1102, may be included in the RAN. One or more core network elements, such as core network element 120, may be included in the CN.

In addition, the technical scheme introduced by the application is suitable for a communication system between the UE and the access network equipment and is also suitable for a UE-UE communication system.

In order to facilitate understanding of the embodiments of the present application, some terms or related techniques of the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

1) And the terminal equipment.

A terminal device, which may also be referred to as a User Equipment (UE), includes a device that provides voice and/or data connectivity to a user, and may include, for example, a handheld device with wireless connectivity, or a processing device connected to a wireless modem. The terminal device may communicate with the core network via a radio access network (radio access network, RAN), exchanging voice and/or data with the RAN. The terminal devices may include wireless terminal devices, mobile terminal devices, device-to-device (D2D) terminal devices, vehicle-to-everything (vehicle to everything, V2X) terminal devices, machine-to-machine/machine-type communication (M2M/MTC) terminal devices, internet of things (internet of things, ioT) terminal devices, subscriber units, subscriber stations, mobile stations, remote stations, access Points (APs), remote terminals, access terminals, user agents, user equipment, or the like. For example, mobile telephones (or "cellular" telephones) computers with mobile terminal devices, portable, pocket, hand-held, computer-built mobile devices, and the like may be included. Such as personal communication services (personal communication service, PCS) phones, cordless phones, session initiation protocol (session initiation protocol, SIP) phones, wireless local loop (wireless local loop, WLL) stations, personal digital assistants (personal digital assistant, PDAs), and the like. But may also include limited devices such as devices with lower power consumption, or devices with limited memory or computing capabilities, etc. Examples include bar codes, radio frequency identification (radio frequency identification, RFID), sensors, global positioning systems (global positioning system, GPS), laser scanners, and other information sensing devices.

In the embodiment of the present application, the device for implementing the function of the terminal device may be the terminal device, or may be a device capable of supporting the terminal device to implement the function, for example, a chip system or a combination device or a component capable of implementing the function of the terminal device, and the device may be installed in the terminal device. In the embodiment of the application, the chip system can be composed of chips, and can also comprise chips and other discrete devices. In the technical solution provided in the embodiment of the present application, the device for implementing the function of the terminal device is an example of the terminal device, and the technical solution provided in the embodiment of the present application is described.

2) Access network device

An access network device is a node or device that accesses a terminal device to a wireless network, which may also be referred to as a base station. Access network devices include, for example, but are not limited to: a new generation base station (generation Node B, gNB), evolved node B (eNB), radio network controller (radio network controller, RNC), node B (NB), base station controller (base station controller, BSC), base transceiver station (base transceiver station, BTS), home base station (home evolved nodeB, heNB) or (home node B, HNB), baseBand unit (BBU), transmission reception point (transmitting and receiving point, TRP), transmission point (transmitting point, TP), or mobile switching center in a 5G communication system.

In the embodiment of the present application, the means for implementing the function of the access network device may be the access network device, or may be a means capable of supporting the access network device to implement the function, for example, a chip system or a combination device or a component capable of implementing the function of the access network device, where the means may be installed in the access network device. In the technical solution provided in the embodiment of the present application, the device for implementing the function of the access network device is an access network device, which is described in the technical solution provided in the embodiment of the present application.

The interface between the access network device and the terminal device may be a Uu interface (or referred to as a null interface). Of course, in future communications, the names of these interfaces may be unchanged or may be replaced with other names, as the application is not limited in this regard. Illustratively, the communication between the access network device and the terminal device follows a protocol layer structure, e.g., the control plane protocol layer structure may include a radio resource control (radio resource control, RRC) layer, a packet data convergence layer protocol (packet data convergence protocol, PDCP) layer, a radio link control (radio link control, RLC) layer, a medium access control (mediu access control, MAC) layer, and a physical layer; the user plane protocol layer structure may include a PDCP layer, an RLC layer, a MAC layer, and a physical layer, and in one possible implementation, a service data adaptation (service data adaptation protocol, SDAP) layer may be further included above the PDCP layer.

The access network device may implement the functions of the protocol layers such as RRC, PDCP, RLC and MAC by one node, or may implement the functions of the protocol layers by a plurality of nodes. For example, in an evolved architecture, an access network device may include one or more Centralized Units (CUs) and one or more Distributed Units (DUs), where multiple DUs may be centrally controlled by one CU. As an example, the interface between a CU and a DU may be referred to as an F1 interface, where a Control Plane (CP) interface may be F1-C, and a User Plane (UP) interface may be F1-U. CUs and DUs may be divided according to the protocol layers of the wireless network: for example, as shown in fig. 2a, the functions of the PDCP layer and above are set at the CU, and the functions of the PDCP layer and below protocol layers (e.g., RLC layer, MAC layer, etc.) are set at the DU.

It will be appreciated that the above-mentioned division of the processing functions of the CU and the DU according to the protocol layer is only an example, and may be divided in other manners, for example, the functions of the protocol layer above the RLC layer are set in the CU, the functions of the RLC layer and the protocol layers below the RLC layer are set in the DU, and the CU or the DU may be divided into functions having more protocol layers, and the CU or the DU may be divided into partial processing functions having the protocol layers, for example. In one design, part of the functions of the RLC layer and the functions of the protocol layers above the RLC layer are set at CU, and the remaining functions of the RLC layer and the functions of the protocol layers below the RLC layer are set at DU. In another design, the functions of the CU or the DU may be further divided according to a service type or other system requirements, for example, the functions that the processing time needs to meet the delay requirement are set in the DU, and the functions that do not need to meet the delay requirement are set in the CU. In another design, a CU may also have one or more functions of the core network. Illustratively, the CUs can be arranged on the network side to facilitate centralized management; the DU may have multiple radio functions, or the radio functions may be set remotely. The embodiment of the present application is not limited thereto.

The functionality of a CU may be implemented by one entity, or by a different entity, for example. For example, as shown in fig. 2b, the functions of the CU may be further split, that is, the control plane and the user plane are separated and implemented by different entities, that is, a control plane CU entity (i.e., a CU-CP entity) and a user plane CU entity (i.e., a CU-UP entity), which may be coupled to the DU, to jointly complete the functions of the access network device. The interface between the CU-CP entity and the CU-UP entity can be an E1 interface, the interface between the CU-CP entity and the DU can be an F1-C interface, and the interface between the CU-UP entity and the DU can be an F1-U interface. Wherein one DU and one CU-UP can be connected to one CU-CP. One DU may be connected to a plurality of CU-UPs and one CU-UP may be connected to a plurality of DUs under the same CU-CP control.

It should be noted that: in the architecture illustrated in fig. 2a and 2b above, the signaling generated by the CU may be sent to the terminal device through a DU, or the signaling generated by the terminal device may be sent to the CU through a DU. The DU may be directly transmitted to the terminal device or CU after being encapsulated by the protocol layer without parsing the signaling. In the following embodiments, transmission or reception of signaling by a DU includes such a scenario if such signaling is involved in the transmission between the DU and the terminal device. For example, signaling of the RRC or PDCP layer is eventually processed as data of the physical layer to be transmitted to the terminal device or converted from the received data of the physical layer. Under this architecture, the signaling of the RRC or PDCP layer may be considered as being sent by either a DU or by both a DU and a radio frequency device.

3) Network element of core network

Taking the 5G communication system as an example, the core network elements in the CN may include, but are not limited to, an access and mobility management function (access and mobility management function, AMF) network element, a session management function (session management function, SMF) network element, a user plane function (user plane function, UPF) network element, a policy control function (policy control function, PCF) network element, and the like.

The access and mobility management function (access and mobility management function, AMF) is a control plane network element provided by the operator network, and is responsible for access control and mobility management of the terminal device accessing the operator network, for example, including mobility state management, allocation of a temporary identity of a user, authentication, user, and other functions. In future communication systems, the access management network element may still be an AMF network element, or may have other names, which is not limited by the present application.

Session management functions (session management function, SMF) network elements are mainly responsible for session management in mobile networks, such as session establishment, modification, release. Specific functions include assigning an IP address to a user, selecting a user plane network element that provides a message forwarding function, and the like. In future communication systems, the session management network element may still be an SMF network element, or may have other names, which is not limited by the present application.

The user plane function (user plane function, UPF) network element is responsible for forwarding and receiving user data in the terminal device. User data can be received from the data network and transmitted to the terminal equipment through the access network equipment; the user plane network element may also receive user data from the terminal device via the access network device and forward the user data to the data network. The transmission resources and scheduling functions in the user plane network element that serve the terminal device are managed and controlled by the SMF network element. In future communication systems, the user plane network element may still be a UPF network element, or may have other names, which is not limited by the present application.

4) Three states of the terminal: RRC Idle, RRC Inactive, RRC Connected.

The third generation partnership project (3rd Generation Partnership Project,3GPP) specifies three states of a terminal in the 5G communication standard, namely: RRC Idle, RRC Inactive, RRC Connected. RRC Connected may also be referred to as RRC Active.

In the RRC Connected state, there is a dedicated RRC connection between the terminal device and the access network device.

In the RRC Idle state, there is no dedicated RRC connection between the terminal device and the access network device.

In the RRC Inactive state, the terminal device moves under the radio access network RNA, and does not move out of the configured RNA range, so that the access network device may not be informed. The terminal device stores the context of the terminal device, and the Last serving gNB stores the context of the terminal device and is connected with the AMF and the NG of the UPF. The dedicated RRC connection of the terminal device with the access network device is suspended and subsequently recoverable.

The RRC Inactive state is similar to the RRC Idle state, content of the common search space (e.g., paging, broadcast) may also be received, and the principle of performing cell reselection in the RRC Inactive state is the same as that of performing cell reselection in the RRCIdle state. The RRC Inactive state can save energy consumption of the terminal device, because the UE in the RRC Inactive state can suspend data processing, and if the UE moves in the same RNA, information interaction with the access network device is not required, so that the RRC Inactive state can obtain a power consumption level similar to that of the RRC Idle state. However, if the UE moves out of range of the RNA, then an RNA update process needs to be initiated. The UE in the RRC Inactive state may be quickly converted to RRC Connected through an RRC Resume procedure, so that when the UE in the RRC Inactive state resumes data transmission, the recovery delay is lower.

The process of these 3 state transitions is shown in fig. 3: the RRC Idle state may be converted into an RRC Connected state through an RRC recovery procedure, and the RRC Connected state may be converted into an RRC Idle state through an RRC release procedure. The RRC Inactive (Inactive or Inactive) state may be converted into an RRC Connected state through an RRC recovery procedure, and the RRC Connected state may be converted into an RRC Inactive (Inactive or Inactive) state through an RRC release procedure. The RRC recovery procedure may also be performed in the RRC Inactive state, and the RRC Inactive state may be converted into the RRC Idle state through the RRC release procedure. For convenience of description, RRC Idle, RRC active, RRC Connected will hereinafter be abbreviated as Idle, inactive, connected, respectively.

5) Small data: the total amount of data to be transmitted for a radio bearer that allows data transmission in a power saving state (e.g., inactive or Idle state in which the connection state access layer part context is maintained) is below a pre-configured threshold, then the data of the radio bearer may be considered as small data. For example, the configured threshold is 30 bytes, 50 bits, etc. The radio bearers that allow small data transmissions in the power saving state include data radio bearers DRBs, signaling radio bearers SRBs. The DRB for small data transmission is described below as an example.

6) The request may also be referred to as a request message in the present application, for example, the RRC request may be referred to as an RRC request message, and for example, the RRC recovery request may be referred to as an RRC recovery request message. Similarly, a response may also be referred to as a response message.

The key subscripts 0, 1, 2, and 3 are used for distinguishing the keys, and should not be limited to the key names and roles, such as K _{NG-RAN*_1} Base station key K _gNB1 RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 The subscript 1 of (2) should not be construed as limiting the key name and effect.

When the UE in RRC inactive state has uplink data radio bearer (data radio bearer, DRB) service data to be sent, the UE initiates an RRC resume request message. After receiving the RRC restoration message, the UE restores the RRC connection, changes from the Inactive state to the Connected state, and sends the uplink DRB service data, which results in lower service data sending efficiency. Based on this, further discussion of the standard, data transmission on a designated DRB is performed in the Inactive state without the need to enter the Connected state. The designated DRBs may be referred to as small data transfer (small data transmission, SDT) DRBs (hereinafter SDT), i.e., DRBs that allow data to be directly transmitted in the active state when the total amount of data to be transmitted for all designated DRBs is below a pre-configured threshold. For such DRBs, the UE is also allowed to transmit multiple times in the Inactive state. Otherwise, the UE needs to restore the RRC connection to perform data transmission. The non-designated DRB may be referred to as a non-SDT DRB (hereinafter referred to as non-SDT), i.e., a DRB that does not allow direct data transmission in the Inactive state, i.e., the UE needs to recover the RRC connection for data transmission. The small data transmission may be a small data transmission (CG-SDT) based on configuration authorization, or may be a small data transmission (RA-SDT) based on random access. For a small data transmission flow based on random access, supporting the migration of an anchor base station and the non-migration of the anchor base station.

As shown in fig. 4, the small data transmission flow is introduced, and at least the following steps are included:

step 401: the base station (gNB) sends an RRC Release (RRC Release) message to the UE, and instructs the UE to enter an Inactive state.

The RRC release message carries a suspend Config field, where the field may include an inactive radio network temporary identifier (inactive radio network temporary identifier, I-RNTI) and may further include CG configuration. The I-RNTI is used to uniquely identify an Access Stratum (AS) context within one base station.

Step 402: after receiving the RRC release message, the UE changes from the Connected state to the Inactive state.

Optionally, the UE may also store the current base station key K _gNB0 Current RRC integrity protection key K _RRCint0 Information is passed to the AS context of the active.

Step 403: when the SDT data arrives, the UE triggers a first RRC connection recovery procedure.

For example, the UE protects the key K based on RRC integrity _RRCint0 Deducing new K _{NG-RAN*_1} Will K _{NG-RAN*_1} As an existing base station key K _gNB1 The method comprises the steps of carrying out a first treatment on the surface of the New RRC keys, new UP keys, etc. may also be derived.

For example, the UE is K-based _gNB1 Deducing RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 . Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 The method is used for carrying out integrity protection and encryption on the user plane data respectively; RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 And the method is used for carrying out integrity protection and encryption on the RRC signaling respectively.

The application locally stores the RRC integrity protection key K when the UE triggers the SDT _RRCint0 RRC encryption key K _RRCenc0 Integrity protection key K for user plane _Upint0 And encryption key K of user plane _Upenc0 The composed key set is marked as K_0; deriving a new RRC integrity protection key K from the UE _RRCint1 RRC encryption key K _RRCenc1 User and userIntegrity protection key K for a face _UPint1 And encryption key K of user plane _UPenc1 The key set formed is denoted as k_1.

The UE may also protect the key K based on RRC integrity _RRCint0 Deriving a message authentication code for identity verification: short recovery integrity message authentication code shortresummac-I (integrity message authentication code message authentication code for Integrity, MAC-I), or resummac-I.

Step 404: the UE sends a first RRC resume request (RRC Resume Request) message to the base station (gNB) and uses K _UPenc1 Encrypted upstream data. The first RRC recovery request contains the I-RNTI and the resubmeMAC-I or shortresumeMAC-I generated above.

The UE may send the first RRC resume request and employ K through message 3 (Msg 3) in a 4-step random access procedure, or message a (MsgA) in a 2-step random access procedure, or a configuration grant _UPenc1 Encrypted upstream data. For example, the UE checks whether the condition of CG-SDT is satisfied; if yes, triggering CG-SDT by UE, and sending RRC recovery request message by UE using CG resources allocated in CG configuration and adopting K _UPenc1 Encrypted upstream data. For example, the UE checks whether a condition for random access RA-SDT is satisfied; if yes, the UE triggers RA-SDT, and sends RRC Resume Request message in message 3 of 4 steps random access or message A of 2 steps random access according to random access flow and adopts K _UPenc1 Encrypted upstream data.

In the random access scenario, after the UE sends a first RRC recovery request on a resource provided by a 4-step random access response or a 2-step random access message a resource, the UE starts a first timer, monitors a response message of the first RRC recovery request during operation of the first timer, for example, response information including contention resolution information (contention resolution), compares the received contention resolution information with 48 bits or all bits before the first RRC recovery request, and if 2 are the same or matched, indicates that contention resolution is successful, and considers successful sending. If no matching competition resolving information is received within the time-out period of the timer, the competition resolving information indicates that the competition resolving is failed, and the sending is considered to be failed. In addition to this way contention resolution is achieved, there are other ways, if the downlink scheduling information of the physical downlink control channel (physical downlink control channel, PDCCH) scrambled by the RNTI dedicated to the UE indicates that contention resolution is successful, then it is considered that transmission is successful. If the physical downlink control channel scrambled by the RNTI special for the UE is not received within the timeout of the timer, the contention resolution failure is indicated, and the transmission failure is considered.

In the configuration grant transmission scenario, after the UE transmits a first RRC recovery request on a resource of the configuration grant, a second timer is started, and a response message of the first RRC recovery request is monitored during operation of the second timer, and if PDCCH information scrambled with an RNTI dedicated to the UE is included, the UE is considered to be successfully transmitted. If the PDCCH scrambled by the RNTI special for the UE is not received within the time-out of the timer, the transmission is considered to be failed.

Step 405: after gNB receives the first RRC Resume Request message, the key K is protected based on RRC integrity _RRCint0 Deducing a resubmac-I or a shortresummac-I, and authenticating the UE by the gNB according to the resubmac-I or the shortresummac-I.

For example, the gNB obtains the context of the UE (e.g., the Inactive AS context) from the I-RNTI and uses the same method AS the UE based on the base station key K in the context _gNB0 Either ResumeMAC-I or shortresumeMAC-I is derived.

If passing the verification, gNB adopts the same method as UE based on base station key K _gNB0 Deducing new K _{NG-RAN*_1} Will K _{NG-RAN*_1} As an existing base station key K _gNB1 Keys in the key set k_1 may also be deduced.

All upstream and downstream data transmitted in the SDT process can use the integrity protection key K of the user plane in K_1 _UPint1 And/or encryption key K of user plane _UPenc1 Integrity protection and/or encryption is performed.

Step 406: the UE completes the initial transmission of the SDT.

For example, during a small data transmission based on configuration authorization, the gNB replies a configuration authorization (CG) response to the UE, and the initial transmission of CG-SDT is completed after the UE receives the response (initial transmission).

For example, in a small data transmission procedure based on random access, when the random access procedure is successfully completed, the UE completes the initial transmission of RA-SDT. Optionally, the gNB dynamically configures uplink transmission resources for subsequent transmission for the UE through downlink control information (downlink control information, DCI).

Step 407: after the UE completes the initial transmission of the SDT, a subsequent transmission of the SDT may be made between the UE and the gNB (subsequent transmission).

Step 408: after the subsequent transmission of the SDT is finished, the gNB sends an RRC Release message to the UE to terminate the SDT process.

The example presented in fig. 4 is applicable to the same scenario where the serving gNB when the UE initiates the SDT and the serving gNB when the UE transitions the UE from Connected to Inactive state by sending an RRCRelease message.

In another scenario, when the UE moves, the gNB that sends the RRCRelease message to switch the UE from Connected to Inactive state and the serving gNB when the UE initiates SDT may not be the same gNB. The application refers to a gNB for transferring the UE from Connected to Inactive state by sending RRCRelease message as a Last serving gNB (which can be called anchor base station, or old serving base station, or Last serving base station), and refers to a serving gNB when the UE initiates SDT as a new serving base station. When the anchor base station and the new serving base station are not the same gNB, the UE can only trigger RA-SDT and cannot trigger CG-SDT. After the new serving base station receives the RRC Resume Request message from the UE, the new serving base station requests the UE context from the anchor base station, which decides whether to perform anchor relocation. If the anchor relocation is performed, the anchor base station transmits the entire context of the UE to a new serving base station, which establishes a path with the core network, and becomes a new anchor base station. If the anchor relocation is not performed, the new serving base station is responsible for forwarding data between the UE and the anchor base station.

As shown in fig. 5, the flow of RA-SDT that does not perform anchor relocation is introduced.

Step 501: an anchor base station (Last serving gNB) sends an RRC Release message to the UE, and instructs the UE to enter an Inactive state.

The RRC release message carries a suspend Config field, where the field includes: the inactive radio network temporary identity I-RNTI may also include CG configuration.

Step 502: after receiving the RRC release message, the UE changes from the Connected state to the Inactive state.

Optionally, the UE may also store the current base station key K _gNB0 Current RRC integrity protection key K _RRCint0 Information is passed to the AS context of the active.

Step 503: when the SDT data arrives, the UE triggers a first RRC connection recovery procedure.

For example, the UE is based on the base station key K _gNB0 Deducing new K _{NG-RAN*_1} Will K _{NG-RAN*_1} As an existing base station key K _gNB1 The method comprises the steps of carrying out a first treatment on the surface of the New RRC keys, new UP keys may also be derived.

For example, based on K _gNB1 Deducing RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 . Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 The method is used for carrying out integrity protection and encryption on the user plane data respectively; RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 And the method is used for carrying out integrity protection and encryption on the RRC signaling respectively.

The application locally stores the RRC integrity protection key K when the UE triggers the SDT _RRCint0 RRC encryption key K _RRCenc0 Integrity protection key K for user plane _Upint0 And encryption key K of user plane _Upenc0 The composed key set is marked as K_0; deriving a new RRC integrity protection key K from the UE _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 The key set formed is denoted as k_1.

The UE may also use RRC integrity protection key K _RRCint0 A message authentication code, such as shortresummac-I or resummac-I, is derived for authentication.

Step 504: UE to new serving base station (new)gNB) sends a first RRC resume request and employs K _UPenc1 Encrypted upstream data.

The first RRC recovery request contains the I-RNTI and the shortResecumeMAC-I or resubmeMAC-I generated above, and may also include a resumeId and a cause value.

The UE may send the first RRC resume request and employ K through message 3 in the 4-step random access procedure or message a in the 2-step random access procedure _UPenc1 Encrypted upstream data.

Step 505: the new Serving base station (new gNB) determines an anchor base station (Last Serving gNB) according to the I-RNTI, and sends a first request message to the anchor base station. Accordingly, the anchor base station receives a first request message from the new serving base station. The first request message is used for acquiring the context of the terminal or requesting the anchor point base station to transmit data or small data.

The first request message comprises an I-RNTI, a resubmeMAC-I for verifying the identity of the UE or a short resubmeMAC-I.

Optionally, the first request message may further include a small data transfer indication (SDT indication).

The first request message may be a get UE context request (RETRIEVE UE CONTEXT REQUEST) message.

Step 506: an anchor base station (Last Serving gNB) acquires a UE context according to the I-RNTI, and adopts the same method as the UE, and protects a key K based on RRC integrity _RRCint0 Deducing a resubmac-I or a short resubmac-I, and authenticating the identity of the UE by the gNB according to the resubmac-I or the short resubmac-I.

If the authentication is passed, the anchor base station adopts the same method as the UE and is based on the base station key K _gNB0 Deducing new K _{NG-RAN*_1} Will K _{NG-RAN*_1} As an existing base station key K _gNB1 New RRC keys, new UP keys (e.g., keys in key set k_1) may also be deduced. All upstream and downstream data transmitted in the SDT process can use the integrity protection key K of the user plane in K_1 _UPint0 And/or encryption key K of user plane _UPenc0 Integrity protection and/or encryption is performed.

Step 507: the anchor base station (Last Serving gNB) decides not to perform anchor relocation.

Step 508: the anchor base station (Last Serving gNB) transmits a response message of the first request message to the new Serving base station (new gNB). Accordingly, the new serving base station receives the response message from the anchor base station.

Optionally, the response message includes a partial context of the UE (UE partial context). The response message is, for example, an acquire UE context response (Xn-AP RETRIEVE UE CONTEXT RESPONSE) message.

Optionally, step 509: the new Serving base station (new gNB) sends an address indication (Xn-U address indication) of the new Serving base station to the anchor base station (Last Serving gNB), which indicates a tunnel address for informing the anchor base station to forward downstream data.

This prevents the downlink data packets buffered at the anchor base station from being lost.

If the anchor base station has downlink data of the UE, the downlink data can be sent to the new serving base station, and then the new serving base station sends the downlink data to the UE. Of course, the new serving base station may not notify the anchor base station of the tunnel address for forwarding the downlink data.

And establishing a data forwarding channel between the new service base station and the anchor base station through the step 508 and the step 509, then sending the cached user data to the anchor base station by the new service base station, sending the user data to the core network by the anchor base station, and sending the downlink data received from the core network to the UE through the new service base station by the anchor base station.

Step 510: after receiving the response message of step 508, the new Serving base station (new gNB) may send the adoption K received in step 504 to the anchor base station (Last Serving gNB) _UPenc1 Encrypted upstream data.

The anchor base station may also send the decrypted uplink data to the user plane function UPF network element. For example, the anchor base station receives the K _UPenc1 After encrypting the upstream data, K can be used to extrapolate the performance in step 506 _UPenc1 The upstream data is decrypted and sent to the UPF.

Optionally, step 511: anchor point base station (Las)t Serving gNB) may also receive downstream data from the UPF, e.g., the anchor base station sends K to the new Serving base station _UPenc1 Encrypted downstream data.

Of course, there may not currently be downlink data to be sent to the UE.

Step 512: the new serving base station (new gNB) sends a response message of the first RRC recovery request to the UE, and the terminal receives the response message from the new serving base station.

The new serving base station transmits a response message of the first RRC recovery request through message 4 in the 4-step random access procedure or message B in the 2-step random access procedure, and the response message may include contention resolution information (contention resolution). If the core network element sends downlink data to the anchor base station, the response message may further include the downlink data.

In the RA-SDT procedure that does not perform anchor relocation, the UE derives the key set k_1 before sending the first RRC Resume Request, and uses the keys in the key set k_1 to integrity protect and/or encrypt the uplink data. The anchor base station derives a key set K_1 after user identity authentication is completed on the UE, and in subsequent transmission (subsequent transmission), the key in the key set K_1 is used for carrying out integrity protection and/or encryption on downlink data, and then the downlink data is sent to the new service base station.

As shown in fig. 6, the flow of RA-SDT to perform anchor relocation is introduced.

Steps 601 to 605 are the same as steps 501 to 505 in fig. 5, and the detailed description will not be repeated.

Step 606 differs from step 506 in that it includes: the anchor base station will not pull new K for the push in step 606 _{NG-RAN*_1} As an existing base station key K _gNB1 The rest is the same and the detailed description is not repeated.

Step 607: the anchor base station (Last Serving gNB) decides to perform anchor relocation.

Step 608: the anchor base station (Last Serving gNB) transmits a response message of the first request message to the new Serving base station (new gNB). Accordingly, the new serving base station receives the response message from the anchor base station.

Optionally, the response message includes the entire context of the UE, which may include the new K that was deduced in step 606 _{NG-RAN*_1} . The response message is, for example, a get UE context response (RETRIEVE UE CONTEXT RESPONSE) message.

Step 608a: the new serving base station (new gNB) adopts the same method as the UE and is based on K _{NG-RAN*_1} Deducing (deriving) the keys in the set of keys K_1 and adding K _{NG-RAN*_1} As an existing base station key K _gNB1 。

Optionally, step 609 (same as step 509): the new Serving base station (new gNB) sends an address indication (Xn-U address indication) of the new Serving base station to the anchor base station (Last Serving gNB), which indicates a tunnel address for informing the anchor base station to forward downstream data.

This prevents the downlink data packets buffered at the anchor base station from being lost. If the anchor base station has downlink data of the UE, the downlink data can be sent to the new serving base station, and then the new serving base station sends the downlink data to the UE. Of course, the new serving base station may not notify the anchor base station of the tunnel address for forwarding the downlink data.

Step 610: the new serving base station sends a path switch request (path switch request) to a core network element (e.g., AMF or SMF), and the new serving base station establishes a path with the core network.

Step 611: the new serving base station receives a path switch request acknowledgement (path switch request acknowledge) message from a core network element (e.g., AMF or SMF).

Step 612a: the new Serving base station sends a UE context release (UE CONTEXT RELEASE) message to the anchor base station (Last Serving gNB) triggering the anchor base station to release the UE context.

Step 612b: the new serving base station (new gNB) sends a response message of the first RRC recovery request to the UE, and the terminal receives the response message from the new serving base station.

The order of steps 612a and 612b is not limited.

The new serving base station transmits a response message of the first RRC recovery request through message 4 in the 4-step random access procedure or message B in the 2-step random access procedure, and the response message may include contention resolution information (contention resolution). If the core network element sends downlink data to the new serving base station, the response message may further include the downlink data.

The UE and the new serving base station (new gNB) may make subsequent transmissions of data (subsequent transmission). The new serving base station may directly transmit uplink data sent by the UE to the core network, or transmit downlink data sent by the core network to the UE.

In RA-SDT performing anchor relocation, the UE derives the base station key K before sending the first RRC Resume Request _gNB1 And the key set K_1 is used for carrying out integrity protection and/or encryption on the uplink data by using the keys in the key set K_1. The anchor base station deduces K after finishing user identity authentication to UE _NG-RAN*1 And key set K_1, then the anchor base station will derive a new K in step 608 _{NG-RAN*_1} To a new serving base station based on the received new K _{NG-RAN*_1} Deriving the key in the key set k_1, and subsequently performing integrity protection and/or encryption on the downlink data by using the key in the key set k_1.

When the UE in the RRC Inactive state needs to send service data on the designated DRB, the UE triggers an RRC connection recovery procedure, and sends an RRC recovery request message for the first time (i.e., the first RRC recovery request message above). If the UE has traffic data (i.e., non-SDT) on the unspecified DRB to be transmitted before receiving the RRC release message, the UE triggers the RRC connection resume procedure again, and transmits an RRC resume request message (hereinafter referred to as a second RRC resume request message) for the second time.

As shown in fig. 7, a communication flow diagram is provided, which describes that the first RRC connection recovery procedure (which may also be referred to as a data or small data transmission procedure) of the UE in the Inactive state is not ended, and the UE triggers the RRC connection recovery procedure again. Steps 401 through 406 in fig. 7 and 4, and step 407 (excluding step 408) may be considered as a general communication flow, which is described in two parts for convenience of drawing. The method specifically comprises the following steps:

the UE determines that non-SDT data arrives, i.e., uplink data that cannot be transmitted in the RRC inactive state arrives.

Step 409: the UE starts a second RRC recovery procedure.

For example, the UE may key the base station K _gNB1 RRC integrity protection key K _RRCint1 The information is updated into the AS context of the active.

For example, the UE may be based on the base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 The method comprises the steps of carrying out a first treatment on the surface of the New RRC keys, new UP keys, etc. may also be derived. For example, the UE is K-based _gNB2 Deducing RRC integrity protection key K _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 . The application derives a new RRC integrity protection key K from the UE _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 The composed key set is denoted as k_2.

For example, the UE may also protect the key K based on RRC integrity _RRCint1 A message authentication code resubmac-I or shortresummac-I for authentication is derived.

Step 410: the UE sends a second RRC resume request message to the base station gNB.

The second RRC recovery request includes the I-RNTI and the shortResecumeMAC-I or resubmeMAC-I generated above.

Step 411: after receiving the second RRC Resume Request message, the base station gNB acquires the UE context according to the I-RNTI, and adopts the same method as the UE to protect the key K based on RRC integrity _RRCint1 Deducing a resubmac-I or a shortresummac-I, and authenticating the UE by the gNB according to the resubmac-I or the shortresummac-I.

For example, the gNB obtains a UE context (e.g., an Inactive AS context) from the I-RNTI and uses the same method AS the UE based on the base station key K in the context _gNB1 Deducing ResumeMAC-I or shortResumeMAC-I。

If passing the verification, gNB adopts the same method as UE based on base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 Keys in the key set k_2 may also be deduced.

Optionally, step 412: the base station gNB sends K to the UE _{_} The key in 1 performs security protection on the downstream data.

Alternatively, the downlink data may be buffered data of the base station gNB before receiving the second RRC Resume Request message.

Optionally, step 413: after receiving the downlink data from the base station gNB, the UE adopts the key in the newly generated key set K_2 to carry out security verification on the downlink data.

When the UE sends the second rrcresmerequest message, the gNB may have generated some downstream data that is security protected (e.g., encrypted) using k_1. After receiving these downlink data, the UE performs security verification (e.g., decryption) using the newly generated k_2, which causes a security verification (e.g., decryption) error.

Step 414: the base station gNB transmits a response message of the second RRC recovery request message to the UE.

The response message may be an RRC Resume (RRC Resume) message or an RRC Release (RRC Release) message. If the UE receives the RRC recovery message replied by the gNB, switching from an inactive state to a connection state, and starting to transmit non-SDT data; if the UE receives the RRC Release message replied by the gNB, ending the current SDT process, triggering the RRC connection recovery process, and transmitting non-SDT data after switching to a connection state.

Optionally, the response message is security protected based on the keys in the key set k_2.

As shown in fig. 8, a communication flow diagram is provided, which describes that the first RRC connection recovery procedure (which may also be referred to as a data or small data transmission procedure) of the UE in the Inactive state is not ended, and the UE triggers the RRC connection recovery procedure again. The flows of fig. 8 and 5 (i.e., RA-SDT that does not perform anchor relocation) can be considered as a general communication flow, which is described in two parts for ease of drawing. The method specifically comprises the following steps:

the UE determines that non-SDT data arrives, i.e., uplink data that cannot be transmitted in the RRC inactive state arrives.

Step 513: the UE starts a second RRC recovery procedure.

For example, the UE may key the base station K _gNB1 RRC integrity protection key K _RRCint1 The information is updated into the AS context of the active.

For example, the UE may be based on the base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 The method comprises the steps of carrying out a first treatment on the surface of the New RRC keys, new UP keys, etc. may also be derived. For example, the UE is K-based _gNB2 Deducing RRC integrity protection key K _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 . The application derives a new RRC integrity protection key K from the UE _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 The composed key set is denoted as k_2.

For example, the UE may also protect the key K based on RRC integrity _RRCint1 A message authentication code, such as resubmac-I or shortresummac-I, is derived for authentication.

Step 514: the UE sends a second RRC resume request message to the new serving base station (new gNB).

The second RRC recovery request includes the I-RNTI and the shortResecumeMAC-I or resubmeMAC-I generated above.

Step 515: the new Serving base station (new gNB) determines an anchor base station (Last Serving gNB) according to the I-RNTI, and sends a second request message to the anchor base station. Accordingly, the anchor base station receives a second request message from the new serving base station. The second request message is used for acquiring the context of the terminal or requesting the anchor point base station to transmit data or small data.

The second request message includes an I-RNTI, a resubmeMAC-I for verifying the identity of the UE, or a short resubmeMAC-I.

The second request message may be a get UE context request (RETRIEVE UE CONTEXT REQUEST) message.

Step 516: an anchor base station (Last Serving gNB) acquires a UE context according to the I-RNTI, and adopts the same method as the UE, and protects a key K based on RRC integrity _RRCint1 Deducing a resubmac-I or a short resubmac-I, and authenticating the identity of the UE by the gNB according to the resubmac-I or the short resubmac-I.

For example, the anchor base station acquires a UE context (e.g., an Inactive AS context) from the I-RNTI and protects the key K based on RRC integrity in the context using the same method AS the UE _RRCint1 Either ResumeMAC-I or shortresumeMAC-I is derived.

If the authentication is passed, the anchor base station adopts the same method as the UE and is based on the base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 New RRC keys, new UP keys (e.g., keys in key set k_2) may also be deduced.

Step 517: the anchor base station (Last Serving gNB) transmits a response message of the second request message to the new Serving base station (new gNB). Accordingly, the new serving base station receives the response message from the anchor base station.

Optionally, the response message is, for example, a failed acquisition UE context (RETRIEVE UE CONTEXT FAILURE) message.

The response message includes an RRC Release message.

Step 518: the new serving base station (new gNB) sends a response message of the second RRC recovery request to the UE, and the terminal receives the response message from the new serving base station. The response message is, for example, an RRC release message.

Optionally, step 519: the anchor base station (Last Serving gNB) transmits downlink data which is subjected to security protection by adopting the key in K_1 to the new Serving base station (new gNB).

Optionally, step 520: the new serving base station (new gNB) caches the downlink data for security protection using the key in K_1.

Step 519 and step 520 are performed before step 514.

Optionally, step 521: the new serving base station (new gNB) sends downlink data with security protection using the key in k_1 to the UE.

Optionally, step 522: after the UE receives the downlink data from the new serving base station (new gNB), the UE performs security verification (e.g., decryption) on the downlink data by using the key in the newly generated key set k_2, which may cause a security verification (e.g., decryption) error.

Steps 521 and 522 are performed before step 518.

It can be seen that if the new serving base station has cached downstream data from the anchor base station when the UE sends the second RRC Resume Request message, which is secured (e.g., encrypted) using the key in k_1, the new serving base station sends the secured (e.g., encrypted) downstream data to the UE. After receiving the downlink data, if the UE performs security verification on the downlink data by using the key in the k_2 set, a security verification (e.g. decryption) error may occur.

As shown in fig. 9, a communication flow diagram is provided, which describes that the first RRC connection recovery procedure (which may also be referred to as a data or small data transmission procedure) of the UE in the Inactive state is not ended, and the UE triggers the RRC connection recovery procedure again. The flows of fig. 9 and 6 (i.e., RA-SDT performing anchor relocation) can be regarded as a general communication flow, which is described in two parts for ease of drawing. The method specifically comprises the following steps:

the UE determines that non-SDT data arrives, i.e., uplink data that cannot be transmitted in the RRC inactive state arrives.

Steps 613 to 615 are the same as steps 513 to 515 in fig. 5, and a detailed description thereof will not be repeated.

Step 616 differs from step 516 in that it includes: in step 616 the anchor base station will not pull the new K for the push _{NG-RAN*_2} As an existing base station key K _gNB2 The rest is the same and the detailed description is not repeated.

Step 617: the anchor base station (Last Serving gNB) transmits a response message of the second request message to the new Serving base station (new gNB). Accordingly, the new serving base station receives the response message from the anchor base station.

Optionally, the response message includes the entire context of the UE, which may include the new K that was deduced in step 616 _NG-RAN*2 . The response message is, for example, a get UE context response (RETRIEVE UE CONTEXT RESPONSE) message.

Step 618a: the new serving base station (new gNB) may also be K-based _{NG-RAN*_2} Deducing (deriving) the keys in the set of keys K_2 and adding K _{NG-RAN*_2} As an existing base station key K _gNB2 。

Step 618b: the new serving base station (new gNB) sends a response message of the second RRC recovery request to the UE, and the terminal equipment receives the response message from the new serving base station. The response message is, for example, an RRC restore message.

Optionally, step 618c: the new Serving base station (new gNB) sends a UE context release (UE CONTEXT RELEASE) message to the anchor base station (Last Serving gNB) triggering the anchor base station to release the UE context.

Optionally, step 619: the new serving base station (new gNB) receives downlink data from the user plane function UPF network element.

Optionally, step 620: the new serving base station (new gNB) adopts the key in K_1 to carry out security protection on the downlink data, and caches the downlink data subjected to the security protection.

Step 619 and step 620 are performed before step 614.

Optionally, step 621: and the new serving base station (new gNB) sends the downlink data which adopts the key in the K_1 for security protection to the UE.

Optionally, step 622: after the UE receives the downlink data from the new serving base station (new gNB), the UE performs security verification (e.g., decryption) on the downlink data by using the key in the newly generated key set k_2, which may cause a security verification (e.g., decryption) error.

The sequence of step 621 and step 618 is not limited, and the sequence of step 622 and step 618 is not limited.

It can be seen that if the new serving base station has buffered downlink data secured with the key in k_1 when the UE sends the second RRC Resume Request message, the new serving base station sends the secured (e.g., encrypted) downlink data to the UE. If the UE performs security verification on the downlink data by using the key in k_2 after receiving the downlink data, a security verification (e.g. decryption) error may occur.

In summary, it can be seen that in various scenarios, when non-SDT data arrives in the SDT process, the problem of error in downlink data security verification occurs in the terminal device. Based on the above, the application provides various technical schemes to avoid the error of the terminal equipment to verify the security of the downlink data.

Several examples are described below in conjunction with the accompanying drawings, in which features or content identified by dashed lines may be understood as optional operations or optional structures of embodiments of the application.

It is to be understood that the present application introduces a number of examples, and that the interpretation and action of the same words between the various examples may be referred to each other.

The new serving access network device and the anchor access network device are similar to the new serving base station and anchor base station described above, the base station being a specific example of an access network device.

As shown in fig. 10, a communication flow diagram is presented, comprising the steps of:

step 1001: the terminal device in the inactive state determines the first key if it is determined that the first type of data arrives.

The first key is used for transmitting the first type of data by the terminal equipment in the inactive state, or the first key is used for carrying out security protection on the first type of data transmitted between the access network equipment and the terminal equipment in the inactive state. The security protection may include encryption protection and/or integrity protection.

The first type of data may be data transmitted on a designated DRB, may also be referred to as data transmitted on an SDT DRB, may also be referred to as SDT data, or small data, etc.

The first key may include, but is not limited to, one or more of the following keys: k (K) _{NG-RAN*_1} Base station key K _gNB1 RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 。

Optionally, before step 1001, the terminal device may further receive an RRC release message from the access network device, and the terminal device transitions from the connected state to the inactive state.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1001 may be the same as step 403; the processes described in steps 401 and 402 may also be performed before step 1001.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 6 and 9, and step 1001 may be the same as step 603; the procedure described in step 601 and step 602 may also be performed before step 1001. The access network device in the example of fig. 10 is the new serving base station in the examples of fig. 6 and 9.

Step 1002: the terminal device (still in an inactive state) may send an RRC request message to the access network device, and the access network device receives the RRC request message from the terminal device, accordingly.

The RRC request message is for requesting recovery of the RRC connection, and may be an RRC recovery request message. The RRC request message herein may be referred to as a first RRC request message.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1002 may be the same as step 404; after step 1002, the procedure described in step 406 may also be performed, and the procedure described in step 407 may further be performed.

In an example, the example of fig. 10 may be applied in the application scenarios of fig. 6 and fig. 9, where the access network device in fig. 10 is a new serving base station in the examples of fig. 6 and fig. 9, and step 1002 may be the same as step 604; after step 1002, the process described in step 612b may also be performed.

Step 1003: the access network device determines a first key upon receiving a first RRC request message from the terminal device in an inactive state.

The access network device determines the first key in the same way as the terminal device.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1003 may be the same as step 405.

In an example, the example of fig. 10 may be applied to the application scenarios of fig. 6 and 9, and step 1003 may be the same as step 608 a.

Step 1004: the terminal device (still in the inactive state) determines the second key in case it is determined that the second class data arrives.

The second key is used for transmitting the second type of data in the connection state of the terminal equipment, or the second key is used for carrying out security protection on the second type of data transmitted between the access network equipment and the terminal equipment in the connection state. The security protection may include encryption protection and/or integrity protection.

The second type of data may be data transmitted on a non-designated DRB, may also be referred to as data transmitted on a non-SDT DRB, may also be referred to as non-SDT data, or non-small data, etc. The second type of data here is uplink second type of data.

The second key may include, but is not limited to, one or more of the following keys: k (K) _{NG-RAN*_2} Base station key K _gNB2 RRC integrity protection key K _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 。

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1004 may be the same as step 409; the process described in step 406 may also be performed before step 1004, and the process described in step 407 may also be performed. It should be noted that before performing step 1004, the terminal device does not receive the RRC Release message from the access network device, and may also be understood that the procedure described in step 408 is not performed.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 6 and 9, where step 1004 may be the same as step 613, and the process described in step 612b may also be performed before step 1004. It is noted that before performing step 1004, the terminal device does not receive an RRC Release message from the access network device.

Step 1005: the terminal device (still in an inactive state) sends an RRC request message to the access network device, and the corresponding access network device receives the RRC request message from the terminal device.

The RRC request message is used to request recovery of the RRC connection. The RRC resume request message herein may be referred to as a second RRC resume request message.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1005 may be the same as step 410.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 6 and 9, and step 1005 may be the same as step 614.

Step 1006: the access network device determines a second key in case of receiving a second RRC request message from the terminal device in an inactive state.

The access network device determines the second key in the same way as the terminal device.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1006 may be the same as step 411.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 6 and 9, and step 1006 may be the same as step 618 a.

Step 1007: the terminal device (still in an inactive state) receives the first type of data from the access network device before receiving the RRC response message from the access network device. Correspondingly, the access network device sends the first type data to the terminal device before sending the RRC response message to the terminal device.

The first type of data is downlink first type of data. After sending the RRC request message, the UE receives the first type of data before receiving the RRC response message, where the first type of data may be security protected with a first key.

The RRC response message is used to respond to the RRC request message, for example, an RRC resume message, or an RRC release message.

In one example, before sending an RRC response message to a terminal device, an access network device uses the first key to secure the first type of data, and sends the first type of data to the terminal device (which is still in an inactive state).

The first type of data may be security protected by the access network device before or after receiving the second RRC request message from the terminal device in the inactive state.

If the first type of data is secured before the access network device receives the second RRC request message from the terminal device in the inactive state, the first type of data is secured with the first key, typically. If the first type of data is security protected after the access network device receives the second RRC request message from the terminal device in the inactive state, the first type of data is security protected with a second key, typically. In an alternative example of the present application, it may also be provided that, after the access network device receives the second RRC request message from the terminal device in the inactive state, the first key is used to perform security protection on the first type of data.

Step 1008a and step 1008b may select one to execute.

In an alternative implementation, step 1008a is performed: the terminal device (still in an inactive state) uses the first key to perform security verification on the first type of data.

As illustrated in fig. 7, when the UE receives the downlink first type data after sending the second RRC request message (or determining the second key), the UE generally uses the newly generated second key to perform security verification (e.g., decryption) on the downlink first type data, but if the downlink first type data uses the first key for security protection, an error in security verification (e.g., decryption) is caused. In the application, after the terminal device sends the second RRC request message, before receiving the response message (e.g. RRC resume or RRC release message) of the second RRC request message, if the downlink first type data is received, the security verification (e.g. decryption) is performed on the downlink first type data by using the first key, so that security verification errors will not occur, and further, wrong data can be prevented from being delivered to an upper layer.

In an alternative implementation, step 1008b is performed: the terminal device (still in inactive state) discards the first type of data.

If the terminal device receives the downlink data after sending the second RRC request message, the security verification error will not occur if the downlink data is directly discarded, and further, the wrong data can be prevented from being delivered to an upper layer.

Step 1009: the access network device sends an RRC response message to the terminal device, and correspondingly, the terminal device may receive the RRC response message from the access network device.

The RRC response message is used to respond to the RRC request message, for example, an RRC resume message, or an RRC release message.

The RRC response message may use the second key for security protection.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1009 and step 414 may be the same.

In one example, the example of fig. 10 may be applied to the application scenarios of fig. 4 and 7, and step 1009 may be the same as step 618 a.

As shown in fig. 11, in another example, a communication flow is presented that is applicable to CU and DU split architecture. This example may be applicable to the same scenario where sending an RRCRelease message turns the UE from Connected to Inactive state gNB and the serving gNB when the UE initiates SDT. For explanation and role of names of the first key, the second key, the first type data, the second type data, the first RRC request message, the second RRC request message, etc., reference may be made to the description in the example of fig. 10, and the detailed description will not be repeated.

Step 1101: the distributed unit DU (which may be referred to as a gNB-DU) sends a first RRC request message to the centralized unit CU (e.g. the control plane CU, which may be referred to as a gNB-CU-CP), and the centralized unit CU receives the first RRC request message from the DU, accordingly. The first RRC request message is from the terminal device in an inactive state, and is used to request recovery of the RRC connection.

Step 1102: the centralized unit CU (e.g. control plane CU) determines the first key in case of receiving a first RRC request message from the DU. The first key is used for transmitting first-class data with the terminal equipment in the inactive state.

Step 1103: the DU sends a second RRC request (e.g., RRC resume request) message to the CU (e.g., control plane CU), and the corresponding CU receives the second RRC request message from the DU. And the second RRC recovery request message is from the terminal equipment in the inactive state, and is used for requesting to recover the RRC connection.

After receiving the second RRC request message sent by the UE, the DU sends the second RRC request message to the CU (e.g., control plane CP) through an INITIAL uplink RRC message transmission (INITIAL UL RRC MESSAGE TRANSFER) message.

Step 1104: the centralized unit CU, e.g. the control plane CU, determines a second key. The second key is used for transmitting second class data with the terminal equipment in a connection state.

Optionally, the CU may perform user authentication on the terminal device according to information in the second RRC request message, and determine the second key after the authentication is passed. This procedure may refer to the procedure of authentication of the UE by the base station in fig. 7, and will not be described in detail.

Step 1105: a CU, such as a control plane CU or a user plane CU (which may be referred to as a gNB-CU-UP), sends first indication information to the DU, the first indication information being used to instruct the DU to clear the first type of data.

Step 1106: the DU clears (or discards, deletes, etc.) the first class of data in response to the first indication information.

In an alternative example, when the CU sends the first indication information to the DU, it may be that the user plane CU sends the first indication information to the DU. When the user plane CU sends first indication information to the DU, for example: the USER plane CU sends a downlink USER DATA (DL USER DATA) message to the DU, the downlink USER DATA message comprising the first indication information. The first indication information sent by the user plane CU to the DU may be used to indicate that the DU clears downlink data, where the first indication information includes identification information (for example, an index, may also be understood as a flag of a PDCP protocol data unit (protocol data unit, PDU)) of downlink data to be cleared, where the downlink data to be cleared is data in cached downlink data, and the cached downlink data is data of a first type. The control plane CU derives a new second key and then sends a bearer context modification request (BEAR CONTEXT MODIFICATION REQUEST) message to the user plane CU, carrying an indication to resume the non-SDT Radio Bearer (RB). After the USER plane CU receives the DATA, it triggers to send a downlink USER DATA (DL USER DATA) message to the DU, where the downlink USER DATA (DL USER DATA) message carries first indication information, and the first indication information indicates downlink DATA information to be cleared. After receiving the downlink USER DATA (DL USER DATA) message, the DU deletes the downlink DATA indicated in the DL USER DATA message.

In an alternative example, when the CU sends the first indication information to the DU, it may be that the control plane CU sends the first indication information to the DU. When the control plane CU sends first indication information to the DU, for example: the control plane CU sends a UE context setup request (UE CONTEXT SETUP REQUEST) message to the DU, the UE context setup request message comprising the first indication information. The first indication information sent by the CU to the DU may be used to instruct the DU to clear all buffered downlink data, where the buffered downlink data is a first type of data. Of course, the control plane CU may also send the first indication information to the DU alone, informing the DU to clear all buffered downlink data, where the buffered downlink data is the first type of data.

Step 1107: after sending the first indication information to the DU, the CU (e.g. control plane CU) sends an RRC response message of the second RRC request message to the DU.

In the prior art, if there is buffered downlink data on the DU side, the data will be sent to the terminal device in the inactive state. However, since the buffered downlink data is secured with the first key, and the UE has determined the second key before sending the second RRC request message, if the buffered downlink data is continued to be sent to the UE, an error in security verification (e.g. decryption) at the UE side may be caused. In this example, after receiving the second RRC request message, the CU instructs the DU to delete the buffered downlink data, avoiding wasting transmission resources, and also avoiding UE security verification errors.

As shown in fig. 12, a schematic communication flow diagram is presented, and this example may be applicable to the scenario where sending an RRCRelease message changes the UE from Connected to Inactive state gNB and serving gNB when the UE initiates SDT. This fig. 12 is described in detail on the basis of fig. 11.

The method comprises the following steps:

step 1201: the control plane CU sends an RRC release message to the terminal device, and correspondingly, the terminal device receives the RRC release message from the control plane CU.

The RRC release message may refer to the description of step 401, and will not be repeated.

Step 1202 (same as step 402): the terminal device transitions from the connected state to the inactive state.

Step 1203 (and step): when the first type of data (e.g., SDT data) arrives, the UE initiates a first RRC connection recovery procedure.

For example, the terminal device determines a first key including, but not limited to, one or more of the following: k (K) _{NG-RAN*_1，} Base station key K _gNB1 RRC integrity protection key K _RRCint1 RRC encryption key K _RRCenc1 Integrity protection key K for user plane _UPint1 And encryption key K of user plane _UPenc1 。

The process of step 1203 may refer to the process of step 403, and the repetition is not repeated.

Step 1204: the UE sends a first RRC request message, such as an RRC resume request (RRC Resume Request), message to the DU. Accordingly, the DU receives a first RRC resume request (RRC Resume Request) message from the UE.

The process of step 1204 may refer to the process of step 404, and the repetition is not repeated.

Step 1205: the DU buffers the uplink data (buffer UL data).

Step 1206: the DU sends a first RRC recovery request to the control plane CU, which may be carried in an INITIAL uplink RRC message transmission (INITIAL UL RRC MESSAGE TRANSFER) message.

Step 1207: the control plane CU determines the first key.

The process of step 1207 may refer to the process of step 405, and the repetition is not repeated.

Step 1208: the control plane CU sends a UE context setup request to the DU (UE CONTEXT SETUP REQUEST), and the DU receives the UE context setup request from the control plane CU accordingly.

Step 1209: the DU sends a UE context setup response (UE CONTEXT SETUP RESPONSE) to the control plane CU, and correspondingly, the control plane CU sends a UE context setup response to the DU.

Step 1210: the control plane CU sends a bearer context modification request (BEAR CONTEXT MODIFICATION REQUEST) to the user plane CU, which receives BEAR CONTEXT MODIFICATION REQUEST the control plane CU accordingly.

Step 1211: the user plane CU sends a bearer context modification response (BEAR CONTEXT MODIFICATION RESPONSE) to the control plane CU, which receives BEAR CONTEXT MODIFICATION RESPONSE the user plane CU accordingly.

Step 1212: after the DU sends the UE context setup response to the control plane CU, the DU may send uplink data to the user plane CU.

Step 1213: the UE determines that non-SDT data arrives, i.e., uplink data that cannot be transmitted in the RRC inactive state arrives. The UE starts a second RRC recovery procedure.

For example, the terminal device determines a second key including, but not limited to, one or more of the following: k (K) _{NG-RAN*_2，} Base station key K _gNB2 RRC integrity protection key K _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _UPint2 And encryption key K of user plane _UPenc2 。

Step 1214: the UE sends a second RRC resume request (RRC Resume Request) message to the DU. Accordingly, the DU receives a second RRC resume request (RRC Resume Request) message from the UE.

The process of step 1214 may refer to the process of step 410, and is repeated without further description.

Before the DU receives the second RRC recovery request from the UE, the DU performs steps 1215 and 1216.

Step 1215: the DU receives first type data (downlink data) for security protection using a first key, which is transmitted from the user plane CP.

Step 1216: the DU caches the first type of data for security protection using the first key.

Step 1217: the DU, after receiving the second RRC recovery request, sends a second RRC recovery request to the control plane CU, where the second RRC recovery request may be carried in an INITIAL uplink RRC message transmission (INITIAL UL RRC MESSAGE TRANSFER) message.

Step 1218: the control plane CU determines the second key.

The process of step 1218 may refer to the process of step 411, and the repetition is not repeated.

In an alternative example, after step 1218, step 1219a is performed.

Step 1219a: the control plane CU sends a resume instruction information to the user plane CU, the resume instruction information being carried in the bearer context modification request (BEAR CONTEXT MODIFICATION REQUEST).

After receiving the recovery indication information, the USER plane CU triggers transmission of a downlink USER DATA (DL USER DATA) message (trigger the transfer of DL USER DATD).

The USER plane CU sends a downlink USER DATA (DL USER DATA) message to the DU, said downlink USER DATA message comprising said first indication information. The first indication information sent by the user plane CU to the DU may be used to indicate that the DU clears downlink data, where the first indication information includes identification information (for example, an index, or may be understood as a reference number of a PDCP PDU) of downlink data that needs to be cleared, where the downlink data that needs to be cleared is data in cached downlink data, and the cached downlink data is first type data.

In an alternative example, after step 1218, step 1219b is performed.

Step 1219b: the control plane CU sends a UE context setup request (UE CONTEXT SETUP REQUEST) message to the DU, the UE context setup request message comprising the first indication information. The first indication information sent by the CU to the DU may be used to indicate that all buffered downlink data is cleared, where the buffered downlink data is a first type of data.

In an alternative example, after step 1218, step 1219c is performed.

Step 1219c: the control plane CU sends first indication information to the DU, where the first indication information may be used to indicate that the DU clears downlink data, and the first indication information includes identification information (for example, an index, may also be understood as a reference number of a PDCP PDU) of downlink data that needs to be cleared, where the downlink data needs to be cleared is data in cached downlink data, and the cached downlink data is a first type of data.

Step 1220: and the DU responds to the first indication information and clears the corresponding first type data.

The first type of data may be the first type of data in step 1215 and step 1216.

In another example, after sending the RRCRelease message to change the UE from Connected to Inactive state, the serving gNB is different from the serving gNB when the UE initiates SDT, and the anchor access network device (e.g., the anchor base station described in the example of fig. 5 and 8) receives the second RRC recovery request message in a scenario of RA-SDT where anchor relocation is not performed (e.g., the scenario described in the example of fig. 5 and 8), the new base station may be instructed to delete the buffered downlink data.

The new serving access network device receives a first radio resource control RRC request message from the terminal device in an inactive state, the first RRC request message being used to request recovery of an RRC connection (refer to the procedure of step 504);

the new serving access network device receives a second RRC request message from the terminal device in an inactive state (refer to the procedure of step 514); the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message;

the new serving access network device sends a request message to the anchor access network device, where the request message is used to request to acquire the context of the terminal device (refer to the procedure of step 515);

the new service access network device receives a response message for the request message from the anchor access network device;

and before the new service access network equipment sends a response message of the second RRC recovery request message to the terminal equipment, the cached first-class data is cleared.

In one example, the response message is a failed to acquire UE context (RETRIEVE UE CONTEXT FAILURE) message, optionally including RRC release. Based on the response message, the new service base station deletes all cached downlink data, wherein the cached downlink data is the first type data.

In an example, the response message includes second indication information, where the second indication information is used to instruct the new service access network device to clear all buffered downlink data, where the buffered downlink data is the first type of data; optionally, the response message is a UE context acquisition failure (RETRIEVE UE CONTEXT FAILURE) message, where the response message includes RRC release.

In an example, the second indication information is used to indicate identification information (for example, an index, which may also be understood as a reference number of PDCP PDU) of downlink DATA to be cleared, where the downlink DATA to be cleared is DATA in the downlink DATA cached by the new serving access network device, and the cached downlink DATA is the first type of DATA, and optionally, the response message is a downlink USER DATA (DL USER DATA) message.

The new serving access network device sends RETRIEVE UE CONTEXT REQUEST a message to the anchor serving access network device after receiving the second RRCResumeRequest message from the terminal device. The anchor service access network device knows that the second RRC connection recovery process initiated by the same UE is performed according to the I-RNTI in the RRCResumeRequest message, and then:

In one example, the anchor serving access network replies RETRIEVE UE CONTEXT FAILURE to the new serving access network device, carrying the RRCRelease message. After receiving the RETRIEVE UE CONTEXT FAILURE message, the new base station can automatically delete all the cached downlink data. Optionally, when the anchor access network device replies RETRIEVE UE CONTEXT FAILURE to the new service access network device, the anchor access network device carries the second indication information in the message to inform the new service access network device to clear all the cached downlink data. And after receiving the indication, the new service access network equipment deletes all cached downlink data.

In another example, the anchor access network device sends a DL USER DATA message to the new serving access network device, carrying downlink DATA information (e.g., an index, which may also be understood as a reference number of PDCP PDUs) to be deleted. After receiving the DL USER DATA message, the new service access network device deletes the downlink DATA specified in the message.

In the prior art, if the new service access network device has cached downlink data, the new service access network device will continue to send to the UE. However, since the buffered downlink data is secured by using the first key, and the UE has already determined the second key before sending the second RRCResumeRequest message, if the downlink data secured by using the first key is continued to be sent to the UE, a security verification error at the UE side may be caused. In this example, after the anchor access network device learns that the second RRC recovery procedure initiated by the same UE through the I-RNTI, the anchor access network device instructs the new serving access network device to delete the buffered downlink data, avoiding wasting transmission resources, and avoiding occurrence of security verification errors by the UE.

As described above, in the scenario of RA-SDT (e.g., the scenario described in the examples of fig. 6 and 9) where the serving gNB is different when sending the RRCRelease message to switch the UE from Connected to Inactive state and the UE initiates SDT, and the anchor relocation is performed:

on the one hand, when the UE initiates the first RRC connection recovery procedure, in step 606, the anchor base station estimates K _{NG-RAN*_1} And the keys in the key set k_1; in step 608, the anchor base station will K _{NG-RAN*_1} Transmitting to a new service base station; in step 608a, when the new serving base station receives K _{NG-RAN*_1} And then, the keys in the key set K_1 are deduced, and the K_1 is used for carrying out security protection on the downlink data in the subsequent SDT process. Next, when the UE initiates a second RRC connection recovery procedure, the anchor base station needs to authenticate the UE with the key in the key set k_1 (e.g., by RRC integrity protection key K in step 616 _RRCint1 Deducing resubmac-I or shortresummac-I, where the keys in the key set k_1 are used in both the anchor base station and the new serving base station, causes security problems.

On the other hand, although the new serving base station has acquired the UE context in the SDT procedure through steps 605 and 608, since the I-RNTI still identifies the UE and the anchor base station, after the UE transmits the second rrcresmerequest message (e.g., step 614) when the non-SDT data arrives, the new serving base station still needs to transmit the RETRIEVE UE CONTEXT REQUEST message to the anchor base station (e.g., step 615), performs UE identity authentication by the anchor base station (e.g., step 616), and replies RETRIEVE UE CONTEXT RESPONSE message to the new serving base station again after the authentication is completed (e.g., step 617), which results in a large signaling overhead.

In yet another aspect, the anchor base station needs to keep the UE context until the non-SDT data transmission ends, which consumes memory resources of the anchor base station.

In one example, an RRCRelease message (e.g., step 1312, below) may be sent to the UE (still in an inactive state) after the new serving access network device receives a path switch request acknowledgement (path switch request acknowledge) message (e.g., step 611) from a core network element (e.g., AMF or SMF) in an RA-SDT performing anchor relocation (e.g., the scenario introduced by the examples of fig. 6 and 9). Optionally, the RRCRelease message carries an indication information, where the indication information is used to instruct the UE to initiate a new SDT procedure. And the new serving access network device sends a UE context release (UE CONTEXT RELEASE) message to the anchor access network device (e.g., step 1313, below).

As shown in fig. 13, a communication flow is presented, comprising the steps of:

step 1301: the anchor access network device (Last serving gNB) sends an RRC Release message to the UE, and instructs the UE to enter an Inactive state.

Step 1301 may refer to the process of step 601 and will not be described in detail.

Step 1302: after receiving the RRC release message, the UE changes from the Connected state to the Inactive state.

Step 1302 may refer to the process of step 602 and will not be described in detail.

Step 1303: when the SDT data arrives, the UE triggers a first RRC connection recovery procedure.

For example, the first key is determined, and the first key may be referred to the description above, and will not be repeated.

Step 1303 may refer to the process of step 603, and will not be described in detail.

Step 1304: the UE sends a first RRC request to a new serving access network device (new gNB).

The first RRC request message may be a first RRC resume request message. Step 1304 may refer to the process of step 604, and will not be repeated.

Step 1305: the new Serving access network device (e.g. new gNB) determines an anchor access network device (e.g. Last Serving gNB) according to the I-RNTI, and sends a first request message to the anchor access network device. Accordingly, the anchor access network device receives a first request message from the new serving access network device. The first request message is used for acquiring the context of the terminal or requesting the anchor point access network equipment to transmit data or small data.

The first request message comprises an I-RNTI, a resubmeMAC-I for verifying the identity of the UE or a short resubmeMAC-I. The first request message may be a get UE context request (RETRIEVE UE CONTEXT REQUEST) message.

Step 1305 may refer to the process of step 605 and will not be repeated.

Step 1306: an anchor access network device (Last Serving gNB) determines the first key.

Step 1306 may refer to the process of step 606, and will not be repeated.

Step 1307 (same as step 607): an anchor access network device (Last Serving gNB) decides to perform anchor relocation.

Step 1308: the anchor access network device (Last Serving gNB) sends a response message of the first request message to the new Serving access network device (new gNB). Accordingly, the new serving access network device receives the response message from the anchor access network device.

Step 1308 may refer to the process of step 608, and will not be repeated.

Step 1308a: the new serving access network device determines a first key.

Step 1308a may refer to the process of step 608a, and will not be repeated.

Optionally, step 1309 (same as step 609): the new Serving access network device (new gNB) sends an address indication (Xn-U address indication) of the new Serving access network device to the anchor access network device (Last Serving gNB), the address indication being used to inform the anchor access network device of the tunnel address for forwarding downstream data.

Step 1310 (same as step 610): the new serving access network device sends a path switch request (path switch request) to a core network element (e.g., AMF or SMF), and the new serving access network device establishes a path with the core network.

Step 1311 (same as step 611): the new serving access network device receives a path switch request acknowledgement (path switch request acknowledge) message from a core network element (e.g., AMF or SMF).

Step 1312: the new serving access network device sends an RRCRelease message to the UE (still inactive). Optionally, the RRCRelease message carries an indication information, where the indication information is used to instruct the UE to initiate a new first type data transmission process, for example, the first type data transmission process is an SDT process.

Typically, the RRC RELEASE message includes a new I-RNTI, identifying the UE and the new access network device, and downstream data is also sent in this step.

Using K _{RRC-int 1} And K _gNB1 Updating AS context of UE active (updates UE lnactive AS context with K) _{RRCint 1} and K _gNB-1 )。

Step 1313: the new Serving access network device sends a UE context release (UE CONTEXT RELEASE) message to the anchor access network device (Last Serving gNB) triggering the anchor access network device to release the UE context.

Step 1314: the UE (still in an inactive state) initiates a second RRC recovery procedure, e.g., for transmitting the first type of data that was not sent in the first RRC recovery procedure.

For example, the UE determines the second key. The principle is the same as in step 1303.

For example, the UE may key the base station K _gNB1 RRC integrity protection key K _RRCint1 The information is updated into the AS context of the active.

For example, the UE may be based on the base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 The method comprises the steps of carrying out a first treatment on the surface of the New RRC keys, new UP keys, etc. may also be derived. For example, the UE is K-based _gNB2 Deducing RRC integrity protection key K _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 . The application derives a new RRC integrity protection key K from the UE _RRCint2 RRC encryption key K _RRCenc2 Integrity protection key K for user plane _Upint2 And encryption key K of user plane _Upenc2 The composed key set is denoted as k_2.

For example, the UE may also protect the key K based on RRC integrity _RRCint1 A message authentication code resubmac-I or shortresummac-I for authentication is derived.

Step 1315: the UE sends a second RRC request to the new serving access network device (new gNB).

The second RRC request may be a second RRC resume request message. The second RRC recovery request includes the new I-RNTI determined in step 1312, the shortResumeMAC-I or resumeMAC-I generated in step 1314.

K may also be sent in this step _UPenc2 Encrypted upstream data.

Step 1316: the new serving access network device determines a second key. The principle is the same as in step 1308 a.

For example, the new access network device acquires the UE context according to the I-RNTI and adopts the same method as the UE to protect the key K based on RRC integrity _RRCint1 Deducing a resubmac-I or a shortresummac-I, and authenticating the UE by the new service access network device according to the resubmac-I or the shortresummac-I.

For example, the gNB obtains a UE context (e.g., an Inactive AS context) from the I-RNTI and uses the same method AS the UE based on the base station key K in the context _gNB1 Either ResumeMAC-I or shortresumeMAC-I is derived.

If passing the verification, gNB adopts the same method as UE based on base station key K _gNB1 Deducing new K _{NG-RAN*_2} Will K _{NG-RAN*_2} As an existing base station key K _gNB2 Keys in the key set k_2 may also be deduced.

Step 1317 (same as step 612 b): the new serving access network device (new gNB) sends a response message of the second RRC request to the UE, and the terminal receives the response message from the new serving access network device.

For example, the response message may be message B or message 4, and the new serving access network device may also send downlink data to the UE.

The response message marks the end of the initial transmission of RA-SDT.

Optionally, the UE may also perform subsequent transmission of SDT data.

Step 1318: the UE determines that non-SDT data arrives, i.e., uplink data that cannot be transmitted in the RRC inactive state arrives. The UE starts the third RRC recovery procedure.

The UE determines a third key including, but not limited to, one or more of the following keys: k (K) _{NG-RAN*_3} Access network device key K _gNB3 RRC integrity protection key K _RRCint3 RRC encryption key K _RRCenc3 Integrity protection key K for user plane _Upint3 And encryption key K of user plane _Upenc3 。

Step 1318 may refer to the process of step 613, except that the key name is changed from 1 to 2 and from 2 to 3, the principle being the same, and the specific process will not be described in detail.

Step 1319: the UE sends a third RRC restoration request message to the new serving access network device (new gNB).

The process of step 1319 may refer to the process of step 614, and will not be repeated. The third RRC recovery request message includes the new I-RNTI determined in step 1312.

Step 1320: the new serving base station determines a third key.

For example, the new serving access network device determines that the third RRCRumeRequest and the second RRCRumeRequest are from the same UE based on the I-RNTl, and may protect the key K based on RRC integrity _RRCint2 Deducing a resubmac-I or a shortresummac-I, and authenticating the UE by the new service access network device according to the resubmac-I or the shortresummac-I.

For example, the new serving base station acquires a UE context (e.g., an active AS context) from the I-RNTI and adopts the same method AS the UE based on the base station key K in the context _gNB2 Either ResumeMAC-I or shortresumeMAC-I is derived.

If passing the verification, gNB adopts the same method as UE based on base station key K _gNB2 Deducing new K _{NG-RAN*_3} Will K _{NG-RAN*_3} As an existing base station key K _gNB3 Keys in the key set k_3 may also be deduced.

Step 1321: the new serving access network device sends an RRC restoration message to the UE.

In the second prior art, the situation that the last serving base station and the new base station use the krrcint_1 key simultaneously has a security problem, and in addition, the new base station needs to repeatedly request the UE context from the last serving base station, which causes a large signaling overhead. In this example, the new base station sends the RRCRelease message to the UE after completing the path switching, and allocates a new I-RNTI to the UE, where the I-RNTI identifies the UE and the new base station, so that when non-SDT data arrives in the subsequent SDT process, the new base station can directly perform identity authentication on the UE after receiving the RRCResumeRequest message carrying the I-RNTI, thereby avoiding repeated sending of UE CONTEXT REQUEST message to the last serving base station and avoiding security problem caused by the same key being used in different base stations. In addition, after the new base station completes the path switching, the last service base station can be informed to clear the context of the UE, and the storage resources of the last service base station are saved.

In another example, the I-RNTI may be carried in RETRIEVE UE CONTEXT RESPONSE messages replied to the new access network device when the last serving access network device decides to perform anchor relocation after receiving RETRIEVE UE CONTEXT REQUEST messages in RA-SDT performing anchor relocation (e.g., the scenario introduced by the examples of fig. 6 and 9).

The new serving access network device receives a first radio resource control RRC request message (refer to the procedure of step 604) from the terminal device in the inactive state, where the first RRC request message is used to request to restore an RRC connection;

the new serving access network device receives a second RRC request message from the terminal device in an inactive state (refer to the procedure of step 614); the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message; the second RRC request message comprises a first identifier, wherein the first identifier is used for determining the context of the terminal equipment; the first identifier may be an I-RNTI, which may be an I-RNTI carried in the first RRC request message in step 604 or an I-RNTI carried in the terminal device context response message in step 608.

The new service access network device determines the context of the terminal device based on the first identifier, where the context of the terminal device is the context of the terminal device received by the new service access network device from the anchor access network device in the first type of data transmission process (refer to the process of step 608); the new service access network device determines a second key based on information in the context of the terminal device, the second key being used for transmitting second class data with the terminal device in a connected state.

The method can be suitable for the anchor point relocation, and after receiving the first RRC request message from the terminal equipment, the new service access network equipment can also receive a context response message of the terminal equipment from the anchor point access network equipment before receiving the second RRC request message from the terminal equipment, wherein the context response message of the terminal equipment comprises all the contexts of the terminal equipment. The process may refer to the process of step 608, and will not be repeated.

In an alternative example, the new serving access network device may further receive the first identifier from the anchor access network device after receiving the first RRC request message from the terminal device and before receiving the second RRC request message from the terminal device, and associate the first identifier with the context of the terminal device. For example, the new serving access network device may receive, when receiving the first identifier from the anchor access network device, an acquire terminal device context response (RETRIEVE UE CONTEXT RESPONSE) message from the anchor access network device, where the acquire terminal device context response message includes the first identifier. For example, the first identity, e.g., I-RNTI, is carried in step 608. For another example, the anchor access network device may send the first identification to the new serving access network device alone or in a new message.

The new serving access network device determines the second key instead of the anchor access network device, without the anchor access network device determining the second key (steps 615-618a are no longer performed), which may avoid security problems caused by the same key being used in different access network devices. The process of determining the second key by the new serving access network device may refer to the process performed by the anchor point base station in step 616, and will not be described in detail. The new serving access network device may also send an RRC restore message to the UE after determining the second key.

In an alternative example, the first identifier is included in the first RRC request message (e.g., the first identifier, e.g., I-RNTI, is included in step 604); the new serving access network device may also receive an acquire terminal device context response (RETRIEVE UE CONTEXT RESPONSE) message (e.g., step 608) from the anchor access network device after receiving the first RRC request message from the terminal device and before receiving the second RRC request message from the terminal device, triggering the association of the first identity with the context of the terminal device. For example, the context response message of the terminal equipment includes third indication information, where the third indication information is used to instruct to verify the terminal equipment, or instruct the new serving access network equipment to verify the terminal equipment in the second RRC recovery process, or instruct the new serving base station to store the first identifier in the first RRC request message, or instruct the new serving access network equipment to associate the first identifier with the context of the terminal equipment.

The new serving access network device may save the first identity, e.g. the I-RNTI, after receiving the third indication information or the terminal device context response (RETRIEVE UE CONTEXT RESPONSE) message.

In the examples of fig. 6 and 9, it may appear that the anchor base station and the new serving base station use the first key simultaneously (e.g., K _{RRCint_1} Key), there is a security problem, and the new serving base station needs to repeatedly request to the anchor base stationUE context is found, which results in a large signaling overhead. In this example, the new serving base station sends the I-RNTI to the new serving base station in the response (RETRIEVE UE CONTEXT RESPONSE) message of acquiring the context of the terminal device, or the new serving base station receives the I-RNTI from the UE, and subsequently, when second type data (e.g., non-SDT data) arrives, the new serving base station may directly perform identity authentication on the UE after receiving a second rrcreseumerequest message containing the new I-RNTI, thereby avoiding the new serving base station repeatedly requesting the UE context from the anchor base station, and also avoiding the security problem caused by the use of the same key at a different base station.

In yet another example, the new access network device may allocate a new I-RNTI to the UE after completing the path switch in RA-SDT performing anchor relocation (e.g., the scenario introduced by the examples of fig. 6 and 9), which may be carried in the rrcrecon configuration message or in the new RRC message.

The method comprises the steps that a new service access network device receives a first Radio Resource Control (RRC) request message from a terminal device in an inactive state, wherein the first RRC request message is used for requesting to recover RRC connection; the first RRC request message includes a first identity, where the first identity is used to determine a context of the terminal device (may refer to the procedure of step 604), and the first identity may be an I-RNTI;

the new service access network equipment sends a second identifier to the terminal equipment, wherein the second identifier is used for determining the context of the terminal equipment; the second identity may be a new I-RNTI. The new I-RNTI may be carried in the rrcrecon configuration message or in a new RRC message.

The new serving access network device receives a second RRC request message from the terminal device in an inactive state (refer to the procedure of step 614); the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message; the second RRC request message includes the second identifier (note that in step 614, the second RRC recovery request message carries the first identifier (e.g., I-RNTI) still, and in this example, the second identifier (e.g., new I-RNTI) allocated by the new serving access network device to the UE);

The new service access network equipment determines the context of the terminal equipment based on the second identifier, wherein the context of the terminal equipment is sent by the anchor access network equipment in the small data transmission process;

the new service access network device determines a second key based on information in the context of the terminal device, the second key being used for transmitting second class data with the terminal device in a connected state.

Optionally, when the new service access network device sends the second identifier to the terminal device, the new service access network device may also send a next hop chain count NCC value to the terminal device.

The new serving access network device determines the second key instead of the anchor access network device, and the anchor access network device is not required to determine the second key (steps 615-618a are not executed any more), so that the security problem caused by the fact that the same key is used in different access network devices can be avoided, and the storage resources of the anchor access network device can be saved. The process of determining the second key by the new serving access network device may refer to the process performed by the anchor point base station in step 616, and will not be described in detail. The new serving access network device may also send an RRC restore message to the UE after determining the second key.

In the examples of fig. 6 and 9, a situation may occur in which the anchor base station and the new serving base station use the first key (e.g., krrcint_1 key) at the same time, which has a security problem, and in addition, the new serving base station needs to repeatedly request the UE context from the anchor base station, which may cause a signaling overhead to be large. In this example, after the new serving base station completes path switching, a new I-RNTI is allocated to the UE, and then when second class data (e.g., non-SDT data) arrives, the new serving base station may directly perform identity authentication on the UE after receiving a second rrcresmerequest message containing the new I-RNTI, so as to avoid the new serving base station repeatedly requesting the UE context from the anchor base station, and also avoid the security problem caused by the use of the same key in different base stations.

The foregoing describes a method of an embodiment of the present application, and the following describes an apparatus of an embodiment of the present application. The method and the device are based on the same technical conception, and because the principles of solving the problems by the method and the device are similar, the implementation of the device and the method can be mutually referred to, and the repeated parts are not repeated.

The embodiment of the application can divide the functional modules of the device according to the method example, for example, the functional modules can be divided into the functional modules corresponding to the functions, or two or more functions can be integrated into one module. These modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be adopted in specific implementation.

Based on the same technical concept as the above method, referring to fig. 14, there is provided a schematic structural diagram of a communication apparatus 1400, and the apparatus 1400 may include: the processing module 1410, optionally, further comprises a receiving module 1420a, a sending module 1420b, and a storage module 1430. The processing module 1410 may be connected to the storage module 1430 and the receiving module 1420a and the transmitting module 1420b, respectively, and the storage module 1430 may also be connected to the receiving module 1420a and the transmitting module 1420 b.

In one example, the receiving module 1420a and the transmitting module 1420b may be integrated together, and may be defined as a transceiver module.

In one example, the apparatus 1400 may be a terminal device, or may be a chip or a functional unit applied in the terminal device. The apparatus 1400 has any of the functions of the terminal device in the above method, for example, the apparatus 1400 can perform the steps performed by the terminal device in the above methods of fig. 10, 11, 12, and 13.

The receiving module 1420a may perform the receiving actions performed by the terminal device in the above-described method embodiment.

The sending module 1420b may perform the sending actions performed by the terminal device in the above method embodiment.

The processing module 1410 may perform actions other than the sending action and the receiving action in the actions performed by the terminal device in the above method embodiment.

In one example, the processing module 1410 is configured to determine a first key if the device in an inactive state determines that a first type of data arrives; wherein the first key is used for transmitting the first type of data by the device in an inactive state; and in the event that it is determined that the second class of data arrives, determining a second key. The sending module 1420b is configured to send an RRC request message to an access network device; wherein the second key is used for transmitting the second class data by the device in a connected state; the RRC request message is used to request recovery of the RRC connection. The receiving module 1420a is configured to receive first type data from the access network device before receiving the RRC response message from the access network device. The processing module 1410 is further configured to perform security verification on the first type of data using the first key; the RRC response message is used for responding to the RRC request message.

In one example, the processing module 1410 is configured to determine a first key if the device in an inactive state determines that a first type of data arrives; wherein the first key is used for transmitting the first type of data by the device in an inactive state; and in the event that it is determined that the second class of data arrives, determining a second key. The sending module 1420b is configured to send an RRC request message to an access network device; wherein the second key is used for transmitting the second class data by the device in a connected state; the RRC request message is used to request recovery of the RRC connection. The receiving module 1420a is configured to receive first type data from the access network device before receiving the RRC response message from the access network device; the RRC response message is used for responding to the RRC request message. The processing module 1410 is further configured to discard the first type of data.

By way of example, a memory module may include one or more memories, which may be one or more devices, circuits, or means for storing programs or data. The memory module may be a register, a cache, a RAM, etc., and may be integrated with the processing module. The memory module may be a ROM or other type of static storage device that may store static information and instructions, and may be independent of the processing module.

The transceiver module may be an input or output interface, a pin or circuit, etc.

In one example, the apparatus 1400 may be a centralized unit CU, or may be a chip or a functional unit applied in the centralized unit CU. The apparatus 1400 has any of the functions of the centralized unit CU in the above-described method, and for example, the apparatus 1400 can perform the steps performed by the centralized unit CU in the above-described methods of fig. 10, 11, 12, and 13.

The receiving module 1420a may perform the receiving actions performed by the centralized unit CU in the method embodiment described above.

The sending module 1420b may perform the sending actions performed by the centralized unit CU in the method embodiment described above.

The processing module 1410 may perform actions other than the sending and receiving actions among the actions performed by the centralized unit CU in the above-described method embodiment.

In one example, the processing module 1410 is configured to determine a first key if a first RRC request message from a DU is received; the first RRC request message is from a terminal device in an inactive state, the first RRC request message is used for requesting to recover RRC connection, and the first key is used for transmitting first type data with the terminal device in the inactive state. The receiving module 1420a is configured to receive a second RRC request message from the DU; the second RRC restoration request message is from the terminal device in the inactive state, where the second RRC request message is used to request restoration of RRC connection. The processing module 1410 is further configured to determine a second key, where the second key is used to transmit second class data with the terminal device in a connected state. The sending module 1420b is configured to send, after sending the first indication information to the DU, an RRC response message of the second RRC request message to the DU; the first indication information is used for indicating the DU to clear the first type of data.

In one example, the apparatus includes a control plane CU and a user plane CU.

In an example, the user plane CU sends first indication information to the DU, including: the user plane CU sends a downlink user data message to the DU, wherein the downlink user data message comprises the first indication information.

In one example, the control plane CU sends first indication information to the DU, including: the control plane CU sends a UE context setup request message to the DU, the UE context setup request message including the first indication information.

By way of example, a memory module may include one or more memories, which may be one or more devices, circuits, or means for storing programs or data. The memory module may be a register, a cache, a RAM, etc., and may be integrated with the processing module. The memory module may be a ROM or other type of static storage device that may store static information and instructions, and may be independent of the processing module.

The transceiver module may be an input or output interface, a pin or circuit, etc.

In one example, the apparatus 1400 may be a new serving access network device, or may be a chip or a functional unit applied in the new serving access network device. The apparatus 1400 has any of the functions of the new serving access network device in the method described above, for example, the apparatus 1400 is capable of performing the steps performed by the new serving access network device in the method described above with respect to fig. 10, 11, 12, and 13.

The receiving module 1420a may perform the receiving actions performed by the new serving access network device in the method embodiment described above.

The sending module 1420b may perform the sending actions performed by the new serving access network device in the method embodiment described above.

The processing module 1410 may perform actions other than the sending and receiving actions in the actions performed by the new service access network device in the above method embodiment.

In one example, the receiving module 1420a is configured to receive a first radio resource control RRC request message from a terminal device in an inactive state, where the first RRC request message is configured to request recovery of an RRC connection; and receiving a second RRC request message from the terminal device in an inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in an inactive state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message. The sending module 1420b is configured to send a request message to an anchor access network device, where the request message is used to request to obtain a context of the terminal device. The receiving module 1420a is further configured to receive a response message to the request message from the anchor access network device. The processing module 1410 is configured to clear the buffered first type data before sending a response message of the second RRC resume request message to the terminal device.

In one example, the response message includes second indication information; wherein: the second indication information is used for indicating the new service access network equipment to clear all cached downlink data, and the cached downlink data is the first type data; or the second indication information is used for indicating the identification information of the downlink data to be cleared, the downlink data to be cleared is data in the downlink data cached by the new service access network device, and the cached downlink data is the first type data.

In one example, the response message is a get UE context failure message; or, the response message is a downlink user data message.

By way of example, a memory module may include one or more memories, which may be one or more devices, circuits, or means for storing programs or data. The memory module may be a register, a cache, a RAM, etc., and may be integrated with the processing module. The memory module may be a ROM or other type of static storage device that may store static information and instructions, and may be independent of the processing module.

The transceiver module may be an input or output interface, a pin or circuit, etc.

As one possible product form, the apparatus may be implemented by a general bus architecture.

As shown in fig. 15, a schematic block diagram of a communication device 1500 is provided.

The apparatus 1500 may include: the processor 1510, optionally, further comprises a transceiver 1520, memory 1530. The transceiver 1520 may be configured to receive a program or instructions and transmit the same to the processor 1510, or the transceiver 1520 may be configured to communicate with other communication devices, such as interactive control signaling and/or traffic data, etc. with the apparatus 1500. The transceiver 1520 may be a code and/or data read-write transceiver, or the transceiver 1520 may be a signal transmission transceiver between a processor and a transceiver. The processor 1510 is electrically coupled to the memory 1530.

In an example, the apparatus 1500 may be a terminal device, or may be a chip applied in the terminal device. It should be understood that the apparatus has any function of the terminal device in the above method, for example, the apparatus 1500 can perform each step performed by the terminal device in the above methods of fig. 10, 11, 12, and 13. Illustratively, the memory 1530 is used for storing computer programs; the processor 1510 may be configured to invoke computer programs or instructions stored in the memory 1530, perform methods performed by the terminal device in the above examples, or perform methods performed by the terminal device in the above examples through the transceiver 1520.

In one example, the apparatus 1500 may be a centralized unit CU, or may be a chip that is used in a centralized unit CU. It should be appreciated that the apparatus has any of the functions of the centralized unit CU in the above-described method, for example, the apparatus 1500 is capable of performing the steps performed by the centralized unit CU in the above-described methods of fig. 10, 11, 12, 13. Illustratively, the memory 1530 is used for storing computer programs; the processor 1510 may be configured to invoke computer programs or instructions stored in the memory 1530, perform methods performed by the centralized unit CU in the above example, or perform methods performed by the centralized unit CU in the above example via the transceiver 1520.

The processing module 1410 in fig. 14 may be implemented by the processor 1510.

The receiving module 1420a and the transmitting module 1420b in fig. 14 may be implemented by the transceiver 1520. Alternatively, the transceiver 1520 is divided into a receiver that performs the function of a receiving module and a transmitter that performs the function of a transmitting module.

The storage module 1430 in fig. 14 may be implemented by the memory 1530.

In one example, the apparatus 1500 may be a new serving access network device, or may be a chip that is applied in a new serving access network device. It should be understood that the apparatus has any of the functions of the new serving access network device in the above method, for example, the apparatus 1500 is capable of performing the steps performed by the new serving access network device in the above methods of fig. 10, 11, 12, and 13. Illustratively, the memory 1530 is used for storing computer programs; the processor 1510 may be configured to invoke computer programs or instructions stored in the memory 1530 to perform the methods performed by the new serving access network device in the above examples or to perform the methods performed by the new serving access network device in the above examples via the transceiver 1520.

The processing module 1410 in fig. 14 may be implemented by the processor 1510.

The receiving module 1420a and the transmitting module 1420b in fig. 14 may be implemented by the transceiver 1520. Alternatively, the transceiver 1520 is divided into a receiver that performs the function of a receiving module and a transmitter that performs the function of a transmitting module.

The storage module 1430 in fig. 14 may be implemented by the memory 1530.

As one possible product form, the apparatus may be implemented by a general-purpose processor (a general-purpose processor may also be referred to as a chip or a system-on-chip).

In a possible implementation manner, the general purpose processor implementing the means applied to the terminal device or the means of the centralized unit CU comprises: processing circuitry (processing circuitry may also be referred to as a processor); optionally, the method further comprises: an input-output interface in communication with the processing circuit, a storage medium (the storage medium may also be referred to as a memory) for storing instructions to be executed by the processing circuit to perform the method performed by the terminal device or the centralized unit CU in the above example.

The processing module 1410 in fig. 14 may be implemented by a processing circuit.

The receiving module 1420a and the transmitting module 1420b in fig. 14 may be implemented by input-output interfaces. Or the input/output interface is divided into an input interface and an output interface, the input interface performs the function of the receiving module, and the output interface performs the function of the transmitting module.

The storage module 1430 in fig. 14 may be implemented by a storage medium.

As a possible product form, the device according to the embodiment of the present application may be further implemented using the following: one or more FPGAs (field programmable gate arrays), PLDs (programmable logic devices), controllers, state machines, gate logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

The embodiment of the application also provides a computer readable storage medium storing a computer program, which when executed by a computer, can cause the computer to perform the method of communication. Or the following: the computer program comprises instructions for implementing the method of communication described above.

The embodiment of the application also provides a computer program product, which comprises: computer program code which, when run on a computer, enables the computer to perform the method of communication provided above.

In addition, the processor mentioned in the embodiment of the present application may be a central processor (central processing unit, CPU), a baseband processor, and a CPU may be integrated together or separated, or may be a network processor (network processor, NP) or a combination of a CPU and an NP. The processor may further comprise a hardware chip or other general purpose processor. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array field-programmable gate array (FPGA), general-purpose array logic (generic array logic, GAL), and other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like, or any combination thereof. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory referred to in embodiments of the present application may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and Direct RAM (DR RAM). It should be noted that the memory described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The transceiver mentioned in the embodiments of the present application may include a separate transmitter and/or a separate receiver, or the transmitter and the receiver may be integrated. The transceiver may operate under the direction of a corresponding processor. Alternatively, the transmitter may correspond to a transmitter in a physical device and the receiver may correspond to a receiver in the physical device.

Those of ordinary skill in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the steps and components of the various embodiments have been described generally in terms of functionality in the foregoing description to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those of ordinary skill in the art may implement the described functionality using different approaches for each particular application, but such implementation is not considered to be beyond the scope of the present application.

In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices, or elements, or may be an electrical, mechanical, or other form of connection.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment of the present application.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application is essentially or a part contributing to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

In the present application, "and/or" describing the association relationship of the association object, three relationships may exist, for example, a and/or B may represent: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. The term "plurality" as used herein means two or more. In addition, it should be understood that in the description of the present application, the words "first," "second," and the like are used merely for distinguishing between the descriptions and not for indicating or implying any relative importance or order.

While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments of the present application without departing from the spirit or scope of the embodiments of the application. Thus, if such modifications and variations of the embodiments of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to include such modifications and variations.

Claims (15)

1. A method of communication, the method comprising:

the terminal equipment in the inactive state determines a first key under the condition that the first type of data arrives; the first key is used for transmitting the first type of data by the terminal equipment in an inactive state;

the terminal equipment determines a second key and sends an RRC request message to the access network equipment under the condition that the second class data arrives; the second key is used for transmitting the second type of data by the terminal equipment in a connection state; the RRC request message is used for requesting to recover the RRC connection;

before receiving the RRC response message from the access network equipment, the terminal equipment receives first-class data from the access network equipment, and adopts the first key to carry out security verification on the first-class data; the RRC response message is used for responding to the RRC request message.

2. A method of communication, the method comprising:

the terminal equipment in the inactive state determines a first key under the condition that the first type of data arrives; the first key is used for transmitting the first type of data by the terminal equipment in an inactive state;

The terminal equipment determines a second key and sends an RRC request message to the access network equipment under the condition that the second class data arrives; the second key is used for transmitting the second type of data by the terminal equipment in a connection state; the RRC request message is used for requesting to recover the RRC connection;

the terminal equipment receives first-class data from the access network equipment before receiving the RRC response message from the access network equipment, and discards the first-class data; the RRC response message is used for responding to the RRC request message.

3. A method of communication, the method comprising:

the centralized unit CU determines a first key in case of receiving a first RRC request message from the DU; the first RRC request message is from a terminal device in an inactive state, the first RRC request message is used for requesting to recover RRC connection, and the first key is used for transmitting first type data with the terminal device in the inactive state;

the centralized unit CU receives a second RRC request message from the DU and determines a second key; the second RRC recovery request message is from the terminal equipment in the inactive state, the second RRC request message is used for requesting to recover RRC connection, and the second key is used for transmitting second-class data with the terminal equipment in the connected state;

After sending the first indication information to the DU, the centralized unit CU sends an RRC response message of the second RRC request message to the DU; the first indication information is used for indicating the DU to clear the first type of data.

4. The method of claim 3, wherein the CUs comprise a control plane CU and a user plane CU;

transmitting first indication information to the DU includes:

the user plane CU sends first indication information to the DU; or alternatively, the process may be performed,

the control plane CU sends a first indication information to the DU.

5. The method of claim 4, wherein the user plane CU sends first indication information to the DU, comprising:

the user plane CU sends a downlink user data message to the DU, wherein the downlink user data message comprises the first indication information.

6. The method of claim 4, wherein the control plane CU sends first indication information to the DU, comprising:

the control plane CU sends a UE context setup request message to the DU, the UE context setup request message including the first indication information.

7. A method of communication, the method comprising:

The method comprises the steps that a new service access network device receives a first Radio Resource Control (RRC) request message from a terminal device in an inactive state, wherein the first RRC request message is used for requesting to recover RRC connection;

the new service access network equipment receives a second RRC request message from the terminal equipment in the inactive state; the second RRC request message is configured to request to restore RRC connection, where the second RRC request message is sent by the terminal device in a non-active state when there is second type data to be transmitted in a first type data transmission process, and the first type data transmission process is triggered based on the first RRC request message;

the new service access network device sends a request message to the anchor access network device, wherein the request message is used for requesting to acquire the context of the terminal device;

the new service access network device receives a response message for the request message from the anchor access network device;

and before the new service access network equipment sends a response message of the second RRC recovery request message to the terminal equipment, the cached first-class data is cleared.

8. The method of claim 7, wherein the response message includes second indication information; wherein:

The second indication information is used for indicating the new service access network equipment to clear all cached downlink data, and the cached downlink data is the first type data; or alternatively, the process may be performed,

the second indication information is used for indicating the identification information of the downlink data to be cleared, the downlink data to be cleared is data in the downlink data cached by the new service access network device, and the cached downlink data is the first type data.

9. The method of claim 7 or 8, wherein the response message is a acquisition UE context failure message; or alternatively, the process may be performed,

the response message is a downlink user data message.

10. A communication device, comprising: functional module for implementing the method according to any of claims 1-9.

11. A communications apparatus comprising a processor coupled to a memory;

the memory is used for storing a computer program or instructions;

the processor being configured to execute part or all of the computer program or instructions in the memory, which, when executed, is configured to implement the method of any one of claims 1-9.

12. A communication device comprising a processor and a memory;

the memory is used for storing a computer program or instructions;

the processor being configured to execute part or all of the computer program or instructions in the memory, which, when executed, is configured to implement the method of any one of claims 1-9.

13. A chip system, the chip system comprising: a processing circuit; the processing circuit is coupled with a storage medium;

the processing circuitry being adapted to execute part or all of the computer program or instructions in the storage medium, which, when executed, is adapted to carry out the method of any one of claims 1-9.

14. A computer readable storage medium storing a computer program comprising instructions for implementing the method of any one of claims 1-9.

15. A computer program product, the computer program product comprising: computer program code which, when run on a computer, causes the computer to perform the method of any of claims 1-9.