Data transmission method and product

Abstract

The application provides a data transmission method and product, and belongs to the technical field of communication. The method comprises the following steps: associating the parity of a serial number with the transmission mode of a data packet, and increasing the serial number of the data packet in the acknowledgement mode by a step of 2, so that the data packet in the acknowledgement mode and the data packet in the non-acknowledgement mode respectively occupy mutually non-overlapping parity subsets in the serial number space, thereby avoiding the collision of the serial numbers of the data packets in the two modes and ensuring the clear division of the serial number space. Since the data packet in the acknowledgement mode remains continuous in the parity subset to which it belongs, the receiving end device can determine whether there is a serial number gap in the subset to perform packet loss detection on the data packet in the acknowledgement mode. Thus, the receiving end device can accurately identify the lost data packet that needs to initiate an automatic repeat request, while ignoring the data packet in the non-acknowledgement mode that does not need to be retransmitted, so that a single data radio bearer can simultaneously support the acknowledgement mode and the non-acknowledgement mode.

Description

Technical Field

[0001] This application belongs to the field of communication technology, specifically relating to a data transmission method and product. Background Technology

[0002] In the field of communication technology, when sending data packets, the sending device can adopt transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). Transparent mode refers to transparent transmission of data packets. Unacknowledged mode means that the sending device adapts the data packets before sending them; the receiving device is responsible for detecting data loss and reassembling the data packets, but does not request retransmission. Acknowledged mode adds an automatic retransmission request mechanism to the unacknowledged mode. That is, when sending a data packet, the sending device caches a copy of the data packet in a retransmission buffer, and decides whether to discard the cached copy or retransmit the data based on the information from the receiving device.

[0003] In existing network configurations, a data radio bearer (DRB) is typically configured to use a fixed transmission mode; that is, a single DRB cannot simultaneously support acknowledged and unacknowledged modes. With the emergence of new services such as extended reality (XR) and artificial intelligence (AI), the aforementioned transmission mechanism based on a fixed DRB transmission mode is no longer suitable for supporting these new service flows. However, currently, there is no transmission mechanism where a single DRB simultaneously supports both AM and UM modes. Summary of the Invention

[0004] This application provides a data transmission method and product that enables a single DRB to simultaneously support acknowledged and unacknowledged modes.

[0005] Firstly, a data transmission method is provided. This method can be executed by a first device, by a component configured in the first device (such as a circuit, processor, chip, or chip system), 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 the scope of this method. The following description uses the first device as an example.

[0006] The method includes: obtaining a first sequence number corresponding to the first data packet based on the transmission mode of the first data packet, wherein the transmission mode is an acknowledged mode or an unacknowledged mode, and the first sequence number is used to identify the first data packet; in the acknowledged mode, after the first device sends the data packet, it buffers the data packet and determines whether to retransmit the data packet based on information fed back by the second device indicating a lost data packet; in the unacknowledged mode, after the first device sends the data packet, it does not retransmit the lost data packet; if the first sequence number is within the sending window, a second data packet is sent based on the first data packet and the first sequence number, wherein the second data packet carries the first sequence number; wherein, when the first data packet corresponds to the acknowledged mode, the first sequence number is even, and when the first data packet corresponds to the unacknowledged mode, the first sequence number is odd; or, when the first data packet corresponds to the acknowledged mode, the first sequence number is odd, and when the first data packet corresponds to the unacknowledged mode, the first sequence number is even; when the first data packet corresponds to the acknowledged mode and the first data packet is not the first data packet in the acknowledged mode, the difference between the first sequence number and the sequence number corresponding to the data packet transmitted in the previous acknowledged mode is 2.

[0007] By associating the parity of sequence numbers with the transmission mode of data packets, and incrementing the sequence numbers of packets in acknowledgment mode by a step of 2, packets in acknowledgment mode and packets in unacknowledgment mode each occupy non-overlapping parity subsets in the sequence number space. This fundamentally avoids sequence number conflicts between the two modes, ensuring a clear division of the sequence number space. Furthermore, since packets in acknowledgment mode remain continuous within their respective parity subsets, the receiving device can determine whether there are sequence number gaps within that subset. This allows for independent and accurate packet loss detection for packets in acknowledgment mode, unaffected by packet loss or out-of-order delivery in unacknowledgment mode. Consequently, the receiving device can accurately identify lost packets requiring automatic retransmission requests while ignoring packets in unacknowledgment mode that do not require retransmission. This enables differentiated processing of packets from both transmission modes in mixed transmission scenarios on the same DRB, allowing a single DRB to support both acknowledgment and unacknowledgment modes simultaneously. Moreover, through this method, the receiving device can directly determine the transmission mode corresponding to a data packet based on the parity of the sequence number without any additional indication information, thereby reducing protocol header overhead and communication resources.

[0008] In one possible implementation, the aforementioned transmission mode is an acknowledgment mode. Obtaining the first sequence number corresponding to the first data packet based on the transmission mode corresponding to the first data packet includes: obtaining a first parameter under the acknowledgment mode based on the transmission mode corresponding to the first data packet, and obtaining the first sequence number based on the first parameter; wherein the first parameter is a count value of the next data packet to be associated in the acknowledgment mode. By obtaining the first sequence number using the state variable (first parameter) under the acknowledgment mode, the generation logic of the data packet sequence number in the acknowledgment mode can be completely isolated from the generation logic of the data packet sequence number in the non-acknowledgment mode. This ensures that data transmission events in the non-acknowledgment mode do not affect the generation of the data packet sequence number in the acknowledgment mode, thereby guaranteeing the reliability of the data packet sequence number in the acknowledgment mode.

[0009] In one possible implementation, the expression for obtaining the first sequence number based on the first parameter is: SN_AM = TX_Next_AM mod 2 [sn-FieldLength -1] Wherein, SN_AM is the first sequence number, TX_Next_AM is the first parameter, and sn-FieldLength is the preset sequence number length. This ensures that when the value of the first parameter exceeds the maximum value that the sequence number field can represent, the sequence number can automatically wrap around, thus conforming to the common practice in communication protocols where sequence number space is limited and cyclically used, and ensuring that the length of the generated sequence number always conforms to the preset sequence number length.

[0010] In one possible implementation, after obtaining the first sequence number based on the first parameter, the method described in the first aspect further includes: updating the first parameter, wherein the updated first parameter is the sum of the aforementioned first parameter and 2. This ensures that the difference between the sequence numbers corresponding to two adjacent data packets in acknowledgment mode is 2, thus ensuring that the sequence numbers in acknowledgment mode are consecutive.

[0011] In one possible implementation, the aforementioned transmission mode is a non-acknowledgment mode. The acquisition of the first sequence number corresponding to the first data packet, based on the transmission mode corresponding to the first data packet, includes: acquiring a second parameter under the non-acknowledgment mode, where the second parameter is the count value of the next data packet to be associated in the non-acknowledgment mode; updating the second parameter if the second parameter is less than the first window count value, wherein the updated second parameter is located within the counting interval corresponding to the sending window, the first window count value is the count value corresponding to the lower edge value of the first window, and the lower edge value of the first window is the value of the lower edge of the sending window; and acquiring the first sequence number based on the updated second parameter. In this way, when data packet transmission in the non-acknowledgment mode is infrequent, the sequence number of the data packet in the non-acknowledgment mode is always within the sending window, thus avoiding the situation where the sequence number assigned to the data packet in the non-acknowledgment mode falls outside the sending window and cannot be sent, thereby ensuring the reliability of data packet transmission in the non-acknowledgment mode. Simultaneously, this method allows the sequence number in the non-acknowledgment mode to advance in leaps as the sending window progresses, avoiding the problem of the sequence number in the non-acknowledgment mode permanently lagging behind the lower edge of the sending window and thus being unable to send data packets.

[0012] In one possible implementation, the updated second parameter is the sum of the first window count and 1. This allows the second parameter to be set to the count value corresponding to the first available sequence number within the sending window that has a different parity than the sequence number in the acknowledgment mode. This ensures that the first data packet obtains sending eligibility as quickly as possible, provided it meets the sending window requirements, reducing the latency introduced by waiting for the sequence number to gradually increase into the sending window. Simultaneously, when subsequent data packets in the unacknowledgment mode exist, the latest second parameter can be used directly without waiting for the count value to increase again, further reducing latency.

[0013] In one possible implementation, the expression for obtaining the first sequence number based on the updated second parameter is: SN_UM = TX_Next_UM mod 2 [sn-FieldLength -1] Wherein, SN_UM is the first sequence number, TX_Next_UM is the updated second parameter, and sn-FieldLength is the preset sequence number length. This ensures that when the value of the second parameter exceeds the maximum value that the sequence number field can represent, the sequence number can automatically wrap around, thus conforming to the common practice in communication protocols where sequence number space is limited and cyclically used, and ensuring that the length of the generated sequence number always conforms to the preset sequence number length.

[0014] In one possible implementation, after obtaining the first sequence number based on the updated second parameter, the method described in the first aspect further includes: updating the updated second parameter again, wherein the updated second parameter is the sum of the updated second parameter and 2. This ensures that the sequence number of data packets in non-acknowledgment mode remains within the same parity subset during the normal transmission of the data packet, and does not fall into the sequence number space of acknowledgment mode due to the increment of the second parameter, thus ensuring the stability of the mechanism for distinguishing different modes based on the parity of the sequence number.

[0015] In one possible implementation, the method of the first aspect further includes: if the second parameter is greater than or equal to the first window count value, obtaining a first sequence number based on the second parameter. This ensures that the first sequence number obtained based on the second parameter meets the lower edge requirement of the sending window, and eliminates the need to wait for the count value (second parameter) to gradually increase from below the lower edge of the window to within the window, thereby reducing the latency introduced by the count value catching up with the lower edge of the window.

[0016] In one possible implementation, the method of the first aspect further includes: receiving a status report from the second device, and updating the lower edge value of the first window according to the minimum sequence number in the acknowledgment mode that was not successfully transmitted in the status report; wherein the status report is used to indicate data packets in the acknowledgment mode that the second device has not received, and data packets in the acknowledgment mode that the second device has received; the lower edge value of the first window is the value of the lower edge of the sending window; and the updated lower edge value of the first window is the minimum sequence number. In this way, based on the actual reception status reported by the second device, the lower edge of the sending window can be adjusted to the position of the earliest unsuccessfully transmitted sequence number, ensuring that all lost acknowledgment mode data packets can regain the right to be transmitted, avoiding the omission of retransmitted data packets due to the lower edge of the sending window advancing too quickly, thereby ensuring the integrity and reliability of data retransmission in the acknowledgment mode.

[0017] Secondly, a data transmission method is provided. This method can be executed by a second device, by a component configured in the second device (such as a circuit, processor, 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 the scope of this method. The following description uses a second device as an example.

[0018] The method includes: when the sequence number of the data packet in acknowledgment mode is even and the sequence number of the data packet in non-acknowledgment mode is odd, sending a status report when there is a gap in the received even-numbered sequence number; or, when the sequence number of the data packet in acknowledgment mode is odd and the sequence number of the data packet in non-acknowledgment mode is even, sending a status report when there is a gap in the received odd-numbered sequence number; wherein the status report is used to indicate the data packets in acknowledgment mode that have not been received, and the data packets in acknowledgment mode that have been received.

[0019] When data packets in acknowledgment mode use even or odd sequence numbers, by determining whether there are gaps in the received even or odd sequence numbers, and sending a status report when a gap exists, it is possible to identify the loss of acknowledgment mode data packets in mixed data packet transmission scenarios and send status reports in a timely manner. Simultaneously, the status report is used to indicate unreceived and received acknowledgment mode data packets, enabling the sending device to accurately know the receiving device's reception status, thereby allowing for targeted retransmission and improving the reliability of data transmission.

[0020] In one possible implementation, sending a status report when there is a gap in the received even-numbered sequence number includes: sending a status report when there is a gap in the received even-numbered sequence number and the reassembly timer expires, wherein the reassembly timer starts counting when it is determined that there is a gap in the received even-numbered sequence number. This allows time for reassembling data packets arriving out of order due to transmission delay differences, effectively avoiding unnecessary retransmissions triggered by sending status reports too early, reducing waste of communication resources, and improving the efficiency and reliability of data transmission.

[0021] In one possible implementation, the method described in the second aspect further includes: determining that there is a gap in the received even-numbered sequence numbers based on the fact that a first variable is greater than the sum of a second variable and 2; wherein the first variable is used to indicate the upper bound of the sequence number of the data packets in the received acknowledgment mode, and the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window. The fact that the first variable is greater than the sum of the second variable and 2 indicates that there is at least one missing even-numbered sequence number between the second variable and the currently received maximum sequence number. Through the above comparison and judgment method based on the first and second variables, the second device does not need to sort and traverse all received sequence numbers; it only needs to maintain two variables and perform a single numerical comparison to quickly determine whether there is a gap in the received even-numbered sequence numbers. This reduces computational complexity and the computational power consumption of the second device.

[0022] In one possible implementation, sending a status report when there is a gap in the received odd-numbered sequence number includes: sending a status report when there is a gap in the received odd-numbered sequence number and the reassembly timer expires, wherein the reassembly timer starts counting when it is determined that there is a gap in the received odd-numbered sequence number. This allows time for reassembling data packets arriving out of order due to transmission delay differences, effectively avoiding unnecessary retransmissions triggered by sending status reports too early, reducing communication resource waste, and improving data transmission efficiency and reliability.

[0023] In one possible implementation, the method in the second aspect further includes: determining that there is a gap in the received odd-numbered sequence numbers based on the fact that a first variable is greater than the sum of a second variable and 2; wherein the first variable is used to indicate the upper bound of the data packet sequence numbers in the received acknowledgment mode, and the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window. The fact that the first variable is greater than the sum of the second variable and 2 indicates that there is at least one missing odd-numbered sequence number between the second variable and the currently received maximum sequence number. Through the above comparison and judgment method based on the first and second variables, the second device does not need to sort and traverse all received sequence numbers; it only needs to maintain two variables and perform a single numerical comparison to quickly determine whether there is a gap in the received even-numbered sequence numbers. This reduces computational complexity and the computational power consumption of the second device.

[0024] In one possible implementation, the method described in the second aspect further includes: when the reassembly timer times out, if a restart condition is met, then restarting the reassembly timer; wherein the restart condition includes at least one of the following: a first variable is greater than the sum of a third variable and 2, the first variable is equal to the sum of a third variable and 2, and the data packet corresponding to the third variable has not been fully received; the first variable is used to indicate the upper bound of the sequence number of the data packet in the received acknowledgment mode, the third variable is the sequence number of the first data packet in the acknowledgment mode whose sequence number is greater than or equal to the fourth variable and has not been fully received when the status report is triggered, and the fourth variable is the first variable when the reassembly timer is started. This ensures that in scenarios where multiple consecutive acknowledgment mode data packets are lost, subsequent packet loss is continuously monitored and reported, preventing the omission of subsequent packet loss events due to ending monitoring with only one status report.

[0025] In one possible implementation, the method described in the second aspect may further include: starting a reassembly timer when the first variable equals the sum of the second variable and 2, and the data packet corresponding to the second variable has not been fully received. In this way, the reassembly timer can be started promptly when the maximum received sequence number has not exceeded the expected reception position, but the expected data packet has not been fully received, reserving waiting time for receiving the data packet, thereby ensuring the reliability of data transmission.

[0026] In one possible implementation, the method in the second aspect further includes: when the reassembly timer is enabled, pausing the reassembly timer and performing a reset operation on the reassembly timer when a stop condition is met; wherein the stop condition includes at least one of the following: the second variable is equal to the fourth variable, the fourth variable is outside the receiving window, the fourth variable is equal to the sum of the second variable and 2, and the data packet corresponding to the second variable has been completely received; the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window, and the fourth variable is the first variable when the reassembly timer is enabled. In this way, the reassembly timer can be stopped in a timely manner, thereby releasing timer resources promptly and avoiding continuous device overhead caused by the reassembly timer waiting in vain.

[0027] Thirdly, a data transmission apparatus is provided. This data transmission apparatus includes: a module for performing the method in any possible implementation of any of the above aspects, such as a communication module and a processing module. For example, the communication module is used to instruct the transmission and reception functions of the data transmission apparatus; the processing module is used to perform functions of the data transmission apparatus other than the transmission and reception functions.

[0028] Optionally, the communication module may include a transmitting module and a receiving module. The transmitting module implements the transmitting function of the data transmission device described in the third aspect, and the receiving module implements the receiving function of the data transmission device described in the third aspect.

[0029] Optionally, the data transmission apparatus described in the third aspect may further include a storage module storing programs or instructions. When the processing module executes the program or instructions, the data transmission apparatus can perform the methods in any of the possible implementations of any of the above aspects.

[0030] It is understood that the data transmission device described in the third aspect may be a terminal device or a network device, or it may be a chip (system) or other component or assembly that can be disposed in the terminal device or the network device, or it may be a device that includes the terminal device or the network device. This application does not limit it in this regard.

[0031] Furthermore, the technical effects of the data transmission device described in the third aspect can be referenced from the technical effects of the methods in any possible implementation of any of the above aspects, and will not be elaborated here.

[0032] Fourthly, a data transmission apparatus is provided, including at least one processor. The at least one processor is coupled to a memory storing programs or instructions. The processor executes the programs or instructions in the memory, causing the data transmission apparatus to perform a method in any possible implementation of any of the above aspects. Optionally, the data transmission apparatus further includes a memory. Optionally, the data transmission apparatus further includes a communication interface, and the processor is coupled to the communication interface.

[0033] In one implementation, the communication interface may be a transceiver, or an input / output interface.

[0034] In another implementation, the data transmission device is a chip configured in a terminal device or network device. When the data transmission device is a chip configured in a terminal device or network device, the communication interface can be an input / output interface.

[0035] Fifthly, 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.

[0036] 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 output to, for example, but not limited to, a transmitter and transmitted by the transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0037] In a sixth aspect, a data transmission apparatus is provided, including a processor and a memory. The processor is used to read instructions stored in the memory and to receive signals via a receiver and transmit signals via a transmitter to execute the method in any possible implementation of any of the above aspects.

[0038] Optionally, the processor may be one or more, and the memory may be one or more.

[0039] In a seventh aspect, 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 any possible implementations of the above aspects to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

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

[0041] Eighthly, 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 methods in any possible implementation of any of the preceding aspects.

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

[0043] In a tenth aspect, a communication system is provided, including the aforementioned first device and second device. Optionally, the communication system may further include other devices that communicate with the first device and / or the second device. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings.

[0045] Figure 1 A schematic diagram of the communication system provided in the embodiments of this application; Figure 2 A schematic diagram illustrating the data transmission at each layer of the protocol stack provided in the embodiments of this application; Figure 3 A flowchart illustrating the data transmission method provided in the embodiments of this application. Figure 1 ; Figure 4 A flowchart illustrating the data transmission method provided in the embodiments of this application. Figure 2 ; Figure 5 A flowchart illustrating the operation method of a Radio Link Control (RLC) entity receiving an RLC Protocol Data Unit (PDU) as provided in an embodiment of this application; Figure 6 A flowchart illustrating the operation method of an RLC entity when assembling an RLC Service Data Unit (SDU) according to an embodiment of this application; Figure 7 A flowchart illustrating the operation method of an RLC entity when the reorganization timer is not running, as provided in the embodiments of this application; Figure 8 A flowchart illustrating the operation method of an RLC entity during the operation of a recombination timer, as provided in this application embodiment; Figure 9A flowchart illustrating the operation method of an RLC entity when the recombination timer times out, as provided in an embodiment of this application; Figure 10 A schematic diagram of a data transmission device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of the data transmission device provided in the embodiments of this application. Detailed Implementation

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

[0047] 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). Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networking. The technical solutions provided in this application can also be applied to future communication systems. This application does not limit the scope of these applications.

[0048] Figure 1 This is a schematic diagram of a communication system applied in an embodiment of this application. The communication system may include a first device, such as... Figure 1 The first device 110 is shown. The communication system 100 may also include a second device, such as... Figure 1 The second device 120 shown.

[0049] The first device 110 is a transmitting device, and the second device 120 is a receiving device. The first device 110 and the second device 120 can communicate via a wireless link. In this embodiment, the first device 110 can be a terminal device, and the second device 120 can be a network device; or, the first device 110 can be a network device, and the second device 120 can be a terminal device.

[0050] Figure 1 An exemplary first device 110 and a second device 120 are shown. Optionally, the communication system 100 may also include multiple first devices and / or multiple second devices.

[0051] The aforementioned network equipment can be network-side equipment such as access network equipment and core network equipment. Access network equipment is sometimes also called access node. Access network equipment has wireless transceiver capabilities and is used to communicate 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, or indoor stations, relay nodes or donor nodes, or wireless controllers in cloud radio access 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.

[0052] The aforementioned terminal equipment can be a wireless terminal device capable of receiving network device scheduling and instruction information. A 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). Terminal devices can also be called terminals, user equipment (UE), mobile stations, mobile terminals, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ultra-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. The terminal can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, wearable device, vehicle, aircraft (such as drone, helicopter, airplane), hot air balloon, ship, robot, robotic arm, or smart home device, etc. The embodiments of this application do not limit the form of the terminal device.

[0053] In practical applications, multiple network devices can collaborate to assist terminals in achieving wireless access, with different network devices each implementing a portion of the base station's functions. For example, network devices can be central units (CUs), distributed units (DUs), CUs (control planes, CPs), CUs (user planes, UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0054] 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.

[0055] To facilitate understanding of the embodiments of this application, the terminology used in this application is first briefly explained. Optionally, the explanation of some terms can also refer to the explanations in the 3rd Generation Partnership Project (3GPP) standard protocol. It should be understood that the technical terms in this application are only examples and not limitations. For example, as technology evolves, technical terms may also change; where the technical meaning remains the same, other technical terms should also apply to this application.

[0056] 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 protocol layers such as Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). The user plane protocol layer structure, from top to bottom, can include the functions of protocol layers such as PDCP, RLC, MAC, and Physical. The Physical layer is located at the lowest layer (Layer 1), the MAC, RLC, and PDCP belong to the second layer (Layer 2), and RRC belongs to the third layer (Layer 3). In one possible implementation, a Service Data Adaptation Protocol (SDAP) layer may also be included above the PDCP layer.

[0057] The functions of these protocol layers can be implemented by a single node or by multiple nodes. For example, in one evolutionary architecture, access network equipment may include CUs and DUs, and multiple DUs can be centrally controlled by a single CU. CUs and DUs can be distinguished according to the protocol layers of the wireless network. For example, the functions of PDCP and higher protocol layers are located in the CU, while the functions of lower protocol layers, RLC layers, and MAC layers are located in the DU.

[0058] It should be understood that the above-described protocol layer division is merely an example, and it can be applied to other protocol layers as well. For instance, at the RLC layer, the functions of the RLC layer and above could be placed in the CU, while the functions of the protocol layers below the RLC layer could be placed in the DU. Alternatively, within a specific protocol layer, some functions of the RLC layer and those of the protocol layers above the RLC layer could be placed in the CU, while the remaining functions of the RLC layer and those of the protocol layers below the RLC layer could be placed 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.

[0059] like Figure 2 As shown, when the first device (transmitting device) and the second device (receiving device) transmit data, the data first reaches the PDCP layer of the first device. After processing by the PDCP layer, it is transmitted to the RLC layer and MAC layer. After processing at the MAC layer, it is sent to the second device through the physical layer. When the second device receives data, the protocol layers it passes through in sequence are the physical layer, MAC layer, RLC layer, and PDCP layer. Data in each radio bearer needs to be processed by each layer. Each layer has corresponding functional entities to perform its respective function. 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, etc. Each radio bearer contains one PDCP entity and one or more RLC entities, and each RLC entity corresponds to one logical channel. One MAC entity corresponds to multiple logical channels. Data in logical channels can be multiplexed at the MAC layer, such as multiplexing into the same data block, and finally sent out through the physical layer.

[0060] 2. Data packet A data packet refers to a data unit transmitted in the user plane (such as the 5G user plane), i.e., a user plane data packet. This data packet can be used to carry service data, such as web browsing data, video streaming data, file transfer data, and voice data. The data packet typically includes a payload and a header. The payload carries the data to be transmitted, and the header contains control information for processing the data packet.

[0061] Data packets are processed differently at different protocol layers. For example, on the sending side, the data packet first arrives at the SDAP layer. The SDAP layer, based on the Quality of Service (QoS) flow mapping rules to data DRBs, 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 PDU and delivers it to the PHY layer.

[0062] In this process, 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.

[0063] In the PDCP layer, the SDAP PDU is referred to as a PDCP SDU. After the PDCP layer performs related 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 a PDCP PDU.

[0064] 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 can be called an RLC SDU segment. After processing the RLC SDU segments or RLC SDUs by adding headers and other related steps to obtain the RLC PDU, the RLC PDU is delivered to the MAC layer. That is, the data packets delivered by the RLC layer to the MAC layer are RLC PDUs.

[0065] In the MAC layer, the RLC PDU is referred to as a MAC SDU. The MAC layer performs various processing on the MAC SDU, such as adding a MAC header, to obtain a MAC subPDU. One or more MAC subPDUs are then combined to form a MAC PDU, which is then delivered to the PHY layer. In other words, the data packets delivered by the MAC layer to the PHY layer are MAC PDUs.

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

[0067] As can be understood, the above content describes the data packet processing procedure on the sending side. On the receiving side, each protocol layer performs the opposite decapsulation and reassembly process to restore the original data packet.

[0068] 3. Transmission Mode The transmission mode indicates how data packets are transmitted. This transmission mode can be either acknowledged or unacknowledged. Both acknowledged and unacknowledged modes are used to transmit user data.

[0069] In acknowledgment mode, after sending a data packet, the sending device (such as the first device) buffers the packet and determines whether to retransmit it based on information (such as a status report) from the receiving device (such as the second device) indicating a lost data packet. The lost data packet can be understood as a packet sent by the sending device but not received by the receiving device (within a certain time period). Acknowledgment mode is typically used for traffic that requires retransmission to achieve high reliability.

[0070] In unacknowledged mode, the sending device (such as the first device) does not retransmit lost data packets after sending them. Unacknowledged mode is typically used for traffic that requires low latency and does not require retransmission.

[0071] The RLC layer supports the above transmission modes. For example, in acknowledged mode, the RLC entity introduces positive acknowledgment (ACK) and negative acknowledgment (NACK) mechanisms, requiring the receiving device to acknowledge (ACK) or deny (NACK) the received data. The sending device can retransmit unacknowledged data packets based on the ACK / NACK information received from the receiving device. As another example, in unacknowledged mode, the RLC entity adds control protocol overhead (such as sequence numbers) to the higher-layer PDU, generates an RLC PDU, and transmits it; since no retransmission protocol is used, the sending device does not wait for acknowledgment messages from the receiving device.

[0072] 4. Unified Model The unified mode can be understood as a hybrid transmission mode that combines data packets in both acknowledged and unacknowledged modes. In 5G NR, the unified mode can be understood as a single DRB being configured to operate in a mode that simultaneously supports both acknowledged and unacknowledged modes. For example, in this unified mode, the receiving device (such as the receiving device's RLC entity) can determine whether to process the data packet in acknowledged or unacknowledged mode based on the parity of the sequence number (SN) corresponding to the data packet. For instance, when the sequence number of the data packet is odd, the receiving device processes the data packet in acknowledged mode; when the sequence number of the data packet is even, the receiving device processes the data packet in unacknowledged mode. Alternatively, the processing modes corresponding to the parity of the sequence number can be interchanged, and this application does not limit this. Through the aforementioned unified mode, a single DRB can simultaneously carry data packets in both acknowledged and unacknowledged modes.

[0073] In existing network configurations, a single DRB cannot simultaneously support both acknowledged and unacknowledged modes. For example, when a DRB is established, its corresponding transport mode (i.e., acknowledged or unacknowledged mode) is determined based on the QoS requirements of the service flow. This transport mode remains unchanged throughout the DRB's entire lifecycle. The only way to change the transport mode of a service flow is to release the DRB and re-add it. In other words, once a DRB is established, all data packets belonging to that DRB will be transmitted using the same transport mode (i.e., acknowledged or unacknowledged mode).

[0074] With the emergence of new services such as XR and AI, the aforementioned fixed transmission mode (i.e., a single DRB is configured to always use one transmission mode) is no longer adequate. Research has found that AI and XR-type service flows exhibit hybrid characteristics within the same service flow, meaning that different data packets have varying requirements for transmission reliability and latency. For example, in XR services, I-frames require high reliability, while P / B frames have lower requirements; in AI services, inference data requires low latency, while training data can tolerate higher latency. In this context, existing transmission mechanisms are inefficient for transmitting these hybrid data packets.

[0075] For emerging services such as XR and AI, a transmission mechanism is needed that allows a single DRB to support both acknowledged and unacknowledged modes simultaneously, in order to address the inefficiency of current mechanisms in transmitting mixed data packets. However, currently, there is no transmission mechanism that allows a single DRB to simultaneously support both acknowledged and unacknowledged modes; that is, a unified transmission mechanism under these conditions is currently lacking.

[0076] In view of this, embodiments of this application propose associating the parity of the sequence number with the transmission mode of the data packet (acknowledgment mode and unacknowledgment mode). For example, data packets in acknowledgment mode use even sequence numbers, while data packets in unacknowledgment mode use odd sequence numbers; or, data packets in acknowledgment mode use odd sequence numbers, while data packets in unacknowledgment mode use even sequence numbers. The sequence number of the acknowledgment mode data packet is incremented by a step of 2. This ensures that data packets in acknowledgment mode and data packets in unacknowledgment mode occupy non-overlapping parity subsets in the sequence number space, fundamentally avoiding sequence number conflicts between the two modes and guaranteeing a clear division of the sequence number space.

[0077] Building upon this, since data packets in acknowledgment mode remain continuous within their respective odd / even subsets (i.e., the odd sequence number subset or the even sequence number subset), the receiving device can determine whether there are sequence number gaps within these subsets. This allows for independent and accurate packet loss detection for data packets in acknowledgment mode, unaffected by packet loss or out-of-order delivery in unacknowledgment mode. Consequently, the receiving device can accurately identify lost data packets requiring automatic retransmission requests, while ignoring unacknowledgment mode data packets that do not require retransmission. This enables differentiated processing of data packets from both transmission modes on the same DRB in mixed transmission scenarios, allowing a single DRB to simultaneously support both acknowledgment and unacknowledgment modes.

[0078] 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 mainly use different devices (such as the first device and the second device) as examples to illustrate the method, but this application does not limit the illustrative execution entities. For example, the devices (such as the first device and the second device) in the illustrative flowcharts can also be chips, chip systems, or processors that support the implementation of the method on those devices, or they can be logic modules or software that can implement all or part of the functions of the device.

[0079] As a general statement, the message or signaling interactions involved in the process provided in 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.

[0080] To facilitate understanding, let's first combine... Figure 3 This section describes the method and process of data transmission by the sending device (i.e., the first device).

[0081] Figure 3 This is a schematic diagram of the data transmission method according to an embodiment of this application. Figure 1 That's understandable. Figure 3 The first device in the process can be Figure 1The first device in the context can also refer to a component within the first device (such as a circuit, processor, chip, or chip system), or it can be implemented by a logic module or software capable of performing all or part of the functions of the first device. The following description uses the first device as an example.

[0082] like Figure 3 As shown, the above data transmission method includes the following steps: S301, the first device obtains the first sequence number corresponding to the first data packet based on the transmission mode of the first data packet.

[0083] The first data packet can be understood as a data unit transmitted in the user plane. For details, please refer to the relevant introduction in "2. Data Packets" above. It will not be repeated here.

[0084] The transmission mode of the first data packet is either acknowledged or unacknowledged. In acknowledged mode, after sending the data packet, the first device buffers the data packet and determines whether to retransmit it based on the information from the second device indicating a lost data packet. In unacknowledged mode, the first device does not retransmit lost data packets after sending them. The transmission mode of the first data packet can be determined by network-side devices (such as core network devices and access network devices) according to the QoS parameters required by the service; specific details can be found in existing technologies and will not be elaborated here.

[0085] The first sequence number can be used to identify the first data packet. The first sequence number uses different parity sequence numbers depending on the transmission mode of the first data packet. For example, when the first data packet corresponds to an acknowledgment mode, the first sequence number is even; when the first data packet corresponds to an unacknowledgment mode, the first sequence number is odd. Alternatively, when the first data packet corresponds to an acknowledgment mode, the first sequence number is odd, and when the first data packet corresponds to an unacknowledgment mode, the first sequence number is even. In the embodiments of this application, data packets in acknowledgment mode and data packets in unacknowledgment mode occupy odd and even sequence numbers respectively, or data packets in acknowledgment mode and data packets in unacknowledgment mode occupy even and odd sequence numbers respectively, thus ensuring that data packets in acknowledgment mode and data packets in unacknowledgment mode do not interfere with each other.

[0086] When the first data packet corresponds to an acknowledgment mode, and the first data packet is not the first data packet in the acknowledgment mode, the difference between the first sequence number and the second sequence number is 2. This difference refers to the value obtained by subtracting the second sequence number from the first sequence number; that is, the value obtained by subtracting the second sequence number from the first sequence number is 2. The first data packet in this acknowledgment mode can be understood as the first acknowledgment mode data packet transmitted on the DRB in unified mode. The second sequence number is the sequence number corresponding to the data packet transmitted in the previous acknowledgment mode. The data packet transmitted in the previous acknowledgment mode can be understood as the acknowledgment mode data packet that immediately precedes the first data packet in sequence number order when the first data packet corresponds to the acknowledgment mode.

[0087] For example, in acknowledgment mode, the sequence number of the data packet is even, and the sequence number of the first data packet in acknowledgment mode is 0; the first data packet is the 4th data packet in acknowledgment mode, that is, the first sequence number corresponding to the first data packet is 6, and the data packet transmitted in the previous acknowledgment mode is the 3rd data packet in acknowledgment mode, and the sequence number of this data packet is 4, that is, the difference between the first sequence number and the sequence number corresponding to the data packet transmitted in the previous acknowledgment mode is 2. Through the above settings, the sequence numbers of the data packets in acknowledgment mode can be consecutive even numbers (such as 0, 2, 4, 6, 8...) or consecutive odd numbers (such as 1, 3, 5, 7, 9...), which makes it easier for the receiving device (the second device below) to detect sequence number gaps and trigger data packet retransmission based on the gaps (details are described below).

[0088] In this application embodiment, the following rules may be predefined in the protocol or pre-set in the first device: data packets in acknowledgment mode use odd sequence numbers, data packets in non-acknowledgment mode use even sequence numbers, and the sequence numbers of data packets in acknowledgment mode are consecutively odd; or, data packets in acknowledgment mode use even sequence numbers, data packets in non-acknowledgment mode use odd sequence numbers, and the sequence numbers of data packets in acknowledgment mode are consecutively even.

[0089] After acquiring the first data packet, the first device can determine whether the first sequence number of the first data packet is an odd number or an even number based on the transmission mode of the first data packet and the above rules, and determine the specific sequence number based on the order in which the first data packet is sent.

[0090] For example, the protocol predefines the following rules: data packets in acknowledged mode use even sequence numbers, and data packets in unacknowledged mode use odd sequence numbers. In acknowledged mode, the sequence numbers of data packets are consecutively even. After acquiring the first data packet, the first device determines that the transmission mode of the first data packet is acknowledged mode. In this case, the first sequence number corresponding to the first data packet should be an even number. If the first data packet is the third data packet to be sent in acknowledged mode, then the first sequence number is 4, meaning the sequence number corresponding to the first data packet in acknowledged mode is 0, the sequence number corresponding to the second data packet is 2, and the sequence number corresponding to the third data packet is 4. If the transmission mode of the first data packet is unacknowledged mode, then the first sequence number should be an odd number; if the first data packet is the second data packet to be sent in unacknowledged mode, then the first sequence number is 3, meaning the sequence number corresponding to the first data packet in unacknowledged mode is 1, and the sequence number corresponding to the second data packet is 3.

[0091] When the first device includes multiple protocol layers, the specific implementation of the first device obtaining the first serial number can be executed by one of the protocol layers. The following describes two possible implementation methods.

[0092] In a first possible implementation, the first sequence number is obtained by the PDCP entity. That is, when the first device includes a PDCP entity and an RLC entity, the first device obtaining the first sequence number corresponding to the first data packet based on the transmission mode of the first data packet may specifically include: the PDCP entity obtaining the first sequence number based on the transmission mode of the first data packet; the method may also include: the PDCP entity sending the first data packet and the first sequence number to the RLC entity, and correspondingly, the RLC entity receiving the first data packet and the first sequence number from the PDCP.

[0093] For example, after acquiring the first data packet, the PDCP entity can determine the transmission mode of the first data packet (such as acknowledged mode or unacknowledged mode), and determine whether the first sequence number should be odd or even based on the transmission mode. Then, combining this with the transmission order of the first data packet, it determines the specific sequence number corresponding to the first data packet. After determining the first sequence number, the PDCP entity sends the first data packet and the first sequence number together to the RLC entity.

[0094] The PDCP entity determines the transmission mode of the first data packet as follows: Based on the first data packet received from the SDAP entity and the indication information carried by the first data packet, the PDCP entity determines the transmission mode of the first data packet. This indication information characterizes the correspondence between the first data packet and the transmission mode. For example, before the first device obtains the first sequence number corresponding to the first data packet based on its transmission mode, the network-side device can configure acknowledgment information to the PDCP layer of the first device. This acknowledgment information indicates whether the data packet corresponding to each QoS flow identifier (QFI) requires acknowledgment from the receiving device; that is, the acknowledgment information indicates the mapping relationship between the QFI and the transmission mode. After receiving PDCP SDU#1 (i.e., the first data packet) from the SDAP layer, the PDCP entity reads the QFI field in the SDAP header of PDCP SDU#1 and, based on the aforementioned acknowledgment information, determines the acknowledgment policy corresponding to the QFI, thereby determining the transmission mode of PDCP SDU#1. The aforementioned acknowledgment information may include a table showing the mapping relationship between different QFIs and different transmission modes. The specific principles of QFI can be found in existing technologies and will not be elaborated here.

[0095] Furthermore, in the first possible implementation, before the PDCP entity sends the first data packet to the RLC entity, the first data packet can be referred to as a PDCP SDU, meaning the PDCP entity obtains the first sequence number according to the transmission mode of PDCP SDU#1 (the first data packet). When the PDCP entity sends the first data packet to the RLC entity, this first data packet can be referred to as a PDCPPDU, meaning the PDCP entity sends PDCP PDU#1 (the first data packet) and the first sequence number to the RLC entity. And the first data packet PDCP PDU#1 received by the RLC entity from the PDCP entity can be referred to as an RLC SDU, meaning the RLC entity receives RLC SDU#1 (the first data packet) and the first sequence number from the PDCP entity.

[0096] The above method enables the PDCP entity to predetermine the sequence number of a data packet based on its transmission mode and send this sequence number along with the data packet to the RLC entity. This eliminates the need for the RLC entity to manually determine the correspondence between the transmission mode and the parity of the sequence number, allowing it to directly use the sequence number for subsequent processing. By setting the association decision between the transmission mode and the sequence number at the PDCP layer, the processing complexity of the RLC entity is reduced. Furthermore, in unified mode, acknowledged and unacknowledged data packets occupy different parity sequence number tracks, and they do not interfere with each other.

[0097] In a second possible implementation, the first sequence number is obtained by the RLC entity. That is, when the first device includes an RLC entity, the first device obtaining the first sequence number corresponding to the first data packet based on the transmission mode of the first data packet can specifically include: the RLC entity obtaining the first sequence number corresponding to the first data packet based on the transmission mode of the first data packet.

[0098] In this embodiment, the transmission mode of the first data packet can be determined by the PDCP entity of the first device. The specific implementation of the PDCP entity determining the transmission mode of the first data packet can be found in the foregoing description, and will not be repeated here. After determining the transmission mode of the first data packet, the PDCP entity can send the transmission mode to the RLC entity. For example, the PDCP entity can send the transmission mode of the first data packet along with the first data packet when sending it to the RLC entity. After obtaining the transmission mode of the first data packet, the RLC entity can obtain the first sequence number based on the transmission mode. In this case, the transmission mode is associated with the sequence number of the RLC layer; for example, an acknowledged mode is associated with an even sequence number, and an unacknowledged mode is associated with an odd sequence number; or an acknowledged mode is associated with an odd sequence number, and an unacknowledged mode is associated with an even sequence number. Furthermore, the sequence number of the RLC layer is independent of the count value of the PDCP layer.

[0099] It is understood that the specific implementation of the RLC entity obtaining the first sequence number is similar to the specific implementation of the RLC entity allocating a sequence number to the RLC SDU in the prior art. The difference is that in this embodiment, data packets under different transmission modes use sequence numbers with different parity, while in the prior art, data packets under the same mode do not consider distinguishing the parity of the sequence number when allocating the sequence number. The similarities can be understood by referring to the prior art, and will not be repeated here.

[0100] In addition, in the second possible implementation, the first data packet processed by the RLC entity can be referred to as the RLC SDU, that is, the RLC entity obtains the first sequence number corresponding to the RLC SDU#1 based on the transmission mode of the RLC SDU#1 (first data packet).

[0101] By using the above method, the sequence number parity association rule can be integrated into the existing sequence number allocation process of the RLC entity. This makes the scope of changes to the RLC entity controllable and has good compatibility with the existing RLC entity architecture.

[0102] In the two possible implementations described above, the first sequence number can be understood as the sequence number of the RLC layer, which can be used to uniquely identify the first data packet at the RLC layer. In the embodiments of this application, unless otherwise specified, "sequence number" refers to the sequence number of the RLC layer.

[0103] In S302, when the first sequence number is within the sending window, the first device sends a second data packet based on the first data packet and the first sequence number.

[0104] The sending window can be understood as a sliding window based on sequence numbers. The lower edge (or lower boundary) of the sending window is the starting point of the sending window. This lower edge is usually the sequence number of the first data packet in the acknowledged mode that is arranged in sequence and for which positive acknowledgment has not yet been received from the receiving end device. And the initial value of this lower edge is the sequence number of the first data packet in the acknowledged mode. The initial value of the lower edge of the sending window can be understood as: the value of the lower edge of the initial sending window (that is, the sending window that has not yet slid). The upper edge (or upper boundary) of the sending window is the end point of the sending window, which defines the maximum sequence number value currently allowed to be sent, and the upper edge is the sum of the lower edge of the sending window and the window length (or window size). In the embodiments of the present application, the window size of the sending window may be half of the sequence number value space in the acknowledged mode.

[0105] That the first sequence number is within the sending window can be expressed as: TX_Next_Ack≤SN#1<TX_Next_Ack+Window_Size; where TX_Next_Ack is the lower edge of the sending window, Window_Size is the window length, TX_Next_Ack + Window_Size is the upper edge of the sending window, and SN#1 is the first sequence number. That the first sequence number is within the sending window may indicate that the first data packet can be sent currently.

[0106] In the embodiments of the present application, the first device sends a new data packet or a to-be-retransmitted data packet within the window range of the sending window.

[0107] The second data packet may be obtained based on the first data packet and the first sequence number, that is, the second data packet is a data packet obtained based on the first data packet and the first sequence number. And the second data packet carries the first sequence number. The first device may place the first sequence number in the first data packet to obtain the second data packet. Alternatively, the first device may perform segmentation processing on the first data packet to obtain a plurality of data packets; then respectively place the first sequence number into the plurality of data packets to obtain the second data packet, that is, the second data packet includes a plurality of data packets at this time.

[0108] In the embodiments of the present application, after acquiring the first sequence number, the first device may determine whether the first sequence number is within the window range of the sending window. If the first sequence number is within the sending window, the first device acquires the second data packet based on the first data packet and the first sequence number, and sends the second data packet. If the first sequence number is not within the sending window, that is, the first sequence number is outside the sending window, the first device does not process the first data and the first sequence number.

[0109] For the two possible implementations in S301 mentioned above, S302 can be executed by the RLC entity. That is, the sending of the second data packet by the first device based on the first data packet and the first sequence number can specifically include: the RLC entity of the first device sending the second data packet based on the first data packet and the first sequence number.

[0110] The specific implementation of the RLC entity determining that the first sequence number is within the sending window is similar to the specific implementation of the first device determining that the first sequence number is within the sending window, except that the executing entities are different; one is the RLC entity, and the other is the first device. The similarities can be understood by referring to the relevant descriptions above, and will not be repeated here. When the first sequence number is within the sending window, the RLC entity associates the first sequence number with the first data packet, then puts the value of the first sequence number into the sequence number field of one or more data packets constructed based on the first data packet to obtain the second data packet, and then sends the second data packet.

[0111] Furthermore, in this case, the first data packet can be referred to as RLC SDU#1, and the second data packet can be referred to as RLCPDU#1. The aforementioned transmission window can be understood as the transmission window of the RLC layer; the specific principle of this transmission window can be found in existing technologies and will not be elaborated here.

[0112] In summary, in this embodiment, by associating the parity of the sequence number with the transmission mode of the data packet, and incrementing the sequence number of the acknowledgment mode data packet by a step of 2, the data packets in the acknowledgment mode and the data packets in the unacknowledgment mode each occupy non-overlapping parity subsets in the sequence number space. This fundamentally avoids conflicts between the sequence numbers of the data packets in the two modes and ensures a clear division of the sequence number space. Furthermore, since the data packets in the acknowledgment mode remain continuous within their respective parity subsets, the receiving device can determine whether there are sequence number gaps within that subset. This allows for independent and accurate packet loss detection of the data packets in the acknowledgment mode, without being affected by packet loss or out-of-order delivery of the data packets in the unacknowledgment mode. Therefore, the receiving device can accurately identify lost data packets that require an automatic retransmission request, while ignoring unacknowledgment mode data packets that do not require retransmission. This achieves differentiated processing of data packets in the two transmission modes on the same DRB in mixed transmission scenarios, enabling a single DRB to simultaneously support both acknowledgment and unacknowledgment modes. Furthermore, through the above method, the receiving device can directly determine the transmission mode corresponding to the data packet based on the parity of the sequence number, without any additional indication information, thereby reducing protocol header overhead and communication resources.

[0113] Optionally, in conjunction with the above embodiments, the operation of the first device in obtaining the first serial number differs under different transmission modes. This will be explained in detail below.

[0114] Case 1.1: The transmission mode is acknowledgment mode.

[0115] In this case, the first device obtaining the first serial number corresponding to the first data packet based on the transmission mode of the first data packet may specifically include: the first device obtaining a first parameter under the confirmation mode based on the transmission mode corresponding to the first data packet, and obtaining the first serial number based on the first parameter.

[0116] The first parameter is a state variable used to determine the sequence number of the data packet in acknowledgment mode. The second parameter is a count value for the next data packet to be associated in acknowledgment mode. In other words, the first parameter stores the count value to be assigned to the next newly generated data packet in acknowledgment mode.

[0117] The initial value of the first parameter is related to the bottom edge of the initial sending window. For example, the initial value of the first parameter can be a count value corresponding to the initial value of the bottom edge of the sending window. For instance, if the count value corresponding to the initial value of the bottom edge of the sending window is 0, the initial value of the first parameter can be set to 0.

[0118] The first parameter is updated as each data packet in the acknowledgment mode is processed. For example, after obtaining a sequence number for a data packet based on the current value of the first parameter, the value of the first parameter can be incremented by 2 so that the updated first parameter can be used for data packets in the next acknowledgment mode. In this embodiment, after the first device obtains the first sequence number based on the first parameter, the method may further include: the first device updating the first parameter, where the updated first parameter is the sum of the first parameter and 2. That is, after using the current first parameter, the first device adds 2 to the current value of the first parameter to obtain the updated first parameter. This ensures that the difference between the sequence numbers corresponding to two adjacent data packets in the acknowledgment mode is 2, thus ensuring that the sequence numbers in the acknowledgment mode are consecutive.

[0119] Based on the first parameter, the expression for obtaining the first sequence number can be: SN_AM = TX_Next_AM mod 2 [sn -FieldLength -1] Where SN_AM is the first sequence number, TX_Next_AM is the first parameter, and sn-FieldLength is the preset sequence number length. This sequence number length can be understood as the number of bits occupied by the sequence number field in the data packet (such as the RLC PDU header). This sequence number length is configurable; for example, it can be configured to be 12 bits or 18 bits. The sequence number length is related to the window length of the sending window mentioned above. That is, 2... [sn-FieldLength -1] This can represent the size of the sending window, which is equal in length to half the sequence number space. For example, if the sequence number length is N bits, its value space is 0 to 2. N-1, the window length of the sending window can be half of this value range, i.e., 2. N-1 In this context, the first data packet in the aforementioned acknowledgment mode can be understood as the data packet corresponding to the first sequence number in the sequence number space corresponding to the acknowledgment mode. For example, if the sequence number space corresponding to the acknowledgment mode includes even numbers from 0 to 300, then the data packet corresponding to the first sequence number is the data packet corresponding to sequence number 0.

[0120] By employing modulo operations, when the value of the first parameter exceeds the maximum value that the sequence number field can represent, the sequence number can automatically wrap around, thus conforming to the normal practice of limited and cyclical use of sequence number space in communication protocols, and ensuring that the length of the generated sequence number always conforms to the preset sequence number length. Furthermore, since the first parameter itself increases in increments of 2, the above operation method ensures that the generated sequence number retains its parity after the modulo operation, allowing the receiving device to identify or process the data packet transmission pattern based on the parity of the sequence number.

[0121] Alternatively, obtaining the first sequence number based on the first parameter can specifically include setting the first parameter as the first sequence number. That is, the first parameter serves as the first sequence number of the first data packet. This allows for convenient and quick acquisition of the first sequence number.

[0122] For example, the initial value of the first parameter is 0. For the first data packet in the acknowledgment mode (denoted as data packet #a1), the first parameter corresponding to data packet #a1 is 0. At this time, the first device uses the first parameter to obtain the sequence number corresponding to data packet #a1, such as if the sequence number #a1 is 0.

[0123] After using the first parameter, the first device updates the first parameter to 2. For the second data packet in the confirmation mode (denoted as data packet #a2), the first parameter corresponding to data packet #a2 is 2. At this time, the first device uses the first parameter to obtain the sequence number corresponding to data packet #a2, such as the sequence number #a2 being 2.

[0124] After using the first parameter, the first device updates it to 4. For the third data packet in the acknowledgment mode (denoted as data packet #a3), the first parameter corresponding to data packet #a3 is 4. At this time, the first device can use this first parameter to obtain the sequence number corresponding to data packet #a3, such as sequence number #a3 being 4. Following the above method, the sequence number corresponding to each data packet in the acknowledgment mode can be obtained.

[0125] In this embodiment of the application, by maintaining the counting parameter (first parameter) used in the confirmation mode, the generation logic of the sequence number of the data packet in the confirmation mode can be completely isolated from the generation logic of the sequence number of the data packet in the non-confirmation mode. This ensures that the data transmission event in the non-confirmation mode will not affect the generation of the sequence number of the data packet in the confirmation mode, thereby guaranteeing the reliability of the sequence number of the data packet in the confirmation mode.

[0126] Case 1.2: The transmission mode is unacknowledged mode.

[0127] In this case, the first device obtaining the first sequence number corresponding to the first data packet based on the transmission mode of the first data packet can specifically include the following steps one to three. These are described below.

[0128] Step 1: The first device obtains the second parameter in the non-confirmation mode based on the transmission mode corresponding to the first data packet.

[0129] The second parameter is a state variable used to determine the sequence number of the data packet in unacknowledged mode. The second parameter is also a count value for the next data packet to be associated in unacknowledged mode. In other words, the second parameter stores the count value to be assigned to the next newly generated data packet in unacknowledged mode.

[0130] The initial value of the second parameter can be any odd or even value within the initial sending window. For example, in unacknowledged mode, if the sequence number of the data packet is even, the initial value of the second parameter can be any even value within the initial sending window, such as the smallest even value within the initial sending window. For instance, if the initial sending window range is [1, 8), then the initial value of the second parameter can be 2, 4, or 6. Conversely, in unacknowledged mode, if the sequence number of the data packet is odd, the initial value of the second parameter can be any odd value within the initial sending window, such as the smallest odd value within the initial sending window. For instance, if the initial sending window range is [0, 8), then the initial value of the second parameter can be 1, 3, 5, or 7.

[0131] The second parameter is updated as each packet in the unacknowledged mode is processed. For example, after obtaining a sequence number for a packet based on the current value of the second parameter, the value of the second parameter can be incremented by 2 so that the updated second parameter can be used for the next packet in the unacknowledged mode.

[0132] In this embodiment, the second parameter is a variable parameter. When the first device determines that the first data packet is in unacknowledged mode, it can obtain the latest second parameter. It can be understood that the second parameter is similar to the aforementioned first parameter, except that: the first parameter is a state variable in acknowledged mode, while the second parameter is a state variable in unacknowledged mode; the first parameter is a series of even numbers, while the second parameter may not be a series of odd numbers, or vice versa. Similarities can be understood by referring to each other, and will not be elaborated further here.

[0133] Step 2: If the second parameter is less than the first window count value, the first device updates the second parameter.

[0134] The first window count value is the count value corresponding to the lower edge value of the first window. This lower edge value is the value of the lower edge of the (current) transmission window, or in other words, the lower edge value is the sequence number corresponding to the lower edge of the (current) transmission window. It is understood that the conversion method between "count value" and "sequence number" in this embodiment can be referred to the relevant description in section 5.2.2.1 of 3GPP TS 38.323, and will not be repeated here.

[0135] If the second parameter is less than the first window count value, it means that the first sequence number determined based on the second parameter is outside the sending window. In this case, obtaining the first sequence number using the second parameter will cause the first data packet in unacknowledged mode to fail to be sent.

[0136] The updated second parameter is located within the counting interval corresponding to the sending window. That is, the first sequence number determined based on the updated second parameter is located within the sending window. In this case, obtaining the first sequence number using the updated second parameter ensures that the first data packet in unacknowledged mode is sent.

[0137] In one possible implementation, the updated second parameter is the sum of the first window count and 1. That is, the first device can increment the first window count by 1 to obtain the updated second parameter. This allows the second parameter to be set as the count value corresponding to the first available sequence number within the sending window that has a different parity than the sequence number in the acknowledgment mode. This ensures that the first data packet obtains sending eligibility as quickly as possible, provided the sending window requirements are met, reducing the latency introduced by waiting for the sequence number to gradually increment into the sending window. Simultaneously, when subsequent data packets in unacknowledgment mode exist, the latest second parameter can be used directly without waiting for the count value to increment again, further reducing latency.

[0138] In this embodiment, after obtaining the second parameter, the first device can determine whether the second parameter is less than the first window count value. If it is determined that the second parameter is less than the first window count value, the first device updates the second parameter to obtain the updated second parameter.

[0139] Step 3: The first device obtains the first serial number based on the updated second parameter.

[0140] In one possible implementation, the expression for obtaining the first sequence number based on the updated second parameter is: SN_UM = TX_Next_UM mod 2 [sn-FieldLength -1] Wherein, SN_UM is the first sequence number, TX_Next_UM is the updated second parameter, and sn-FieldLength is the preset sequence number length. This sequence number length can be referred to the relevant description in Case 1.1 above, and will not be repeated here. By employing modulo operations, when the value of the second parameter exceeds the maximum value that the sequence number field can represent, the sequence number can automatically wrap around, thus conforming to the normal practice of limited and cyclical use of sequence number space in communication protocols, and ensuring that the length of the generated sequence number always conforms to the preset sequence number length.

[0141] In another possible implementation, obtaining the first sequence number based on the updated second parameter can specifically include setting the updated second parameter as the first sequence number. That is, the second parameter serves as the first sequence number of the first data packet. This allows for convenient and quick acquisition of the first sequence number.

[0142] By employing steps one through three above, when data packet transmission in unacknowledged mode is infrequent, the sequence number of the data packets in unacknowledged mode is ensured to always remain within the sending window. This prevents data packets from being unable to be sent due to their assigned sequence number falling outside the sending window, thus guaranteeing the reliability of data packet transmission in unacknowledged mode. Furthermore, this method allows the sequence number in unacknowledged mode to advance in leaps as the sending window progresses, avoiding the problem of the sequence number permanently lagging behind the bottom edge of the sending window and thus preventing data packet transmission.

[0143] After the first device obtains the first sequence number based on the updated second parameter, the above method may further include: the first device updating the updated second parameter again, wherein the updated second parameter is the sum of the updated second parameter and 2. That is, the first device can add 2 to the updated second parameter to obtain the updated second parameter again; at this time, the updated second parameter is the latest second parameter. In this way, the sequence number of the data packet in the unacknowledged mode remains within the same odd-even subset during the normal transmission of the data packet, and will not fall into the sequence number space of the acknowledged mode due to the increment of the second parameter, thus ensuring the stability of the mechanism for distinguishing different modes based on the parity of the sequence number.

[0144] In addition, the above method may also include: if the second parameter is greater than or equal to the first window count value, the first device may obtain the first serial number based on the second parameter.

[0145] The second parameter is the second parameter obtained in step one above.

[0146] The second parameter being greater than or equal to the first window count value indicates that the sequence number obtained based on the second parameter is within the sending window range; and the sequence number meets the requirement of being greater than the lower edge of the sending window, so the first data packet will not be determined as invalid because the sequence number is behind the lower edge of the sending window.

[0147] The specific implementation of obtaining the first serial number based on the second parameter (denoted as specific implementation #1) is similar to the specific implementation of obtaining the first serial number based on the updated second parameter in step three above (denoted as specific implementation #2). The difference is that the values ​​of the second parameter used in the two are different. That is, in specific implementation #1, the second parameter obtained in step one is used, while in specific implementation #2, the updated second parameter obtained in step two is used. The similarities can be understood by referring to the relevant introduction above, and will not be repeated here.

[0148] By obtaining the first sequence number based on the second parameter when the second parameter is greater than or equal to the first window count value, it can be ensured that the first sequence number obtained based on the second parameter meets the lower edge requirement of the sending window, and the process of waiting for the count value (second parameter) to gradually increase from below the lower edge of the window to inside the window is eliminated, thereby reducing the latency introduced by the count value catching up with the lower edge of the window.

[0149] It is understood that Cases 1.1 and 1.2 above describe the operations for obtaining the first serial number under different modes. When the first device includes a PDCP entity, the operations for obtaining the first serial number in Cases 1.1 and 1.2 can be performed by that PDCP entity.

[0150] Optionally, in conjunction with the above embodiments, the method may further include: the first device receiving a status report from the second device, and updating the lower edge value of the first window according to the minimum sequence number in the acknowledgment mode of the unsuccessfully transmitted status report.

[0151] The status report is used to indicate data packets in acknowledgment mode that the second device has not received, as well as data packets in acknowledgment mode that the second device has received. For example, the status report may include an acknowledgment sequence number (ACK_SN) and a negative acknowledgment (NACK) field. ACK_SN indicates that all data packets in acknowledgment mode with sequence numbers less than ACK_SN and not listed in the NACK field have been successfully received. The NACK field indicates data packets in acknowledgment mode that were lost or not successfully received. In the unified mode of this application embodiment, the status report may include information indicating the reception status of acknowledgment mode data packets, but not information indicating the reception status of non-acknowledgment mode data packets. The sequence numbers indicated by the ACK_SN and NACK fields in the status report both belong to the odd / even subset corresponding to the acknowledgment mode data packets.

[0152] It is understood that the status report in this application embodiment is similar to the RLC layer status report in the prior art. The difference is that in this application embodiment, the status report only reports the reception status of data packets in acknowledgment mode. Since the sequence numbers in acknowledgment mode are all restricted to the same odd-even subset (e.g., all even or all odd), the sequence numbers indicated by the ACK_SN and NACK fields are also all even or all odd. However, the sequence numbers in acknowledgment mode reported by the existing RLC layer status report do not have this odd-even restriction, and the sequence numbers indicated by the ACK_SN and NACK fields may contain both even and odd numbers. The similarities can be understood by referring to the existing RLC layer status report, and will not be repeated here.

[0153] The value of the lower edge of the first window can be found in the aforementioned description and will not be repeated here. The updated value of the lower edge of the first window is the minimum sequence number mentioned above.

[0154] For example, in unified mode, data packets in acknowledgment mode use even sequence numbers, and the initial value of the lower edge of the first window is 0. The first device sends acknowledgment mode data packets with sequence numbers 0, 2, 4, 6, and 8 to the second device sequentially. The second device successfully receives data packets with sequence numbers 0, 2, and 8, but data packets with sequence numbers 4 and 6 are lost. Therefore, the second device sends a status report to the first device with the following content: ACK_SN = 10, indicating that acknowledgment mode data packets with sequence numbers less than 10 and not listed in the NACK field (i.e., 0, 2, and 8) have been successfully received; NACK = {4, 6}, explicitly indicating that acknowledgment mode data packets with sequence numbers 4 and 6 were lost or not successfully received. After receiving this status report, the first device parses the NACK field, obtains the set of sequence numbers that were not successfully transmitted {4, 6}, and determines the smallest sequence number from it, which is 4. The first device updates the lower edge value of the first window from 0 to 4.

[0155] In this embodiment, after receiving a status report, the first device can determine the minimum sequence number in the acknowledgment mode of the unsuccessful transmission in the status report, and update the lower edge value of the first window to that minimum sequence number. After the lower edge value of the first window is updated, the upper edge of the sending window changes accordingly, and the entire sending window moves forward.

[0156] By employing the above method, the lower edge of the sending window can be adjusted to the position of the earliest unsuccessfully transmitted sequence number based on the actual reception status reported by the second device. This ensures that all lost acknowledgment mode data packets can regain the right to be transmitted, avoiding the omission of retransmitted data packets due to the lower edge of the sending window advancing too quickly. This guarantees the integrity and reliability of data retransmission in acknowledgment mode. Furthermore, since the sequence numbers in acknowledgment mode are all restricted to the same parity subset, and the smallest unsuccessfully transmitted sequence number in the status report also belongs to this parity subset, the updated lower edge of the window remains consistent with the sequence number space of acknowledgment mode. Therefore, the mechanism for distinguishing different modes based on the parity of sequence numbers will not be disrupted due to window updates.

[0157] The above describes the operation of the first device updating the first window lower edge value based on the status report. When the first device includes an RLC entity, as in the two possible implementations of S301 described above, the operation of updating the first window lower edge value based on the status report can be performed by the RLC entity. When the PDCP entity needs to use the first window lower edge value, such as when determining the relationship between the second parameter and the first window count value, it can request the latest first window lower edge value from the RLC entity or obtain the latest first window lower edge value from the buffer of the first device.

[0158] Furthermore, the RLC entity can delete successfully transmitted data packets (RLCPDUs) from the retransmission buffer based on status reports. The RLC entity can also send information #1 to the PDCP entity indicating successfully transmitted data packets, and the PDCP entity can delete successfully transmitted data packets (PDCP PDUs) based on this information #1.

[0159] As you can understand, the above content provides an overall overview of the data transmission methods on the sending end. For ease of understanding, the following section will combine... Figure 4 Taking the example of data packets using even sequence numbers in acknowledged mode and data packets using odd sequence numbers in unacknowledged mode, the above data transmission method is introduced through a complete process.

[0160] like Figure 4 As shown, the data transmission method includes the following steps: S401, the RRC entity of the network-side device configures a "QFI to Acknowledgment policy" mode policy mapping table to the PDCP layer of the sending device through dedicated signaling.

[0161] The transmitting device corresponds to the first device in the aforementioned embodiments.

[0162] The mode policy mapping table specifies whether the data packet corresponding to each QFI requires confirmation from the receiving device. This mode policy mapping table corresponds to the confirmation information in the aforementioned embodiments.

[0163] In this embodiment, when the sending device is a terminal device, the network-side device can configure the aforementioned mode policy mapping table to the PDCP layer of the sending device after establishing an RRC connection with the sending device. During the RRC connection maintenance period, the network-side device does not need to configure the mode policy mapping table to the PDCP layer of the sending device again.

[0164] Furthermore, S401 is not executed when the sending device is a network device.

[0165] S402, the PDCP entity receives a PDCP SDU from the SDAP layer and obtains the transmission mode corresponding to the PDCPSDU based on the mode policy mapping table.

[0166] In this embodiment, the PDCP entity is the PDCP entity of the transmitting device, corresponding to the PDCP entity of the first device in the aforementioned embodiment. The aforementioned PDCP SDU corresponds to the first data packet in the aforementioned embodiment.

[0167] After receiving a PDCP SDU, the PDCP entity can read the QFI field in the SDAP header of the PDCP SDU and, based on the QFI field, look up the mode policy mapping table to retrieve the acknowledgment policy corresponding to the QFI field. This acknowledgment policy indicates whether the receiving device needs to provide acknowledgment upon receiving the data packet corresponding to the PDCP SDU; that is, the acknowledgment policy characterizes the transmission mode of the PDCP SDU. Specifically, if the acknowledgment mode indicates that the receiving device needs to provide acknowledgment upon receiving the data packet corresponding to the PDCP SDU, then the PDCP SDU corresponds to the acknowledgment mode; otherwise, the PDCP SDU corresponds to the non-acknowledgment mode.

[0168] When the QFI in the PDCP SDU header corresponds to "feedback confirmation", that is, when the PDCP SDU corresponds to confirmation mode, execute S403 below; when the QFI in the PDCP SDU header corresponds to "no confirmation required", that is, when the PDCP SDU corresponds to non-confirmation mode, execute S408 below.

[0169] S403, the PDCP entity will associate TX_Next_AM with the PDCP SDU.

[0170] TX_Next_AM corresponds to the first parameter in the aforementioned embodiment. The initial value of TX_Next_AM is 0.

[0171] S404, the PDCP entity uses TX_Next_AM to perform integrity protection and encryption on the PDCP SDU.

[0172] The specific implementation of integrity protection and encryption of PDCP SDU by the PDCP entity can be found in the relevant descriptions in the existing technology, and will not be repeated here.

[0173] S405, the PDCP entity obtains the SN_AM corresponding to the PDCP SDU based on TX_Next_AM.

[0174] SN_AM is the sequence number corresponding to the PDCP SDU, and SN_AM = TX_Next_AM mod 2. [sn-FieldLength -1] SN_AM corresponds to the first sequence number in case 1.1 of the aforementioned embodiment, which can be found in the relevant descriptions in the aforementioned embodiments and will not be repeated here.

[0175] S406, the PDCP entity transmits PDCP SDU and SN_AM to the RLC layer through the inter-layer interface. Correspondingly, the RLC entity receives the RLC SDU and SN_AM from the PDCP.

[0176] PDCP PDU is a data packet processed by the PDCP entity from PDCP SDU.

[0177] The inter-layer interface can be understood as the interface between the PDCP layer and the RLC layer. This interface can be used to transmit data units and / or control information. The specific principles of the inter-layer interface can be found in relevant existing technologies, and will not be elaborated upon here.

[0178] In this embodiment, the RLC entity is the RLC entity of the transmitting device, corresponding to the RLC entity of the first device in the aforementioned embodiment.

[0179] S407, PDCP entity update TX_Next_AM.

[0180] The PDCP entity adds 2 to the current value of TX_Next_AM to obtain the updated TX_Next_AM. The updated TX_Next_AM is the sum of the current value of TX_Next_AM and 2, that is, TX_Next_AM = TX_Next_AM + 2, where "=" indicates assignment.

[0181] S408, the PDCP entity obtains TX_Next_Ack and converts TX_Next_Ack into a COUNT value to obtain COUNT(TX_Next_Ack).

[0182] The COUNT value is the count value.

[0183] TX_Next_Ack corresponds to the lower edge value of the first window in the aforementioned embodiment. The initial value of TX_Next_Ack is 0.

[0184] COUNT(TX_Next_Ack) corresponds to the first window count value in the aforementioned embodiment. The initial value of COUNT(TX_Next_Ack) is 0.

[0185] In this embodiment, TX_Next_Ack and COUNT(TX_Next_Ack) are always even numbers.

[0186] S409, PDCP entity obtains TX_Next_UM.

[0187] TX_Next_UM corresponds to the second parameter in the aforementioned embodiment. The initial value of TX_Next_UM can be 1 (i.e., the smallest odd value within the initial sending window).

[0188] S410, the PDCP entity determines whether TX_Next_UM is less than COUNT(TX_Next_Ack).

[0189] Execute S411 when TX_Next_UM is less than COUNT(TX_Next_Ack); execute S412 when TX_Next_UM is greater than or equal to COUNT(TX_Next_Ack).

[0190] S411, PDCP entity update TX_Next_UM.

[0191] PDCP increments the current COUNT(TX_Next_Ack) by 1 to obtain the updated TX_Next_UM, that is, the updated TX_Next_UM = COUNT(TX_Next_Ack) + 1.

[0192] S412, the PDCP entity uses TX_Next_UM to perform integrity protection and encryption on the PDCP SDU.

[0193] S413, the PDCP entity obtains the SN_UM corresponding to the PDCP SDU based on TX_Next_UM.

[0194] SN_UM is the sequence number corresponding to the PDCP SDU, and SN_UM = TX_Next_UM mod 2. [sn-FieldLength -1] SN_UM corresponds to the first sequence number in case 1.2 of the aforementioned embodiment, which can be found in the relevant descriptions in the aforementioned embodiments and will not be repeated here.

[0195] S414, the PDCP entity transmits PDCP PDU and SN_UM to the RLC layer through the inter-layer interface. Correspondingly, the RLC entity receives RLC SDU and SN_UM from the PDCP.

[0196] For PDCP, PDU, and inter-layer interfaces, please refer to the relevant introduction in S406 above, which will not be repeated here.

[0197] S415, PDCP entity update TX_Next_UM.

[0198] The PDCP entity adds 2 to the current value of TX_Next_UM to obtain the updated TX_Next_UM. The updated TX_Next_UM is the sum of the current value of TX_Next_UM and 2, that is, TX_Next_UM = TX_Next_UM + 2, where "=" indicates assignment.

[0199] S416 After receiving the RLC SDU and SN from the PDCP layer, the RLC entity determines whether the SN is within the transmission window.

[0200] SN is either SN_AM or SN_UM.

[0201] The SN being within the transmission window may be expressed as: TX_Next_Ack≤SN<TX_Next_Ack + Window_Size, where Window_Size is the window length of the transmission window.

[0202] When the SN is within the transmission window, step S417 described below is executed; when the SN is outside the transmission window, the RLC entity does not send the aforementioned RLC SDU to the MAC layer.

[0203] In S417, the RLC entity associates the SN with the RLC SDU, places the value of the SN into the sequence number field for constructing an RLC PDU, and sends the RLC PDU to the MAC layer.

[0204] The RLC PDU is the aforementioned RLC SDU or a segment of the aforementioned RLC SDU.

[0205] In S418, when a status report from a receiving end device is received, the RLC entity obtains, based on the status report, the SN of the RLC SDU that has been acknowledged by the receiving end device, and the smallest unacknowledged SN.

[0206] The aforementioned status report is configured to feed back the reception status of data packets, and the status report is generated and sent by the RLC layer of the receiving end device.

[0207] In S419, the RLC entity updates TX_Next_Ack based on the smallest unacknowledged SN.

[0208] The RLC entity may further send the SN of the acknowledged RLC SDU to the PDCP layer based on the SN of the acknowledged RLC SDU. The PDCP entity may delete the PDCP PDU that has been successfully transmitted based on the SN.

[0209] It can be understood that for the specific implementation of S401 to S419 described above, reference may be made to the foregoing Figure 3 related descriptions in the illustrated embodiments, which will not be repeated herein.

[0210] In addition, S401 to S419 describe a sequence number configuration manner for data packets in a unified mode, that is, the acknowledged mode uses even sequence numbers, and the unacknowledged mode uses odd sequence numbers. In the case of adopting the opposite convention (that is, the acknowledged mode uses odd sequence numbers, and the unacknowledged mode uses even sequence numbers), the initial values of TX_Next_AM and TX_Next_Ack may be set to 1, and the initial value of TX_Next_UM may be set to 2. In this case, TX_Next_Ack and COUNT(TX_Next_Ack) are always odd. Other operations are similar to those in S401 to S419, which may be understood with reference to the relevant descriptions of S401 to S419, and will not be repeated herein.

[0211] In the two embodiments described above, data packets in unacknowledged mode only carry sequence numbers when sent in segments; they do not carry sequence numbers when sent without segments. That is, data packets in unacknowledged mode without segments can be sent directly without being assigned sequence numbers. Typically, the number of unacknowledged mode data packets that need to carry sequence numbers will not exceed the number of data packets in acknowledged mode. Therefore, the above data transmission method is applicable to most situations.

[0212] The above describes the operation of the sending end (first device). The following describes the operation of the receiving end (second device). This second device can be... Figure 1 The second device can also refer to a component within the second device (such as a circuit, processor, chip, or chip system), or it can be implemented by a logic module or software capable of performing all or part of the functions of the second device. The following description uses the second device as an example.

[0213] In unified mode, after receiving a data packet from the first device, the second device can determine whether there are gaps in the received sequence numbers in the acknowledgment mode based on the continuity of the sequence numbers in the acknowledgment mode. If a gap exists, it will report the lost or unreceived data packets in the acknowledgment mode to the first device. Since the sequence numbers in the acknowledgment mode and the unacknowledgment mode belong to different odd and even subsets, the sequence number corresponding to the acknowledgment mode may be even or odd. The following sections will describe the different cases.

[0214] Case 2.1: The sequence number of the data packet in acknowledgment mode is even, and the sequence number of the data packet in non-acknowledgment mode is odd.

[0215] In this case, the second device sends a status report when there is a gap in the received even-numbered sequence number.

[0216] In acknowledgment mode, an even sequence number in a data packet indicates that the data packet with an even sequence number received by the second device belongs to acknowledgment mode.

[0217] In unacknowledged mode, an odd sequence number in a data packet indicates that the data packet with an odd sequence number received by the second device belongs to unacknowledged mode.

[0218] A gap in the received even-numbered sequence numbers can be understood as follows: among the received even-numbered sequence numbers, there are two even-numbered sequence numbers whose difference is greater than 2, and there are no other received even-numbered sequence numbers between these two. This indicates that a gap exists in the received even-numbered sequence numbers. This gap indicates that the data packet corresponding to the sequence number was lost or failed to be transmitted. For example, the second device has received even-numbered sequence numbers including 0, 2, 6, 4, and 10. Among them, the difference between the received even-numbered sequence numbers 6 and 10 is 4, which is greater than 2, and there are no other received even-numbered sequence numbers between 6 and 10, indicating that sequence number 8 is missing. In this case, a gap exists in the received even-numbered sequence numbers.

[0219] The status report can be used to indicate packets in acknowledgment mode that (the second device) has not received, as well as packets in acknowledgment mode that (the second device) has received. The packets in acknowledgment mode that have not been received can be determined based on gaps in the received even-numbered sequence numbers; that is, the sequence number corresponding to the gap is the sequence number of the packets in acknowledgment mode. Continuing the example above, if sequence number 8 is missing from the received even-numbered sequence numbers, the second device can indicate this sequence number through the NACK field in the status report to notify the first device to retransmit the packet with sequence number 8. It is understood that the above status report can be referenced from the aforementioned... Figure 3 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0220] In this embodiment of the application, when there is a gap in the even-numbered sequence number that has been received, the second device sends a status report to the first device, which can promptly request the first device to retransmit the data packets that the second device has not received.

[0221] Furthermore, the second device sending a status report when there is a gap in the received even-numbered sequence number can specifically include: the second device sending a status report when there is a gap in the received even-numbered sequence number and the reassembly timer expires.

[0222] The recombination timer is used to start timing when a gap is detected in the received even-numbered sequence numbers. The timing duration and specific principles of the recombination timer can be found in existing technologies and will not be elaborated here.

[0223] When the second device detects a gap in a received even-numbered sequence number, it starts a reassembly timer. During the reassembly timer's duration, the second device continues to receive data packets. If all data packets for the even-numbered sequence number corresponding to the gap are received before the reassembly timer expires, the reassembly timer is stopped, and the second device does not send a status report. If the gap still exists when the reassembly timer expires, the second device sends a status report to indicate to the first device that the data packet corresponding to the gap was not successfully received.

[0224] By using the above method, reassembly time can be reserved for out-of-order data packets that arrive due to differences in transmission delay, effectively avoiding unnecessary retransmissions triggered by sending status reports too early, reducing waste of communication resources, and improving the efficiency and reliability of data transmission.

[0225] There are several ways for the second device to determine whether there are gaps in the received even-numbered sequence numbers. These are explained below.

[0226] In one possible implementation, the second device can determine whether there is a gap in the even-numbered sequence number based on the first variable and the second variable. That is, the above method can also include: the second device determining that there is a gap in the received even-numbered sequence number based on the fact that the first variable is greater than the sum of the second variable and 2.

[0227] The first variable is used to indicate the upper bound of the sequence number (to be reached) of the received acknowledgment mode data packets. The first variable can be the value obtained by adding 2 to the maximum sequence number of the currently received acknowledgment mode data packets. That is, if the maximum sequence number of the successfully received acknowledgment mode data packets is N, then the first variable is N+2. In this embodiment, when the second device receives an acknowledgment mode data packet, it can determine whether to update the first variable based on the sequence number corresponding to the acknowledgment mode data packet. For example, when the sequence number of the acknowledgment mode data packet is greater than or equal to the current first variable, or when the sequence number of the acknowledgment mode data packet is greater than the maximum sequence number of the currently successfully received acknowledgment mode data packets, the second device updates the first variable based on the sequence number of the acknowledgment mode data packet. In this case, the updated first variable is the sum of the sequence number of the acknowledgment mode data packet and 2.

[0228] The second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window (i.e., the value of the lower edge), which is the sequence number of the next acknowledgment mode data packet that the second device expects to receive. This receiving window can be understood as a sliding window based on sequence numbers. The lower edge (or lower boundary) of the receiving window is the starting point of the receiving window, and this lower edge is used to indicate the sequence number of the next acknowledgment mode data packet that the second device expects to receive in sequence. When the data packet corresponding to this sequence number is successfully received, and subsequent consecutive data packets have all been received in sequence, the receiving window slides forward, and the lower edge is updated to the next sequence number that has not yet been received in sequence. The upper edge of the receiving window defines the maximum range of sequence numbers currently allowed to be received, and this upper edge is the sum of the lower edge of the receiving window and the window length (or window size). In this embodiment, the window length of the receiving window is the same as described above. Figure 3 In the illustrated embodiment, the sending windows have the same window length; and the initial value of the bottom edge of the receiving window is the same as the initial value of the bottom edge of the sending window.

[0229] After assembling each acknowledgment mode data packet, the second device can determine whether the sequence number of the acknowledgment mode data packet is equal to the second variable. When the sequence number is equal to the second variable, the second device starts from the sequence number corresponding to the current second variable and checks the subsequent even-numbered sequence numbers in sequence with a step size of 2, and updates the second variable to the first even-numbered sequence number that has not yet been fully received.

[0230] For example, when the acknowledgment mode data packets use even-numbered sequence numbers, the sequence numbers corresponding to the acknowledgment mode data packets are: 0, 2, 4, 6, 8, 10... Assuming that the second device has not yet received any acknowledgment mode data packets, the initial value of the second variable is 0, meaning the second device expects to receive the acknowledgment mode data packet with sequence number 0. After the second device receives the data packet with sequence number 0 in sequence and successfully assembles it, the second variable slides forward to the next unreceived even-numbered sequence number, that is, the second variable is updated to 2, indicating that the second device expects to receive the acknowledgment mode data packet with sequence number 2. Subsequently, the second device successfully receives and assembles the data packet with sequence number 2, and the second variable continues to slide forward to 4. And so on, with the second variable incrementing by 2 for each consecutive data packet successfully received.

[0231] Suppose the second device has successfully received and assembled data packets with sequence numbers 0 and 4, but the data packet with sequence number 2 has not yet arrived. At this point, since the second variable points to the next expected data packet, and the data packet with sequence number 0 has been successfully assembled, the second variable should slide to the next unreceived even-numbered sequence number. Because sequence number 2 has not been received, the second variable remains at 2 and will not jump to 4. Only when the data packet with sequence number 2 arrives and is successfully assembled will the second variable slide to 4 (if 4 has been received and buffered) or slide to the sequence number corresponding to the next gap.

[0232] It is understood that the first variable in this embodiment is similar to "RX_Next_Highest" in the prior art, except that: the first variable is the value obtained by adding 2 to the maximum value of the sequence number in the currently successfully received acknowledgment mode data packet, while RX_Next_Highest is the value obtained by adding 1 to the maximum value of the sequence number in the successfully received data packet in acknowledgment mode. The similarities can be found in the relevant descriptions in the prior art, and will not be repeated here. The second variable in this embodiment is similar to "RX_Next" in the prior art, except that: in this embodiment, the acknowledgment mode data packet uses an even or odd sequence number, therefore the value of the second variable is a consecutive even number (such as 0, 2, 4, 6...) or an odd number (such as 1, 3, 5, 7...), while in the prior art, RX_Next is a consecutive natural number (such as 0, 1, 2, 3...). The similarities can be found in the relevant descriptions in the prior art, and will not be repeated here.

[0233] Based on the definitions of the first and second variables mentioned above, the technical principle of the judgment condition "the first variable is greater than the sum of the second variable and 2" is explained below.

[0234] If the difference between the sequence numbers of two adjacent acknowledgment mode data packets is 2, and all acknowledgment mode data packets arrive in sequence, the maximum sequence number corresponding to the acknowledgment mode data packets successfully received by the second device does not exceed the second variable, meaning the next expected sequence number has not yet arrived. In this case, the first variable is less than or equal to the sum of the second variable and 2, meaning the received even-numbered sequence numbers are consecutive and there are no gaps. Conversely, when the first variable is greater than the sum of the second variable and 2, the maximum sequence number plus 2 is still greater than the sum of the second variable and 2, meaning the maximum received sequence number is greater than the second variable. This indicates that among the acknowledgment mode data packets received by the second device, there are data packets with sequence numbers greater than the second variable, while the data packet corresponding to the second variable itself has not yet been received. In other words, there is at least one missing even-numbered sequence number between the second variable and the maximum received sequence number, resulting in a gap in the received even-numbered sequence numbers.

[0235] For example, if RX_Next (the second variable) is 0, it means the second device expects to receive an acknowledgment mode data packet with sequence number 0. If the second device has successfully received data packets with sequence numbers 2 and 4, then the highest sequence number received is 4. In this case, RX_Next_Highest (the first variable) is 6, meaning RX_Next_Highest = 4 + 2 = 6; and RX_Next remains 0. At this point, RX_Next_Highest > RX_Next + 2, meaning 6 > 2, indicating a gap in the received even-numbered sequence numbers. In fact, the expected sequence number 0 is missing, while sequence numbers 2 and 4 have been received, creating a gap between 0 and 4.

[0236] For example, if RX_Next is 2 and the highest received sequence number is 6, then RX_Next_Highest = 6 + 2 = 8, and RX_Next_Highest > RX_Next + 2 = 4. This indicates that there is a gap between sequence number 2 and 6, that is, sequence number 4 is missing.

[0237] By using the comparison method based on the first and second variables described above, the second device does not need to sort and traverse all received sequence numbers. It only needs to maintain two variables and perform a single numerical comparison to quickly determine whether there are gaps in the received even-numbered sequence numbers. This reduces computational complexity and the power consumption of the second device.

[0238] In another possible implementation, the second device can sort the even-numbered sequence numbers corresponding to the received acknowledgment mode data packets in ascending order, and determine whether there is a gap by traversing the sorted sequence numbers.

[0239] For example, after receiving each acknowledgment mode data packet, the second device records the even-numbered sequence number corresponding to that data packet and sorts all the recorded even-numbered sequence numbers in ascending order. Starting from the sequence number corresponding to the bottom edge of the receiving window (i.e., the second variable), the second device checks whether the sorted sequence numbers are consecutive, that is, whether the difference between two adjacent sequence numbers is always 2. If, during the check, the difference between two adjacent sequence numbers is found to be greater than 2, it is determined that there is a gap in the received even-numbered sequence numbers, and the missing sequence number corresponding to this gap is the previous sequence number plus 2.

[0240] For example, the even-numbered serial numbers received by the second device include: 0, 2, 6, 4, 10, which, after sorting, become: 0, 2, 4, 6, 10. The second device starts traversing from the current second variable (assuming it is 0), and finds that the difference between serial number 6 and serial number 10 is 4, which is greater than 2. Therefore, it determines that there is a gap in the received even-numbered serial numbers, and the missing serial number corresponding to this gap is 8.

[0241] In this way, the second device can accurately identify the gaps in the received even-numbered sequence numbers, thereby determining the lost acknowledgment mode data packets and providing a basis for triggering subsequent status reports.

[0242] Case 2.2: The sequence number of the data packet in acknowledgment mode is odd, and the sequence number of the data packet in non-acknowledgment mode is even.

[0243] In this case, a status report is sent when there is a gap in the received odd sequence number.

[0244] In acknowledgment mode, an odd sequence number in a data packet indicates that the data packet with an odd sequence number received by the second device belongs to acknowledgment mode.

[0245] In unacknowledged mode, an even sequence number in a data packet indicates that the data packet with an even sequence number received by the second device belongs to unacknowledged mode.

[0246] A gap in the received odd sequence numbers can be understood as follows: among the received odd sequence numbers, there are two odd sequence numbers whose difference is greater than 2, and there are no other received odd sequence numbers between these two. This indicates a gap in the received odd sequence numbers. The gap indicates that the data packet corresponding to that sequence number was lost or failed to be transmitted.

[0247] For information on status reports, please refer to the aforementioned introduction; further details will not be provided here.

[0248] In this embodiment of the application, when there is a gap in the received odd sequence number, the second device sends a status report to the first device, which can promptly request the first device to retransmit the data packets that the second device has not received.

[0249] Furthermore, the second device's sending of a status report when a gap exists in the received odd-numbered sequence number can specifically include: the second device sending a status report when a gap exists in the received odd-numbered sequence number and the reconstruction timer times out. The reconstruction timer is used to start timing when it is determined that a gap exists in the received odd-numbered sequence number.

[0250] There are several ways for the second device to determine whether there are gaps in the received odd-numbered sequence numbers. These are explained below.

[0251] In one possible implementation, the second device can determine whether a gap exists in the odd-numbered sequence number based on a first variable and a second variable. That is, the method can further include: the second device determining that a gap exists in the received odd-numbered sequence number based on the first variable being greater than the sum of the second variable and 2. Here, the first variable indicates the upper bound of the data packet sequence number in the received acknowledgment mode, and the second variable indicates the sequence number corresponding to the lower edge of the receiving window.

[0252] It should be noted that in Case 2.2, the acknowledgment mode data packets use odd sequence numbers, with the sequence numbers corresponding to the acknowledgment mode data packets being: 1, 3, 5, 7, 9... The initial value of the first variable can be set accordingly, and the initial value of the second variable can be set to 1, meaning the second device expects the next acknowledgment mode data packet with a sequence number of 1. The second variable increments by 2 each time it slides forward after successfully assembling the data packet. The definitions, update logic, and specific methods for judging gaps based on the first and second variables are the same as those described in Case 2.1, and can be understood by referring to the relevant introduction in Case 2.1, such as replacing even sequence numbers with odd sequence numbers. This will not be elaborated further here.

[0253] For example, in case 2.2, assume the second variable is 1, meaning the second device expects to receive an acknowledgment mode data packet with sequence number 1. If the second device has successfully received data packets with sequence numbers 3 and 5, then the maximum sequence number received is 5, and the first variable is 7. At this point, the first variable > the second variable + 2, i.e., 7 > 3, indicating a gap in the received odd-numbered sequence numbers. In fact, the expected sequence number 1 is missing, while sequence numbers 3 and 5 have been received, creating a gap between 1 and 5.

[0254] For example, if the second variable is 3 and the maximum received sequence number is 7, then the first variable is 9. The first variable > the second variable + 2, that is, 9 > 5. This indicates that there is a gap between sequence number 3 and 7, that is, sequence number 5 is missing.

[0255] In another possible implementation, the second device can sort the odd sequence numbers corresponding to the received acknowledgment mode data packets in ascending order, and determine whether there is a gap by traversing the sorted sequence numbers.

[0256] It is understandable that Case 2.2 is similar in implementation principle to Case 2.1, except that in Case 2.2, data packets in acknowledged mode use odd sequence numbers, while data packets in unacknowledged mode use even sequence numbers. That is, the correspondence between sequence number parity and transmission mode is reversed compared to Case 2.1. Accordingly, in Case 2.2, the second device detects whether there are gaps in the received odd sequence numbers, not even sequence numbers. Apart from this, the specific methods for gap detection, the triggering conditions and sending mechanism for status reports, and the definition and update logic of related variables are all the same as described in Case 2.1, and can be understood by referring to the aforementioned related introductions; they will not be repeated here.

[0257] In addition, the following rules can be predefined in the protocol or pre-set in the second device: data packets in acknowledgment mode use odd sequence numbers, data packets in unacknowledgment mode use even sequence numbers, and data packets in acknowledgment mode use consecutive odd sequence numbers; or, data packets in acknowledgment mode use even sequence numbers, data packets in unacknowledgment mode use odd sequence numbers, and data packets in acknowledgment mode use consecutive even sequence numbers.

[0258] In summary, in this embodiment, when data packets in acknowledgment mode use even or odd sequence numbers, by determining whether there are gaps in the received even or odd sequence numbers and sending a status report when gaps exist, the loss of acknowledgment mode data packets can be identified in mixed data packet transmission scenarios (i.e., unified mode), and the sending of status reports can be triggered in a timely manner. Simultaneously, the status report is used to indicate both unreceived and received acknowledgment mode data packets, enabling the sender to accurately know the receiving status of the receiver, thereby allowing for targeted retransmission and improving the reliability of data transmission.

[0259] Optionally, in conjunction with the above embodiments, the method may further include: if the restart condition is met when the reorganization timer times out, then restarting the reorganization timer.

[0260] The restart conditions include at least one of the following: the first variable is greater than the sum of the third variable and 2 (referred to as restart condition #1), the first variable is equal to the sum of the third variable and 2, and the data packet corresponding to the third variable has not been fully received (referred to as restart condition #2).

[0261] The first variable can be referred to in the previous introduction, and will not be repeated here.

[0262] The third variable is determined based on the fourth variable. For ease of understanding, the fourth variable will be introduced below.

[0263] The fourth variable is the same as the first variable when the reassembly timer starts; that is, the value of the fourth variable is the same as the value of the first variable when the reassembly timer starts. In other words, the fourth variable records the upper bound of the sequence number of the acknowledgment mode data packets already received by the second device when the reassembly timer starts. This fourth variable can serve as a benchmark for subsequently determining whether the reception status has changed. For example, consider acknowledgment mode data packets using even-numbered sequence numbers (sequence numbers are 0, 2, 4, 6, 8, 10...). Assume the current second variable is 2, meaning the second device expects to receive the data packet with sequence number 2. The second device has successfully received data packets with sequence numbers 0 and 4, but the data packet with sequence number 2 has not yet arrived. At this time, the maximum received sequence number is 4, and the first variable is 6, i.e., 4 + 2 = 6. The second device determines that there is a gap in the received even-numbered sequence numbers, starts the reassembly timer, and records the fourth variable as the current value of the first variable, i.e., the fourth variable is now 6.

[0264] The third variable is the sequence number of the first acknowledgment mode data packet that was not fully received (i.e., not all bytes have been received) when the status report was triggered, and whose sequence number is greater than or equal to the fourth variable. In other words, starting from the sequence number position corresponding to the fourth variable, the search proceeds upwards to find the first acknowledgment mode data packet that has not yet been fully received by the second device; the sequence number corresponding to this data packet is the third variable. This upward search can be understood as searching in the sequence number space from a reference point (such as the sequence number corresponding to the fourth variable) in an increasing direction along the sequence number values.

[0265] Continuing the example above, when the reassembly timer starts, the fourth variable is 6. During the reassembly timer's operation, assume the second device does not receive any new acknowledgment mode packets. When the reassembly timer times out, a status report needs to be generated. At this time, the search starts from the fourth variable (i.e., 6) and moves upwards to find the first incompletely received packet. Since the packet with sequence number 6 was not received, the first incompletely received sequence number greater than or equal to 6 is 6, i.e., the third variable is 6.

[0266] For example, if the second device successfully receives the data packet with serial number 6 during the reassembly timer operation, but the data packet with serial number 8 has not yet arrived, when the status report is generated, the search starts from the fourth variable (i.e., 6) and moves upwards. Serial number 6 has been fully received, but serial number 8 has not been fully received, so the third variable is 8.

[0267] It is understood that the third variable in this application embodiment is similar to "RX_Highest_Status" in the prior art, except that in this application embodiment, the confirmation mode data packet uses an even or odd sequence number. Therefore, the value of the third variable is related to the parity of the sequence number used in the confirmation mode data packet. For example, if the confirmation mode data packet uses an even sequence number, the third variable is even; if the confirmation mode data packet uses an odd sequence number, the third variable is odd. The prior art does not have such a limitation on the value of RX_Highest_Status. Similarities can be found in the relevant descriptions in the prior art, and will not be repeated here. The fourth variable in this application embodiment is similar to "RX_Next_Status_Trigger" in the prior art, and can be found in the relevant descriptions in the prior art, and will not be repeated here.

[0268] Regarding the aforementioned restart condition #1, when the reassembly timer times out, the third variable is updated to the sequence number of the first acknowledgment mode data packet whose current sequence number is greater than or equal to the fourth variable and which has not been fully received. If the first variable is greater than the sum of the third variable and 2 at this time, it indicates that during the timer's operation, the second device received an acknowledgment mode data packet with a sequence number greater than the third variable, causing the first variable to increase further, resulting in a gap between the updated third variable and the first variable. In this case, the reassembly timer needs to be restarted to wait for the data packet corresponding to this gap.

[0269] For example, consider a data packet in acknowledgment mode with an even sequence number (sequence numbers are 0, 2, 4, 6, 8, 10, etc.). When the reassembly timer starts, the second variable is 2, sequence numbers 0 and 4 have been received, the first variable is 6, and the fourth variable is 6. During the timer's operation, a data packet with sequence number 10 arrives and is fully received, at which point the first variable is updated to 12. When the reassembly timer times out, the third variable is updated to the first even sequence number greater than or equal to 6 that has not been fully received, i.e., the third variable is 6. At this time, the first variable (12) > the sum of the third variable and 2 (8), indicating that there is a gap between the third variable (6) and the first variable (12), and the reassembly timer is restarted to restart the timing.

[0270] Regarding the aforementioned restart condition #2, when the reassembly timer times out, the third variable is updated to the sequence number of the first data packet in acknowledgment mode whose current sequence number is greater than or equal to the fourth variable and which has not yet been fully received. If the first variable is exactly equal to the sum of the third variable and 2, it means that the first variable has just reached the sequence number position corresponding to the next acknowledgment mode data packet after the third variable, but the data packet corresponding to the third variable itself has not yet been fully received.

[0271] In this embodiment, when the reassembly timer expires, the second device can determine whether the first variable is greater than the sum of the third variable and 2, or whether the first variable is equal to the sum of the third variable and 2, and whether the data packet corresponding to the third variable has not been fully received, thereby deciding whether to restart the reassembly timer. This method ensures continuous monitoring and reporting of subsequent packet loss in scenarios where multiple consecutive acknowledgment mode data packets are lost, preventing the omission of subsequent packet loss events due to ending monitoring with a single status report.

[0272] In addition, if the reorganization timer times out and the above restart conditions #1 and #2 are not met, the second device will not restart the reorganization timer.

[0273] Optionally, in conjunction with the above embodiments, the method may further include: starting a reassembly timer when the first variable is equal to the sum of the second variable and 2, and the data packet corresponding to the second variable has not been fully received.

[0274] The first and second variables can be referred to in the previous introductions, and will not be repeated here.

[0275] When the first variable equals the sum of the second variable and 2, it indicates that the maximum sequence number of the received acknowledgment mode data packet is exactly equal to the second variable. In other words, the second device expects to receive a next acknowledgment mode data packet, and some data packet chunks have already arrived (i.e., this data packet chunk triggered the update of the first variable), but the data packet has not yet been fully received. In this case, the maximum sequence number received has not exceeded the second variable, so there is no sequence number gap exceeding the second variable. However, the data packet corresponding to the second variable itself is in an incompletely received state, that is, the expected data packet is missing. At this time, a reassembly timer is started to wait for the remaining chunks of the data packet corresponding to the second variable.

[0276] By using the above method, when the maximum sequence number received has not exceeded the expected reception position, but some segments of the expected data packet have arrived but have not been fully received, the reassembly timer can be started in time to reserve waiting time for receiving the remaining segments of the data packet, thereby ensuring the reliability of data transmission.

[0277] Furthermore, the above method may also include: when the resetting timer is enabled, pausing the resetting timer when the stop condition is met, and performing a reset operation on the resetting timer.

[0278] The above stopping conditions include at least one of the following: the second variable is equal to the fourth variable (denoted as stopping condition #1), the fourth variable is outside the receiving window (denoted as stopping condition #2), the fourth variable is equal to the sum of the second variable and 2, and the data packet corresponding to the second variable has been completely received (denoted as stopping condition #3).

[0279] The second and fourth variables can be referred to in the previous introductions, and will not be repeated here.

[0280] For stop condition #1, the second variable equaling the fourth variable indicates that the bottom edge of the receive window has advanced to the reference position recorded when the reassembly timer started, i.e., the value of the first variable when the reassembly timer started. Since the second variable indicates the sequence number of the next acknowledgment mode data packet to be received, when the second variable slides to the fourth variable, it means that all data packets before the gap that existed when the reassembly timer started have been received in order and completely, the gap has been eliminated, and the reassembly timer is stopped at this time.

[0281] For example, consider acknowledgment mode data packets using even-numbered sequence numbers (sequence numbers are 0, 2, 4, 6, 8, 10, etc.). Assume that when the reassembly timer starts, the second variable is 2, sequence numbers 0 and 4 have been received, but sequence number 2 has not been received. The first variable is 6, the reassembly timer starts, and the fourth variable is 6. During the reassembly timer's operation, the data packet with sequence number 2 arrives and is successfully reassembled, and the second variable slides to 4; the data packet with sequence number 4 has been buffered, and the second variable slides to 6. At this point, the second variable is exactly equal to the fourth variable, indicating that all acknowledgment mode data packets before the fourth variable have been received in order, the gap has been eliminated, and the reassembly timer stops.

[0282] Regarding stop condition #2, the fourth variable being outside the sending window can be understood as: the fourth variable being greater than the sum of the second variable and the receiving window length. This indicates that the reference position recorded when the reassembly timer started has exceeded the valid range of the current receiving window. When the fourth variable exceeds this range, it is meaningless to continue waiting for the data packet corresponding to that reference position, and the reassembly timer is stopped at this point.

[0283] For stop condition #3, the fourth variable equals the sum of the second variable and 2, and the data packet corresponding to the second variable has been completely received. This means that the reference position when the reassembly timer starts is exactly one position after the lower edge of the receiving window, and the data packet corresponding to that position has been successfully received. In this case, the gap that the reassembly timer was concerned with when it started has been filled, and the data packet corresponding to the lower edge of the receiving window itself has also been completely received. At this point, the reassembly timer stops.

[0284] In this embodiment, the reassembly timer is stopped by the advancement of the receive window. As acknowledgment mode data packets are gradually received and assembled, the second variable slides forward. When the above-mentioned stopping condition is met, it indicates that the gap that the reassembly timer was concerned with when it was started has been filled. At this time, the reassembly timer is stopped and reset.

[0285] The second device can make corresponding judgments based on the status of the reassembly timer after each data packet is assembled. For example, when the reassembly timer is running (i.e., enabled), it can determine whether the above-mentioned stop conditions are met. If the stop conditions are met, the reassembly timer can be paused and a reset operation can be performed on the reassembly timer.

[0286] In this way, the second device can stop the reassembly timer in a timely manner, thereby releasing the timer resources promptly and avoiding continuous equipment overhead caused by the reassembly timer waiting for invalid timeouts. Furthermore, by actively determining the aforementioned stopping conditions, in cases where a packet loss event has been actually resolved (e.g., the receive window has moved forward past the packet, or the packet has arrived completely within the timeout period), redundant status reports for resolved events can be avoided after a timeout, thus reducing unnecessary uplink signaling overhead.

[0287] Furthermore, if the second device determines that the aforementioned stopping conditions are not met, it may not operate the running reassembly timer. When the reassembly timer times out, the second device may send a status report to the first device. For the timeout handling after the reassembly timer is started (including whether the restart conditions are met, whether to send a status report, etc.), please refer to the relevant descriptions in the foregoing embodiments, which will not be repeated here.

[0288] As can be understood, the above content describes the different operations when the recombination timer is in different states. When there is a gap in the received even-numbered sequence number and the recombination timer times out, the second device can generate a status report based on the second and third variables.

[0289] For example, taking the case where acknowledgment mode data packets use even sequence numbers and unacknowledgment mode data packets use odd sequence numbers, for even sequence numbers greater than or equal to the second variable and less than the third variable, the sequence number of the data packets within that even sequence number that have not been fully received is obtained (denoted as sequence number #1). This sequence number #1 is used to indicate data packets in acknowledgment mode that were not successfully received; this sequence number #1 can be set in the negative acknowledgment field of the status report. Furthermore, the second device can set the value of ACK_SN to the value of the third variable. Additionally, for odd sequence numbers greater than or equal to the second variable and less than the third variable, the second device can delete the data packets corresponding to that odd sequence number that have not been fully received.

[0290] If the acknowledgment mode uses an odd sequence number, then similarly, for odd sequence numbers that are greater than or equal to the second variable and less than the third variable, the sequence number of the acknowledgment mode data packet that has not yet been fully received is obtained as a negative acknowledgment, and ACK_SN is set to the third variable; for even sequence numbers within this range, the data packets that have not yet been fully received in the non-acknowledgment mode are deleted.

[0291] In this embodiment, when the second device includes an RLC entity, the implementation of this embodiment can be performed by that RLC entity. In this case, the aforementioned data packet can be understood as an RLC PDU or RLC SDU (see below for details). Figures 5 to 9 (Related information).

[0292] As you can understand, the above content provides an overall overview of the data transmission methods on the receiving end. For ease of understanding, the following section will combine... Figures 5-9 Taking the example of data packets using even sequence numbers in acknowledged mode and data packets using odd sequence numbers in unacknowledged mode, the above data transmission method is introduced through a complete process.

[0293] Upon receiving an RLC PDU, the RLC entity first determines whether the RLC PDU should be placed in the receive buffer. After placing the RLC PDU in the receive buffer, it updates RX_Next_Highest and checks whether the corresponding RLC SDU can be assembled. After assembling the RLC SDU, it determines whether to operate on the reassembly timer based on its current state. When the reassembly timer times out, the RLC entity triggers the generation of a status report and sends this report to the first device (the transmitting device). This will be described in detail below.

[0294] like Figure 5 As shown, the RLC entity operates as follows upon receiving an RLC PDU: S501, the RLC entity receives an RLC PDU from the MAC layer.

[0295] The RLC entity corresponds to the RLC entity of the second device in the aforementioned embodiments.

[0296] The RLC PDU contains the yz bytes of the RLC SDU with sequence number x.

[0297] S502, the RLC entity determines whether x is within the receiving window.

[0298] That is, the RLC entity determines whether x is greater than or equal to RX_Next, and less than the sum of RX_Next and Window_Size (RX_Next ≤ x). <RX_Next + Window_Size)。

[0299] RX_Next corresponds to the bottom edge of the receiving window in the aforementioned embodiment (i.e., the aforementioned second variable), and Window_Size corresponds to the window length of the receiving window in the aforementioned embodiment. The initial value of RX_Next is 0.

[0300] If x is within the receiving window, then execute S503 below; if x is outside the receiving window, then discard the above RLC PDU.

[0301] S503, the RLC entity determines whether the yz byte of the RLC SDU with sequence number x has been received.

[0302] If the yz byte of the RLC SDU with sequence number x is not received, then execute S504 below; if the yz byte of the RLC SDU with sequence number x has been received, then discard the above RLC PDU.

[0303] S504, RLC entity determines whether x is even.

[0304] If x is even, then execute S505 below. If x is not even, then execute S507 below.

[0305] S505, RLC entity determines whether x is greater than or equal to RX_Next_Highest.

[0306] RX_Next_Highest corresponds to the first variable in the aforementioned embodiment. The initial value of RX_Next_Highest is 0.

[0307] If x is greater than or equal to RX_Next_Highest, then execute S506 below.

[0308] It is understood that in this embodiment, since RX_Next_Highest is always even (the acknowledgment mode data packet uses an even sequence number), and odd sequence numbers are numerically smaller than the corresponding even sequence numbers (in the absence of sequence number wrapping), S504 can be skipped and S505 can be executed directly. In this case, the data packet corresponding to the odd sequence number will not enter the update process of S506.

[0309] S506, RLC entity update RX_Next_Highest.

[0310] The RLC entity adds 2 to x to obtain the updated RX_Next_Highest. The updated RX_Next_Highest is the sum of x and 2, that is, RX_Next_Highest = x + 2, where "=" indicates assignment.

[0311] like Figure 6 As shown, when an RLC entity assembles an RLC SDU, it can determine whether to update RX_Next and RX_Highest_Status (described below) by combining the sequence number of the assembled RLC SDU. The specific operation is as follows: S601: After receiving all bytes of all RLC SDUs with sequence number x, assemble all RLCPDUs with sequence number x, remove the header, and send the assembled RLC SDU and sequence number x to the PDCP layer.

[0312] After the RLC SDU is assembled, execute S602.

[0313] S602, RLC entity determines whether x is even.

[0314] If x is even, then execute S603 below.

[0315] S603, RLC entity determines whether x is equal to RX_Next.

[0316] If x equals RX_Next, then execute S604.

[0317] S604, the RLC entity updates RX_Next to the sequence number of the first acknowledgment mode RLC SDU whose sequence number is greater than the current RX_Next and has not been fully received.

[0318] The serial number of the RLC SDU mentioned above is an even serial number.

[0319] S605, RLC entity determines whether x is equal to RX_Highest_Status.

[0320] RX_Highest_Status corresponds to the third variable in the aforementioned embodiment. The initial value of RX_Highest_Status is 0.

[0321] If x equals RX_Highest_Status, then execute S606 below.

[0322] S606, the RLC entity updates RX_Highest_Status to the sequence number of the RLC SDU in the first acknowledgment mode that has not been fully received and whose sequence number is greater than the current RX_Highest_Status.

[0323] The serial number of the RLC SDU mentioned above is an even serial number.

[0324] It is understandable that after assembling the RLC SDU, the RLC entity can sequentially determine whether to update RX_Next and RX_Highest_Status (as in S602-S606), or simultaneously determine whether to update RX_Next and RX_Highest_Status. When the RLC entity simultaneously determines whether to update RX_Next and RX_Highest_Status, it can first check whether x is even. If x is even, then it can simultaneously determine whether to update RX_Next and RX_Highest_Status.

[0325] The RLC entity performs the above-mentioned actions. Figure 6 After the operations shown, the corresponding operations can be performed on the re-reset timer based on its current state. For example, when the re-reset timer is not running, the RLC entity can determine whether to start the re-reset timer based on the start condition; or, when the re-reset timer is running, the RLC entity can determine whether to stop the re-reset timer based on the stop condition. The following section will combine... Figure 7 and Figure 8 This section will introduce these two different scenarios.

[0326] like Figure 7 As shown, the RLC entity operates as follows when the recombination timer is not running: S701, when the recombination timer is not running, the RLC entity determines whether the recombination timer meets the start conditions.

[0327] The activation conditions include at least one of the following: RX_Next_Highest is greater than the sum of RX_Next and 2 (i.e., RX_Next_Highest > RX_Next + 2); RX_Next_Highest equals the sum of RX_Next and 2 (i.e., RX_Next_Highest = RX_Next + 2), and the RLC SDU corresponding to RX_Next was not fully received.

[0328] If RX_Next_Highest is greater than the sum of RX_Next and 2, it can indicate that there is a gap in the received even-numbered sequence number.

[0329] If the reset timer meets the start condition, then execute S702. If the reset timer does not meet the start condition, then no operation is performed on the reset timer.

[0330] S702, the RLC entity starts the reorganization timer and updates RX_Next_Status_Trigger.

[0331] RX_Next_Status_Trigger corresponds to the fourth variable in the aforementioned embodiment. The initial value of RX_Next_Status_Trigger is 0.

[0332] The RLC entity updates the value of RX_Next_Status_Trigger to the current value of RX_Next_Highest, that is, RX_Next_Status_Trigger = RX_Next_Highest at this time.

[0333] like Figure 8 As shown, the RLC entity operates as follows while the recombination timer is running: S801, while the recombination timer is running, the RLC entity determines whether the recombination timer meets the stop condition.

[0334] The stopping conditions include at least one of the following: RX_Next equals RX_Next_Status_Trigger (corresponding to stop condition #1 in the previous embodiment, i.e., RX_Next = RX_Next_Status_Trigger). RX_Next_Status_Trigger is located outside the receiving window (corresponding to stop condition #2 in the aforementioned embodiment, i.e., RX_Next_Status_Trigger > RX_Next + Window_Size). RX_Next_Status_Trigger is equal to the sum of RX_Next and 2 (i.e., RX_Next_Status_Trigger = RX_Next + 2), and the RLC SDU corresponding to RX_Next has been fully received (corresponding to stop condition #3 in the aforementioned embodiment).

[0335] If the reset timer meets the stop condition, then execute S802. If the reset timer does not meet the stop condition, then no operation is performed on the reset timer.

[0336] S802, the RLC entity stops the resetting timer and performs a reset operation on the resetting timer.

[0337] like Figure 9 As shown, when the reorganization timer times out, the RLC entity generates a status report and determines whether to restart the reorganization timer. The specific operation is as follows: S901, when the reorganization timer times out, the RLC entity updates RX_Highest_Status.

[0338] That is, the RLC entity updates RX_Highest_Status to the sequence number of the first RLC SDU in the acknowledged mode whose sequence number is greater than or equal to RX_Next_Status_Trigger, and the RLC SDU is not completely received.

[0339] The sequence number of the above RLC SDU is an even number.

[0340] In S902, the RLC entity constructs a status report based on the updated RX_Highest_Status.

[0341] The RLC entity may set the value of ACK_SN in the status report to the current value of RX_Highest_Status. The ACK_SN is the sequence number corresponding to the next not-yet-received data packet in the acknowledged mode that is not marked as lost in the status report. In addition, the RLC entity may report RLC SDUs whose even sequence numbers (SN_AM) satisfy RX_Next ≤ SN_AM < RX_Highest_Status and have not been completely received, in ascending order of the sequence numbers.

[0342] In addition, the RLC entity may delete RLC SDUs whose odd sequence numbers (SN_UM) satisfy RX_Next ≤ SN_UM < RX_Highest_Status and have not been completely received. That is, when generating the status report, since unacknowledged mode data packets do not need to be retransmitted, it is meaningless to continue waiting for unacknowledged mode data packets that have exceeded the valid reception range (i.e., located between RX_Next and RX_Highest_Status) and have not been completely received, and directly deleting these RLC SDUs can release the reception buffer.

[0343] In S903, the RLC entity determines whether a reassembly timer satisfies a restart condition.

[0344] The restart condition includes at least one of the following: RX_Next_Highest is greater than the sum of RX_Highest_Status and 2 (corresponding to the restart condition #1 in the foregoing embodiment, that is, RX_Next_Highest>RX_Highest_Status +2); RX_Next_Highest is equal to the sum of RX_Highest_Status and 2 (that is, RX_Next_Highest= RX_Highest_Status +2), and the RLC SDU corresponding to RX_Highest_Status is not completely received (corresponding to the restart condition #2 in the foregoing embodiment).

[0345] If the reorganization timer meets the restart conditions, then execute S904; if the reorganization timer does not meet the restart conditions, then execute S905.

[0346] S904, RLC entity restarts reorganization timer.

[0347] S905, the RLC entity performs a reset operation on the recombination timer.

[0348] It is understandable that the above Figures 5-9 For a detailed implementation, please refer to the relevant descriptions in the foregoing embodiments, which will not be repeated here.

[0349] In addition, the above Figures 5-9 This section describes the operation of the receiving device (i.e., the RLC entity of the second device) when even sequence numbers are used for data packets in acknowledged mode and odd sequence numbers are used for data packets in unacknowledged mode. When the opposite convention is adopted (i.e., odd sequence numbers are used in acknowledged mode and even sequence numbers in unacknowledged mode), the initial values ​​of RX_Next, RX_Next_Highest, RX_Highest_Status, and RX_Next_Status_Trigger can be set to 1. Other operations are the same as described above. Figures 5-9 The operation is similar; you can refer to the above. Figures 5-9 For a more detailed understanding, please refer to the relevant introduction; further details will not be provided here.

[0350] The above combination Figures 3-9 The operation of the first device (sender device) and the second device (receiver device) in unified mode has been introduced. The following example, using even sequence numbers for data packets in acknowledged mode and odd sequence numbers for data packets in unacknowledged mode, illustrates the above method. Table 1 shows the mixed-type data transmission process of the first device.

[0351] Table 1

[0352] In Table 1 above, "packet number" refers to the packet number of the data packet. "Type" refers to the transmission mode, i.e., acknowledged mode (AM) or unacknowledged mode (UM). "TX_Next_Ack" is the bottom edge of the sending window; its initial value is 0. "TX_Next_UM" corresponds to the second parameter in the aforementioned embodiment, i.e., the count value associated with the next data packet to be allocated in unacknowledged mode; its initial value is 1. "Whether synchronization is triggered" can be understood as whether the value of "TX_Next_UM" is incremented to the first odd-numbered position after the bottom edge of the current window. "Assigned sequence number" can be understood as the sequence number assigned to the data packet. "Send counter update" can be understood as updating "TX_Next_AM" when sending data packets in acknowledged mode, where "TX_Next_AM" corresponds to the first parameter in the aforementioned embodiment and its initial value is 0; and updating "TX_Next_UM" when sending data packets in unacknowledged mode. "Feedback event" can be understood as the event related to the status report received from the second device. The window length for both the sending and receiving windows is 16. Furthermore, for ease of understanding, in this embodiment of the application, the count value (COUNT) of the PDCP layer is the same as the sequence number (SN) of the RLC layer, that is, the hyperframe number (HFN) is 0.

[0353] As shown in Table 1, the first device sends 10 data packets (i.e., #1-#10 in Table 1, denoted as data packet #1-data packet #10). For data packet #1, this data packet is in acknowledgment mode. At this time, TX_Next_Ack is 0, and the sequence number (SN#1) of data packet #1 can be obtained through TX_Next_Ack, such as SN#1 = TX_Next_AM mod 2. [sn-FieldLength -1] =0. Based on the current TX_Next_Ack, update the value of TX_Next_Ack to 2. The process of assigning sequence numbers to packets #2 through #10 is similar to the process of assigning a sequence number to packet #1; you can refer to the relevant introduction on assigning a sequence number to packet #1 for understanding.

[0354] During the transmission of 10 data packets by the first device, the first device received 3 status reports from the second device. The first status report received from the second device indicated that data packets with sequence numbers 0, 2, and 4 had been successfully transmitted. At this time, the first device updated TX_Next_Ack to 6. When assigning a sequence number to data packet #5, because data packet #5 was in unacknowledged mode and the current value of TX_Next_UM (3) was less than the current value of TX_Next_Ack (6), the first forced synchronization was performed, updating the value of TX_Next_UM to the sum of the current TX_Next_Ack and 1 (i.e., 7). The sequence number assigned to data packet #5 at this time was 7. After using the updated TX_Next_UM, TX_Next_UM was updated again, i.e., the value of the updated TX_Next_UM was 9. The "Second Forced Synchronization" in Table 1 can be understood by referring to this content, and will not be elaborated here.

[0355] For the first device, both synchronizations occur on packets in unacknowledged mode, and each time the lagging TX_Next_UM is moved directly to the first odd-numbered position after the lower edge of the current window. This eliminates the risk of packets in unacknowledged mode being dropped because their sequence numbers fall outside the sending window. In addition, all even-numbered sequence numbers (0, 2, 4, 6, 8, 10) are used for packets in acknowledged mode, ensuring that there are always clean even-numbered tracks available for retransmission and new transmission of packets in acknowledged mode.

[0356] Suppose that the data packet with sequence number 7 in unacknowledged mode is lost during transmission, meaning the second device did not receive the data packet with sequence number 7 in unacknowledged mode. Since the sequence number of this data packet is odd, the second device will not update any variables based on this sequence number.

[0357] Suppose that data packet with sequence number 10 in acknowledgment mode is lost during transmission, meaning the second device did not receive data packet with sequence number 10 in acknowledgment mode. In this case, the first device sends data packets with sequence numbers 10, 11, and 12; the second device actually receives data packets with sequence numbers 11 and 12. Among them, data packets with sequence numbers 10 and 12 are data packets in acknowledgment mode; data packet with sequence number 11 is a data packet in unacknowledgment mode; data packet with sequence number 12 is a subsequent data packet sent by the first device, which demonstrates the packet loss in acknowledgment mode, assuming there are data packets after data packet #9.

[0358] For the second device, let's assume the current state is: RX_Next=10,RX_Next_Highest=10,RX_Highest_Status=10.

[0359] When the second device receives the data packet with sequence number 11, RX_Next remains at 10 (odd and even numbers are not on the same track, and non-acknowledgment mode data packets cannot fill the gaps in acknowledgment mode data packets). After receiving the data packet with sequence number 12, RX_Next_Highest is updated, and RX_Next remains at 10. At this time, RX_Next_Highest = 10, RX_Highest_Status = 10.

[0360] When the second device receives the data packet with sequence number 12, RX_Next = 10, RX_Next_Highest = 12 + 2 = 14, and RX_Highest_Status = 10. Since RX_Next_Highest > RX_Next + 2, the reassembly timer t-Reassembly will start, and RX_Next_Status_Trigger = RX_Next_Highest = 14.

[0361] When the reassembly timer t-Reassembly times out, RX_Highest_Status is updated to 14. Since RX_Next_Highest = RX_Highest_Status, and the RLC SDU corresponding to sequence number 14 has been fully received, the reassembly timer t-Reassembly will not restart.

[0362] The second device constructs a status report and sends it to the first device. This status report includes an ACK_SN and an unacknowledged even-numbered sequence number, 10. The ACK_SN is set to 14.

[0363] After receiving the status report, the first device implicitly triggers the retransmission of the data packet with sequence number 10. The specific implementation of the first device retransmitting the data packet can refer to existing technologies, and will not be elaborated here.

[0364] It is understood that in the above embodiments, "data packet transmitted in acknowledgment mode," "data packet in acknowledgment mode," "data packet in acknowledgment mode," and "data packet in acknowledgment mode" are synonyms, representing the same concept, and can be used interchangeably. Similarly, the terms "data packet in non-acknowledgment mode," "data packet in non-acknowledgment mode," and "data packet in non-acknowledgment mode" are also synonyms, representing the same concept, and can be used interchangeably. "Not fully received," "not completely received," "not all bytes received," and "not completely received" all indicate that all segments of the RLC SDU (i.e., all bytes corresponding to the RLC SDU) have not been fully received, and can be used interchangeably. "Sequence number of data packet" and "sequence number corresponding to data packet" are synonyms, representing the same concept, and can be used interchangeably.

[0365] It should be understood that Figures 3 to 9 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 3 to 9 The examples in the document can be transformed into equivalent ways to obtain more implementations.

[0366] The above text combined Figures 3 to 9 This document describes in detail the data transmission method provided in the embodiments of this application. The following will combine [the description with...] Figures 10 to 11 The apparatus embodiments of this application are described in detail below. It should be understood that the data transmission apparatus of this application embodiments can execute the various data transmission 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.

[0367] 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.

[0368] Figure 10 This is a schematic block diagram of a data transmission apparatus provided in an embodiment of this application. Figure 10 As shown, the data transmission device 1000 may include a communication module 1020. The communication module 1020 can implement corresponding communication functions, which can be internal communication functions of the data transmission device 1000 or communication functions between the data transmission device 1000 and other devices. Optionally, the communication module 1020 may also be referred to as a communication interface or a transceiver module. Optionally, the data transmission device 1000 further includes a processing module 1010. The processing module 1010 can implement corresponding processing functions.

[0369] Optionally, the data transmission device 1000 further includes a storage module, which can be used to store instructions and / or data; the processing module 1010 can read the instructions and / or data in the storage module so that the data transmission device 1000 can implement the aforementioned method embodiment.

[0370] In one possible design, the data transmission device 1000 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 data transmission device 1000 may be used to perform the steps or processes performed by the first device in any of the above method embodiments.

[0371] For example, the processing module 1010 is used to obtain a first sequence number corresponding to the first data packet based on the transmission mode of the first data packet, wherein the transmission mode is an acknowledged mode or an unacknowledged mode, and the first sequence number is used to identify the first data packet; in the acknowledged mode, after the first device sends the data packet, it buffers the data packet and determines whether to retransmit the data packet based on the information fed back by the second device to indicate the lost data packet; in the unacknowledged mode, the first device does not retransmit the lost data packet after sending the data packet; wherein, when the first data packet corresponds to the acknowledged mode, the first sequence number is even, and when the first data packet corresponds to the unacknowledged mode, the first sequence number is odd; or, when the first data packet corresponds to the acknowledged mode, the first sequence number is odd, and when the first data packet corresponds to the unacknowledged mode, the first sequence number is even; when the first data packet corresponds to the acknowledged mode and the first data packet is not the first data packet in the acknowledged mode, the difference between the first sequence number and the second sequence number is 2, and the second sequence number is the sequence number corresponding to the data packet transmitted in the previous acknowledged mode.

[0372] The communication module 1020 is used to send a second data packet based on the first data packet and the first sequence number, provided that the first sequence number is within the sending window. The second data packet carries the first sequence number.

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

[0374] In one possible design, the data transmission device 1000 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 data transmission device 1000 may be used to perform the steps or processes performed by the second device in any of the above method embodiments.

[0375] For example, the communication module 1020 is used to send a status report when there is a gap in the received even sequence number if the sequence number of the data packet in the acknowledged mode is even and the sequence number of the data packet in the unacknowledged mode is odd; or, when the sequence number of the data packet in the acknowledged mode is odd and the sequence number of the data packet in the unacknowledged mode is even, it sends a status report when there is a gap in the received odd sequence number; wherein the status report is used to indicate the data packets that have not been received in the acknowledged mode and the data packets that have been received in the acknowledged mode.

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

[0377] Figure 11 This is another schematic block diagram of the data transmission device 1100 provided in this application embodiment. The data transmission device 1100 may be a chip, chip system, or processor, etc., that implements the above-described method in a first or second device. The data transmission device 1100 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.

[0378] like Figure 11 As shown, the data transmission device 1100 may include one or more processors 1110, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 1110 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 data transmission device 1100 (e.g., a base station, baseband chip, user, user chip), execute software programs, and process data from the software programs.

[0379] In an alternative design, the processor 1110 may also store instructions and / or data that can be executed by the processor 1110 to cause the data transmission device 1100 to perform the method described in the above method embodiments.

[0380] In another alternative design, the data transmission device 1100 may include a communication interface 1120 for implementing receiving and transmitting functions. For example, the communication interface 1120 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.

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

[0382] 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.

[0383] In one implementation, the data transmission device 1100 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 1110 may be used to execute instructions stored in the memory 1130, and when the processor 1110 executes the instructions stored in the memory, the processor 1110 is used to execute the various steps and / or processes of the above method embodiments corresponding to the first device.

[0384] In another implementation, the data transmission device 1100 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 1110 may be used to execute instructions stored in the memory 1130, and when the processor 1110 executes the instructions stored in the memory, the processor 1110 is used to execute the various steps and / or processes of the above method embodiments corresponding to the second device.

[0385] 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.

[0386] 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.

[0387] 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.

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

[0389] 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.

[0390] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: a computer program or instructions, which, when the computer program or instructions are run, cause 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.

[0391] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing a computer program that, 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.

[0392] 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.

[0393] 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.

[0394] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in 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.

[0395] 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.

[0396] 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.

[0397] 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 data transmission method, characterized in that, Applied to a first device, the method includes: Based on the transmission mode of the first data packet, the first sequence number corresponding to the first data packet is obtained, wherein the transmission mode is an acknowledged mode or an unacknowledged mode; the first sequence number is used to identify the first data packet; in the acknowledged mode, after the first device sends the data packet, it buffers the data packet and determines whether to retransmit the data packet based on the information fed back by the second device to indicate the lost data packet; in the unacknowledged mode, after the first device sends the data packet, it does not retransmit the lost data packet. If the first sequence number is within the sending window, a second data packet is sent based on the first data packet and the first sequence number, the second data packet carrying the first sequence number; Wherein, when the first data packet corresponds to the confirmation mode, the first sequence number is even, and when the first data packet corresponds to the non-confirmation mode, the first sequence number is odd; or, when the first data packet corresponds to the confirmation mode, the first sequence number is odd, and when the first data packet corresponds to the non-confirmation mode, the first sequence number is even. When the first data packet corresponds to the acknowledgment mode and the first data packet is not the first data packet in the acknowledgment mode, the difference between the first sequence number and the second sequence number is 2, and the second sequence number is the sequence number corresponding to the data packet transmitted in the previous acknowledgment mode.

2. The method according to claim 1, characterized in that, The transmission mode is the confirmation mode. The transmission mode based on the first data packet, obtaining the first sequence number corresponding to the first data packet, includes: Based on the transmission mode corresponding to the first data packet, a first parameter under the confirmation mode is obtained, wherein the first parameter is the count value of the next data packet to be associated in the confirmation mode; Based on the first parameter, obtain the first serial number.

3. The method according to claim 2, characterized in that, Based on the first parameter, the expression for obtaining the first sequence number is: SN_AM = TX_Next_AM mod 2 [sn-FieldLength -1] Wherein, SN_AM is the first sequence number, TX_Next_AM is the first parameter, and sn-FieldLength is the preset sequence number length.

4. The method according to claim 2, characterized in that, After obtaining the first serial number based on the first parameter, the method further includes: Update the first parameter. The updated first parameter is the sum of the first parameter and 2.

5. The method according to claim 1, characterized in that, The transmission mode is the unacknowledged mode, and the transmission mode based on the first data packet, obtaining the first sequence number corresponding to the first data packet, includes: Based on the transmission mode corresponding to the first data packet, a second parameter is obtained under the unconfirmed mode, wherein the second parameter is the count value of the next data packet to be associated in the unconfirmed mode; If the second parameter is less than the first window count value, the second parameter is updated. The updated second parameter is located within the count interval corresponding to the sending window. The first window count value is the count value corresponding to the lower edge value of the first window. The lower edge value of the first window is the value of the lower edge of the sending window. Based on the updated second parameter, the first serial number is obtained.

6. The method according to claim 5, characterized in that, The updated second parameter is the sum of the first window count value and 1.

7. The method according to claim 5 or 6, characterized in that, Based on the updated second parameter, the expression for obtaining the first sequence number is: SN_UM = TX_Next_UM mod 2 [sn-FieldLength -1] Wherein, SN_UM is the first sequence number, TX_Next_UM is the updated second parameter, and sn-FieldLength is the preset sequence number length.

8. The method according to claim 5 or 6, characterized in that, After obtaining the first serial number based on the updated second parameter, the method further includes: The updated second parameter is then updated again, and the updated second parameter is the sum of the updated second parameter and 2.

9. The method according to claim 5, characterized in that, The method further includes: If the second parameter is greater than or equal to the first window count value, the first sequence number is obtained based on the second parameter.

10. The method according to claim 1, characterized in that, The method further includes: Receive a status report from the second device, the status report being used to indicate data packets in the acknowledgment mode that the second device has not received, and data packets in the acknowledgment mode that the second device has received; Based on the minimum sequence number in the confirmation mode that failed to transmit in the status report, update the lower edge value of the first window. The lower edge value of the first window is the value of the lower edge of the sending window, and the updated lower edge value of the first window is the minimum sequence number.

11. A data transmission method, characterized in that, Applied to a second device, the method includes: In acknowledged mode, if the sequence number of a data packet is even, and in unacknowledged mode, if the sequence number of a data packet is odd, a status report is sent if there is a gap in the received even-numbered sequence number; or, In the case where the sequence number of the data packet in the acknowledged mode is odd and the sequence number of the data packet in the unacknowledged mode is even, a status report is sent when there is a gap in the received odd sequence number. The status report is used to indicate data packets that have not been received in the acknowledgment mode and data packets that have been received in the acknowledgment mode.

12. The method according to claim 11, characterized in that, When there is a gap in the received even-numbered sequence number, sending a status report includes: When a gap exists in the received even-numbered sequence number and the recombination timer times out, the status report is sent. The recombination timer is used to start timing when it is determined that a gap exists in the received even-numbered sequence number.

13. The method according to claim 12, characterized in that, The method further includes: Based on the fact that the first variable is greater than the sum of the second variable and 2, it is determined that there is a gap in the received even sequence number. The first variable is used to indicate the upper bound of the received data packet sequence number in the acknowledgment mode, and the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window.

14. The method according to claim 11, characterized in that, When there is a gap in the received odd sequence number, sending a status report includes: When a gap exists in the received odd sequence number and the reassembly timer times out, the status report is sent. The reassembly timer is used to start timing when it is determined that a gap exists in the received odd sequence number.

15. The method according to claim 14, characterized in that, The method further includes: Based on the fact that the first variable is greater than the sum of the second variable and 2, it is determined that there is a gap in the received odd sequence number. The first variable is used to indicate the upper bound of the received data packet sequence number in the acknowledgment mode, and the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window.

16. The method according to any one of claims 12-15, characterized in that, The method further includes: If the restart condition is met when the recombination timer times out, the recombination timer is restarted. The restart conditions include at least one of the following: the first variable is greater than the sum of the third variable and 2, the first variable is equal to the sum of the third variable and 2, and the data packet corresponding to the third variable has not been fully received; the first variable is used to indicate the upper bound of the sequence number of the data packet in the acknowledgment mode that has been received, the third variable is the sequence number of the first data packet in the acknowledgment mode whose sequence number is greater than or equal to the fourth variable and has not been fully received when the status report is triggered, and the fourth variable is the first variable when the reassembly timer is started.

17. The method according to any one of claims 12-15, characterized in that, The method further includes: The reassembly timer is started when the first variable equals the sum of the second variable and 2, and the data packet corresponding to the second variable has not been fully received.

18. The method according to claim 17, characterized in that, The method further includes: When the recombination timer is enabled, if the stop condition is met, the recombination timer is paused and a reset operation is performed on the recombination timer. The stopping conditions include at least one of the following: the second variable is equal to the fourth variable, the fourth variable is outside the receiving window, the fourth variable is equal to the sum of the second variable and 2, and the data packet corresponding to the second variable has been completely received; the second variable is used to indicate the sequence number corresponding to the lower edge of the receiving window, and the fourth variable is the first variable when the reassembly timer is started.

19. A data transmission device, characterized in that, The apparatus includes a module for performing the method as described in any one of claims 1 to 18.

20. A data transmission device, characterized in that, 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 18.

21. A chip system, characterized in that, 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 18 is performed.

22. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are run on a computer, the computer causes the computer to perform the method as described in any one of claims 1 to 18.

23. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed, cause the method of any one of claims 1 to 18 to be performed.

Images