WO2022022699A1 - 数据传输方法、终端及网络侧设备 - Google Patents

数据传输方法、终端及网络侧设备 Download PDF

Info

Publication number
WO2022022699A1
WO2022022699A1 PCT/CN2021/109710 CN2021109710W WO2022022699A1 WO 2022022699 A1 WO2022022699 A1 WO 2022022699A1 CN 2021109710 W CN2021109710 W CN 2021109710W WO 2022022699 A1 WO2022022699 A1 WO 2022022699A1
Authority
WO
WIPO (PCT)
Prior art keywords
base station
data packet
terminal
data
transmission method
Prior art date
Application number
PCT/CN2021/109710
Other languages
English (en)
French (fr)
Inventor
刘亮
陈宁宇
韩星宇
胡南
Original Assignee
中国移动通信有限公司研究院
中国移动通信集团有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中国移动通信有限公司研究院, 中国移动通信集团有限公司 filed Critical 中国移动通信有限公司研究院
Priority to JP2023506351A priority Critical patent/JP2023535839A/ja
Priority to US18/040,107 priority patent/US20230319941A1/en
Priority to EP21849926.7A priority patent/EP4178311A4/en
Publication of WO2022022699A1 publication Critical patent/WO2022022699A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present disclosure relates to the field of communication technologies, and in particular, to a data transmission method, a terminal, and a network side device.
  • the state of the terminal also includes an RRC inactive state (RRC_inactive).
  • RRC_inactive can save resources and energy as much as possible. , quickly let the user equipment (User Equipment, UE) enter the RRC connection state and complete the establishment of the Protocol Data Unit (Protocol Data Unit, PDU) session, to meet the demands of ultra-reliable and low-latency scenarios.
  • UE User Equipment
  • the terminal in the RRC inactive state wants to send data, it must first perform connection recovery and enter the RRC connected state before sending data. In the scenario of small packet transmission, this method will increase the transmission delay.
  • Embodiments of the present disclosure provide a data transmission method, a terminal, and a network-side device, so as to solve the problem of relatively large transmission delay in the transmission mode of the related art.
  • an embodiment of the present disclosure provides a data transmission method for a terminal in a radio resource control RRC inactive state, the data transmission method includes:
  • an embodiment of the present disclosure provides a data transmission method 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:
  • an embodiment of the present disclosure provides a data transmission method for a second base station, where the data transmission method includes:
  • the data packet is sent to the core network.
  • an embodiment of the present disclosure provides a data transmission method, which is applied to a distribution unit DU of a first base station, and the data transmission method includes:
  • an embodiment of the present disclosure provides a terminal, where the terminal is in a radio resource control RRC inactive state, including:
  • a sending module configured to send the data packet and the 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;
  • the receiving module is configured to receive the 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.
  • an embodiment of the present disclosure provides a terminal, where the terminal is in a radio resource control RRC inactive state, including a processor and a transceiver;
  • the transceiver is used to send data packets and RRC recovery request messages 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 the first base station or the CU of the first base station or the first base station.
  • the RRC release message sent by the DU of the base station.
  • an embodiment of the present disclosure 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:
  • a 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
  • the sending module is used for sending the RRC release message to the terminal.
  • an embodiment of the present disclosure 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 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 a radio resource control RRC inactive state, and send an RRC release message to the terminal.
  • an embodiment of the present disclosure provides a network-side device, where the network-side device is a second base station, including:
  • a first receiving module configured 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;
  • 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;
  • the second sending module is configured to send the data packet to the core network.
  • an embodiment of the present disclosure provides a network-side device, where the network-side device is a second base station and includes a processor and a transceiver;
  • the transceiver is configured 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 packets to the core network.
  • an embodiment of the present disclosure provides a network-side device, where the network-side device is a DU of a first base station, including:
  • 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
  • a first sending module configured to send the data packet and the RRC recovery request message to the centralized unit CU of the first base station
  • a second receiving module configured to receive the RRC release message sent by the CU of the first base station
  • the second sending module is configured to send the RRC release message to the terminal.
  • an embodiment of the present disclosure provides a network-side device, where the network-side device is a DU of a first base station, and includes a processor and a transceiver;
  • the transceiver is used to receive the data packet and the RRC recovery request message sent by the terminal in the RRC inactive state of the radio resource control; send the data packet and the RRC recovery request message to the centralized unit CU of the first base station; receive the first An RRC release message sent by a CU of a base station; and sending the RRC release message to a terminal.
  • an embodiment of the present disclosure provides a terminal, including a processor, a memory, and a computer program stored on the memory and executable on the processor, when the computer program is executed by the processor. The steps in the data transmission method as described in the first aspect are implemented.
  • an embodiment of the present disclosure provides a network-side device, including a processor, a memory, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor When executed, the steps in the data transmission method described in the second aspect are realized, or the computer program is executed by the processor to realize the steps in the data transmission method described in the third aspect, or the computer program is executed by the processor.
  • the processor implements the steps in the data transmission method according to the fourth aspect when executed.
  • an embodiment of the present disclosure provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program according to the first aspect of the claim is implemented.
  • the steps in the data transmission method or, when the computer program is executed by the processor, implements the steps in the data transmission method described in the second aspect, or, when the computer program is executed by the processor, implements the steps as described in the second aspect.
  • the steps in the data transmission method described in the third aspect, or, when the computer program is executed by the processor implements the steps in the data transmission method described in the fourth aspect.
  • 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 the first base station or the CU of the first base station or the first base station.
  • FIG. 2 is a schematic flowchart of data transmission between a terminal and a target base station in the related art
  • FIG. 3 a and FIG. 3 b are schematic diagrams of the field structure of a MAC PDU provided by an embodiment of the present disclosure
  • FIG. 6 is a fourth flowchart of a data transmission method provided by an embodiment of the present disclosure.
  • FIGS. 8 and 9 are structural diagrams of a terminal provided by an embodiment of the present disclosure.
  • 10-13 are structural diagrams of network-side devices provided by embodiments of the present disclosure.
  • FIG. 1 is a flowchart of a data transmission method provided by an embodiment of the present disclosure, which is used for a terminal in a radio resource control RRC inactive state. As shown in FIG. 1, the data transmission method includes the following steps:
  • Step 101 Send a data packet and an RRC recovery request message to a first base station or a Centralized Unit (CU for short) of the first base station or a Distributed Unit (DU for short) of the first base station.
  • a Centralized Unit CU for short
  • DU Distributed Unit
  • the data packet may be application data of various applications, such as data packets of instant messaging software, heartbeat packets of applications such as mail, data packets of smart wearable devices and sensors, and the like.
  • 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.
  • the terminal sends a preamble 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, PRACH for short) opportunity.
  • the CU of the 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, RA for short) radio network temporary identifier (RNTI) corresponding to the PRACH opportunity for sending the preamble.
  • the terminal receives the 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, RAPID (Random Access Preamble Identifier, Random Access preamble identifier) is consistent, then the terminal sends 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.
  • RAPID Random Access Preamble Identifier, Random Access preamble identifier
  • step 101 includes: the terminal sends a preamble to the first base station or the CU of the first base station or the DU of the first base station at the PRACH opportunity, and transmits a preamble on the Physical Uplink Shared Channel (Physical Uplink Shared Channel, referred to as the DU for short).
  • PUSCH Physical Uplink Shared Channel
  • Step 102 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.
  • the terminal After receiving the RRC release message, the terminal releases the RRC connection, and the terminal enters the RRC inactive state, which can save the power consumption of the terminal.
  • the target base station is the first base station or the CU or CU of the first base station.
  • Step 111 the terminal sends a preamble to the target base station
  • Step 112 the terminal receives the random access response message of the target base station
  • Step 113 the terminal sends an RRC recovery request message to the target base station
  • Step 114 the terminal receives the RRC recovery message sent by the target base station
  • Step 115 the terminal sends an RRC recovery complete message to the target base station
  • Step 116 the terminal sends a data packet to the target base station.
  • the data transmission method of the specific embodiment of the present disclosure does not need to start transmitting data packets after the RRC recovery is completed, but only after receiving the random access response message.
  • Data packets can be transmitted, that is to say, the timing of data packet transmission is advanced, which reduces the transmission delay.
  • the specific embodiments of the present disclosure can speed up the process of the terminal returning to the RRC inactive state, and save the power consumption of the terminal.
  • the power consumption of the terminal can be saved while reducing the data transmission delay.
  • the terminal in the RRC inactive state sends 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, and receives the first base station or the CU of the first base station or the first base station.
  • the RRC release message sent by the base station DU The timing of data packet transmission is advanced, the transmission delay is reduced, the process of returning the terminal to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • 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, the method further includes:
  • the data packet is directly encapsulated into the first MAC protocol data unit (ProtocolDataUnit, PDU) as the first media access control (Media Access Control, MAC) service data unit (Service Data Unit, SDU);
  • PDU protocol data unit
  • MAC media access control
  • SDU Service Data Unit
  • the second MAC SDU generated by performing preprocessing on the data packet is encapsulated into the second MAC PDU.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the terminal when the terminal receives the 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, it will send the random access response message to the terminal.
  • the identity document (ID for short) of the terminal and the uplink data packet are sent on the uplink (Uplink, UL for short) grant (Grant) resource.
  • the terminal If the terminal does not activate Signal Radio Bearer (SRB), Data Radio Bearer (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. And add MAC sub-header information (ie sub-header) to the data packet to form a MAC sub-PDU (ie sub-PDU), and then place it after the MAC sub-PDU containing CCCH (ie RRC recovery request message) or DCCH, and The subheader information of the MAC sub-PDU carrying the CCCH or DCCH includes an indication of whether other MAC PDUs are also included.
  • SRB Signal Radio Bearer
  • DRB Data Radio Bearer
  • the S field of the first sub-header information indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU includes two implementations:
  • the first implementation mode (as shown by the symbol AA in Figure 3a): the subheader information includes a dedicated LCID corresponding to the data packet, and the dedicated LCID is used for the base station (which can be understood as the first base station or the CU of the first base station or the first base station).
  • the DU) of the base station identifies that this is an IP data packet, and the DRB ID information corresponding to the data packet is used for 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.
  • the subheader information contains the DRB ID information corresponding to the data packet, and the base station recognizes that this is an IP data packet according to the DRB ID information, and at the same time learns that the data packet corresponds to Which bearer of the terminal enables the base station to accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the terminal does not activate the SRB, DRB and other configurations at this time, activate the SRB, DRB and other configurations to obtain the second MAC PDU.
  • the data packet is processed according to the normal processing method, including PDCP layer and RLC layer processing, etc., and then the second MAC SDU is generated, and the second MAC SDU and the MAC sub-header together form a MAC sub-PDU, and the MAC sub - The PDU is placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b.
  • the LCID can use the logical channel ID of the normal data, that is, 000001-100000.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • 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.
  • the first MAC SDU corresponds to the terminal that 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.
  • the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to the IP data packet.
  • the second MAC SDU corresponds to the case where the terminal bearer is activated.
  • the second MAC SDU is determined through preprocessing.
  • information such as the data bearer of the data packet can be obtained.
  • the header information only needs to include logical channel identification information, not bearer identification information.
  • an embodiment of the present disclosure provides a schematic flowchart of a data transmission method.
  • the data transmission method provided in this embodiment is used for the first base station or the CU of the first base station or the DU of the first base station.
  • Data transfer methods include:
  • Step 201 Receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state.
  • the terminal sends a preamble 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, PRACH for short) opportunity.
  • the CU of the 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, RA for short) radio network temporary identifier (RNTI) corresponding to the PRACH opportunity for sending the preamble.
  • RNTI radio network temporary identifier
  • 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 by itself, for example, the RAPID is consistent, the terminal sends a data packet and RRC recovery The request message is to the first base station or the CU of the first base station or the DU of the first base station.
  • the preamble sent by the terminal at the PRACH opportunity is received, and the data packet and the RRC recovery request message sent by the terminal at the PUSCH opportunity are received.
  • Step 202 Send an RRC release message to the terminal.
  • the first base station (the first base station is used as an example below, 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 a message to the terminal.
  • RRC release message carrying a suspend indication.
  • the first base station may carry the RRC release message in the MSGB message and send it to the terminal, and the MSGB message may also include a random access response message and RAPID information.
  • the terminal After receiving the RRC release message, the terminal releases the RRC connection, and the terminal enters the RRC inactive state, which can save the power consumption of the terminal.
  • the RRC release message is also used to indicate that the terminal contention conflict is successfully resolved.
  • 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 core network to complete the transmission of the data packet.
  • the first base station or the CU of the first base station or the DU of the first base station receives the data packet and the RRC recovery request message sent by the terminal in the RRC inactive state, and sends the RRC release message to the terminal.
  • the timing of data packet transmission is advanced, the transmission delay is reduced, the process of returning the terminal to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
  • the RRC recovery request message is the RRC connection recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSG A in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • 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
  • the second MAC PDU includes an The second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the terminal when the terminal receives the 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, it will send the random access response message to the terminal.
  • Send the terminal's ID and uplink data packets on the UL Grant resource Specifically, there are the following options:
  • the terminal If the terminal does not activate SRB, DRB and other configurations at this time, the terminal directly encapsulates the IP data packet (that is, the data packet) as the first MAC SDU into the first MAC PDU.
  • the terminal adds MAC sub-header information (ie sub-header) to the data packet to form a MAC sub-PDU (ie sub-PDU), and then places it after the MAC sub-PDU containing CCCH (ie RRC recovery request message) or DCCH, and
  • CCCH ie RRC recovery request message
  • the subheader information of the MAC sub-PDU carrying the CCCH or DCCH includes an indication of whether other MAC PDUs are also included.
  • the specific MAC PDU is shown in Figure 3a:
  • the S field of the first subheader information indicates whether there is a subsequent MAC sub-PDU
  • the subheader of the second MAC sub-PDU includes two implementations:
  • the subheader information contains a dedicated LCID corresponding to the data packet
  • 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
  • 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.
  • the sub-header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet according to the DRB ID information, and at the same time learns which bearer of the terminal the data packet corresponds to, so that the base station can accurately Put the packet on the appropriate GTP-U tunnel and send it to the core network.
  • the terminal does not activate the SRB, DRB and other configurations at this time, activate the SRB, DRB and other configurations to obtain the second MAC PDU.
  • the data packet is processed according to the normal processing method, including PDCP layer and RLC layer processing, etc., and then the second MAC SDU is generated, and the second MAC SDU and the MAC subheader form a MAC sub-PDU, and the MAC sub-PDU is placed in the CCCH carrying the or after the MAC sub-PDU of the DCCH, as shown in Figure 3b.
  • the LCID uses the normal data logical channel ID, ie, 000001-100000.
  • 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 the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • 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.
  • the first MAC SDU corresponds to the terminal that does not activate the SRB, DRB and other configurations, since the data bearer is not activated, the data bearer needs to be indicated in the first MAC SDU.
  • the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to the IP data packet.
  • the second MAC SDU corresponds to the case where the terminal bearer is activated.
  • the second MAC SDU is determined through preprocessing.
  • information such as the data bearer of the data packet can be obtained.
  • the header information includes logical channel identification information, but does not include bearer identification information.
  • the method further includes:
  • the first base station may send the data packet to the core network (corresponding to the case where the anchor base station needs to be switched), or the first base station may send the data packet to the second base station, and the second base station may send the data packet to the core network (Corresponding to the case where the anchor base station does not need to be switched), the descriptions are as follows.
  • the first base station can send the data packet to the second base station together with the UE context retrieval request message. If the anchor base station needs to be switched, the recovered terminal context can be Send processing.
  • the data packet is sent to the core network.
  • the first base station after receiving the data packet and the RRC recovery request message sent by the terminal, the first base station obtains the I-RNTI and MAC-I from the RRC recovery request message, obtains the ID information of the second base station, and sends the information to the second base station. Send a UE context request 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 Core Network.
  • 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.
  • sending the data packet to the core network is specifically:
  • the data packet is obtained from the first MAC PDU or the second MAC PDU sent by the terminal, and the first MAC PDU includes the first MAC SDU directly generated by the data packet.
  • the second MAC PDU includes a second MAC SDU generated by preprocessing the data packet;
  • the data packet is sent to the core network.
  • 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 the PDU session information are obtained.
  • the first base station 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 an appropriate tunnel.
  • the method further includes:
  • the UE context retrieval request message carries the RRC recovery reason indication, the data packet transmission indication, the subsequent data packet indication information, the terminal cache information, the data packets sent by the terminal, the data at least one of the logical channel identification information of the packet and the bearer identification information of the data packet;
  • the second base station determines whether to perform UE context migration based on the information in the UE context request message.
  • the RRC recovery reason indication includes at least one of emergency call, high-priority access, terminal-terminated access, terminal-triggered signaling, terminal-triggered data, terminal-triggered voice call, and terminal-triggered video call.
  • the UE context retrieval request message may include an RRC recovery cause indication, and carry bearer identification information corresponding to the data packet, and the bearer identification information is used by the second base station to obtain the DRB ID corresponding to the data packet, so as to facilitate subsequent retrieval of the data packet.
  • the packet is sent to the core network through a suitable tunnel.
  • the UE context retrieval request message may include an RRC recovery reason indication and/or a data packet sending indication.
  • the first base station After receiving the UE context retrieval failure message, the first base station can send the 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 sends a data packet while sending the UE context retrieval request message to the second base station, the first base station does not need to send the data packet to the second base station again after receiving the UE context retrieval failure message.
  • the data transmission method also includes:
  • 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.
  • the data forwarding information may be Transport Network Layer (TNL) information of the second base station, including Internet Protocol Address (IP) information and User plane of GPRS Tunneling Protocol (GPRS, GPRS for short) GTP-U) tunnel endpoint identifier (Tunnel Endpoint Identifier, referred to as TEID for short) information 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.
  • TNL Transport Network Layer
  • IP Internet Protocol Address
  • GPRS GPRS Tunneling Protocol
  • GTP-U GTP-U tunnel endpoint identifier
  • the data packets sent by the terminal are IP data packets, the first MAC PDU data packets, the first MAC SDU data packets, the second MAC PDU data packets, the second MAC SDU data packets, and the recovered first RLC SDU. and at least one of the recovered second RLC SDUs.
  • the retrieve UE context reply message may carry RLC configuration information and/or transport layer address information.
  • the first base station or the CU of the first base station restores the RLC SDU or the PDCP PDU, and sends the restored data to the first base station or the CU of the first base station, and the first base station or the CU of the first base station restores the terminal to send the data packet, and sends the data packet.
  • the data packets are sent to the core network.
  • an embodiment of the present disclosure provides another schematic flowchart of a data transmission method.
  • the data transmission method provided in this embodiment is used for a second base station, and the data transmission method includes:
  • Step 301 Receive a UE context retrieval request message sent by a first base station or a CU of the first base station;
  • Step 302 Send a UE context retrieval failure message to the first base station or the CU of the first base station;
  • Step 303 Send the data packet to the core network.
  • the UE context retrieval request message carries the RRC recovery reason indication, the data packet transmission indication, the subsequent data packet indication information, the terminal buffer information, the data packet sent by the terminal, the logical channel identification information of the data packet, and the bearer identification of the data packet. at least one of the information.
  • the second base station determines whether to perform UE context migration based on the information in the UE context request message.
  • the UE context retrieval request message may include an RRC recovery cause indication, and carry bearer identification information corresponding to the data packet, and the bearer identification information is used by the second base station to obtain the DRB ID corresponding to the data packet, so as to facilitate subsequent retrieval of the data packet.
  • the packet is sent to the core network through a suitable tunnel.
  • the UE context retrieval request message may include an RRC recovery reason indication and/or a data packet sending indication.
  • the second base station may learn that the reason for the RRC recovery is data packet transmission, IP data packets, and DRB ID information according to the UE context retrieval request message.
  • IP data packets and DRB ID information can be obtained in the following two ways:
  • the first way obtain DRB ID or PDU session ID information from the retrieve UE context request message, and obtain IP data packets from the data plane between the second base station and the first base station.
  • the second way 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.
  • the second base station can obtain the data packet sent by the terminal according to the retrieve UE context 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 retrieve UE context 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.
  • the UE context retrieval failure message can carry the TNL layer information of the second base station, including IP address information and GTP-U TEID information, and can also use the data forwarding information to inform the TNL layer information of the second base station, the TNL layer of the second base station.
  • the information is used by the access base station to forward the data packet to the second base station.
  • the UE context retrieval failure message may carry RLC configuration information and/or transport layer address information.
  • the first base station or the CU of the first base station restores the RLC SDU or the PDCP PDU, and sends the restored data to the first base station or the CU of the first base station, and the first base station or the CU of the first base station restores the terminal to send the data packet, and sends the data packet.
  • the data packets are sent to the core network.
  • the first base station also receives the RLC configuration information and/or the transport layer address information sent by the second base station after receiving the UE context retrieval reply message.
  • the first base station or the CU of the first base station restores the RLC SDU or the PDCP PDU, and sends the restored data to the first base station or the CU of the first base station, and the first base station or the CU of the first base station restores the terminal to send the data packet, and sends the data packet.
  • the data packets are sent to the core network.
  • the second base station after the second base station sends the UE context retrieving failure message 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, in the scenario where the anchor base station is not switched
  • the data packet is sent to the core network, which improves the transmission efficiency of the data packet and reduces the transmission delay of the data packet.
  • the UE context retrieval failure message carries data forwarding information
  • the data transmission method further includes:
  • the data forwarding information can be carried in the UE context retrieval failure message, and the data forwarding information can be the TNL layer information of the second base station, including IP address information and GTP-U TEID information, and is used to determine the second base station according to the data forwarding information.
  • 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.
  • 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 the address indication message, and the second base station sends the address indication message to the first base station or the first base station. CU, and 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.
  • 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;
  • an embodiment of the present disclosure provides another schematic flowchart of a data transmission method.
  • the data transmission method provided in this embodiment is used in the distribution unit DU of the first base station, and the data transmission method includes:
  • Step 401 Receive a data packet and an RRC recovery request message sent by a terminal in an RRC inactive state.
  • receiving the preamble sent by the terminal at the PRACH opportunity after detecting the preamble, sends a random access response message to the terminal, using the RA-RNTI corresponding to the PRACH opportunity for sending the preamble to scramble;
  • the preamble sent by the terminal at the PRACH opportunity is received, and the data packet and the RRC recovery request message sent by the terminal at the PUSCH opportunity are received.
  • Step 402 Send the data packet and the RRC recovery request message to the centralized unit CU of the first base station.
  • Step 403 Receive the RRC release message sent by the CU of the first base station
  • the CU of the first base station sends an RRC release message to the terminal, which carries a suspension indication.
  • the CU of the first base station may carry the RRC release message in the MSGB message.
  • Step 404 Send the RRC release message to the terminal.
  • 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 the terminal enters the RRC inactive state, which can save the power consumption of the terminal.
  • the RRC release message is also used to indicate the terminal.
  • the DU of the first base station receives the data packet and the RRC recovery request message sent by the terminal in the RRC inactive state; sends the data packet and the RRC recovery request message to the centralized unit CU of the first base station; receives the first The RRC release message sent by the CU of a base station; the RRC release message is sent to the terminal.
  • the timing of data packet transmission is advanced, the transmission delay is reduced, the process of returning the terminal to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • 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
  • the second MAC PDU includes an The second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the sub-header information of the first MAC SDU includes the logical channel identification information as a logical channel identification dedicated to the IP data packet.
  • the centralized unit CU that sends the data packet and the RRC recovery request message to the first base station includes:
  • the packet is sent to the CU through an initial RRC transfer message or through the user plane interface between the CU and the DU.
  • sending the data packet to the CU through the user plane interface between the CU and the DU includes:
  • the data packet is sent to the CU according to the transport network layer information.
  • 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.
  • the DU may send a UE context establishment reply message and a data packet to the CU.
  • the data transmission method further includes: receiving BSR information sent by the terminal, and sending the BSR information to the CU of the first base station.
  • 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.
  • buffer status report Buffer Status Report, BSR for short
  • 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
  • the core network can be the access and mobility management functions (Access and Mobility Management Functions). Mobility Management Function, AMF for short) network element or User Plane Function (UPF for short) network element.
  • AMF Access and Mobility Management Function
  • UPF User Plane Function
  • scenario 1 data packets are sent based on the four-step RACH, and the anchor base station does not switch.
  • step 10 the terminal is in the RRC inactive state (ie, the RRC_inactive state);
  • Step 11 The terminal has uplink small packet data to transmit, and sends a preamble to the base station at the PRACH opportunity.
  • Step 12 The base station detects the preamble, and sends a random access response to the terminal, which mainly includes information such as TA, UL grant, and RAPID, and uses the PRACH opportunity for sending the preamble to correspond to RA-RNTI scrambling.
  • 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's ID and uplink data packets on the UL Grant resource. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations. In this way, the data packet is processed according to the normal processing method, including PDCP layer and RLC layer processing, etc., to generate a MAC SDU, and combine the SDU with the The MAC sub-header forms the MAC sub-PDU together, and then is placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b. In this way, since the bearer is activated, the LCID uses the normal data logical channel ID That is, 000001-100000 is used.
  • Step 14 After receiving the data packet and the connection recovery request message sent by the terminal, the access base station (that is, the target base station) learns the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends it to the anchor point.
  • the point base station sends a terminal context acquisition request message (that is, a UE context retrieval request message), and the content of the message is as follows:
  • Case 1 The access base station sends the RRC recovery reason in the terminal context acquisition request message as data packet transmission, and carries the DRB ID corresponding to the data packet, so that the anchor base station can learn the DRB ID corresponding to the data packet, so that the The packets are sent to the core network through a suitable tunnel.
  • Case 2 The access base station sends the RRC recovery reason in the terminal context acquisition request message as data packet transmission, and/or sends the MAC sub-PDU information to the anchor base station.
  • Step 15 The anchor base station learns that the reason for the connection recovery request (that is, the RRC recovery reason) is data packet transmission, obtains IP data packets, and DRB ID information, and sends a terminal context acquisition failure message to the access base station (that is, a UE context retrieval failure message). ), the message can carry the TNL layer information of the anchor base station, including IP address information and GTP-U TEID information, or in the subsequent use step 15', send TNL indication information to inform the access base station of the TNL information of the anchor base station, use The data is transferred from the access base station to the anchor base station.
  • the reason for the connection recovery request that is, the RRC recovery reason
  • the message can carry the TNL layer information of the anchor base station, including IP address information and GTP-U TEID information, or in the subsequent use step 15', send TNL indication information to inform the access base station of the TNL information of the anchor base station, use
  • the data is transferred from the access base station to the anchor base station.
  • 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.
  • Case 2 The DRB or PDU session ID information corresponding to the LCID is obtained by parsing the MAC PDU sent by the access base station, and the data packet is obtained by parsing, and the data packet is sent to the core network.
  • Step 16 The access base station sends an RRC release message to the terminal, which carries 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.
  • scenario 2 data packets are sent based on the four-step RACH, and the anchor base station is switched.
  • Step 20 The terminal is in the RRC_inactive state.
  • Step 21 The terminal has uplink small packet data to transmit, and sends a preamble to the base station at the PRACH opportunity.
  • Step 22 The base station detects the preamble, and sends a random access response to the terminal, which mainly includes information such as TA, UL grant, and RAPID, and uses the PRACH opportunity for sending the preamble to correspond to RA-RNTI scrambling.
  • 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's ID and uplink data packets in the UL Grant resource provider. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in a suitable GTP-U tunnel (ie, tunnel) and send it to the core network.
  • a suitable GTP-U tunnel ie, tunnel
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The headers together form the MAC sub-PDU, and are then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b, where the LCID uses the normal data logical channel ID, which is 000001-100000.
  • Step 24 After receiving the data packet and the connection restoration request message sent by the terminal, the access base station learns the I-RNTI and MAC-I from the connection restoration message, obtains the ID information of the anchor base station, and sends the terminal context to the anchor base station. Get request message.
  • 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 packets from the MAC sub-PDU, or parse the data packets corresponding to the LCID from the MAC PDU, and obtain the DRB information and PDU session information.
  • Step 26 the access base station sends a path switching request to the core network
  • Step 27 Receive a reply to the path switching request sent by the core network.
  • Step 28 The access base station sends the data packet to the core network through an appropriate tunnel.
  • Step 29 The access base station sends a terminal context release message to the anchor base station.
  • scenario 3 two-step RACH sends data packets and the anchor base station does not switch.
  • Step 30 The terminal is in the RRC_inactive state.
  • Step 31 The terminal has uplink small packet data to transmit, sends a preamble to the base station at the PRACH opportunity, and sends an RRC recovery request and a data packet at the PUSCH opportunity. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The headers together form a MAC sub-PDU, which is then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b.
  • the LCID in the figure uses the normal data logical channel ID, that is, 000001-100000.
  • Step 32 The access base station detects the preamble and successfully demodulates the MAC PDU information carried by the PUSCH.
  • the access base station After receiving the data packet and the connection recovery request message (that is, the RRC recovery request message) sent by the terminal, the access base station learns the I-RNTI and MAC-I from the connection recovery message, obtains the ID information of the anchor base station, and sends it to the anchor point.
  • the base station sends a terminal context acquisition request message, which carries the following contents:
  • Case 1 The access base station sends the RRC recovery reason in the terminal context acquisition request message as data packet transmission, and carries the DRB ID corresponding to the data packet, so that the anchor base station can learn the DRB ID corresponding to the data packet, so that the The packets are sent to the core network through a suitable tunnel.
  • Case 2 The access base station sends the RRC recovery reason in the terminal context acquisition request message as data packet transmission, and/or sends the MAC sub-PDU information to the anchor base station.
  • Step 33 The anchor base station learns that the reason for the connection recovery request is data packet transmission, obtains IP data packets, and DRB ID 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
  • the address information and GTP-U TEID information can also be used in the subsequent step 33' to send TNL indication information to inform the access base station of the TNL information of the anchor base station, which is used for the access base station to transfer data to the anchor base station.
  • How to obtain IP data packets and DRB information specifically includes: obtaining the DRB ID or PDU session ID information from the terminal context acquisition request message, obtaining the data packet from the data plane between the anchor base station and the access base station, and sending the data packet to the core network.
  • the DRB or PDU session ID information corresponding to the LCID is obtained by parsing the MAC PDU sent by the access base station, and the data packet is obtained by parsing, and the data packet is sent to the core network.
  • Step 34 The access base station sends an MSGB message to the terminal, which may include successful random access response information, RRC release information, and RAPID information.
  • the terminal receives the corresponding information of successful random access and the terminal identifier and RAPID correspond to itself, it considers that the data transmission is successful, otherwise, it continues to try random access.
  • Figure 7d shows scenario 4: data packets are sent based on the two-step RACH, and the anchor base station is switched.
  • Step 40 The terminal is in the RRC_inactive state.
  • Step 41 The terminal has uplink small packet data to transmit, sends a preamble to the base station at the PRACH opportunity, and sends an RRC recovery request and a data packet at the PUSCH opportunity. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The headers together form the MAC sub-PDU, and are then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b, where the LCID uses the normal data logical channel ID, which is 000001-100000.
  • Step 42 After receiving the data packet and the connection restoration request message sent by the terminal, the access base station learns the I-RNTI and MAC-I from the connection restoration message, obtains the ID information of the anchor base station, and sends the terminal context to the anchor base station. Get request message.
  • 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 data packets from the MAC sub-PDU, or parse the data packets corresponding to the LCID from the MAC PDU, and obtain the DRB information and PDU session information.
  • Step 44 the access base station sends a path switching request to the core network
  • Step 45 Receive the path switching request reply sent by the core network.
  • Step 46 The access base station sends the data packet to the core network through an appropriate tunnel.
  • Step 47 The access base station sends an MSGB message to the terminal, which may include successful random access response information, RRC release message, and RAPID information.
  • the terminal receives the corresponding information of successful random access and the terminal identifier and RAPID correspond to itself, it considers that the data transmission is successful, otherwise, it continues to try random access.
  • Figure 7e shows the example of the four-step RACH sending data packets without changing the anchor base station as an example. The steps are described, and the process is also applicable to the scenario of four-step RACH replacement of anchor base stations, the scenario of two-step RACH replacement of anchor base stations, and the scenario of two-step RACH without anchor base station replacement.
  • the CU-DU architecture sends data packets based on four-step RACH, and the anchor base station switches scenarios.
  • Step 50 The terminal is in an RRC inactive state.
  • Step 51 The terminal has uplink small packet data to transmit, and sends a preamble to the DU at the PRACH opportunity.
  • Step 52 The DU detects the preamble, sends a random access response to the terminal, mainly including information such as TA, UL grant, RAPID, etc., and uses the PRACH opportunity for sending the preamble to correspond to RA-RNTI scrambling.
  • 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's ID and uplink data packets in the UL Grant resource provider. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The headers together form the MAC sub-PDU, and are then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b, where the LCID uses the normal data logical channel ID, which is 000001-100000.
  • Step 54 After receiving the data packet and the connection restoration request message sent by the terminal, the access base station DU sends the above connection restoration request message to the CU, optionally, the data packet is sent to the CU, and the CU will restore the connection from the connection.
  • the recovery message learns the I-RNTI and MAC-I, and obtains the ID information of the anchor base station.
  • Step 55 The CU sends a terminal context acquisition request message to the anchor base station.
  • Step 56 The CU receives 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 packets from the MAC sub-PDU, or parse the data packets corresponding to the LCID from the MAC PDU, and obtain the DRB information and PDU session information.
  • Step 57 The access base station CU sends a UE context establishment request to the DU, which carries the address information of the transport network layer.
  • Step 58 The DU sends a UE context establishment reply message to the CU.
  • Step 58' Optionally, the DU sends the data packet to the CU according to the transport network layer address information.
  • Step 59 the CU sends a path switching request to the core network
  • Step 59' the CU sends an RRC release message to the DU;
  • Step 510' The DU sends an RRC release message to the terminal.
  • Step 510 and receive a path switching request reply sent by the core network.
  • Step 511 The CU sends the data packet to the core network through an appropriate tunnel.
  • Step 512 The CU sends a terminal context release message to the anchor base station.
  • the CU-DU architecture sends data packets based on the four-step RACH, and the anchor base station does not switch scenarios.
  • Step 60 The terminal is in an RRC inactive state.
  • Step 61 The terminal has uplink small packet data to transmit, and sends a preamble to the DU at the PRACH opportunity.
  • Step 62 The DU detects the preamble, and sends a random access response to the terminal, which mainly includes information such as TA, UL grant, and RAPID, and uses the PRACH opportunity for sending the preamble to correspond to RA-RNTI scrambling.
  • 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's ID and uplink data packets in the UL Grant resource provider. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The header forms the MAC sub-PDU together, and then is placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b.
  • the LCID can use the logical channel ID of the normal data, that is, use 000001-100000 .
  • Step 64 After receiving the data packet and the connection restoration request message sent by the terminal, the access base station DU sends the above connection restoration request message to the CU, optionally, sends the data packet to the CU, and the CU will restore the connection from the connection.
  • the recovery message learns the I-RNTI and MAC-I, and obtains the ID information of the anchor base station.
  • Step 65 The CU sends a terminal context acquisition request message to the anchor base station.
  • Step 66 the CU receives the terminal context request reply message sent by the anchor base station, and the context request reply message is the terminal context acquisition failure message, and the message can carry the TNL layer information of the anchor base station, including IP address information and GTP-U TEID information,
  • TNL indication information may also 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.
  • Step 67 The CU sends a UE context establishment request to the DU, which carries the address information of the transport network layer.
  • Step 68 The DU sends a UE context establishment reply message to the CU.
  • Step 68' Optionally, the DU sends the data packet to the CU according to the transport network layer address information.
  • Step 69' The CU sends an RRC release message to the DU.
  • Step 610' The DU sends an RRC release message to the terminal.
  • Step 610 The CU sends the data packet to the anchor base station.
  • Step 611 The anchor base station sends the data packet to the core network.
  • Step 612 The CU sends a terminal context release message to the anchor base station.
  • the CU-DU architecture sends data packets based on two-step RACH, and the anchor base station does not switch scenarios.
  • Step 70 The terminal is in the RRC_inactive state.
  • Step 71 The terminal has uplink small packet data to transmit, sends a preamble to the base station at the PRACH occasion, and sends an RRC recovery request and a data packet at the PUSCH occasion. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, which is placed after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send uplink data packets, first activate SRB, DRB and other configurations, process the uplink data packets in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate MAC SDU, and combine the SDU with the MAC subheader
  • the MAC sub-PDU is formed, and then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b, the LCID in the figure uses the logical channel ID of the normal data, that is, 000001-100000.
  • Step 72 After receiving the data packet and the connection restoration request message sent by the terminal, the DU sends the above connection restoration request message to the CU, optionally, the data packet is sent to the CU, and the CU will learn from the connection restoration message.
  • I-RNTI and MAC-I get the ID information of the anchor base station.
  • the CU sends a terminal context acquisition request message to the anchor base station.
  • Step 73 The CU receives the terminal context request reply message sent by the anchor base station, and the terminal context request reply message is the terminal context acquisition failure message. If the terminal context is successfully restored, obtain the DRB ID information and data packets from the MAC sub-PDU, or parse the data packets corresponding to the LCID from the MAC PDU, and obtain the DRB information and PDU session information.
  • Step 74 The CU sends a UE context establishment request to the DU, carrying the transport network layer address information.
  • Step 75 The DU sends a UE context establishment reply message to the CU.
  • Step 75' Optionally, the DU sends the data packet to the CU according to the transport network layer address information.
  • Step 76' The CU sends an RRC release message to the DU.
  • Step 77' The DU sends an RRC release message to the terminal.
  • Step 76 The CU sends the data packet to the anchor base station.
  • Step 77 The anchor base station sends the data packet to the core network.
  • Step 78 The CU sends a terminal context release message to the anchor base station.
  • the CU-DU architecture is based on two-step RACH sending data packets, and the anchor base station is switched.
  • Step 80 The terminal is in the RRC_inactive state.
  • Step 81 The terminal has uplink small packet data to transmit, sends a preamble to the base station at the PRACH opportunity, and sends an RRC recovery request and a data packet at the PUSCH opportunity. Specifically, there are the following options:
  • Option 1 If the terminal does not activate SRB, DRB and other configurations, the terminal directly encapsulates the IP data packet as a MAC SDU into a MAC PDU and sends it out.
  • the terminal adds the MAC sub-header to the data packet to form a MAC sub-PDU, and puts it after the MAC sub-PDU containing the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains the sub-header.
  • the specific MAC PDUs are shown in Figure 3a:
  • the first sub-header S field indicates whether there is a subsequent MAC sub-PDU
  • the sub-header of the second MAC sub-PDU has the following two situations:
  • the header information (ie 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 the data packet. Which bearer corresponds to the terminal, so that the base station can accurately place the data packet in the appropriate GTP-U tunnel and send it to the core network.
  • the header information contains the DRB ID information corresponding to the data packet.
  • the base station identifies that this is an IP data packet and 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 on the terminal.
  • the appropriate GTP-U tunnel is sent to the core network.
  • Option 2 If the terminal needs to send an uplink data packet, first activate the SRB, DRB and other configurations, process the uplink data packet in the normal processing mode, including PDCP layer and RLC layer processing, etc., generate a MAC SDU, and associate the SDU with the MAC sub- The headers together form the MAC sub-PDU, and are then placed after the MAC sub-PDU carrying the CCCH or DCCH, as shown in Figure 3b, where the LCID uses the normal data logical channel ID, that is, 000001-100000.
  • Step 82 After receiving the data packet and the connection restoration request message sent by the terminal, the DU sends the above connection restoration request message to the CU, optionally, the data packet is sent to the CU, and the CU will learn from the connection restoration message.
  • I-RNTI and MAC-I get the ID information of the anchor base station.
  • the CU sends a terminal context acquisition request message to the anchor base station.
  • Step 83 The CU receives the terminal context request reply message sent by the anchor base station.
  • Step 84 The CU sends a UE context establishment request to the DU, which carries the address information of the transport network layer.
  • Step 85 The DU sends a UE context establishment reply message to the CU.
  • Step 85' Optionally, the DU sends the data packet to the CU according to the transport network layer address information.
  • Step 86 The CU sends a path switching request to the core network.
  • Step 86' The CU sends an RRC release message to the DU.
  • Step 87 Receive a reply to the path switching request sent by the core network.
  • Step 88 The CU sends the data packet to the core network through an appropriate tunnel.
  • Step 89 The CU sends a terminal context release message to the anchor base station.
  • the target base station receives the data packet sent by the random access process of the terminal, and sends the data packet to the core network when the anchor base station switches or does not switch.
  • the target base station and the anchor base station exchange information such as data packets, DRB ID and anchor base station TNL, the target base station sends the data packets to the anchor base station, and the anchor base station sends the data packets to the core network;
  • 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 switching.
  • the above embodiment uses a two-step random access process or a four-step random access process to send small data packets, which can send data packets without restoring the RRC connection and the anchor base station can or cannot be handed over.
  • the transmission of small and medium data packets needs to restore the RRC connection first, and needs to switch the anchor base station, which brings about the disadvantages of large data packet transmission delay and low efficiency.
  • FIG. 8 is a schematic structural diagram of a terminal provided by an embodiment of the present disclosure. As shown in FIG. 8, the terminal 600 is in a radio resource control RRC inactive state, and the terminal 600 includes:
  • the first sending module 601 is used to send the data packet and the 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;
  • the first receiving module 602 is 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.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • an encapsulation template is also included, for directly encapsulating the data packet into the first MAC protocol data unit PDU as the first media access control MAC service data unit SDU;
  • the second MAC SDU generated by performing preprocessing on the data packet is encapsulated into the second MAC PDU.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to the IP data packet.
  • the terminal 600 can implement each process implemented by the terminal in the method embodiment shown in FIG. 1 , and can achieve the same technical effect. To avoid repetition, details are not described here.
  • the terminal 800 includes but is not limited to: a transceiver unit (ie, a transceiver) 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, and a display unit 806 , a user input unit 807 , an interface unit 808 , a memory 809 , a processor 810 , and a power supply 811 and other components.
  • a transceiver unit ie, a transceiver
  • the terminal 800 includes but is not limited to: a transceiver unit 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, and a display unit 806 , a user input unit 807 , an interface unit 808 , a memory 809 , a processor 810 , and a power supply 811 and other components.
  • the terminal structure shown in FIG. 9 does not constitute a limitation on the terminal, and the terminal may include more or less components than the one shown, or combine some components, or
  • the transceiver unit 801 is configured 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; receive the first base station or the first base station The RRC release message sent by the CU of a base station or the DU of the first base station.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • the processor 810 is configured to directly encapsulate the data packet as the first media access control MAC service data unit SDU into the first MAC protocol data unit PDU;
  • the second MAC SDU generated by performing preprocessing on the data packet is encapsulated into the second MAC PDU.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identification dedicated to the IP data packet.
  • the terminal 800 can implement each process implemented by the terminal in the method embodiment shown in FIG. 1 , and can achieve the same technical effect. To avoid repetition, details are not described here.
  • the transceiver unit 801 may be used for receiving and sending signals during sending and receiving of information or during a call. Specifically, after receiving the downlink data from the base station, it is processed by the processor 810; The uplink data is sent to the base station.
  • 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, and the like.
  • the transceiver unit 801 can also communicate with the network and other devices through a wireless communication system.
  • the terminal provides the user with wireless broadband Internet access through the network module 802, such as helping the user to send and receive emails, browse web pages, and access streaming media.
  • the audio output unit 803 may convert audio data received by the transceiving unit 801 or the network module 802 or stored in the memory 809 into audio signals and output as sound. Also, the audio output unit 803 may also provide audio output related to a specific function performed by the terminal 800 (eg, call signal reception sound, message reception sound, etc.).
  • the audio output unit 803 includes a speaker, a buzzer, a receiver, and the like.
  • the input unit 804 is used to receive audio or video signals.
  • the input unit 804 may include a graphics processor (Graphics Processing Unit, GPU for short) 8041 and a microphone 8042, and the graphics processor 8041 is used for still pictures or videos obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. image data for processing.
  • the processed image frames may be displayed on the display unit 806 .
  • the image frames processed by the graphics processor 8041 may be stored in the memory 809 (or other storage medium) or transmitted via the transceiving 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 that can be transmitted to a mobile communication base station via the transceiving unit 801 and output in the case of a telephone conversation mode.
  • the terminal 800 also includes at least one sensor 805, such as a light sensor, a motion sensor, and other sensors.
  • 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 when the terminal 800 is moved to the ear. or backlight.
  • the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary, and can be used to identify the terminal posture (such as horizontal and vertical screen switching, related games,
  • the sensor 805 may also include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared Sensors, etc., will not be repeated here.
  • 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, and the display panel 8061 may be configured in the form of a Liquid Crystal Display (LCD for short), an Organic Light-Emitting Diode (OLED for short).
  • LCD Liquid Crystal Display
  • OLED Organic Light-Emitting Diode
  • the user input unit 807 may be used to receive input numerical or character information, and generate key signal input related to user settings and function control of the terminal.
  • the user input unit 807 includes a touch panel 8071 and other input devices 8072 .
  • the touch panel 8071 also referred to as a touch screen, collects the user's touch operations on or near it (such as the user's finger, stylus, etc., any suitable object or accessory on or near the touch panel 8071). operate).
  • the touch panel 8071 may include two parts, a touch detection device and a touch controller.
  • 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 contact coordinates, and then sends it to the touch controller.
  • the touch panel 8071 can be realized by various types of resistive, capacitive, infrared, and surface acoustic waves.
  • the user input unit 807 may also include other input devices 8072 .
  • other input devices 8072 may include, but are not limited to, physical keyboards, function keys (such as volume control keys, switch keys, etc.), trackballs, mice, and operation sticks, which will not be repeated here.
  • the touch panel 8071 can be covered on the display panel 8061.
  • the touch panel 8071 detects a touch operation on or near it, it transmits it to the processor 810 to determine the type of the touch event, and then the processor 810 determines the type of the touch event according to the touch
  • the type of event provides a corresponding visual output on the display panel 8061.
  • the touch panel 8071 and the display panel 8061 are used as two independent components to realize the input and output functions of the terminal, in some embodiments, the touch panel 8071 and the display panel 8061 can be integrated to form a Realize the input and output functions of the terminal, which is not limited here.
  • the interface unit 808 is an interface for connecting an external device to the terminal 800 .
  • external devices may include wired or wireless headset ports, external power (or battery charger) ports, wired or wireless data ports, memory card ports, ports for connecting devices with identification modules, audio input/output (I/O) ports, video I/O ports, headphone ports, and more.
  • the interface unit 808 may be used to receive input (eg, data information, power, etc.) from an external device and transmit the received input to one or more elements within the terminal 800 or may be used to communicate between the terminal 800 and the external device. transfer data between.
  • the memory 809 may be used to store software programs as well as various data.
  • the memory 809 may mainly include a stored program area and a stored data area, wherein the stored program area may store an operating system, an application program (such as a sound playback function, an image playback function, etc.) required for at least one function, and the like; Data created by the use of the mobile phone (such as audio data, phone book, etc.), etc.
  • memory 809 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.
  • the processor 810 is the control center of the terminal, uses various interfaces and lines to connect various parts of the entire terminal, and executes by running or executing the software programs and/or modules stored in the memory 809, and calling the data stored in the memory 809. Various functions of the terminal and processing data, so as to monitor the terminal as a whole.
  • the processor 810 may include one or more processing units; optionally, 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, etc., and the modem
  • the modulation processor mainly handles wireless communication. It can be understood that, the above-mentioned modulation and demodulation processor may not be integrated into the processor 810.
  • the terminal 800 may also include a power source 811 (such as a battery) for supplying power to various components.
  • a power source 811 such as a battery
  • the power source 811 may be logically connected to the processor 810 through a power management system, so as to manage charging, discharging, and power consumption management through the power management system. and other functions.
  • the terminal 800 includes some unshown functional modules, which are not repeated here.
  • an embodiment of the present disclosure further provides a terminal, including a processor 810 , a memory 809 , a computer program stored in the memory 809 and executable on the processor 810 , when the computer program is executed by the processor 810
  • a terminal including a processor 810 , a memory 809 , a computer program stored in the memory 809 and executable on the processor 810 , when the computer program is executed by the processor 810
  • FIG. 10 is a schematic structural diagram of a network side device provided by an embodiment of the present disclosure.
  • the first network side device 900 is a first base station or a centralized unit CU of the first base station or a first base station
  • the distribution unit DU, the first network side device 900 includes:
  • a second receiving module 901 configured to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;
  • the second sending module 902 is configured to send an RRC release message to the terminal.
  • the RRC recovery request message is the RRC connection recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSG A in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • the data packet is encapsulated in the first media access control MAC protocol data unit PDU or the second MAC PDU, and the first MAC PDU includes the first MAC service data unit SDU directly generated by the data packet, so the second MAC PDU includes a second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • 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 the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the sub-header information of the first MAC SDU includes the logical channel identification information as a logical channel identification dedicated to the IP data packet.
  • the first network-side device 900 further includes: a third sending module, configured to send the recovered data packet to the core network.
  • the first network side device 900 further includes:
  • a fourth sending module configured to send a UE context retrieval request message to the second base station
  • a third receiving module configured to receive a UE context retrieval reply message sent by the second base station
  • the fifth sending module is configured to send the data packet to the core network.
  • 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 according to the successfully recovered terminal context, and the first MAC PDU includes the data packet through the The directly generated first MAC SDU, the second MAC PDU includes the second MAC SDU generated by preprocessing the data packet; sending the data packet to the core network.
  • the first network side device 900 further includes a sixth sending module, configured to send a UE context retrieval request message to the second base station, where the UE context retrieval request message carries an RRC recovery reason indication, a data packet transmission indication, at least one of subsequent data packet indication information, terminal cache information, data packets sent by the terminal, logical channel identification information of the data packets, and bearer identification information of the data packets;
  • a sixth sending module configured to send a UE context retrieval request message to the second base station, where the UE context retrieval request message carries an RRC recovery reason indication, a data packet transmission indication, at least one of subsequent data packet indication information, terminal cache information, data packets sent by the terminal, logical channel identification information of the data packets, and bearer identification information of the data packets;
  • the fourth receiving module is configured to receive the UE context retrieval failure message sent by the second base station.
  • the first network side device 900 further includes:
  • a fifth receiving module configured to receive the data forwarding information carried by the second base station through the address indication message or the UE context retrieval failure message;
  • a seventh sending module configured to forward the data packet sent by the terminal to the second base station.
  • the data packets sent by the terminal are IP data packets, the first MAC PDU data packets, the first MAC SDU data packets, the second MAC PDU data packets, the second MAC SDU data packets, and the recovered first RLC SDU. and at least one of the recovered second RLC SDUs.
  • the RRC recovery reason indication includes at least one of emergency call, high-priority access, terminal-terminated access, terminal-triggered signaling, terminal-triggered data, terminal-triggered voice call, and terminal-triggered video call.
  • 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 FIG. 3 and achieve the same technical effect, in order to avoid repetition , which will not be repeated here.
  • FIG. 11 is a schematic structural diagram of a network side device provided by an embodiment of the present disclosure.
  • the second network side device 1000 includes:
  • a sixth receiving module 1001 configured to receive a request message for retrieving user equipment UE context sent by the first base station or the centralized unit CU of the first base station;
  • An eighth sending module 1002 configured to send a UE context retrieval failure message to the first base station or the CU of the first base station;
  • the ninth sending module 1003 sends the data packet to the core network.
  • the UE context retrieval request message carries the RRC recovery reason indication, the data packet transmission indication, the subsequent data packet indication information, the terminal buffer information, the data packet sent by the terminal, the logical channel identification information of the data packet, and the bearer of the data packet. at least one of the identification information.
  • the second network side device 1000 further includes:
  • a seventh receiving module configured 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.
  • the second network side device 1000 further includes:
  • 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;
  • the eighth receiving module is configured 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.
  • the second network-side device 1000 can implement each process implemented by the second base station in the method embodiment shown in FIG. 4 and achieve the same technical effect, and to avoid repetition, details are not repeated here.
  • FIG. 12 is a schematic structural diagram of a network side device provided by an embodiment of the present disclosure.
  • the third network side device 1100 is a DU of the first base station, and the third network side device 1100 includes:
  • a ninth receiving module 1101, configured to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;
  • An eleventh sending module 1102 configured to send the data packet and the RRC recovery request message to the centralized unit CU of the first base station;
  • a tenth receiving module 1103, configured to receive the RRC release message sent by the CU of the first base station
  • the twelfth sending module 1104 is configured to send the RRC release message to the terminal.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • the data packet is encapsulated in the first media access control MAC protocol data unit PDU or the second MAC PDU, and the first MAC PDU includes the first MAC service data unit SDU directly generated by the data packet, so the second MAC PDU includes a second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the sub-header information of the first MAC SDU includes the logical channel identification information as a logical channel identification dedicated to the IP data packet.
  • the eleventh sending module 1102 further includes:
  • a sending submodule configured 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.
  • a sending sub-module configured to receive a UE context establishment request message that is sent by the CU and carries the transmission network layer information
  • the data packet is sent to the CU according to the transport network layer information.
  • the third network side device 1100 further includes:
  • the eleventh receiving module is configured 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.
  • the third network side device 1100 can implement each process of the DU implementation of the first base station in the method embodiment shown in FIG. 5 and achieve the same technical effect. To avoid repetition, details are not repeated here.
  • FIG. 13 is a schematic structural diagram of a network side device provided by an embodiment of the present disclosure, as shown in FIG.
  • the network-side device is 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 the transceiver 1202 is configured to receive the transmission from the terminal in the RRC inactive state.
  • the data packet and RRC recovery request message ; send RRC release message to the terminal.
  • the RRC recovery request message is the RRC connection recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSG A in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • the data packet is encapsulated in the first media access control MAC protocol data unit PDU or the second MAC PDU, and the first MAC PDU includes the first MAC service data unit SDU directly generated by the data packet, so the second MAC PDU includes a second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • 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 the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the sub-header information of the first MAC SDU includes the logical channel identification information as a logical channel identification dedicated to the IP data packet.
  • transceiver 1202 is further configured to send the recovered data packet to the core network.
  • the transceiver 1202 is further configured to send a UE context retrieval request message to the second base station;
  • the data packet is sent to the core network.
  • the transceiver 1202 is further configured to obtain the data packet from the first MAC PDU or the second MAC PDU sent by the terminal according to the successfully recovered terminal context, where the first MAC PDU includes the data packet passed through the The directly generated first MAC SDU, the second MAC SDU includes the second MAC SDU generated by preprocessing the data packet;
  • the data packet is sent to the core network.
  • the transceiver 1202 is further configured to send a UE context retrieval request message to the second base station, where the UE context retrieval request message carries the RRC recovery reason indication, the data packet transmission indication, the subsequent data packet indication information, and the terminal buffer information. , at least one of the data packet sent by the terminal, the logical channel identification information of the data packet, and the bearer identification information of the data packet;
  • the transceiver 1202 is further configured to receive the data forwarding information carried by the second base station through the address indication message or the UE context retrieval failure message;
  • the data packets sent by the terminal are IP data packets, the first MAC PDU data packets, the first MAC SDU data packets, the second MAC PDU data packets, the second MAC SDU data packets, and the recovered first RLC SDU. and at least one of the recovered second RLC SDUs.
  • the RRC recovery reason indication includes at least one of emergency call, high-priority access, terminal-terminated access, terminal-triggered signaling, terminal-triggered data, terminal-triggered voice call, and terminal-triggered video call.
  • the device in this embodiment 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 embodiment shown in FIG. 3 to achieve the same technical effect, which is not described here. Repeat.
  • the network-side device is the second base station
  • the transceiver 1202 is configured to receive a request message for retrieving the user equipment UE context sent by the first base station or the centralized unit CU of the first base station; Or the CU of the first base station sends a UE context retrieval failure message; and sends the data packet to the core network.
  • the UE context retrieval request message carries the RRC recovery reason indication, the data packet transmission indication, the subsequent data packet indication information, the terminal buffer information, the data packet sent by the terminal, the logical channel identification information of the data packet, and the bearer of the data packet. at least one of the identification information.
  • the transceiver 1202 is further configured 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.
  • the transceiver 1202 is further configured to send an address indication message carrying data forwarding information to the first base station or the CU of the first base station; the data packet.
  • the device in this embodiment can implement each process implemented by the second base station in the embodiment shown in FIG. 4 to achieve the same technical effect, which is not repeated here.
  • the network side device is a DU of the first base station
  • the transceiver 1202 is configured to receive a data packet and an RRC recovery request message sent by a terminal in a radio resource control RRC inactive state;
  • the packet and the RRC recovery request message are sent to the centralized unit CU of the first base station;
  • the RRC release message sent by the CU of the first base station is received; and
  • the RRC release message is sent to the terminal.
  • the RRC recovery request message is the RRC recovery request message in the four-step random access procedure, or the RRC recovery request message carried by the MSGA in the two-step random access procedure.
  • the data packet is multiplexed or concatenated with the RRC recovery request message.
  • the data packet is encapsulated in the first media access control MAC protocol data unit PDU or the second MAC PDU, and the first MAC PDU includes the first MAC service data unit SDU directly generated by the data packet, so the second MAC PDU includes a second MAC SDU generated by preprocessing the data packet.
  • the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of signaling bearers and data bearers.
  • the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information, and the logical channel identification information is used to indicate the logical channel type of the data packet, and the bearer identification information.
  • the information is used to indicate the data bearer corresponding to the data packet;
  • the subheader information of the second MAC SDU includes logical channel identification information.
  • the sub-header information of the first MAC SDU includes the logical channel identification information as a logical channel identification dedicated to the IP data packet.
  • the transceiver 1202 is further configured 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.
  • the transceiver 1202 is further configured 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.
  • the transceiver 1202 is further configured 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.
  • the device in this embodiment can implement each process of the DU implementation of the first base station in the embodiment shown in FIG. 5 to achieve the same technical effect, which is not repeated here.
  • bus 1201 which may include any number of interconnected buses and bridges
  • bus 1201 will include one or more processors represented by processor 1205 and memory represented by memory 1206
  • the various circuits are linked together.
  • the bus 1201 may also link together various other circuits, such as peripherals, voltage regulators, and power management circuits, etc., which are well known in the art and, therefore, will not be described further herein.
  • Bus interface 1204 provides an interface between bus 1201 and transceiver 1202 .
  • Transceiver 1202 may be a single element or multiple elements, such as multiple receivers and transmitters, providing a means for communicating with various other devices over a transmission medium.
  • the data processed by the processor 1205 is transmitted on the wireless medium through the antenna 1203 , and further, the antenna 1203 also receives the data and transmits the data to the processor 1205 .
  • the processor 1205 is responsible for managing the bus 1201 and general processing, and may also provide various functions including timing, peripheral interface, voltage regulation, power management, and other control functions. And memory 1206 may be used to store data used by processor 1205 in performing operations.
  • the processor 1205 may be a CPU, ASIC, FPGA or CPLD.
  • an embodiment of the present disclosure further provides a network-side device, including a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and running on the processor 1205, the computer program being executed by the processor 1205
  • a network-side device including a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and running on the processor 1205, the computer program being executed by the processor 1205
  • a network-side device including a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and running on the processor 1205, the computer program being executed by the processor 1205
  • a network-side device including a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and running on the processor 1205, the computer program being executed by the processor 1205
  • Embodiments of the present disclosure further provide a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps in the data transmission method shown in FIG. 1 are implemented, Alternatively, when the computer program is executed by the processor, the steps in the data transmission method shown in FIG. 3 are implemented, or, when the computer program is executed by the processor, the data transmission method shown in FIG. 4 is implemented or, when the computer program is executed by the processor, the steps in the data transmission method shown in FIG. 5 are implemented.
  • the computer-readable storage medium such as ROM, RAM, magnetic disk or optical disk, etc.
  • modules, units, sub-modules, sub-units, etc. can be implemented in one or more Application Specific Integrated Circuits (ASIC), Digital Signal Processing (DSP), digital signal processing equipment ( DSP Device, DSPD), Programmable Logic Device (Programmable Logic Device, PLD), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA), general-purpose processor, controller, microcontroller, microprocessor, for in other electronic units or combinations thereof that perform the functions described in this disclosure.
  • ASIC Application Specific Integrated Circuits
  • DSP Digital Signal Processing
  • DSP Device digital signal processing equipment
  • PLD Programmable Logic Device
  • Field-Programmable Gate Array Field-Programmable Gate Array
  • FPGA Field-Programmable Gate Array
  • the method of the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is better implementation.
  • the technical solutions of the present disclosure can be embodied in the form of software products in essence or the parts that make contributions to related technologies.
  • the computer software products are stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) ), including several instructions to enable a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in the various embodiments of the present disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

提供了一种数据传输方法、终端及网络侧设备，其中，数据传输方法包括：处于RRC非激活状态的终端发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU（101），接收第一基站或第一基站的CU或第一基站DU发送的RRC释放消息（102）。

Description

数据传输方法、终端及网络侧设备
相关申请的交叉引用
本公开主张在2020年7月31日在中国提交的中国专利申请号No.202010757105.7的优先权，其全部内容通过引用包含于此。
技术领域
本公开涉及通信技术领域，尤其涉及一种数据传输方法、终端及网络侧设备。
背景技术
目前，终端的状态除了无线资源控制(Radio Resource Control，简称RRC)空闲态和RRC连接态以外，还包括RRC非激活状态(RRC_inactive)，RRC非激活状态可以在尽可能节省资源和节能的情况下，快速地让用户设备(User Equipment，简称UE)进入RRC连接态并且完成协议数据单元(Protocol Data Unit，简称PDU)会话的建立，满足超可靠低时延场景的诉求。
但是，处于RRC非激活状态的终端若要发送数据，则必须先进行连接恢复，进入RRC连接态才能发送数据，在小包传输的场景下，这种方式将会加大传输时延。
发明内容
本公开实施例提供一种数据传输方法、终端及网络侧设备，以解决相关技术的传输方式传输时延较大的问题。
第一方面，本公开实施例提供一种数据传输方法，用于处于无线资源控制RRC非激活状态的终端，所述数据传输方法包括：
发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU；
接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
第二方面，本公开实施例提供一种数据传输方法，用于第一基站或第一基站的集中单元CU或第一基站的分布单元DU，所述数据传输方法包括：
接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
发送RRC释放消息给终端。
第三方面，本公开实施例提供一种数据传输方法，用于第二基站，所述数据传输方法包括：
接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；
向第一基站或第一基站的CU发送取回UE上下文失败消息；
发送所述数据包到核心网。
第四方面，本公开实施例提供一种数据传输方法，应用于第一基站的分布单元DU，所述数据传输方法包括：
接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；
接收第一基站的CU发送的RRC释放消息；
将所述RRC释放消息发送给终端。
第五方面，本公开实施例提供一种终端，所述终端处于无线资源控制RRC非激活状态，包括：
发送模块，用于发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU；
接收模块，用于接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
第六方面，本公开实施例提供一种终端，所述终端处于无线资源控制RRC非激活状态，包括处理器和收发机；
所述收发机，用于发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU，以及接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
第七方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，包括：
接收模块，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
发送模块，用于发送RRC释放消息给终端。
第八方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，包括处理器和收发机；
所述收发机，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息，以及发送RRC释放消息给终端。
第九方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第二基站，包括：
第一接收模块，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；
第一发送模块，用于向第一基站或第一基站的CU发送取回UE上下文失败消息；
第二发送模块，用于发送所述数据包到核心网。
第十方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第二基站，包括处理器和收发机；
所述收发机，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息，向第一基站或第一基站的CU发送取回UE上下文失败消息，以及发送所述数据包到核心网。
第十一方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第一基站的DU，包括：
第一接收模块，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
第一发送模块，用于将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；
第二接收模块，用于接收第一基站的CU发送的RRC释放消息；
第二发送模块，用于将所述RRC释放消息发送给终端。
第十二方面，本公开实施例提供一种网络侧设备，所述网络侧设备为第一基站的DU，包括处理器和收发机；
所述收发机，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；接收第一基站的CU发送的RRC释放消息；以及将所述RRC释放消息发送给终端。
第十三方面，本公开实施例提供一种终端，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的数据传输方法中的步骤。
第十四方面，本公开实施例提供一种网络侧设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第二方面所述的数据传输方法中的步骤，或者所述计算机程序被所述处理器执行时实现如第三方面所述的数据传输方法中的步骤，或者所述计算机程序被所述处理器执行时实现如第四方面所述的数据传输方法中的步骤。
第十五方面，本公开实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求第一方面所述的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如第二方面所述的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如第三方面所述的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如第四方面所述的数据传输方法中的步骤。
本公开实施例中，处于RRC非激活状态的终端发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU，接收第一基站或第一基站的CU或第一基站DU发送的RRC释放消息。将数据包传输的时机提前，降低了传输时延，且能够加快终端重新回到RRC非激活状态的进程，节约了终端的功耗。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对本公开实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种数据传输方法的流程图之一；
图2是相关技术中终端与目标基站之间的数据传输的流程示意图；
图3a、图3b是本公开实施例提供MAC PDU的字段构成示意图；
图4是本公开实施例提供的一种数据传输方法的流程图之二；
图5是本公开实施例提供的一种数据传输方法的流程图之三；
图6是本公开实施例提供的一种数据传输方法的流程图之四；
图7a-7h是本公开实施例提供的在各场景下的数据传输方法的流程图；
图8、图9是本公开实施例提供的终端的结构图；
图10-图13是本公开实施例提供的网络侧设备的结构图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
参见图1，图1是本公开实施例提供的一种数据传输方法的流程图，用于处于无线资源控制RRC非激活状态的终端，如图1所示，所述数据传输方法包括以下步骤：
步骤101、发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元(Centralized Unit，简称CU)或第一基站的分布单元(Distributed Unit，简称DU)。
本公开具体实施例中，该数据包可为各种应用的应用数据，例如即时通信软件的数据包，邮件等应用的心跳包，智能穿戴设备和传感器的数据包等等。数据包和RRC恢复请求消息可在同一次数据发送中被发送到第一基站或 第一基站的CU或第一基站的DU。
对于四步随机接入流程，终端在物理随机接入信道(PhysicalRandom Access Channel，简称PRACH)时机向第一基站或第一基站的CU或第一基站的DU发送前导码，第一基站或第一基站的CU或第一基站的DU在检测出前导码后，向终端发送随机接入响应消息，使用发送前导码的PRACH时机对应的随机接入(Random Access，简称RA)无线网络临时标识(RNTI Radio Network Tempory Identity，简称RNTI)加扰；
终端接收第一基站或第一基站的CU或第一基站的DU发送的随机接入响应消息，若确定该随机接入响应消息是发送给终端的，例如RAPID(随机访问前置标识符，Random Access preamble identifier)一致，则终端发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU。
对于两步随机接入流程，在步骤101包括：终端在PRACH时机向第一基站或第一基站的CU或第一基站的DU发送前导码，并在物理上行共享信道(Physical Uplink Shared Channel，简称PUSCH)发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU。
步骤102、接收第一基站或第一基站的CU或第一基站DU发送的RRC释放消息。
终端在接收到RRC释放消息后，释放RRC连接，终端进入RRC非激活状态，可节省终端的功耗。
四步接入流程相关技术中，若处于RRC非激活状态的终端要发送数据包括，需要如图2所示的几个步骤，图2中，目标基站为第一基站或第一基站的CU或第一基站DU：
步骤111、终端向目标基站发送前导码；
步骤112、终端接收目标基站的随机接入响应消息；
步骤113、终端向目标基站发送RRC恢复请求消息；
步骤114、终端接收目标基站发送的RRC恢复消息；
步骤115、终端向目标基站发送RRC恢复完成消息；
步骤116、终端向目标基站发送数据包。
相比于图2所示的终端传输数据包的过程，本公开具体实施例的数据传 输方法并不需要在RRC恢复完成之后才开始传输数据包，而是在接收到随机接入响应消息之后便可传输数据包，也就是说将数据包传输的时机提前，降低了传输时延。同时，相比相关技术，本公开具体实施例能够加快终端重新回到RRC非激活状态的进程，节约了终端的功耗。
同样的，对于两步随机接入流程来说，也能够在降低数据传输延的同时，节约终端的功耗。
本实施例中，处于RRC非激活状态的终端发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU，接收第一基站或第一基站的CU或第一基站DU发送的RRC释放消息。将数据包传输的时机提前，降低了传输时延，且能够加快终端重新回到RRC非激活状态的进程，节约了终端的功耗。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，在步骤101、发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU之前，还包括：
将所述数据包直接作为第一媒体访问控制(Media Access Control，MAC)服务数据单元(Service Data Unit，SDU)封装到第一MAC协议数据单元(ProtocolDataUnit，PDU)；
或
将利用所述数据包进行前置处理生成的第二MAC SDU封装到第二MAC PDU。
也就是说，所述数据包封装于第一MAC PDU或第二MAC PDU。其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理中的至少一项。
具体的，终端在收到第一基站或第一基站的CU或第一基站的DU发送的随机接入响应消息，若确定该随机接入响应消息是发送给终端的，例如RAPID一致，则将在上行(Uplink，简称UL)授权(Grant)资源上发送终端的标识(Identity Document，简称ID)，以及上行的数据包。
若此时终端没有激活信令无线承载(Signal Radio Bearer，简称SRB)、数据无线承载(Data Radio Bearer，简称DRB)等配置，终端直接将IP数据包(即数据包)作为第一MAC SDU封装成第一MAC PDU。并在数据包中添加MAC子头信息(即sub-header)，形成MAC子PDU(即sub-PDU)，然后放在包含CCCH(即RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的子头信息中包含是否还包含其它MAC PDU的指示，具体MAC PDU如图3a所示：
其中，第一个子头信息(sub-header)的S域表示后续是否还有MAC sub-PDU，第二个MAC sub-PDU的sub-header包括两种实现方式：
第一种实现方式(如图3a中标号AA所示)：子头信息中包含对应于数据包的专用LCID，专用LCID用于基站(可理解为第一基站或第一基站的CU或第一基站的DU)识别这是一个IP数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel，然后发给核心网。
第二种实现方式(如图3a中标号BB所示)：子头信息中包含数据包对应的DRB ID信息，基站根据DRB ID信息识别这是一个IP的数据包，同时获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel然后发给核心网。
若此时终端没有激活SRB，DRB等配置，则激活SRB，DRB等配置，获得第二MAC PDU。这种方式下，数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，然后生成第二MAC SDU，将第二MAC SDU与MAC sub-header一起形成MAC sub-PDU，将该MAC sub-PDU放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示。这种方式下，由于承载激活，所以LCID使用正常的数据的逻辑信道ID即可，即使用000001-100000。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
其中，第一MAC SDU包括逻辑信道标识信息和承载标识信息中的至少一个。进一步的，第一MAC SDU至少包括承载标识信息。第一MAC SDU对应终端在没有激活SRB，DRB等配置的情况，由于数据承载未激活，需要在第一MAC SDU中指示数据承载。进一步的，所述第一MAC SDU的子头信息中包括的逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
第二MAC SDU对应终端承载激活的情况，通过前置处理确定第二MAC SDU，后续对第二MAC PDU进行解封装时，可获取数据包的数据承载等信息，所述第二MAC SDU的子头信息中只需要包括逻辑信道标识信息，不用包括承载标识信息。
如图4所示，本公开实施例提供一种数据传输方法的一流程示意图，本实施例提供的数据传输方法，用于第一基站或第一基站的CU或第一基站的DU，所述数据传输方法包括：
步骤201、接收处于RRC非激活状态的终端发送的数据包和RRC恢复请求消息。
对于四步随机接入流程，终端在物理随机接入信道(PhysicalRandom Access Channel，简称PRACH)时机向第一基站或第一基站的CU或第一基站的DU发送前导码，第一基站或第一基站的CU或第一基站的DU在检测出前导码后，向终端发送随机接入响应消息，使用发送前导码的PRACH时机对应的随机接入(Random Access，简称RA)无线网络临时标识(RNTI Radio Network Tempory Identity，简称RNTI)加扰。
第一基站或第一基站的CU或第一基站的DU向终端发送随机接入响应消息，若终端确定该随机接入响应消息是发送自己的，例如RAPID一致，则终端发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU。
对于两步随机接入流程，接收终端在PRACH时机发送的前导码，并接收终端在PUSCH时机发送的数据包和RRC恢复请求消息。
步骤202、发送RRC释放消息给终端。
对于四步随机接入流程，第一基站(以下以第一基站进行举例说明，应用在第一基站上的方法也可应用在第一基站的CU或第一基站的DU)可直接 向终端发送RRC释放消息，携带挂起指示。
对于两步随机接入流程，第一基站可将RRC释放消息携带在MSG B消息中发送给终端，该MSG B消息还可包括随机接入响应消息、以及RAPID信息。
终端在接收到RRC释放消息后，释放RRC连接，终端进入RRC非激活状态，可节省终端的功耗，RRC释放消息也用于指示终端竞争冲突解决成功。
进一步的，在步骤202之后，第一基站或第一基站的CU或第一基站的DU发送数据包到核心网，完成数据包的传输。
本实施例中，第一基站或第一基站的CU或第一基站的DU接收处于RRC非激活状态的终端发送的数据包和RRC恢复请求消息；发送RRC释放消息给终端。将数据包传输的时机提前，降低了传输时延，且能够加快终端重新回到RRC非激活状态的进程，节约了终端的功耗。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC连接恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一MAC PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理中的至少一项。
具体的，终端在收到第一基站或第一基站的CU或第一基站的DU发送的随机接入响应消息，若确定该随机接入响应消息是发送给终端的，例如RAPID一致，则将在UL Grant资源上发送终端的ID，以及上行的数据包。具体有如下几种方案：
若此时终端没有激活SRB，DRB等配置，终端直接将IP数据包(即数据包)作为第一MAC SDU封装成第一MAC PDU。
终端在数据包中添加MAC子头信息(即sub-header)，形成MAC子PDU(即sub-PDU)，然后放在包含CCCH(即RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的子头信息 中包含是否还包含其它MAC PDU的指示，具体MAC PDU如图3a所示：
其中，第一个子头信息(subheader)的S域表示后续是否还有MAC sub-PDU，第二个MAC sub-PDU的subheader包括两种实现方式：
第一种实现方式：子头信息中包含对应于数据包的专用LCID，专用LCID用于基站(可理解为第一基站或第一基站的CU或第一基站的DU)识别这是一个IP数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel，然后发给核心网。
第二种实现方式：子头信息中包含数据包对应的DRB ID信息，基站根据DRB ID信息识别这是一个IP的数据包，同时获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel然后发给核心网。
若此时终端没有激活SRB，DRB等配置，则激活SRB，DRB等配置，获得第二MAC PDU。将数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，然后生成第二MAC SDU，将第二MAC SDU与MAC subheader一起形成MAC sub-PDU，将该MAC sub-PDU放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示。LCID使用正常的数据的逻辑信道ID，即000001-100000。
进一步的，所述第一MAC PDU包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
其中，第一MAC SDU包括逻辑信道标识信息和承载标识信息中的至少一个。进一步的，第一MAC SDU至少包括承载标识信息。第一MAC SDU对应终端在没有激活SRB，DRB等配置的情况，由于数据承载未激活，需要在第一MAC SDU中指示数据承载。进一步的，所述第一MAC SDU的子头信息中包括的逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
第二MAC SDU对应终端承载激活的情况，通过前置处理确定第二MAC  SDU，后续对第二MAC PDU进行解封装时，可获取数据包的数据承载等信息，所述第二MAC SDU的子头信息中包括逻辑信道标识信息，不用包括承载标识信息。
进一步的，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
发送恢复出的所述数据包到核心网。
本实施例中，可由第一基站将数据包发送到核心网(对应于需要切换锚点基站的情况)，也可由第一基站将数据包发送给第二基站，由第二基站发送给核心网(对应于不需要切换锚点基站的情况)，分别说明如下。
对应于不需要切换锚点基站的情况，此时第一基站可以将数据包与取回UE上下文请求消息一并发送给第二基站，如果需要切换锚点基站，则可以根据恢复出的终端上下文进行发送处理。
也就是说，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
向第二基站发送取回UE上下文请求消息；
接收第二基站发送的取回UE上下文回复消息；
发送所述数据包到核心网。
本实施例中，第一基站在收到终端发送来的数据包和RRC恢复请求消息后，从RRC恢复请求消息获知I-RNTI和MAC-I，得到第二基站的ID信息，向第二基站发送UE上下文请求消息。
若取回UE上下文回复消息为取回UE上下文失败消息，则由第一基站或第一基站的CU或第一基站的DU将数据包发送给第二基站，由第二基站将数据包括发送到核心网。
若取回UE上下文回复消息为取回UE上下文成功消息，则由第一基站或第一基站的CU或第一基站的DU直接将数据包发送到核心网。
具体的，若取回UE上下文回复消息为取回UE上下文成功消息，则发送所述数据包到核心网具体为：
依据成功恢复的终端上下文，从终端发送的第一MAC PDU或第二MAC PDU中获取所述数据包，所述第一MAC PDU中包括通过所述数据包直接生 成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU；
发送所述数据包到核心网。
具体的，若成功恢复终端上下文，则从第一MAC PDU里获取DRB ID信息，以及数据包，或者从第二MAC PDU中解析LCID对应的数据包，并获得DRB信息和PDU会话信息。
第一基站在获得数据包之后，向核心网发送路径切换请求，并接收核心网发送的路径切换请求回复；第一基站将数据包通过合适的隧道发送给核心网。
进一步的，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
向第二基站发送取回UE上下文请求消息，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、所述终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个；
第二基站基于UE上下文请求消息中的信息，确定是否进行UE上下文的迁移。
接收第二基站发送的取回UE上下文失败消息。
其中，所述RRC恢复原因指示包含紧急呼叫，高优先级接入，终端终结的接入，终端触发的信令，终端触发的数据，终端触发的语音呼叫和终端触发的视频呼叫至少之一。
在一种实现方式中，取回UE上下文请求消息可以包括RRC恢复原因指示、并携带该数据包对应的承载标识信息，承载标识信息用于第二基站获知数据包对应的DRB ID，以便后续将该数据包通过合适的隧道发送给核心网。
在另一种实现方式中，取回UE上下文请求消息可以包括RRC恢复原因指示和/或数据包发送指示。
第一基站在接收到取回UE上下文失败消息之后，可将数据包发送给第二基站，由第二基站将数据包发送给核心网。若第一基站在向第二基站发送取回UE上下文请求消息的同时也发送了数据包，则第一基站在接收到取回 UE上下文失败消息之后，不用再次向第二基站发送数据包。
进一步的，数据传输方法还包括：
接收所述第二基站通过地址指示消息或所述取回UE上下文失败消息携带的数据转发信息；
向所述第二基站转发所述终端发送的数据包。
具体的，若数据转发信息未携带在取回UE上下文失败消息中，则在接收第二基站发送的取回UE上下文失败消息之后，还接收所述第二基站通过地址指示消息携带的数据转发信息。若数据转发信息携带在取回UE上下文失败消息中，则第一基站通过取回UE上下文失败消息获取数据转发信息。
数据转发信息可为第二基站的传输层(Transport Network Layrer，简称TNL)信息，包括互联网协议地址(Internet Protocol Address，简称IP)信息和隧道协议用户平面(User plane of GPRS Tunneling Protocol,GPRS，简称GTP-U)隧道端点标识(Tunnel Endpoint Identifier,筒称TEID)信息，用于根据数据转发信息确定第二基站，后续将数据包转发至第二基站。
进一步的，所述终端发送的数据包是IP数据包、第一MAC PDU数据包、第一MAC SDU数据包、第二MAC PDU数据包、第二MAC SDU数据包、恢复出的第一RLC SDU和恢复出的第二RLC SDU中至少一个。
在另一实现方式中，取回UE上下文回复消息可以携带RLC配置信息和/或传输层地址信息。
进一步地，第一基站或第一基站的CU恢复RLC SDU或者PDCP PDU，将恢复数据发送给第一基站或第一基站的CU，第一基站或第一基站的CU恢复终端发送数据包，将数据包发送给核心网。
如图5所示，本公开实施例提供一种数据传输方法的又一流程示意图，本实施例提供的数据传输方法，用于第二基站，所述数据传输方法包括：
步骤301、接收第一基站或第一基站的CU发送的取回UE上下文请求消息；
步骤302、向第一基站或第一基站的CU发送取回UE上下文失败消息；
步骤303、发送所述数据包到核心网。
其中，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发 送指示、后续数据包指示信息、终端缓存信息、终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个。
第二基站基于UE上下文请求消息中的信息，确定是否进行UE上下文的迁移。
在一种实现方式中，取回UE上下文请求消息可以包括RRC恢复原因指示、并携带该数据包对应的承载标识信息，承载标识信息用于第二基站获知数据包对应的DRB ID，以便后续将该数据包通过合适的隧道发送给核心网。
在另一种实现方式中，取回UE上下文请求消息可以包括RRC恢复原因指示和/或数据包发送指示。
第二基站可根据取回UE上下文请求消息获知RRC恢复原因是数据包传输、IP数据包，以及DRB ID信息。具体可通过如下两种方式获得IP数据包，和DRB ID信息：
第一种方式：从取回UE上下文请求消息里获取DRB ID或者PDU会话ID信息，从第二基站和第一基站间的数据面获得IP数据包。
第二种方式：从第二基站发送的MAC PDU解析获得LCID对应的DRB或者PDU会话ID信息，解析获得IP数据包。
若第二基站根据取回UE上下文请求消息可获得终端发送的数据包，则可将数据包发送到核心网络；若第二基站根据取回UE上下文请求消息未获得终端发送的数据包，则需要接收第一基站或第一基站的CU发送的数据包，然后将数据包发送到核心网络。
取回UE上下文失败消息可以携带第二基站的TNL层信息，包括IP地址信息和GTP-U TEID信息，也可以在后续使用数据转发信息告知第二基站的TNL层信息，第二基站的TNL层信息用于接入基站将数据包转至第二基站。
在另一实现方式中，取回UE上下文失败消息可以携带RLC配置信息和/或传输层地址信息。
进一步地，第一基站或第一基站的CU恢复RLC SDU或者PDCP PDU，将恢复数据发送给第一基站或第一基站的CU，第一基站或第一基站的CU恢复终端发送数据包，将数据包发送给核心网。
在另一实现方式中，第一基站接收取回UE上下文回复消息后还接收第二基站发送的RLC配置信息和/或传输层地址信息。
进一步地，第一基站或第一基站的CU恢复RLC SDU或者PDCP PDU，将恢复数据发送给第一基站或第一基站的CU，第一基站或第一基站的CU恢复终端发送数据包，将数据包发送给核心网。
在本实施例中，第二基站向第一基站或第一基站的CU发送取回UE上下文失败消息之后，第二基站发送所述数据包到核心网，即可以在不切换锚点基站的场景下将数据包发送给核心网，提高了数据包的传输效率，降低了数据包的传输时延。
进一步的，所述取回UE上下文失败消息携带数据转发信息，所述数据传输方法还包括：
接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
数据转发信息可携带在取回UE上下文失败消息中，数据转发信息可为第二基站的TNL层信息，包括IP地址信息和GTP-U TEID信息，用于根据数据转发信息确定第二基站，后续第一基站或第一基站的CU根据数据转发信息将数据包转发至第二基站。
进一步的，数据转发信息还可未携带在取回UE上下文失败消息中，而是第二基站通过地址指示消息携带数据转发信息，第二基站将地址指示消息发送给第一基站或第一基站的CU，后续第一基站或第一基站的CU将数据包根据数据转发信息转发至第二基站。
即，所述数据传输方法还包括：向所述第一基站或第一基站的CU发送携带数据转发信息的地址指示消息；
接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
如图6所示，本公开实施例提供一种数据传输方法的又一流程示意图，本实施例提供的数据传输方法，用于第一基站的分布单元DU，所述数据传输方法包括：
步骤401、接收处于RRC非激活状态的终端发送的数据包和RRC恢复 请求消息。
对于四步随机接入流程，接收终端在PRACH时机发送的前导码，在检测出前导码后，向终端发送随机接入响应消息，使用发送前导码的PRACH时机对应的RA-RNTI加扰；
对于两步随机接入流程，接收终端在PRACH时机发送的前导码，并接收终端在PUSCH时机发送的数据包和RRC恢复请求消息。
步骤402、将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU。
步骤403、接收第一基站的CU发送的RRC释放消息；
对于四步随机接入流程，第一基站的CU向终端发送RRC释放消息，携带挂起指示。
对于两步随机接入流程，第一基站的CU可将RRC释放消息携带在MSG B消息。
步骤404、将所述RRC释放消息发送给终端。
第一基站的DU将所述RRC释放消息发送给终端，终端在接收到RRC释放消息后，释放RRC连接，终端进入RRC非激活状态，可节省终端的功耗，RRC释放消息也用于指示终端竞争冲突解决成功。
本实施例中，第一基站的DU接收处于RRC非激活状态的终端发送的数据包和RRC恢复请求消息；将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；接收第一基站的CU发送的RRC释放消息；将所述RRC释放消息发送给终端。将数据包传输的时机提前，降低了传输时延，且能够加快终端重新回到RRC非激活状态的进程，节约了终端的功耗。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一MAC PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、 分段处理至少一项。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
上述与图1所示实施例中的记载相同的内容，具体可参见图1所示实施例中的相关记载，在此不做赘述。
进一步的，所述将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU包括：
通过初始RRC转移消息或通过CU与DU之间的用户面接口发送所述数据包到所述CU。
进一步的，通过CU与DU之间的用户面接口发送所述数据包到所述CU包括：
接收所述CU发送的携带传输网络层信息的UE上下文建立请求消息；
根据所述传输网络层信息，发送所述数据包到所述CU。
DU向CU发送UE上下文建立请求消息，UE上下文建立请求消息携带传输网络层信息，例如网络层地址信息。DU根据所述传输网络层信息，发送所述数据包到所述CU，具体的，DU可向CU发送UE上下文建立回复消息和数据包。
进一步的，数据传输方法还包括：接收终端发送的BSR信息，将所述BSR信息发送给第一基站的CU。
第一基站的DU接收终端发送的缓存状态报告(Buffer Status Report，简称BSR)信息，所述BSR信息用于告知终端的缓存情况。
以下提供几种场景对本公开提供的数据传输方法的过程进行如下说明。图7a-7d中，目标基站可理解为第一基站或第一基站的DU或第一基站的CU，锚点基站可理解为第二基站，核心网可为接入和移动管理功能(Access and  Mobility Management Function，简称AMF)网元或者用户面功能(User Plane Function，简称UPF)网元。
如图7a所示为场景1：基于四步RACH发送数据包，且锚点基站不切换。
其中，步骤10：终端处于RRC非激活状态(即RRC_inactive状态)；
步骤11：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码。
步骤12：基站检测出前导码，向终端发送随机接入响应，主要包括TA，UL grant，RAPID等信息，使用发送前导码的PRACH时机对应RA-RNTI加扰。
步骤13：终端如果发现随机接入响应是给自己的，也就是RAPID一致，将在UL Grant资源上发送终端的ID，以及上行的数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，这种方式下，数据包按照正常处理方式处理，包括PDCP层和RLC层处理等， 生成MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，这种方式下，由于承载激活，所以LCID使用正常的数据的逻辑信道ID即可，即使用000001-100000。
步骤14：接入基站(即目标基站)在收到终端发送来的数据包和连接恢复请求消息后，从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息，向锚点基站发送终端上下文获取请求消息(即取回UE上下文请求消息)，该消息携带内容有如下几种情况：
情况1：接入基站在终端上下文获取请求消息中发送RRC恢复原因为数据包传输，并携带该数据包对应的DRB ID，用于锚点基站获知该数据包对应的DRB ID，以便后续将该数据包通过合适的隧道发送给核心网。
情况2：接入基站在终端上下文获取请求消息中发送RRC恢复原因为数据包传输，和/或将该MAC sub-PDU信息发送给锚点基站。
步骤15：锚点基站获知连接恢复请求原因(即RRC恢复原因)是数据包传输，获得IP数据包，以及DRB ID信息，向接入基站发送终端上下文获取失败消息(即取回UE上下文失败消息)，该消息可以携带锚点基站的TNL层信息，包括IP地址信息和GTP-U TEID信息，也可以在后续使用步骤15’、发送TNL指示信息告知接入基站锚点基站的TNL信息，用于接入基站将数据转至锚点基站。
具体如何获得IP数据包以及DRB信息有如下两种情况：
情况1：从终端上下文获取请求消息里获取DRB ID或者PDU会话ID信息，从锚点基站和接入基站间的数据面获得数据包，将该数据包发送至核心网。
情况2：从接入基站发送的MAC PDU解析获得LCID对应的DRB或者PDU会话ID信息，并解析获得数据包，将该数据包发送至核心网。
步骤16：接入基站向终端发送RRC释放消息，携带挂起指示，终端进入非激活状态，该RRC release消息也用于指示终端竞争冲突解决成功。
如图7b所示为场景2：基于四步RACH发送数据包，并且锚点基站切换。
步骤20：终端处于RRC_inactive状态。
步骤21：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码。
步骤22：基站检测出前导码，向终端发送随机接入响应，主要包括TA，UL grant，RAPID等信息，使用发送前导码的PRACH时机对应RA-RNTI加扰。
步骤23：终端如果发现随机接入响应是给自己的，也就是RAPID一致，将在UL Grant资源商发送终端的ID，以及上行的数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U隧道(即tunnel)发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤24：接入基站在收到终端发送来的数据包和连接恢复请求消息后， 从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息，向锚点基站发送终端上下文获取请求消息。
步骤25：接收锚点基站发送的终端上下文请求回复消息。如果成功恢复终端上下文，从MAC sub-PDU里获取DRB ID信息，以及数据包，或者，从MAC PDU解析LCID对应的数据包，并获得DRB信息和PDU session信息。
步骤26：接入基站向核心网发送路径切换请求；
步骤27、接收核心网发送的路径切换请求回复。
步骤28：接入基站将数据包通过合适的隧道发送给核心网。
步骤29：接入基站向锚点基站发送终端上下文释放消息。
如图7c所示为场景3：两步RACH发送数据包并且锚点基站不切换。
步骤30：终端处于RRC_inactive状态。
步骤31：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码，并在PUSCH时机发送RRC恢复请求和数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成 MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤32：接入基站检测出前导码，并成功解调PUSCH携带的MAC PDU信息。
接入基站在收到终端发送来的数据包和连接恢复请求消息(即RRC恢复请求消息)后，从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息，向锚点基站发送终端上下文获取请求消息，该消息携带内容有以下几种情况：
情况1：接入基站在终端上下文获取请求消息中发送RRC恢复原因为数据包传输，并携带该数据包对应的DRB ID，用于锚点基站获知该数据包对应的DRB ID，以便后续将该数据包通过合适的隧道发送给核心网。
情况2：接入基站在终端上下文获取请求消息中发送RRC恢复原因为数据包传输，和/或将该MAC sub-PDU信息发送给锚点基站。
步骤33：锚点基站获知连接恢复请求原因是数据包传输，获得IP数据包，以及DRB ID信息，向接入基站发送终端上下文获取失败消息，该消息可以携带锚点基站的TNL层信息包括IP地址信息和GTP-U TEID信息，也可以在后续使用步骤33’、发送TNL指示信息告知接入基站锚点基站的TNL信息，用于接入基站将数据转至锚点基站。
具体如何获得IP数据包以及DRB信息包括：从终端上下文获取请求消息里获取DRB ID或者PDU会话ID信息，从锚点基站和接入基站间的数据面获得数据包，将该数据包发送至核心网。或者，从接入基站发送的MAC PDU解析获得LCID对应的DRB或者PDU会话ID信息，并解析获得数据包，将该数据包发送至核心网。
步骤34：接入基站向终端发送MSG B消息，可能包含成功随机接入响应信息，RRC释放信息以及RAPID信息等。
进一步的，终端如果收到成功随机接入相应信息且终端标识以及RAPID与自己的对应，认为数据发送成功，否则继续尝试随机接入。
如图7d所示为场景4：基于两步RACH发送数据包，并且锚点基站切 换。
步骤40：终端处于RRC_inactive状态。
步骤41：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码，并在PUSCH时机发送RRC恢复请求和数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤42：接入基站在收到终端发送来的数据包和连接恢复请求消息后，从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息，向锚点基站发送终端上下文获取请求消息。
步骤43：接收锚点基站发送的终端上下文请求回复消息。如果成功恢复终端上下文，从MAC sub-PDU里获取DRB ID信息，以及数据包，或者，从MAC PDU解析LCID对应的数据包，并获得DRB信息和PDU session信息。
步骤44：接入基站向核心网发送路径切换请求；
步骤45：接收核心网发送的路径切换请求回复。
步骤46：接入基站将数据包通过合适的隧道发送给核心网。
步骤47：接入基站向终端发送MSG B消息，可能包含成功随机接入响应信息，RRC释放消息以及RAPID信息等。
进一步的，终端如果收到成功随机接入相应信息且终端标识以及RAPID与自己的对应，认为数据发送成功，否则继续尝试随机接入。
由于第一基站可以分为第一基站CU和第一基站的DU，涉及CU与DU之间信息交互，图7e所示为以四步RACH发送数据包、且不更换锚点基站为例进行的步骤描述，其流程同样适用于四步RACH更换锚点基站场景、两步RACH更换锚点基站场景和两步RACH不更换锚点基站场景。
如图7e所示为CU-DU架构基于四步RACH发送数据包，且锚点基站切换场景。
步骤50：终端处于RRC非激活状态。
步骤51：终端有上行小包数据需要传输，在PRACH时机向DU发送前导码。
步骤52：DU检测出前导码，向终端发送随机接入响应，主要包括TA，UL grant，RAPID等信息，使用发送前导码的PRACH时机对应RA-RNTI加扰。
步骤53：终端如果发现随机接入响应是给自己的，也就是RAPID一致，将在UL Grant资源商发送终端的ID，以及上行的数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤54：接入基站DU在收到终端发送来的数据包和连接恢复请求消息后，将上述连接恢复请求消息发送给CU，可选地，将所述数据包发送给CU，CU将从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息。
步骤55、CU向锚点基站发送终端上下文获取请求消息。
步骤56：CU接收锚点基站发送的终端上下文请求回复消息。如果成功恢复终端上下文，从MAC sub-PDU里获取DRB ID信息，以及数据包，或者，从MAC PDU解析LCID对应的数据包，并获得DRB信息和PDU session信息。
步骤57：接入基站CU向DU发送UE上下文建立请求，携带传输网络层地址信息。
步骤58：DU向CU发送UE上下文建立回复消息。
步骤58’：可选地，DU根据传输网络层地址信息，将所述数据包发送给CU。
步骤59：CU向核心网发送路径切换请求；
步骤59’：CU向DU发送RRC释放消息；
步骤510’：DU向终端发送RRC释放消息。
步骤510、并接收核心网发送的路径切换请求回复。
步骤511：CU将数据包通过合适的隧道发送给核心网。
步骤512：CU向锚点基站发送终端上下文释放消息。
如图7f所示为CU-DU架构基于四步RACH发送数据包，且锚点基站不切换场景。
步骤60：终端处于RRC非激活状态。
步骤61：终端有上行小包数据需要传输，在PRACH时机向DU发送前导码。
步骤62：DU检测出前导码，向终端发送随机接入响应，主要包括TA，UL grant，RAPID等信息，使用发送前导码的PRACH时机对应RA-RNTI加扰。
步骤63：终端如果发现随机接入响应是给自己的，也就是RAPID一致，将在UL Grant资源商发送终端的ID，以及上行的数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成 MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，这种情况下，LCID使用正常的数据的逻辑信道ID即可，即使用000001-100000。
步骤64：接入基站DU在收到终端发送来的数据包和连接恢复请求消息后，将上述连接恢复请求消息发送给CU，可选地，将所述数据包发送给CU，CU将从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息。
步骤65：CU向锚点基站发送终端上下文获取请求消息。
步骤66：CU接收锚点基站发送的终端上下文请求回复消息，上下文请求回复消息为终端上下文获取失败消息，该消息可以携带锚点基站的TNL层信息，包括IP地址信息和GTP-U TEID信息，也可以在后续步骤中，发送TNL指示信息告知接入基站锚点基站的TNL信息，用于接入基站将数据转至锚点基站。
步骤67：CU向DU发送UE上下文建立请求，携带传输网络层地址信息。
步骤68：DU向CU发送UE上下文建立回复消息。
步骤68’：可选地，DU根据传输网络层地址信息，将所述数据包发送给CU。
步骤69’：CU向DU发送RRC释放消息。
步骤610’：DU向终端发送RRC释放消息。
步骤610、CU将数据包发送给锚点基站。
步骤611、锚点基站将数据包发送给核心网。
步骤612：CU向锚点基站发送终端上下文释放消息。
如图7f所示为CU-DU架构基于两步RACH发送数据包，且锚点基站不切换场景。
步骤70：终端处于RRC_inactive状态。
步骤71：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码，并在PUSCH时机发送RRC恢复请求和数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header 形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成MAC SDU，并将该SDU与MAC subheader一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤72：DU在收到终端发送来的数据包和连接恢复请求消息后，将上述连接恢复请求消息发送给CU，可选地，将所述数据包发送给CU，CU将从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息。CU向锚点基站发送终端上下文获取请求消息。
步骤73：CU接收锚点基站发送的终端上下文请求回复消息，终端上下文请求回复消息为终端上下文获取失败消息。如果成功恢复终端上下文，从MAC sub-PDU里获取DRB ID信息，以及数据包，或者，从MAC PDU解析LCID对应的数据包，并获得DRB信息和PDU会话信息。
步骤74：CU向DU发送UE上下文建立请求，携带传输网络层地址信息。
步骤75：DU向CU发送UE上下文建立回复消息。
步骤75’：可选地，DU根据传输网络层地址信息，将所述数据包发送给 CU。
步骤76’：CU向DU发送RRC释放消息。
步骤77’：DU向终端发送RRC释放消息。
步骤76：CU将数据包发送给锚点基站。
步骤77：锚点基站将数据包发送给核心网。
步骤78：CU向锚点基站发送终端上下文释放消息。
如图7f所示为CU-DU架构基于两步RACH发送数据包，且锚点基站切换场景。
步骤80：终端处于RRC_inactive状态。
步骤81：终端有上行小包数据需要传输，在PRACH时机向基站发送前导码，并在PUSCH时机发送RRC恢复请求和数据包。具体有如下几种方案：
方案1：如果终端没有激活SRB，DRB等配置，终端直接将IP数据包作为MAC SDU封装成MAC PDU发送出去。终端将数据包添加MAC sub-header形成MAC sub-PDU，放在包含CCCH(RRC恢复请求消息)或DCCH的MAC sub-PDU之后，且携带CCCH或DCCH的MAC sub-PDU的sub-header中包含指示之后是否还包含其它MAC PDU，具体MAC PDU如图3a所示：
其中，第一个sub-header S域表示后续是否还有MAC sub-PDU存在，第二个MAC sub-PDU的sub-header具有如下两种情况：
情况1：头信息(即子头信息)中包含对应于数据包的专用LCID，用于基站识别这是一个IP的数据包，以及该数据包对应的DRB ID信息，用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
情况2：头信息中包含数据包对应的DRB ID信息，基站识别这是一个IP的数据包同时用于基站获知该数据包对应于终端的哪个承载，使得基站能够准确地将该数据包放在合适的GTP-U tunnel发给核心网。
方案2：终端如果需要发送上行数据包，首先激活SRB，DRB等配置，将上行数据包按照正常处理方式处理，包括PDCP层和RLC层处理等，生成MAC SDU，并将该SDU与MAC sub-header一起形成MAC sub-PDU，然后放置在携带CCCH或DCCH的MAC sub-PDU之后，如图3b所示，图中LCID 使用正常的数据的逻辑信道ID，也就是000001-100000。
步骤82：DU在收到终端发送来的数据包和连接恢复请求消息后，将上述连接恢复请求消息发送给CU，可选地，将所述数据包发送给CU，CU将从连接恢复消息获知I-RNTI和MAC-I，得到锚点基站的ID信息。CU向锚点基站发送终端上下文获取请求消息。
步骤83：CU接收锚点基站发送的终端上下文请求回复消息。
步骤84：CU向DU发送UE上下文建立请求，携带传输网络层地址信息。
步骤85：DU向CU发送UE上下文建立回复消息。
步骤85’：可选地，DU根据传输网络层地址信息，将所述数据包发送给CU。
步骤86：CU向核心网发送路径切换请求。
步骤86’：CU向DU发送RRC释放消息。
步骤87：接收核心网发送的路径切换请求回复。
步骤88：CU将数据包通过合适的隧道发送给核心网。
步骤89：CU向锚点基站发送终端上下文释放消息。
上述实施例中，目标基站接收终端随机接入过程发送的数据包，并将该数据包在锚点基站切换或者不切换时将数据包发送给核心网。锚点基站不切换时，目标基站和锚点基站交互数据包，DRB ID以及锚点基站TNL等信息，目标基站将数据包发送给锚点基站，由锚点基站将数据包发送给核心网；锚点基站切换时，目标基站获取终端上下文，并恢复终端上下文，获得数据包，在路径切换后将数据包发送给核心网。
上述实施例利用两步随机接入流程或四步随机接入流程发送小数据包，可以在不用恢复RRC连接且锚点基站可以切换或者不可以切换的场景下，进行数据包发送，可以解决已有技术中小数据包传输需要先恢复RRC连接，并需要切换锚点基站带来的数据包传输时延大，效率低的缺点。
如图8所示，图8是本公开实施例提供的一种终端的结构示意图，如图8所示，终端600处于无线资源控制RRC非激活状态，终端600包括：
第一发送模块601，用于发送数据包和RRC恢复请求消息到第一基站或 第一基站的集中单元CU或第一基站的分布单元DU；
第一接收模块602，用于接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，还包括封装模板，用于将所述数据包直接作为第一媒体访问控制MAC服务数据单元SDU封装到第一MAC协议数据单元PDU；
或
将利用所述数据包进行前置处理生成的第二MAC SDU封装到第二MAC PDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理中的至少一项。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括的逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
终端600能够实现图1所示的方法实施例中终端实现的各个过程，并能达到相同的技术效果，为避免重复，这里不再赘述。
图9为实现本公开各个实施例的终端的结构示意图，该终端800包括但不限于：收发单元(即收发机)801、网络模块802、音频输出单元803、输入单元804、传感器805、显示单元806、用户输入单元807、接口单元808、存储器809、处理器810、以及电源811等部件。本领域技术人员可以理解，图9中示出的终端结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。在本公开实施例中，终端包括但不限于手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿 戴设备、以及计步器等。
其中，在本公开一个实施例中，收发单元801用于发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU；接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，处理器810，用于将所述数据包直接作为第一媒体访问控制MAC服务数据单元SDU封装到第一MAC协议数据单元PDU；
或
将利用所述数据包进行前置处理生成的第二MAC SDU封装到第二MAC PDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理中的至少一项。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括的逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
终端800能够实现图1所示的方法实施例中终端实现的各个过程，并能达到相同的技术效果，为避免重复，这里不再赘述。
应理解的是，本公开实施例中，收发单元801可用于收发信息或通话过程中，信号的接收和发送，具体的，将来自基站的下行数据接收后，给处理器810处理；另外，将上行的数据发送给基站。通常，收发单元801包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，收发单元801还可以通过无线通信系统与网络和其他设备通信。
终端通过网络模块802为用户提供了无线的宽带互联网访问，如帮助用户收发电子邮件、浏览网页和访问流式媒体等。
音频输出单元803可以将收发单元801或网络模块802接收的或者在存储器809中存储的音频数据转换成音频信号并且输出为声音。而且，音频输出单元803还可以提供与终端800执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出单元803包括扬声器、蜂鸣器以及受话器等。
输入单元804用于接收音频或视频信号。输入单元804可以包括图形处理器(Graphics Processing Unit，简称GPU)8041和麦克风8042，图形处理器8041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元806上。经图形处理器8041处理后的图像帧可以存储在存储器809(或其它存储介质)中或者经由收发单元801或网络模块802进行发送。麦克风8042可以接收声音，并且能够将这样的声音处理为音频数据。处理后的音频数据可以在电话通话模式的情况下转换为可经由收发单元801发送到移动通信基站的格式输出。
终端800还包括至少一种传感器805，比如光传感器、运动传感器以及其他传感器。具体地，光传感器包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板8061的亮度，接近传感器可在终端800移动到耳边时，关闭显示面板8061和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别终端姿态(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；传感器805还可以包括指纹传感器、压力传感器、虹膜传感器、分子传感器、陀螺仪、气压计、湿度计、温度计、红外线传感器等，在此不再赘述。
显示单元806用于显示由用户输入的信息或提供给用户的信息。显示单元806可包括显示面板8061，可以采用液晶显示器(Liquid Crystal Display，简称LCD)、有机发光二极管(Organic Light-Emitting Diode,简称OLED)等形式来配置显示面板8061。
用户输入单元807可用于接收输入的数字或字符信息，以及产生与终端的用户设置以及功能控制有关的键信号输入。具体地，用户输入单元807包括触控面板8071以及其他输入设备8072。触控面板8071，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板8071上或在触控面板8071附近的操作)。触控面板8071可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器810，接收处理器810发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板8071。除了触控面板8071，用户输入单元807还可以包括其他输入设备8072。具体地，其他输入设备8072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。
进一步的，触控面板8071可覆盖在显示面板8061上，当触控面板8071检测到在其上或附近的触摸操作后，传送给处理器810以确定触摸事件的类型，随后处理器810根据触摸事件的类型在显示面板8061上提供相应的视觉输出。虽然在图8中，触控面板8071与显示面板8061是作为两个独立的部件来实现终端的输入和输出功能，但是在某些实施例中，可以将触控面板8071与显示面板8061集成而实现终端的输入和输出功能，具体此处不做限定。
接口单元808为外部装置与终端800连接的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元808可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到终端800内的一个或多个元件或者可以用于在终端800和外部装置之间传输数据。
存储器809可用于存储软件程序以及各种数据。存储器809可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可 存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器809可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
处理器810是终端的控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器809内的软件程序和/或模块，以及调用存储在存储器809内的数据，执行终端的各种功能和处理数据，从而对终端进行整体监控。处理器810可包括一个或多个处理单元；可选的，处理器810可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器810中。
终端800还可以包括给各个部件供电的电源811(比如电池)，可选的，电源811可以通过电源管理系统与处理器810逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
另外，终端800包括一些未示出的功能模块，在此不再赘述。
可选的，本公开实施例还提供一种终端，包括处理器810，存储器809，存储在存储器809上并可在所述处理器810上运行的计算机程序，该计算机程序被处理器810执行时实现上述图1所示的数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
参见图10，图10是本公开实施例提供的一种网络侧设备的结构示意图，如图10所示，第一网络侧设备900为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，第一网络侧设备900包括：
第二接收模块901，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
第二发送模块902，用于发送RRC释放消息给终端。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC连接恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生 成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理至少一项。
进一步的，所述第一MAC PDU包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
进一步的，第一网络侧设备900还包括：第三发送模块，用于发送恢复出的所述数据包到核心网。
进一步的，第一网络侧设备900还包括：
第四发送模块，用于向第二基站发送取回UE上下文请求消息；
第三接收模块，用于接收第二基站发送的取回UE上下文回复消息；
第五发送模块，用于发送所述数据包到核心网。
进一步的，第五发送模块，用于依据成功恢复的终端上下文，从终端发送的第一MAC PDU或第二MAC PDU中获取所述数据包，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU；发送所述数据包到核心网。
进一步的，第一网络侧设备900还包括，第六发送模块，用于向第二基站发送取回UE上下文请求消息，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、所述终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个；
第四接收模块，用于接收第二基站发送的取回UE上下文失败消息。
进一步的，第一网络侧设备900还包括：
第五接收模块，用于接收所述第二基站通过地址指示消息或所述取回UE上下文失败消息携带的数据转发信息；
第七发送模块，用于向所述第二基站转发所述终端发送的数据包。
进一步的，所述终端发送的数据包是IP数据包、第一MAC PDU数据包、第一MAC SDU数据包、第二MAC PDU数据包、第二MAC SDU数据包、恢复出的第一RLC SDU和恢复出的第二RLC SDU中至少一个。
进一步的，所述RRC恢复原因指示包含紧急呼叫，高优先级接入，终端终结的接入，终端触发的信令，终端触发的数据，终端触发的语音呼叫和终端触发的视频呼叫至少之一。
第一网络侧设备900能够实现图3所示的方法实施例中第一基站或第一基站的集中单元CU或第一基站的分布单元DU实现的各个过程以及达到相同的技术效果，为避免重复，这里不再赘述。
参见图11，图11是本公开实施例提供的一种网络侧设备的结构示意图，如图11所示，第二网络侧设备1000包括：
第六接收模块1001，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；
第八发送模块1002，用于向第一基站或第一基站的CU发送取回UE上下文失败消息；
第九发送模块1003，发送所述数据包到核心网。
进一步的，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个。
进一步的，第二网络侧设备1000还包括：
第七接收模块，用于接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
进一步的，第二网络侧设备1000还包括：
第十发送模块，用于向所述第一基站或第一基站的CU发送携带数据转发信息的地址指示消息；
第八接收模块，用于接收第一基站或第一基站的CU根据所述数据转发 信息发送的所述数据包。
第二网络侧设备1000能够实现图4所示的方法实施例中第二基站实现的各个过程以及达到相同的技术效果，为避免重复，这里不再赘述。
参见图12，图12是本公开实施例提供的一种网络侧设备的结构示意图，如图12所示，第三网络侧设备1100为第一基站的DU，第三网络侧设备1100包括：
第九接收模块1101，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
第十一发送模块1102，用于将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；
第十接收模块1103，用于接收第一基站的CU发送的RRC释放消息；
第十二发送模块1104，用于将所述RRC释放消息发送给终端。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理至少一项。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
进一步的，第十一发送模块1102，还包括：
发送子模块，用于通过初始RRC转移消息或通过CU与DU之间的用户面接口发送所述数据包到所述CU。
进一步的，发送子模块，用于接收所述CU发送的携带传输网络层信息的UE上下文建立请求消息；
根据所述传输网络层信息，发送所述数据包到所述CU。
进一步的，第三网络侧设备1100还包括：
第十一接收模块，用于接收终端发送的缓存状态报告BSR信息，将所述BSR信息发送给第一基站的CU。
第三网络侧设备1100能够实现图5所示的方法实施例中第一基站的DU实现的各个过程以及达到相同的技术效果，为避免重复，这里不再赘述。
参见图13，图13是本公开实施例提供的一种网络侧设备的结构示意图，如图13所示，包括总线1201、收发机1202、天线1203、总线接口1204、处理器1205和存储器1206。
在本公开一个实施例中，网络侧设备为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，收发机1202，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；发送RRC释放消息给终端。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC连接恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理至少一项。
进一步的，所述第一MAC PDU包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
进一步的，收发机1202，还用于发送恢复出的所述数据包到核心网。
进一步的，收发机1202，还用于向第二基站发送取回UE上下文请求消息；
接收第二基站发送的取回UE上下文回复消息；
发送所述数据包到核心网。
进一步的，收发机1202，还用于依据成功恢复的终端上下文，从终端发送的第一MAC PDU或第二MAC PDU中获取所述数据包，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU；
发送所述数据包到核心网。
进一步的，收发机1202，还用于向第二基站发送取回UE上下文请求消息，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、所述终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个；
接收第二基站发送的取回UE上下文失败消息。
进一步的，收发机1202，还用于接收所述第二基站通过地址指示消息或所述取回UE上下文失败消息携带的数据转发信息；
向所述第二基站转发所述终端发送的数据包。
进一步的，所述终端发送的数据包是IP数据包、第一MAC PDU数据包、第一MAC SDU数据包、第二MAC PDU数据包、第二MAC SDU数据包、恢复出的第一RLC SDU和恢复出的第二RLC SDU中至少一个。
进一步的，所述RRC恢复原因指示包含紧急呼叫，高优先级接入，终端终结的接入，终端触发的信令，终端触发的数据，终端触发的语音呼叫和终端触发的视频呼叫至少之一。
本实施例中的设备可实现图3所示实施例中的第一基站或第一基站的集 中单元CU或第一基站的分布单元DU实现的各个过程以达到相同的技术效果，在此不做赘述。
在本公开另一个实施例中，网络侧设备为第二基站，收发机1202，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；向第一基站或第一基站的CU发送取回UE上下文失败消息；发送所述数据包到核心网。
进一步的，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个。
进一步的，收发机1202，还用于接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
进一步的，收发机1202，还用于向所述第一基站或第一基站的CU发送携带数据转发信息的地址指示消息；接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
本实施例中的设备可实现图4所示实施例中的第二基站实现的各个过程以达到相同的技术效果，在此不做赘述。
在本公开又一个实施例中，网络侧设备为第一基站的DU，收发机1202，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；接收第一基站的CU发送的RRC释放消息；将所述RRC释放消息发送给终端。
进一步的，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
进一步的，所述数据包与所述RRC恢复请求消息复用或者串联。
进一步的，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
进一步的，所述前置处理包括信令承载和数据承载的恢复处理、加密处 理、分段处理至少一项。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
或
所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
进一步的，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
进一步的，收发机1202，还用于通过初始RRC转移消息或通过CU与DU之间的用户面接口发送所述数据包到所述CU。
进一步的，收发机1202，还用于接收所述CU发送的携带传输网络层信息的UE上下文建立请求消息；根据所述传输网络层信息，发送所述数据包到所述CU。
进一步的，收发机1202，还用于接收终端发送的缓存状态报告BSR信息，将所述BSR信息发送给第一基站的CU。
本实施例中的设备可实现图5所示实施例中的第一基站的DU实现的各个过程以达到相同的技术效果，在此不做赘述。
在图12中，总线架构(用总线1201来代表)，总线1201可以包括任意数量的互联的总线和桥，总线1201将包括由处理器1205代表的一个或多个处理器和存储器1206代表的存储器的各种电路链接在一起。总线1201还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口1204在总线1201和收发机1202之间提供接口。收发机1202可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1205处理的数据通过天线1203在无线介质上进行传输，进一步，天线1203还接收数据并将数据传送给处理器1205。
处理器1205负责管理总线1201和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1206 可以被用于存储处理器1205在执行操作时所使用的数据。
可选的，处理器1205可以是CPU、ASIC、FPGA或CPLD。
可选的，本公开实施例还提供一种网络侧设备，包括处理器1205，存储器1206，存储在存储器1206上并可在所述处理器1205上运行的计算机程序，该计算机程序被处理器1205执行时实现上述图3所示数据传输方法中的各个过程，或者，该计算机程序被处理器1205执行时实现上述图4所示数据传输方法中的各个过程，或者，该计算机程序被处理器1205执行时实现上述图5所示数据传输方法中的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
本公开实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如图1所示的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如图3所示的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如图4所示的数据传输方法中的步骤，或者，所述计算机程序被所述处理器执行时实现如图5所示的数据传输方法中的步骤。
其中，所述的计算机可读存储介质，如ROM、RAM、磁碟或者光盘等。
可以理解的是，本公开描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，模块、单元、子模块、子单元等可以实现在一个或多个专用集成电路(Application Specific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable Logic Device，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本公开所述功能的其它电子单元或其组合中。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方 法、物品或者装置中还存在另外的相同要素。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本公开各个实施例所述的方法。
上面结合附图对本公开的实施例进行了描述，但是本公开并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本公开的启示下，在不脱离本公开宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本公开的保护之内。

Claims (49)

  1. 一种数据传输方法，用于处于无线资源控制RRC非激活状态的终端，所述数据传输方法包括：
    发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU；
    接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
  2. 根据权利要求1所述的数据传输方法，其中，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
  3. 根据权利要求1所述的数据传输方法，其中，所述数据包与所述RRC恢复请求消息复用或者串联。
  4. 根据权利要求1所述的数据传输方法，其中，发送数据包和RRC恢复请求消息到第一基站或第一基站的CU或第一基站的DU之前，还包括：
    将所述数据包直接作为第一媒体访问控制MAC服务数据单元SDU封装到第一MAC协议数据单元PDU；
    或
    将利用所述数据包进行前置处理生成的第二MAC SDU封装到第二MAC PDU。
  5. 根据权利要求4所述的数据传输方法，其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理中的至少一项。
  6. 根据权利要求4所述的数据传输方法，其中：
    所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
    或
    所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
  7. 根据权利要求6所述的数据传输方法，其中，所述第一MAC SDU的 子头信息中包括的逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
  8. 一种数据传输方法，用于第一基站或第一基站的集中单元CU或第一基站的分布单元DU，所述数据传输方法包括：
    接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
    发送RRC释放消息给终端。
  9. 根据权利要求8所述的数据传输方法，其中，所述RRC恢复请求消息为四步随机接入流程中的RRC连接恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
  10. 根据权利要求8所述的数据传输方法，其中，所述数据包与所述RRC恢复请求消息复用或者串联。
  11. 根据权利要求8所述的数据传输方法，其中，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，第一MAC PDU中包括通过所述数据包直接生成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
  12. 根据权利要求11所述的数据传输方法，其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理至少一项。
  13. 根据权利要求11所述的数据传输方法，其中，所述第一MAC PDU包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
    或
    所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
  14. 根据权利要求13所述的数据传输方法，其中，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
  15. 根据权利要求8所述的数据传输方法，其中，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
    发送恢复出的所述数据包到核心网。
  16. 根据权利要求8所述的数据传输方法，其中，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
    向第二基站发送取回UE上下文请求消息；
    接收第二基站发送的取回UE上下文回复消息；
    发送所述数据包到核心网。
  17. 根据权利要求16所述的数据传输方法，其中，发送所述数据包到核心网具体为：
    依据成功恢复的终端上下文，从终端发送的第一MAC PDU或第二MAC PDU中获取所述数据包，所述第一MAC PDU中包括通过所述数据包直接生成的第一MAC SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU；
    发送所述数据包到核心网。
  18. 根据权利要求8所述的数据传输方法，其中，在接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息之后，还包括：
    向第二基站发送取回UE上下文请求消息，所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、所述终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个；
    接收第二基站发送的取回UE上下文失败消息。
  19. 根据权利要求18所述的数据传输方法，其中，还包括：
    接收所述第二基站通过地址指示消息或所述取回UE上下文失败消息携带的数据转发信息；
    向所述第二基站转发所述终端发送的数据包。
  20. 根据权利要求18所述的数据传输方法，其中，所述终端发送的数据包是IP数据包、第一MAC PDU数据包、第一MAC SDU数据包、第二MAC PDU数据包、第二MAC SDU数据包、恢复出的第一RLC SDU和恢复出的第二RLC SDU中至少一个。
  21. 根据权利要求18所述的数据传输方法，其中，所述RRC恢复原因指示包含紧急呼叫，高优先级接入，终端终结的接入，终端触发的信令，终端触发的数据，终端触发的语音呼叫和终端触发的视频呼叫至少之一。
  22. 一种数据传输方法，用于第二基站，所述数据传输方法包括：
    接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；
    向第一基站或第一基站的CU发送取回UE上下文失败消息；
    发送数据包到核心网。
  23. 根据权利要求22所述的数据传输方法，其中，
    所述取回UE上下文请求消息携带RRC恢复原因指示、数据包发送指示、后续数据包指示信息、终端缓存信息、终端发送的数据包、数据包的逻辑信道标识信息和数据包的承载标识信息中的至少一个。
  24. 根据权利要求22所述的数据传输方法，其中，
    所述取回UE上下文失败消息携带数据转发信息，所述数据传输方法还包括：
    接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
  25. 根据权利要求22所述的数据传输方法，其中，所述数据传输方法还包括：
    向所述第一基站或第一基站的CU发送携带数据转发信息的地址指示消息；
    接收第一基站或第一基站的CU根据所述数据转发信息发送的所述数据包。
  26. 一种数据传输方法，应用于第一基站的分布单元DU，其中，所述数据传输方法包括：
    接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
    将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；
    接收第一基站的CU发送的RRC释放消息；
    将所述RRC释放消息发送给终端。
  27. 根据权利要求26所述的数据传输方法，其中，所述RRC恢复请求消息为四步随机接入流程中的RRC恢复请求消息，或，两步随机接入流程中MSG A携带的RRC恢复请求消息。
  28. 根据权利要求26所述的数据传输方法，其中，所述数据包与所述RRC恢复请求消息复用或者串联。
  29. 根据权利要求19所述的数据传输方法，其中，所述数据包封装于第一媒体访问控制MAC协议数据单元PDU或第二MAC PDU，第一MAC PDU中包括通过所述数据包直接生成的第一MAC服务数据单元SDU，所述第二MAC PDU中包括对所述数据包进行前置处理生成的第二MAC SDU。
  30. 根据权利要求29所述的数据传输方法，其中，所述前置处理包括信令承载和数据承载的恢复处理、加密处理、分段处理至少一项。
  31. 根据权利要求29所述的数据传输方法，其中，所述第一MAC SDU的子头信息中包括逻辑信道标识信息和承载标识信息中的至少一个，所述逻辑信道标识信息用于指示所述数据包的逻辑信道类型，所述承载标识信息用于指示所述数据包对应的数据承载；
    或
    所述第二MAC SDU的子头信息中包括逻辑信道标识信息。
  32. 根据权利要求31所述的数据传输方法，其中，所述第一MAC SDU的子头信息中包括逻辑信道标识信息为专用于IP数据包的逻辑信道标识。
  33. 根据权利要求26所述的数据传输方法，其中，所述将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU包括：
    通过初始RRC转移消息或通过CU与DU之间的用户面接口发送所述数据包到所述CU。
  34. 根据权利要求33所述的数据传输方法，其中，通过CU与DU之间的用户面接口发送所述数据包到所述CU包括：
    接收所述CU发送的携带传输网络层信息的UE上下文建立请求消息；
    根据所述传输网络层信息，发送所述数据包到所述CU。
  35. 根据权利要求26所述的数据传输方法，其中，还包括：
    接收终端发送的缓存状态报告BSR信息，将所述BSR信息发送给第一基站的CU。
  36. 一种终端，所述终端处于无线资源控制RRC非激活状态，包括：
    发送模块，用于发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU；
    接收模块，用于接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
  37. 一种终端，所述终端处于无线资源控制RRC非激活状态，包括处理器和收发机；
    所述收发机，用于发送数据包和RRC恢复请求消息到第一基站或第一基站的集中单元CU或第一基站的分布单元DU，以及接收第一基站或第一基站的CU或第一基站的DU发送的RRC释放消息。
  38. 一种网络侧设备，所述网络侧设备为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，包括：
    接收模块，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
    发送模块，用于发送RRC释放消息给终端。
  39. 一种网络侧设备，所述网络侧设备为第一基站或第一基站的集中单元CU或第一基站的分布单元DU，包括处理器和收发机；
    所述收发机，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息，以及发送RRC释放消息给终端。
  40. 一种网络侧设备，所述网络侧设备为第二基站，包括：
    第一接收模块，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息；
    第一发送模块，用于向第一基站或第一基站的CU发送取回UE上下文失败消息；
    第二发送模块，用于发送数据包到核心网。
  41. 一种网络侧设备，所述网络侧设备为第二基站，包括处理器和收发机；
    所述收发机，用于接收第一基站或第一基站的集中单元CU发送的取回用户设备UE上下文请求消息，向第一基站或第一基站的CU发送取回UE上下文失败消息，以及发送数据包到核心网。
  42. 一种网络侧设备，所述网络侧设备为第一基站的DU，包括：
    第一接收模块，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；
    第一发送模块，用于将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；
    第二接收模块，用于接收第一基站的CU发送的RRC释放消息；
    第二发送模块，用于将所述RRC释放消息发送给终端。
  43. 一种网络侧设备，所述网络侧设备为第一基站的DU，包括处理器和收发机；
    所述收发机，用于接收处于无线资源控制RRC非激活状态的终端发送的数据包和RRC恢复请求消息；将所述数据包和RRC恢复请求消息发送给第一基站的集中单元CU；接收第一基站的CU发送的RRC释放消息；以及将所述RRC释放消息发送给终端。
  44. 一种终端，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述的数据传输方法中的步骤。
  45. 一种网络侧设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求8-21中任一项所述的数据传输方法中的步骤，或者所述计算机程序被所述处理器执行时实现如权利要求22-25中任一项所述的数据传输方法中的步骤，或者所述计算机程序被所述处理器执行时实现如权利要求26-35中任一项所述的数据传输方法中的步骤。
  46. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的数据传输方法中的步骤，或者，所述计算机程序被处理器执行时实现如权利要求8至21中任一项所述的数据传输方法中的步骤，所述计算机程序被 处理器执行时实现如权利要求22至25中任一项所述的数据传输方法中的步骤，所述计算机程序被处理器执行时实现如权利要求26至35中任一项所述的数据传输方法中的步骤。
  47. 一种计算机程序产品，所述程序产品被存储在非易失的存储介质中，所述程序产品被至少一个处理器执行以实现如权利要求1至7中任一项所述的数据传输方法，或者，所述计算机程序被至少一个处理器执行以实现如权利要求8至21中任一项所述的数据传输方法，所述计算机程序被至少一个处理器执行以实现如权利要求22至25中任一项所述的数据传输方法，所述计算机程序被至少一个处理器执行以实现如权利要求26至35中任一项所述的数据传输方法。
  48. 一种终端，所述终端被配置成用于执行如权利要求1-7中任一项所述的数据传输方法。
  49. 一种网络侧设备，所述网络侧设备被配置成用于执行如权利要求8-21中任一项所述的数据传输方法，或者如权利要求22-25中任一项所述的数据传输方法，或者如权利要求26-35中任一项所述的数据传输方法。
PCT/CN2021/109710 2020-07-31 2021-07-30 数据传输方法、终端及网络侧设备 WO2022022699A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023506351A JP2023535839A (ja) 2020-07-31 2021-07-30 データ伝送方法、端末及びネットワーク側機器
US18/040,107 US20230319941A1 (en) 2020-07-31 2021-07-30 Data transmission method, terminal and network side device
EP21849926.7A EP4178311A4 (en) 2020-07-31 2021-07-30 DATA TRANSMISSION METHOD, TERMINAL AND NETWORK-SIDE DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010757105.7A CN114071803A (zh) 2020-07-31 2020-07-31 数据传输方法、终端及网络侧设备
CN202010757105.7 2020-07-31

Publications (1)

Publication Number Publication Date
WO2022022699A1 true WO2022022699A1 (zh) 2022-02-03

Family

ID=80037598

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/109710 WO2022022699A1 (zh) 2020-07-31 2021-07-30 数据传输方法、终端及网络侧设备

Country Status (5)

Country Link
US (1) US20230319941A1 (zh)
EP (1) EP4178311A4 (zh)
JP (1) JP2023535839A (zh)
CN (1) CN114071803A (zh)
WO (1) WO2022022699A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116889079A (zh) * 2021-01-05 2023-10-13 欧芬诺有限责任公司 逻辑信道配置
CN114679756B (zh) * 2022-05-26 2022-08-05 武汉世炬信息技术有限公司 用户终端非激活状态的无线连接状态管理系统和方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110636565A (zh) * 2018-06-21 2019-12-31 电信科学技术研究院有限公司 Rrc非活跃状态下的数据传输方法、装置、终端及设备
US20200196349A1 (en) * 2018-12-16 2020-06-18 Qualcomm Incorporated Small data transfer over configured grants for asynchronous non-orthogonal multiple access
CN113271687A (zh) * 2020-02-17 2021-08-17 大唐移动通信设备有限公司 一种数据传输方法、服务基站及锚点基站

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090129315A1 (en) * 2007-11-21 2009-05-21 Qualcomm Incorporated Data discard for radio link control in wireless networks
WO2017132965A1 (zh) * 2016-02-04 2017-08-10 华为技术有限公司 一种数据传输系统、方法和装置
CN110140409B (zh) * 2017-01-05 2023-08-18 索尼公司 通信装置、基础设施设备和方法
WO2018151546A1 (ko) * 2017-02-20 2018-08-23 삼성전자 주식회사 무선 통신 시스템에서 개선된 보안을 위한 방법 및 장치
EP3585087B1 (en) * 2017-03-13 2021-05-05 Huawei Technologies Co., Ltd. Data processing method and base station for handling change of radio bearer type
CN110999523A (zh) * 2017-06-14 2020-04-10 三星电子株式会社 重新连接与无线接入网节点的无线资源控制连接的方法和用户设备
CN109756891A (zh) * 2017-11-08 2019-05-14 夏普株式会社 数据传输方法、设备和存储介质
US11564277B2 (en) * 2018-08-16 2023-01-24 Lg Electronics Inc. Method and apparatus for supporting early data transmission in inactive state in wireless communication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110636565A (zh) * 2018-06-21 2019-12-31 电信科学技术研究院有限公司 Rrc非活跃状态下的数据传输方法、装置、终端及设备
US20200196349A1 (en) * 2018-12-16 2020-06-18 Qualcomm Incorporated Small data transfer over configured grants for asynchronous non-orthogonal multiple access
CN113271687A (zh) * 2020-02-17 2021-08-17 大唐移动通信设备有限公司 一种数据传输方法、服务基站及锚点基站

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ERICSSON (RAPPORTEUR): "Report of email discussion: [96#31][NR] UL data in inactive solution B", 3GPP DRAFT; R2-1700626-REPORT-EMAIL-DISCUSSION-31-SMALL DATA TX-SOLUTION-B-FV, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, 17 January 2017 (2017-01-17), Spokane, USA, pages 1 - 28, XP051211205 *
See also references of EP4178311A4 *

Also Published As

Publication number Publication date
JP2023535839A (ja) 2023-08-21
US20230319941A1 (en) 2023-10-05
EP4178311A4 (en) 2024-01-10
CN114071803A (zh) 2022-02-18
EP4178311A1 (en) 2023-05-10

Similar Documents

Publication Publication Date Title
US11876746B2 (en) Data transmission method and communications device
WO2021037148A1 (zh) 数据传输方法及终端
WO2022022699A1 (zh) 数据传输方法、终端及网络侧设备
US20210337618A1 (en) Connection Establishment Method, Terminal Device, and Network Device
WO2021136473A1 (zh) 多播业务的传输方法、传输处理方法及相关设备
US20230041176A1 (en) Paging response method, terminal, and network device
CN110636641B (zh) 一种ca配置信息的处理方法和终端
WO2019056959A1 (zh) 完整性保护方法、终端和基站
US20210258840A1 (en) Cell handover method, terminal, and communication node
WO2019137425A1 (zh) 重配置方法、终端及基站
US11523428B2 (en) Random access method, terminal device and network device
US20210219325A1 (en) Information indicating method, indication receiving method, terminal, and network-side device
WO2020221125A1 (zh) 配置信息获取、发送方法、终端及网络侧设备
CN113329322A (zh) 数据传输方法、装置、终端及网络侧设备
WO2021218848A1 (zh) 数据重传方法、装置、目标节点、源节点及终端
CN109195185B (zh) 一种业务处理方法及相关设备
US20220159619A1 (en) Multimedia broadcast multicast service configuration method, terminal, and network-side device
AU2020342206B2 (en) Message transmission method and terminal
US20220263561A1 (en) Transmission processing method and terminal
WO2020244479A1 (zh) 连接管理方法、终端及网络侧设备
US20220150773A1 (en) Data transmission method and user equipment
WO2020063474A1 (zh) 数据传输方法及通信设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21849926

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023506351

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021849926

Country of ref document: EP

Effective date: 20230203

NENP Non-entry into the national phase

Ref country code: DE