Communication method and device and readable storage medium

Abstract

The invention relates to the technical field of communication, in particular to a communication method and device and a readable storage medium, and the method comprises the steps: receiving an RRC reconfiguration message sent by a second communication device; the RRC reconfiguration message is used for indicating switching from the second communication device to a third communication device; sending a random access request to a third communication device and receiving a random access response, the response comprising the first scheduling resource; when the to-be-transmitted data comprises user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet a preset condition, sending a first message to a third communication device by using the first scheduling resource; the first message comprises control plane data and a first BSR, the first BSR is used for applying for a second scheduling resource for sending part of or all data in the user plane data, and the first BSR is a short type BSR. According to the embodiment of the invention, the switching time delay can be reduced, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, apparatus and readable storage medium. Background Technology

[0002] In communication systems, random access (RA) is one of the most fundamental and crucial processes. User equipment (UE) can use RA to achieve uplink synchronization, obtain its unique identifier within the cell—the cell-radio network temporary identifier (C-RNTI), and establish a radio resource control (RRC) connection. Random access is an essential step in establishing a radio link between the UE and the network; only after RA is completed can the access network equipment and the UE exchange data normally. Random access can be categorized into contention-based random access and contention-free random access.

[0003] When network-side preamble resources are sufficient, UEs typically follow a non-contention-based random access procedure during handover. In this random access process, the UE can use scheduling resources carrying uplink grants (also known as RAR grants or UL grants) in the random access response (RAR) to assemble data packets and send a handover reconfiguration complete message to the network. Besides the signalalling radio bearer (SRB) data in the handover reconfiguration complete message, the RAR grant's packet scope can also include user plane data radio bearer (DRB) data to be transmitted and medium access control-control element (MAC-CE) data from buffer status reports (BSRs). The scheduling packet assembly strategy of the RAR grant scheduling resources has a significant impact on the transmission of the handover reconfiguration complete message.

[0004] Currently, during handover, if the UE has multiple types of data to be transmitted, significant handover latency may occur. Handover latency is a crucial KPI for operators to evaluate user experience. Operators can assess network handover performance and UE handover experience by monitoring the latency from when the network sends handover configuration to when it receives the handover reconfiguration completion message. Given that each UE performs a large number of handovers per day on average, high handover latency has a negative impact on user experience.

[0005] Therefore, the industry is exploring how to provide a solution that can reduce handover latency. Summary of the Invention

[0006] This application provides a communication method, apparatus, and readable storage medium that can reduce switching latency and improve user experience.

[0007] The present application is described below from different aspects. It should be understood that the different implementation methods and beneficial effects described below can be referenced from each other.

[0008] In a first aspect, this application provides a communication method, characterized in that it is applied to a first communication device, the method comprising: receiving a Radio Resource Control (RRC) reconfiguration message sent by a second communication device; the RRC reconfiguration message being used to instruct the communication service device of the first communication device to switch from the second communication device to a third communication device;

[0009] Send a random access request to the third communication device;

[0010] Receive a random access response sent by the third communication device; the random access response includes a first scheduling resource;

[0011] When the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions, a first message is sent to the third communication device using the first scheduling resource; the first message includes the control plane data and a first buffer status report (BSR), the first BSR is used to request a second scheduling resource to send part or all of the data in the user plane data, and the first BSR is a short BSR.

[0012] In this embodiment of the application, during the random access process of handover, when the UE has multiple types of data to be transmitted simultaneously, when the UE receives a small RAR grant (scheduling resource), and the control plane data (SRB data) to be transmitted and the scheduling resource meet certain conditions, the UE can prioritize assembling complete control plane data (or SRB data), then reserve resources for short BSR, and if there are still remaining resources, then assemble and schedule part of the user plane data (DRB data) for transmission, so that the complete control plane data can be sent in one RAR grant, effectively reducing handover latency and providing a better user experience.

[0013] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource.

[0014] In this embodiment, when multiple types of data to be transmitted exist simultaneously on the UE side, if the resources required to transmit the data to be transmitted (DRB data and SRB data) are greater than the first scheduling resource, while the resources required to transmit control plane data (SRB data) and short BSR are less than or equal to the first scheduling resource, the UE can prioritize assembling complete SRB data packets and separately request scheduling resources for the remaining DRB data through short BSR. This ensures that complete control plane data can be transmitted in a single RAR authorization, effectively reducing handover latency and improving user experience.

[0015] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy a preset condition, and further includes: the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource.

[0016] In this embodiment, when the resources required for transmitting control plane data and short BSR are less than or equal to the first scheduling resources, there may be a situation where the resources required for transmitting control plane data and long BSR are greater than the first scheduling resources. The UE can prioritize completing the complete control plane data and construct a short BSR (since the control plane data has been completed, only user plane data is available) to request scheduling resources for the remaining user plane data, ensuring that the control plane data can be transmitted in full within the scheduling resources granted in one uplink, thereby reducing handover latency.

[0017] In one possible implementation, the first message further includes a portion of the user plane data, and the first BSR is used to request a second scheduling resource to send other portions of the user plane data.

[0018] In this embodiment, if there are still remaining resources available after the UE packages complete control plane data and reserves short BSR resources, it can continue to package some user plane data for transmission, thereby reducing resource waste.

[0019] In one possible implementation, the method further includes:

[0020] When the data to be transmitted includes the user plane data and the control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources; the second message includes part of the control plane data and the second BSR; the second BSR is used to request third scheduling resources to transmit other parts of the control plane data and part or all of the user plane data, and the second BSR is a long BSR.

[0021] In this embodiment of the application, when the first scheduling resource is insufficient to transmit control plane data and short BSR simultaneously, the UE can prioritize packetizing a portion of the control plane data, and at the same time request a third scheduling resource for the remaining control plane data and user plane data through a long BSR (such as a second BSR).

[0022] In one possible implementation, the method further includes:

[0023] When the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources; the third message includes part of the control plane data and a third BSR, the third BSR is used to request a fourth scheduling resource to transmit other parts of the control plane data, and the third BSR is a short BSR.

[0024] In this embodiment of the application, when the data to be transmitted on the UE side only includes control plane data, if the first scheduling resource granted for uplink is insufficient to transmit the control plane data, the UE can first assemble a portion of the control plane data, and then request scheduling resources for the remaining control plane data by constructing a short BSR (such as a third BSR), and send the remaining control plane data on the subsequently granted scheduling resources.

[0025] Secondly, this application provides a first communication device, the device comprising:

[0026] The receiving unit is configured to receive a Radio Resource Control (RRC) reconfiguration message sent by the second communication device; the RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device.

[0027] The sending unit is used to send a random access request to the third communication device;

[0028] The receiving unit is further configured to receive a random access response sent by the third communication device; the random access response includes a first scheduling resource.

[0029] The transmitting unit is further configured to send a first message to the third communication device using the first scheduling resource when the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions; the first message includes the control plane data and a first BSR; the first BSR is used to request a second scheduling resource for transmitting part or all of the data in the user plane data, and the first BSR is a short BSR.

[0030] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource.

[0031] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy a preset condition, and further includes: the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource.

[0032] In one possible implementation, the first message further includes a portion of the user plane data, and the first BSR is used to request a second scheduling resource to send other portions of the user plane data.

[0033] In one possible implementation, the sending unit is further configured to:

[0034] When the data to be transmitted includes the user plane data and the control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources; the second message includes part of the control plane data and the second BSR; the second BSR is used to request third scheduling resources to transmit other parts of the control plane data and part or all of the user plane data, and the second BSR is a long BSR.

[0035] In one possible implementation, the sending unit is further configured to:

[0036] When the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources; the third message includes part of the control plane data and a third BSR, the third BSR is used to request a fourth scheduling resource to transmit other parts of the control plane data, and the third BSR is a short BSR.

[0037] Thirdly, this application provides a communication device that may include a processor, a transceiver, and a memory. The memory stores a computer program, and the transceiver sends and receives various messages. The computer program includes program instructions that, when executed by the processor, cause the communication device to perform the method described in any of the possible implementations of the first aspect. The transceiver may be a radio frequency module in the communication device, or a combination of a radio frequency module and an antenna, or an input / output interface of a chip or circuit.

[0038] Fourthly, this application provides a computer-readable storage medium storing program instructions that, when run on a computer, cause the computer to perform the method described in any of the possible implementations of the first aspect above.

[0039] Fifthly, this application provides a program product containing program instructions that, when run, cause the method described in any of the possible implementations of the first aspect to be executed.

[0040] Sixthly, this application provides a communication device, which can be implemented as a chip, a device, or a component within a device, etc. The device includes a processor. The processor is used to read and execute a program stored in a memory to perform the communication method provided by any of the possible implementations of the first aspect described above. Optionally, the communication device further includes a memory connected to the processor via a circuit. Further optionally, the communication device includes a communication interface to which the processor is connected. The communication interface is used to receive data packets and / or information to be processed. The processor obtains the data packets and / or information from the communication interface, processes the data packets and / or information, and outputs the processing result through the communication interface. The communication interface can be an input / output interface.

[0041] In a seventh aspect, this application provides a chip system including a processor for supporting a device in implementing the functions involved in any of the possible implementations of the first aspect, such as generating or processing information involved in the communication method described above. In one possible design, the chip system further includes a memory for storing necessary program instructions and data for the device. This chip system may be composed of chips or may include chips and other discrete devices.

[0042] Optionally, the processor and memory can be physically independent units, or the memory can be integrated with the processor.

[0043] It should be noted that the technical effects achieved in the above aspects can be referred to each other or to the beneficial effects in the method embodiments shown below, which will not be repeated here. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0045] Figure 1a This is a schematic diagram of the architecture of the communication system provided in the embodiments of this application;

[0046] Figure 1b This is a schematic diagram of a Sidelink UE-to-Network Relay scenario provided in an embodiment of this application;

[0047] Figure 1c This is a schematic diagram of a Sidelink UE-to-UE Relay scenario provided in an embodiment of this application;

[0048] Figure 2 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0049] Figure 3 This is a schematic diagram of a packet scheduling format provided in an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of another packet scheduling format provided in the embodiments of this application;

[0051] Figure 5 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0052] Figure 6 This is a schematic diagram of another communication device provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of the structure of another communication device provided in the embodiments of this application. Detailed Implementation

[0054] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0055] In the description of this application, the terms "first," "second," etc., are used only to distinguish different objects and do not limit the quantity or order of execution, nor do they imply that they are necessarily different. For example, "first resource" and "second resource," etc., are merely used to distinguish different information and do not limit their order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0056] In the description of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one item", "one or more of the following", or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0057] In the description of this application, the words "exemplary," "exemplarily," or "for example" are used to indicate examples, illustrations, or illustrative purposes. Any embodiment or design described as "exemplary," "for example," or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the words "exemplary," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0058] It is understood that in the description of this application, "when," "if," and "if" all refer to the device making a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment action when it is implemented, nor do they mean that there are other limitations.

[0059] In this application, "simultaneously" can be understood as at the same point in time, within a period of time, or within the same cycle; the specific meaning can be determined by considering the context.

[0060] In this application, the use of singular designations for elements is intended to represent "one or more" rather than "one and only one," unless otherwise specified.

[0061] It is understood that in the various embodiments of this application, "A and B correspond" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0062] It is understood that in the embodiments of this application, "for indicating" and "indication" can include direct and indirect indication, as well as explicit and implicit indication. When describing "a certain indication information is used to indicate A" or "indication information of A", it can include the indication information directly indicating A or indirectly indicating A, but does not necessarily mean that the indication information carries A. The information indicated by a certain information is called the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as, but not limited to, directly indicating the information to be indicated, such as the information to be indicated itself or its index. It can also indirectly indicate the information to be indicated by indicating other information, where there is an association between the other information and the information to be indicated. It can also indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed upon in advance. For example, the indication of specific information can also be achieved by using the arrangement order of various information in advance (e.g., according to an agreement), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of various information can be identified and indicated uniformly to reduce the indication overhead caused by individually indicating the same information. In addition, the specific indication method can also be various existing indication methods, such as, but not limited to, the above-mentioned indication methods and their various combinations. Specific details of various indication methods can be found in existing technologies and will not be repeated here. As described above, for example, when multiple pieces of information of the same type need to be indicated, the indication methods for different pieces of information may differ. In specific implementation, the required indication method can be selected according to specific needs. This application does not limit the selection of the indication method. Therefore, the indication methods involved in this application should be understood to cover various methods that enable the party to be indicated to know the information to be indicated. The information to be indicated can be sent as a whole or divided into multiple sub-information and sent separately. Moreover, the sending period and / or sending time of these sub-information can be the same or different. This application does not limit the specific sending method.

[0063] For ease of understanding, the technical solution provided in this application will be described below with reference to more accompanying drawings.

[0064] The technical solutions of this application can be applied to various communication systems, such as: Universal Mobile Telecommunications System (UMTS), also known as third-generation (3G) systems; Long Term Evolution (LTE) systems, also known as fourth-generation (4G) systems; Worldwide Interoperability for Microwave Access (WiMAX) communication systems; fifth-generation (5G) systems, such as new radio (NR) technologies; networks integrating multiple systems; Internet of Things (IoT) systems; vehicle-to-everything (V2X) systems; and future communication systems, such as sixth-generation (6G) systems and even seventh-generation (7G) systems. The technical solutions of this application can also be applied to open RAN (O-RAN or ORAN), cloud radio access networks (CRAN), or communication networks including two or more of the above. The technical solutions of this application can also be applied to sidelink communication systems, or to other communication systems operating in unlicensed spectrum. It is understood that the "communication system operating in unlicensed spectrum" mentioned in this application means that the communication system operates in unlicensed spectrum under some circumstances, and of course, the communication system can also operate in licensed spectrum under other circumstances.

[0065] It should be understood that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of communication network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0066] See Figure 1a , Figure 1a This is a schematic diagram of the architecture of the communication system provided in an embodiment of this application. Figure 1a As shown, the communication system includes a wireless access network 100. The wireless access network 100 may include at least one wireless access network device (such as...). Figure 1a 110a and 110b in the above), may also include at least one terminal device (such as Figure 1a(120a-120j in the original text). Terminal devices can connect to wireless access network devices wirelessly, and terminal devices and wireless access network devices can be interconnected via wired or wireless means. Understandably, Figure 1a This is just an illustration; the communication system may also include other network devices, such as core network equipment, wireless relay equipment, and wireless backhaul equipment. Figure 1a It is not shown in the middle.

[0067] Wireless access network equipment, often simply referred to as network equipment, is the access device that enables terminals to wirelessly access a communication system. Wireless access network equipment can be a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in 5G mobile communication systems, a next-generation base station in 6G mobile communication systems, a base station in a future mobile communication system, or an access node in a WiFi system; it can also be a module or unit that performs some of the functions of a base station, for example, it can be a central unit (CU) or a distributed unit (DU). The CU here performs the functions of the radio resource control protocol and packet data convergence protocol (PDCP) of the base station, and can also perform the functions of the service data adaptation protocol (SDAP). The DU performs the functions of the radio link control layer and medium access control (MAC) layer of the base station, and can also perform some or all of the physical layer functions. For specific descriptions of the above protocol layers, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). The radio access network equipment can be a macro base station (such as...) Figure 1a 110a in the text), can also be a micro base station or an indoor station (such as... Figure 1a 110b) in the text can also be a relay node or a donor node, etc. The embodiments of this application do not limit the specific technology or device form used in the wireless access network equipment. For ease of description, the following description uses a base station as an example of a wireless access network device.

[0068] A terminal device is a device with wireless transceiver capabilities, capable of sending signals to or receiving signals from a base station. Terminal devices can also be referred to as terminals, user equipment (UE), mobile stations, mobile terminals, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, intelligent transportation, and smart cities. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, airplanes, ships, robots, robotic arms, smart home devices, etc. The embodiments of this application do not limit the specific technologies or device forms used in the terminals.

[0069] Optionally, the base station and terminal can be fixed or mobile. The base station and terminal can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed on aircraft, balloons, and satellites. The embodiments of this application do not limit the application scenarios of the base station and terminal.

[0070] Alternatively, the roles of the base station and the terminal can be relative, for example, Figure 1a The helicopter or drone 120i can be configured as a mobile base station. For terminals 120j accessing the wireless access network 100 via 120i, terminal 120i is a base station; however, for base station 110a, 120i is a terminal, meaning that 110a and 120i communicate via a wireless air interface protocol. Of course, 110a and 120i can also communicate via a base station-to-base station interface protocol; in this case, 120i is also a base station relative to 110a. Therefore, both base stations and terminals can be collectively referred to as communication devices. Figure 1a The 110a and 110b in the text can be referred to as communication devices with base station functions. Figure 1a The 120a-120j in the text can be referred to as communication devices with terminal functions.

[0071] Optionally, communication can be conducted between base stations and terminals, between base stations, and between terminals through licensed spectrum, through unlicensed spectrum, or simultaneously through both licensed and unlicensed spectrum; communication can be conducted through spectrum below 6 GHz, through spectrum above 6 GHz, or simultaneously using both spectrum below 6 GHz and spectrum above 6 GHz.

[0072] It is understood that the interface between terminals is a PC5 interface, and the interface between a terminal and a base station is a Uu interface. Terminals can use unlicensed spectrum to communicate with other terminals via sidelink. Communication between terminals can be unicast, multicast, or broadcast. In sidelink communication, a terminal can be configured with one or more antennas for sending and receiving messages / information / data, etc. It is understood that the terminal may also include multiple components related to message / information / data transmission and reception (e.g., processor, modulator, multiplexer, demodulator, or demultiplexer, etc.).

[0073] In this application embodiment, the device for implementing the terminal's functions can be a terminal itself; it can also be a device capable of supporting the terminal in implementing those functions, such as a chip system, a communication module, or a modem, etc., which can be installed in the terminal. In this application embodiment, the chip system can be composed of chips, or it can include chips and other discrete devices. In the technical solutions provided in this application embodiment, the device for implementing the terminal's functions is a terminal, and the terminal is a UE (User Equipment) as an example, to describe the technical solutions provided in this application embodiment. The embodiments of this application do not limit the specific technology or specific device form adopted by the terminal device.

[0074] In some scenarios, the UE can also be used as a base station. For example, the UE can act as a scheduling entity, providing sidelink signaling between UEs in vehicle-to-everything (V2X), device-to-device (D2D), or peer-to-peer (P2P) networks.

[0075] In some scenarios, the UE can also be used as a relay node. For example, the UE can act as a relay device or an integrated access and backhaul (IAB) node to provide wireless backhaul services to terminal devices.

[0076] Optionally, a typical application scenario for sidelink communication is vehicle-to-everything (V2X). The method provided in this application can be applied not only to V2X scenarios (as mentioned above) Figure 1aIn scenarios involving communication between 120a and 120b, it can also be applied to sidelink UE-to-Network Relay and sidelink UE-to-UE Relay scenarios. See also Figure 1b , Figure 1b This is a schematic diagram of a Sidelink UE-to-NetworkRelay scenario provided in an embodiment of this application. For example... Figure 1b As shown, the Sidelink UE-to-Network Relay scenario includes a Remote UE and a Relay UE, as well as a base station; the method provided in this application can be applied to communication between the Remote UE and the Relay UE. See also Figure 1c , Figure 1c This is a schematic diagram of a Sidelink UE-to-UE Relay scenario provided in an embodiment of this application. For example... Figure 1c As shown, the Sidelink UE-to-UE Relay scenario includes a Source UE, a Relay UE, and a target UE; the method provided in this application can be applied to communication between the Source UE and the Relay UE and / or communication between the Relay UE and the target UE.

[0077] In the embodiments of this application, the term "wireless communication" can also be abbreviated as "communication", and the term "communication" can also be described as "data transmission", "information transmission" or "transmission".

[0078] To better understand the technical solutions of the embodiments of this application, several terms or nouns related to this application are briefly introduced below so that those skilled in the art can understand them.

[0079] I. Random Access (RA)

[0080] Random access can be divided into contention-based random access and non-contention-based random access. During communication, the random access process of a terminal device can be triggered by many events, including initial access, radio resource control (RRC) connection re-establishment, uplink synchronization loss in RRC connection state, insufficient uplink scheduling resources in RRC connection state, uplink scheduling failure, and uplink synchronization reconfiguration (such as cell handover), etc. In this embodiment, the random access process initiated by the terminal device in handover scenarios will be improved to quickly feed back the handover reconfiguration completion message to the network side, thereby reducing handover latency.

[0081] II. Contention-Free Random Access (CFRA)

[0082] Non-contention-based random access can be divided into four-step random access procedures and two-step random access procedures. In the four-step CFRA procedure, the access network device first allocates a preamble for random access. Then, the terminal device uses the preamble allocated by the access network device to initiate the RACH procedure. Finally, the terminal device receives the RAR message from the access network device. In the two-step CFRA procedure, the access network device first allocates a preamble and Physical Uplink Shared Channel (PUSCH) resources to the terminal device. Then, the terminal device uses the resources allocated by the access network device to send MsgA and receives the RAR message from the access network device. The four-step CFRA procedure does not involve the exchange of four messages (e.g., Msg1-Msg4), or in other words, it does not involve four steps of interaction. However, the first message sent by the terminal device to the access network device only includes the random access preamble; that is, the first message is Msg1, not MsgA. Therefore, it can still be called a four-step random access procedure according to the standard. In handover scenarios, a non-contention-based random access procedure is typically followed. After receiving the RAR message, the UE can assemble data packets based on the uplink grant (also known as RAR grant or ULgrant) carried in the RAR message and send a handover reconfiguration completion message to the network side. In this embodiment, the random access procedure initiated by the terminal device in a handover scenario is improved by prioritizing the assembly of reconfiguration completion data during the uplink grant. This allows the reconfiguration completion data to be sent within a single uplink grant, enabling rapid feedback of the handover reconfiguration completion message to the network side and reducing handover latency.

[0083] III. Service Data Unit (SDU) and Protocol Data Unit (PDU)

[0084] An Service Data Unit (SDU) is an information unit transmitted from a higher-layer protocol to a lower-layer protocol; it is a data unit exchanged between entities at adjacent layers. A Service Data Unit (SDU) is a data unit manipulated by the protocol of a specific layer during communication between peer entities. It mainly consists of two parts: User Data Information (UDI) and Protocol Control Information (PCI). A PDU contains an Service Data Unit (SDU) and may be composed of one or more SDUs or be segmented. For the protocol stack, the SDU plays a role in the exchange between layers, while the PDU is a processed data unit with a specific format used to transmit data between peer entities at the protocol layer. When a PDU is used as a data unit of the next layer, it is equivalent to the Service Data Unit (SDU) of the previous layer. Depending on the size of the PDU, an SDU may be divided into multiple PDUs for transmission, or multiple SDUs may be merged into a single PDU; this division or merging depends on the requirements of the specific protocol. In general, both SDUs and PDUs are basic units of data transmission, but their roles and composition in the communication process differ. A PDU is an encapsulated form of an SDU, containing the necessary control information to ensure correct data transmission and processing.

[0085] IV. Buffer Status Report (BSR)

[0086] Buffer Status Report (BSR) is a MAC layer procedure in a wireless network. A terminal device (UE) can use a BSR to report the amount of data in its uplink (UL) buffer to be transmitted to the serving access network device (such as a gNB). Simply put, a BSR is a MAC layer message sent from the UE to the gNB, notifying the gNB, "I have data to send; please grant me permission to send data?" The gNB then allocates a minimum number of uplink (UL) authorized resources to the UE based on available radio resources (such as radio blocks, radio stations, and radio banks). The Buffer Status Report (BSR) process involves the UE providing information to the serving gNB about the amount of uplink (UL) data in the MAC entity. Before sending a BSR, the UE first estimates how much data it must transmit; this process is called "data volume calculation." The amount of data to be transmitted depends on the data volume in the radio link control (RLC) layer and the packet data convergence protocol (PDCP) layer.

[0087] First, this paper analyzes and proposes the specific technical problem to be solved in this application. Currently, for handover scenarios, UEs generally follow a non-contention-based random access procedure. During this random access process, the UE can use the uplink grant (also known as RAR grant or UL grant) carried in the random access response (RAR) to assemble data packets and send the handover reconfiguration completion message SRB data (also known as control plane data) to the network side. The handover reconfiguration completion message is an acknowledgment message with a fixed format. The resource size required in the RAR grant is relatively fixed, for example, 12 bytes, including the PDCP PDU (8 bytes), the RLC PDU header (2 bytes), and the MAC SDU header (2 bytes).

[0088] In addition, during handover, besides the SRB data in the handover reconfiguration completion message, there is also user plane DRB data (also known as user plane data) to be transmitted. If RAR granting cannot assemble all the SRB and DRB data to be transmitted, the UE can report the amount of data to be transmitted to the network side via BSRMAC-CE, thereby requesting scheduling resources from the network side to send the data. Therefore, the scope of RAR granting scheduling resources can include the SRB data in the handover reconfiguration completion message, the user plane DRB data to be transmitted, and BSR MAC-CE.

[0089] Currently, the protocols related to group BSR do not specify which type of data the UE should prioritize for packetization in scenarios where multiple types of data to be transmitted coexist. This may result in the SRB data of the handover reconfiguration completion message not being transmitted in one RAR authorization, but instead being sent in batches using scheduling resources subsequently requested by the BSR, leading to increased handover latency.

[0090] The protocol descriptions related to group BSRs include: Description 1: When a MAC entity triggers a group packet BSR during a regular BSR or periodic BSR, there are multiple logical channel groups (LCGs) that need to report a Long BSR, as described in protocol 38321 5.4.5; Description 2: MAC entity scheduling priorities, the MAC CE priority of buffered data BSRs is higher than the priority of dedicated control channel (DCCH) data, as described in protocol 38321 5.4.3.1.3. The existence of multiple LCGs can be understood as the existence of multiple types of data to be transmitted (e.g., SRB+DRB).

[0091] Description 1 only emphasizes the conditions for judging the BSR format in the packet assembly process, but there is ambiguity regarding the timing of the BSR format judgment. It does not specify whether the BSR format is judged after authorized packet assembly scheduling or before authorized packet assembly scheduling. Description 2 also only emphasizes the priority of BSR during the scheduling process, but does not emphasize the timing of BSR format selection.

[0092] In scenarios where multiple types of data to be transmitted coexist, if the BSR format is determined before authorization packet scheduling, according to protocol specifications, a long BSR must be constructed before assembling and scheduling SRB and DRB data. Therefore, when a UE receives a small RAR authorization (e.g., unable to simultaneously transmit SRB and DRB data), it may not assemble the complete handover reconfiguration SRB data, but instead assemble a long BSR along with a portion of the DRB and reconfigured SRB data. Then, under a subsequent new authorization request for the BSR, the UE will assemble and send the remaining portion of the DRB and reconfigured SRB data to the network, causing a delay in the network's handover reconfiguration completion time and increasing handover latency.

[0093] For example, the RAR-authorized scheduling resource size is 14 bytes. Transmitting the SRB data after handover reconfiguration requires 12 bytes, transmitting DRB data requires 10 bytes, and a long BSR requires 5 bytes. Since the UE has multiple types of data to be transmitted simultaneously (which can be understood as multiple LCG data in the UE's buffer), the format of the Long BSR needs to be constructed first. This means reserving 5 bytes of resources for the BSR MACCE (e.g., bytes 10-14), and the remaining 9 bytes of scheduling resources are used for packetizing the data to be transmitted. Obviously, the remaining 9 bytes (e.g., bytes 1-9) cannot transmit the PDCP PDU data (12 bytes) carrying the reconfigured data. Instead, only a portion of the reconfigured data is packetized. In practice, the remaining reconfigured data must wait for the Long BSR to reach the network side before the network can allocate additional resources to continue sending (if it still cannot be sent completely, more scheduling resources can be requested). Therefore, when uplink authorization scheduling resources are insufficient, if the data to be transmitted on the UE side contains both reconfigured SRB data and DRB data, the handover delay will inevitably increase by one or more base station scheduling cycles, which means the handover delay will increase.

[0094] To address this, this application proposes a communication method, apparatus, and readable storage medium. During random access handover, when a UE simultaneously has multiple types of data to be transmitted, if the UE receives a small RAR grant (scheduling resource) and the control plane data (SRB data) and scheduling resources meet certain conditions, it can prioritize packetizing complete SRB data, then reserve resources for a short BSR. If there are still remaining resources, it can then packetize and schedule a portion of user plane data (DRB data) for transmission. The short BSR can be used to request scheduling resources for the remaining DRB data after packetization. Compared to the above scheme that first determines the BSR format and then performs authorization packetization and scheduling, this application prioritizes packetizing complete SRB data and then selects the BSR format for the remaining data to be transmitted, enabling complete SRB data to be transmitted in a single RAR grant, effectively reducing handover latency and improving user experience.

[0095] To better understand the communication method provided in the embodiments of this application, the technical solution of the communication method provided in the embodiments of this application will be described below with reference to more accompanying drawings.

[0096] To clearly describe the technical solution of this application, multiple embodiments will be used to illustrate the technical solution of this application, as detailed below. In this application, unless otherwise specified, the same or similar parts between various embodiments or implementations can be referenced mutually. In the various embodiments of this application, and in the various implementation methods / methods / implementations within each embodiment, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments and between the various implementation methods / methods / implementations within each embodiment are consistent and can be mutually referenced. The technical features in different embodiments and the various implementation methods / methods / implementations within each embodiment can be combined according to their inherent logical relationships to form new embodiments, implementation methods, methods, or implementation approaches. The embodiments described below do not constitute a limitation on the scope of protection of this application.

[0097] Please see Figure 2 , Figure 2 This is a flowchart illustrating a communication method provided in an embodiment of this application. The method can be applied to a first communication device, and may also involve a second and a third communication device. For ease of understanding, the first communication device is used as a terminal device (such as a UE), and the second and third communication devices are both access network devices (such as a source base station and a target base station) for illustration. The terminal device can be one of the aforementioned... Figure 1a Any terminal or module applied to that terminal; or, the terminal device can be any of the aforementioned. Figure 1b Any of the UEs in the list, such as a Relay UE or a Remote UE; or, the terminal device can be one of the aforementioned. Figure 1cAny UE in the list, such as Source UE, Relay UE, or Target UE. That is to say, the above... Figure 1a , Figure 1b as well as Figure 1c The terminal devices in the middle can be used to support and execute Figure 2 The method flow shown includes steps S200-S203. Steps S200-S203 include the following:

[0098] S200: The UE receives a Radio Resource Control (RRC) reconfiguration message sent by the source base station.

[0099] The RRC reconfiguration message can be used to instruct the UE's communication service device to switch from the source base station to the target base station. Optionally, the source base station can send a preamble (with a non-zero value) used by the UE in the RRC reconfiguration message to prevent the UE from having access sequence conflicts with other UEs during handover. It should be noted that if the preamble index decoded by the UE is all 0, the UE will perform a contention-based random access procedure.

[0100] Optionally, the target base station and the source base station can be different base stations, meaning the UE can handover between different base stations. During inter-base station handover, in addition to establishing a new communication link in the target cell, the UE also needs to perform an additional RRC connection process to determine the relevant information of the target base station and to determine whether to establish an S1 or X2 link connection. This RRC connection process requires direct communication between the source base station and the target base station. Alternatively, the target base station and the source base station can be the same base station, meaning the UE can handover between different cells under the same base station, such as handover from the source cell to the target cell. During intra-base station handover, while maintaining communication with the source cell, the UE can establish a new communication link with the target cell. The source cell and the target cell can complete the handover preparation work through inter-board message exchange without requiring direct communication between base stations, and the core network does not need to be notified after the handover is completed. For ease of understanding, this application describes the situation as the target base station and the source base station being different base stations. One base station can correspond to one cell or multiple cells, and no specific limitation is made here. Furthermore, the aforementioned target base station and source base station may belong to the same communication system (such as 3G, 4G, 5G, or 6G systems), or they may belong to different communication systems (such as the source base station belonging to a 4G system and the target base station belonging to a 5G system, or both may belong to other communication systems besides 4G and 5G systems), without specific limitations here.

[0101] S201: The UE sends a random access request to the target base station.

[0102] In this process, the UE can enter the handover phase upon receiving an RRC reconfiguration message from the source base station and send a random access request to the destination base station. Optionally, the random access procedure initiated by the UE for handover can be a contention-free random access procedure. In this case, the network side will notify the UE of the exact preamble used (which can be called a dedicated random access preamble, and the preamble value is not 0). For example, the source base station can send the preamble to the UE through an RRC reconfiguration message, ensuring that the random access procedure initiated by the UE will not conflict with the random access procedures of other UEs. Optionally, if the UE cannot perform a contention-free random access procedure, it needs to perform a contention-based random access procedure. For example, when dedicated random access preamble resources are insufficient, the source base station can notify the UE to initiate a contention-based random access procedure to the target base station. For instance, the source base station can set the preamble index to all zeros. After the UE decodes the preamble index to all zeros, it will perform a contention-based random access procedure. Optionally, if the source base station specifies multiple Physical Random Access Channel (PRACH) resources, the UE can randomly select one of the specified PRACH resources from three consecutive available subframes with PRACH channel resources to carry the random access request. After sending the preamble, the UE can wait for a random access response within the random access response window. Accordingly, the target base station will detect the preamble in the PRACH. If the source base station detects the random access preamble, it will report it to the MAC and subsequently send back the MAC's random access response within the random access response window.

[0103] S202: The UE receives the random access response sent by the target base station.

[0104] The random access response may include a first scheduling resource. The first scheduling resource authorized by the target base station is limited. The packet scope of the RAR-authorized scheduling resource may include SRB data from the handover reconfiguration completion message, DRB data to be transmitted in the user plane, and BSR MAC-CE. Subsequently, the UE can use this first scheduling resource to send data to be transmitted to the network side, and to request new uplink authorization via a transmit buffer status report (BSR). Furthermore, the random access response may also include the UE's preamble, indicating a response to the UE's random access request. The UE determines whether it has received the target base station's random access response by detecting whether the random access response carries its sent preamble. Optionally, the random access response may also include timing advance (TA) to compensate for transmission delays caused by distance during uplink transmission, ensuring that uplink data from different UEs arrives at the base station at the expected time, avoiding intra-cell interference.

[0105] S203: When the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions, the UE uses the first scheduling resource to send a first message to the target base station.

[0106] The first message includes the control plane data and a first buffer status report (BSR). The first BSR is used to request second scheduling resources to send part or all of the user plane data. The first BSR is a short BSR. The control plane data can be carried by an SRB, which is generally also called SRB data. Optionally, the SRB data includes reconfiguration completion data for handover. In this embodiment, during random access for handover, when there are multiple types of data to be transmitted on the UE side, if the first scheduling resource granted by the RAR is small and the control plane data (SRB data) to be transmitted and the first scheduling resource meet certain conditions, the UE can prioritize assembling complete SRB data and then request scheduling resources for the remaining DRB data by assembling a short BSR (such as the first BSR). This allows the complete SRB data to be sent within a single RAR-granted scheduling resource, effectively reducing handover latency.

[0107] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource. That is, in scenarios where multiple types of data to be transmitted exist simultaneously on the UE side, when the resources required to transmit the data to be transmitted (DRB data and SRB data) are greater than the first scheduling resource, while the resources required to transmit the control plane data (SRB data) and the short BSR are less than or equal to the first scheduling resource, the UE can prioritize packetizing complete SRB data and request additional scheduling resources for the remaining DRB data through the short BSR. Optionally, after the UE prioritizes packetizing complete SRB data and the short BSR, if the first scheduling resource is not fully occupied and some resources remain, the UE can also packetize and send some DRB data together to reduce uplink resource idleness. It should be noted that the total amount of resources required for data transmission can be determined based on the amount of data to be transmitted and the amount of data in the RLC header and MAC header during data packetization.

[0108] For example, the first scheduling resource size granted by RAR is 14 bytes, the resource size required for transmitting control plane data and user plane data is 20 bytes, the resource size required for transmitting control plane data is 12 bytes, and the resource size required for the short BSR is 2 bytes. The size of the first scheduling resource is insufficient to packetize and transmit all control plane data and user plane data (14 bytes is less than 20 bytes), but it is sufficient to packetize and transmit control plane data and the short BSR (14 bytes is greater than or equal to (12+2=14) bytes). Therefore, the UE can prioritize packetizing the complete control plane data and the short BSR, and the short BSR can be used to request other scheduling resources for transmitting user plane data. Optionally, if the size of the first scheduling resource is 16 bytes, which is insufficient to packetize and transmit all control plane data and user plane data, and after packetizing the complete control plane data and reserving the resources required for the short BSR, there are still 2 bytes of resources available in the first scheduling resource. At this time, the UE can packetize part of the user plane data to occupy these 2 bytes of scheduling resources, and the short BSR can be used to request scheduling resources to send the remaining part of the user plane data.

[0109] For example, the method of prioritizing the packaging of control plane data and short BSRs for scheduling resources can be referred to Figure 3 , Figure 3 This is a schematic diagram of a packet scheduling format provided in an embodiment of this application. The first scheduling resource size is 14 bytes, the control plane data to be transmitted is 6 bytes, the resource size required to transmit this control plane data is 12 bytes, the control plane data itself is 6 bytes (e.g., bytes 7-12), the PDCP header occupies 2 bytes (e.g., bytes 5-6), the RLC header occupies 2 bytes (e.g., bytes 3-4), and the MAC header occupies 2 bytes (e.g., bytes 1-2). In addition, constructing a short BSR requires 2 bytes (e.g., bytes 13-14). For example, (1) the MAC header may include the following fields:

[0110] R: Reserved space, field length is 1 bit, usually set to 0.

[0111] F: Indicates the size of the length field. Each MAC subheader has an F field, except for the subheaders corresponding to the fixed-size MAC CE, padding, and the MAC SDU including the Uplink Common Control Channel (UL CCCH). The F field is typically 1 bit in size; a value of 0 indicates an 8-bit length field, and a value of 1 indicates a 16-bit length field. Figure 3 The value of the F field is 0, and the length field is 8 bits (corresponding to Byte2).

[0112] LCID: Logical Channel Identity (LCID) field, identifies the logical channel instance of the corresponding MAC SDU or the corresponding MAC CE or padding type. Each MAC subheader has an LCID field, which is typically 6 bits in size.

[0113] L: Length field, indicating the length (in bytes) of the corresponding MAC SDU or variable-size MAC CE. Each MAC subheader has an L field, except for the subheaders corresponding to fixed-size MAC CEs, padding, and MAC SDUs containing UL CCCHs. The size of the L field is indicated by the F field.

[0114] (2) The RLC header may include the following fields:

[0115] D / C: Data / Control (D / C) field, indicating the PDU type identifier, specifying whether the current RLC PDU is an RLC data PDU or an RLC control PDU. A value of 0 in the D / C field indicates that the current RLC PDU is a control PDU, and a value of 1 in the D / C field indicates that the current RLC PDU is a data PDU.

[0116] P: Indicates whether the RLC entity sends a status report, typically a polling bit of 1 bit length. A value of 0 for the P field indicates "status report not requested", and a value of 1 for the P field indicates "status report requested".

[0117] SI: Segment Information (SI) field, indicating the segmentation status of the data field. The field length can be 2 characters, and the meanings of each value are as follows:

[0118] 00: Indicates that the data field contains all bytes of the RLC SDU;

[0119] 01: Indicates that the data field contains the first segment of the RLC SDU;

[0120] 10: Indicates that the data field contains the last segment of the RLC SDU;

[0121] 11: Indicates that the data field does not contain the first and last segments of the RLC SDU.

[0122] SN: Serial Number (SN) field, representing the serial number of the RLC SDU. For AMD PDUs, the SN field can be 12 bits or 18 bits long, while the SRB can be configured to be 12 bits.

[0123] (3) The PDCP header may include the following fields:

[0124] R: Reserved space, field length can be 4 bits.

[0125] PDCP SN: PDCP sequence number field, which represents the sequence number of the transmitted data. The length can be configured to 12 bits.

[0126] (4) Short BSRs may include the following fields:

[0127] R: Reserved space, the field length can be 2 bits.

[0128] LCID: Logical Channel Identity (LCID) field, identifies the type of BSR, and its length can be configured to 8 bits. LCID(61) represents a short BSR, and LCID(62) represents a long BSR. Figure 3 The value of the LCID field is 61, indicating that the BSR is a short BSR.

[0129] LCG ID: Indicates the requested logical channel group ID, with a length that can be configured to 3 bits, corresponding to LCG0-LCG7 respectively.

[0130] Buffersize: The buffer size field indicates the amount of data to be transmitted. The length can be configured to 5 bits.

[0131] Furthermore, after the UE assembles complete control plane data and reserves the resources required for the short BSR, there are still remaining scheduling resources available. When the UE assembles a portion of the user plane data into the packet and uses these remaining scheduling resources, it can use an additional 2 bytes of resources in the RLC header to indicate the user plane data, where the D / C field value is 1. Alternatively, the UE can extend the D / C field in the RLC header to 2 bits (with other fields reduced accordingly, such as reducing the SN field by 1 bit), using the 2-bit D / C field to indicate whether the current RLC PDU is an RLC data PDU, an RLC control PDU, or a combination of both; no specific limitation is made here.

[0132] Optionally, the condition that the size of the control plane data and the size of the first scheduling resource satisfy a preset condition further includes: the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource. In other words, when the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource, there may be a situation where the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource. In this case, if the long BSR is constructed first (i.e., resources are reserved for the long BSR), the remaining portion of the first scheduling resource will inevitably be insufficient to transmit the control plane data, causing the control plane data to be sent in one or more subsequent grants, increasing the handover latency. Therefore, in this situation, the UE can prioritize assembling the complete control plane data and construct a short BSR (since the control plane data has been assembled, only user plane data remains) to request scheduling resources for the remaining user plane data, ensuring that the control plane data can be transmitted in full within the scheduling resources of one uplink grant, reducing the handover latency.

[0133] Optionally, when the resources required to transmit the control plane data and the long BSR are less than or equal to the first scheduling resources, the first message also includes a portion of the user plane data, and the first BSR is used to request second scheduling resources to send other portions of the user plane data. In other words, when the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resources, there may be a situation where the resources required to transmit the control plane data and the long BSR are less than or equal to the first scheduling resources, meaning that the first scheduling resources are not only sufficient to transmit the complete control plane data and the short BSR, but may even be sufficient to transmit the complete control plane data and the long BSR. In this case, if the long BSR is constructed first (i.e., resources are reserved for the long BSR) and the complete control plane data is packaged, the long BSR can only request scheduling resources for the user plane data (because the control plane data has been fully packaged), and some fields in the long BSR are left empty (such as fields originally used to indicate / request resources related to the control plane data), resulting in wasted resources or potentially causing confusion in the packaging logic and transmission errors. Therefore, in this situation, the UE can prioritize assembling complete control plane data, construct a short BSR, and use the remaining first scheduling resources to transmit part of the user plane data (i.e., the first message also includes part of the user plane data). The short BSR can request scheduling resources for the remaining user plane data, reducing the waste caused by resource idling, minimizing the number of rounds of user plane data transmission, and improving the timeliness of user plane data.

[0134] In one possible implementation, when the data to be transmitted includes user plane data and control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources. The second message includes a portion of the control plane data and a second BSR. The second BSR is used to request third scheduling resources for transmitting other portions of the control plane data and for transmitting some or all of the user plane data. The second BSR is a long BSR. That is, when the first scheduling resources are insufficient to transmit control plane data and the short BSR simultaneously, the UE can prioritize packetizing a portion of the control plane data and simultaneously request third scheduling resources for the remaining control plane data and user plane data through a long BSR (such as the second BSR). Further optionally, when the third scheduling resources are insufficient to simultaneously complete the transmission of the remaining control plane data and user plane data, the UE can refer to the above S203 step, prioritize packetizing the remaining control plane data, and then request scheduling resources for the user plane data through the short BSR, minimizing the scheduling rounds for transmitting complete control plane data and reducing handover latency.

[0135] For example, the first scheduling resource size authorized by RAR is 14 bytes, the resource size required for transmitting control plane data and user plane data is 20 bytes, the resource size required for transmitting control plane data is 14 bytes, the control plane data size is 8 bytes, the resource size required for the short BSR is 2 bytes, and the resource size required for the long BSR is 5 bytes. The first scheduling resource size is insufficient to packetize and transmit control plane data and the short BSR (14 bytes is less than (14+2=16) bytes). Therefore, the UE can reserve scheduling resources (5 bytes) for the long BSR and prioritize packetizing a portion of the control plane data using the remaining scheduling resources (9 bytes). The long BSR can be used to request scheduling resources for the remaining control plane data and user plane data. Furthermore, after obtaining new scheduling resources through the long BSR, the UE can prioritize packetizing the remaining control plane data and then packetize the user plane data for transmission.

[0136] For methods of prioritizing the grouping of control plane data and long BSRs for resource scheduling, please refer to [the relevant documentation / reference]. Figure 4 , Figure 4This is a schematic diagram of another packet scheduling format provided in this application embodiment. The first scheduling resource size is 14 bytes, the control plane data to be transmitted is 8 bytes, the resource size required to transmit this control plane data is 14 bytes, the control plane data itself is 8 bytes, and the PDCP header, RLC header, and MAC header each occupy 2 bytes. The first scheduling resource is insufficient to transmit the control plane data and the short BSR. Therefore, the UE can construct a long BSR occupying 5 bytes (e.g., bytes 10-14), while packetizing a portion of the control plane data occupying the remaining first scheduling resource, where the control plane data occupies 3 bytes (e.g., bytes 7-9), the PDCP header occupies 2 bytes (e.g., bytes 5-6), the RLC header occupies 2 bytes (e.g., bytes 3-4), and the MAC header occupies 2 bytes (e.g., bytes 1-2). Understandably, the relevant descriptions of the various fields in the MAC header, RLC header, and PDCP header can be found above. Figure 3 The corresponding explanations will not be repeated here. Long BSRs may include the following fields:

[0137] R: Reserved space, the field length can be 2 bits.

[0138] LCID: Logical Channel Identity (LCID) field, identifies the type of BSR, and its length can be configured to 8 bits. LCID(61) represents a short BSR, and LCID(62) represents a long BSR. Figure 3 The value of the LCID field is 62, indicating that the BSR is a long BSR.

[0139] LCG x (e.g., LCG0-7): Indicates the logical channel group ID of the request. The length of each LCG x can be configured to 1 bit. A value of 0 for LCG x indicates no request, and a value of 1 for LCG x indicates a request.

[0140] Buffersizex: Buffer size field, indicating the size of the data to be transmitted. The length can be configured to 8 bits. For example, Buffersize 1 (e.g., Byte13) indicates the size of the control plane data, and Buffersize 2 (e.g., Byte14) indicates the size of the user plane data.

[0141] Understandably, when the resources required to transmit the data to be transmitted (which may include control plane data and user plane data, or may include only control plane data) are less than or equal to the first scheduling resource, the UE can packetize the data to be transmitted and send it without needing to apply for additional scheduling resources using BSR.

[0142] It should be noted that during the handover process, the data to be transmitted on the UE side may include multiple types of data (control plane data and user plane data), or it may only include one type of data (control plane data). In other words, before the handover, the UE may have already transmitted all the user plane data that needs to be transmitted through the source base station, and only the control plane data is waiting to be transmitted during the handover process.

[0143] In one possible implementation, when the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources. The third message includes a portion of the control plane data and a third BSR (Background Scheduler). The third BSR is used to request fourth scheduling resources to transmit other portions of the control plane data, and the third BSR is a short BSR. That is, in a scenario where the data to be transmitted on the UE side only includes control plane data, when the first uplink-authorized scheduling resources are insufficient to transmit the control plane data, the UE can first assemble a portion of the control plane data and request scheduling resources for the remaining control plane data by constructing a short BSR (such as a third BSR), and then transmit the remaining control plane data on subsequently authorized scheduling resources.

[0144] For example, the first scheduling resource size granted by RAR is 10 bytes, the resource size required for transmitting control plane data is 12 bytes (e.g., the control plane data itself is 6 bytes, the PDCP header occupies 2 bytes, the RLC header occupies 2 bytes, and the MAC header occupies 2 bytes), the data to be transmitted on the UE side does not contain user plane data, and the resource size required for the short BSR is 2 bytes. The size of the first scheduling resource is insufficient to packetize and transmit all the control plane data (10 bytes is less than 12 bytes), so the UE can packetize a portion of the control plane data (e.g., 2 bytes of data) and the short BSR, and request scheduling resources (e.g., the fourth scheduling resource) to send the remaining control plane data (e.g., 4 bytes of data) through the short BSR. If the size of the fourth scheduling resource is greater than or equal to 10 bytes, the UE can transmit the remaining 4 bytes of control plane data in packets on the fourth scheduling resource (PDCP header, RLC header, and MAC header each occupy 2 bytes); if the size of the fourth scheduling resource is less than 10 bytes, the UE cannot transmit the remaining 4 bytes of control plane data in packets on the fourth scheduling resource, but can packetize part of the control plane data and a short BSR (and then request additional scheduling resources to send the control plane data that could not be sent).

[0145] It should be noted that the specific values ​​of the scheduling resources, control plane data, user plane data, short BSR, and long BSR mentioned above are merely exemplary descriptions for the convenience of illustrating the embodiments of this application, and should not constitute a specific limitation on the embodiments of this application.

[0146] The foregoing describes the method provided in this application. In order to facilitate the implementation of the above-described solutions in the embodiments of this application, the embodiments of this application also provide corresponding devices or equipment.

[0147] This application divides the device into functional modules according to the above method embodiments. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation. The device of the embodiments of this application will be described below with reference to the accompanying drawings.

[0148] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. The communication device 10 can be used to implement the function of the first communication device involved in any of the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0149] like Figure 5 As shown, the communication device 10 may include a receiving unit 100 and a transmitting unit 101. The functions of each unit are as follows:

[0150] The receiving unit 100 is configured to receive a Radio Resource Control (RRC) reconfiguration message sent by the second communication device; the RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device.

[0151] The sending unit 101 is used to send a random access request to the third communication device;

[0152] The receiving unit 100 is further configured to receive a random access response sent by the third communication device; the random access response includes a first scheduling resource.

[0153] The sending unit 101 is further configured to send a first message to the third communication device using the first scheduling resource when the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions; the first message includes the control plane data and a first BSR; the first BSR is used to request a second scheduling resource for sending part or all of the data in the user plane data, and the first BSR is a short BSR.

[0154] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource.

[0155] In one possible implementation, the size of the control plane data and the size of the first scheduling resource satisfy a preset condition, and further includes: the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource.

[0156] In one possible implementation, the first message further includes a portion of the user plane data, and the first BSR is used to request a second scheduling resource to send other portions of the user plane data.

[0157] In one possible implementation, the sending unit 101 is further configured to:

[0158] When the data to be transmitted includes the user plane data and the control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources; the second message includes part of the control plane data and the second BSR; the second BSR is used to request third scheduling resources to transmit other parts of the control plane data and part or all of the user plane data, and the second BSR is a long BSR.

[0159] In one possible implementation, the sending unit 101 is further configured to:

[0160] When the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources; the third message includes part of the control plane data and a third BSR, the third BSR is used to request a fourth scheduling resource to transmit other parts of the control plane data, and the third BSR is a short BSR.

[0161] It should be noted that the functions of each functional unit / module in the communication device described in the embodiments of this application can be found in the relevant descriptions in the above method embodiments, and will not be repeated here.

[0162] Understandably, the specific descriptions of the transmitting and receiving units shown in the above device embodiments are merely examples. For the specific functions or execution steps of the transmitting and receiving units, please refer to the description of any of the above method embodiments, which will not be detailed here.

[0163] The communication device according to embodiments of this application has been described above. The following describes possible product forms of the communication device. It should be understood that any device possessing the above-described features... Figure 5 Any form of the communication device described herein falls within the protection scope of the embodiments of this application. It should also be understood that the following description is merely illustrative and does not limit the form of the communication device in the embodiments of this application to this specific example.

[0164] In one possible implementation, the above Figure 5 In the communication device shown, the receiving unit 100 and the transmitting unit 101 can be transceivers; or, the receiving unit 100 can be a receiver and the transmitting unit 101 can be a transmitter. In this embodiment, the communication device may further include a processor, which can be used to process information received by the transceiver or generate information transmitted by the transceiver. The processor and transceiver can be coupled, etc. This embodiment does not limit the connection method between the processor and the transceiver. During the execution of the above method, the process of transmitting information can be understood as the process of the processor outputting the information. When outputting the information, the processor outputs the information to the transceiver so that the transceiver can transmit it. After the information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, the process of receiving information in the above method can be understood as the process of the processor receiving the input information. When the processor receives the input information, the transceiver receives the information and inputs it to the processor. Furthermore, after the transceiver receives the information, the information may need to undergo other processing before being input to the processor.

[0165] See Figure 6 , Figure 6 This is a schematic diagram of another communication device provided in an embodiment of this application. The communication device 20 can be the communication device 10, or a chip therein. Figure 6 Only the main components of the communication device 20 are shown. In addition to the processor 1001, the communication device 20 may optionally further include a transceiver 1002, a memory 1003, or an input / output device (not shown).

[0166] The processor 1001 is mainly used to process communication protocols and communication data, control the entire communication device, execute software programs, and process the data of the software programs. The memory 1003 is mainly used to store software programs and data. The transceiver 1002 may include control circuitry and an antenna. The control circuitry is mainly used for converting baseband signals to radio frequency signals and processing radio frequency signals. The antenna is mainly used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are mainly used to receive user input data and output data to the user.

[0167] When the communication device is powered on, the processor 1001 can read the software program in the memory 1003, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor 1001 performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit processes the baseband signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor 1001. The processor 1001 converts the baseband signal into data and processes the data.

[0168] In another implementation, the radio frequency circuitry and antenna can be set up independently of the processor performing baseband processing. For example, in a distributed scenario, the radio frequency circuitry and antenna can be arranged remotely, independent of the communication device.

[0169] Transceiver 1002 may include a receiver for performing a receiving function (or operation) and a transmitter for performing a transmitting function (or operation). The transceiver is also used for communicating with other devices / appliances via a transmission medium.

[0170] The processor 1001, transceiver 1002, and memory 1003 can be connected via a communication bus.

[0171] For example, when the communication device 20 is used to perform the steps, methods, or functions involved in the first communication device described above, the transceiver 1002 can be used to receive a Radio Resource Control (RRC) reconfiguration message sent by the second communication device; the RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device; the transceiver 1002 is also used to send a random access request to the third communication device; the transceiver 1002 is also used to receive a random access response sent by the third communication device; the random access response includes a first scheduling resource; the transceiver 1002 is also used to send a first message to the third communication device using the first scheduling resource when the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions; the first message includes the control plane data and a first BSR; the first BSR is used to request a second scheduling resource to send part or all of the data in the user plane data, and the first BSR is a short BSR. Optionally, the processor 1001 can be used to process information received by the transceiver 1002 or generate information sent by the transceiver 1002; the memory 1003 can be used to store data necessary for the operation of the above-mentioned communication device and related data during the data processing process.

[0172] Understandably, further details regarding the processor and transceiver can be found above. Figure 5 The descriptions of the processing unit and the transmitting unit in the device embodiments involved will not be repeated here.

[0173] Optionally, the processor 1001 may include a transceiver for implementing receiving and transmitting functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit can be used for reading and writing code / data, or it can be used for transmitting or relaying signals.

[0174] Optionally, the processor 1001 may store instructions, which may be a computer program. The computer program, running on the processor 1001, causes the communication device 20 to perform the methods described in the above method embodiments. The computer program may be embedded in the processor 1001; in this case, the processor 1001 may be implemented in hardware.

[0175] In one implementation, the communication device 20 may include circuitry capable of performing the functions of transmitting, receiving, or communicating as described in the aforementioned method embodiments. The processor and transceiver described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal-oxide semiconductors (CMOS), n-metal-oxide-semiconductor (NMOS), p-type metal-oxide semiconductors (PMOS), bipolar junction transistors (BJTs), bipolar CMOS (BiCMOS), silicon-germanium (SiGe), gallium arsenide (GaAs), etc.

[0176] Understandably, the communication device shown in the embodiments of this application may also have more than Figure 6 This application does not limit the use of other components or other related elements. The methods performed by the processor and transceiver described above are merely examples; for the specific steps performed by the processor and transceiver, please refer to the description of the method embodiments above.

[0177] In another possible implementation, Figure 5 In the communication device involved, the processing unit can be one or more logic circuits; the receiving unit 100 and the transmitting unit 101 can be input / output interfaces, or communication interfaces, or interface circuits, or interfaces, etc. Alternatively, the transmitting unit can be an output interface, and the receiving unit can be an input interface, with the transmitting and receiving units integrated into one unit, such as an input / output interface. See also Figure 7 , Figure 7 This is a schematic diagram of the structure of another communication device provided in the embodiments of this application. For example... Figure 7As shown, the communication device 30 includes a logic circuit 901 and an interface 902. That is, the processing unit can be implemented using the logic circuit 901, and the receiving unit 100 and the transmitting unit 101 can be implemented using the interface 902. The logic circuit 901 can be a chip, processing circuit, integrated circuit, or system-on-chip (SoC) chip, etc., and the interface 902 can be a communication interface, input / output interface, pins, etc. For example, Figure 7 The above-mentioned communication device 30 is used as an example of a chip, which includes a logic circuit 901 and an interface 902.

[0178] In this embodiment, the logic circuit and the interface can also be coupled to each other. The specific connection method between the logic circuit and the interface is not limited in this embodiment.

[0179] For example, when the communication device 30 is used to execute the method, function, or step involved in the first communication device described above, interface 902 is used to receive a Radio Resource Control (RRC) reconfiguration message sent by the second communication device; the RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device; interface 902 is also used to send a random access request to the third communication device; interface 902 is also used to receive a random access response sent by the third communication device; the random access response includes a first scheduling resource; interface 902 is also used to send a first message to the third communication device using the first scheduling resource when the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions; the first message includes the control plane data and a first BSR; the first BSR is used to request a second scheduling resource to send part or all of the data in the user plane data, and the first BSR is a short BSR. Optionally, logic circuit 901 can be used to generate the message sent by interface 902 or process the message received by interface 902.

[0180] Understandably, the specific descriptions of logic circuit 901 and interface 902 can also be found above. Figure 5 The descriptions of the processing unit, transmitting unit, and receiving unit involved in the device embodiments are not repeated here.

[0181] It is understood that the communication device shown in the embodiments of this application can implement the method provided in the embodiments of this application in hardware form or in software form, etc., and the embodiments of this application do not limit it in this way.

[0182] for Figure 7 For specific implementations of the various embodiments shown, please refer to the above embodiments, which will not be described in detail here.

[0183] In addition, this application also provides a computer program for implementing the operations and / or processes performed by the communication device 10, communication device 20, and communication device 30 in the method provided in this application.

[0184] This application also provides a readable storage medium storing computer code that, when executed on a computer, causes the computer to perform the operations and / or processes performed by the communication device 10, communication device 20, and communication device 30 in the method provided in this application.

[0185] This application also provides a computer program product, which includes computer code or a computer program that, when run on a computer, causes the operations and / or processes performed by communication device 10, communication device 20, and communication device 30 in the method provided in this application to be executed.

[0186] This application also provides a chip system including a processor for supporting the device in implementing the functions involved in any of the above embodiments, such as generating or processing information involved in the above communication methods. In one possible design, the chip system further includes a memory for storing necessary program instructions and data for the device. This chip system may be composed of chips or may include chips and other discrete devices.

[0187] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0188] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0189] In the several embodiments provided in this application, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, or it may be an electrical, mechanical or other form of connection.

[0190] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, Applied to a first communication device; the method includes: Receive a Radio Resource Control (RRC) reconfiguration message sent by the second communication device; the RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device; Send a random access request to the third communication device; Receive a random access response sent by the third communication device; the random access response includes a first scheduling resource; When the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions, a first message is sent to the third communication device using the first scheduling resource; the first message includes the control plane data and a first buffer status report (BSR), the first BSR is used to request a second scheduling resource to send part or all of the data in the user plane data, and the first BSR is a short BSR.

2. The method as described in claim 1, characterized in that, The size of the control plane data and the size of the first scheduling resource meet preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource.

3. The method as described in claim 2, characterized in that, The condition that the size of the control plane data and the size of the first scheduling resource meet preset conditions also includes that the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource.

4. The method according to any one of claims 1-3, characterized in that, The first message also includes a portion of the user plane data, and the first BSR is used to request a second scheduling resource to send other portions of the user plane data.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: When the data to be transmitted includes the user plane data and the control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources; the second message includes part of the control plane data and the second BSR; the second BSR is used to request third scheduling resources to transmit other parts of the control plane data and part or all of the user plane data, and the second BSR is a long BSR.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: When the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources; the third message includes part of the control plane data and a third BSR, the third BSR is used to request a fourth scheduling resource to transmit other parts of the control plane data, and the third BSR is the short BSR.

7. A first communication device, characterized in that, include: The receiving unit is used to receive Radio Resource Control (RRC) reconfiguration messages sent by the second communication device; The RRC reconfiguration message is used to instruct the communication service device of the first communication device to switch from the second communication device to the third communication device; The sending unit is used to send a random access request to the third communication device; The receiving unit is further configured to receive a random access response sent by the third communication device; the random access response includes a first scheduling resource. The transmitting unit is further configured to send a first message to the third communication device using the first scheduling resource when the data to be transmitted includes user plane data and control plane data, and the size of the control plane data and the size of the first scheduling resource meet preset conditions; the first message includes the control plane data and a first BSR; the first BSR is used to request a second scheduling resource for transmitting part or all of the data in the user plane data, and the first BSR is a short BSR.

8. The apparatus as claimed in claim 7, characterized in that, The size of the control plane data and the size of the first scheduling resource meet preset conditions, including: the resources required to transmit the data to be transmitted are greater than the first scheduling resource, and the resources required to transmit the control plane data and the short BSR are less than or equal to the first scheduling resource.

9. The apparatus as claimed in claim 8, characterized in that, The condition that the size of the control plane data and the size of the first scheduling resource meet preset conditions also includes that the resources required to transmit the control plane data and the long BSR are greater than the first scheduling resource.

10. The apparatus according to any one of claims 7-9, characterized in that, The first message also includes a portion of the user plane data, and the first BSR is used to request a second scheduling resource to send other portions of the user plane data.

11. The apparatus according to any one of claims 7-10, characterized in that, The transmitting unit is further configured to: When the data to be transmitted includes the user plane data and the control plane data, and the resources required to transmit the control plane data and the short BSR are greater than the first scheduling resources, a second message is sent to the third communication device using the first scheduling resources; the second message includes part of the control plane data and the second BSR; the second BSR is used to request third scheduling resources to transmit other parts of the control plane data and part or all of the user plane data, and the second BSR is a long BSR.

12. The apparatus according to any one of claims 7-11, characterized in that, The transmitting unit is further configured to: When the data to be transmitted includes the control plane data, and the resources required to transmit the control plane data are greater than the first scheduling resources, a third message is sent to the third communication device using the first scheduling resources; the third message includes part of the control plane data and a third BSR, the third BSR is used to request a fourth scheduling resource to transmit other parts of the control plane data, and the third BSR is a short BSR.

13. A communication device, characterized in that, The device includes a processor and an interface circuit, wherein the interface circuit is used to receive signals from other communication devices and transmit them to the processor or to send signals from the processor to other communication devices, and the processor is used to implement the method as described in any one of claims 1-6 through logic circuits or executing code instructions.

14. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions, which, when executed by a communication device, implement the method as described in any one of claims 1-6.

15. A computer program, characterized in that, The computer program includes instructions that, when executed by a communication device, implement the method as described in any one of claims 1-6.

Images