Communication method and communication apparatus

Abstract

The application provides a communication method and a communication device, and belongs to the field of communication. In the method, a first device sends indication information to a second device, the indication information being used for indicating a first lower edge of a sending window, the first lower edge being a lower edge updated based on a lower edge of the sending window by a first status report constructed by a media access control (MAC) layer of the first device; the second device sends a second status report to the first device, the second status report including a lower edge of a receiving window of the second device; and the first lower edge of the sending window is updated to a second lower edge, the second lower edge being the same as the lower edge of the receiving window. The method can correct errors caused by fast window pushing and realize reliable fast window pushing.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a communication method and a communication device. Background Technology

[0002] In 5G (5G) new radio access technology (NR) systems, a dual-layer retransmission mechanism ensures data transmission reliability. Specifically, the medium access control (MAC) layer employs a hybrid automatic repeat request (HARQ) mechanism, where the transmitter performs rapid incremental redundant retransmissions, and the receiver improves the decoding success probability through soft combining of multiple transmissions. Simultaneously, the radio link control (RLC) layer uses an automatic repeat request (ARQ) mechanism to retransmit data that failed to be transmitted by the HARQ mechanism. This layered design aims to balance the requirements of low latency and high reliability. The HARQ mechanism corrects most errors within milliseconds, while the ARQ mechanism compensates for residual errors uncorrected by the HARQ mechanism over a longer time scale. The two mechanisms complement each other to meet overall reliability requirements.

[0003] Currently, the sending end can only push the sending window based on the traditional status report sent by the receiving end. However, the receiving end only sends the traditional status report when the reassembly timer expires. Therefore, the sending window can only be pushed after the reassembly timer expires, resulting in a slow window pushing speed, which is difficult to meet the more stringent low-latency requirements of 6th generation (6G) systems. Therefore, how to achieve reliable and fast window pushing has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a communication method and a communication device. The method can correct errors caused by rapid window pushing and achieve reliable rapid window pushing.

[0005] In a first aspect, a communication method is provided. This method can be executed by a first device, or by a component (such as a circuit, chip, or chip system) configured in the first device, or by a logic module or software capable of implementing all or part of the functions of the first device. This application does not limit this approach. The following description uses the first device as an example.

[0006] The method includes: a first device sending indication information to a second device, the indication information indicating a first lower edge of a sending window, the first lower edge being the updated lower edge of the sending window based on a first status report constructed by the MAC layer of the first device; the first device receiving a second status report from the second device, the second status report including the lower edge of the receiving window of the second device; and the first device updating the first lower edge of the sending window to a second lower edge, the second lower edge being the same as the lower edge of the receiving window.

[0007] Optionally, the first status report refers to the status report constructed by the MAC layer of the first device, used to notify the first device's RLC layer that the RLC PDU corresponding to the first transport block has been successfully transmitted. This first status report can also be called an ACK inter-layer report.

[0008] Optionally, the first status report is constructed based on HARQ feedback. The second status report is determined based on indication information. Alternatively, the second status report is sent based on indication information.

[0009] Optionally, the second status report is sent by the second device when the lower edge of the first lower edge and the lower edge of the receiving window are different.

[0010] In the above technical solution, the first device can update the lower edge of the sending window to the first lower edge based on the first status report constructed at the MAC layer, without waiting for the second device to send a traditional status report before pushing the sending window, thus achieving fast window pushing. Simultaneously, to avoid errors in fast window pushing, the first device also sends an indication message to the second device. This indication message informs the second device of the update status of the lower edge of the sending window, allowing the second device to be aware of the update status. Upon receiving the indication message, the second device can determine whether an error has occurred in the first device's fast window pushing and sends a second status report to the first device. Upon receiving this second status report, the first device can confirm that the previous fast window pushing was erroneous, and promptly update the lower edge of the sending window from the first lower edge to the second lower edge, achieving timely correction of the fast window pushing error, synchronizing the sending and receiving windows, and ultimately achieving reliable fast window pushing.

[0011] In conjunction with the first aspect, in some possible implementations, the above method further includes: updating the lower edge of the sending window to the aforementioned first lower edge when the first timer times out; wherein the aforementioned first timer is started when the RLC layer of the first device receives the first status report and the first timer has not been started.

[0012] Optionally, if the first timer times out, the lower edge of the sending window is updated to the first lower edge, and an indication message is sent to the second device.

[0013] The above technical solution updates the lower edge of the sending window to the first lower edge only when the first timer times out, thus avoiding the high-frequency triggering of the first state report to push the sending window.

[0014] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the shutdown condition of the first timer includes at least one of the following: A second status report was received from the second device; A third status report is received from the second device. The third status report is a status report sent by the second device in the event of a recombination timer timeout. The third status report includes the reception status of the expected RLC PDU. The first timer mentioned above has timed out.

[0015] In combination with the first aspect and the above implementation, in some possible implementations, the above method further includes: deleting the first RLC PDU when the second timer times out and no second status report is received, wherein the sequence number of the first RLC PDU is less than the first lower edge of the transmission window; wherein the second timer is started when an indication message is sent to the second device.

[0016] In the above technical solution, if the second timer times out and no second status report is received, the first device can determine that no error has occurred in the fast window push (also known as the virtual window push). At this time, the first device can determine that the first lower edge is a real lower edge or a correct lower edge. Therefore, the first device will delete the first RLC PDU with a sequence number less than the first lower edge. In this way, the first device can delete the first RLC PDU only after ensuring that no error has occurred in the fast window push, avoiding data loss caused by rapidly pushing the transmission window and improving the reliability of the fast window push.

[0017] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the shutdown condition of the second timer includes at least one of the following: A second status report was received from the second device; A third status report is received from the second device. The third status report is a status report sent by the second device in the event of a recombination timer timeout. The third status report includes the reception status of the expected RLC PDU. The second timer timed out.

[0018] The above technical solution sets flexible shutdown conditions for both the first and second timers, including shutdown after timeout and other shutdown conditions. Since both the second and third status reports are reliable and protected by CRC, if the first device receives either the second or third status report, it means that the actual window push can be performed based on the reliable second or third status report, without needing to rely on the ACK inter-layer report (i.e., the first status report) to perform the virtual window push. Therefore, the first and second timers can be shut down promptly, avoiding unnecessary timer waiting and virtual window push operations, and improving the reliability of window state updates.

[0019] In combination with the first aspect and the above implementation, in some possible implementations, the first status report includes the sequence number of at least one RLC PDU; if the sequence number of at least one RLC PDU includes a third lower edge and the Radio Link Control Service Data Unit (RLC SDU) corresponding to the third lower edge has been successfully transmitted, the first lower edge is the sequence number corresponding to the first RLC SDU that was not completely transmitted after the third lower edge, and the third lower edge is the lower edge of the transmission window before the update.

[0020] The above technical solution, since the first status report includes the third lower edge and the RLC SDU corresponding to the third lower edge has been successfully sent, indicates that the RLC SDU at the lower edge of the sending window before the update has been confirmed to have been successfully transmitted. Therefore, determining the first lower edge as the sequence number corresponding to the first incompletely sent RLC SDU after the third lower edge can enable the lower edge of the sending window to be accurately advanced to the next RLC SDU that still needs to be processed. This avoids incorrect window pushing due to incomplete segmentation and also avoids window blocking caused by insufficient advancement.

[0021] In combination with the first aspect and the above implementation, in some possible implementations, the above method further includes: deleting the second RLC PDU, wherein the sequence number of the second RLC PDU is less than the second lower edge of the sending window.

[0022] The above technical solution updates the first lower edge of the sending window to the second lower edge, which is the actual result of window pushing and there is no window pushing error. Therefore, after updating the first lower edge of the sending window to the second lower edge, the second RLC PDU can be deleted directly to release the cache space in time.

[0023] In combination with the first aspect and the above implementation, in some possible implementations, the above indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the above first lower edge.

[0024] The above technical solution reduces the overhead of additional control signaling and improves transmission efficiency by carrying the indication information in the header of the third RLC PDU.

[0025] In combination with the first aspect and the above implementation, in some possible implementations, the above method further includes: when the RLC layer of the first device receives the first status report, updating the lower edge of the transmission window to the first lower edge, and retransmitting the third RLC PDU.

[0026] In the above technical solution, after the virtual window is pushed, the first device can promptly retransmit the third RLCPDU with the sequence number of the first lower edge, and synchronously notify the second device of the update status of the sending window through the indication information carried in the header, so that the second device can promptly trigger the second status report, which is conducive to timely correction of errors that may occur in the virtual window.

[0027] In combination with the first aspect and the above implementation, in some possible implementations, the first status report includes at least one RLC PDU sequence number; the above method further includes: setting the status flag of the RLC PDU corresponding to the sequence number to a first value, the first value being used to indicate that the RLC PDU transmission was successful.

[0028] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the second status report further includes: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status, wherein the first status is used to indicate that the RLC PDU is in a state where transmission is confirmed to be successful, and the second status is used to indicate that the RLC PDU is in a state where transmission is not confirmed to be successful by the second device; the method further includes: deleting the RLC PDU when the status flag of the RLC PDU is a first value and the sequence number of the RLC PDU corresponds to the first status; and retransmitting the RLC PDU when the status flag of the RLC PDU is a first value and the sequence number of the RLC PDU corresponds to the second status.

[0029] The above technical solution, by comparing the status of the RLC PDU in the second status report with the status flag set for the RLCPDU based on the first status report, helps the first device to detect the error of NACK turning into ACK more quickly and earlier, thereby accelerating retransmission.

[0030] In combination with the first aspect and the above implementation, in some possible implementations, the above method further includes: the MAC layer of the first device receiving feedback information from the second device, the feedback information being used to indicate whether the MAC subPDU in the first transport block has been successfully transmitted; the MAC layer of the first device constructing a first status report based on the feedback information, the logical channel number in the MAC subheader of the MAC subPDU, and the sequence number of the RLC PDU in the MAC subheader.

[0031] Optionally, the feedback information is a HARQ feedback sent by the second device to the first device at the physical layer for the first transport block. The HARQ feedback indicates the decoding status of the first transport block.

[0032] The above technical solution provides coarse-grained feedback information at the TB level, indicating whether the entire first transport block was successfully decoded or failed. The first status report, however, converts the feedback information into fine-grained status at the RLC PDU level. By parsing the LCID and RLC PDU sequence number in the MAC subheading, the MAC layer of the first device implements an information mapping from "first transport block successfully transmitted" to "which specific RLC PDUs were successfully transmitted." Through the aforementioned first status report, a close interaction is established between HARQ and ARQ. In traditional architectures, HARQ and ARQ operate relatively independently, with ARQ typically relying on the reassembly timer to time out before detecting packet loss, resulting in significant feedback and retransmission delays. The above technical solution, through the first status report, enables the ARQ entity at the RLC layer to utilize the rapid feedback from HARQ to achieve fast windowing and fast retransmission, thereby reducing data transmission latency.

[0033] In combination with the first aspect and the above implementation, in some possible implementations, receiving the second status report from the second device includes: receiving the second status report from the second device when the first lower edge is greater than the lower edge of the receiving window.

[0034] In the above technical solution, considering that the second device's RLC layer maintains its own receiving window, if the first lower edge is greater than the lower edge of the receiving window, it indicates that the sending window and the receiving window are out of sync. If the current lower edge of the sending window (i.e., the first lower edge) is after the current lower edge of the receiving window, it indicates that an error has occurred in the virtual windowing. At this time, the second device sends a second status report to the first device to notify the first device that its virtual windowing has encountered an error, enabling the first device to correct the erroneous windowing result in a timely manner.

[0035] Secondly, a communication method is provided, which can be executed by a second device, or by a component configured in the second device (such as a circuit, chip, or chip system), or by a logic module or software capable of implementing all or part of the functions of the second device. This application does not limit this approach. The following description uses a second device as an example.

[0036] The method includes: receiving indication information from a first device, the indication information indicating a first lower edge of a transmission window, the first lower edge being an updated lower edge of the transmission window based on a first status report constructed based on the MAC layer of the first device; and, if the first lower edge and the lower edge of a receiving window of the second device are different, sending a second status report to the first device so that the first device updates the first lower edge of the transmission window to the second lower edge, the second status report including the lower edge of the receiving window of the second device, the second lower edge being the same as the lower edge of the receiving window.

[0037] In conjunction with the second aspect, in some possible implementations, sending a second status report to the first device when the lower edges of the first and second devices' receiving windows are different includes: sending a second status report to the first device when the first lower edge is greater than the lower edge of the receiving window.

[0038] Combining the second aspect and the above implementation methods, in some possible implementation methods, the indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the first lower edge.

[0039] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the second status report may also include: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status. The first status is used to indicate that the RLCPDU is in a state where the transmission is confirmed to be successful, and the second status is used to indicate that the RLC PDU is in a state where the transmission is not confirmed to be successful by the second device.

[0040] The second aspect is the implementation on the second device side, which corresponds to the first aspect. The explanations, supplements, and descriptions of the beneficial effects of the first aspect also apply to the second aspect, and will not be repeated here.

[0041] Thirdly, a communication device is provided, comprising a communication unit and a processing unit, the communication unit and the processing unit cooperating with each other to enable the communication device to perform the functions of the first device described in the first aspect. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the aforementioned functions.

[0042] Fourthly, a communication device is provided, comprising a communication unit and a processing unit, the communication unit and the processing unit cooperating with each other to enable the communication device to perform the functions of the second device described in the second aspect above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the aforementioned functions.

[0043] The third and fourth aspects are the implementation on the device side corresponding to the first and second aspects. The explanations, supplements, and descriptions of the beneficial effects of the first and second aspects also apply to the third and fourth aspects, and will not be repeated here.

[0044] Fifthly, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the method in any possible implementation of the first aspect described above. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0045] In one implementation, the aforementioned communication interface can be a transceiver, or an input / output interface.

[0046] In another implementation, the communication device is a chip configured in the first device. When the communication device is a chip configured in the first device, the communication interface can be an input / output interface.

[0047] In a sixth aspect, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the method in any possible implementation of the second aspect described above. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0048] In one implementation, the aforementioned communication interface can be a transceiver, or an input / output interface.

[0049] In another implementation, the communication device is a chip configured in the second device. When the communication device is a chip configured in the second device, the communication interface can be an input / output interface.

[0050] In a seventh aspect, a processor is provided, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute a method in any possible implementation of any aspect.

[0051] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0052] Eighthly, a communication device is provided, including a processor and a memory. The processor is used to read instructions stored in the memory, receive signals via a receiver, and transmit signals via a transmitter to execute the method in any possible implementation of any of the preceding aspects.

[0053] Optionally, there may be one or more processors and one or more memories.

[0054] Ninthly, a computer program product is provided, comprising: a computer program (also referred to as code or instructions) that, when executed, causes a computer to perform a method in any possible implementation of any of the above aspects.

[0055] In a tenth aspect, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when run on a computer, causes the computer to perform the method in any possible implementation of any of the above aspects.

[0056] Eleventhly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0057] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0058] In a twelfth aspect, a communication system is provided, including the aforementioned first device and second device. Exemplarily, the first device is configured to send indication information to the second device, the indication information indicating a first lower edge of a transmission window, the first lower edge being an updated lower edge of the transmission window based on a first status report constructed based on the Media Access Control (MAC) layer of the first device; the second device is configured to receive the indication information from the first device and, based on the indication information, send a second status report to the first device; the first device is configured to receive the second status report from the second device, the second status report including the lower edge of a reception window of the second device; the first device is further configured to update the first lower edge of the transmission window to a second lower edge, the second lower edge being the same as the lower edge of the reception window.

[0059] Optionally, the second device sending a second status report to the first device based on the indication information can be: the second device sending a second status report to the first device when the lower edge of the first device and the lower edge of the receiving window are different.

[0060] Optionally, the communication system may also include other devices that communicate with the first device and / or the second device. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of a communication system 100 used in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the data transmission process between a transmitting device and a receiving device in a communication system, as provided in an embodiment of this application. Figure 3 This is a schematic diagram illustrating the data packet processing flow of each protocol layer in the user plane of a transmitting device, as provided in an embodiment of this application. Figure 4 This is a schematic diagram illustrating an example of a stagnant sending window provided in an embodiment of this application; Figure 5 This is a schematic diagram of an example communication method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating an example of a data transmission process provided in an embodiment of this application. Figure 7 This is a schematic flowchart illustrating the processing procedure of inter-layer reports and correction status reports by the transmitting end, as provided in an embodiment of this application. Figure 8 This is a schematic flowchart illustrating an example of a receiving end receiving data, provided in an embodiment of this application. Figure 9 This is a schematic diagram illustrating the initial states of a sending window and a receiving window as provided in an embodiment of this application. Figure 10 This is a schematic diagram of an example of actively pushing a sending window provided in an embodiment of this application; Figure 11 This is a schematic diagram illustrating the principle of triggering a correction status report, provided in an embodiment of this application. Figure 12 This is a schematic diagram illustrating the principle of detecting an error where NACK becomes ACK, provided in an embodiment of this application. Figure 13 This is a schematic block diagram of the communication device provided in the embodiments of this application; Figure 14 This is another schematic block diagram of the communication device provided in the embodiments of this application. Detailed Implementation

[0062] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0063] The technical solutions provided in this application can be applied to various communication systems, such as: Global System for Mobile Communications (GSM) systems, General Packet Radio Service (GPRS), Wireless Local Area Network (WLAN), Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink communication systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, non-terrestrial network (NTN) communication systems, 5th generation (5G) mobile communication systems or new radio access technology (NR), and 6th generation (6G) mobile communication systems. Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networks. The technical solutions provided in this application can also be applied to future communication systems. This application does not impose any limitations on this.

[0064] Figure 1This is a schematic diagram of a communication system 100 used in an embodiment of this application. The communication system 100 may include a transmitting device 110 and a receiving device 120. Optionally, the transmitting device 110 may be a terminal device, and the receiving device 120 may be a network device. Optionally, the transmitting device 110 may be a network device, and the receiving device 120 may be a terminal device. This application does not limit this.

[0065] The network equipment in this application can be network-side equipment such as access network equipment and core network equipment. Access network equipment can also be called an access node. Access network equipment has wireless transceiver capabilities for communicating with terminals. Access network equipment includes, but is not limited to, base stations, evolved NodeBs (eNodeBs), transmission reception points (TRPs) in the aforementioned communication systems, next-generation NodeBs (gNBs) in 5G mobile communication systems, access network equipment or modules of access network equipment in open RAN (ORAN) systems, satellites in NTN communication systems, base stations in future mobile communication systems, or access nodes in WiFi systems. Access network equipment can also be modules or units capable of implementing some of the functions of a base station. Access network equipment can be macro base stations, micro base stations, indoor stations, relay nodes, donor nodes, or wireless controllers in cloud radioaccess network (CRAN) scenarios. Optionally, access network equipment can also be servers, wearable devices, or vehicle-mounted equipment, etc. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). Multiple access network devices in a communication system can be base stations of the same type or different types. Base stations can communicate with terminals directly or via relay stations. Terminals can communicate with multiple base stations using different access technologies. The embodiments of this application do not limit the specific technology or device form used in the access network equipment. In this application, the access network equipment is referred to as a network device.

[0066] In this application, the means for implementing the functions of a network device can be a network device itself, or a means capable of supporting the network device in implementing those functions, such as a processor, circuit, chip, or chip system. This means can be installed in or connected to the network device. In the technical solutions provided in this application, the example of a network device being used to implement the functions of a network device is used to describe the technical solutions provided in this application.

[0067] The terminal device in this application can be a wireless terminal device capable of receiving network device scheduling and instruction information. The wireless terminal device can be a device providing voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. For example, the terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN). The terminal device can also be referred to as a terminal, user equipment (UE), mobile station, mobile terminal, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (DTM) communication. to Device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication Type Communication (MTC), Internet of Things (IoT), and Ultra-Reliable Low-Latency Communication (ULLC) reliable low Latency communication (URLLC), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, or satellite communication, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, aircraft (such as drones, helicopters, and airplanes), hot air balloons, ships, robots, robotic arms, or smart home devices, etc. The embodiments of this application do not limit the form of the terminal device.

[0068] In this application, the device used to implement the functions of the terminal device can be the terminal device itself, or any device capable of supporting the terminal device in implementing those functions, such as a processor, circuit, chip, or chip system. This device can be installed in or connected to the terminal device. In the technical solutions provided in this application, the terminal device is used as an example to illustrate the technical solutions provided. The access network device and / or terminal can be fixed or mobile. The access network device and / or terminal can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed in the air on airplanes, balloons, and artificial satellites. The embodiments of this application do not limit the application scenarios of the access network device and terminal. The access network device and terminal device can be deployed in the same or different scenarios. For example, the access network device and terminal device can be deployed simultaneously on land; or the access network device can be deployed on land, and the terminal device can be deployed on water, etc., and so on.

[0069] In practical applications, multiple network devices can collaborate to assist terminals in achieving wireless access, with each network device performing some of the functions of a base station. For example, network devices can be centralized units (CUs), distributed units (DUs), and so on. Control plane (CP), CU User plane (UP) or radio unit (RU), etc. CU and DU can be separate entities or included in the same network element, such as the baseband unit (BBU). RU can be included in radio equipment or radio units, such as in a remote radio unit (RRU), active antenna unit (AAU), or remote radio head (RRH).

[0070] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (Open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules. CU (or CU-CP and CU-UP), DU, and RU can implement different protocol layer functions.

[0071] To facilitate understanding of the embodiments of this application, the terminology used in this application will be briefly explained first. Optionally, the explanation of some terms may also refer to the explanations in the 3rd Generation Partnership Project (3GPP) standard protocol.

[0072] 1. Protocol Layer Structure Interoperable network devices and terminal devices have a specific protocol layer structure. For example, the control plane protocol layer structure, from top to bottom, can include the functions of the radio resource control (RRC) layer, packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, medium access control (MAC) layer, and physical (PHY) layer. The user plane protocol layer structure, from top to bottom, can include the functions of the PDCP layer, RLC layer, MAC layer, and PHY layer. Among these, the physical layer is the lowest layer (layer one), the MAC layer, RLC layer, and PDCP layer belong to the second layer (layer two), and RRC layer belongs to the third layer (layer three).

[0073] In one implementation, a Service Data Adaptation Protocol (SDAP) layer may be included above the PDCP layer. The control plane protocol layer structure, from top to bottom, may include a non-access layer. It includes the functions of protocol layers such as the access stratum (NAS), radio resource control (RRC) layer, PDCP layer, RLC layer, MAC layer, and physical layer.

[0074] The functions of these protocol layers can be implemented by a single node or by multiple nodes. For example, in one evolutionary architecture, a radio access network device may include a centralized unit (CU) and a distributed unit (DU), with multiple DUs being centrally controlled by a single CU. The CU and DU can be distinguished according to the protocol layers of the wireless network; for example, the functions of the PDCP layer and above are located in the CU, while the functions of protocol layers below PDCP, such as the RLC layer and MAC layer, are located in the DU.

[0075] It should be understood that this protocol layer division is merely an example. It can also be applied to other protocol layers, such as the RLC layer, where the functions of the RLC layer and above are placed in the CU, and the functions of the protocol layers below the RLC layer are placed in the DU. Alternatively, it can be divided within a specific protocol layer, for example, placing some functions of the RLC layer and the functions of the protocol layers above the RLC layer in the CU, and placing the remaining functions of the RLC layer and the functions of the protocol layers below the RLC layer in the DU. Furthermore, it can be divided in other ways, such as by latency, placing functions whose processing time needs to meet latency requirements in the DU, and functions that do not need to meet this latency requirement in the CU.

[0076] Figure 2 This is a schematic diagram illustrating the data transmission process between a transmitting device and a receiving device in a communication system, as provided in an embodiment of this application.

[0077] For example, such as Figure 2 As shown, data first reaches the PDCP layer of the sending device. After processing at the PDCP layer, it is transmitted to the RLC and MAC layers. After further processing at the MAC layer, it is sent to the receiving device via the PHY layer. When the receiving device receives data, the protocol layers it passes through in sequence are the PHY layer, MAC layer, RLC layer, and PDCP layer. When the receiving device sends data to the sending device, the process is the reverse of the above, and will not be described again.

[0078] Data in each radio bearer needs to be processed by various layers. Each layer has corresponding functional entities to perform its functions; for example, the PDCP layer corresponds to the PDCP entity, the RLC layer to the RLC entity, and the MAC layer to the MAC entity. Each radio bearer contains one PDCP entity and one or more RLC entities, each RLC entity corresponding to a logical channel. One MAC entity corresponds to multiple logical channels, and data in these logical channels can be multiplexed at the MAC layer, for example, multiplexed into the same transport block, and finally transmitted through the PHY layer. The transmission process for downlink data is similar.

[0079] 2. Data packet The 5G system's user plane (UP) protocol stack, from top to bottom, includes: SDAP layer, PDCP layer, RLC layer, MAC layer, and PHY layer.

[0080] Figure 3 This is a schematic diagram illustrating the data packet processing flow of each protocol layer in the user plane of a sending device, as provided in an embodiment of this application.

[0081] For example, such as Figure 3As shown, in the transmitting device, the data packet first arrives at the SDAP layer. The SDAP layer, based on the Quality of Service (QoS) flow to Data Radio Bearer (DRB) mapping rules, delivers the data packet to the corresponding PDCP entity for each DRB (each DRB corresponds to one PDCP entity). The PDCP layer performs compression, encryption, and other operations on the data packet before delivering it to the RLC layer. The RLC layer processes the data packet, whether segmenting or not, before delivering it to the MAC layer. The MAC layer assembles one or more data packets into a MAC Protocol Data Unit (PDU) and delivers it to the PHY layer.

[0082] The data packets received by the SDAP layer are Internet Protocol (IP) packets, which are called SDAP Service Data Units (SDUs) at the SDAP layer. After processing these SDUs by adding headers and other steps to obtain SDAP Protocol Data Units (PDUs), the SDAP layer delivers the SDAP PDU to the PDCP entity. In other words, the data packets delivered by the SDAP layer to the PDCP entity are SDAP PDUs.

[0083] In the PDCP layer, the SDAP PDU is referred to as a PDCP SDU. After the PDCP layer performs processing such as adding a header to the PDCP SDU to obtain the PDCP PDU, it delivers the PDCP PDU to the RLC layer. That is, the data packet delivered by the PDCP layer to the RLC layer is the PDCP PDU.

[0084] In the RLC layer, the PDCP PDU is referred to as an RLC SDU. The RLC layer may or may not segment the RLC SDU. When the RLC SDU is segmented, each segment is called an RLC SDU segment. After obtaining the RLC PDU by adding headers and other related processing to the RLC SDU segments or RLC SDUs, the RLC PDU is delivered to the MAC layer. That is, the data packet delivered by the RLC layer to the MAC layer is the RLC PDU.

[0085] In the MAC layer, the RLC PDU is referred to as a MAC SDU. The MAC layer performs various processing steps on the MAC SDU, such as adding a MAC header, to obtain a MAC subPDU. One or more MAC subPDUs then form a MAC PDU, which is then submitted to the PHY layer. In other words, the data packet submitted by the MAC layer to the PHY layer is the MAC PDU.

[0086] The PHY layer modulates and encodes the MAC PDU to generate a transport block (TB), which is then sent out through air interface resources.

[0087] 3. The sequence number (SN) of the data packet. A sequence number (SN) is a unique identifier assigned to each data packet, used to track the order in which data packets are sent and received. It can also be called a sequence number. Data packets from different layers can each have their own SN. This application primarily relates to the SN of RLC layer data packets. In some cases, for distinction, the SN of an RLC layer data packet may also be referred to as an RLC SN. The RLC SN operates on an RLC SDU; one RLC SN corresponds to one RLC SDU, and the RLC SN can be stored in the RLC header of the RLC PDU. After receiving an RLC PDU, the receiving device can parse the SN corresponding to the RLC SDU in that RLC PDU from the RLC header.

[0088] Additionally, for segmented RLC SDUs, the RLC header of each RLC PDU containing a segment may include the offset information of that RLC SDU segment within its parent RLC SDU, to distinguish it from other RLC SDU segments within that RLC SDU. For example, an RLC SDU with SN=X comprises 26 bytes from a to z. This RLC SDU is divided into two RLC SDU segments by the RLC layer: RLC SDU segment 1 includes bytes a to m, and RLC SDU segment 2 includes bytes n to z. RLC SDU segment 1 undergoes header addition and other related processing to become RLC PDU 1, and RLC SDU segment 2 undergoes header addition and other related processing to become RLC PDU 2. The RLC headers of RLC PDU 1 and RLC PDU 2 contain the same SN. However, the offset information in the RLC header of RLC PDU 1 points to bytes a to m in the RLC SDU, while the offset information in the RLC header of RLC PDU 2 points to bytes n to z in the RLC SDU.

[0089] 4. HARQ mechanism of MAC layer HARQ is an error correction mechanism that combines forward error correction and automatic repeat request. Its core objective is to ensure reliable and efficient data reception in unreliable wireless channels. To support high-speed data transmission, NR allows multiple HARQ processes to work in parallel. While HARQ process A is waiting for its acknowledgment, HARQ processes B, C, and D can continue transmitting data, thus filling the pipeline and avoiding wasted time waiting.

[0090] The HARQ mechanism operates at the MAC layer and can be understood as retransmitting transport blocks (TBs). When retransmitting the same transport block, the encoded bits used in each retransmission can be different or the same.

[0091] The following section uses the downlink HARQ mechanism as an example to introduce the downlink HARQ feedback process, where the sending device is a network device and the receiving device is a terminal device.

[0092] For example, a network device schedules and sends a transport block, which includes a HARQ process ID and a new data indicator (NDI), typically 0. The terminal device receives the transport block and attempts to decode it. If decoding is successful, the terminal device sends an acknowledged (ACK) message to the network device; if decoding fails, it sends a negative acknowledgement (NACK) message. Upon receiving the ACK message, the network device confirms that the transport block has been successfully received by the terminal device, clears the HARQ process's buffer, and sends the next new data using the same process ID (while simultaneously flipping the NDI, for example, to 1). Upon receiving the NACK message, the network device confirms that the transport block has not been successfully received by the terminal device, and initiates a retransmission, retransmitting the transport block using the same HARQ process ID, but keeping the NDI unchanged to indicate a retransmission. The terminal device merges the retransmitted data with previously buffered failed data to improve the decoding success rate.

[0093] However, the HARQ mechanism has several typical problems, and these errors need to be addressed by the upper-layer ARQ mechanism. For example, in downlink transmission, a NACK-to-ACK misjudgment error may occur. This NACK-to-ACK error means that the terminal device actually fails to decode and sends a NACK message to the network device, but due to noise and interference affecting the uplink feedback channel during transmission, the network device incorrectly detects the NACK message as an ACK message. The network device mistakenly believes that the transport block has been successfully received, thereby triggering an NDI flip, clearing the buffer of the HARQ process, and sending new data using the same process ID, resulting in an improper new transmission due to HARQ. Even if this HARQ error can be detected, the terminal device cannot trigger a status report (such as an RLC status report) because the terminal device lacks the mapping information from RLC PDU to transport block (TB). Once the above misjudgment occurs, in traditional schemes, it is necessary to rely on the ARQ mechanism for handling. The ARQ mechanism will be introduced below.

[0094] 5. ARQ mechanism of RLC layer The RLC layer sits above the MAC layer and below the PDCP layer, providing services such as segmentation and retransmission for user and control data. The ARQ mechanism operates at the RLC layer and can be understood as retransmitting the RLC PDUs filled into the transport block.

[0095] For example, the transmission modes of the RLC layer include: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). UM mode is also called unacknowledged mode, and AM mode is also called acknowledged mode. In this application, the RLC layer in AM mode can also be simply referred to as RLC AM mode.

[0096] In AM mode, the sending device's RLC entity (also known as the sending device's AM RLC entity or RLC sending entity) sends data packets to the receiving device's RLC entity. The receiving device's RLC entity (also known as the receiving device's AMRLC entity or RLC receiving entity) reports the data packet reception status back to the sending device via a traditional status report. The sending device's RLC entity requires an acknowledgment report from the receiving device after transmitting data before ceasing to maintain the data packet. Specific implementation methods include: The sending device's RLC entity maintains a sending window. This sending window is a dynamically sliding window, also known as a sending window. The serial numbers (SNs) of data packets sent by the sending device's RLC entity must fall within the sending window. In related technologies, the lower edge (or lower boundary, left boundary, etc.) of the sending window is the SN of the earliest sent but unacknowledged data packet, or the smallest SN among sent but unacknowledged data packets, or the smallest SN among unacknowledged received data packets. The upper edge (or upper boundary, right boundary, etc.) of the sending window is the lower edge of the sending window plus the window size. The window size is a preset value. The window size represents the maximum number of data packets that the sending device's RLC entity is allowed to send without waiting for acknowledgment from the receiving device's RLC entity. In other words, data packets with SNs falling within the sending window can be sent continuously without waiting for acknowledgment from the receiving device's RLC entity.

[0097] The receiving device's RLC entity maintains a receive window. The receive window is a dynamically sliding window, also known as a receive sliding window or reassembly window. The serial number (SN) of data packets received by the receiving device's RLC entity must fall within the receive window. In related technologies, the lower edge of the receive window is the smallest SN among the data packets that were expected to be received but were not successfully received, or the smallest SN among the unacknowledged received data packets. The upper edge of the receive window is the lower edge of the receive window plus the window size. The window size is a preset value.

[0098] TX_Next_Ack: Represents the lower edge of the sending window, pointing to the next RLC SDU that the RLC sending entity expects to receive a full acknowledgment. In other words, SN has received full acknowledgment for all RLC SDUs before TX_Next_Ack, but does not include SN = TX_Next_Ack itself.

[0099] TX_Next: This is a transmit status variable that stores the sequence number (SN) assigned to the newly generated RLC PDU. The initial value of TX_Next is 0. When the RLC PDU encapsulates a complete RLC SDU or the last segment of an RLC SDU, TX_Next is incremented by 1.

[0100] RX_Next: This represents the receive status variable, storing the next SN that the RLC receiving entity expects to receive completely in sequence (but has not yet fully received). In other words, RLC SDUs with SNs prior to RX_Next have already been fully received and are considered old data. In AM mode, RX_Next is the lower edge of the receive window.

[0101] AM_Window_Size: Represents the size of the sending and receiving windows. Data packets within the sending window can be sent continuously without waiting for confirmation from the other party.

[0102] TX_VirNext_Ack: Represents the lower edge of the virtual transmit window. Its update is based on the interaction between HARQ and ARQ. This virtual transmit window lower edge is likely to be an incorrect transmit window lower edge value. If an error occurs, the error will be corrected by the correction status report mentioned below.

[0103] The RLC entity of the receiving device can update the receive window based on the data packet reception status, thus enabling the receiving window to slide. Specifically, if the data packet corresponding to the current lower edge of the receiving window is acknowledged, the RLC entity of the receiving device updates the lower edge of the receiving window, and updates the upper edge of the receiving window based on the updated lower edge and the size of the receiving window. In this way, the receiving window slides, or pushes the receiving window.

[0104] In addition, the receiving device's RLC entity can send a status report to the sending device's RLC entity when the reassembly timer (also known as the t-Reassembly timer) times out, notifying the receiving device of the packet reception status. This allows the sending device's RLC entity to update its sending window, enabling a sliding sending window. Specifically, when the receiving device's RLC entity determines that a packet is missing or out of order, it starts a reassembly timer for that packet. If the receiving device's RLC entity has not received the packet by the timer expires, it triggers a status report to the sending device's RLC entity. The status report carries the serial numbers (SNs) of ACK and NACK packets, used to notify the sending RLC entity of the successfully received and unsuccessfully received packet SNs, allowing the sending RLC entity to update its sending window.

[0105] After receiving the status report, the RLC entity of the sending device can trigger the retransmission of the data packet in the NACK state. On the other hand, according to the status report, if the data packet corresponding to the lower edge of the current sending window is acknowledged, that is, the SN of the data packet in the ACK state carried in the status report includes the lower edge of the current sending window, the RLC entity of the sending device updates the lower edge of the sending window, and updates the upper edge of the sending window according to the updated lower edge of the sending and receiving window and the size of the sending window. In this way, the sending window is slid, that is, the sending window is pushed.

[0106] For example, the status report triggered when the reassembly timer times out includes the reception status of the expected data packet. The reception status can include an acknowledged (ACK) status and a negative acknowledgement (NACK) status. The ACK status indicates that the data packet has been received, the verification is correct, and it can be reassembled in order. The NACK status indicates that the data packet was not received, lost, or the verification failed. If the sending device's RLC entity receives a status report from the receiving device's RLC entity after sending a data packet, indicating that the data packet's reception status is ACK, then the sending device's RLC entity no longer maintains the data packet. If the sending device's RLC entity receives a status report from the receiving device's RLC entity indicating that the data packet's reception status is NACK, then the sending device's RLC entity triggers a retransmission of the data packet. This status report is also referred to in this embodiment as a third status report, a conventional status report, or an RLC status report.

[0107] In this embodiment, for ease of description, a data packet that has been sent by the RLC entity of the sending device but has not been acknowledged by the RLC entity of the receiving device (i.e., the reception status is NACK) is called an unacknowledged data packet. A data packet that has been sent by the RLC entity of the sending device and has been acknowledged by the RLC entity of the receiving device (i.e., the reception status is ACK) is called an acknowledged data packet. A data packet that the RLC entity of the receiving device expects to receive but has not received, has not been correctly verified, or cannot be used for reorder reassembly is called a data packet that has not been successfully received (or a missing data packet). In other words, a data packet that has not been successfully received is a data packet whose reception status is NACK, reported by the RLC entity of the receiving device to the RLC entity of the sending device. A data packet that the RLC entity of the receiving device expects to receive, has been received, has been correctly verified, and can be used for reorder reassembly is called a successfully received data packet or a data packet in a state of confirmed successful transmission. In other words, a successfully received data packet is a data packet whose reception status is ACK, reported by the RLC entity of the receiving device to the RLC entity of the sending device. The data packet here can be an RLC PDU.

[0108] As described above, the ARQ mechanism relies on the receiver's traditional status report, which is sent to the transmitter after the receiver's reassembly timer expires. Upon receiving this traditional status report, the transmitter triggers the ARQ mechanism and begins retransmitting the RLC PDU. However, since this reassembly timer is typically configured to 80 milliseconds, the long waiting time results in a slow ARQ trigger speed, leading to significant delays in ARQ retransmissions.

[0109] Considering the higher requirements of 6G, the current 5G HARQ and ARQ mechanisms have several limitations. First, the latency associated with ARQ feedback and retransmissions at the RLC layer is high, typically tens of milliseconds or even higher. This is because the transmitting device triggers the ARQ mechanism only after receiving the receiver's traditional status report, and triggering the traditional status report requires the reassembly timer to time out. This process significantly prolongs the end-to-end latency of data requiring reliable transmission. For services requiring extremely low latency, this additional latency is unacceptable. Second, unlike HARQ, ARQ cannot utilize soft combining. That is, different ARQ retransmissions of the same data packet cannot be soft-combined to improve decoding success rate. In short, multiple retransmissions driven by traditional status report feedback essentially add round-trip latency costs to each retransmission. These inefficiencies mean that they cannot meet the more stringent low-latency and massive connectivity requirements of 6G.

[0110] The high latency (tens of milliseconds or even higher) of ARQ feedback and retransmission directly impacts the deployment of high-reliability, low-latency services. The RAN 131 meeting of 3GPP Release 20 has begun research and discussion on the 6G user plane. The interaction between ARQ and HARQ entities (referred to as ARQ-HARQ interaction) is a core hot topic. The core viewpoint of various companies is that the traditional status report triggered by 5G based on t-Reassembly timer timeout has excessive latency, leading to significant delays in ARQ retransmission (for a typical 80ms t-Reassembly timer configuration, the average latency is approximately 40ms). To reduce this latency in 6G, a completely new mechanism needs to be researched to avoid triggering excessive retransmission delays.

[0111] Research revealed that the fundamental reason for the slow ARQ retransmission in 5G is the excessive delay in traditional status reports triggered by t-Reassembly timer timeouts. This results in not only slow retransmissions but also sluggish windowing speeds at the transmitting end. The key to changing this situation lies in close interaction between the ARQ entity and the HARQ entity at the transmitting end. The HARQ entity is a functional entity at the MAC layer, responsible for interacting with the physical layer and handling fast retransmissions at the transport block (TB) level. The ARQ entity is a functional entity at the RLC layer corresponding to a specific logical channel, responsible for reliable data transmission on that logical channel.

[0112] Currently, at the RAN 132 meeting of 3GPP Release 20, it was discussed and agreed that for uplink HARQ, the UE can obtain explicit HARQ feedback from the network side. New HARQ feedback (such as downlink control information (DCI) or new MAC CE) can indicate TB transmission failure (i.e. NACK) and instruct the UE to trigger ARQ retransmission of the data corresponding to that TB.

[0113] However, no company has discussed how the transmitting device should operate when the new HARQ feedback indicates that the TB has been acknowledged (ACK). Specifically, can the transmitting device also quickly advance the ARQ transmission window (TXwindow) based on HARQ feedback? If the transmission window can only be advanced based on the receiver's traditional status reports (STATUS PDUs), as in the traditional way, the advantage of coordination between the HARQ and ARQ entities will be diminished when the transmission window has already stalled or is about to stall, because new transmissions may not be executed at this time. In other words, in 5G systems, the ARQ transmission window may not be advanced until the t-Reassembly timer expires, which is extremely disadvantageous for the more demanding low-latency and reliability requirements of 6G services. For ease of understanding, the following will combine... Figure 4 Explanation: Figure 4 This is a schematic diagram illustrating an example of a stagnant sending window provided in an embodiment of this application.

[0114] like Figure 4 As shown in (a), assuming the lower edge of the sending window TX_Next_Ack=1, the size of the sending window is 81, and the upper edge of the sending window is 82. A set of data packets for a certain extended reality (XR) service is sent across the upper edge of the sending window; that is, some data packets in this set are within the sending window, and others are outside the sending window. For example, as... Figure 4As shown in (a), the data packet set includes data packets with SN=81~92. Among them, the data packet with SN=81 is within the sending window, and the data packets with SN=82~92 are outside the sending window waiting for transmission.

[0115] Suppose that during the initial transmission, the sending device sends data packets (RLCPDUs) with SNs 1-81 within its sending window. Data packet SN=13 within the sending window fails to transmit successfully; that is, SN=13 is an unacknowledged data packet. Data packets with SNs 1-12 and 14-81 within the sending window are successfully transmitted and are acknowledged data packets. Data packets with SNs 82-92 are stored in the sending device's buffer and are pending transmission; discard timers for each of these data packets have been started. Specifically, when the sending device receives a data packet from the upper layer (i.e., the PDCP layer) at the RLC layer, it starts the corresponding discard timer. If the data packet is acknowledged before the discard timer expires, the discard timer is canceled. If the data packet is not acknowledged by the timer expires, it is discarded.

[0116] like Figure 4 As shown in (b), the receiving device receives data packets within its receive window. Assume the receiving device successfully receives data packets SN=1~12 and SN=14~81, but fails to receive the data packet SN=13. Data packets SN=82~94 are pending reception. Therefore, the receiving device updates the lower edge RX_Next of the receive window to SN=13. Through ARQ and HARQ interaction, the sending device knows that data packets SN=1~12 have been successfully received. However, because the receiving device's t-Reassembly timer has not expired, the receiving device cannot send traditional status reporting. Therefore, the sending device does not push the sending window, causing the sending window to lag behind the receiving window. This lag occurs in... Figure 4 This is reflected in the lower edge of the transmitting window being SN=1, and the lower edge of the receiving window being SN=13. This lag issue is extremely detrimental to the more demanding low-latency and high-reliability requirements of 6G services. Figure 4 As shown, some data packets in the packet set of the sending device (such as data packets with SN=82~92) are waiting for transmission outside the sending window because the sending window cannot be pushed. When this part of the data is subsequently transmitted into the sending window, it is very likely that the above-mentioned discard timer will time out during the first retransmission, which can easily cause a large number of packet losses in XR services, because if even one data packet in the packet set is discarded due to timeout, the entire packet set will be discarded.

[0117] To accelerate data packet transmission and avoid or reduce the possibility of the entire packet set being discarded, a rapid window push (or simply fast window push) can be considered. This allows data packets that were originally outside the sending window to quickly enter it, achieving fast transmission. For example, HARQ feedback can be used to trigger the early push of the sending window. However, if HARQ feedback can be used to trigger the early push of the sending window, it is necessary to ensure that this new mechanism has sufficient reliability. Otherwise, if a misjudgment causes the sending window to advance incorrectly, some data packets may be lost. For downlink transmission, HARQ feedback may have a NACK to ACK error (10% error rate). The main reason for the potential NACK to ACK error in HARQ feedback is that HARQ feedback typically only occupies 1 bit during physical layer transmission and lacks cyclic redundancy check (CRC) protection, making it susceptible to channel interference and errors. Due to noise and fading in the physical channel, a NACK sent by the receiving device may be misjudged as an ACK by the sending device during transmission, causing the sending device to incorrectly believe that the data packet has been successfully transmitted and clear its buffer. Compared to control signaling with CRC protection (such as DCI or MAC CE), HARQ feedback sacrifices some reliability verification mechanisms in pursuit of low latency. Therefore, during fast windowing, it is necessary to detect such windowing errors to improve the reliability of fast windowing. In other words, how to achieve reliable fast windowing has become an urgent technical problem to be solved.

[0118] In view of this, embodiments of this application provide a communication method that introduces a correction status report while quickly pushing windows, which is beneficial for timely correction of errors that occur during quick window pushing and achieves reliable quick window pushing.

[0119] The solution provided in this application will be described in detail below with reference to the corresponding flowcharts. It is understood that the illustrative flowcharts provided in this application primarily use different devices (e.g., sending devices and receiving devices) as examples of the execution subjects of this interactive illustration to illustrate the method, but this application does not limit the execution subjects of the interactive illustrations. For example, the devices (e.g., sending devices and receiving devices) in the illustrative flowcharts can also be chips, chip systems, or processors that support the implementation of this method on the device, or they can be logic modules or software that can implement all or part of the functions of the device.

[0120] As a general statement, the message or signaling interactions involved in the interaction process of this application embodiment can be standard messages or signaling or newly introduced messages or signaling. This application embodiment does not make specific limitations on this.

[0121] Figure 5 This is a schematic diagram illustrating an example of a communication method provided in an embodiment of this application. It can be understood that... Figure 5 The first device in the process can be Figure 1 The term "transmitting device" can also refer to a component within the transmitting device (e.g., a processor, chip, or chip system). The second device can be... Figure 1 The term "receiving end equipment" can also refer to devices within the receiving end equipment (such as processors, chips, or chip systems).

[0122] For example, such as Figure 5 The communication method shown includes the following steps: S51, the first device sends indication information to the second device; correspondingly, the second device receives indication information from the first device, which is used to indicate the first lower edge of the sending window. The first lower edge is the lower edge of the sending window after the first status report constructed based on the MAC layer of the first device is updated.

[0123] Optionally, the first status report refers to the status report constructed by the MAC layer of the first device, used to notify the first device's RLC layer that the RLC PDU corresponding to the first transport block has been successfully transmitted. This first status report can also be called an ACK inter-layer report. The first transport block can be a transport block obtained by the first device after processing the data packet to be sent by each protocol layer. The first device sends the first transport block to the second device, and the second device receives the first transport block.

[0124] Optionally, the MAC layer of the first device can report the success of RLC PDU transmission to the RLC layer via inter-layer reports. These inter-layer reports include: the sequence number of the RLC PDU within the first transport block and the logical channel identifier (LCID) to which each RLC PDU belongs. Inter-layer reports are divided into two types: ACK inter-layer reports and NACK inter-layer reports. ACK inter-layer reports are used to notify the first device's RLC layer that the RLC PDU corresponding to the first transport block has been successfully transmitted, while NACK inter-layer reports are used to notify the first device's RLC layer that the RLC PDU corresponding to the first transport block has not been successfully transmitted.

[0125] For example, a first transport block (TB) can be sent through a HARQ process. In a HARQ process, the sending device sends a TB from a MAC PDU of a MAC entity, and the MAC PDU from an RLC PDU of one or more RLC entities. Since one RLC entity corresponds to one logical channel, in a HARQ process, a TB from an RLC PDU of one or more RLC entities can also be replaced by a TB from an RLC PDU of one or more logical channels.

[0126] In the description of this application, the RLC PDU corresponding to the first transport block represents the RLC PDU that the first transport block comes from one or more RLC entities. For example, if the RLC PDUs corresponding to the first transport block are RLC PDU1, RLC PDU2, and RLCPDU3, it means that the first transport block comes from RLC PDU1, RLC PDU2, and RLC PDU3. Based on this, the ACK inter-layer report used to notify the first device that the RLC layer RLC layer RLC PDU corresponding to the first transport block has been successfully transmitted can mean that RLC PDU1, RLCPDU2, and RLC PDU3 have been successfully transmitted.

[0127] In some embodiments, the method further includes: the MAC layer of the first device receiving feedback information from the second device, the feedback information indicating whether the MAC subPDU in the first transport block has been successfully transmitted. The MAC layer of the first device constructs a first status report based on the feedback information, the logical channel number in the MAC subheader of the MAC subPDU, and the sequence number of the RLC PDU in the MAC subheader.

[0128] Optionally, the feedback information, also known as a feedback report, refers to feedback on the first transport block. This feedback information can be either ACK or NACK. When the feedback information is ACK, it indicates that the MAC subPDU within the first transport block was successfully transmitted. When the feedback information is NACK, it indicates that the MAC subPDU within the first transport block was not successfully transmitted.

[0129] Furthermore, the feedback information is the HARQ feedback sent by the second device to the first device at the physical layer for the first transport block. The HARQ feedback indicates the decoding status of the first transport block. When the HARQ feedback indicates successful decoding (usually represented by an ACK message), the feedback information indicates that all MAC subPDUs within the first transport block have been successfully transmitted. When the HARQ feedback indicates failed decoding (usually represented by a NACK message), the feedback information indicates that none of the MAC subPDUs within the first transport block have been successfully transmitted. HARQ feedback has a dedicated physical layer feedback channel and is a technology situated between the MAC layer and the PHY layer. HARQ feedback is located between the physical layer of the second device and the MAC layer of the first device, offering low latency, but it may carry the risk of bit errors, such as a NACK being misinterpreted as an ACK.

[0130] Optionally, each MAC subPDU in a MAC PDU has a MAC subheader at the beginning. The MAC subheader contains at least the Logical Channel Number (LCID) and the Sequence Number (SN) of the RLC PDU corresponding to the LCID. The LCID is used to determine which logical channel the MAC subPDU belongs to, thereby locating the corresponding ARQ entity in the RLC layer. The ARQ entity refers to the functional entity in the RLC layer responsible for automatic retransmission requests, typically operating in Acknowledgment Mode (AM), and maintaining the transmission window, retransmission buffer, and related state variables. The SN in the ACK inter-layer report is used to accurately locate the RLC PDU in the buffer.

[0131] For example, after receiving the feedback information, the MAC layer of the first device first parses the feedback information to determine the overall transmission status of the first transmission block. If the feedback information is an ACK message, the MAC layer of the first device determines that all MAC subPDUs contained in the first transmission are considered successful at the physical transmission level. If the feedback information is a NACK message, it waits for HARQ retransmission or generates a corresponding failure indication; this application does not limit this.

[0132] When the feedback information is ACK, the MAC layer of the first device traverses all MAC subPDUs within the first transport block, reads the MAC subheader corresponding to each MAC subPDU, and extracts the LCID and RLC PDU sequence number from the MAC subheader. Based on the extracted LCID and RLC PDU sequence number, an ACK inter-layer report is constructed. The ACK inter-layer report contains one or more "LCID-SN" pairs, used to indicate that a specific sequence number of the RLC PDU on a specific logical channel has been confirmed as successfully transmitted via the HARQ mechanism. The ACK inter-layer report is not air interface signaling, but rather interactive information between the internal protocol layers of the first device.

[0133] When the feedback information is NACK, the MAC layer of the first device traverses all MAC subPDUs within the first transport block, reads the MAC subheader corresponding to each MAC subPDU, and extracts the LCID and RLC PDU sequence number from the MAC subheader. Based on the extracted LCID and RLC PDU sequence number, a NACK inter-layer report is constructed. The NACK inter-layer report contains one or more "LCID-SN" pairs, used to indicate that a specific sequence number of an RLC PDU on a specific logical channel has been confirmed as unsuccessfully transmitted via the HARQ mechanism. The NACK inter-layer report is not air interface signaling, but rather interactive information between the internal protocol layers of the first device.

[0134] The MAC layer of the first device sends the constructed inter-layer report (ACK inter-layer report / NACK inter-layer report) to the RLC layer of the first device. If the inter-layer report received by the RLC layer of the first device is an ACK inter-layer report, the RLC layer virtually pushes the transmission window based on the ACK inter-layer report.

[0135] The aforementioned feedback information, i.e., HARQ feedback, provides coarse-grained status at the TB level, indicating whether the entire first transport block was successfully decoded or failed. Inter-layer reports (ACK inter-layer report / NACK inter-layer report) convert the feedback information into fine-grained status at the RLC PDU level. By parsing the LCID and RLC PDU sequence number in the MAC sub-header, the MAC layer of the first device implements an information mapping from "first transport block transmission successful" to "which specific RLC PDUs were successful." Through these inter-layer reports, a close interaction is established between HARQ and ARQ. In traditional architectures, HARQ and ARQ operate relatively independently; RLC ARQ typically relies on the reassembly timer to time out before detecting packet loss, resulting in significant feedback and retransmission delays. This embodiment, through inter-layer reports, enables the RLC layer's ARQ entity to utilize the rapid feedback from HARQ to achieve fast windowing and fast retransmission, thereby reducing data transmission latency and meeting the stringent low-latency requirements of services such as XR.

[0136] Specifically, the RLC layer of the first device finds the corresponding ARQ entity based on the LCID in the ACK inter-layer report. This ARQ entity then searches for the corresponding RLC PDU in its buffer based on the sequence number (SN) of the RLC PDU in the ACK inter-layer report. The buffer stores RLC PDUs that have been sent but not yet acknowledged. If an RLC PDU corresponding to the SN is found in the buffer, it is determined that the RLC PDU has been successfully transmitted and acknowledged by the HARQ mechanism. Subsequently, the ARQ entity uses the sequence numbers of these successfully transmitted RLC PDUs to virtually update the lower edge of the transmission window, thus achieving virtual window pushing (referred to as virtual window pushing / fast window pushing).

[0137] Virtual windowing refers to updating the lower edge of the sending window to the first lower edge (TX_VirNext_Ack) without immediately deleting RLC PDUs with sequence numbers less than that first lower edge from the buffer. Specifically, the ARQ entity determines the new position to which the lower edge of the sending window should be advanced, i.e., the first lower edge, based on the SN in the ACK inter-layer report. Unlike regular window advancement, after updating the lower edge of the sending window to the first lower edge, RLC PDUs with SNs less than that first lower edge from the buffer are not immediately deleted; instead, these RLC PDUs are retained to avoid data loss due to rapid windowing. In other words, the core idea of ​​virtual windowing is to update the lower edge of the sending window to the first lower edge to allow the transmission of new data packets, while retaining RLC PDUs with sequence numbers less than that first lower edge from the buffer. The purpose of virtual windowing is to achieve rapid windowing by utilizing the low latency characteristics of HARQ feedback, thereby allowing the transmission of new RLC PDUs, while retaining the ability to recover from abnormal situations such as false ACK errors. Because HARQ feedback carries the risk of errors—for example, a NACK might be mistakenly interpreted as an ACK—if the ARQ entity performs a standard window advance operation and immediately deletes the acknowledged RLC PDU after receiving the ACK inter-layer report, it will be unable to retransmit the RLC PDU if the HARQ feedback is subsequently found to be a misinterpretation, resulting in data loss. However, by using virtual windowing, only the lower edge of the sending window is updated, allowing the transmission of new RLC PDUs while retaining the old ones in the buffer. Therefore, when retransmission is needed later, the ARQ entity can still retrieve the corresponding RLC PDU from the buffer and perform the retransmission.

[0138] The aforementioned first lower edge refers to the lower edge of the transmission window after updating the lower edge of the transmission window in the first status report (ACK inter-layer report) built based on the MAC layer. Since the first lower edge is the result of a virtual windowing, it can also be called the virtual transmission window lower edge, or the virtual lower edge of the transmission window TX_VirNext_Ack. The first lower edge is updated based on the interaction result between HARQ and ARQ. Because HARQ feedback may contain NACK to ACK errors (also known as NACK to ACK errors, or pseudo-ACK errors), the first lower edge is likely to be an incorrect transmission window lower edge value. If an error occurs, it can be corrected by subsequent correction status reports.

[0139] Optionally, the first lower edge refers to the lower edge after the ACK inter-layer report built based on the MAC layer performs a virtual update on the lower edge of the sending window. The virtual update means that: a new RLC PDU is sent based on the sending window corresponding to the first lower edge, and RLC PDUs with sequence numbers less than the first lower edge are not deleted temporarily. If the second timer expires and no second status report is received, then RLC PDUs with sequence numbers less than the first lower edge are deleted.

[0140] Through the aforementioned virtual windowing mechanism, the ARQ entity can quickly advance the transmission window using HARQ feedback without waiting for the t-Reassembly timer to expire, thereby reducing the latency of new data transmission. At the same time, since the old RLC PDUs in the cache are not immediately deleted, the ability to recover from abnormal situations such as HARQ misjudgment is still retained, thus balancing low latency and high reliability.

[0141] For example, the HARQ entity at the MAC layer of the first device receives ACK / NACK information (i.e., feedback information or feedback report) from the second device via the physical layer, determines whether the first transport block was successfully transmitted, constructs an inter-layer report, and sends the inter-layer report to the ARQ entity at the RLC layer, informing it whether the RLC PDUs on each logical channel of the RLC layer were transmitted correctly or incorrectly. The HARQ entity maps terabyte-level transmission results to specific logical channels and RLC PDU sequence numbers through the inter-layer report, thereby enabling the ARQ entity to achieve fast windowing and fast retransmission, solving the delay problem caused by the timeout of the reassembly timer in traditional ARQ mechanisms.

[0142] In some embodiments, the first status report includes the sequence number of at least one RLC PDU. Since the first status report is an ACK inter-layer report, the sequence number of the RLC PDU in the first status report is used to indicate that the RLC PDU corresponding to that sequence number was successfully transmitted. If the sequence number of at least one RLC PDU includes a third lower edge and the RLC SDU corresponding to the third lower edge has been successfully transmitted, the first lower edge is the sequence number corresponding to the first RLC SDU that was not completely transmitted after the third lower edge, and the third lower edge is the lower edge of the transmission window before the update.

[0143] In other words, the first lower edge is determined as follows: when all sequence numbers in the ACK inter-layer report contain a third lower edge, and the RLC SDU corresponding to this third lower edge has been successfully transmitted, the RLC layer of the first device determines the first lower edge as: the sequence number corresponding to the first incompletely transmitted RLC SDU after the third lower edge. Here, the third lower edge is the lower edge of the transmission window before the update, i.e., the lower edge of the aforementioned virtual transmission window before the update. The first lower edge is the virtual lower edge TX_VirNext_Ack of the transmission window, not the final determined lower edge TX_Next_Ack of the transmission window.

[0144] Optionally, "RLC SDU successfully sent" can mean that the RLC SDU is an acknowledged data packet. "RLC SDU not fully sent" can mean that the RLC SDU was not successfully sent and is an unacknowledged data packet.

[0145] For example, determining whether the RLC SDU corresponding to the third falling edge has been successfully transmitted can be divided into two cases: unsegmented and segmented. Scenario 1: No segmentation. The RLC SDU is carried by an RLC PDU. If the RLC layer of the first device determines that the third falling edge is included in the ACK inter-layer report, it considers the RLC SDU corresponding to the third falling edge to have been successfully transmitted.

[0146] Scenario 2: Segmentation. The RLC SDU is divided into multiple RLC SDU segments, each carried by a different RLC PDU. These RLC PDUs share the same SN (i.e., the third falling edge) but have different offset information. The RLC layer of the first device, based on the ACK inter-layer report, confirms whether all RLC PDUs corresponding to the RLC SDU segments under the SN corresponding to the third falling edge have been successfully transmitted, and whether the byte range covered by each RLC SDU segment is continuous and completely covers the RLC SDU. When all RLC PDUs corresponding to the RLC SDU segments under the SN are confirmed as successful and can be assembled into a complete RLC SDU without missing bytes, the RLC SDU corresponding to the third falling edge is considered to have been successfully transmitted.

[0147] If the RLC SDU corresponding to the third falling edge meets any of the above conditions, it is determined that the RLC SDU has been successfully transmitted, and the first falling edge is then determined as the sequence number of the first incompletely transmitted RLC SDU after the third falling edge. If the RLC SDU corresponding to the third falling edge does not meet the above conditions, it is determined that it was not completely transmitted, and the first falling edge is still determined based on the incompletely transmitted RLC SDU. For example, the first falling edge is the sequence number of the incompletely transmitted RLC SDU.

[0148] As described above, the RLC layer of the first device has received the first falling edge TX_VirNext_Ack. The first device sends this first falling edge indication information to the second device. This indication information is used to indicate the first falling edge of the transmission window. After receiving this indication information, the second device can determine that the transmission window of the first device has changed, that is, the first device has performed the aforementioned virtual windowing.

[0149] Optionally, the indication information is used to notify the lower edge of the sending window of the update status, so that the second device can know the update status of the lower edge of the sending window.

[0150] In some embodiments, the indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the aforementioned first falling edge. That is, the third RLC PDU is the RLC PDU in the buffer whose sequence number is the aforementioned first falling edge.

[0151] Optionally, the indication information is carried in reserved bits in the header of the third RLC PDU. Reserved bits are bits in the header of the third RLC PDU that are originally reserved for future use or specific purposes. In existing protocols, reserved bits are typically set to a fixed value (e.g., 0) by the first device, and the second device ignores their content. In this embodiment, the first device uses the reserved bits to carry the indication information, and the second device parses the reserved bits according to an agreement, thereby transmitting additional indication information without changing the basic format of the RLC PDU, ensuring backward compatibility. By carrying the indication information in reserved bits in the third RLC PDU, the overhead of additional control signaling can be reduced, and transmission efficiency can be improved.

[0152] For example, the reserved bit can be denoted as W. When W = 1, it means that the sequence number SN in the header of the third RLC PDU is equal to the virtual falling edge value of the transmission window, i.e., the first falling edge TX_VirNext_Ack mentioned above.

[0153] In some embodiments, the method further includes: upon receiving a first status report at the RLC layer of the first device, updating the lower edge of the transmission window to a first lower edge and retransmitting the third RLC PDU. Here, "update" refers to a virtual update; an explanation of virtual updates can be found above and will not be repeated here.

[0154] For example, when the RLC layer of the first device receives a first status report, the RLC layer reads the LCID from the first status report and sends the first status report to the corresponding ARQ entity based on the LCID. The ARQ entity reads the sequence number of the RLC PDU in the first status report and determines the first falling edge based on the sequence number of the RLC PDU in the first status report. The first falling edge is the sequence number of the first incompletely transmitted RLC SDU after the falling edge of the transmission window. The ARQ entity updates the falling edge of the transmission window to the first falling edge, thereby performing new data transmission based on the updated transmission window. This new data transmission includes retransmitting a third RLC PDU, the sequence number of which is the first falling edge. The header of the third RLC PDU carries indication information to notify the second device of the update status of the transmission window.

[0155] After the first device implements virtual windowing using the first status report (i.e., ACK inter-layer report), the lower edge of the transmission window is updated to the first lower edge. At this time, the first device can send new RLC PDUs, such as the aforementioned third RLC PDU, as well as the RLC PDUs within the updated transmission window, based on the updated transmission window. Simultaneously, the retransmitted third RLC PDU header carries indication information, actively notifying the second device of the transmission window update, enabling the second device to be promptly informed of the transmission window update. In this way, after virtual windowing, the first device can promptly retransmit the third RLCPDU with the sequence number at the first lower edge, and synchronously notify the second device of the transmission window update through the indication information carried in the header.

[0156] In some embodiments, the first status report includes at least one RLC PDU sequence number; the method further includes: the first device sets the status flag of the RLC PDU corresponding to the sequence number to a first value, which is used to indicate that the RLC PDU transmission was successful.

[0157] The status flag can refer to the status flag set for the RLC PDU stored in the buffer of the first device, which can be called the S flag. The S flag indicates whether the RLC PDU in the buffer has been successfully transmitted.

[0158] When the S flag of an RLC PDU is set to the first value, it indicates that the RLC PDU was successfully transmitted. When the S flag of an RLCPDU is set to the second value, it indicates that the RLC PDU is in a pending state. This pending state means that the RLC PDU has failed to transmit but is being retransmitted or is being sent for the first time. The first value can be 1, and the second value can be 0, or vice versa. The determination of whether an RLC PDU was successfully transmitted is based on the interaction between HARQ and ARQ. In reality, there may be errors where HARQ feedback NACK changes to ACK. That is, even if the S flag is set to the first value, it may be because of an error where NACK changes to ACK that the S flag is set to the first value. Therefore, setting the S flag to the first value can also temporarily indicate that the transmission was successful.

[0159] For example, after receiving the first status report, the RLC layer of the first device can set the status flag of all RLC PDUs corresponding to the sequence numbers in the first status report stored in the cache to the first value.

[0160] It should be noted that the cache in this application embodiment can refer to a sending cache or a retransmission cache.

[0161] In some embodiments, the method further includes: updating the lower edge of the sending window to a first lower edge if the first timer times out; wherein the first timer is started when the RLC layer of the first device receives the first status report and the first timer is not started.

[0162] In some embodiments, when the lower edge of the sending window is updated to a first lower edge, the first device sends indication information to the second device.

[0163] The first timer can also be called the t-PushWindow timer. The t-PushWindow timer is used to prevent the ACK inter-layer report (i.e., the first status report) from triggering the push window frequently. In other words, the first timer is used to prevent the first status report from triggering the virtual push window mentioned above frequently.

[0164] For example, when the RLC layer of the first device receives a first status report sent by the MAC layer of the first device, if the first timer has not been started, the first device starts the first timer; if the first timer has been started, active window pushing (i.e., virtual window pushing) is no longer executed to avoid the first device triggering the push sending window frequently based on the received first status report. After the first timer is started, if the first timer times out, the RLC layer of the first device executes virtual window pushing and sends the indication information of the first lower edge to the second device.

[0165] For example, during the first timer start-up period, if the RLC layer of the first device receives a first status report sent by the MAC layer of the first device, the RLC layer of the first device will not immediately perform active windowing based on the first status report. However, it can set the status flag of all RLC PDUs corresponding to the sequence numbers in the first status report to a first value, which is used to indicate that the RLC PDU transmission was successful. The purpose of this setting is to avoid frequent active windowing, because active windowing also has a cost, requiring the retransmission of the RLC PDU with the sequence number of the first falling edge (i.e., the third RLC PDU). In other words, after receiving the first status report, the RLC layer of the first device will set the status flag of all RLC PDUs corresponding to the sequence numbers in the first status report to a first value, regardless of whether the first timer has started or expired, so that after the first timer expires, the first falling edge can be determined based on all RLC PDUs with the status flag set to the first value.

[0166] For example, when the first timer times out and SN = TX_Next_Ack (i.e., the third falling edge) exists in the first status report received by the RLC layer during the first timer start-up period, the RLC layer of the first device determines the first falling edge based on all the first status reports received by the RLC layer during the first timer start-up period, updates the falling edge of the transmission window to the first falling edge, and retransmits the third RLC PDU. The third RLC PDU is a data packet containing the updated falling edge information of the transmission window (i.e., the first falling edge). The header of the third RLC PDU carries indication information to notify the second device of the update status of the transmission window.

[0167] For example, suppose the RLC layer of the first device first receives ACK inter-layer report 1, which includes SN=1~4. The RLC layer of the first device then sets the status flag S for SN=1~4 in its buffer to 1. When the RLC layer of the first device receives ACK inter-layer report 1, since the t-PushWindow timer is not yet started, it starts the t-PushWindow timer. During the t-PushWindow timer's operation, the RLC layer of the first device receives ACK inter-layer report 2, which includes SN=5, 7. The RLC layer of the first device then sets the status flag S for SN=5, 7 in its buffer to 1. After the t-PushWindow timer times out, the RLC layer of the first device determines the first falling edge TX_VirNext_Ack based on the ACK inter-layer reports 1 and ACK inter-layer reports 2 received during the t-PushWindow timer's operation.

[0168] Assuming the third lower edge (i.e. the lower edge of the sending window before the update, or the current lower edge of the sending window) is SN=1, the RLC layer of the first device determines that the ACK inter-layer report 1 and ACK inter-layer report 2 received during the t-PushWindow timer operation include this third lower edge. Based on the status flag S of each RLC PDU in the buffer, the RLC layer of the first device determines that the RLC SDU corresponding to SN=1 has been successfully sent. Then the first lower edge is the sequence number of the first RLC SDU that was not completely sent after SN=1 (SN=7), that is, TX_VirNext_Ack=7.

[0169] S52, the second device sends a second status report to the first device; correspondingly, the first device receives the second status report from the second device, the second status report including the lower edge of the receiving window of the second device.

[0170] The second status report is determined based on the indication information. After receiving the indication information, the second device can determine the second status report based on the indication information.

[0171] As explained above, the first device sends an indication message to the second device. Upon receiving this indication message, the second device can determine that the current lower edge of the first device's sending window is the first lower edge TX_VirNext_Ack. Based on the relationship between this first lower edge and the lower edge of the receiving window, the second device can determine whether to send a second status report to the first device. If, based on the relationship between the first lower edge and the lower edge of the receiving window, the second device determines that the triggering condition for the second status report is met, then it sends a second status report to the first device.

[0172] Optionally, the second device sends a second status report to the first device when it determines that the first lower edge is different from the lower edge of the receiving window. That is, the triggering condition for the second status report may include: the first lower edge is different from the lower edge of the receiving window. The second status report is sent by the second device when the first lower edge is different from the lower edge of the receiving window.

[0173] Optionally, the first lower edge differing from the lower edge of the receiving window can mean that the first lower edge is greater than the lower edge of the receiving window. That is, if the first lower edge is greater than the lower edge of the receiving window, the second device sends a second status report to the first device. Correspondingly, if the first lower edge is greater than the lower edge of the receiving window, the first device receives the second status report from the second device. In other words, the triggering condition for the second status report can include: the first lower edge being greater than the lower edge of the receiving window.

[0174] It should be understood that because the RLC layer of the first device performs virtual windowing based on the ACK inter-layer report, the lower edge of the sending window is updated to the first lower edge. The RLC layer of the second device maintains its own receiving window. If the first lower edge is greater than the lower edge of the receiving window, it indicates that the sending and receiving windows are out of sync. If the current lower edge of the sending window (i.e., the first lower edge) is after the current lower edge of the receiving window, it indicates that an error has occurred in the virtual windowing. Therefore, the first device sends an indication message to the second device to notify it that it has updated the lower edge of the sending window to the first lower edge. After receiving this indication message, the second device can send a second status report to the first device if the first lower edge is greater than the lower edge of the receiving window, to notify it that its virtual windowing has encountered an error, allowing the first device to correct the erroneous windowing result in a timely manner.

[0175] Optionally, the indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the first lower edge. As described above, when the RLC layer of the first device receives the first status report, it updates the lower edge of the transmission window to the first lower edge and retransmits the third RLC PDU. Correspondingly, the second device receives the third RLCPDU from the first device, parses the header of the third RLC PDU to obtain the aforementioned indication information, and then determines that the sequence number of the third RLC PDU is the first lower edge of the transmission window.

[0176] Optionally, the first device uses reserved bits in the header of the third RLC PDU to carry indication information. After receiving the third RLC PDU, the second device parses the reserved bits to determine the indication information. For example, the reserved bit can be denoted as W. When the second device determines that W = 1, it further determines that the sequence number SN in the header of the third RLC PDU is equal to the value of the lower edge of the transmission window, i.e., the aforementioned first lower edge TX_VirNext_Ack. When the second device determines that W = 0, it further determines that the sequence number SN in the header of the third RLC PDU is not equal to TX_VirNext_Ack.

[0177] Optionally, the aforementioned second status report can also be called a correction status report or a correction report. The trigger condition for the second device to send this correction status report to the first device is: TX_VirNext_Ack > RX_Next (i.e., the first lower edge is greater than the lower edge of the receiving window). The correction status report is used to correct errors in the first device's fast window push (also known as virtual window push). The content of the correction status report includes the lower edge of the receiving window, RX_Next, which instructs the first device to update the first lower edge of the transmitting window to the second lower edge, which is equal to the lower edge of the receiving window, RX_Next, so that the transmitting and receiving windows are synchronized.

[0178] Optionally, the correction status report can also be used to correct the aforementioned NACK to ACK error that occurred in the first device. The correction status report also includes: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status. The first status indicates that the RLC PDU is in a confirmed transmission success state, and the second status indicates that the RLC PDU is in a state where the second device has not confirmed successful transmission. Here, the confirmed transmission success state refers to the state where the second device has confirmed successful transmission, i.e., the ACK state.

[0179] Optionally, the first state can also be described as a confirmed successful transmission state, a successful reception state, or an ACK state, and the second state can be a confirmed transmission failure state or a pending state. A confirmed transmission failure state can also be described as an unsuccessful reception state or a NACK state. Both ACK and NACK states are deterministic states, while the pending state is a non-deterministic state. Based on this, the corrective status report includes at least one of the following: the sequence number of the RLC PDU in the ACK state, the sequence number of the RLC PDU in the pending state, and the sequence number of the RLC PDU in the NACK state. If an RLC PDU is in the pending state in the corrective status report, it indicates that the RLC PDU is being transmitted for the first time or has failed to be transmitted and is being retransmitted; it is a data packet in a pending state. If an RLC PDU is in the ACK state in the corrective status report, it indicates that the RLC PDU has been successfully received by the second device; it is a successfully received data packet. If an RLC PDU is in the NACK state in the corrective status report, it indicates that the RLC PDU has been determined by the second device to have failed to be transmitted; it is a data packet that was not successfully received.

[0180] In this context, the pending state refers to a state where the second device has not yet confirmed the successful transmission; it is neither a clear success nor a clear failure. The NACK state indicates that the second device has clearly confirmed the unsuccessful transmission, representing a clear transmission failure. Due to the introduction of the fast windowing mechanism, the feedback frequency of the correction status report is relatively high. Before the traditional reassembly timer expires, the HARQ process may not have completed all retransmission attempts, or the decoding result may be uncertain. Therefore, when a correction status report needs to be sent, the final transmission status of some RLC PDUs may not be determined, thus introducing a pending state in the correction status report for these RLC PDUs. After the HARQ process completes all retransmission attempts, the pending state may change to a definite ACK or NACK state.

[0181] Optionally, the correction status report uses the same format as the status report for the traditional RLC layer, except that it includes the sequence number of the RLC PDU in the pending state. This status report for the traditional RLC layer is also referred to as the traditional status report described above.

[0182] Optionally, the correction status report includes the reception status of the expected RLC PDU, which is either the first status or the second status mentioned above. That is, the correction status report does not include the NACK status found in traditional status reports.

[0183] Optionally, the correction status report can ensure transmission integrity through CRC checksum verification. In other words, the correction status report is CRC protected, providing the true status from the receiver's (i.e., the second device's) perspective and eliminating false ACK errors common in physical layer HARQ feedback. If the first device relies solely on HARQ feedback windowing, it might mistakenly assume data packets have been successfully received and delete the buffer, leading to data loss. The correction status report is generated by the receiver's RLC layer based on the actual reception results. The receiver clearly knows which data packets (RLC PDUs) have been successfully decoded and are in a confirmed successful transmission state, and which are in a pending state. Furthermore, the correction status report is CRC protected. Therefore, the lower edge of the received window and the state of the RLC PDUs confirmed in the correction status report are accurate, providing a reliable basis for the accurate advancement of the transmission window.

[0184] Optionally, the correction status report is a control PDU at the RLC layer, which can be encapsulated in a data block at the MAC layer for transmission. Data transmission at the MAC layer is typically protected by CRC checksums. If a bit error occurs during transmission, the receiving device (such as the RLC entity in the second device) will detect the error through CRC checksum and discard the data packet, rather than mistaking it for a correct ACK. Therefore, if the first device receives the correction status report, it indicates that the content of the correction status report itself is complete and correct.

[0185] S53, the first device updates the first lower edge of the transmitting window to the second lower edge, which is the same as the lower edge of the receiving window.

[0186] It should be understood that since the second status report received by the first device includes the lower edge of the receiving window of the second device, the first device can determine the lower edge of the receiving window and determine the second lower edge of the sending window based on the lower edge of the receiving window. The first lower edge of the sending window is then updated to the second lower edge, making the second lower edge of the sending window the same as the lower edge of the receiving window. Compared to the virtual update of the lower edge of the sending window described above, the update involved in S53 can be understood as an actual update of the lower edge of the sending window, in order to actually push the sending window (referred to as actual window pushing).

[0187] Optionally, actual window pushing means updating the first lower edge of the sending window to the second lower edge and deleting RLC PDUs with sequence numbers less than the second lower edge from the cache.

[0188] In this way, even if the lower edge of the transmitting window leads the lower edge of the receiving window due to the rapid window pushing of the first device, the transmitting window can be corrected through the correction status report, thereby improving the reliability of rapid window pushing.

[0189] For example, upon determining a second falling edge, the first device can delete a second RLC PDU, where the sequence number of the second RLCPDU is less than the second falling edge of the transmission window. The second RLC PDU can refer to an RLC PDU in the buffer whose sequence number is less than the second falling edge.

[0190] Optionally, after updating the first lower edge of the transmission window to the second lower edge, the first device deletes the aforementioned second RLC PDU. It should be understood that updating the first lower edge of the transmission window to the second lower edge is the result of actual window pushing, and there is no window pushing error. Therefore, after updating the first lower edge of the transmission window to the second lower edge, the aforementioned second RLCPDU can be deleted directly to release buffer space in a timely manner.

[0191] The correction status report includes the lower edge of the receive window, meaning that all RLC PDUs with sequence numbers less than the lower edge of the receive window have been successfully received and delivered to the upper layer in order at the receiving device. Since the first device has clearly known from the correction status report that RLC PDUs with sequence numbers less than the lower edge of the receive window have been successfully received, after updating the first lower edge of the transmit window to the second lower edge, the first device can directly delete the aforementioned second RLC PDU, thus avoiding data packet loss and saving memory.

[0192] It should be understood that before receiving the correction status report, the first device may have performed a virtual windowing based on the ACK inter-layer report, pushing the lower edge of the sending window to a larger value (e.g., SN=13). However, this may be incorrect, so the first device will not immediately delete RLC PDUs with SN<13 from the buffer. The correction status report will correct the lower edge of the sending window to the actual reception progress (e.g., SN=6). At this time, RLC PDUs with SN<6 are confirmed by both parties to have been successfully transmitted, therefore, the first device can delete RLC PDUs with SN<6. This deletion operation is based on receiving the correction status report, which solves the risk of accidental deletion caused by false ACK errors in fast windowing, and ensures that the sending device only releases buffer resources after the receiving device confirms successful reception at the RLC layer.

[0193] The above text introduced how to correct erroneous results from virtual push windows using calibration status reports. It should be understood that the result of a virtual push window could also be correct. If the result is correct, a calibration status report will not be triggered. In other words, if the result is correct, the second device will not send a calibration status report to the first device, and the first device will not receive a calibration status report.

[0194] For example, if the second device receives the instruction information and determines that the first lower edge of the sending window is the same as the lower edge of the receiving window, then the second device determines that the result of the virtual window push is correct. In order to let the first device know that the result of the virtual window push is correct, a second timer is introduced in this embodiment.

[0195] In some embodiments, if the second timer times out and no second status report is received, the first device deletes the first RLC PDU, the sequence number of the first RLC PDU being less than the first lower edge of the transmission window; wherein the second timer is started when an indication message is sent to the second device.

[0196] The second timer, also known as the t-correct timer, tracks the reception of the correction status report to enable the first device to determine whether the virtual windowing result is correct. Specifically, it determines whether updating the lower edge of the sending window to the first lower edge is correct. In other words, the second timer tracks and confirms whether the fast windowing is correct. Because HARQ feedback may contain false ACKs, the first device needs to wait for a period after the fast windowing to see if the second device will send a second status report indicating a windowing error.

[0197] Optionally, the first device may start a second timer when sending instruction information to the second device. For example, the first device may start the second timer at the same time as sending instruction information to the second device, or the first device may start the second timer after or before sending instruction information to the second device.

[0198] Optionally, the indication information is carried in the header of the third RLC PDU. Therefore, when the first device retransmits the third RLC PDU to the second device, it can start the second timer. For example, the first device can start the second timer at the same time as retransmitting the third RLC PDU to the second device, or the first device can start the second timer after or before retransmitting the third RLC PDU to the second device.

[0199] If the second timer times out and no second status report is received, the first device can determine that no error has occurred in the virtual window push. At this point, the first device can determine that the first falling edge TX_VirNext_Ack is the actual falling edge, and the first device will delete the RLC PDU with a sequence number less than the first falling edge. This RLC PDU with a sequence number less than the first falling edge is the aforementioned first RLCPDU. In this way, the first device can delete the first RLC PDU only after ensuring that no error has occurred in the virtual window push, avoiding data loss caused by rapidly pushing the transmission window and improving the reliability of fast window push.

[0200] Optionally, to ensure the first device is aware that the virtual push window result is correct, the second device can send a notification message to the first device. This notification message indicates that no error occurred during the virtual push window process. For example, the second device can send the notification message to the first device if it determines that the lower edge of the sending window is the same as the lower edge of the receiving window. Upon receiving this notification message, the first device deletes the aforementioned first RLC PDU.

[0201] In some embodiments, the shutdown condition for the second timer includes at least one of the following: The first device receives a second status report from the second device; The first device receives a third status report from the second device; The first device determines that the second timer has timed out.

[0202] It should be understood that if the first device receives the second status report, it can determine that an error has occurred in the virtual push window, and therefore, the first device can turn off the second timer. Alternatively, since the second timer is used to track the reception of the correction status report (i.e., the second status report), and since the first device has already received the second status report, there is no need to track it further; therefore, the second timer can be turned off.

[0203] The aforementioned third status report refers to the traditional status report, which includes the reception status of the expected RLC PDU. The reception status can be either ACK or NACK. The third status report is sent by the second device when the reassembly timer times out. The third status report can serve as a basis for correcting the virtual window push result. The first device can push the transmission window based on this third status report. If the lower edge of the transmission window determined based on the third status report is the same as the first lower edge, the first device can determine that no error has occurred in the virtual window push. If the lower edge of the transmission window determined based on the third status report is different from the first lower edge, the first device can determine that an error has occurred in the virtual window push and update the first lower edge of the transmission window to a fourth lower edge, which is the lower edge of the transmission window determined based on the third status report.

[0204] Since the shutdown condition for the second timer includes receiving a second status report from the second device, it means that if the first device receives the second status report, the second timer will be shut down. Therefore, if the second timer times out, it also means that the first device has not received the second status report. Thus, the above-mentioned deletion of the first RLC PDU in the case of the second timer timeout and no second status report received can be simplified as follows: In the case of the second timer timeout, the first RLCPDU is deleted.

[0205] The aforementioned second timer timeout refers to the fact that the runtime (also known as the timing duration) of the second timer after its start is greater than the corresponding second duration. The specific value of the second duration can be pre-configured or agreed upon by the protocol.

[0206] Optionally, the second duration can be greater than the round-trip time (RTT) of a data packet transmission. For example, the second duration can be 8 to 12 milliseconds.

[0207] Optionally, the second timer can be turned off if it times out.

[0208] In the above method, if the first device receives a correction status report or a traditional status report before the second timer expires, it means that the second device has clearly informed the first device of the reliable status of the data packet (whether successful or not). At this time, there is no need to wait any longer, and the second timer can be turned off directly.

[0209] In some embodiments, the shutdown condition for the first timer includes at least one of the following: The first device receives a second status report from the second device; The first device receives a third status report from the second device; The first device determines that the first timer has timed out.

[0210] If the first device receives the second status report, it can determine that an error has occurred in the virtual push window. Therefore, the first device can turn off the first timer and wait for a new ACK inter-layer report to trigger the first timer to start the next virtual push window.

[0211] If the first device receives the third status report, it can verify whether the virtual push window has malfunctioned based on the third status report. Therefore, the first device can turn off the first timer and wait for a new ACK inter-layer report to trigger the first timer to start the next virtual push window.

[0212] It should be understood that since both the second and third status reports are reliable and protected by CRC, if the first device receives either the second or third status report, it means that the actual windowing can be performed based on the reliable second or third status report, without needing to rely on the ACK inter-layer report to perform the virtual windowing. Therefore, the first timer can be turned off.

[0213] The aforementioned first timer timeout refers to the fact that the runtime (also known as the timing duration) of the first timer after its start is greater than the first duration corresponding to the first timer. The specific value of the first duration can be pre-configured or agreed upon by the protocol.

[0214] Optionally, the first duration is less than 80 milliseconds. For example, the first duration can be around 10 milliseconds. Optionally, the first duration can be 8 to 12 milliseconds.

[0215] Optionally, the first timer can be turned off if the first timer times out.

[0216] In some embodiments, the second status report further includes: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status. The first status indicates that the RLC PDU is in a state where transmission is confirmed to be successful, and the second status indicates that the RLC PDU is in a state where transmission has not been confirmed to be successful by the second device. For a detailed explanation of the first and second statuses, please refer to the relevant descriptions above; they will not be repeated here.

[0217] For example, if the status flag of an RLC PDU is the first value and the sequence number of the RLC PDU corresponds to the first status, the first device deletes the RLC PDU. The first value indicates that the RLC PDU has a successful transmission status in the first status report, and the sequence number of the RLC PDU corresponding to the first status indicates that the RLC PDU has also a successful transmission status in the second status report. At this point, the first device can confidently determine that the RLC PDU has indeed been successfully transmitted. The first value of the RLC PDU's status flag is not due to an error where NACK changes to ACK; therefore, the first device can directly delete the RLC PDU.

[0218] For example, if the status flag of the RLC PDU is a first value and the sequence number of the RLC PDU corresponds to a second state, the first device retransmits the RLC PDU. The fact that the sequence number of the RLC PDU corresponds to a second state indicates that the RLC PDU did not show a successful transmission status in the second state report, but rather a pending or NACK status. In this case, the first device determines that the status flag of the RLC PDU is a first value because there is an error where NACK changed to ACK. Therefore, the first device needs to retransmit the RLC PDU.

[0219] For ease of understanding, the following explanation will use the state flag as the first value, which can be represented as S=1.

[0220] When the status flag S=1 of the RLC PDU (RLC SDU or RLC SDU segment) with sequence number SN=x in the buffer, and the RLC PDU with sequence number SN=x is in a pending or NACK state in the second status report, then the first device retransmits the RLCPDU with SN=x.

[0221] When the status flag S=1 of the RLC PDU (RLC SDU or RLC SDU segment) with sequence number SN=x in the cache, and If the RLC PDU with sequence number SN=x is in a confirmed transmission success state (such as ACK state) in the second status report, then the first device deletes the RLC PDU with SN=x from its buffer.

[0222] When the status flag S=1 of the RLC PDU (RLC SDU or RLC SDU segment) with sequence number SN=x in the cache, and the RLC PDU with sequence number SN=x is in the NACK state in the third status report (i.e., the traditional status report), then the first device retransmits the RLC PDU with SN=x.

[0223] When the status flag S=1 of the RLC PDU (RLC SDU or RLC SDU segment) with sequence number SN=x in the cache, and the RLC PDU with sequence number SN=x is in the ACK state in the third status report (i.e. the traditional status report), then the first device deletes the RLC PDU with SN=x from the cache.

[0224] The above method compares the status of the RLC PDU in the second status report with the status of the RLC PDU in the cache. This allows the first device to detect the error of NACK turning into ACK more quickly and earlier, thereby accelerating retransmission.

[0225] To gain a deeper understanding of the method provided in the embodiments of this application, the method is further explained below in conjunction with the process of the first device sending an RLC PDU and the second device receiving an RLC PDU. An RLC PDU can be an RLC SDU or a segment of an RLC SDU. In the following description, the first device is referred to as the sending device (hereinafter referred to as the sending end), the second device as the receiving device (hereinafter referred to as the receiving end), the first status report is used as an ACK inter-layer report, the second status report is used as a correction status report, the third status report is used as a traditional status report, the first timer is used as a t-PushWindow timer, and the second timer is used as a t-correct timer. It should be understood that the following process is only an example of the implementation of this method and does not constitute a limitation. The following is divided into three parts: 1. The process of the sending end sending data; 2. The processing of the inter-layer report and the correction status report by the sending end; 3. The process of the receiving end receiving data.

[0226] 1. The process of the sending end sending data: During data transmission, in addition to maintaining the transmission window as described in the above embodiment, the transmitting end also maintains the transmission status variable TX_Next. The transmission status variable TX_Next indicates the serial number (SN) of the next RLC PDU to be transmitted for the first time. The value in the transmission status variable TX_Next is assigned to the newly generated (next to be transmitted) RLC PDU. It should be understood that if the newly generated RLC PDU is segmented, the value of TX_Next will be used as the SN of each RLC PDU segment.

[0227] The initial value of TX_Next can be 0, and it increments sequentially with each RLC PDU sent. Specifically, when the RLCPDU encapsulates a complete RLC SDU or the last block of an RLC SDU, TX_Next is incremented by 1.

[0228] For example, Figure 6 This is a flowchart illustrating an example of a data transmission process provided in an embodiment of this application.

[0229] like Figure 6 As shown, the process of the sending end sending data includes: S61, the RLC entity of the sending end is initialized with TX_VirNext_Ack = TX_Next_Ack.

[0230] For example, the RLC entity at the transmitting end initializes the virtual transmit window's lower edge TX_VirNext_Ack to TX_Next_Ack.

[0231] S62, the RLC entity at the sending end receives an RLC SDU from the upper layer (PDCP layer).

[0232] The RLC layer at the transmitting end is in AM mode, therefore the RLC entity at the transmitting end is called an AM RLC entity.

[0233] Optionally, if the RLC entity at the sending end receives an RLC SDU from the upper layer, it can store the RLC SDU in a cache.

[0234] S63, the sending RLC entity associates the value of TX_Next with the RLC SDU.

[0235] The association of the TX_Next value with the RLC SDU can be understood as temporarily using the TX_Next value as the SN of the RLC SDU.

[0236] In S64, the RLC entity at the transmitting end determines whether the value of TX_Next associated with the RLC SDU falls within the transmission window; if yes, step S65 is executed; if no, step S66 is executed, and the RLC SDU is stored in the buffer.

[0237] As described above, the RLC entity at the transmitting end transmits data packets based on the transmission window. If the SN of the to-be-transmitted RLC SDU falls within the transmission window (or is located within the transmission window), the RLC entity at the transmitting end transmits the RLC SDU. In this case, the RLC entity at the transmitting end formally uses the value of TX_Next associated with the RLC SDU as the SN of the RLC SDU, and performs operations such as encapsulation.

[0238] If the SN of the to-be-transmitted RLC SDU does not fall within the transmission window and is located outside the transmission window, the RLC is not transmitted temporarily SDU, and the RLC SDU is temporarily stored in the buffer. In this case, the RLC entity at the transmitting end releases the association relationship between the RLC SDU and the value of TX_Next, and releases TX_Next.

[0239] Exemplarily, determining whether the value of TX_Next associated with the RLC SDU falls within the transmission window is equivalent to: determining whether TX_Next_Ack <= SN < TX_Next_Ack + AM_Window_Size is satisfied. If the condition is satisfied, the value of TX_Next associated with the RLC SDU falls within the transmission window; if the condition is not satisfied, the value of TX_Next associated with the RLC SDU does not fall within the transmission window. TX_Next_Ack + AM_Window_Size refers to the upper edge of the transmission window.

[0240] In S65, the RLC entity at the transmitting end uses the value of TX_Next associated with the RLC SDU as the SN of the RLC SDU, and encapsulates the RLC SDU to obtain one or more RLC PDUs.

[0241] Optionally, if the RLC entity at the transmitting end does not segment the RLC SDU, the RLC entity at the transmitting end puts the value of TX_Next into the SN field of one constructed RLC PDU; if the RLC entity at the transmitting end segments the RLC SDU, the RLC entity at the transmitting end puts the value of TX_Next into the SN field of the RLC PDU corresponding to each constructed RLC SDU segment respectively.

[0242] In S66, the RLC entity at the transmitting end stores the RLC SDU into the buffer.

[0243] S67, the RLC entity of the transmitting end submits the RLC PDU containing the RLC SDU or RLC SDU segments to the MAC layer to fill the transport block of the MAC layer.

[0244] S68, the MAC layer of the transmitting end submits the MAC PDU to the PHY layer, the PHY layer of the transmitting end modulates and encodes the MAC PDU to generate the first transport block, and sends the first transport block to the receiving end.

[0245] S69, the sending end updates the RLC entity TX_Next=TX_Next+1.

[0246] The above process describes how the RLC entity at the sending end sends data.

[0247] 2. Processing of inter-layer reports and correction status reports by the sending end: During the data transmission process of the RLC entity at the sending end, the RLC entity at the sending end can also perform virtual windowing or data retransmission based on the inter-layer report, and can also correct the result of virtual windowing based on the correction status report.

[0248] Figure 7 This is a schematic flowchart illustrating the processing procedure of inter-layer reports and correction status reports by the transmitting end, as provided in an embodiment of this application.

[0249] S71, the MAC layer of the transmitting end receives the feedback report from the receiving end, determines whether the MAC subPDU in the first transmission block has been successfully transmitted, and constructs an inter-layer report based on the LCID and RLC PDU sequence number in the MAC subheader.

[0250] As shown above, if the sending end's MAC layer determines that the MAC subPDU in the first transport block has been successfully transmitted based on the feedback report, it constructs an ACK inter-layer report based on the LCID and RLC PDU sequence number in the MAC subPDU's MAC subheader. If the sending end's MAC layer determines that the MAC subPDU in the first transport block has not been successfully transmitted based on the feedback report, it constructs a NACK inter-layer report based on the LCID and RLC PDU sequence number in the MAC subPDU's MAC subheader.

[0251] Optionally, one LCID corresponds to one inter-layer report. The MAC layer of the sending end sends the constructed inter-layer report to the RLC layer of the sending end.

[0252] S72, the RLC layer of the sending end determines whether it has received the inter-layer report sent by the MAC layer. If yes, proceed to step S73; otherwise, proceed to step S714.

[0253] S73, the RLC layer of the sending end reads the LCID in the inter-layer report and sends the inter-layer report to the corresponding ARQ entity according to the LCID.

[0254] The following describes the process of receiving and processing inter-layer reports. Since the previous steps have already sent the inter-layer reports to the corresponding ARQ entities, the subsequent processing of inter-layer reports can be performed by the ARQ entity of the RLC layer.

[0255] S74, the ARQ entity at the sending end determines whether the inter-layer report is a NACK inter-layer report. If it is, proceed to step S75; otherwise, proceed to step S76.

[0256] S75, the ARQ entity at the sending end reads the sequence number of the RLC PDU in the NACK interlayer report, then retransmits the RLC PDU corresponding to these sequence numbers, and proceeds to step S714.

[0257] S76, the ARQ entity at the sending end reads the sequence number of the RLC PDU in the ACK interlayer report and sets the status flag S of the RLC PDU corresponding to these sequence numbers to 1.

[0258] S77, the ARQ entity at the sending end determines whether the t-PushWindow timer has not been started. If so, proceed to step S78; otherwise, proceed to step S79.

[0259] S78, the ARQ entity at the sending end starts the t-PushWindow timer.

[0260] S79, the ARQ entity at the sending end determines whether the t-PushWindow timer has timed out. If so, proceed to step S710; otherwise, proceed to step S714.

[0261] S710, the ARQ entity at the sending end determines whether SN = TX_Next_Ack exists in the ACK inter-layer report, and whether the RLC SDUs corresponding to TX_Next_Ack have been successfully sent. If so, proceed to step S711; otherwise, proceed to step S714.

[0262] The ACK inter-layer reports in this step can include all ACK inter-layer reports received by the ARQ entity during the runtime of the t-PushWindow timer.

[0263] S711, the ARQ entity at the transmitting end obtains the sequence number SN of the first RLC SDU that has not been completely transmitted after TX_Next_Ack, and assigns the SN to TX_VirNext_Ack.

[0264] In other words, if the sequence number SN in all ACK inter-layer reports received during the t-PushWindow timer operation includes the third lower edge TX_Next_Ack and the RLC SDU corresponding to the third lower edge TX_Next_Ack has been successfully transmitted, then the first lower edge TX_VirNext_Ack is the sequence number corresponding to the first RLC SDU that was not completely transmitted after the third lower edge TX_Next_Ack.

[0265] S712, TX_Next_Ack = TX_VirNext_Ack.

[0266] In other words, after the t-PushWindow timer expires, the ARQ entity at the sending end updates the lower edge of the sending window to the first lower edge TX_VirNext_Ack to realize virtual window pushing and start the transmission of new data.

[0267] The above process can be understood as follows: When the RLC layer at the sending end receives the ACK inter-layer report sent by the MAC layer, it finds the corresponding ARQ entity based on the LCID of the ACK inter-layer report. The ARQ entity then looks up the RLCPDU in the buffer based on the sequence number SN of the ACK inter-layer report. It uses the sequence numbers of these RLC PDUs to virtually update the lower edge TX_VirNext_Ack of the sending window, virtually pushing the sending window forward to ensure that new data transmission can be performed. Additionally, the status flag S of these RLC PDUs is set to 1, indicating that the transmission is temporarily considered successful.

[0268] S713, the sending end retransmits the ARQ entity retransmission sequence number SN = TX_VirNext_Ack RLC PDU, sets the W flag in the header of the RLCPDU to 1, and starts the t-correct timer.

[0269] In other words, while the RLC layer at the transmitting end is sending new data, it also needs to retransmit the third RLC PDU. The sequence number of the third RLC PDU is the first falling edge TX_VirNext_Ack, and a t-correct timer is started simultaneously. The reserved bits W in the header of the third RLC PDU carry indication information to indicate to the receiving end that the sequence number of this third RLC PDU is the first falling edge TX_VirNext_Ack of the transmission window after the virtual push window.

[0270] The following describes the processing flow for correction status reports.

[0271] In step S714, the ARQ entity at the sending end determines whether a correction status report (or traditional status report) has been received. If yes, proceed to step S715; otherwise, proceed to step S720.

[0272] In S715, the ARQ entity at the transmitting end reads the lower edge RX_Next of the reception window in the corrected status report (or the conventional status report), and updates TX_Next_Ack to RX_Next.

[0273] It can be seen in conjunction with the above S712 that the lower edge of the transmission window has been updated to the first lower edge TX_VirNext_Ack in S712. Therefore, this S715 can be understood as updating the first lower edge of the transmission window to a second lower edge, where the second lower edge is the same as RX_Next. Updating the first lower edge of the transmission window to the second lower edge can also be described as: updating the lower edge of the transmission window from the first lower edge to the second lower edge.

[0274] S716: The ARQ entity at the transmitting end deletes the RLC PDUs with SN < TX_Next_Ack in the buffer.

[0275] In this step, TX_Next_Ack refers to the above-mentioned second lower edge, therefore S716 refers to deleting the RLC PDUs with sequence numbers smaller than the second lower edge in the buffer.

[0276] In S717, when the status flag S of the RLC PDU with sequence number SN=x in the buffer is 1, and it is in a pending state in the corrected status report, the ARQ entity at the transmitting end retransmits the RLC PDU with SN=x.

[0277] Optionally, if a conventional status report is received in the above S714, then when the status flag S of the RLC PDU with sequence number SN=x in the buffer is 1, and it is in the NACK state in the conventional status report, the ARQ entity at the transmitting end retransmits the RLC PDU with SN=x.

[0278] In S718, when the status flag S of the RLC PDU with sequence number SN=x in the buffer is 1, and it is in the ACK state in the corrected status report, the ARQ entity at the transmitting end deletes the RLC SDU with SN=x in the buffer.

[0279] Optionally, if a conventional status report is received in the above S714, then when the status flag S of the RLC PDU with sequence number SN=x in the buffer is 1, and it is in the ACK state in the conventional status report, the ARQ entity at the transmitting end deletes the RLC SDU with SN=x in the buffer.

[0280] In S719, the ARQ entity at the transmitting end stops the t-correct timer and the t-PushWindow timer.

[0281] In S720, the ARQ entity at the transmitting end determines whether the t-correct timer expires. If yes, S721 is executed; otherwise, the process returns to S71.

[0282] In S721, the ARQ entity at the transmitting end deletes RLC SDUs with SN < TX_Next_Ack, and stops the t-correct timer and the t-PushWindow timer.

[0283] That is, when the t-correct timer expires, the transmitting end confirms that no error has occurred in the virtual window pushing, the lower edge of the transmission window TX_Next_Ack = TX_VirNext_Ack, and at the same time, deletes the RLC PDUs with SN < TX_VirNext_Ack in the buffer.

[0284] 3. The process of the receiving end receiving data: Figure 8 is a schematic flowchart of an example of the process for the receiving end to receive data provided by the embodiments of the present application.

[0285] For example, as shown in Figure 8 , the operations performed by the RLC entity at the receiving end include the following steps.

[0286] In S81, the RLC entity at the receiving end receives an RLC PDU whose SN field value is x from the lower layer (MAC layer).

[0287] The RLC layer at the receiving end is in AM mode, so the RLC entity at the receiving end may be referred to as an AM RLC entity.

[0288] This RLC PDU contains an SN and an RLC SDU or an RLC SDU segment (several bytes of the RLC SDU). The SN is the SN corresponding to the RLC SDU or the RLC SDU segment. In this embodiment, it is assumed that this RLC PDU contains bytes y to z of the RLC SDU with SN = x.

[0289] In S82, the RLC entity at the receiving end determines whether x falls outside the reception window; if not, step S83 is executed; if yes, indicating that x falls outside the reception window, the RLC PDU is discarded.

[0290] As described above, the RLC entity at the receiving end receives data packets based on the reception window. If the SN of the to-be-received RLC SDU or RLC SDU segment falls within the reception window (or is located within the reception window), the RLC entity at the receiving end receives this RLC SDU. If the SN of the to-be-received RLC SDU or RLC SDU segment does not fall within the reception window and is located outside the reception window, the RLC SDU or RLC SDU segment is discarded. The RLC SDU or RLC SDU segment (referred to as RLC SDU segment for short) may be understood as an RLC PDU.

[0291] Exemplarily, determining whether x falls within the reception window is specifically: determining whether RX_Next≤x<RX_Next+ AM_Window_Size is satisfied; if satisfied, the x falls within the reception window. If x<RX_Next or x ≥RX_Next + AM_Window_Size, the x does not fall within the reception window (i.e., falls outside the reception window), and the RLC PDU is discarded.

[0292] In S83, the RLC entity at the receiving end determines whether part of the bytes of the RLC SDU with SN = x have been received; if yes, the RLC PDU is discarded; if no, step S84 is executed.

[0293] That is, the RLC entity at the receiving end determines whether the RLC SDU or the segment of the RLC SDU in the RLC PDU has been received. In other words, the RLC entity at the receiving end determines whether bytes y to z of the RLC SDU with SN=x have been received.

[0294] In S84, the RLC entity at the receiving end determines whether x is greater than or equal to RX_Next_Highest. If yes, S85 is executed, otherwise S86 is executed.

[0295] RX_Next_Highest refers to the SN next to the maximum SN of the received RLC SDU within the reception window. Optionally, the initial value of RX_Next_Highest is set to 0.

[0296] In S85, the RLC entity at the receiving end updates RX_Next_Highest to x + 1.

[0297] In S86, the RLC entity at the receiving end stores the RLC PDU (with sequence number SN= x) in the buffer.

[0298] In S87, the RLC entity at the receiving end determines whether all bytes of the RLC SDU with SN=x have been received; if yes, step S88 is executed; if no, no processing is performed, and the reception of the RLC SDU is continued to be waited for.

[0299] In S88, the RLC entity at the receiving end assembles the RLC SDU with SN=x, and delivers the assembled RLC SDU to the upper layer.

[0300] Specifically, the RLC entity at the receiving end removes the header of each RLC PDU whose SN field value is x, assembles the RLC SDU or the segment of the RLC SDU therein to form the complete RLC SDU with SN=x, and then delivers the RLC SDU with SN=x to the upper layer (PDCP layer).

[0301] S89: The RLC entity at the receiving end determines whether x is equal to RX_Next. If yes, proceed to step S810; otherwise, proceed to step S811.

[0302] If x = RX_Next, it means that all RLC SDUs corresponding to the lower edge of the receive window have been successfully received, so S810 can be executed to update the lower edge of the receive window.

[0303] S810, the receiving end's RLC entity updates the bottom edge of the receiving window to the SN of the first RLC SDU that has not yet received all bytes after x.

[0304] In other words, RX_Next is updated to the sequence number (SN) of the first RLC SDU that has not received all bytes. The SN of this RLC SDU is greater than the current RX_Next, which is sequence number x. An RLC SDU that has not received all bytes is an RLC SDU that has not been fully received.

[0305] S811, the RLC entity at the receiving end determines whether the value of the W flag in the header of the RLC PDU with SN=x is 1 and whether x is greater than RX_Next. If so, S812 is executed; otherwise, no processing is performed.

[0306] S812, the receiving end's RLC entity sends a correction status report to the sending end's RLC entity.

[0307] That is, when the receiving end receives an RLC PDU with window indication bit W=1 in the header, if the falling edge RX_Next of the receiving window is less than the sequence number x of the RLC PDU with W=1, then the receiving end sends a correction status report (including RX_Next) to the sending end, announcing the transmission status of the RLC PDU within the receiving window. The content of this correction status report includes: the falling edge RX_Next of the receiving window, the sequence number of the RLC PDU in the ACK state, the sequence number of the RLC PDU in the pending state, and the sequence number of the RLC PDU in the NACK state.

[0308] After receiving the correction status report, the sending end updates the lower edge of the sending window to RX_Next. It uses the sequence number of the pending RLC PDU in the correction status report to look up the status of the RLC PDU in the buffer. If the found RLC PDU has S=1 and is pending in the correction status report, then the RLC PDU is immediately retransmitted; otherwise, the RLC PDU is deleted.

[0309] The above process describes how the receiving RLC entity receives and assembles the RLC SDU, as well as the process of triggering the correction status report.

[0310] It should be noted that, since this application embodiment mainly describes the ARQ mechanism of the RLC layer, the RLC entity of the RLC layer can also be described as an ARQ entity. That is, the RLC entity and ARQ entity in this application embodiment can have the same meaning. Since the RLC layer may have multiple ARQ connections, the RLC layer includes multiple ARQ entities, and each ARQ entity corresponds to a logical channel.

[0311] In this embodiment, the close interaction between the MAC layer and RLC layer of the transmitting end is utilized to rapidly advance the transmission window, and an RLC PDU with sequence number SN = TX_VirtualNext_Ack is retransmitted to the receiving end to announce the update status of the lower edge of the transmission window (the header of the third RLC PDU carries W=1). If TX_VirtualNext_Ack > RX_Next, the receiving end will trigger a correction status report (containing RX_Next). After receiving the correction status report, the transmitting end updates the lower edge of the transmission window again, and uses the correction status report to detect the error of NACK changing to ACK. In other words, this embodiment introduces an RLC PDU containing W=1, carrying information about rapid window advancement (i.e., the first lower edge of the transmission window TX_VirtualNext_Ack), and then uses the correction status report to allow the transmitting end to detect the NACK changing to ACK error faster and earlier, thereby accelerating retransmission.

[0312] The following is combined with Figures 9 to 12 The above implementation process is described with examples.

[0313] Figure 9 This is a schematic diagram illustrating the initial state of a sending window and a receiving window as provided in an embodiment of this application.

[0314] For example, such as Figure 9 As shown in (a) and (b), in the initial state, the lower edges of the transmitting and receiving windows are synchronized, i.e., TX_Next_Ack = RX_Next = 1. like Figure 9 As shown in (a), the sequence numbers of RLC SDUs (i.e., unacknowledged data packets) that were not successfully transmitted within the sending window include: 1, 6, and 13. The sequence numbers of RLC SDUs (i.e., acknowledged data packets) that were successfully transmitted within the sending window include: 2~5, 7~12, and 14~81. The sequence numbers of RLC SDUs (i.e., data packets to be sent) outside the sending window include: 82~92.

[0315] like Figure 9As shown in (b), the sequence numbers of RLC SDUs in the pending state within the receive window include: 1, 6, and 13. The sequence numbers of RLC SDUs successfully received within the receive window (i.e., successfully received data packets) include: 2~5, 7~12, and 14~81. The sequence numbers of RLC SDUs outside the receive window (i.e., data packets to be received) include: 82~92.

[0316] Figure 10 This is a schematic diagram of an example of actively pushing a sending window provided in an embodiment of this application.

[0317] For example, such as Figure 10 As shown in (a), assume the sender sends two ACK interlayer reports to the RLC layer via the MAC layer. The first ACK interlayer report informs the RLC layer that the RLC PDU with SN=1 was successfully transmitted, and the second ACK interlayer report informs the RLC layer that the RLC PDU with SN=6 was successfully transmitted. However, the second ACK interlayer report conveys incorrect information because the HARQ feedback sent by the receiver shows an error where NACK becomes ACK. That is, the RLC PDU with SN=6 belongs to a data packet that was acknowledged based on a HARQ feedback error, but the RLC layer sets the status flag S of the RLC PDU with SN=6 to 1 based on the ACK interlayer report. Based on the two received ACK interlayer reports, the sender determines that the two received ACK interlayer reports include the third lower edge (the lower edge of the transmission window in the initial state, i.e., SN=1) and that the RLC SDU corresponding to the third lower edge has been successfully transmitted. The sender determines that the first lower edge TX_VirNext_Ack is the sequence number (SN=13) of the first incompletely transmitted RLC SDU after the third lower edge (SN=1). Therefore, the transmitter updates TX_Next_Ack to 13 at the bottom edge of the transmission window (i.e., TX_Next_Ack = TX_VirtualNext_Ack = 13) to actively push the transmission window (i.e., virtual window push). At this time, the sequence numbers of RLC SDUs within the transmission window include: 13~93.

[0318] like Figure 10 As shown in (b), after receiving an RLC SDU with SN=1, the receiver updates the lower edge RX_Next of the receive window to the SN of the first RLC SDU that has not yet received all its bytes after SN=1 (SN=6 in the figure). That is, the receiver updates the lower edge RX_Next of the receive window to SN=6. At this time, the sequence numbers of the RLC SDUs within the receive window include: 6~86. Combined with... Figure 9 (b) and Figure 10 As can be seen from (b) in the figure: the state of the data packet with SN=1 changes from the pending state to the successfully received state (ACK state).

[0319] Figure 11 is a schematic diagram illustrating the principle of triggering a correction status report according to an embodiment of the present application.

[0320] For example, as shown in Figure 11 in (a), the transmission window actively slides to SN=13, that is, the transmitting end performs virtual window advancement, so that the transmitting end can transmit RLC PDUs with SN=82 to 93. At the same time, the transmitting end retransmits the RLC PDU with SN=13, and the W flag in the header of this RLC PDU is set to 1, indicating that the sequence number of this RLC PDU is the value of the first lower edge TX_VirNext_Ack of the transmission window.

[0321] As shown in Figure 11 in (b), the receiving end discards the received RLC PDUs with SN=87 to 93, because these RLC PDUs are outside the reception window. The receiving end receives the RLC PDU with SN=13, finds that the W flag in the header of this RLC PDU is 1, reads the sequence number 13 of this RLC PDU, the receiving end further learns that RX_Next = 6 < TX_Next_Ack = 13, determines that an error of NACK turning into ACK occurs at the transmitting end, and immediately triggers the transmission of a correction status report. The content of the correction status report includes: the lower edge RX_Next (SN=6) of the reception window, the sequence numbers of RLC PDUs determined to be successfully transmitted (i.e., successfully received data packets) (such as SN=7 to 12 and 14 to 81 within the reception window), and the sequence numbers of RLC PDUs in a pending state (such as SN=6 and 13).

[0322] Figure 12 is a schematic diagram illustrating the principle of detecting an error of NACK turning into ACK according to an embodiment of the present application.

[0323] For example, as shown in Figure 12 , after receiving the correction status report, the transmitting end reads the lower edge RX_Next of the reception window, the sequence numbers of the RLC PDUs determined to be successfully transmitted, and the sequence numbers of the RLC PDUs in the pending state in the correction status report. The transmitting end updates the lower edge TX_Next_Ack of the transmission window to RX_Next (SN=6), so that the updated lower edge of the transmission window is the same as the lower edge of the reception window. In addition, the transmitting end deletes RLC PDUs with SN < TX_Next_Ack.

[0324] The transmitting end searches for RLC PDUs with the status flag S=1 in the buffer (the RLC PDU may be an RLC SDU or an RLC SDU segment), and if these RLC PDUs are in a pending state or a NACK state in the correction status report, the transmitting end retransmits these RLC PDUs. As shown in Figure 12The status flag S=1 of the RLC PDU with SN=6, and it is in an unresolved state in the correction status report, indicating that a NACK to ACK error has occurred. Therefore, the sender immediately retransmits the RLC PDU with SN=6.

[0325] The sending end looks up RLC PDUs with status flag S=1 in the buffer (the RLC PDU can be an RLC SDU or an RLC SDU segment). If they are in the ACK state in the correction status report, the sending end deletes these RLC PDUs from the buffer and reports to the upper layer that these RLC PDUs were successfully transmitted.

[0326] In summary, this embodiment achieves fast windowing based on ACK inter-layer reports through close interaction between the HARQ entity of the MAC layer and the ARQ entity of the RLC layer. Simultaneously, a correction status report is introduced with the trigger condition TX_VirNext_Ack > RX_Next, enabling timely correction in case of errors during fast windowing, thus achieving reliable fast windowing.

[0327] It should be understood that Figures 1 to 12 The flowcharts or scene diagrams shown are for illustrative purposes only and are not intended to limit the embodiments of this application to the examples illustrated. In fact, those skilled in the art can interpret the embodiments based on... Figures 1 to 12 The examples in the document can be transformed into equivalent ways to obtain more implementations.

[0328] The above text combined Figures 1 to 12 This document describes in detail the communication method provided in the embodiments of this application. The following will combine... Figures 13 to 14 The device embodiments of this application are described in detail below. It should be understood that the communication device of this application embodiment can execute the various communication methods of the foregoing embodiments of this application, that is, the specific working processes of the various products below can be referred to the corresponding processes in the foregoing method embodiments.

[0329] In the embodiments described above, the first device may execute some or all of the steps in each embodiment; the second device may execute some or all of the steps in each embodiment. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments, and it is not necessary to execute all the operations in the embodiments of this application. Moreover, the sequence number of each step does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0330] Figure 13 This is a schematic block diagram of a communication device provided in an embodiment of this application. Figure 13As shown, the communication device 1300 may include a communication module 1320. The communication module 1320 can implement corresponding communication functions, which can be internal communication functions of the communication device 1300 or communication functions between the communication device 1300 and other devices. Optionally, the communication module 1320 may also be referred to as a communication interface or transceiver module.

[0331] Optionally, the communication device 1300 further includes a processing module 1310. The processing module 1310 can perform corresponding processing functions.

[0332] Optionally, the communication device 1300 further includes a storage module, which can be used to store instructions and / or data; the processing module 1310 can read the instructions and / or data in the storage module so that the communication device 1300 can implement the aforementioned method embodiments.

[0333] In one possible design, the communication device 1300 may correspond to the first device in the above method embodiments, or to a component (such as a circuit, chip, or chip system) configured in the first device. The communication device 1300 may be used to perform the steps or processes performed by the first device in any of the above method embodiments.

[0334] For example, communication module 1320 is used to implement Figure 5 The processes S51 and S52 described in the text; or, used to implement Figure 6 The S68 process described in the text; or, used to implement Figure 7 The processes described in S71 and S714; or, used to implement Figure 8 The process of S812 is described in the text.

[0335] Processing module 1310 is used to implement Figure 5 The process described in the text is S53; or, used to implement... Figure 6 The processes S61 to S69 described herein; or, used to implement Figure 7 The process from S72 to S713 and from S715 to S721 is described in the text.

[0336] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0337] In one possible design, the communication device 1300 may correspond to the second device in the above method embodiments, or to a component (such as a circuit, chip, or chip system) configured in the second device. The communication device 1300 may be used to perform the steps or processes performed by the second device in any of the above method embodiments.

[0338] For example, communication module 1320 is used to implement Figure 5The processes S51 and S52 described in the text; or, used to implement Figure 6 The S68 process described in the text; or, used to implement Figure 7 The processes described in S71 and S714; or, used to implement Figure 8 The process of S812 is described in the text.

[0339] Processing module 1310 is used to implement Figure 8 The process from S81 to S811 is described in the text.

[0340] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0341] Figure 14 This is another schematic block diagram of the communication device 1400 provided in the embodiments of this application. The communication device 1400 may be a first device, a second device, or a chip, chip system, or processor that implements the above methods. The communication device 1400 can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0342] like Figure 14 As shown, the communication device 1400 may include one or more processors 1410, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 1410 may be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device 1400 (e.g., a base station, baseband chip, user, user chip), execute software programs, and process data from the software programs.

[0343] In an alternative design, the processor 1410 may also store instructions and / or data that can be executed by the processor 1410 to cause the communication device 1400 to perform the methods described in the above method embodiments.

[0344] In another alternative design, the communication device 1400 may include a communication interface 1420 for implementing receiving and transmitting functions. For example, the communication interface 1420 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0345] Optionally, the communication device 1400 may include one or more memories 1430, which may store instructions that can be executed on the processor 1410, causing the communication device 1400 to perform the methods described in the above method embodiments. Optionally, the memories 1430 may also store data. Optionally, the processor 1410 may also store instructions and / or data. The processor 1410 and the memories 1430 may be provided separately or integrated together.

[0346] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0347] In one implementation, the communication device 1400 may correspond to the first device in the above method embodiments and may be used to execute the various steps and / or processes executed by the first device in the above method embodiments. The processor 1410 may be used to execute instructions stored in the memory 1430, and when the processor 1410 executes the instructions stored in the memory, the processor 1410 is used to execute the various steps and / or processes of the above method embodiments corresponding to the first device.

[0348] In another implementation, the communication device 1400 may correspond to the second device in the above method embodiments and may be used to execute the various steps and / or processes executed by the second device in the above method embodiments. The processor 1410 may be used to execute instructions stored in the memory 1430, and when the processor 1410 executes the instructions stored in the memory, the processor 1410 is used to execute the various steps and / or processes of the above method embodiments corresponding to the second device.

[0349] It should be understood that the aforementioned processing device can be one or more chips. For example, the processing device can be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0350] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0351] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0352] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0353] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned first device and second device.

[0354] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the first device or the second device in any of the foregoing method embodiments.

[0355] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the first device or the second device in any of the foregoing method embodiments.

[0356] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0357] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0358] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0359] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0360] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0361] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method characterized by comprising: Applied to a first device, the method includes: Send indication information to the second device. The indication information is used to indicate the first lower edge of the transmission window. The first lower edge is the lower edge of the transmission window after the first status report is constructed based on the media access control (MAC) layer of the first device and updated. The first status report is used to notify the first device that the radio link control protocol data unit (RLC PDU) corresponding to the first transport block of the radio link control (RLC) layer has been successfully transmitted. Receive a second status report from the second device, the second status report including the lower edge of the receiving window of the second device, the second status report being sent by the second device when the first lower edge and the lower edge of the receiving window are different; The first lower edge of the sending window is updated to a second lower edge, which is the same as the lower edge of the receiving window.

2. The method of claim 1, wherein, The method further includes: If the first timer times out, the lower edge of the sending window is updated to the first lower edge; The first timer is started when the first device's Radio Link Control (RLC) layer receives the first status report and the first timer is not started.

3. The method of claim 2, wherein, The shutdown condition of the first timer includes at least one of the following: Received the second status report from the second device; A third status report is received from the second device. The third status report is a status report sent by the second device when the reassembly timer expires. The third status report includes the reception status of the expected Radio Link Control Protocol Data Unit (RLC PDU). The first timer timed out.

4. The method of claim 1, wherein, The method further includes: If the second timer times out and the second status report is not received, delete the first RLC PDU, where the sequence number of the first RLC PDU is less than the first lower edge of the sending window; The second timer is started when an instruction message is sent to the second device.

5. The method of claim 4, wherein, The shutdown condition for the second timer includes at least one of the following: Received the second status report from the second device; A third status report is received from the second device. The third status report is a status report sent by the second device when the reassembly timer expires. The third status report includes the reception status of the expected RLC PDU. The second timer timed out.

6. The method of claim 1, wherein, The first status report includes the serial number of at least one RLC PDU; When the sequence number of at least one RLC PDU includes a third lower edge and the Radio Link Control Service Data Unit (RLC SDU) corresponding to the third lower edge has been successfully transmitted, the first lower edge is the sequence number corresponding to the first RLC SDU that was not fully transmitted after the third lower edge, and the third lower edge is the lower edge of the transmission window before the update.

7. The method of claim 1, wherein, The method further includes: Delete the second RLC PDU, whose sequence number is less than the second lower edge of the transmission window.

8. The method of claim 1, wherein, The indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the first lower edge.

9. The method of claim 8, wherein, The method further includes: Upon receiving the first status report at the RLC layer of the first device, the lower edge of the transmission window is updated to the first lower edge, and the third RLC PDU is retransmitted.

10. The method of claim 1, wherein, The first status report includes the serial number of at least one RLC PDU; the method further includes: Set the status flag of the RLC PDU corresponding to the sequence number to a first value, which indicates that the RLCPDU transmission was successful.

11. The method of claim 10, wherein, The second status report also includes: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status. The first status is used to indicate that the RLC PDU is in a state where transmission is confirmed to be successful, and the second status is used to indicate that the RLC PDU is in a state where transmission is not confirmed to be successful by the second device. The method further includes: If the status flag of the RLC PDU is the first value and the serial number of the RLC PDU corresponds to the first status, then delete the RLC PDU. If the status flag of the RLC PDU is the first value and the sequence number of the RLC PDU corresponds to the second status, the RLC PDU is retransmitted.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: The MAC layer of the first device receives feedback information from the second device, which is used to indicate whether the Media Access Control Sub-Protocol Data Unit (MAC subPDU) in the first transport block has been successfully transmitted. The MAC layer of the first device constructs the first status report based on the feedback information, the logical channel number in the MAC subheader of the MAC subPDU, and the sequence number of the RLC PDU in the MAC subheader.

13. The method according to any one of claims 1 to 11, characterized in that, The receiving of the second status report from the second device includes: If the first lower edge is greater than the lower edge of the receiving window, a second status report is received from the second device.

14. A communication method, comprising: Applied to a second device, the method includes: Receive indication information from the first device, the indication information is used to indicate the first lower edge of the transmission window, the first lower edge is the lower edge after the lower edge of the transmission window is updated based on the first status report constructed by the MAC layer of the first device, the first status report is used to notify the first device that the Radio Link Control Protocol Data Unit (RLC PDU) corresponding to the first transport block of the Radio Link Control (RLC) layer has been successfully transmitted. If the first lower edge and the lower edge of the receiving window of the second device are different, a second status report is sent to the first device so that the first device updates the first lower edge of the sending window to the second lower edge. The second status report includes the lower edge of the receiving window of the second device, and the second lower edge is the same as the lower edge of the receiving window.

15. The method of claim 14, wherein, When the lower edges of the first lower edge and the receiving window of the second device are different, sending a second status report to the first device includes: If the first lower edge is greater than the lower edge of the receiving window, a second status report is sent to the first device.

16. The method according to claim 14 or 15, characterized in that The indication information is carried in the header of the retransmitted third RLC PDU, and the sequence number of the third RLC PDU is the first lower edge.

17. The method of claim 14 or 15, wherein, The second status report also includes: the sequence number of the RLC PDU corresponding to the first status and the sequence number of the RLC PDU corresponding to the second status. The first status is used to indicate that the RLC PDU is in a state where transmission is confirmed to be successful, and the second status is used to indicate that the RLC PDU is in a state where transmission is not confirmed to be successful by the second device.

18. A communications device, characterized by The device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the device to perform the method as described in any one of claims 1 to 17.

19. A computer readable storage medium having stored thereon a computer program or instructions, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 17.

20. A communication system, characterized by Includes the communication device as described in claim 18.

21. A chip system, characterized by The chip system includes one or more processors, which are configured to retrieve and execute instructions stored in memory, such that the method as described in any one of claims 1 to 17 is performed.

Images