Data transmission method, terminal, and network side device
The data transmission method for terminals in the RRC inactive state addresses the issue of transmission delay by allowing them to transmit data directly after sending an RRC resume request, thereby reducing delay and saving power.
Patent Information
- Application Number
- JP2025029190
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2020-07-31
- Filing Date
- 2025-02-26
- Publication Date
- 2025-05-27
AI Technical Summary
In communication technologies, terminals in the RRC inactive state face significant transmission delay when needing to transmit data, as they must first perform connection recovery and enter the RRC connected state.
A data transmission method where a terminal in the RRC inactive state transmits data and an RRC resume request message to a base station or centralized unit, and receives an RRC release message, thereby reducing transmission delay and saving power.
This method accelerates data transmission, reduces transmission delay, speeds up the terminal's return to the RRC inactive state, and conserves terminal power.
Smart Images

Figure 2025081674000001_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technologies, and in particular, to a data transmission method, a terminal, and a network-side device.
[0002] (Cross-reference to related applications) This application claims the priority of a Chinese patent application with an application number of 202010757105.7, filed with the Chinese Patent Office on July 31, 2020, and all of its content is incorporated herein by reference.
Background Art
[0003] Currently, in addition to the radio resource control (RRC) idle state and the RRC connected state of a terminal, the RRC inactive state (RRC_inactive) is further included. The RRC inactive state can quickly change the user equipment (UE) to the RRC connected state while saving resources and energy as much as possible, can complete the establishment of a protocol data unit (PDU) session, and can meet the requirements of ultra-reliability and low-latency scenarios.
Summary of the Invention
Problems to be Solved by the Invention
[0004] However, when a terminal in the RRC inactive state needs to transmit data, the terminal first needs to perform connection recovery and enter the RRC connected state to transmit data. This method may increase the transmission delay in a small packet transmission scenario.
[0005] Embodiments of the present disclosure provide a data transmission method, a terminal (UE), and a network-side device to solve the problem of large transmission time delay in the transmission mode of related technologies.
Means for Solving the Problems
[0006] According to a first aspect, 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: transmitting data and an RRC resume request message to a first base station or a centralized unit (CU) of the first base station or a distributed unit (DU) of the first base station; receiving an RRC release message transmitted from the first base station or the CU of the first base station or the DU of the first base station.
[0007] According to a second aspect, 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. The data transmission method includes: receiving data and an RRC resume request message transmitted from a terminal in an RRC inactive state; transmitting an RRC release message to the terminal.
[0008] According to a third aspect, an embodiment of the present disclosure provides a data transmission method for a second base station. The data transmission method includes: receiving a user equipment (UE) context retrieval request message transmitted from a first base station or a centralized unit (CU) of the first base station; transmitting a UE context retrieval failure message to the first base station or the CU of the first base station; transmitting the data to a core network.
[0009] According to a fourth aspect, an embodiment of the present disclosure provides a data transmission method applied to a distributed unit (DU) of a first base station. The data transmission method includes: receiving data and an RRC resume request message transmitted from a terminal in an RRC inactive state; Transmitting the data and the RRC recovery request message to the central unit (CU) of the first base station; Receiving an RRC release message transmitted from the CU of the first base station; Including transmitting the RRC release message to the terminal.
[0010] According to a fifth aspect, an embodiment of the present disclosure provides a terminal in a radio resource control (RRC) inactive state, where the terminal includes: A transmission module configured to transmit data and an RRC recovery request message to a first base station, a central unit (CU) of the first base station, or a distributed unit (DU) of the first base station; A reception module configured to receive an RRC release message transmitted from the first base station, the CU of the first base station, or the DU of the first base station.
[0011] According to a sixth aspect, an embodiment of the present disclosure provides a terminal in a radio resource control (RRC) inactive state, where the terminal includes a processor and a transceiver, The transceiver transmits data and an RRC recovery request message to a first base station, a central unit (CU) of the first base station, or a distributed unit (DU) of the first base station, and receives an RRC release message transmitted from the first base station, the CU of the first base station, or the DU of the first base station.
[0012] According to a seventh aspect, an embodiment of the present disclosure provides a network-side device that is a first base station, a central unit (CU) of the first base station, or a distributed unit (DU) of the first base station, where the network-side device includes: A reception module configured to receive data and an RRC recovery request message transmitted from a terminal in a radio resource control (RRC) inactive state; A transmission module configured to transmit an RRC release message to the terminal.
[0013] According to an eighth aspect, an embodiment of the present disclosure provides a network-side device that is a first base station or a central unit (CU) of the first base station or a distributed unit (DU) of the first base station. The network-side device includes a processor and a transceiver. The transceiver receives data and an RRC resume request message transmitted from a terminal in a radio resource control (RRC) inactive state, and transmits an RRC release message to the terminal.
[0014] According to a ninth aspect, an embodiment of the present disclosure provides a network-side device that is a second base station. The network-side device includes: a first receiving module configured to receive a user equipment (UE) context search request message transmitted from a first base station or a central unit (CU) of the first base station; a first transmitting module configured to transmit a UE context search failure message to the first base station or the CU of the first base station; and a second transmitting module configured to transmit the data to a core network.
[0015] According to a tenth aspect, an embodiment of the present disclosure provides a network-side device that is a second base station. The network-side device includes a processor and a transceiver. The transceiver receives a UE context search request message transmitted from a first base station or a CU of the first base station, transmits a UE context search failure message to the first base station or the CU of the first base station, and transmits the data to the core network.
[0016] According to an eleventh aspect, an embodiment of the present disclosure provides a network-side device that is a DU of a first base station. The network-side device includes: a first receiving module configured to receive data and an RRC resume request message transmitted from a terminal in an RRC inactive state; A first transmission module configured to transmit the data and the RRC recovery request message to a central unit (CU) of a first base station; A second receiving module configured to receive an RRC release message transmitted from the CU of the first base station; A second transmission module configured to transmit the RRC release message to a terminal.
[0017] According to a twelfth aspect, an embodiment of the present disclosure provides a network-side device that is a distributed unit (DU) of a first base station. The network-side device includes a processor and a transceiver. The transceiver receives data and an RRC recovery request message transmitted from a terminal in a radio resource control (RRC) inactive state, transmits the data and the RRC recovery request message to a central unit (CU) of the first base station, receives an RRC release message transmitted from the CU of the first base station, and transmits the RRC release message to the terminal.
[0018] According to a thirteenth aspect, an embodiment of the present disclosure provides a terminal. The terminal includes a processor, a memory, and a computer program stored in the memory and executable by the processor. When the computer program is executed by the processor, the processor is caused to execute the steps in the data transmission method according to the first aspect.
[0019] According to a fourteenth aspect, an embodiment of the present disclosure provides a network-side device. The network-side device includes a processor, a memory, and a computer program stored in the memory and executable by the processor. When the computer program is executed by the processor, the processor is caused to execute the steps in the data transmission method according to the second aspect, or the steps in the data transmission method according to the third aspect, or the steps in the data transmission method according to the fourth aspect.
[0020] According to the 15th aspect, an embodiment of the present disclosure provides a computer-readable storage medium storing a computer program, and when the computer program is executed by the processor, the processor is caused to perform the steps in the data transmission method according to the 1st aspect, or the steps in the data transmission method according to the 2nd aspect, or the steps in the data transmission method according to the 3rd aspect, or the steps in the data transmission method according to the 4th aspect.
Advantages of the Invention
[0021] In an embodiment of the present disclosure, a terminal in the RRC inactive state transmits data and an RRC resume request message to a first base station or a CU of the first base station or a DU of the first base station, and receives an RRC release message transmitted from the first base station or the CU of the first base station or the DU of the first base station. By accelerating the data transmission time, the transmission delay can be reduced, the process of the terminal returning to the RRC inactive state can be speeded up, and the power consumption of the terminal can be saved.
Brief Description of the Drawings
[0022]
Figure 1
Figure 2
Figure 3a
Figure 3b
Figure 4
Figure 5
Figure 6
Figure 7a
Figure 7b
Figure 7c
Figure 7d
Figure 7e
Figure 7f
Figure 7g
Figure 7h
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Embodiments for Carrying Out the Invention
[0023] To more clearly explain the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments were briefly introduced above. Obviously, the above drawings are only some embodiments of the present disclosure. For those skilled in the art, other related drawings can be obtained based on these drawings without creative efforts.
[0024] Hereinafter, the technical solutions in the embodiments of the present application will be described with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present disclosure without creative efforts are included in the protection scope of the present disclosure.
[0025] Referring to FIG. 1, FIG. 1 is a flowchart of a data transmission method according to 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 (S: Step).
[0026] In step 101, data and an RRC recovery request message are transmitted to a first base station or a centralized unit (CU) of the first base station or a distributed unit (DU) of the first base station.
[0027] In a specific embodiment of the present disclosure, the data can be application data of various applications, such as data of instant messaging software, heartbeat packets of applications such as emails, and data of smart wearable devices and sensors. The data and the RRC recovery request message are transmitted 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.
[0028] In the case of a 4-step random access process, the terminal transmits a preamble to the first base station or the CU of the first base station or the DU of the first base station on a Physical Random Access Channel (PRACH) occasion. After detecting the preamble, the first base station or the CU of the first base station or the DU of the first base station transmits a random access response message to the terminal. Here, it is scrambled with a Random Access Radio Network Temporary Identity (RNTI) corresponding to the PRACH occasion for transmitting the preamble.
[0029] The terminal receives the random access response message transmitted from the first base station or the CU of the first base station or the DU of the first base station. When it is determined that the random access response message is the one transmitted to the terminal, for example, when the Random Access preamble identifier (RAPID) matches, the terminal transmits data 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.
[0030] In the case of a 2-step random access process, step 101 includes the terminal transmitting a preamble to the first base station or the CU of the first base station or the DU of the first base station on a PRACH occasion and transmitting data and an RRC recovery request message to the first base station or the CU of the first base station or the DU of the first base station on a Physical Uplink Shared Channel (PUSCH).
[0031] In step 102, an RRC release message transmitted from the first base station or the CU of the first base station or the DU of the first base station is received.
[0032] After the terminal receives the RRC release message, the RRC connection is released, the terminal enters the RRC inactive state, and power consumption of the terminal can be saved.
[0033] In the related art of the 4-step access process, when a terminal in the RRC inactive state needs to transmit data, a plurality of steps shown in FIG. 2 are required. In FIG. 2, the target base station is the first base station or the CU of the first base station or the DU of the first base station.
[0034] In step 111, the terminal transmits a preamble to the target base station.
[0035] In step 112, the terminal receives a random access response message from the target base station.
[0036] In step 113, the terminal transmits an RRC resume request message to the target base station.
[0037] In step 114, the terminal receives an RRC resume message transmitted from the target base station.
[0038] In step 115, the terminal transmits an RRC resume complete message to the target base station.
[0039] In step 116, the terminal transmits data to the target base station.
[0040] Compared with the process of the terminal transmitting data shown in FIG. 2, in the specific embodiment of the present disclosure, the data transmission method does not need to start data transmission after RRC resume is completed, and can transmit data after receiving a random access response message, that is, by advancing the data transmission time, the transmission delay can be reduced. At the same time, compared with the related art, the specific embodiment 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.
[0041] Similarly, even in a two-step random access process, it is possible to save the power consumption of the terminal while reducing the data transmission delay.
[0042] In this embodiment, a terminal in the RRC inactive state transmits data and an RRC recovery request message to a first base station, a CU of the first base station, or a DU of the first base station, and receives an RRC release message transmitted from the first base station, the CU of the first base station, or the DU of the first base station. By advancing the data transmission time, the transmission delay can be reduced, the process of the terminal returning to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
[0043] Furthermore, the RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process.
[0044] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0045] Furthermore, in step 101, before transmitting data and an RRC recovery request message to a first base station, a CU of the first base station, or a DU of the first base station, the data transmission method further includes encapsulating the data directly as a first Media Access Control (MAC) service data unit (SDU) into a first MAC protocol data unit (PDU), or encapsulating a second MAC SDU generated by preprocessing using the data into a second MAC PDU.
[0046] That is, the data is encapsulated into a first MAC PDU or a second MAC PDU. Here, the preprocessing includes at least one of recovery processing of a signaling bearer and a data bearer, encryption processing, and segmentation processing.
[0047] Specifically, after the terminal receives a random access response message sent from the first base station, 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 the one sent to the terminal, for example, when RAPID matches, the terminal transmits the identifier (ID: Identity Document) and uplink data of the terminal on the uplink (UL: Uplink) grant resource.
[0048] At this time, if the terminal has not activated the configurations of the signaling radio bearer (SRB: Signal Radio Bearer), data radio bearer (DRB: Data Radio Bearer), etc., the terminal directly encapsulates the IP (Internet Protocol) data (i.e., data) as the first MAC SDU into the first MAC PDU. Then, MAC sub-header information (i.e., sub-header) is added to the data to form a MAC sub-PDU (i.e., sub-PDU), and then it is placed after the MAC sub-PDU including the CCCH (Common Control Channel) (i.e., RRC recovery request message) or DCCH (Dedicated Control Channel). The sub-header information of the MAC sub-PDU carrying the CCCH or DCCH includes an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0049] Here, the S domain of the first sub-header information (sub-header) indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU includes the following two implementation forms.
[0050] First Embodiment (as indicated by reference sign AA in Fig. 3a): The sub-header information includes a dedicated LCID (Logical Channel Identification) corresponding to the data and DRB ID information corresponding to the data. 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 the data is IP data. The DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Therefore, the base station can accurately place the data in an appropriate GTP-U (User Plane of GPRS Tunneling Protocol) tunnel and then transmit it to the core network.
[0051] Second Embodiment (as indicated by reference sign BB in Fig. 3a): The sub-header includes DRB ID information corresponding to the data. The base station identifies that the data is IP data based on the DRB ID information and knows which bearer of which terminal the data corresponds to, so that the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0052] At this time, if the terminal has not activated configurations such as SRB and DRB, activate the configurations such as SRB and DRB to obtain the second MAC PDU. In this way, as shown in Fig. 3b, process the data according to the normal processing mode such as the PDCP layer and the RLC layer, then generate the second MAC SDU, form a MAC sub-PDU with the second MAC SDU and the MAC sub-header, and place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. In this way, since the bearer is activated, the LCID can use the logical channel ID of normal data, that is, 000001 to 100000.
[0053] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data, or the sub-header information of the second MAC SDU includes logical channel identification information.
[0054] Here, the first MAC SDU includes at least one of logical channel identification information and bearer identification information. Furthermore, the first MAC SDU includes at least bearer identification information. The first MAC SDU corresponds to the case where the terminal has not activated configurations such as SRB and DRB, and since the data bearer has not been activated, it is necessary to indicate the data bearer in the first MAC SDU. Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0055] The second MAC SDU corresponds to the case where the terminal bearer has been activated. When the second MAC SDU is determined by preprocessing and the subsequent second MAC PDU is decapsulated, information such as the data bearer of the data can be obtained. The sub-header information of the second MAC SDU does not include bearer identification information and only needs to include logical channel identification information.
[0056] As shown in FIG. 4, the embodiment of the present disclosure provides a flowchart of a data transmission method. The data transmission method provided by this embodiment is used in a first base station or a CU of the first base station or a DU of the first base station. The data transmission method includes the following steps.
[0057] In step 201, receive data and an RRC recovery request message transmitted from a terminal in the RRC inactive state.
[0058] In the case of a 4-step random access process, the terminal transmits a preamble to the first base station or the CU of the first base station or the DU of the first base station on a Physical Random Access Channel (PRACH) opportunity. After detecting the preamble, the first base station or the CU of the first base station or the DU of the first base station transmits a random access response message to the terminal. Here, it is scrambled with a Random Access (RA) Radio Network Temporary Identity (RNTI) corresponding to the PRACH opportunity for transmitting the preamble.
[0059] The first base station or the CU of the first base station or the DU of the first base station transmits a random access response message to the terminal. When the terminal determines that the random access response message is sent to itself, for example, when the RAPID matches, the terminal transmits data 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.
[0060] In the case of a 2-step random access process, the terminal receives the preamble transmitted on a PRACH opportunity and receives the data and RRC recovery request message transmitted on a PUSCH opportunity.
[0061] In step 202, an RRC release message is transmitted to the terminal.
[0062] In the case of a 4-step random access process, the first base station (hereinafter, the first base station is taken as an example for explanation, and the method applicable 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 transmit an RRC release message carrying a suspend indication to the terminal.
[0063] In the case of a two-step random access process, the first base station can transmit the RRC release message to the terminal carried in the MSG B (message B) message, and the MSG B message may further include a random access response message and RAPID information.
[0064] After the terminal receives the RRC release message, the RRC connection is released, the terminal enters the RRC inactive state, and the power consumption of the terminal can be saved. The RRC release message is also used to indicate that the terminal competition has been successfully resolved.
[0065] Furthermore, after step 202, the first base station or the CU of the first base station or the DU of the first base station transmits the data to the core network to complete the data transmission.
[0066] In this embodiment, the first base station or the CU of the first base station or the DU of the first base station receives the data and the RRC recovery request message transmitted from the terminal in the RRC inactive state, and transmits the RRC release message to the terminal. By accelerating the data transmission time, the transmission delay can be reduced, the process for the terminal to return to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
[0067] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a four-step random access process or an RRC recovery request message carried by MSG A in a two-step random access process.
[0068] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0069] Furthermore, the data 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, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data.
[0070] Here, the preprocessing includes at least one of recovery processing, encryption processing, and segmentation processing of a signaling bearer and a data bearer.
[0071] Specifically, after the terminal receives a random access response message sent from 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 the one sent to the terminal, for example, when RAPID matches, the terminal ID and uplink data are sent using the UL Grant resource. Specifically, there are several solutions as follows.
[0072] At this time, if the terminal has not activated the configurations of SRB, DRB, etc., the terminal directly encapsulates the IP data (i.e., data) as the first MAC SDU into the first MAC PDU.
[0073] The terminal adds MAC sub-header information (i.e., sub-header) to the data to form a MAC sub-PDU (i.e., sub-PDU), and then places it after the MAC sub-PDU including CCCH (i.e., RRC recovery request message) or DCCH. The sub-header information of the MAC sub-PDU carrying CCCH or DCCH includes an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0074] Here, the S domain of the first sub-header information (sub-header) indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU includes the following two implementation forms.
[0075] First Embodiment: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0076] Second Embodiment: The sub-header includes DRB ID information corresponding to the data. The base station identifies that the data is IP data based on the DRB ID information and knows which bearer of which terminal the data corresponds to, so that the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0077] At this time, when the terminal has not activated configurations such as SRB and DRB, activate the configurations such as SRB and DRB to obtain the second MAC PDU. As shown in Figure 3b, process the data according to the normal processing mode such as the PDCP layer and the RLC layer, and then generate the second MAC SDU. Form a MAC sub-PDU with the second MAC SDU and the MAC sub-header, and place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. The LCID uses the logical channel ID of normal data, that is, 000001 to 100000.
[0078] Furthermore, 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, and the bearer identification information is used to indicate the data bearer corresponding to the data, or The sub-header information of the second MAC SDU includes logical channel identification information.
[0079] Here, 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 case where the terminal has not activated configurations such as SRB and DRB, and since the data bearer is not activated, it is necessary to indicate the data bearer in the first MAC SDU. Further, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0080] The second MAC SDU corresponds to the case where the terminal bearer is activated. When the second MAC SDU is determined by pre-processing and the second MAC PDU is subsequently decapsulated, information such as the data bearer of the data can be obtained. The sub-header information of the second MAC SDU does not include bearer identification information but includes logical channel identification information.
[0081] Further, after receiving data and an RRC recovery request message transmitted from a terminal in the radio resource control (RRC) inactive state, the data transmission method further includes transmitting the recovered data to the core network.
[0082] In this embodiment, as described later, the first base station may transmit data to the core network (corresponding to the case where it is necessary to switch the anchor base station, that is, to relocate the UE context), the first base station may transmit data to the second base station, and the second base station may transmit data to the core network (corresponding to the case where it is not necessary to switch the anchor base station, that is, to relocate the UE context).
[0083] Corresponding to the case where it is not necessary to switch the anchor base station, at this time, the first base station transmits the data and the UE context search request message to the second base station together. When it is necessary to switch the anchor base station, transmission processing can be performed based on the recovered terminal context.
[0084] That is, after receiving data and an RRC recovery request message transmitted from a terminal in the radio resource control (RRC) inactive state, the data transmission method transmits a UE context search request message to a second base station, receives a UE context search response message transmitted from the second base station, and further includes transmitting the data to a core network.
[0085] In this embodiment, after receiving data and an RRC recovery request message transmitted from a terminal, the first base station obtains an I-RNTI (Inactive Radio Network Temporary Identifier) and a MAC-I (Message Authentication Code - Integrity) from the RRC recovery request message, obtains the ID information of the second base station, and transmits a UE context request message to the second base station.
[0086] When the UE context search response message is a UE context search failure message, the first base station or the CU of the first base station or the DU of the first base station transmits the data to the second base station, and the second base station transmits the data to the core network.
[0087] When the UE context search response message is a UE context search success message, the first base station or the CU of the first base station or the DU of the first base station directly transmits the data to the core network.
[0088] Specifically, when the UE context search response message is a UE context search success message, transmitting the data to the core network specifically means Obtaining the data from the first MAC PDU or the second MAC PDU transmitted from the terminal based on the normally recovered terminal context, where the first MAC PDU contains a first MAC SDU directly generated by the data, and the second MAC PDU contains a second MAC SDU generated by preprocessing the data, and transmitting the data to the core network.
[0089] Specifically, when the terminal context is normally recovered, obtain DRB ID information and data from the first MAC PDU, or analyze the data corresponding to the LCID from the second MAC PDU to obtain DRB information and PDU session information.
[0090] After obtaining the data, the first base station transmits a path switching request to the core network, receives a path switching request response transmitted by the core network, and the first base station transmits the data to the core network via an appropriate tunnel.
[0091] Furthermore, after receiving the data and the RRC recovery request message transmitted from a terminal in the radio resource control (RRC) inactive state, the data transmission method transmits a UE context search request message to the second base station, where the UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, the data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data, and the second base station determines whether to perform a UE context transition based on the information in the UE context request message, and further includes receiving a UE context search failure message transmitted from the second base station.
[0092] Here, the RRC recovery reason indication includes at least one of an emergency call, a high-priority access, a terminal termination access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call, and a terminal-triggered video call.
[0093] In one embodiment, the UE context search request message may include an RRC recovery reason indication, carry bearer identification information corresponding to the data, and the bearer identification information is used for the second base station to know the DRB ID corresponding to the data so as to transmit the data to the core network via an appropriate tunnel subsequently.
[0094] In another embodiment, the UE context search request message may include an RRC recovery reason indication and / or a data transmission indication.
[0095] After receiving the UE context search failure message, the first base station transmits the data to the second base station, and the second base station transmits the data to the core network. When the first base station transmits the data simultaneously when transmitting the UE context search request message to the second base station, the first base station does not need to transmit the data to the second base station again after receiving the UE context search failure message.
[0096] Furthermore, the data transmission method further includes receiving, from the second base station, data transfer information carried by an address indication message or the UE context search failure message, and transferring the data transmitted from the terminal to the second base station.
[0097] Specifically, when the data transfer information is not carried by the UE context search failure message, after receiving the UE context search failure message transmitted from the second base station, the data transfer information carried by the address indication message is also received from the second base station. When the data transfer information is carried by the UE context search failure message, the first base station obtains the data transfer information via the UE context search failure message.
[0098] The data transfer information may be the transport network layer (TNL) information of the second base station, including Internet Protocol Address (IP) information and Tunnel Endpoint Identifier (TEID) information of the User plane of GPRS Tunneling Protocol (GTP-U). It is used to determine the second base station based on the data transfer information and subsequently transfer data to the second base station.
[0099] Furthermore, the data transmitted from the terminal is at least one of IP data, first MAC PDU data, first MAC SDU data, second MAC PDU data, second MAC SDU data, recovered first RLC SDU, and recovered second RLC SDU.
[0100] In another embodiment, the UE context search response message can carry RLC configuration information and / or transport layer address information.
[0101] Furthermore, the first base station or the CU of the first base station recovers the RLC SDU or PDCP PDU and transmits the recovered data to the first base station or the CU of the first base station. The first base station or the CU of the first base station recovers the data transmitted from the terminal and transmits the data to the core network.
[0102] As shown in FIG. 5, FIG. 5 is yet another flowchart of the data transmission method according to an embodiment of the present disclosure. The data transmission method provided by this embodiment is used for the second base station, and the data transmission method includes the following steps.
[0103] In step 301, receive a UE context search request message transmitted from the first base station or the CU of the first base station.
[0104] In step 302, send a UE context search failure message to the first base station or the CU of the first base station.
[0105] In step 303, send the data to the core network.
[0106] Here, the UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data.
[0107] The second base station determines whether to perform a UE context transition based on the information in the UE context request message.
[0108] In one embodiment, the UE context search request message may include an RRC recovery reason indication, carry bearer identification information corresponding to the data, and the bearer identification information is used for the second base station to know the DRB ID corresponding to the data so as to transmit the data to the core network via an appropriate tunnel subsequently.
[0109] In another embodiment, the UE context search request message may include an RRC recovery reason indication and / or a data transmission indication.
[0110] The second base station can know that the RRC recovery reason is data transmission, IP data, and DRB ID information based on the UE context search request message. Specifically, IP data and DRB ID information can be obtained in the following two ways.
[0111] The first method: Obtain DRB ID or PDU session ID information from the UE context search request message, and obtain IP data from the data plane between the second base station and the first base station.
[0112] Second method: Obtain DRB or PDU session ID information corresponding to the LCID from the MAC PDU analysis transmitted from the second base station, and obtain IP data through analysis.
[0113] When the second base station can obtain the data transmitted from the terminal based on the UE context search request message, the data can be transmitted to the core network. When the second base station cannot obtain the data transmitted from the terminal based on the UE context search request message, it is necessary to receive the data transmitted from the first base station or the CU of the first base station, and then transmit the data to the core network.
[0114] The UE context search failure message may carry the TNL layer information of the second base station including the IP address information and the GTP-U TEID information, and the TNL layer information of the second base station can also be notified using the subsequent data transfer information. The TNL layer information of the second base station is used for the access base station to transfer data to the second base station.
[0115] In another embodiment, the UE context search failure message can carry the RLC configuration information and / or the transport layer address information.
[0116] Furthermore, the first base station or the CU of the first base station recovers the RLC SDU or the PDCP PDU, and transmits the recovered data to the first base station or the CU of the first base station. The first base station or the CU of the first base station recovers the data transmitted from the terminal and transmits the data to the core network.
[0117] In another embodiment, after receiving the UE context search response message, the first base station also receives the RLC configuration information and / or the transport layer address information transmitted from the second base station.
[0118] Furthermore, the first base station or the CU of the first base station recovers the RLC SDU or PDCP PDU, transmits the recovered 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 recovers the data transmitted from the terminal and transmits the data to the core network.
[0119] In this embodiment, after the second base station transmits the UE context search failure message to the first base station or the CU of the first base station, the second base station transmits the data to the core network, that is, when not switching the anchor base station, by transmitting the data to the core network, the data transmission efficiency can be improved and the data transmission delay can be reduced.
[0120] Furthermore, the UE context search failure message carries data transfer information, and the data transmission method further includes receiving, by the first base station or the CU of the first base station, the data transmitted based on the data transfer information.
[0121] The data transfer information can be carried in the UE context search failure message, and the data transfer information can be the TNL layer information of the second base station including IP address information and GTP-U TEID information. The second base station is determined based on the data transfer information and is subsequently used by the first base station or the CU of the first base station to transfer data to the second base station based on the data transfer information.
[0122] Furthermore, the data transfer information is not carried in the UE context search failure message, but the second base station carries the data transfer information via an address indication message. The second base station transmits the address indication message to the first base station or the CU of the first base station, and subsequently, the first base station or the CU of the first base station transfers the data to the second base station based on the data transfer information.
[0123] That is, the data transmission method includes transmitting an address indication message carrying the data transfer information to the first base station or the CU of the first base station, and Further including receiving, by the first base station or the CU of the first base station, the data transmitted based on the data transfer information.
[0124] As shown in FIG. 6, an embodiment of the present disclosure provides another flowchart of a data transmission method. The data transmission method provided by this embodiment is used in the distributed unit (DU) of the first base station. The data transmission method includes the following steps.
[0125] In step 401, receive data and an RRC recovery request message transmitted from a terminal in the RRC inactive state.
[0126] In the case of a 4-step random access process, receive the preamble transmitted by the terminal in the PRACH opportunity. After detecting the preamble, transmit a random access response message to the terminal and scramble it using the RA-RNTI corresponding to the PRACH opportunity where the preamble is transmitted.
[0127] In the case of a 2-step random access process, receive the preamble transmitted by the terminal in the PRACH opportunity, and receive the data and the RRC recovery request message transmitted by the terminal in the PUSCH opportunity.
[0128] In step 402, transmit the data and the RRC recovery request message to the central unit (CU) of the first base station.
[0129] In step 403, receive an RRC release message transmitted from the CU of the first base station.
[0130] In the case of a 4-step random access process, the CU of the first base station transmits an RRC release message carrying a suspend indication to the terminal.
[0131] In the case of a 2-step random access process, the CU of the first base station can carry the RRC release message in the MSG B message.
[0132] In step 404, the RRC release message is sent to the terminal.
[0133] The DU of the first base station sends the RRC release message to the terminal. After the terminal receives the RRC release message, the RRC connection is released, the terminal enters the RRC inactive state, and the power consumption of the terminal can be saved. The RRC release message is also used to indicate the successful resolution of terminal contention.
[0134] In this embodiment, the DU of the first base station receives the data and the RRC recovery request message sent from the terminal in the RRC inactive state, sends the data and the RRC recovery request message to the centralized unit (CU) of the first base station, receives the RRC release message sent from the CU of the first base station, and sends the RRC release message to the terminal. By shortening the data transmission time, the transmission delay can be reduced, the process of the terminal returning to the RRC inactive state can be accelerated, and the power consumption of the terminal can be saved.
[0135] Furthermore, the RRC recovery request message is the RRC recovery request message in the 4-step random access process or the RRC recovery request message carried by MSG A in the 2-step random access process.
[0136] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0137] Furthermore, the data is encapsulated in a first MAC PDU or a second MAC PDU. The first MAC PDU contains a first MAC SDU directly generated by the data, and the second MAC PDU contains a second MAC SDU generated by preprocessing the data.
[0138] Here, the preprocessing includes at least one of recovery processing of signaling bearers and data bearers, encryption processing, and segmentation processing.
[0139] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data. Or The sub-header information of the second MAC SDU includes logical channel identification information.
[0140] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0141] Specifically, the same content as described in the embodiment shown in FIG. 1 above can be referred to the description in the embodiment shown in FIG. 1, and will not be repeatedly described here.
[0142] Furthermore, transmitting the data and the RRC recovery request message to the central unit (CU) of the first base station includes transmitting the data to the CU via an initial RRC transition message or via a user plane interface between the CU and the distributed unit (DU).
[0143] Furthermore, transmitting the data to the CU via a user plane interface between the CU and the DU includes receiving a UE context establishment request message transmitted from the CU and carrying transmission network layer information, and transmitting the data to the CU based on the transmission network layer information.
[0144] 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 to the CU based on the transmission network layer information. Specifically, the DU can send a UE context establishment response message and data to the CU.
[0145] Furthermore, the data transmission method further includes receiving BSR information sent from a terminal and sending the BSR information to the CU of the first base station.
[0146] The DU of the first base station receives buffer status report (BSR) information sent from a terminal, and the BSR information is used to notify the buffer status of the terminal.
[0147] The following provides several scenarios for explaining the process of the data transmission method provided by the present disclosure. In FIGS. 7a to 7d, the target base station can be understood as the first base station or the DU of the first base station or the CU of the first base station, the anchor base station can be understood as the second base station, and the core network can be an access and mobility management function (AMF) network element or a user plane function (UPF) network element.
[0148] Scenario 1 shown in FIG. 7a: Transmit data based on a 4-step RACH, and the anchor base station does not change.
[0149] Here, in step 10, the terminal is in the RRC inactive state (i.e., the RRC_inactive state).
[0150] In step 11, the terminal has uplink packet data that needs to be transmitted and sends a preamble to the base station in a PRACH opportunity.
[0151] In step 12, the base station detects the preamble, and mainly transmits a random access response including information such as TA, UL grant, and RAPID to the terminal, and scrambles it using the RA-RNTI corresponding to the PRACH opportunity for transmitting the preamble.
[0152] In step 13, when the terminal confirms that the random access response is for itself, that is, when the RAPID matches, the terminal transmits its ID and uplink data on the UL Grant. Specifically, there are several solutions as follows.
[0153] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as the MAC SDU into the MAC PDU and transmits it. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU including the CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH includes an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0154] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU, and the sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0155] Situation 1: The header information (i.e., sub-header information) includes the dedicated LCID corresponding to the data and the DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in the appropriate GTP-U tunnel and then transmit it to the core network.
[0156] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thus, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0157] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB. In this way, as shown in Figure 3b, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. Since the bearer is activated in this way, the LCID can use the logical channel ID of normal data, that is, 000001 to 100000.
[0158] In step 14, after the access base station (i.e., the target base station) receives the data and the connection recovery request message sent by the terminal, obtain the I-RNTI and MAC-I from the connection recovery request message, obtain the ID information of the anchor base station, and send a terminal context acquisition request message (i.e., a UE context search request message) to the anchor base station. The content of the message has the following several situations.
[0159] Situation 1: The RRC recovery reason sent by the access base station in the terminal context acquisition request message is data transmission, and it also carries the DRB ID corresponding to the data. The DRB ID is used by the anchor base station to know the DRB ID corresponding to the data so as to transmit the data to the core network through an appropriate tunnel subsequently.
[0160] Situation 2: The RRC recovery reason sent by the access base station in the terminal context acquisition request message is for data transmission and / or sending the MAC sub-PDU information to the anchor base station.
[0161] In step 15, the anchor base station is aware that the connection recovery request reason (i.e., the RRC recovery reason) is for data transmission, obtains the IP data and DRB ID information, and sends a terminal context acquisition failure message (i.e., a UE context search failure message) to the access base station. This message may carry the TNL layer information of the anchor base station including the IP address information and the GTP-U TEID information. Subsequently, in step 15’, the access base station may send the TNL indication information for transferring data to the anchor base station to notify the access base station of the TNL information of the anchor base station.
[0162] Specifically, there are the following two situations for the method of obtaining the IP data and DRB information.
[0163] Situation 1: Obtain the DRB ID or PDU session ID information from the terminal context acquisition request message, obtain the data from the data plane between the anchor base station and the access base station, and send the data to the core network.
[0164] Situation 2: Obtain the DRB or PDU session ID information corresponding to the LCID from the MAC PDU analysis sent by the access base station, obtain the data from the analysis, and send the data to the core network.
[0165] In step 16, the access base station sends an RRC release message carrying a suspend indication to the terminal, and the terminal enters the RRC inactive state. This RRC release message is also used to indicate the successful resolution of the terminal contention.
[0166] Scenario 2 shown in Figure 7b: Transmit data based on a 4-step RACH, and the anchor base station switches.
[0167] In step 20, the terminal is in the RRC_inactive state.
[0168] In step 21, the terminal has uplink packet data to be transmitted and sends a preamble to the base station in a PRACH opportunity.
[0169] In step 22, the base station detects the preamble and sends a random access response containing information such as TA, UL grant, and RAPID to the terminal, and scrambles it using the RA-RNTI corresponding to the PRACH opportunity where the preamble is sent.
[0170] In step 23, when the terminal confirms that the random access response is for itself, that is, when the RAPID matches, it sends the terminal ID and uplink data on the UL Grant. Specifically, there are several solutions as follows.
[0171] Solution 1: If the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as a MAC SDU into a MAC PDU and transmits it. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU including CCCH (RRC resume request message) or DCCH, and the sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0172] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU, and the sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0173] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0174] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0175] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. As shown in Figure 3b, the LCID in the figure uses the logical channel IDs of normal data, i.e., 000001 to 100000.
[0176] In step 24, after receiving the data and the connection recovery request message sent from the terminal, the access base station obtains the I-RNTI and MAC-I from the connection recovery request message, acquires the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station.
[0177] In step 25, receive the terminal context request response message sent from the anchor base station. If the terminal context is successfully restored, obtain the DRB ID information and data from the MAC sub-PDU, or analyze the data corresponding to the LCID from the MAC PDU to obtain the DRB information and PDU session information.
[0178] In step 26, the access base station sends a path switch request to the core network.
[0179] In step 27, receive the path switch request response sent from the core network.
[0180] In step 28, the access base station sends data to the core network via an appropriate tunnel.
[0181] In step 29, the access base station sends a terminal context release message to the anchor base station.
[0182] Scenario 3:2 steps shown in Figure 7c: Transmit data based on the RACH, and the anchor base station does not switch.
[0183] In step 30, the terminal is in the RRC_inactive state.
[0184] In step 31, the terminal has uplink packet data that needs to be transmitted, sends a preamble to the base station in the PRACH opportunity, and sends an RRC recovery request and data in the PUSCH opportunity. Specifically, there are several solutions as follows.
[0185] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as a MAC SDU into a MAC PDU for transmission. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0186] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU, and the sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0187] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data into an appropriate GTP-U tunnel and then send it to the core network.
[0188] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data into an appropriate GTP-U tunnel and then send it to the core network.
[0189] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU that carries CCCH or DCCH. As shown in Figure 3b, the LCIDs in the figure use the logical channel IDs of normal data, that is, 000001 to 100000.
[0190] In step 32, the access base station detects the preamble and successfully demodulates the MAC PDU information carried by the PUSCH.
[0191] After receiving the data and the connection recovery request message (i.e., the RRC recovery request message) sent from the terminal, the access base station obtains the I-RNTI and the MAC-I from the connection recovery request message, acquires the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station. The content of the message has the following several situations.
[0192] Situation 1: The RRC recovery reason sent by the access base station in the terminal context acquisition request message is data transmission, and it also carries the DRB ID corresponding to the data. The DRB ID is used for the anchor base station to know the DRB ID corresponding to the data so as to send the data to the core network through an appropriate tunnel subsequently.
[0193] Situation 2: The RRC recovery reason sent by the access base station in the terminal context acquisition request message is data transmission and / or sending the MAC sub-PDU information to the anchor base station.
[0194] In step 33, the anchor base station acknowledges that the reason for the connection recovery request is data transmission, obtains the IP data and DRB ID information, sends a terminal context acquisition failure message to the access base station, and this message may carry the TNL layer information of the anchor base station including the IP address information and GTP-U TEID information. Subsequently, in step 33', the access base station may send the TNL indication information for transferring data to the anchor base station to notify the access base station of the TNL information of the anchor base station.
[0195] Specifically, the method for obtaining the IP data and DRB information includes obtaining the DRB ID or PDU session ID information from the terminal context acquisition request message, obtaining data from the data plane between the anchor base station and the access base station, and sending the data to the core network. Or, obtaining the DRB or PDU session ID information corresponding to the LCID from the MAC PDU analysis sent by the access base station, obtaining data from the analysis, and sending the data to the core network.
[0196] In step 34, the access base station sends a MSG B message to the terminal, which may include a random access success response message, RRC release information, and RAPID information, etc.
[0197] Furthermore, when the terminal receives a random access success response message and the terminal ID and RAPID correspond to itself, the data transmission is considered successful; otherwise, continue to attempt random access.
[0198] Scenario 4:2 step RACH shown in Figure 7d: Transmit data based on the RACH, and the anchor base station switches.
[0199] In step 40, the terminal is in the RRC_inactive state.
[0200] In step 41, if the terminal has uplink packet data that needs to be transmitted, it sends a preamble to the base station during the PRACH opportunity and transmits an RRC recovery request and data during the PUSCH opportunity. Specifically, there are several solutions as follows.
[0201] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as a MAC SDU into a MAC PDU for transmission. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places 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 an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0202] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0203] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data into an appropriate GTP-U tunnel and then transmit it to the core network.
[0204] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0205] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. As shown in Figure 3b, the LCIDs in the figure use the logical channel IDs of normal data, i.e., 000001 to 100000.
[0206] In step 42, after receiving the data and the connection recovery request message sent from the terminal, the access base station obtains the I-RNTI and MAC-I from the connection recovery request message, acquires the ID information of the anchor base station, and sends a terminal context acquisition request message to the anchor base station.
[0207] In step 43, receive the terminal context request response message sent from the anchor base station. When the terminal context is successfully recovered, obtain the DRB ID information and the data from the MAC sub-PDU, or analyze the data corresponding to the LCID from the MAC PDU to obtain the DRB information and the PDU session information.
[0208] In step 44, the access base station sends a path switching request to the core network.
[0209] In step 45, receive the path switching request response sent from the core network.
[0210] In step 46, the access base station transmits data to the core network via an appropriate tunnel.
[0211] In step 47, the access base station transmits a MSG B message that may include a random access success response message, an RRC release message, and RAPID information, etc., to the terminal.
[0212] Furthermore, if the terminal receives a random access success response message and the terminal ID and RAPID correspond to itself, it is considered that the data transmission is successful; otherwise, continue to attempt random access.
[0213] The first base station is divided into the CU of the first base station and the DU of the first base station. For the information interaction between the CU and the DU, FIG. 7e shows the description of the steps performed by taking as an example the case where data is transmitted based on a 4-step RACH and the anchor base station is not switched. This process is similarly applicable to the scenario of switching the anchor base station in a 4-step RACH, the scenario of switching the anchor base station in a 2-step RACH, and the scenario of not switching the anchor base station in a 2-step RACH.
[0214] FIG. 7e shows a scenario where the CU-DU framework transmits data based on a 4-step RACH and the anchor base station is switched.
[0215] In step 50, the terminal is in the RRC inactive state.
[0216] In step 51, the terminal has uplink packet data that needs to be transmitted and transmits a preamble to the DU in the PRACH opportunity.
[0217] In step 52, the DU detects the preamble, and mainly transmits a random access response including information such as TA, UL grant, and RAPID to the terminal, and scrambles it using the RA-RNTI corresponding to the PRACH opportunity for transmitting the preamble.
[0218] In step 53, when the terminal confirms that the random access response is for itself, that is, when the RAPID matches, the terminal transmits its ID and uplink data on the UL Grant. Specifically, there are several solutions as follows.
[0219] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as the MAC SDU into the MAC PDU for transmission. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU including CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying CCCH or DCCH includes an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0220] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0221] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in the appropriate GTP-U tunnel and then transmit it to the core network.
[0222] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0223] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying the CCCH or DCCH. As shown in Figure 3b, the LCID in the figure uses the logical channel IDs of normal data, i.e., 000001 to 100000.
[0224] In step 54, after the access base station DU receives the data and the connection recovery request message sent by the terminal, it sends the connection recovery request message to the CU, and optionally, sends the data to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station.
[0225] In step 55, the CU sends a terminal context acquisition request message to the anchor base station.
[0226] In step 56, the CU receives the terminal context request response message sent by the anchor base station. When the terminal context is successfully recovered, obtain the DRB ID information and the data from the MAC sub-PDU, or analyze the data corresponding to the LCID from the MAC PDU to obtain the DRB information and the PDU session information.
[0227] In step 57, the access base station CU sends a UE context establishment request carrying transmission network layer address information to the DU.
[0228] In step 58, the DU sends a UE context establishment response message to the CU.
[0229] In step 58’, optionally, the DU sends the data to the CU based on the transmission network layer address information.
[0230] In step 59, the CU sends a path switching request to the core network.
[0231] In step 59’, the CU sends an RRC release message to the DU.
[0232] In step 510’, the DU sends an RRC release message to the terminal.
[0233] In step 510, the CU receives a path switching request response sent from the core network.
[0234] In step 511, the CU sends data to the core network via an appropriate tunnel.
[0235] In step 512, the CU sends a terminal context release message to the anchor base station.
[0236] Figure 7f shows a scenario where the CU-DU framework transmits data based on a 4-step RACH and the anchor base station does not change.
[0237] In step 60, the terminal is in the RRC inactive state.
[0238] In step 61, the terminal has uplink packet data to transmit and sends a preamble to the DU in a PRACH opportunity.
[0239] In step 62, DU detects the preamble and mainly transmits a random access response containing information such as TA, UL grant, and RAPID to the terminal, and scrambles it using the RA-RNTI corresponding to the PRACH opportunity for transmitting the preamble.
[0240] In step 63, when the terminal confirms that the random access response is for itself, that is, when the RAPID matches, the terminal transmits the terminal ID and uplink data on the UL Grant. Specifically, there are several solutions as follows.
[0241] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as the MAC SDU into the MAC PDU and transmits it. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU including CCCH (RRC recovery request message) or DCCH, and the sub-header of the MAC sub-PDU carrying CCCH or DCCH includes an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0242] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU, and the sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0243] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in the appropriate GTP-U tunnel and then transmit it to the core network.
[0244] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0245] Solution 2: When the terminal needs to transmit uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying CCCH or DCCH. As shown in Figure 3b, in this case, the LCID may use the logical channel ID of normal data, i.e., 000001 to 100000.
[0246] In step 64, after the access base station DU receives the data and the connection recovery request message transmitted from the terminal, it transmits the connection recovery request message to the CU, and optionally, transmits the data to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station.
[0247] In step 65, the CU transmits a terminal context acquisition request message to the anchor base station.
[0248] In step 66, the CU receives the terminal context request response message sent from the anchor base station. The context request response message is a terminal context acquisition failure message, which may carry the TNL layer information of the anchor base station including IP address information and GTP-U TEID information. In subsequent steps, the access base station may send the TNL indication information for transferring data to the anchor base station to notify the access base station of the TNL information of the anchor base station.
[0249] In step 67, the CU sends a UE context establishment request carrying the transmission network layer address information to the DU.
[0250] In step 68, the DU sends a UE context establishment response message to the CU.
[0251] In step 68’, optionally, the DU sends the data to the CU based on the transmission network layer address information.
[0252] In step 69’, the CU sends an RRC release message to the DU.
[0253] In step 610’, the DU sends an RRC release message to the terminal.
[0254] In step 610, the CU sends the data to the anchor base station.
[0255] In step 611, the anchor base station data is sent to the core network.
[0256] In step 612, the CU sends a terminal context release message to the anchor base station.
[0257] Figure 7f shows a scenario where the CU-DU framework transmits data based on a two-step RACH and the anchor base station does not switch.
[0258] In step 70, the terminal is in the RRC_inactive state.
[0259] In step 71, the terminal has uplink packet data that needs to be transmitted. It sends a preamble to the base station on a PRACH opportunity and transmits an RRC resume request and data on a PUSCH opportunity. Specifically, there are several solutions as follows.
[0260] Solution 1: When the terminal has not activated the configurations of SRB, DRB, etc., the terminal directly encapsulates the IP data as a MAC SDU into a MAC PDU and transmits it. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, places it after the MAC sub-PDU containing the CCCH (RRC resume request message) or DCCH, and the sub-header of the MAC sub-PDU carrying the CCCH or DCCH contains an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0261] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0262] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0263] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data in an appropriate GTP-U tunnel and then transmit it to the core network.
[0264] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes such as the PDCP layer and the RLC layer to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place it after the MAC sub-PDU that carries the CCCH or DCCH. As shown in Figure 3b, the LCID in the figure uses the logical channel ID of normal data, that is, 000001 to 100000.
[0265] In step 72, after the DU receives the data and the connection recovery request message sent from the terminal, it sends the connection recovery request message to the CU, and optionally sends the data to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station. The CU sends a terminal context acquisition request message to the anchor base station.
[0266] In step 73, the CU receives the terminal context request response message sent from the anchor base station, and the context request response message is a terminal context acquisition failure message. When the terminal context is successfully recovered, obtain the DRB ID information and the data from the MAC sub-PDU, or analyze the data corresponding to the LCID from the MAC PDU to obtain the DRB information and the PDU session information.
[0267] In step 74, the CU sends a UE context establishment request carrying transmission network layer address information to the DU.
[0268] In step 75, the DU sends a UE context establishment response message to the CU.
[0269] In step 75’, optionally, the DU sends the data to the CU based on the transmission network layer address information.
[0270] In step 76’, the CU sends an RRC release message to the DU.
[0271] In step 77’, the DU sends an RRC release message to the terminal.
[0272] In step 76, the CU sends data to the anchor base station.
[0273] In step 77, the anchor base station sends the data to the core network.
[0274] In step 78, the CU sends a terminal context release message to the anchor base station.
[0275] Figure 7f shows a scenario where the CU-DU framework transmits data based on a two-step RACH and the anchor base station switches.
[0276] In step 80, the terminal is in the RRC_inactive state.
[0277] In step 81, the terminal has uplink packet data that needs to be transmitted, sends a preamble to the base station in a PRACH opportunity, and transmits an RRC resume request and data in a PUSCH opportunity. Specifically, there are several solutions as follows.
[0278] Solution 1: When the terminal has not activated the configurations such as SRB and DRB, the terminal directly encapsulates the IP data as a MAC SDU into a MAC PDU for transmission. The terminal adds a MAC sub-header to the data to form a MAC sub-PDU, and places it after the MAC sub-PDU containing CCCH (RRC recovery request message) or DCCH. The sub-header of the MAC sub-PDU carrying CCCH or DCCH contains an indication of whether another MAC PDU is also included. The specific MAC PDU is as shown in Figure 3a.
[0279] Here, the S domain of the first sub-header indicates whether there is a subsequent MAC sub-PDU. The sub-header of the second MAC sub-PDU specifically includes the following two situations.
[0280] Situation 1: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data into an appropriate GTP-U tunnel and then send it to the core network.
[0281] Situation 2: The header information (i.e., sub-header information) includes a dedicated LCID corresponding to the data and DRB ID information corresponding to the data. The dedicated LCID is used by the base station to identify that the data is IP data, and the DRB ID information is used by the base station to know which bearer of the terminal the data corresponds to. Thereby, the base station can accurately place the data into an appropriate GTP-U tunnel and then send it to the core network.
[0282] Solution 2: When the terminal needs to send uplink packets, first activate the configurations such as SRB and DRB, process the data according to the normal processing modes of the PDCP layer and the RLC layer, etc., to generate a MAC SDU, form a MAC sub-PDU with the MAC SDU and the MAC sub-header, and then place the MAC sub-PDU after the MAC sub-PDU carrying CCCH or DCCH. As shown in Figure 3b, the LCID in the figure uses the logical channel IDs of normal data, that is, 000001 to 100000.
[0283] In step 82, after the DU receives the data and the connection recovery request message sent from the terminal, it sends the connection recovery request message to the CU, and optionally sends the data to the CU. The CU obtains the I-RNTI and MAC-I from the connection recovery message and obtains the ID information of the anchor base station. The CU sends a terminal context acquisition request message to the anchor base station.
[0284] In step 83, the CU receives the terminal context request response message sent from the anchor base station.
[0285] In step 84, the CU sends a UE context establishment request carrying the transport network layer address information to the DU.
[0286] In step 85, the DU sends a UE context establishment response message to the CU.
[0287] In step 85’, optionally, the DU sends the data to the CU based on the transport network layer address information.
[0288] In step 86, the CU sends a path switching request to the core network.
[0289] In step 86’, the CU sends an RRC release message to the DU.
[0290] In step 87, receive a path switching request response sent from the core network.
[0291] In step 88, the CU transmits data to the core network via an appropriate tunnel.
[0292] In step 89, the CU transmits a terminal context release message to the anchor base station.
[0293] In the above embodiment, the target base station receives data transmitted by the terminal random access process, and when the anchor base station switches or does not switch, transmits the data to the core network. When the anchor base station does not switch, the target base station and the anchor base station exchange information such as data, DRB ID, and anchor base station TNL. The target base station transmits the data to the anchor base station, and the anchor base station transmits the data to the core network. When the anchor base station switches, the target base station acquires the terminal context, restores the terminal context, acquires the data, and transmits the data to the core network after the path is switched.
[0294] The above embodiment can use a two-step random access process or a four-step random access process to transmit small data, and in a scenario where the RRC connection is not restored and the anchor base station may or may not switch, data transmission can be performed, thereby solving the disadvantages in the prior art that the transmission of small data requires first restoring the RRC connection and switching the anchor base station, resulting in a large data transmission delay and low efficiency.
[0295] FIG. 8 is a schematic structural diagram of a terminal according to 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 is A first transmission module 601 configured to transmit data and an RRC recovery request message to a first base station or a central unit (CU) of the first base station or a distributed unit (DU) of the first base station; A first reception module 602 configured to receive an RRC release message transmitted from the first base station or the CU of the first base station or the DU of the first base station.
[0296] Furthermore, the RRC recovery request message is an RRC recovery request message in a 4-step random access process or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0297] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0298] Furthermore, the terminal 600 is further configured to directly encapsulate the data as a first media access control (MAC) service data unit (SDU) into a first MAC protocol data unit (PDU), or comprises an encapsulation template configured to encapsulate a second MAC SDU generated by preprocessing using the data into a second MAC PDU.
[0299] Furthermore, the preprocessing includes at least one of recovery processing of a signaling bearer and a data bearer, encryption processing, and segmentation processing.
[0300] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data. or The sub-header information of the second MAC SDU includes logical channel identification information.
[0301] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0302] The terminal 600 can perform each process implemented by the terminal in the embodiment of the method shown in FIG. 1, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0303] FIG. 9 is a schematic structural diagram for implementing each embodiment of the present disclosure. The terminal 800 includes components such as a transceiver unit (i.e., a transceiver) 801, a network module 802, an audio output unit 803, an input unit 804, a sensor 805, a display unit 806, a user input unit 807, an interface unit 808, a memory 809, a processor 810, and a power supply 811, but is not limited thereto. Those skilled in the art can understand that the terminal structure shown in FIG. 9 does not constitute a limitation to the terminal, and the terminal can include more or fewer components than shown in the figure, or combine some components, or arrange different components. In the embodiments of the present disclosure, the terminal includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm-top computer, an in-vehicle terminal, a wearable device, and a pedometer.
[0304] Here, in one embodiment of the present disclosure, the transceiver unit 801 is configured to transmit data and an RRC recovery request message to a first base station or a central unit (CU) of the first base station or a distributed unit (DU) of the first base station, and receive an RRC release message transmitted from the first base station or the CU of the first base station or the DU of the first base station.
[0305] Furthermore, the RRC recovery request message is an RRC recovery request message in a 4-step random access process, or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0306] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0307] Furthermore, the processor 810 either directly encapsulates the data as a first Media Access Control (MAC) service data unit (SDU) into a first MAC protocol data unit (PDU), or is configured to encapsulate a second MAC SDU generated by preprocessing using the data into a second MAC PDU.
[0308] Furthermore, the preprocessing includes at least one of a recovery process for a signaling bearer and a data bearer, an encryption process, and a segmentation process.
[0309] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data. or the sub-header information of the second MAC SDU includes logical channel identification information.
[0310] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0311] The terminal 800 can perform each process implemented by the terminal in the embodiment of the method shown in FIG. 1, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0312] It should be understood that in the embodiments of the present disclosure, the transceiver unit 801 can be used to receive and transmit signals during information transmission / reception or a call. Specifically, after receiving downlink data from a base station, it is processed by the processor 810, and uplink data is also transmitted to the base station. Usually, the transceiver unit 801 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Also, the transceiver unit 801 can communicate with a network and other devices via a wireless communication system.
[0313] The terminal provides wireless broadband Internet access to the user via the network module 802, for example, assisting in sending and receiving emails, browsing web pages, accessing streaming media, etc.
[0314] The audio output unit 803 can convert audio data received by the transceiver unit 801 or the network module 802 or stored in the memory 809 into an audio signal and output it as sound. Also, the audio output unit 803 can provide audio output related to specific functions executed by the terminal 800 (for example, call signal reception sound, message reception sound, etc.). The audio output unit 803 includes a speaker, a buzzer, a receiver, etc.
[0315] The input unit 804 is used to receive audio or video signals. The input unit 804 may include a graphics processing unit (GPU) 8041 and a microphone 8042. The graphics processing unit 8041 processes still image or video image data acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frame can be displayed on the display unit 806. The image frame processed by the graphics processing unit 8041 may be stored in the memory 809 (or other storage media), or may be transmitted via the transceiver unit 801 or the network module 802. The microphone 8042 can receive sound and process such sound into audio data. The processed audio data can be output after being converted into a format that can be transmitted to a mobile communication base station via the transceiver unit 801 in call mode.
[0316] The terminal 800 further includes at least one sensor 805 such as an optical sensor, a motion sensor, and other sensors. Specifically, the optical sensor includes an ambient light sensor and a proximity sensor. Here, the ambient light sensor can adjust the brightness of the display panel 8061 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 8061 and / or the backlight when the terminal 800 moves close to the ear. An accelerometer sensor, which is a type of motion sensor, detects the magnitude of acceleration in each direction (generally three axes), detects the magnitude and direction of gravity at rest, and can be used for terminal posture (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tap), etc. The sensor 805 may include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc.
[0317] 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), an organic light-emitting diode (OLED), or the like.
[0318] The user input unit 807 is used to receive input numbers or character information and generate key signal inputs related to user settings and function control of the terminal. Specifically, the user input unit 807 includes a touch panel 8071 and other input devices 8072. The touch panel 8071, also called a touch screen, can collect the user's touch operations on or near it (for example, the user's operations on or near the touch panel 8071 using any suitable object or accessory such as a finger or a stylus). The touch panel 807 may include two parts: a touch detection device and a touch controller. Here, the touch detection device detects the user's touch direction, detects the signal brought about by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into contact coordinates, and transmits it to the processor 810, and receives and executes the command transmitted by the processor 810. Also, the touch panel 8071 can be implemented in various types such as resistive, capacitive, infrared, surface acoustic wave, etc. In addition to the touch panel 8071, the user input unit 807 may also include other input devices 8072. Specifically, the other input devices 8072 include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, and will not be repeatedly described here.
[0319] Furthermore, the touch panel 8071 may be covered on the display panel 8061. When the touch panel 8071 detects a touch operation thereon or in its vicinity, the touch operation is transmitted to the processor 810 to determine the type of touch event. Next, the processor 810 provides a visual output corresponding to the display panel 8061 based on the type of touch event. In FIG. 8, the touch panel 8071 and the display panel 8061 are used as two independent components for realizing the input and output functions of the terminal. However, in some embodiments, the touch panel 8071 may be integrated with the display panel 8061 to implement the input and output functions of the terminal, and the details are not limited herein.
[0320] The interface unit 808 is an interface for connecting an external device to the terminal 800. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having a recognition module, an audio input / output (I / O) port, a video I / O port, a headphone port, and the like. The interface unit 808 may be used to receive an input (such as data information, power, etc.) from the external device and transmit the received input to one or more components within the terminal 800, or may be used to interface the transmission data therebetween.
[0321] The memory 809 can be used to store software programs and various data. The memory 809 may mainly include a program storage area and a data storage area. Here, the program storage area can store an operating system, application programs required for at least one function (such as a voice playback function, an image playback function, etc.), and the data storage area can store data created according to the use of the mobile phone (such as audio data, phone book, etc.). Also, the memory 809 may include a high-speed random access memory and may also include a non-volatile memory such as at least one magnetic disk storage device, a flash memory device, or other volatile solid storage devices.
[0322] The processor 810 is the control center of the terminal. It connects each part of the entire terminal using various interfaces and lines, operates or executes the software programs and / or modules stored in the memory 809, and calls the data stored in the memory 809 to execute various functions and processing data of the terminal, thereby monitoring the entire terminal. The processor 810 may include one or more processing units. Exemplarily, the processor 810 can integrate an application processor and a modem processor. The application processor mainly processes an operating system, a user interface, and applications, etc., and the modem processor mainly processes wireless communications. Understandably, the above-mentioned modem processor may not be integrated into the processor 810.
[0323] The terminal 800 further includes a power supply 811 that supplies power to each component such as a battery. Exemplarily, the power supply 811 is logically connected to the processor 810 via a power management system, whereby functions such as charging, discharging, and power consumption management can be realized via the power management system.
[0324] Also, the terminal 800 includes several function modules not shown here and will not be repeatedly described.
[0325] Exemplarily, an embodiment of the present disclosure further provides a terminal, the terminal includes a processor 810, a memory 809, and a computer program stored in the memory 809 and executable by the processor 810. When the computer program is executed by the processor 810, each process of the embodiment of the data transmission method shown in FIG. 1 above is realized, and the same technical effect can be achieved. To avoid repetition, it will not be described repeatedly here.
[0326] Referring to FIG. 10, FIG. 10 is a schematic structural diagram of a network-side device according to an embodiment of the present disclosure. As shown in FIG. 10, the first network-side device 900 is a first base station or a central unit (CU) of the first base station or a distributed unit (DU) of the first base station. The first network-side device 900 a second receiving module 901 configured to receive data and an RRC recovery request message transmitted from a terminal in the radio resource control (RRC) inactive state; a second transmitting module 902 configured to transmit an RRC release message to the terminal.
[0327] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a 4-step random access process, or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0328] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0329] Furthermore, the data is encapsulated in a first media access control (MAC) protocol data unit (PDU) or a second MAC PDU. The first MAC PDU includes a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data.
[0330] Furthermore, the preprocessing includes at least one of a recovery process for a signaling bearer and a data bearer, an encryption process, and a segmentation process.
[0331] Furthermore, 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, and the bearer identification information is used to indicate the data bearer corresponding to the data. Or The sub-header information of the second MAC SDU includes logical channel identification information.
[0332] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0333] Furthermore, the first network-side device 900 further includes a third transmission module configured to transmit the recovered data to a core network.
[0334] Furthermore, the first network-side device 900 further a fourth transmission module configured to transmit a UE context search request message to a second base station, a third reception module configured to receive a UE context search response message transmitted from the second base station, and a fifth transmission module configured to transmit the data to a core network.
[0335] Furthermore, the fifth transmission module is configured to obtain the data from the first MAC PDU or the second MAC PDU transmitted from the terminal based on the terminal context that has been successfully recovered. The first MAC PDU contains the first MAC SDU directly generated by the data, and the second MAC PDU contains the second MAC SDU generated by the preprocessing of the data. The fifth transmission module is configured to transmit the data to the core network.
[0336] Furthermore, the first network-side device 900 further includes a sixth transmission module configured to transmit a UE context search request message to the second base station. The UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, the data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data. The first network-side device 900 further includes a fourth reception module configured to receive a UE context search failure message transmitted from the second base station.
[0337] Furthermore, the first network-side device 900 further includes a fifth reception module configured to receive data transfer information carried by an address indication message or the UE context search failure message from the second base station, and a seventh transmission module configured to transfer the data transmitted from the terminal to the second base station.
[0338] Furthermore, the data transmitted from the terminal is at least one of IP data, first MAC PDU data, first MAC SDU data, second MAC PDU data, second MAC SDU data, recovered first RLC SDU, and recovered second RLC SDU.
[0339] Furthermore, the RRC recovery reason indication includes at least one of an emergency call, a high-priority access, a terminal termination access, a terminal-triggered signaling, a terminal-triggered data, a terminal-triggered voice call, and a terminal-triggered video call.
[0340] The first network-side device 900 can perform each process implemented by the first base station or the central unit (CU) of the first base station or the distributed unit (DU) of the first base station in the embodiment of the method shown in FIG. 3, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0341] Referring to FIG. 11, FIG. 11 is a schematic structural diagram of a network-side device according to an embodiment of the present disclosure. As shown in FIG. 11, the second network-side device 1000 includes a sixth receiving module 1001 configured to receive a user equipment (UE) context search request message transmitted from the first base station or the central unit (CU) of the first base station, an eighth transmitting module 1002 configured to transmit a UE context search failure message to the first base station or the CU of the first base station, and a ninth transmitting module 1003 configured to transmit the data to the core network.
[0342] Furthermore, the UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data.
[0343] Furthermore, the second network-side device 1000 further includes a seventh receiving module configured to receive the data transmitted by the first base station or the CU of the first base station based on the data transfer information.
[0344] Furthermore, the second network-side device 1000 further includes A first transmission module configured to transmit an address indication message for carrying data transfer information to the first base station or the CU of the first base station; An eighth receiving module configured to receive the data transmitted by the first base station or the CU of the first base station based on the data transfer information.
[0345] The second network-side device 1000 can implement each process realized by the second base station in the embodiment of the method shown in FIG. 4, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0346] Referring to FIG. 12, FIG. 12 is a schematic structural diagram of a network-side device according to an embodiment of the present disclosure. As shown in FIG. 12, the third network-side device 1100 is a DU of the first base station, and the third network-side device 1100 A ninth receiving module 1101 configured to receive data and an RRC recovery request message transmitted from a terminal in a radio resource control (RRC) inactive state; An eleventh transmission module 1102 configured to transmit the data and the RRC recovery request message to the central unit (CU) of the first base station; A tenth receiving module 1103 configured to receive an RRC release message transmitted from the CU of the first base station; A twelfth transmission module 1104 configured to transmit the RRC release message to the terminal.
[0347] Furthermore, the RRC recovery request message is an RRC recovery request message in a 4-step random access process or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0348] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0349] Furthermore, the data is encapsulated in a first Media Access Control (MAC) protocol data unit (PDU) or a second MAC PDU. The first MAC PDU includes a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data.
[0350] Furthermore, the preprocessing includes at least one of a recovery process for a signaling bearer and a data bearer, an encryption process, and a segmentation process.
[0351] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data, or the sub-header information of the second MAC SDU includes logical channel identification information.
[0352] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0353] Furthermore, the eleventh transmission module 1102 further includes a transmission sub-module configured to transmit the data to the CU via an initial RRC transition message or via a user plane interface between the CU and the DU.
[0354] Furthermore, the transmission sub-module receives a UE context establishment request message transmitted from the CU and carrying transmission network layer information, and is configured to transmit the data to the CU based on the transmission network layer information.
[0355] Furthermore, the third network-side device 1100 further includes A first receiving module is configured to receive buffer status report (BSR) information transmitted from a terminal and transmit the BSR information to a CU of a first base station.
[0356] The third network-side device 1100 can implement each process realized by the DU of the first base station in the embodiment of the method shown in FIG. 5, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0357] Referring to FIG. 13, FIG. 13 is a schematic structural diagram of a network-side device according to an embodiment of the present disclosure. As shown in FIG. 13, the network-side device includes a bus 1201, a transceiver 1202, an antenna 1203, a bus interface 1204, a processor 1205, and a memory 1206.
[0358] In an embodiment of the present disclosure, the network-side device is a first base station or a central unit (CU) of the first base station or a distributed unit (DU) of the first base station. The transceiver 1202 receives data and an RRC recovery request message transmitted from a terminal in an RRC inactive state and transmits an RRC release message to the terminal.
[0359] Furthermore, the RRC recovery request message is an RRC connection recovery request message in a 4-step random access process, or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0360] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0361] Furthermore, the data is encapsulated in a first Media Access Control (MAC) protocol data unit (PDU) or a second MAC PDU. The first MAC PDU includes a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data.
[0362] Furthermore, the preprocessing includes at least one of a recovery process for a signaling bearer and a data bearer, an encryption process, and a segmentation process.
[0363] Furthermore, 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, and the bearer identification information is used to indicate the data bearer corresponding to the data, or the sub-header information of the second MAC SDU includes logical channel identification information.
[0364] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0365] Furthermore, the transceiver 1202 further transmits the recovered data to the core network.
[0366] Furthermore, the transceiver 1202 further transmits a UE context search request message to the second base station, receives a UE context search response message transmitted from the second base station, and transmits the data to the core network.
[0367] Furthermore, the transceiver 1202 further obtains the data from the first MAC PDU or the second MAC PDU transmitted from the terminal based on the normally recovered terminal context. The first MAC PDU includes a first MAC SDU directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data. Transmit the data to the core network.
[0368] Furthermore, the transceiver 1202 further transmits a UE context search request message to the second base station. The UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, the data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data. Receive a UE context search failure message transmitted from the second base station.
[0369] Furthermore, the transceiver 1202 further receives data transfer information carried by the address indication message from the second base station or the UE context search failure message. Transfer the data transmitted from the terminal to the second base station.
[0370] Furthermore, the data transmitted from the terminal is at least one of IP data, first MAC PDU data, first MAC SDU data, second MAC PDU data, second MAC SDU data, recovered first RLC SDU, and recovered second RLC SDU.
[0371] Furthermore, the RRC recovery reason indication includes at least one of an emergency call, high-priority access, terminal termination access, terminal-triggered signaling, terminal-triggered data, terminal-triggered voice call, and terminal-triggered video call.
[0372] The device in this embodiment can implement each process realized by the first base station or the central unit (CU) of the first base station or the distributed unit (DU) of the first base station in the embodiment of the method shown in FIG. 3, and can achieve the same technical effect, which will not be repeatedly described here.
[0373] In another embodiment of the present disclosure, the network-side device is a second base station, and the transceiver 1202 receives a user equipment (UE) context search request message transmitted from the first base station or the central unit (CU) of the first base station, and transmits a UE context search failure message to the first base station or the CU of the first base station, and transmits the data to the core network.
[0374] Furthermore, the UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, data transmitted from the terminal, data logical channel identification information, and data bearer identification information.
[0375] Furthermore, the transceiver 1202 further receives the data transmitted by the first base station or the CU of the first base station based on the data transfer information.
[0376] Furthermore, the transceiver 1202 further transmits an address indication message carrying the data transfer information to the first base station or the CU of the first base station, and receives the data transmitted by the first base station or the CU of the first base station based on the data transfer information.
[0377] The device in this embodiment can implement each process realized by the second base station in the embodiment of the method shown in FIG. 4, and can achieve the same technical effect, which will not be repeatedly described here.
[0378] In yet another embodiment of the present disclosure, the network-side device is the DU of the first base station, and the transceiver 1202 receives data and an RRC recovery request message transmitted from a terminal in the radio resource control (RRC) inactive state, and transmits the data and the RRC recovery request message to the centralized unit (CU) of the first base station, receives an RRC release message transmitted from the CU of the first base station, and transmits the RRC release message to the terminal.
[0379] Furthermore, the RRC recovery request message is an RRC recovery request message in a 4-step random access process, or an RRC recovery request message carried by MSG A in a 2-step random access process.
[0380] Furthermore, the data is multiplexed or cascaded with the RRC recovery request message.
[0381] Furthermore, the data is encapsulated in a first media access control (MAC) protocol data unit (PDU) or a second MAC PDU. The first MAC PDU includes a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by preprocessing the data.
[0382] Furthermore, the preprocessing includes at least one of recovery processing of signaling bearers and data bearers, encryption processing, and segmentation processing.
[0383] Furthermore, the sub-header information of the first MAC SDU includes at least one of logical channel identification information and bearer identification information. The logical channel identification information is used to indicate the logical channel type of the data, and the bearer identification information is used to indicate the data bearer corresponding to the data, or the sub-header information of the second MAC SDU includes logical channel identification information.
[0384] Furthermore, the logical channel identification information included in the sub-header information of the first MAC SDU is a logical channel identifier dedicated to IP data.
[0385] Furthermore, the transceiver 1202 further transmits the data to the CU via an initial RRC transition message or via a user plane interface between the CU and the DU.
[0386] Furthermore, the transceiver 1202 further receives a UE context establishment request message that carries transmission network layer information transmitted from the CU, and transmits the data to the CU based on the transmission network layer information.
[0387] Furthermore, the transceiver 1202 further receives buffer status report (BSR) information transmitted from the terminal, and transmits the BSR information to the CU of the first base station.
[0388] The device in this embodiment can implement each process realized by the DU of the first base station in the embodiment of the method shown in FIG. 5, and can achieve the same technical effect, which will not be repeatedly described here.
[0389] In FIG. 12, in the bus architecture (represented by bus 1201), bus 1201 may include any number of interconnected buses and bridges, and bus 1201 connects various circuits including one or more processors represented by processor 1205 and a memory represented by memory 1206. Bus 1201 can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and thus will not be repeatedly described herein. Bus interface 1204 provides an interface between bus 1201 and transceiver 1202. Transceiver 1202 may be a single element or may be multiple elements such as multiple receivers and transmitters, and provides a unit for communicating with various other devices via a transmission medium. Data processed by processor 1205 is transmitted onto a wireless medium via antenna 1203, and further, antenna 1203 receives data and transmits it to processor 1205.
[0390] Processor 1205 is responsible for managing bus 1201 and normal processing and can also provide various functions including time, peripheral interface, voltage regulation, power management, and other control functions. Also, memory 1206 can be used to store data used by processor 1205 when executing operations.
[0391] Exemplarily, processor 1205 can be a CPU, ASIC, FPGA, or CPLD.
[0392] Exemplarily, an embodiment of the present disclosure further provides a network-side device, where the network-side device includes a processor 1205, a memory 1206, and a computer program stored in the memory 1206 and executable by the processor 1205. When the computer program is executed by the processor 1205, it realizes each process of the embodiment of the data transmission method shown in FIG. 3 above, or realizes each process of the embodiment of the data transmission method shown in FIG. 4 above, or realizes each process of the embodiment of the data transmission method shown in FIG. 5 above, and can achieve the same technical effect. To avoid repetition, it will not be described repeatedly here.
[0393] An embodiment of the present disclosure further provides a computer-readable storage medium. When the computer program is executed by a processor, it realizes the steps in the data transmission method shown in FIG. 1, or the steps in the data transmission method shown in FIG. 3, or the steps in the data transmission method shown in FIG. 4, or the steps in the data transmission method shown in FIG. 5.
[0394] Here, the computer-readable storage medium is, for example, a ROM, a RAM, a magnetic disk, or an optical disk, etc.
[0395] As is understood to be possible, these examples described in the present disclosure may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For hardware implementation, modules, units, sub-modules, and sub-units may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), DSP devices, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units configured to perform the functions described in the present disclosure, or any combination thereof.
[0396] In addition, in this specification, the terms "comprising", "including", or any other variation thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or apparatus that includes a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specifically limited, elements defined by the phrase "including..." do not exclude the presence of other identical elements in the process, method, article, or apparatus that includes such an element.
[0397] As can be clearly understood by those skilled in the art from the description of the above embodiments, the method of the above embodiments can be implemented by software and the necessary general-purpose hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a more preferred embodiment. Based on such an understanding, the substantial technical features of the present disclosure or the part that contributes to the related technology can be implemented in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, disk, CD, etc.) and includes a plurality of instructions for causing a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods in the respective embodiments of the present disclosure.
[0398] As described above, the embodiments of the present disclosure have been described with reference to the drawings. However, the present disclosure is not limited to the specific embodiments described above. The above specific embodiments are illustrative and not restrictive. Those skilled in the art can make many other forms without departing from the gist of the present disclosure and the scope of the claims, and all of these should be included within the protection scope of the present invention.
Claims
1. A data transmission method for a terminal in a radio resource control (RRC) inactive state, comprising: Sending data and an RRC recovery request message to a first base station, or a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station; A data transmission method comprising: receiving an RRC release message transmitted from a first base station, or a CU of the first base station, or a DU of the first base station.
2. The RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process; 2. The data transmission method according to claim 1.
3. The data is multiplexed or cascaded with the RRC recovery request message.
2. The data transmission method according to claim 1.
4. Before transmitting the data 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 data transmission method includes: encapsulating the data directly as a first media access control (MAC) service data unit (SDU) into a first MAC protocol data unit (PDU); or encapsulating the second MAC SDU generated by pre-processing using the data into a second MAC PDU.
2. The data transmission method according to claim 1.
5. The pre-processing includes at least one of a signaling bearer and a data bearer recovery process, a ciphering process, and a segment process.
5. The data transmission method according to claim 4.
6. The subheader information of the first MAC SDU includes at least one of a logical channel identification and a bearer identification, the logical channel identification being used to indicate a logical channel type of the data, and the bearer identification being used to indicate a data bearer corresponding to the data; or The subheader information of the second MAC SDU includes logical channel identification information.
5. The data transmission method according to claim 4.
7. The logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identifier dedicated to IP (Internet Protocol) data; 7. The data transmission method according to claim 6.
8. A data transmission method for a first base station, a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station, the data transmission method comprising: receiving data transmitted from a terminal in a radio resource control (RRC) inactive state and an RRC recovery request message; sending an RRC release message to the terminal.
9. The RRC recovery request message is an RRC connection recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process; The data transmission method according to claim 8.
10. The data is multiplexed or cascaded with the RRC recovery request message. The data transmission method according to claim 8.
11. The data is encapsulated in a first media access control (MAC) protocol data unit (PDU) or a second MAC PDU, the first MAC PDU including a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU including a second MAC SDU generated by pre-processing the data. The data transmission method according to claim 8.
12. The pre-processing includes at least one of a signaling bearer and a data bearer recovery process, a ciphering process, and a segment process. The data transmission method according to claim 11.
13. the first MAC PDU includes at least one of a logical channel identity and a bearer identity, the logical channel identity being used to indicate a logical channel type of the data, and the bearer identity being used to indicate a data bearer corresponding to the data; or The subheader information of the second MAC SDU includes logical channel identification information. The data transmission method according to claim 11.
14. The logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identifier dedicated to IP data; The data transmission method according to claim 13.
15. After receiving data transmitted from a terminal in an RRC inactive state and an RRC recovery request message, the data transmission method includes: and transmitting the recovered data to a core network. The data transmission method according to claim 8.
16. After receiving data transmitted from a terminal in an RRC inactive state and an RRC recovery request message, the data transmission method includes: Sending a UE context search request message to a second base station; receiving a UE context search response message sent from a second base station; transmitting the data to a core network. The data transmission method according to claim 8.
17. Specifically, transmitting the data to a core network includes: Obtaining the data from a first MAC PDU or a second MAC PDU transmitted from the terminal based on the successfully recovered terminal context, where the first MAC PDU includes a first MAC SDU directly generated by the data, and the second MAC PDU includes a second MAC SDU generated by pre-processing the data; and transmitting the data to a core network.
17. The data transmission method according to claim 16.
18. After receiving data transmitted from a terminal in an RRC inactive state and an RRC recovery request message, the data transmission method includes: Sending a UE context search request message to a second base station, where the UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, data sent from the terminal, logical channel identification information of data, and bearer identification information of data; receiving a UE context search failure message sent from the second base station; The data transmission method according to claim 8.
19. The data transmission method includes: receiving data forwarding information carried by an address indication message or the UE context search failure message from the second base station; and transmitting the data transmitted from the terminal to the second base station.
20. The data transmission method according to claim 18.
20. The data transmitted from the terminal is at least one of IP data, first MAC PDU data, first MAC SDU data, second MAC PDU data, second MAC SDU data, a recovered first RLC SDU, and a recovered second RLC SDU.
20. The data transmission method according to claim 18.
21. The RRC recovery reason indication includes at least one of an emergency call, a high priority access, a terminal terminated access, a terminal triggered signaling, a terminal triggered data, a terminal triggered voice call, and a terminal triggered video call.
20. The data transmission method according to claim 18.
22. A data transmission method for a second base station, comprising: receiving a user equipment (UE) context search request message sent from a first base station or a centralization unit (CU) of the first base station; Sending a UE context search failure message to the first base station or a CU of the first base station; transmitting the data to a core network.
23. The UE context search request message carries at least one of an RRC recovery reason indication, a data transmission indication, subsequent data indication information, terminal cache information, data transmitted from the terminal, logical channel identification information of the data, and bearer identification information of the data.
23. The data transmission method according to claim 22.
24. The UE context search failure message carries data forwarding information, and the data transmission method includes: The method further includes receiving the data transmitted by the first base station or the CU of the first base station based on the data forwarding information.
23. The data transmission method according to claim 22.
25. The data transmission method includes: Sending an address indication message carrying data forwarding information to the first base station or a CU of the first base station; Receiving the data transmitted by the first base station or the CU of the first base station based on the data forwarding information.
23. The data transmission method according to claim 22.
26. A data transmission method applied to a distributed unit (DU) of a first base station, comprising: receiving data transmitted from a terminal in a radio resource control (RRC) inactive state and an RRC recovery request message; sending the data and an RRC recovery request message to a centralization unit (CU) of a first base station; Receiving an RRC release message sent from a CU of a first base station; sending the RRC release message to a terminal.
27. The RRC recovery request message is an RRC recovery request message in a four-step random access process, or an RRC recovery request message carried by MSG A in a two-step random access process; 27. The data transmission method according to claim 26.
28. The data is multiplexed or cascaded with the RRC recovery request message.
27. The data transmission method according to claim 26.
29. The data is encapsulated in a first media access control (MAC) protocol data unit (PDU) or a second MAC PDU, the first MAC PDU including a first MAC service data unit (SDU) directly generated by the data, and the second MAC PDU including a second MAC SDU generated by pre-processing the data.
20. The data transmission method according to claim 19.
30. The pre-processing includes at least one of a signaling bearer and a data bearer recovery process, a ciphering process, and a segment process.
30. The data transmission method according to claim 29.
31. The subheader information of the first MAC SDU includes at least one of a logical channel identification and a bearer identification, the logical channel identification being used to indicate a logical channel type of the data, and the bearer identification being used to indicate a data bearer corresponding to the data; or The subheader information of the second MAC SDU includes logical channel identification information.
30. The data transmission method according to claim 29.
32. The logical channel identification information included in the subheader information of the first MAC SDU is a logical channel identifier dedicated to IP data; 32. The data transmission method according to claim 31.
33. transmitting the data and the RRC recovery request message to a centralization unit (CU) of a first base station; transmitting the data to the CU via an initial RRC transition message or via a user plane interface between the CU and the DU; 27. The data transmission method according to claim 26.
34. Transmitting the data to the CU via a user plane interface between the CU and the DU includes: receiving a UE context establishment request message sent from the CU, the message carrying transmission network layer information; and transmitting the data to the CU based on the transmission network layer information.
34. The data transmission method according to claim 33.
35. The data transmission method includes: receiving buffer status report (BSR) information transmitted from the terminal; and transmitting the BSR information to a CU of the first base station; 27. The data transmission method according to claim 26.
36. A terminal in a radio resource control (RRC) inactive state, A transmitting module configured to transmit data and an RRC recovery request message to the first base station, or a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station; A terminal comprising: a receiving module configured to receive an RRC release message transmitted from a first base station, a CU of the first base station, or a DU of the first base station.
37. 1. A terminal in a radio resource control (RRC) inactive state, comprising: a processor; and a transceiver, A terminal, wherein the transceiver transmits data and an RRC recovery request message to a first base station, or a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station, and receives an RRC release message transmitted from the first base station, or the CU of the first base station, or the DU of the first base station.
38. A network side device which is a first base station, a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station, a receiving module configured to receive data transmitted from a terminal in a radio resource control (RRC) inactive state and an RRC recovery request message; A network side device comprising: a transmitting module configured to transmit an RRC release message to a terminal.
39. A network side device which is a first base station, a centralized unit (CU) of the first base station, or a distributed unit (DU) of the first base station, comprising: a processor; and a transceiver; The transceiver is a network side device that receives data transmitted from a terminal in a radio resource control (RRC) inactive state and an RRC recovery request message, and transmits an RRC release message to the terminal.
40. A network side device which is a second base station, A first receiving module configured to receive a user equipment (UE) context search request message sent from a first base station or a centralization unit (CU) of the first base station; A first sending module configured to send a UE context search failure message to a first base station or a CU of the first base station; A second transmitting module configured to transmit data to a core network.
41. A network side device which is a second base station, the network side device comprising: a processor; and a transceiver; The transceiver is a network side equipment that receives a user equipment (UE) context search request message transmitted from a first base station or a centralized unit (CU) of the first base station, transmits a UE context search failure message to the first base station or the CU of the first base station, and transmits data to a core network.
42. A network side device which is a distributed unit (DU) of a first base station, A first receiving module configured to receive data transmitted from a terminal in a radio resource control (RRC) inactive state and an RRC recovery request message; a first transmitting module configured to transmit the data and an RRC recovery request message to a centralization unit (CU) of a first base station; A second receiving module configured to receive an RRC release message sent from the CU of the first base station; A second sending module configured to send the RRC release message to a terminal.
43. A network side device which is a distributed unit (DU) of a first base station, comprising: a processor; and a transceiver; The transceiver receives data and an RRC recovery request message transmitted from a terminal in a radio resource control (RRC) inactive state, transmits the data and the RRC recovery request message to a centralization unit (CU) of a first base station, receives an RRC release message transmitted from the CU of the first base station, and transmits the RRC release message to the terminal.
44. A processor, a memory, and a computer program stored in the memory and executable by the processor, A terminal, wherein the computer program, when executed by the processor, causes the processor to perform the steps of the data transmission method according to any one of claims 1 to 7.
45. A processor, a memory, and a computer program stored in the memory and executable by the processor, A network side device, wherein the computer program, when executed by the processor, causes the processor to execute a step in a data transmission method described in any one of claims 8 to 21, or a step in a data transmission method described in any one of claims 22 to 25, or a step in a data transmission method described in any one of claims 26 to 35.
46. A computer-readable storage medium having stored thereon a computer program which, when executed by the processor, causes the processor to execute the steps of the data transmission method according to any one of claims 1 to 7, or the steps of the data transmission method according to any one of claims 8 to 21, the steps of the data transmission method according to any one of claims 22 to 25, or the steps of the data transmission method according to any one of claims 26 to 35.
47. A computer program product stored on a non-volatile storage medium, which, when executed by at least one processor, causes the processor to perform the steps of the data transmission method according to any one of claims 1 to 7, or the steps of the data transmission method according to any one of claims 8 to 21, the steps of the data transmission method according to any one of claims 22 to 25, or the steps of the data transmission method according to any one of claims 26 to 35.
48. A terminal adapted to carry out the data transmission method according to any one of claims 1 to 7.
49. A network side device configured to execute the data transmission method according to any one of claims 8 to 21, or the data transmission method according to any one of claims 22 to 25, or the data transmission method according to any one of claims 26 to 35.
Citation Information
Patent Citations
Communication method and apparatus
WO2019242756A1
Method and apparatus for supporting early data transmission in inactive state in wireless communication system
WO2020036460A1