Data transmission method, terminal and network side equipment

Abstract

The present invention provides a data transmission method, a terminal and a network side device, wherein the data transmission method comprises: a terminal in an RRC inactive state sends a data packet and an RRC recovery request message to a first base station or a CU of the first base station or a DU of the first base station, and receives an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station. The timing of data packet transmission is advanced, the transmission delay is reduced, and the process of the terminal returning to the RRC inactive state can be accelerated, saving the power consumption of the terminal.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a data transmission method, a terminal and a network side device. Background Art

[0002] At present, the terminal status includes the RRC inactive state (RRC_inactive) in addition to the Radio Resource Control (RRC) idle state and the RRC connected state. The RRC inactive state can quickly allow the user equipment (UE) to enter the RRC connected state and complete the establishment of the protocol data unit (PDU) session while saving resources and energy as much as possible, meeting the requirements of ultra-reliable and low-latency scenarios.

[0003] However, if a terminal in an RRC inactive state wants to send data, it must first restore the connection and enter the RRC connected state before sending data. In the scenario of small packet transmission, this method will increase the transmission delay. Summary of the invention

[0004] The embodiments of the present invention provide a data transmission method, a terminal and a network side device to solve the problem of large transmission delay in the transmission mode of the prior art.

[0005] To solve the above technical problems, the present invention is achieved as follows:

[0006] In a first aspect, an embodiment of the present invention provides a data transmission method for a terminal in a radio resource control (RRC) inactive state, the data transmission method comprising:

[0007] Sending a data packet and an RRC recovery request message to the first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station;

[0008] Receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station.

[0009] In a second aspect, an embodiment of the present invention provides a data transmission method, which is used for a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, and the data transmission method includes:

[0010] Receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0011] Send an RRC release message to the terminal.

[0012] In a third aspect, an embodiment of the present invention provides a data transmission method, which is used for a second base station. The data transmission method includes:

[0013] receiving a user equipment UE context retrieval request message sent by the first base station or a centralized unit CU of the first base station;

[0014] Sending a message of failure to retrieve UE context to the first base station or the CU of the first base station;

[0015] Send the data packet to the core network.

[0016] In a fourth aspect, an embodiment of the present invention provides a data transmission method, which is applied to a distributed unit DU of a first base station, and the data transmission method includes:

[0017] Receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0018] Sending the data packet and the RRC recovery request message to a centralized unit CU of the first base station;

[0019] Receiving an RRC release message sent by the CU of the first base station;

[0020] The RRC release message is sent to the terminal.

[0021] In a fifth aspect, an embodiment of the present invention provides a terminal, wherein the terminal is in a radio resource control (RRC) inactive state, including:

[0022] A sending module, used for sending a data packet and an RRC recovery request message to the first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station;

[0023] A receiving module is used to receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station.

[0024] In a sixth aspect, an embodiment of the present invention provides a terminal, the terminal is in a radio resource control RRC inactive state, and includes a processor and a transceiver;

[0025] The transceiver is used to send a data packet and an RRC recovery request message to the first base station or the centralized unit CU of the first base station or the distributed unit DU of the first base station, and receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station.

[0026] In a seventh aspect, an embodiment of the present invention provides a network side device, where the network side device is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, including:

[0027] A receiving module, used for receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0028] The sending module is used to send an RRC release message to the terminal.

[0029] In an eighth aspect, an embodiment of the present invention provides a network side device, wherein the network side device is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, and includes a processor and a transceiver;

[0030] The transceiver is used to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, and to send an RRC release message to the terminal.

[0031] In a ninth aspect, an embodiment of the present invention provides a network side device, where the network side device is a second base station, including:

[0032] A first receiving module, configured to receive a user equipment UE context retrieval request message sent by the first base station or a centralized unit CU of the first base station;

[0033] A first sending module, configured to send a message of failure to retrieve UE context to the first base station or the CU of the first base station;

[0034] The second sending module is used to send the data packet to the core network.

[0035] In a tenth aspect, an embodiment of the present invention provides a network side device, wherein the network side device is a second base station, including a processor and a transceiver;

[0036] The transceiver is used to receive a user equipment UE context retrieval request message sent by the first base station or the centralized unit CU of the first base station, send a UE context retrieval failure message to the first base station or the CU of the first base station, and send the data packet to the core network.

[0037] In an eleventh aspect, an embodiment of the present invention provides a network side device, where the network side device is a DU of a first base station, including:

[0038] A first receiving module, configured to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0039] A first sending module, configured to send the data packet and the RRC recovery request message to a centralized unit CU of the first base station;

[0040] A second receiving module, used to receive an RRC release message sent by the CU of the first base station;

[0041] The second sending module is used to send the RRC release message to the terminal.

[0042] In a twelfth aspect, an embodiment of the present invention provides a network side device, where the network side device is a DU of a first base station, including a processor and a transceiver;

[0043] The transceiver is used to receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state; send the data packet and the RRC recovery request message to a centralized unit CU of a first base station; receive an RRC release message sent by the CU of the first base station; and send the RRC release message to the terminal.

[0044] In the thirteenth aspect, an embodiment of the present invention provides a terminal, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps in the data transmission method as described in the first aspect.

[0045] In the fourteenth aspect, an embodiment of the present invention provides a network side device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps in the data transmission method as described in the second aspect, or the computer program, when executed by the processor, implements the steps in the data transmission method as described in the third aspect, or the computer program, when executed by the processor, implements the steps in the data transmission method as described in the fourth aspect.

[0046] In the fifteenth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the data transmission method as described in the first aspect of claim are implemented, or, when the computer program is executed by the processor, the steps of the data transmission method as described in the second aspect are implemented, or, when the computer program is executed by the processor, the steps of the data transmission method as described in the third aspect are implemented, or, when the computer program is executed by the processor, the steps of the data transmission method as described in the fourth aspect are implemented.

[0047] In an embodiment of the present invention, a terminal in an RRC inactive state sends a data packet and an RRC recovery request message to a first base station or a CU of the first base station or a DU of the first base station, and receives an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station. The timing of data packet transmission is advanced, transmission delay is reduced, and the process of the terminal returning to the RRC inactive state can be accelerated, saving power consumption of the terminal. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0049] Figure 1 This is one of the flow charts of a data transmission method provided by an embodiment of the present invention;

[0050] Figure 2 It is a schematic diagram of the flow of data transmission between a terminal and a target base station in the prior art;

[0051] Figure 3a , Figure 3b It is a schematic diagram of the field composition of a MAC PDU provided by an embodiment of the present invention;

[0052] Figure 4 This is a second flowchart of a data transmission method provided by an embodiment of the present invention;

[0053] Figure 5 This is a third flowchart of a data transmission method provided by an embodiment of the present invention;

[0054] Figure 6 This is a fourth flowchart of a data transmission method provided by an embodiment of the present invention;

[0055] Figure 7a-7h is a flow chart of a data transmission method in various scenarios provided by an embodiment of the present invention;

[0056] Figure 8 , Fig. 9 is a structural diagram of a terminal provided by an embodiment of the present invention;

[0057] Figure 10-13 It is a structural diagram of a network side device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0059] See also Figure 1 , Figure 1 is a flow chart of a data transmission method provided by an embodiment of the present invention, which is used for a terminal in an RRC inactive state, such as Figure 1As shown, the data transmission method includes the following steps:

[0060] Step 101: Send a data packet and an RRC recovery request message to a first base station or a centralized unit (CU) of the first base station or a distributed unit (DU) of the first base station.

[0061] In a specific embodiment of the present invention, the data packet may be application data of various applications, such as data packets of instant messaging software, heartbeat packets of applications such as emails, data packets of smart wearable devices and sensors, etc. The data packet and the RRC recovery request message may be sent to the first base station or the CU of the first base station or the DU of the first base station in the same data transmission.

[0062] For the four-step random access process, the terminal sends a preamble code to the first base station or the CU of the first base station or the DU of the first base station at the physical random access channel (PRACH) opportunity. After detecting the preamble code, the first base station or the CU of the first base station or the DU of the first base station sends a random access response message to the terminal, and uses the random access (RA) corresponding to the PRACH opportunity of sending the preamble code. The RNTI Radio Network Temporary Identity (RNTI) is scrambled;

[0063] The terminal receives a random access response message sent by the first base station or the CU of the first base station or the DU of the first base station. If it is determined that the random access response message is sent to the terminal, for example, the RAPID is consistent, the terminal sends a data packet and an RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station.

[0064] For the two-step random access process, step 101 includes: the terminal sends a preamble code to the first base station or the CU of the first base station or the DU of the first base station at the PRACH timing, and sends a data packet and an RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station on the physical uplink shared channel (Physical Uplink Shared Channel, referred to as PUSCH).

[0065] Step 102: Receive an RRC release message sent by the first base station or the CU of the first base station or the first base station DU.

[0066] After receiving the RRC release message, the terminal releases the RRC connection and enters an RRC inactive state, which can save power consumption of the terminal.

[0067] In the four-step access process related technology, if a terminal in an RRC inactive state wants to send data, it needs to Figure 2 Several steps are shown, Figure 2 In the example, the target base station is the first base station or the CU of the first base station or the first base station DU:

[0068] Step 111, the terminal sends a preamble code to the target base station;

[0069] Step 112: The terminal receives a random access response message from the target base station;

[0070] Step 113: The terminal sends an RRC recovery request message to the target base station;

[0071] Step 114: The terminal receives an RRC recovery message sent by the target base station;

[0072] Step 115: The terminal sends an RRC recovery completion message to the target base station;

[0073] Step 116: The terminal sends a data packet to the target base station.

[0074] Compared to Figure 2 In the process of transmitting a data packet by the terminal shown in the figure, the data transmission method of the specific embodiment of the present invention does not need to start transmitting the data packet after the RRC recovery is completed, but can transmit the data packet after receiving the random access response message, that is, the timing of data packet transmission is advanced, and the transmission delay is reduced. At the same time, compared with the prior art, the specific embodiment of the present invention can speed up the process of the terminal returning to the RRC inactive state, saving the power consumption of the terminal.

[0075] Similarly, for the two-step random access process, it is also possible to reduce data transmission delay while saving power consumption of the terminal.

[0076] In this embodiment, the terminal in the RRC inactive state sends a data packet and an RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station, and receives an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station. The timing of data packet transmission is advanced, the transmission delay is reduced, and the process of the terminal returning to the RRC inactive state can be accelerated, saving the power consumption of the terminal.

[0077] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0078] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0079] Further, before step 101, sending the data packet and the RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station, it also includes:

[0080] Encapsulating the data packet directly as a first Media Access Control (MAC) Service Data Unit (SDU) into a first MAC Protocol Data Unit (PDU);

[0081] or

[0082] The second MAC SDU generated by pre-processing the data packet is encapsulated into the second MAC PDU.

[0083] That is, the data packet is encapsulated in the first MAC PDU or the second MAC PDU. The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of the signaling bearer and the data bearer.

[0084] Specifically, when the terminal receives a random access response message sent by the first base station or the CU of the first base station or the DU of the first base station, if it is determined that the random access response message is sent to the terminal, for example, the RAPID is consistent, then the terminal identification (Identity Document, ID for short) and the uplink data packet will be sent on the uplink (Uplink, UL) grant (Grant) resources.

[0085] If the terminal does not activate the configurations such as Signal Radio Bearer (SRB) and Data Radio Bearer (DRB) at this time, the terminal directly encapsulates the IP data packet (i.e., data packet) as the first MAC SDU into the first MAC PDU. And add MAC sub-header information (i.e., sub-header) in the data packet to form a MAC sub-PDU (i.e., sub-PDU), and then put it after the MAC sub-PDU containing CCCH (i.e., RRC recovery request message) or DCCH. The sub-header information of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are also included. The specific MAC PDU is as follows: Figure 3a As shown:

[0086] The S field of the first subheader indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU includes two implementation methods:

[0087] The first implementation method (such as Figure 3a The sub-header information includes a dedicated LCID corresponding to the data packet, and the dedicated LCID is used by the base station (which can be understood as the first base station or the CU of the first base station or the DU of the first base station) to identify that this is an IP data packet, as well as the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and then send it to the core network.

[0088] The second implementation method (such as Figure 3a The sub-header information includes the DRB ID information corresponding to the data packet. The base station identifies that this is an IP data packet based on the DRB ID information, and learns which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and then send it to the core network.

[0089] If the terminal does not activate SRB, DRB and other configurations at this time, then activate SRB, DRB and other configurations to obtain the second MAC PDU. In this way, the data packet is processed in the normal way, including PDCP layer and RLC layer processing, and then the second MAC SDU is generated. The second MAC SDU is combined with the MAC subheader to form a MAC sub-PDU, and the MAC sub-PDU is placed after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b In this mode, since the bearer is activated, the LCID can use the logical channel ID of the normal data, that is, 000001-100000.

[0090] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0091] or

[0092] The subheader information of the second MAC SDU includes logical channel identification information.

[0093] Among them, the first MAC SDU includes at least one of logical channel identification information and bearer identification information. Further, the first MAC SDU includes at least bearer identification information. When the terminal corresponding to the first MAC SDU does not activate SRB, DRB and other configurations, since the data bearer is not activated, it is necessary to indicate the data bearer in the first MAC SDU. Furthermore, the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to IP data packets.

[0094] The second MAC SDU corresponds to the terminal bearer activation situation. The second MAC SDU is determined through pre-processing. When the second MAC PDU is subsequently decapsulated, the data bearer and other information of the data packet can be obtained. The sub-header information of the second MAC SDU only needs to include the logical channel identification information, and does not need to include the bearer identification information.

[0095] like Figure 4 As shown, an embodiment of the present application provides a flow chart of a data transmission method. The data transmission method provided in this embodiment is used for a first base station or a CU of the first base station or a DU of the first base station. The data transmission method includes:

[0096] Step 201: Receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state.

[0097] For the four-step random access process, the terminal sends a preamble code to the first base station or the CU of the first base station or the DU of the first base station at the physical random access channel (Physical Random Access Channel, referred to as PRACH) opportunity. After detecting the preamble code, the first base station or the CU of the first base station or the DU of the first base station sends a random access response message to the terminal, and uses the random access (Random Access, referred to as RA) radio network temporary identity (RNTI Radio Network Temporary Identity, referred to as RNTI) corresponding to the PRACH opportunity when the preamble code is sent for scrambling.

[0098] The first base station or the CU of the first base station or the DU of the first base station sends a random access response message to the terminal. If the terminal determines that the random access response message is sent to itself, for example, the RAPID is consistent, the terminal sends a data packet and an RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station.

[0099] For the two-step random access process, the preamble code sent by the terminal at the PRACH timing is received, and the data packet and RRC recovery request message sent by the terminal at the PUSCH timing are received.

[0100] Step 202: Send an RRC release message to the terminal.

[0101] For the four-step random access process, the first base station (the first base station is used as an example below, and the method applied to the first base station can also be applied to the CU of the first base station or the DU of the first base station) can directly send an RRC release message to the terminal, carrying a suspension indication.

[0102] For the two-step random access process, the first base station may carry the RRC release message in the MSG B message and send it to the terminal. The MSG B message may also include a random access response message and RAPID information.

[0103] After receiving the RRC release message, the terminal releases the RRC connection and enters the RRC inactive state, which can save power consumption of the terminal. The RRC release message is also used to indicate that the terminal contention conflict is successfully resolved.

[0104] Further, after step 202, the first base station or the CU of the first base station or the DU of the first base station sends a data packet to the core network to complete the transmission of the data packet.

[0105] In this embodiment, the first base station or the CU of the first base station or the DU of the first base station receives a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state, and sends an RRC release message to the terminal. The timing of data packet transmission is advanced, the transmission delay is reduced, and the process of the terminal returning to the RRC inactive state can be accelerated, saving the power consumption of the terminal.

[0106] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0107] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0108] Furthermore, the data packet is encapsulated in a first MAC PDU or a second MAC PDU, the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0109] The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0110] Specifically, when the terminal receives a random access response message sent by the first base station or the CU of the first base station or the DU of the first base station, if it is determined that the random access response message is sent to the terminal, for example, the RAPID is consistent, the terminal ID and the uplink data packet will be sent on the UL Grant resource. There are several specific solutions:

[0111] If the terminal does not activate SRB, DRB and other configurations at this time, the terminal directly encapsulates the IP data packet (ie, data packet) as the first MAC SDU into the first MAC PDU.

[0112] The terminal adds MAC sub-header information (i.e., sub-header) to the data packet to form a MAC sub-PDU (i.e., sub-PDU), and then puts it after the MAC sub-PDU containing CCCH (i.e., RRC recovery request message) or DCCH. The sub-header information of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0113] The S field of the first subheader indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU includes two implementation methods:

[0114] The first implementation method: the sub-header information contains a dedicated LCID corresponding to the data packet, and the dedicated LCID is used by the base station (which can be understood as the first base station or the CU of the first base station or the DU of the first base station) to identify that this is an IP data packet, as well as the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and then send it to the core network.

[0115] The second implementation method: The sub-header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet based on the DRB ID information, and at the same time knows which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and then send it to the core network.

[0116] If the terminal does not activate SRB, DRB and other configurations at this time, then activate SRB, DRB and other configurations to obtain the second MAC PDU. Process the data packet in the normal processing mode, including PDCP layer and RLC layer processing, and then generate the second MAC SDU. The second MAC SDU and the MAC subheader together form a MAC sub-PDU, and the MAC sub-PDU is placed after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b LCID uses the logical channel ID of normal data, that is, 000001-100000.

[0117] Further, the first MAC PDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0118] or

[0119] The subheader information of the second MAC SDU includes logical channel identification information.

[0120] Among them, the first MAC SDU includes at least one of logical channel identification information and bearer identification information. Further, the first MAC SDU includes at least bearer identification information. When the terminal corresponding to the first MAC SDU does not activate SRB, DRB and other configurations, since the data bearer is not activated, it is necessary to indicate the data bearer in the first MAC SDU. Furthermore, the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to IP data packets.

[0121] The second MAC SDU corresponds to the terminal bearer activation situation. The second MAC SDU is determined through pre-processing. When the second MAC PDU is subsequently decapsulated, the data bearer and other information of the data packet can be obtained. The sub-header information of the second MAC SDU includes logical channel identification information, but does not need to include bearer identification information.

[0122] Further, after receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, the method further includes:

[0123] Send the recovered data packet to the core network.

[0124] In this embodiment, the first base station can send the data packet to the core network (corresponding to the situation where the anchor base station needs to be switched), or the first base station can send the data packet to the second base station, and the second base station can send it to the core network (corresponding to the situation where the anchor base station does not need to be switched), as explained below.

[0125] Corresponding to the situation where there is no need to switch the anchor base station, the first base station can send the data packet and the UE context retrieval request message to the second base station. If it is necessary to switch the anchor base station, the sending process can be performed according to the restored terminal context.

[0126] That is, after receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, the method further includes:

[0127] Sending a UE context retrieval request message to the second base station;

[0128] receiving a UE context retrieval reply message sent by the second base station;

[0129] Send the data packet to the core network.

[0130] In this embodiment, after receiving the data packet and RRC recovery request message sent by the terminal, the first base station obtains I-RNTI and MAC-I from the RRC recovery request message, obtains the ID information of the second base station, and sends a UE context request message to the second base station.

[0131] If the UE context retrieval response message is a UE context retrieval failure message, the first base station or the CU of the first base station or the DU of the first base station sends the data packet to the second base station, and the second base station sends the data packet to the core network.

[0132] If the UE context retrieval response message is a UE context retrieval success message, the first base station or the CU of the first base station or the DU of the first base station directly sends the data packet to the core network.

[0133] Specifically, if the UE context retrieval reply message is a UE context retrieval success message, sending the data packet to the core network is specifically:

[0134] According to the successfully recovered terminal context, the data packet is obtained from a first MAC PDU or a second MAC PDU sent by the terminal, wherein the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet;

[0135] Send the data packet to the core network.

[0136] Specifically, if the terminal context is successfully restored, the DRB ID information and the data packet are obtained from the first MAC PDU, or the data packet corresponding to the LCID is parsed from the second MAC PDU, and the DRB information and PDU session information are obtained.

[0137] After obtaining the data packet, the first base station sends a path switching request to the core network and receives a path switching request reply sent by the core network; the first base station sends the data packet to the core network through a suitable tunnel.

[0138] Further, after receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, the method further includes:

[0139] Sending a UE context retrieval request message to the second base station, where the UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet;

[0140] A UE context retrieval failure message sent by the second base station is received.

[0141] The RRC recovery reason indication includes at least one of an emergency call, a high priority access, a terminal-terminated access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call and a terminal-triggered video call.

[0142] In one implementation, the UE context retrieval request message may include an RRC recovery reason indication and carry the bearer identification information corresponding to the data packet. The bearer identification information is used by the second base station to obtain the DRB ID corresponding to the data packet so as to subsequently send the data packet to the core network through an appropriate tunnel.

[0143] In another implementation, the UE context retrieval request message may include an RRC recovery cause indication and / or a data packet sending indication.

[0144] After receiving the message of failure to retrieve UE context, the first base station may send a data packet to the second base station, and the second base station sends the data packet to the core network. If the first base station also sends a data packet while sending a request message to retrieve UE context to the second base station, the first base station does not need to send a data packet to the second base station again after receiving the message of failure to retrieve UE context.

[0145] Furthermore, the data transmission method further includes:

[0146] Receiving data forwarding information carried by the second base station through an address indication message or the UE context retrieval failure message;

[0147] forwarding the data packet sent by the terminal to the second base station.

[0148] Specifically, if the data forwarding information is not carried in the UE context retrieval failure message, after receiving the UE context retrieval failure message sent by the second base station, the data forwarding information carried by the second base station through the address indication message is also received. If the data forwarding information is carried in the UE context retrieval failure message, the first base station obtains the data forwarding information through the UE context retrieval failure message.

[0149] The data forwarding information may be the transport layer (TNL) information of the second base station, including Internet Protocol Address (IP) information and Tunnel Endpoint Identifier (TEID) information of the User plane of GPRS Tunneling Protocol (GPRS, GTP-U), which is used to determine the second base station according to the data forwarding information and subsequently forward the data packet to the second base station.

[0150] Furthermore, the data packet sent by the terminal is at least one of an IP data packet, a first MAC PDU data packet, a first MAC SDU data packet, a second MAC PDU data packet, a second MAC SDU data packet, a recovered first RLC SDU and a recovered second RLC SDU.

[0151] like Figure 5 As shown, an embodiment of the present application provides another flow chart of a data transmission method. The data transmission method provided in this embodiment is used for a second base station. The data transmission method includes:

[0152] Step 301: receiving a UE context retrieval request message sent by a first base station or a CU of the first base station;

[0153] Step 302: Send a message of failure to retrieve UE context to the first base station or the CU of the first base station;

[0154] Step 303: Send the data packet to the core network.

[0155] The UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet.

[0156] In one implementation, the UE context retrieval request message may include an RRC recovery reason indication and carry the bearer identification information corresponding to the data packet. The bearer identification information is used by the second base station to obtain the DRB ID corresponding to the data packet so as to subsequently send the data packet to the core network through an appropriate tunnel.

[0157] In another implementation, the UE context retrieval request message may include an RRC recovery cause indication and / or a data packet sending indication.

[0158] The second base station can learn from the UE context retrieval request message that the RRC recovery reason is data packet transmission, IP data packet, and DRB ID information. Specifically, the IP data packet and DRB ID information can be obtained in the following two ways:

[0159] The first method is to obtain the DRB ID or PDU session ID information from the UE context retrieval request message, and obtain the IP data packet from the data plane between the second base station and the first base station.

[0160] The second method: parse the MAC PDU sent by the second base station to obtain the DRB or PDU session ID information corresponding to the LCID, and parse to obtain the IP data packet.

[0161] If the second base station can obtain the data packet sent by the terminal according to the UE context retrieval request message, it can send the data packet to the core network; if the second base station does not obtain the data packet sent by the terminal according to the UE context retrieval request message, it needs to receive the data packet sent by the first base station or the CU of the first base station, and then send the data packet to the core network.

[0162] The UE context retrieval failure message can carry the TNL layer information of the second base station, including IP address information and GTP-UTEID information, and can also use data forwarding information to subsequently inform the second base station of the TNL layer information. The TNL layer information of the second base station is used to access the base station to transfer the data packet to the second base station.

[0163] In this embodiment, after the second base station sends a failure message to retrieve the UE context to the first base station or the CU of the first base station, the second base station sends the data packet to the core network, that is, the data packet can be sent to the core network without switching the anchor base station, thereby improving the transmission efficiency of the data packet and reducing the transmission delay of the data packet.

[0164] Further, the UE context retrieval failure message carries data forwarding information, and the data transmission method further includes:

[0165] Receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0166] The data forwarding information may be carried in the UE context retrieval failure message. The data forwarding information may be the TNL layer information of the second base station, including IP address information and GTP-U TEID information, which is used to determine the second base station based on the data forwarding information. Subsequently, the first base station or the CU of the first base station forwards the data packet to the second base station based on the data forwarding information.

[0167] Furthermore, the data forwarding information may not be carried in the UE context retrieval failure message, but the second base station carries the data forwarding information through an address indication message, and the second base station sends the address indication message to the first base station or the CU of the first base station. Subsequently, the first base station or the CU of the first base station forwards the data packet to the second base station according to the data forwarding information.

[0168] That is, the data transmission method further includes: sending an address indication message carrying data forwarding information to the first base station or the CU of the first base station;

[0169] Receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0170] like Figure 6 As shown, an embodiment of the present application provides another flow chart of a data transmission method. The data transmission method provided in this embodiment is used in a distributed unit DU of a first base station. The data transmission method includes:

[0171] Step 401: Receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state.

[0172] For the four-step random access process, the preamble sent by the receiving terminal at the PRACH opportunity is detected, and a random access response message is sent to the terminal, which is scrambled using the RA-RNTI corresponding to the PRACH opportunity when the preamble was sent;

[0173] For the two-step random access process, the preamble code sent by the terminal at the PRACH timing is received, and the data packet and RRC recovery request message sent by the terminal at the PUSCH timing are received.

[0174] Step 402: Send the data packet and the RRC recovery request message to a centralized unit CU of the first base station.

[0175] Step 403: Receive an RRC release message sent by the CU of the first base station;

[0176] For the four-step random access process, the CU of the first base station sends an RRC release message to the terminal, carrying a suspension indication.

[0177] For the two-step random access process, the CU of the first base station may carry the RRC release message in the MSG B message.

[0178] Step 404: Send the RRC release message to the terminal.

[0179] The DU of the first base station sends the RRC release message to the terminal. After receiving the RRC release message, the terminal releases the RRC connection and enters the RRC inactive state, which can save power consumption of the terminal. The RRC release message is also used to indicate that the terminal contention conflict is successfully resolved.

[0180] In this embodiment, the DU of the first base station receives a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state; sends the data packet and the RRC recovery request message to a centralized unit CU of the first base station; receives an RRC release message sent by the CU of the first base station; and sends the RRC release message to the terminal. The timing of data packet transmission is advanced, which reduces the transmission delay, speeds up the process of the terminal returning to the RRC inactive state, and saves the power consumption of the terminal.

[0181] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0182] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0183] Furthermore, the data packet is encapsulated in a first MAC PDU or a second MAC PDU, the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0184] The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0185] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0186] or

[0187] The subheader information of the second MAC SDU includes logical channel identification information.

[0188] Furthermore, the sub-header information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

[0189] The above and Figure 1 For details of the same contents in the embodiments shown in FIG. Figure 1 The relevant records in the illustrated embodiments are not repeated here.

[0190] Further, the sending of the data packet and the RRC recovery request message to the centralized unit CU of the first base station includes:

[0191] The data packet is sent to the CU via an initial RRC transfer message or via a user plane interface between the CU and the DU.

[0192] Further, sending the data packet to the CU through the user plane interface between the CU and the DU includes:

[0193] Receiving a UE context establishment request message carrying transport network layer information sent by the CU;

[0194] According to the transmission network layer information, the data packet is sent to the CU.

[0195] The DU sends a UE context establishment request message to the CU, and the UE context establishment request message carries transmission network layer information, such as network layer address information. The DU sends the data packet to the CU according to the transmission network layer information. Specifically, the DU may send a UE context establishment reply message and a data packet to the CU.

[0196] Furthermore, the data transmission method also includes: receiving BSR information sent by the terminal, and sending the BSR information to the CU of the first base station.

[0197] The DU of the first base station receives buffer status report (Buffer Status Report, BSR for short) information sent by the terminal, where the BSR information is used to inform the terminal of the buffer status.

[0198] Several scenarios are provided below to illustrate the process of the data transmission method provided in this application. Figures 7a-7d In the figure, the target base station can be understood as the first base station or the DU of the first base station or the CU of the first base station, the anchor base station can be understood as the second base station, and the core network can be the access and mobility management function (Access and Mobility Management Function, AMF for short) network element or the user plane function (User Plane Function, UPF for short) network element.

[0199] like Figure 7a Scenario 1 is shown: data packets are sent based on four-step RACH, and the anchor base station does not switch.

[0200] Wherein, step 10: the terminal is in an RRC inactive state (ie, RRC_inactive state);

[0201] Step 11: The terminal has uplink small packet data to transmit and sends a preamble code to the base station during the PRACH period.

[0202] Step 12: The base station detects the preamble and sends a random access response to the terminal, which mainly includes TA, UL grant, RAPID and other information, and uses the PRACH opportunity of sending the preamble to scramble the corresponding RA-RNTI.

[0203] Step 13: If the terminal finds that the random access response is for itself, that is, the RAPID is consistent, it will send the terminal ID and the uplink data packet on the ULGrant resource. There are several specific solutions:

[0204] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0205] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0206] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0207] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0208] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations. In this way, the data packet is processed in the normal way, including PDCP layer and RLC layer processing, generating a MAC SDU, and the SDU is combined with the MACsubheader to form a MAC sub-PDU, which is then placed after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, in this mode, since the bearer is activated, the LCID can use the logical channel ID of normal data, that is, 000001-100000.

[0209] Step 14: After receiving the data packet and connection recovery request message sent by the terminal, the access base station (i.e., the target base station) obtains the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends a terminal context acquisition request message (i.e., UE context retrieval request message) to the anchor base station. The content carried in this message has the following situations:

[0210] Case 1: The access base station sends the RRC recovery reason as data packet transmission in the terminal context acquisition request message, and carries the DRB ID corresponding to the data packet, so that the anchor base station can know the DRB ID corresponding to the data packet so as to subsequently send the data packet to the core network through the appropriate tunnel.

[0211] Case 2: The access base station sends the RRC recovery reason as data packet transmission in the terminal context acquisition request message, and / or sends the MAC sub-PDU information to the anchor base station.

[0212] Step 15: The anchor base station learns that the reason for the connection recovery request (i.e., the RRC recovery reason) is data packet transmission, obtains the IP data packet and DRB ID information, and sends a terminal context acquisition failure message (i.e., UE context retrieval failure message) to the access base station. The message can carry the TNL layer information of the anchor base station, including IP address information and GTP-U TEID information, and can also use step 15' in the subsequent step to send TNL indication information to inform the access base station of the TNL information of the anchor base station, so that the access base station can transfer data to the anchor base station.

[0213] There are two specific ways to obtain IP data packets and DRB information:

[0214] Case 1: Obtain the DRB ID or PDU session ID information from the terminal context acquisition request message, obtain the data packet from the data plane between the anchor base station and the access base station, and send the data packet to the core network.

[0215] Case 2: Parse the MAC PDU sent from the access base station to obtain the DRB or PDU session ID information corresponding to the LCID, parse it to obtain the data packet, and send the data packet to the core network.

[0216] Step 16: The access base station sends an RRC release message to the terminal, carrying a suspension indication, and the terminal enters an inactive state. The RRC release message is also used to indicate that the terminal contention conflict is successfully resolved.

[0217] like Figure 7b Scenario 2 is shown: data packets are sent based on four-step RACH, and the anchor base station is switched.

[0218] Step 20: The terminal is in RRC_inactive state.

[0219] Step 21: The terminal has uplink small packet data to transmit and sends a preamble code to the base station during the PRACH period.

[0220] Step 22: The base station detects the preamble and sends a random access response to the terminal, which mainly includes TA, UL grant, RAPID and other information, and uses the PRACH opportunity of sending the preamble to scramble the corresponding RA-RNTI.

[0221] Step 23: If the terminal finds that the random access response is for itself, that is, the RAPID is consistent, it will send the terminal ID and the uplink data packet in the ULGrant resource provider. There are several specific solutions:

[0222] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0223] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0224] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel (i.e., tunnel) and send it to the core network.

[0225] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0226] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0227] Step 24: After receiving the data packet and connection recovery request message sent by the terminal, the access base station obtains the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station.

[0228] Step 25: Receive the terminal context request reply message sent by the anchor base station. If the terminal context is successfully restored, obtain the DRB ID information and data packet from the MAC sub-PDU, or parse the data packet corresponding to the LCID from the MAC PDU and obtain the DRB information and PDU session information.

[0229] Step 26: The access base station sends a path switching request to the core network;

[0230] Step 27: Receive a path switching request reply sent by the core network.

[0231] Step 28: The access base station sends the data packet to the core network through the appropriate tunnel.

[0232] Step 29: The access base station sends a terminal context release message to the anchor base station.

[0233] like Figure 7c Scenario 3 is shown: two-step RACH sends data packets and the anchor base station does not switch.

[0234] Step 30: The terminal is in RRC_inactive state.

[0235] Step 31: The terminal has uplink small packet data to transmit, sends a preamble to the base station during the PRACH period, and sends an RRC recovery request and data packet during the PUSCH period. There are several specific solutions:

[0236] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0237] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0238] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0239] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0240] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0241] Step 32: The access base station detects the preamble and successfully demodulates the MAC PDU information carried by the PUSCH.

[0242] After receiving the data packet and connection recovery request message (i.e., RRC recovery request message) sent by the terminal, the access base station obtains the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station. The content carried in this message has the following situations:

[0243] Case 1: The access base station sends the RRC recovery reason as data packet transmission in the terminal context acquisition request message, and carries the DRB ID corresponding to the data packet, so that the anchor base station can know the DRB ID corresponding to the data packet so as to subsequently send the data packet to the core network through the appropriate tunnel.

[0244] Case 2: The access base station sends the RRC recovery reason as data packet transmission in the terminal context acquisition request message, and / or sends the MAC sub-PDU information to the anchor base station.

[0245] Step 33: The anchor base station learns that the reason for the connection recovery request is data packet transmission, obtains the IP data packet and DRBID information, and sends a terminal context acquisition failure message to the access base station. The message can carry the TNL layer information of the anchor base station including IP address information and GTP-U TEID information, and can also use step 33' in the subsequent step to send TNL indication information to inform the access base station of the TNL information of the anchor base station, so that the access base station can transfer data to the anchor base station.

[0246] The specific method of obtaining IP data packets and DRB information includes: obtaining DRBID or PDU session ID information from the terminal context acquisition request message, obtaining data packets from the data plane between the anchor base station and the access base station, and sending the data packets to the core network. Alternatively, parse the MAC PDU sent by the access base station to obtain the DRB or PDU session ID information corresponding to the LCID, parse to obtain the data packet, and send the data packet to the core network.

[0247] Step 34: The access base station sends a MSG B message to the terminal, which may include successful random access response information, RRC release information, and RAPID information.

[0248] Furthermore, if the terminal receives the corresponding information of successful random access and the terminal identifier and RAPID correspond to its own, it considers that the data is sent successfully, otherwise it continues to try random access.

[0249] like Figure 7d Scenario 4 is shown: data packets are sent based on two-step RACH, and the anchor base station is switched.

[0250] Step 40: The terminal is in RRC_inactive state.

[0251] Step 41: The terminal has uplink small packet data to transmit, sends a preamble to the base station during the PRACH period, and sends an RRC recovery request and data packet during the PUSCH period. There are several specific solutions:

[0252] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0253] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0254] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0255] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0256] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0257] Step 42: After receiving the data packet and connection recovery request message sent by the terminal, the access base station obtains the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station.

[0258] Step 43: Receive the terminal context request reply message sent by the anchor base station. If the terminal context is successfully restored, obtain the DRB ID information and the data packet from the MAC sub-PDU, or parse the data packet corresponding to the LCID from the MAC PDU and obtain the DRB information and PDU session information.

[0259] Step 44: The access base station sends a path switching request to the core network;

[0260] Step 45: Receive the path switching request reply sent by the core network.

[0261] Step 46: The access base station sends the data packet to the core network through a suitable tunnel.

[0262] Step 47: The access base station sends a MSG B message to the terminal, which may include successful random access response information, RRC release message and RAPID information, etc.

[0263] Furthermore, if the terminal receives the corresponding information of successful random access and the terminal identifier and RAPID correspond to its own, it considers that the data is sent successfully, otherwise it continues to try random access.

[0264] Since the first base station can be divided into a first base station CU and a DU of the first base station, information interaction between the CU and the DU is involved. Figure 7e The figure shows a description of steps for sending data packets using four-step RACH without changing the anchor base station. The process is also applicable to the scenario of changing the anchor base station using four-step RACH, the scenario of changing the anchor base station using two-step RACH, and the scenario of not changing the anchor base station using two-step RACH.

[0265] like Figure 7e The CU-DU architecture is shown as sending data packets based on the four-step RACH and the anchor base station switching scenario.

[0266] Step 50: The terminal is in RRC inactive state.

[0267] Step 51: The terminal has uplink small packet data to transmit and sends a preamble code to the DU during the PRACH timing.

[0268] Step 52: DU detects the preamble and sends a random access response to the terminal, which mainly includes TA, UL grant, RAPID and other information, and uses the PRACH opportunity of sending the preamble to correspond to RA-RNTI scrambling.

[0269] Step 53: If the terminal finds that the random access response is for itself, that is, the RAPID is consistent, it will send the terminal ID and the uplink data packet in the ULGrant resource provider. There are several specific solutions:

[0270] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0271] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0272] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0273] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0274] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3bAs shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0275] Step 54: After receiving the data packet and connection recovery request message sent by the terminal, the access base station DU sends the above connection recovery request message to the CU. Optionally, the data packet is sent to the CU. The CU will obtain the I-RNTI and MAC-I from the connection recovery message and obtain the ID information of the anchor base station.

[0276] Step 55: The CU sends a terminal context acquisition request message to the anchor base station.

[0277] Step 56: The CU receives the terminal context request reply message sent by the anchor base station. If the terminal context is successfully restored, the DRB ID information and the data packet are obtained from the MAC sub-PDU, or the data packet corresponding to the LCID is parsed from the MAC PDU, and the DRB information and PDU session information are obtained.

[0278] Step 57: The access base station CU sends a UE context establishment request to the DU, carrying the transmission network layer address information.

[0279] Step 58: The DU sends a UE context establishment reply message to the CU.

[0280] Step 58': Optionally, the DU sends the data packet to the CU according to the transmission network layer address information.

[0281] Step 59: CU sends a path switching request to the core network;

[0282] Step 59': CU sends an RRC release message to DU;

[0283] Step 510': The DU sends an RRC release message to the terminal.

[0284] Step 510: Receive a path switching request reply sent by the core network.

[0285] Step 511: The CU sends the data packet to the core network through a suitable tunnel.

[0286] Step 512: The CU sends a terminal context release message to the anchor base station.

[0287] like Figure 7f The CU-DU architecture is shown as sending data packets based on the four-step RACH, and the anchor base station does not switch scenarios.

[0288] Step 60: The terminal is in RRC inactive state.

[0289] Step 61: The terminal has uplink small packet data to transmit and sends a preamble code to the DU during the PRACH timing.

[0290] Step 62: DU detects the preamble and sends a random access response to the terminal, which mainly includes TA, UL grant, RAPID and other information, and uses the PRACH opportunity of sending the preamble to scramble the corresponding RA-RNTI.

[0291] Step 63: If the terminal finds that the random access response is for itself, that is, the RAPID is consistent, it will send the terminal ID and the uplink data packet in the ULGrant resource provider. There are several specific solutions:

[0292] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0293] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0294] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0295] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0296] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, in this case, LCID can use the logical channel ID of normal data, that is, 000001-100000.

[0297] Step 64: After receiving the data packet and connection recovery request message sent by the terminal, the access base station DU sends the above connection recovery request message to the CU. Optionally, the data packet is sent to the CU. The CU will obtain the I-RNTI and MAC-I from the connection recovery message and obtain the ID information of the anchor base station.

[0298] Step 65: The CU sends a terminal context acquisition request message to the anchor base station.

[0299] Step 66: CU receives the terminal context request reply message sent by the anchor base station. The context request reply message is a terminal context acquisition failure message. The message may carry the TNL layer information of the anchor base station, including IP address information and GTP-U TEID information. In subsequent steps, the TNL indication information may be sent to inform the access base station of the TNL information of the anchor base station, so that the access base station transfers data to the anchor base station.

[0300] Step 67: The CU sends a UE context establishment request to the DU, carrying the transport network layer address information.

[0301] Step 68: The DU sends a UE context establishment reply message to the CU.

[0302] Step 68': Optionally, the DU sends the data packet to the CU according to the transmission network layer address information.

[0303] Step 69': The CU sends an RRC release message to the DU.

[0304] Step 610': The DU sends an RRC release message to the terminal.

[0305] Step 610: The CU sends a data packet to the anchor base station.

[0306] Step 611: The anchor base station sends the data packet to the core network.

[0307] Step 612: The CU sends a terminal context release message to the anchor base station.

[0308] like Figure 7f The CU-DU architecture is shown as sending data packets based on two-step RACH, and the anchor base station does not switch scenarios.

[0309] Step 70: The terminal is in RRC_inactive state.

[0310] Step 71: The terminal has uplink small packet data to transmit, sends a preamble to the base station during the PRACH period, and sends an RRC recovery request and data packet during the PUSCH period. There are several specific solutions:

[0311] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0312] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0313] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0314] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0315] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3bAs shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0316] Step 72: After receiving the data packet and connection recovery request message sent by the terminal, the DU sends the connection recovery request message to the CU. Optionally, the data packet is sent to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station. The CU sends a terminal context acquisition request message to the anchor base station.

[0317] Step 73: The CU receives a terminal context request reply message sent by the anchor base station, which is a terminal context acquisition failure message. If the terminal context is successfully restored, the DRB ID information and the data packet are obtained from the MAC sub-PDU, or the data packet corresponding to the LCID is parsed from the MAC PDU, and the DRB information and PDU session information are obtained.

[0318] Step 74: The CU sends a UE context establishment request to the DU, carrying the transport network layer address information.

[0319] Step 75: The DU sends a UE context establishment reply message to the CU.

[0320] Step 75': Optionally, the DU sends the data packet to the CU according to the transmission network layer address information.

[0321] Step 76': The CU sends an RRC release message to the DU.

[0322] Step 77': The DU sends an RRC release message to the terminal.

[0323] Step 76: The CU sends the data packet to the anchor base station.

[0324] Step 77: The anchor base station sends the data packet to the core network.

[0325] Step 78: The CU sends a terminal context release message to the anchor base station.

[0326] like Figure 7f The CU-DU architecture is shown as sending data packets based on two-step RACH and the anchor base station switching scenario.

[0327] Step 80: The terminal is in RRC_inactive state.

[0328] Step 81: The terminal has uplink small packet data to transmit, sends a preamble to the base station during the PRACH period, and sends an RRC recovery request and data packet during the PUSCH period. There are several specific solutions:

[0329] Solution 1: If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as MAC SDU into MAC PDU and sends it out. The terminal adds a MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether other MAC PDUs are included. The specific MAC PDU is as follows: Figure 3a As shown:

[0330] The first subheader S field indicates whether there is a subsequent MAC sub-PDU. The subheader of the second MAC sub-PDU has the following two conditions:

[0331] Case 1: The header information (i.e., sub-header information) contains a dedicated LCID corresponding to the data packet, which is used by the base station to identify that this is an IP data packet, and the DRB ID information corresponding to the data packet, which is used by the base station to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0332] Case 2: The header information contains the DRB ID information corresponding to the data packet. The base station recognizes that this is an IP data packet and is used to know which bearer of the terminal the data packet corresponds to, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.

[0333] Solution 2: If the terminal needs to send an uplink data packet, it first activates the SRB, DRB and other configurations, processes the uplink data packet in the normal way, including PDCP layer and RLC layer processing, generates a MAC SDU, and forms a MAC sub-PDU with the SDU and MACsubheader, and then places it after the MAC sub-PDU carrying CCCH or DCCH, such as Figure 3b As shown, the LCID in the figure uses the logical channel ID of normal data, that is, 000001-100000.

[0334] Step 82: After receiving the data packet and connection recovery request message sent by the terminal, the DU sends the connection recovery request message to the CU. Optionally, the data packet is sent to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station. The CU sends a terminal context acquisition request message to the anchor base station.

[0335] Step 83: The CU receives the terminal context request reply message sent by the anchor base station.

[0336] Step 84: The CU sends a UE context establishment request to the DU, carrying the transport network layer address information.

[0337] Step 85: The DU sends a UE context establishment reply message to the CU.

[0338] Step 85': Optionally, the DU sends the data packet to the CU according to the transmission network layer address information.

[0339] Step 86: The CU sends a path switching request to the core network.

[0340] Step 86': The CU sends an RRC release message to the DU.

[0341] Step 87: Receive the path switching request reply sent by the core network.

[0342] Step 88: The CU sends the data packet to the core network through a suitable tunnel.

[0343] Step 89: The CU sends a terminal context release message to the anchor base station.

[0344] In the above embodiment, the target base station receives a data packet sent by the terminal during random access, and sends the data packet to the core network when the anchor base station switches or does not switch. When the anchor base station does not switch, the target base station and the anchor base station exchange data packets, DRB ID, anchor base station TNL and other information, the target base station sends the data packet to the anchor base station, and the anchor base station sends the data packet to the core network; when the anchor base station switches, the target base station obtains the terminal context, restores the terminal context, obtains the data packet, and sends the data packet to the core network after the path is switched.

[0345] The above-mentioned embodiment utilizes a two-step random access process or a four-step random access process to send small data packets, and can send data packets in scenarios where the RRC connection does not need to be restored and the anchor base station can be switched or cannot be switched. This can solve the shortcomings of the existing technology that the transmission of small data packets requires the RRC connection to be restored first and the anchor base station needs to be switched, which causes large data packet transmission delay and low efficiency.

[0346] like Figure 8 As shown, Figure 8 is a schematic diagram of the structure of a terminal provided by an embodiment of the present invention, such as Figure 8 As shown, the terminal 600 is in a radio resource control RRC inactive state, and the terminal 600 includes:

[0347] A first sending module 601 is configured to send a data packet and an RRC recovery request message to a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station;

[0348] The first receiving module 602 is used to receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station.

[0349] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0350] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0351] Furthermore, it also includes an encapsulation template, which is used to encapsulate the data packet directly as a first media access control MAC service data unit SDU into a first MAC protocol data unit PDU;

[0352] or

[0353] The second MAC SDU generated by pre-processing the data packet is encapsulated into the second MAC PDU.

[0354] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0355] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0356] or

[0357] The subheader information of the second MAC SDU includes logical channel identification information.

[0358] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identification dedicated to IP data packets.

[0359] Terminal 600 can realize Figure 1 The various processes implemented by the terminal in the method embodiment shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0360] Fig. 9The terminal 800 is a schematic diagram of the structure of the terminal in various embodiments of the present invention. The terminal 800 includes but is not limited to: a transceiver unit (i.e., a transceiver) 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, a display unit 806, a user input unit 807, an interface unit 808, a memory 809, a processor 810, and a power supply 88. Those skilled in the art can understand that Fig. 9 The terminal structure shown in the figure does not constitute a limitation on the terminal, and the terminal may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. In the embodiment of the present invention, the terminal includes but is not limited to a mobile phone, a tablet computer, a laptop computer, a PDA, a vehicle-mounted terminal, a wearable device, and a pedometer.

[0361] In one embodiment of the present invention, the transceiver unit 801 is used to send a data packet and an RRC recovery request message to the first base station or the centralized unit CU of the first base station or the distributed unit DU of the first base station; and receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station.

[0362] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0363] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0364] Further, the processor 810 is configured to encapsulate the data packet directly as a first media access control MAC service data unit SDU into a first MAC protocol data unit PDU;

[0365] or

[0366] The second MAC SDU generated by pre-processing the data packet is encapsulated into the second MAC PDU.

[0367] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0368] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0369] or

[0370] The subheader information of the second MAC SDU includes logical channel identification information.

[0371] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identification dedicated to IP data packets.

[0372] Terminal 800 can achieve Figure 1 The various processes implemented by the terminal in the method embodiment shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0373] It should be understood that in the embodiment of the present invention, the transceiver unit 801 can be used for receiving and sending signals during information transmission or communication. Specifically, after receiving downlink data from the base station, it is sent to the processor 810 for processing; in addition, uplink data is sent to the base station. Generally, the transceiver unit 801 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, etc. In addition, the transceiver unit 801 can also communicate with the network and other devices through a wireless communication system.

[0374] The terminal provides users with wireless broadband Internet access through the network module 802, such as helping users to send and receive emails, browse web pages, and access streaming media.

[0375] The audio output unit 803 can convert the audio data received by the transceiver unit 801 or the network module 802 or stored in the memory 809 into an audio signal and output it as sound. Moreover, the audio output unit 803 can also provide audio output related to a specific function performed by the terminal 800 (for example, a call signal reception sound, a message reception sound, etc.). The audio output unit 803 includes a speaker, a buzzer, a receiver, etc.

[0376] The input unit 804 is used to receive audio or video signals. The input unit 804 may include a graphics processor (Graphics Processing Unit, referred to as GPU) 8041 and a microphone 8042, and the graphics processor 8041 processes the image data of a static picture or video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The processed image frame can be displayed on the display unit 806. The image frame processed by the graphics processor 8041 can be stored in the memory 809 (or other storage medium) or sent via the transceiver unit 801 or the network module 802. The microphone 8042 can receive sound and can process such sound into audio data. The processed audio data can be converted into a format output that can be sent to a mobile communication base station via the transceiver unit 801 in the case of a telephone call mode.

[0377] The terminal 800 also includes at least one sensor 805, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 8061 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 8061 and / or the backlight when the terminal 800 is moved to the ear. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), and can detect the magnitude and direction of gravity when stationary, which can be used to identify the terminal posture (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; the sensor 805 can also include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc., which will not be repeated here.

[0378] The display unit 806 is used to display information input by the user or information provided to the user. The display unit 806 may include a display panel 8061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0379] The user input unit 807 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the terminal. Specifically, the user input unit 807 includes a touch panel 8071 and other input devices 8072. The touch panel 8071, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 8071 or near the touch panel 8071 using any suitable object or accessory such as a finger, stylus, etc.). The touch panel 8071 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into the contact point coordinates, and then sends it to the processor 810, receives the command sent by the processor 810 and executes it. In addition, the touch panel 8071 can be implemented using multiple types such as resistive, capacitive, infrared and surface acoustic waves. In addition to the touch panel 8071, the user input unit 807 may also include other input devices 8072. Specifically, other input devices 8072 may include but are not limited to a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0380] Furthermore, the touch panel 8071 may be overlaid on the display panel 8061. When the touch panel 8071 detects a touch operation on or near it, it transmits the information to the processor 810 to determine the type of the touch event. Then, the processor 810 provides a corresponding visual output on the display panel 8061 according to the type of the touch event. Figure 8 In the embodiment, the touch panel 8071 and the display panel 8061 are used as two independent components to implement the input and output functions of the terminal. However, in some embodiments, the touch panel 8071 and the display panel 8061 can be integrated to implement the input and output functions of the terminal, which is not limited here.

[0381] The interface unit 808 is an interface for connecting an external device to the terminal 800. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, etc. The interface unit 808 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements in the terminal 800 or may be used to transmit data between the terminal 800 and an external device.

[0382] The memory 809 can be used to store software programs and various data. The memory 809 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 809 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0383] The processor 810 is the control center of the terminal. It uses various interfaces and lines to connect various parts of the entire terminal. It executes various functions of the terminal and processes data by running or executing software programs and / or modules stored in the memory 809, and calling data stored in the memory 809, so as to monitor the terminal as a whole. The processor 810 may include one or more processing units; preferably, the processor 810 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 810.

[0384] The terminal 800 may also include a power supply 811 (such as a battery) for supplying power to various components. Preferably, the power supply 88 may be logically connected to the processor 810 through a power management system, thereby implementing functions such as charging, discharging, and power consumption management through the power management system.

[0385] In addition, the terminal 800 includes some functional modules not shown, which will not be described in detail here.

[0386] Preferably, an embodiment of the present invention further provides a terminal, including a processor 810, a memory 809, and a computer program stored in the memory 809 and executable on the processor 810, wherein the computer program is executed by the processor 810 to implement the above Figure 1 The various processes of the data transmission method embodiment shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0387] See also Fig.10 , Fig.10 is a schematic diagram of the structure of a network side device provided by an embodiment of the present invention, such as Fig.10 As shown, the first network side device 900 is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, and the first network side device 900 includes:

[0388] The second receiving module 901 is used to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0389] The second sending module 902 is used to send an RRC release message to the terminal.

[0390] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0391] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0392] Furthermore, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0393] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0394] Further, the first MAC PDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0395] or

[0396] The subheader information of the second MAC SDU includes logical channel identification information.

[0397] Furthermore, the sub-header information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

[0398] Furthermore, the first network side device 900 also includes: a third sending module, used to send the restored data packet to the core network.

[0399] Furthermore, the first network side device 900 further includes:

[0400] A fourth sending module, configured to send a UE context retrieval request message to the second base station;

[0401] A third receiving module is used to receive a UE context retrieval reply message sent by the second base station;

[0402] The fifth sending module is used to send the data packet to the core network.

[0403] Furthermore, the fifth sending module is used to obtain the data packet from the first MAC PDU or the second MAC PDU sent by the terminal based on the successfully recovered terminal context, the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet; and send the data packet to the core network.

[0404] Further, the first network side device 900 also includes a sixth sending module, configured to send a UE context retrieval request message to the second base station, wherein the UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet;

[0405] The fourth receiving module is used to receive a UE context retrieval failure message sent by the second base station.

[0406] Furthermore, the first network side device 900 further includes:

[0407] A fifth receiving module, configured to receive data forwarding information carried by the second base station through an address indication message or the message of failure to retrieve UE context;

[0408] A seventh sending module is used to forward the data packet sent by the terminal to the second base station.

[0409] Furthermore, the data packet sent by the terminal is at least one of an IP data packet, a first MAC PDU data packet, a first MAC SDU data packet, a second MAC PDU data packet, a second MAC SDU data packet, a recovered first RLC SDU and a recovered second RLC SDU.

[0410] Furthermore, the RRC recovery reason indication includes at least one of an emergency call, a high priority access, a terminal-terminated access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call, and a terminal-triggered video call.

[0411] The first network side device 900 can implement each process implemented by the first base station or the centralized unit CU of the first base station or the distributed unit DU of the first base station in the method embodiment shown in Figure 3 and achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0412] See also Fig.11 , Fig.11 is a schematic diagram of the structure of a network side device provided by an embodiment of the present invention, such as Fig.11 As shown, the second network side device 1000 includes:

[0413] A sixth receiving module 1001 is configured to receive a user equipment UE context retrieval request message sent by the first base station or a centralized unit CU of the first base station;

[0414] An eighth sending module 1002 is configured to send a message of failure to retrieve UE context to the first base station or the CU of the first base station;

[0415] The ninth sending module 1003 sends the data packet to the core network.

[0416] Furthermore, the UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet.

[0417] Furthermore, the second network side device 1000 further includes:

[0418] The seventh receiving module is used to receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0419] Furthermore, the second network side device 1000 further includes:

[0420] a tenth sending module, configured to send an address indication message carrying data forwarding information to the first base station or the CU of the first base station;

[0421] An eighth receiving module is used to receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0422] The second network side device 1000 can implement Figure 4 The various processes implemented by the second base station in the method embodiment shown and the same technical effects achieved are not described again here to avoid repetition.

[0423] See also Fig.12 , Fig.12 is a schematic diagram of the structure of a second network side device provided by an embodiment of the present invention, such as Fig.12 As shown, the third network side device 1100 is a DU of the first base station, and the third network side device 1100 includes:

[0424] The ninth receiving module 1101 is used to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;

[0425] An eleventh sending module 1102 is configured to send the data packet and the RRC recovery request message to a centralized unit CU of the first base station;

[0426] The tenth receiving module 1103 is configured to receive an RRC release message sent by the CU of the first base station;

[0427] The twelfth sending module 1104 is configured to send the RRC release message to the terminal.

[0428] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0429] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0430] Furthermore, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0431] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0432] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0433] or

[0434] The subheader information of the second MAC SDU includes logical channel identification information.

[0435] Furthermore, the sub-header information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

[0436] Furthermore, the eleventh sending module 1102 further includes:

[0437] The sending submodule is used to send the data packet to the CU through an initial RRC transfer message or through a user plane interface between the CU and the DU.

[0438] Further, a sending submodule is used to receive a UE context establishment request message carrying transmission network layer information sent by the CU;

[0439] According to the transmission network layer information, the data packet is sent to the CU.

[0440] Furthermore, the third network side device 1100 further includes:

[0441] The eleventh receiving module is used to receive the buffer status report BSR information sent by the terminal, and send the BSR information to the CU of the first base station.

[0442] The third network side device 1100 can implement Figure 5 The various processes implemented by the DU of the first base station in the method embodiment shown and the same technical effects achieved are not described here to avoid repetition.

[0443] See also Fig.13 , Fig.13 is a schematic diagram of the structure of a network side device provided by an embodiment of the present invention, such as Fig.13 As shown, it includes a bus 1201, a transceiver 1202, an antenna 1203, a bus interface 1204, a processor 1205 and a memory 1206.

[0444] In one embodiment of the present invention, the network side device is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, and the transceiver 1202 is used to receive data packets and RRC recovery request messages sent by a terminal in an inactive state of radio resource control RRC; and send an RRC release message to the terminal.

[0445] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0446] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0447] Furthermore, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0448] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0449] Further, the first MAC PDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0450] or

[0451] The subheader information of the second MAC SDU includes logical channel identification information.

[0452] Furthermore, the sub-header information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

[0453] Furthermore, the transceiver 1202 is also used to send the recovered data packet to the core network.

[0454] Further, the transceiver 1202 is further configured to send a UE context retrieval request message to the second base station;

[0455] receiving a UE context retrieval reply message sent by the second base station;

[0456] Send the data packet to the core network.

[0457] Further, the transceiver 1202 is further configured to obtain the data packet from a first MAC PDU or a second MAC PDU sent by the terminal according to the successfully recovered terminal context, wherein the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet;

[0458] Send the data packet to the core network.

[0459] Further, the transceiver 1202 is further configured to send a UE context retrieval request message to the second base station, wherein the UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet;

[0460] A UE context retrieval failure message sent by the second base station is received.

[0461] Further, the transceiver 1202 is further configured to receive data forwarding information carried by the second base station through an address indication message or the UE context retrieval failure message;

[0462] forwarding the data packet sent by the terminal to the second base station.

[0463] Furthermore, the data packet sent by the terminal is at least one of an IP data packet, a first MAC PDU data packet, a first MAC SDU data packet, a second MAC PDU data packet, a second MAC SDU data packet, a recovered first RLC SDU and a recovered second RLC SDU.

[0464] Furthermore, the RRC recovery reason indication includes at least one of an emergency call, a high priority access, a terminal-terminated access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call, and a terminal-triggered video call.

[0465] The device in this embodiment can implement the various processes implemented by the first base station or the centralized unit CU of the first base station or the distributed unit DU of the first base station in the embodiment shown in Figure 3 to achieve the same technical effect, which will not be repeated here.

[0466] In another embodiment of the present application, the network side device is a second base station, and the transceiver 1202 is used to receive a user equipment UE context retrieval request message sent by the first base station or the centralized unit CU of the first base station; send a UE context retrieval failure message to the first base station or the CU of the first base station; and send the data packet to the core network.

[0467] Furthermore, the UE context retrieval request message carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet.

[0468] Furthermore, the transceiver 1202 is also used to receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0469] Furthermore, the transceiver 1202 is also used to send an address indication message carrying data forwarding information to the first base station or the CU of the first base station; and receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

[0470] The device in this embodiment can realize Figure 4 The various processes implemented by the second base station in the illustrated embodiment achieve the same technical effect, which will not be described in detail here.

[0471] In another embodiment of the present application, the network side device is the DU of the first base station, and the transceiver 1202 is used to receive a data packet and an RRC recovery request message sent by a terminal in an inactive state of the radio resource control RRC; send the data packet and the RRC recovery request message to the centralized unit CU of the first base station; receive the RRC release message sent by the CU of the first base station; and send the RRC release message to the terminal.

[0472] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

[0473] Furthermore, the data packet is multiplexed or concatenated with the RRC recovery request message.

[0474] Furthermore, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

[0475] Furthermore, the pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

[0476] Further, the subheader information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet;

[0477] or

[0478] The subheader information of the second MAC SDU includes logical channel identification information.

[0479] Furthermore, the sub-header information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

[0480] Furthermore, the transceiver 1202 is also used to send the data packet to the CU via an initial RRC transfer message or via a user plane interface between the CU and the DU.

[0481] Furthermore, the transceiver 1202 is also used to receive a UE context establishment request message carrying transmission network layer information sent by the CU; and send the data packet to the CU according to the transmission network layer information.

[0482] Furthermore, the transceiver 1202 is also used to receive buffer status report BSR information sent by the terminal, and send the BSR information to the CU of the first base station.

[0483] The device in this embodiment can realize Figure 5 The various processes implemented by the DU of the first base station in the illustrated embodiment achieve the same technical effect, which will not be described in detail here.

[0484] exist Fig.12 In the embodiment, the bus architecture (represented by bus 1201) may include any number of interconnected buses and bridges, and bus 1201 links various circuits including one or more processors represented by processor 1205 and memory represented by memory 1206. Bus 1201 may also link various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. Bus interface 1204 provides an interface between bus 1201 and transceiver 1202. Transceiver 1202 may be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. Data processed by processor 1205 is transmitted on a wireless medium via antenna 1203, and further, antenna 1203 also receives data and transmits the data to processor 1205.

[0485] The processor 1205 is responsible for managing the bus 1201 and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 1206 can be used to store data used by the processor 1205 when performing operations.

[0486] Optionally, the processor 1205 may be a CPU, an ASIC, an FPGA or a CPLD.

[0487] Preferably, an embodiment of the present invention further provides a network side device, including a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and executable on the processor 1205, wherein the computer program is executed by the processor 1205 to implement each process in the data transmission method shown in FIG. 3, or the computer program is executed by the processor 1205 to implement the above Figure 4 The various processes in the data transmission method shown, or the computer program is implemented when the processor 1205 executes the above Figure 5 The various processes in the data transmission method shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0488] The embodiment of the present invention further provides a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the following is implemented: Figure 1 The steps in the data transmission method shown in FIG. 3 are implemented when the computer program is executed by the processor, or the steps in the data transmission method shown in FIG. 3 are implemented when the computer program is executed by the processor. Figure 4 The steps in the data transmission method shown in the figure, or the computer program is implemented when the processor executes the following Figure 5 Steps in the data transmission method shown.

[0489] The computer-readable storage medium is, for example, a ROM, RAM, a magnetic disk or an optical disk.

[0490] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0491] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0492] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation modes, which are merely illustrative rather than restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.

Claims

1. A data transmission method for a terminal in an RRC inactive state, characterized in that: The data transmission method comprises: Sending a data packet and an RRC recovery request message to the first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, wherein the data packet is connected in series with the RRC recovery request message; Receiving an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station; Before sending the data packet and the RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station, the method further includes: The data packet is directly encapsulated into a first MAC protocol data unit PDU as a first media access control MAC service data unit SDU, the subheader information of the first MAC SDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet; or, a second MAC SDU generated by pre-processing the data packet is encapsulated into a second MAC PDU, the subheader information of the second MAC SDU includes logical channel identification information.

2. The data transmission method according to claim 1, characterized in that: The RRC recovery request message is the RRC recovery request message in the four-step random access process, or the RRC recovery request message carried by MSG A in the two-step random access process.

3. The data transmission method according to claim 1, characterized in that: The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

4. The data transmission method according to claim 1, characterized in that: The logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identification dedicated to IP data packets.

5. A data transmission method, used for a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, characterized in that: The data transmission method comprises: Receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state; Send an RRC release message to the terminal; After receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, the method further includes: Sending a UE context retrieval request message to the second base station, where the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message also carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet; A UE context retrieval failure message sent by the second base station is received.

6. The data transmission method according to claim 5, characterized in that: The RRC recovery request message is an RRC connection recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.

7. The data transmission method according to claim 5, characterized in that: The data packet is multiplexed or concatenated with the RRC recovery request message.

8. The data transmission method according to claim 5, characterized in that: The data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet.

9. The data transmission method according to claim 8, characterized in that: The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

10. The data transmission method according to claim 8, characterized in that: The first MAC PDU includes at least one of logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet; or The subheader information of the second MAC SDU includes logical channel identification information.

11. The data transmission method according to claim 8, characterized in that: The subheader information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

12. The data transmission method according to claim 5, characterized in that: After receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, the method further includes: Send the recovered data packet to the core network.

13. The data transmission method according to claim 5, characterized in that: Also includes: Send the data packet to the core network.

14. The data transmission method according to claim 13, characterized in that: Sending the data packet to the core network is specifically as follows: According to the successfully recovered terminal context, the data packet is obtained from a first MAC PDU or a second MAC PDU sent by the terminal, wherein the first MAC PDU includes a first MAC SDU directly generated by the data packet, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet; Send the data packet to the core network.

15. The data transmission method according to claim 5, characterized in that: Also includes: Receiving data forwarding information carried by the second base station through an address indication message or the UE context retrieval failure message; forwarding the data packet sent by the terminal to the second base station.

16. The data transmission method according to claim 5, characterized in that: The data packet sent by the terminal is at least one of an IP data packet, a first MAC PDU data packet, a first MAC SDU data packet, a second MAC PDU data packet, a second MAC SDU data packet, a recovered first RLC SDU and a recovered second RLC SDU.

17. The data transmission method according to claim 5, characterized in that: The RRC recovery reason indication includes at least one of an emergency call, a high priority access, a terminal-terminated access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call, and a terminal-triggered video call.

18. A data transmission method, used in a second base station, characterized in that: The data transmission method comprises: receiving a user equipment UE context retrieval request message sent by the first base station or a centralized unit CU of the first base station, wherein the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message further carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet; Sending a message of failure to retrieve UE context to the first base station or the CU of the first base station; Send data packets to the core network.

19. The data transmission method according to claim 18, further characterized in that: The UE context retrieval failure message carries data forwarding information, and the data transmission method further includes: Receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

20. The data transmission method according to claim 18, further characterized in that: The data transmission method further comprises: Sending an address indication message carrying data forwarding information to the first base station or the CU of the first base station; Receive the data packet sent by the first base station or the CU of the first base station according to the data forwarding information.

21. A data transmission method, applied to a distributed unit DU of a first base station, characterized in that: The data transmission method comprises: Receiving a data packet and an RRC recovery request message sent by a terminal in a radio resource control (RRC) inactive state, wherein the data packet is connected in series with the RRC recovery request message; Sending the data packet and the RRC recovery request message to a centralized unit CU of the first base station; Receiving an RRC release message sent by the CU of the first base station; Sending the RRC release message to the terminal; Among them, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, the first MAC PDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet, the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet, and the sub-header information of the second MAC SDU includes logical channel identification information.

22. The data transmission method according to claim 21, characterized in that: The RRC recovery request message is the RRC recovery request message in the four-step random access process, or the RRC recovery request message carried by MSG A in the two-step random access process.

23. The data transmission method according to claim 21, characterized in that: The pre-processing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearer and data bearer.

24. The data transmission method according to claim 21, characterized in that: The subheader information of the first MAC SDU includes logical channel identification information which is a logical channel identification dedicated to IP data packets.

25. The data transmission method according to claim 21, further characterized in that: The centralized unit CU sending the data packet and the RRC recovery request message to the first base station includes: The data packet is sent to the CU via an initial RRC transfer message or via a user plane interface between the CU and the DU.

26. The data transmission method according to claim 25, characterized in that: Sending the data packet to the CU through the user plane interface between the CU and the DU includes: Receiving a UE context establishment request message carrying transport network layer information sent by the CU; According to the transmission network layer information, the data packet is sent to the CU.

27. The data transmission method according to claim 21, further characterized in that: Also includes: The buffer status report BSR information sent by the receiving terminal is sent to the CU of the first base station.

28. A terminal, the terminal being in a radio resource control (RRC) inactive state, characterized in that: include: A first sending module, configured to send a data packet and an RRC recovery request message to a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, wherein the data packet is connected in series with the RRC recovery request message; A first receiving module, configured to receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station; Among them, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, the first MAC PDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet, the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet, and the sub-header information of the second MAC SDU includes logical channel identification information.

29. A terminal, the terminal being in a radio resource control (RRC) inactive state, characterized in that: including a processor and a transceiver; The transceiver is configured to send a data packet and an RRC recovery request message to a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, and to receive an RRC release message sent by the first base station or the CU of the first base station or the DU of the first base station, wherein the data packet is connected in series with the RRC recovery request message; Among them, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, the first MAC PDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet, the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet, and the sub-header information of the second MAC SDU includes logical channel identification information.

30. A network side device, wherein the network side device is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, characterized in that: include: A second receiving module is used to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state; A second sending module, used for sending an RRC release message to the terminal; a sixth sending module, configured to send a UE context retrieval request message to the second base station, wherein the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message further carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet; The fourth receiving module is used to receive a UE context retrieval failure message sent by the second base station.

31. A network side device, the network side device is a first base station or a centralized unit CU of the first base station or a distributed unit DU of the first base station, characterized in that: including a processor and a transceiver; The transceiver is used to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, and send an RRC release message to the terminal; The transceiver is also used to send a UE context retrieval request message to the second base station, the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message also carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet; and receive a UE context retrieval failure message sent by the second base station.

32. A network side device, the network side device being a second base station, characterized in that: include: A first receiving module, configured to receive a user equipment UE context retrieval request message sent by the first base station or a centralized unit CU of the first base station; A first sending module, configured to send a UE context retrieval failure message to the first base station or the CU of the first base station, wherein the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message further carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, logical channel identification information of the data packet, and bearer identification information of the data packet; The second sending module is used to send data packets to the core network.

33. A network side device, the network side device being a second base station, characterized in that: including a processor and a transceiver; The transceiver is used to receive a user equipment UE context retrieval request message sent by the first base station or the centralized unit CU of the first base station, send a UE context retrieval failure message to the first base station or the CU of the first base station, and send a data packet to the core network, wherein the UE context retrieval request message carries subsequent data packet indication information, and the UE context retrieval request message also carries at least one of an RRC recovery reason indication, a data packet sending indication, a data packet sent by the terminal, the logical channel identification information of the data packet, and the bearer identification information of the data packet.

34. A network side device, the network side device being a DU of a first base station, characterized in that: include: A first receiving module, configured to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state, wherein the data packet is connected in series with the RRC recovery request message; A first sending module, configured to send the data packet and the RRC recovery request message to a centralized unit CU of the first base station; A second receiving module, used to receive an RRC release message sent by the CU of the first base station; A second sending module, used to send the RRC release message to the terminal; Among them, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, the first MAC PDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet, the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet, and the sub-header information of the second MAC SDU includes logical channel identification information.

35. A network side device, the network side device being a DU of a first base station, characterized in that: including a processor and a transceiver; The transceiver is configured to receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state, wherein the data packet is connected in series with the RRC recovery request message; send the data packet and the RRC recovery request message to a centralized unit CU of a first base station; receive an RRC release message sent by the CU of the first base station; and send the RRC release message to the terminal; Among them, the data packet is encapsulated in a first media access control MAC protocol data unit PDU or a second MAC PDU, the first MAC PDU includes a first MAC service data unit SDU directly generated by the data packet, the first MAC PDU includes logical channel identification information and bearer identification information, the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information is used to indicate the data bearer corresponding to the data packet, the second MAC PDU includes a second MAC SDU generated by pre-processing the data packet, and the sub-header information of the second MAC SDU includes logical channel identification information.

36. A terminal, characterized in that: The method comprises a processor, a memory and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the data transmission method according to any one of claims 1 to 4 when executed by the processor.

37. A network side device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the data transmission method as described in any one of claims 5 to 17, or the computer program, when executed by the processor, implements the steps of the data transmission method as described in any one of claims 18 to 20, or the computer program, when executed by the processor, implements the steps of the data transmission method as described in any one of claims 21 to 27.

38. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the data transmission method as described in any one of claims 1 to 4, or, when executed by a processor, implements the steps of the data transmission method as described in any one of claims 5 to 17, when executed by a processor, implements the steps of the data transmission method as described in any one of claims 18 to 20, and when executed by a processor, implements the steps of the data transmission method as described in any one of claims 21 to 27.

Images