A data transmission method and device

Abstract

This application provides a data transmission method and apparatus. The method is applied to a network device, specifically: the Packet Data Convergence Protocol (PDCP) layer receives a packet loss notification message from the Media Access Control (MAC) layer, containing a packet identifier and a transmission status identifier. When the transmission status identifier indicates a residual packet loss acknowledgment state, a corresponding first sequence number is determined based on the packet identifier. A data delivery range is determined based on this first sequence number, and the currently running reordering timer is stopped. The cached consecutive data packets within this data delivery range are then delivered to the upper layer. The technical solution provided by this application can directly stop the reordering timer and promptly deliver the cached consecutive data packets to the upper layer according to the determined delivery range when a residual packet loss acknowledgment state is detected, instead of waiting for the reordering timer to time out as required by the PDCP layer protocol. This effectively shortens the data delivery delay and reduces the time data packets remain in the cache, thus reducing cache occupancy pressure.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data transmission method and device. Background Technology

[0002] 5G New Radio (NR) systems have extremely high requirements for data transmission latency and reliability. The reordering function of the Packet Data Convergence Protocol (PDCP) is a key mechanism to ensure that data is delivered in order and to support real-time service transmission. PDCP's Unacknowledged Mode (UM) is widely used in latency-sensitive service scenarios due to its low transmission overhead and simple process. The performance of its reordering mechanism directly affects the service experience.

[0003] The existing PDCP UM mode, based on the 3GPP protocol specification, uses a reordering timer to control the timing of data delivery. When the data sequence numbers are not consecutive, it buffers received data packets and starts a timer, only delivering data to the upper layer after the timer expires. This mode lacks retransmission guarantees at the Radio Link Control (RLC) layer, relying solely on the Hybrid Automatic Repeat reQuest (HARQ) retransmission mechanism at the Media Access Control (MAC) layer to ensure reliability. Irreversible packet loss occurs after the maximum number of retransmissions.

[0004] In existing solutions, the reordering timer duration is difficult to configure reasonably. An excessively long duration leads to buffer backlog after packet loss, high memory usage, and a significant increase in transmission latency. Conversely, an excessively short duration can easily cause buffer overflow, resulting in additional packet loss. Furthermore, the PDCP layer cannot detect the underlying HARQ retransmission status and deterministic packet loss events. Even if data packets are lost, the layer still needs to wait for the timer to expire before delivering the data, further exacerbating latency and resource waste, making it difficult to meet the low-latency requirements of 5G real-time services. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a data transmission method and apparatus.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a data transmission method, the method comprising: The Packet Data Convergence Protocol (PDCP) layer receives a packet loss notification message from the Media Access Control (MAC) layer. The packet loss notification message includes a packet identifier and a transmission status identifier. When the transmission status indicator indicates a residual packet loss confirmation status, a first sequence number corresponding to the packet identifier is determined according to the packet identifier, and a data delivery range is determined based on the first sequence number; Stop the currently running reordering timer and submit the cached consecutive data packets within the data submission range to the upper layer.

[0007] In one possible implementation, the method further includes: When the transmission status identifier indicates an initial transmission error warning state, the first sequence number corresponding to the data packet identifier is marked, and the continuity of data packets with the sequence number after the first sequence number is monitored.

[0008] In one possible implementation, monitoring the continuity of data packets following the first sequence number includes: If a non-contiguous sequence number is detected after the first sequence number, the marked sequence number is recorded as the first lost sequence number, and the first lost sequence number is associated with and stored with the identifier in the packet loss notification message. If consecutive serial numbers are detected after the first serial number, the mark on the first serial number is cleared.

[0009] In one possible implementation, after submitting the cached consecutive data packets within the data submission range to the upper layer, the method further includes: Update the receive status variables corresponding to the reordering window to complete the adjustment of the reordering window; wherein, the receive status variables include the starting count value RX_DELIV of the data packets to be delivered, the upper boundary count value RX_REORD of the reordering window, and the maximum count value RX_NEXT of the data packets already received; The reordering timer is controlled based on the updated receive status variables.

[0010] In one possible implementation, controlling the reordering timer based on the updated received state variable includes: Verify the numerical relationship between the updated RX_DELIV and the updated RX_NEXT; If the updated RX_DELIV is less than the updated RX_NEXT, update the updated RX_REORD to the same count value as the updated RX_DELIV, and restart the reordering timer; If the updated RX_DELIV is greater than or equal to the updated RX_NEXT, the reordering timer is not restarted.

[0011] In one possible implementation, determining the first sequence number corresponding to the data packet identifier based on the data packet identifier includes: The PDCP layer queries the first sequence number that uniquely corresponds to the packet identifier based on the one-to-one mapping relationship between packet identifiers and sequence numbers.

[0012] In one possible implementation, determining the data delivery range based on the first sequence number specifically includes: Using the complete count value COUNT corresponding to the first sequence number as the dividing line, the data delivery range is determined to be data packets whose count value is less than the COUNT value corresponding to the first sequence number, which are cached but not yet delivered, and data packets whose count value is greater than or equal to the COUNT value corresponding to the first sequence number, which are cached and whose sequence numbers are consecutive without jumps.

[0013] In one possible implementation, stopping the currently running reordering timer specifically includes: After determining the data submission range, determine the running status of the reordering timer; If the reordering timer is running, stop and reset the reordering timer. When the reordering timer is not running, data packets are directly submitted to the upper layer.

[0014] Secondly, embodiments of this application disclose a data transmission apparatus, the apparatus comprising: The receiving module is used to receive packet loss notification messages from the Media Access Control (MAC) layer, wherein the packet loss notification messages include packet identifiers and transmission status identifiers; The determination module is used to determine a first sequence number corresponding to the data packet identifier based on the data packet identifier when the transmission status identifier indicates a residual packet loss confirmation status, and to determine the data delivery range based on the first sequence number; The upload module is used to stop the currently running reordering timer and submit the cached consecutive data packets within the data submission range to the upper layer.

[0015] In one possible implementation, the device further includes a detection module, which is used to mark the first sequence number corresponding to the data packet identifier when the transmission status identifier indicates an initial transmission error warning state, and to monitor the continuity of data packets with sequence numbers following the first sequence number.

[0016] In one possible implementation, the monitoring module monitors the continuity of data packets following the first sequence number. If a non-continuous sequence number is detected after the first sequence number, the marked sequence number is recorded as a first lost sequence number, and the first lost sequence number is associated with and stored with the identifier in the packet loss notification message. If a continuous sequence number is detected after the first sequence number, the marking of the first sequence number is cleared.

[0017] In one possible implementation, after submitting the cached consecutive data packets within the data submission range to the upper layer, the upload module 403 is specifically used to update the receiving status variable corresponding to the reordering window to complete the adjustment of the reordering window; wherein, the receiving status variable includes the starting count value RX_DELIV of the data packets to be submitted, the upper boundary count value RX_REORD of the reordering window, and the maximum count value RX_NEXT of the received data packets; the reordering timer is controlled according to the updated receiving status variable.

[0018] In one possible implementation, the upload module is specifically used to verify the numerical relationship between the updated RX_DELIV and the updated RX_NEXT; if the updated RX_DELIV is less than the updated RX_NEXT, the updated RX_REORD is updated to the same count value as the updated RX_DELIV, and the reordering timer is restarted; if the updated RX_DELIV is greater than or equal to the updated RX_NEXT, the reordering timer is not restarted.

[0019] In one possible implementation, the determining module is specifically used by the PDCP layer to query the first sequence number that uniquely corresponds to the data packet identifier based on the one-to-one mapping relationship between the data packet identifier and the sequence number.

[0020] In one possible implementation, the determining module is specifically used to determine the data delivery range as follows, based on the complete count value COUNT corresponding to the first sequence number: data packets whose count value is less than the COUNT value corresponding to the first sequence number, which are cached but not yet delivered, and data packets whose count value is greater than or equal to the COUNT value corresponding to the first sequence number, which are cached and whose sequence numbers are consecutive without jumps.

[0021] In one possible implementation, the upload module is specifically used to determine the running state of the reordering timer after determining the data delivery range; if the reordering timer is running, stop and reset the reordering timer; if the reordering timer is not running, directly submit data packets to the upper layer.

[0022] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the data transmission method as described in any of the first aspects.

[0023] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the data transmission method as described in any of the first aspects.

[0024] This application provides a data transmission method and device. The method is applied to a network device, specifically: the Packet Data Convergence Protocol (PDCP) layer receives a packet loss notification message from the Media Access Control (MAC) layer, containing a packet identifier and a transmission status identifier. When the transmission status identifier indicates a residual packet loss acknowledgment state, a corresponding first sequence number is determined based on the packet identifier. A data delivery range is determined based on this first sequence number, and the currently running reordering timer is stopped. The buffered consecutive data packets within this data delivery range are then delivered to the upper layer.

[0025] The technical solution provided in this application can directly stop the reordering timer when a residual packet loss confirmation state is detected and promptly deliver the cached continuous data packets to the upper layer according to the determined delivery range, instead of processing the data according to the PDCP layer protocol method, which requires waiting for the reordering timer to expire. This can effectively shorten the data delivery delay and reduce the time that data packets stay in the cache, thereby reducing the cache occupancy pressure. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating a data transmission method provided in an embodiment of this application; Figure 2 A schematic diagram of a receiving buffer queue provided in an embodiment of this application; Figure 3 A flowchart illustrating another data transmission method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a data transmission device provided in an embodiment of this application. Detailed Implementation

[0028] As described above, 5G New Radio systems have stringent requirements for low latency and high reliability transmission. PDCP UM mode is widely used in latency-sensitive services due to its low overhead and simple process. It relies on a reordering timer to deliver data in order and depends solely on MAC layer HARQ retransmission to ensure reliability. In existing solutions, configuring the reordering timer duration is a dilemma. Too long a duration will lead to buffer backlog, high memory usage, and increased transmission latency, while too short a duration will easily cause buffer overflow and additional packet loss. At the same time, the PDCP layer cannot be aware of the underlying HARQ retransmission status and deterministic packet loss events. Even if the data packet has been lost, it still needs to wait for the timer to expire before the data can be delivered, which further exacerbates latency and resource waste, making it difficult to meet the low latency requirements of 5G real-time services.

[0029] To address this technical problem, embodiments of this application provide a data transmission method and apparatus. This method is applied to a network device, specifically: the Packet Data Convergence Protocol (PDCP) layer receives a packet loss notification message from the Media Access Control (MAC) layer, containing a packet identifier and a transmission status identifier. When the transmission status identifier indicates a residual packet loss acknowledgment state, a corresponding first sequence number is determined based on the packet identifier. A data delivery range is determined based on this first sequence number, and the currently running reordering timer is stopped. The buffered consecutive data packets within this data delivery range are then delivered to the upper layer.

[0030] The technical solution provided in this application embodiment can directly stop the reordering timer when a residual packet loss confirmation state is detected, and promptly deliver the cached continuous data packets to the upper layer according to the determined delivery range, without waiting for the reordering timer to time out. This can effectively shorten the data delivery delay, reduce the time the data packets stay in the cache, and reduce the cache occupancy pressure.

[0031] This application applies to hardware devices on the 5G network side, such as 5G base stations, 5G small cells, distributed units (DUs), and centralized units (CUs). The PDCP and MAC layer protocol processing flows run in the baseband processing units and protocol stack processing hardware of these devices. It primarily targets real-time uplink service transmission scenarios on the 5G New Radio (NR) interface, and is particularly suitable for latency-sensitive service scenarios such as video transmission, voice services, industrial control, and vehicle-to-everything (V2X) applications using the PDCP UM mode. When HARQ retransmission fails on the air interface, resulting in data packet loss, the base station hardware quickly triggers reordering window adjustments and early data delivery through real-time interaction between the MAC and PDCP layers. This reduces data buffer usage and processing latency at the hardware level, ensuring stable operation of real-time services.

[0032] The system architecture of the base station in the embodiments of this application is described below.

[0033] The protocol stack of a 5G base station, from bottom to top, includes the physical layer, MAC layer, RLC layer, PDCP layer, and higher-level application and service layers. Each layer operates in a hardware and software collaborative manner within the base station baseband processing unit, and data and control information are exchanged between layers through standardized interfaces. The PDCP layer, located in the upper part of the protocol stack, is mainly responsible for data encryption, integrity protection, sequence number management, data reordering and in-order delivery, and maintaining reordering timers and receive buffers, providing ordered and reliable data services to the upper layers. The MAC layer, located in the lower part of the protocol stack, is mainly responsible for physical layer resource scheduling, uplink data decoding, and Hybrid Automatic Repeat Request (HARQ) management. It can directly sense the air interface transmission status and determine whether data packets have been lost deterministically due to reaching the maximum number of retransmissions. In this embodiment, the MAC layer and the PDCP layer interact through the inter-layer communication interface inside the base station. The MAC layer can report status information such as air interface transmission errors and packet loss to the PDCP layer in real time, providing the underlying status basis for the PDCP layer to adjust the reordering mechanism and execute data delivery. The two work together to complete the efficient and low-latency transmission processing of 5G air interface data.

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0035] See Figure 1 , Figure 1 This is a flowchart illustrating a data transmission method provided in an embodiment of this application. The execution entity of this method can be hardware devices on the 5G network side, such as 5G base stations, 5G small cells, distributed units (DU), and centralized units (CU). The data transmission method provided in this embodiment is described below using the interaction between the PDCP layer and the MAC layer in the base station as an example. This method includes: S101: The PDCP layer receives a packet loss notification message from the Media Access Control (MAC) layer.

[0036] The MAC layer is the core protocol layer in the 5G base station protocol stack, bridging the Physical Layer and the Radio Link Control (RLC) layer. It is primarily responsible for decoding and verifying uplink data packets, managing the entire process of Hybrid Automatic Repeat Request (HARQ), and scheduling air interface radio resources. The MAC layer is the protocol layer in the base station that can directly perceive the success or failure of air interface data packet transmission and the retransmission execution status. The PDCP layer, located above the RLC layer and oriented towards upper-layer services, is primarily responsible for receiving service data packets submitted by the RLC layer, maintaining the data receive buffer queue, managing the reordering timer, and ensuring the orderly delivery of data upwards. It is the core execution layer that determines data transmission latency and delivery timing.

[0037] Packet loss notification messages are pre-defined inter-layer control signaling within the base station's internal protocol stack. They are used by the MAC layer to transmit the transmission anomaly status of air interface data packets to the PDCP layer, and are independent of the service data transmission channel. The packet identifier, carried in the packet loss notification message, is the unique identifier for each individual data packet that has experienced a transmission anomaly. Each anomalous data packet corresponds to a unique packet identifier, enabling a one-to-one mapping between the MAC and PDCP layers for target data packets. The transmission status identifier, also carried in the packet loss notification message, characterizes the current transmission stage and anomaly type of the target data packet. This identifier is used by the PDCP layer to distinguish different transmission anomaly scenarios and execute differentiated processing logic.

[0038] In this embodiment, the MAC layer continuously receives the uplink data packet decoding results reported by the physical layer, performs real-time judgment on the transmission status of each uplink data packet, and when an air interface transmission anomaly is detected, it determines that the abnormal data packet is assigned a globally unique data packet identifier. At the same time, based on the HARQ retransmission execution status of the data packet, it generates a transmission status identifier that represents its anomaly type. Based on the above information, it assembles and generates a packet loss notification message that conforms to a preset format, and then sends the packet loss notification message to the PDCP receiving entity of the corresponding user terminal through the inter-layer control communication interface pre-configured inside the base station protocol stack.

[0039] After receiving the packet loss notification message sent by the MAC layer through the corresponding inter-layer control communication interface, the PDCP layer parses and processes the message according to the preset protocol format, extracts the data packet identifier and transmission status identifier carried in the message, binds the two extracted pieces of information to the PDCP receiving entity of the corresponding user terminal, and stores them in the local control information cache of the PDCP layer. This completes the reception and preprocessing of abnormal status information of air interface transmission, providing accurate and unique input basis for subsequent packet loss judgment and data delivery processing.

[0040] This application embodiment establishes a dedicated packet loss notification message interaction mechanism between the MAC layer and the PDCP layer. This enables the PDCP layer, which previously could not directly perceive the underlying air interface transmission status, to obtain data packet transmission anomaly information in a timely and accurate manner. This breaks the limitation of the PDCP layer in the traditional 3GPP protocol framework, which can only passively determine packet loss by the continuity of received data packet sequence numbers. It fundamentally solves the core pain point that the PDCP layer cannot know deterministic packet loss in advance, providing the necessary prerequisite for subsequent rapid triggering of reordering adjustments and reduction of data transmission latency. At the same time, this application embodiment improves the uniqueness and accuracy of abnormal status transmission through the matching design of data packet identifiers and transmission status identifiers, which can effectively avoid information crosstalk and processing errors in multi-user, multi-concurrent data packet scenarios.

[0041] S102: When the transmission status indicator indicates a residual packet loss confirmation status, the PDCP layer determines the first sequence number corresponding to the packet identifier based on the packet identifier, and determines the data delivery range based on the first sequence number.

[0042] The residual packet loss confirmation state refers to a deterministic packet loss state in which the MAC layer detects that the number of HARQ retransmission requests for the target data packet has reached the preset maximum and has still not been correctly decoded, and the data packet can no longer be recovered through air interface retransmission. This is the core condition for triggering the fast reordering process of this invention. The first sequence number refers to the packet data aggregation protocol sequence number (SN) corresponding to the packet lost data packet in the PDCP layer. It is used to identify the position of the data packet in the receive queue and is the core benchmark for reordering and data delivery. The data delivery range refers to the boundary and set of cached data packets that the PDCP layer submits to the upper layer. It is uniformly defined by the first sequence number to ensure that the delivered data is continuous and orderly.

[0043] In this specific implementation, after parsing the packet loss notification message, the PDCP layer first judges the transmission status identifier. When it identifies the identifier as a residual packet loss acknowledgment status, it confirms that irreversible packet loss has occurred on the air interface. Subsequently, the PDCP layer performs a matching search in the locally maintained mapping relationship based on the data packet identifier carried in the message to determine the first sequence number uniquely corresponding to the identifier, i.e., the PDCP sequence number of the lost data packet.

[0044] After determining the first sequence number, the PDCP layer uses this first sequence number as a benchmark to define the range of data that needs to be submitted to the upper layer. This range is divided by the first sequence number and includes all received and consecutive data packets before the first sequence number, as well as the received and consecutive data packets after the first sequence number, ensuring that the submitted content is complete, in the correct order, and without the risk of out-of-order delivery.

[0045] This step ensures that the rapid processing flow is initiated only when a truly deterministic packet loss occurs, through precise judgment of the residual packet loss confirmation status, thus avoiding false triggering. Precise mapping between packet identifiers and the first sequence number ensures that the PDCP layer can accurately locate the packet loss position, providing a reliable basis for adjusting the reordering window. By defining the data delivery range based on the first sequence number, it ensures clear data delivery logic and explicit delivery content, fully releasing cache resources while strictly adhering to the in-order delivery protocol requirements, guaranteeing the stability of data reception for upper-layer services.

[0046] To further improve the accuracy of packet loss location and ensure the reliability and consistency of data delivery range delineation, this embodiment of the invention also clarifies the specific implementation method of determining the corresponding first sequence number based on the packet identifier.

[0047] In one possible implementation, determining the first sequence number corresponding to the data packet identifier based on the data packet identifier includes: the PDCP layer querying the first sequence number uniquely corresponding to the data packet identifier based on the one-to-one mapping relationship between the data packet identifier and the sequence number.

[0048] The first sequence number is the PDCP sequence number SN corresponding to the data packet that experienced a transmission anomaly. It is the core benchmark for the PDCP layer to identify the order of data packets, perform reordering management, and deliver data in order.

[0049] In this embodiment, when the MAC layer detects an initial decoding error in an uplink data packet and the number of retransmissions using the Hybrid Automatic Repeat Request (HARQ) has not reached the preset maximum, it sends an initial transmission error notification message carrying a data packet identifier to the PDCP layer. Upon receiving this message, the PDCP layer marks the PDCP sequence number (SN) corresponding to the abnormal data packet and establishes a one-to-one binding mapping between the data packet identifier and the marked PDCP sequence number (SN), storing this mapping in the PDCP layer's local mapping table in real time. When the MAC layer subsequently detects that the HARQ retransmission count for the data packet has reached the preset maximum threshold and cannot be recovered via air interface retransmission, it generates a packet loss notification message carrying the same data packet identifier and displaying a residual packet loss confirmation status. Upon receiving this message, the PDCP layer extracts the data packet identifier and uses it as a search keyword to perform a precise matching query in the locally pre-stored mapping table, quickly obtaining the first sequence number uniquely bound to the data packet identifier, thus completing the location of the lost data packet sequence number.

[0050] This application embodiment establishes a one-to-one mapping relationship between data packet identifiers and PDCP sequence numbers in advance. When a residual packet loss confirmation notification is received, the corresponding packet loss sequence number can be quickly queried directly through the identifier. There is no need to perform a full traversal search of the PDCP receiving queue when confirming packet loss, which greatly improves the processing efficiency of packet loss location and further shortens the overall latency of data delivery.

[0051] To further clarify the boundary rules for data delivery, ensure the compliance of PDCP layer data delivery in order, and maximize the release of receiving cache resources and shorten data transmission latency, this application embodiment also clarifies the specific implementation method for determining the data delivery range based on the first sequence number.

[0052] In one possible implementation, determining the data delivery range based on the first sequence number specifically includes: using the complete count value COUNT corresponding to the first sequence number as a boundary benchmark, determining the data delivery range as cached and undelivered data packets with a count value less than the COUNT value corresponding to the first sequence number, and cached data packets with a count value greater than or equal to the COUNT value corresponding to the first sequence number and whose sequence numbers are consecutive without jumps.

[0053] Among them, the complete count value COUNT is a unique value used by the PDCP layer in the 5G NR protocol to identify the global transmission order of data packets. It is composed of the superframe number HFN and the first sequence number (PDCP sequence number SN). It can completely represent the sorting position of the data packet in the PDCP receive queue and avoid the problem of sequence number wrap-around sorting error caused by the SN length limitation. It is the core benchmark for PDCP layer data sorting, decryption and integrity verification specified by the 3GPP TS38.323 protocol.

[0054] The demarcation benchmark is the core anchor point for the PDCP layer to distinguish between deliverable data packets and pending data packets. It uses the COUNT value of deterministically lost data packets as the basis for the demarcation, which can avoid the risk of out-of-order data delivery from the source.

[0055] The cached and undelivered data packets with a count value less than the COUNT value corresponding to the first sequence number refer to all PDCP service data units (SDUs) that have been correctly received, decrypted, verified for integrity, and cached by the PDCP layer before the data packets were lost. The sequence numbers of these data packets are completely consecutive and there is no risk of out-of-order delivery.

[0056] A buffered data packet with a count value greater than or equal to the COUNT value corresponding to the first sequence number and a continuous sequence number without any jumps refers to a PDCPSDU that has been correctly received by the PDCP layer after the data packet was lost and whose sequence number is not interrupted. This part of the data packets is in complete order and there is no risk of out-of-order delivery.

[0057] In this embodiment, after obtaining the corresponding first sequence number through packet identifier matching, the PDCP layer first calculates the complete COUNT value corresponding to the first sequence number according to the COUNT value calculation rules specified in the 3GPP TS 38.323 protocol, combined with the HFN state variables maintained by the current PDCP receiving entity. This complete COUNT value is used as the unique boundary benchmark for the current data delivery range. Subsequently, the PDCP layer traverses the local receive buffer queue to complete the filtering of eligible packets: the first category filters out all buffered, undelivered PDCPSDUs with COUNT values ​​less than the boundary benchmark. This data was received and verified before the lost packet, and there is no issue of missing sequence numbers. The second category filters out PDCPSDUs with COUNT values ​​greater than or equal to the boundary benchmark and consecutive sequence numbers without jumps. This data was received after the lost packet, and there are no sequence number interruptions between them, so the integrity of the sequence can be confirmed without waiting for the lost packet. Finally, the PDCP layer includes both types of packets in the current data delivery range, completing the precise delineation of the delivery boundary.

[0058] This application's embodiments clearly define the range of two types of deliverable data packets by using the COUNT value of the lost data packets as a fixed boundary. This strictly adheres to the core requirement of in-order data delivery in the 3GPP protocol's PDCP layer, avoiding the impact of out-of-order data on upper-layer services. Furthermore, in the event of deterministic packet loss, it includes all received data packets before and after the loss that are not at risk of being out of order within the delivery range. Moreover, it eliminates the need to wait for the reordering timer to time out, maximizing the release of PDCP receive buffer memory resources and solving the memory waste problem of continuously accumulating data packets in the buffer queue after packet loss in existing technologies.

[0059] S103: The PDCP layer stops the currently running reordering timer and submits the cached consecutive data packets within the data submission range to the upper layer.

[0060] The reordering timer, specified in 3GPP TS 38.323, is a t-Reordering timer used in the PDCP layer's non-acknowledgment mode to manage the sequential delivery of data. In traditional protocol flows, when the sequence numbers of data packets received by PDCP become discontinuous, the reordering timer is activated. Only after the reordering timer expires can the PDCP layer skip the lost data packets and deliver cached data to the upper layer, which is the core source of data transmission latency in existing technologies. The upper layer refers to the protocol layer or service entity above the PDCP layer in the 5G base station protocol stack, including the Service Data Adaptation Protocol (SDAP) layer, core network user plane entities, or upper-layer service applications. It is the final delivery object after the PDCP layer completes data processing. The cached continuous data packets refer to PDCP service data units within the delivery range defined in step S102, which have undergone decryption, integrity verification, header decompression preprocessing by the PDCP layer, and are stored in the local receive buffer queue. The count value (COUNT) of these data packets is continuous without any jumps, meeting the sequential delivery requirements specified in the protocol.

[0061] In this embodiment, after defining the data delivery range, the PDCP layer first monitors the running status of the currently maintained reordering timer in real time. The running status of the reordering timer directly reflects whether the PDCP layer is waiting for missing data packets due to discontinuous sequence numbers. If the timer is running, it indicates that the PDCP layer has started the packet loss waiting process. At this time, the timer is immediately stopped and reset, without waiting for the preset timeout duration, directly terminating the invalid waiting process and breaking the limitation in traditional protocols that packet loss can only be handled when the timer times out. If the timer is not running, it indicates that the PDCP layer has not started the packet loss waiting process. There is no need to perform timer-related operations, and the data delivery stage is directly entered, avoiding redundant operations that occupy the processing resources of the base station protocol stack.

[0062] If the reordering timer is detected as currently running, it indicates that the PDCP layer has previously initiated a waiting mechanism due to discontinuous packet sequence numbers. In this case, the PDCP layer immediately stops and resets the reordering timer, without waiting for the timer to reach its preset timeout duration, directly breaking the limitation of traditional protocols that "packet loss can only be handled after a timeout." If the reordering timer is detected as not running, the PDCP layer does not need to stop the timer and directly proceeds to the subsequent data delivery process, avoiding the impact of invalid operations on the protocol stack's processing efficiency.

[0063] After completing the timer state processing, the PDCP layer retrieves the predefined data delivery range, traverses the local PDCP receive buffer queue, and filters out all PDCPSDUs that meet the delivery range requirements. It then strictly follows the ascending order of the COUNT value specified in the 3GPP protocol to sort and organize the filtered data packets. After sorting, the organized consecutive data packets are delivered to the upper-layer service entity all at once. The entire delivery process does not require waiting for the reordering timer to time out; it can be triggered only by the deterministic packet loss notification reported by the MAC layer, ensuring that correctly received data packets can be delivered to the upper layer with the shortest possible latency.

[0064] To further improve the closed-loop process of the PDCP layer reordering mechanism in deterministic packet loss scenarios, ensure the continuity of the receiving and processing flow after data delivery, and fully comply with the 3GPP TS 38.323 protocol specification, this application embodiment also clarifies the reordering window adjustment and timer management scheme after data delivery, as follows: In one possible implementation, after submitting the cached consecutive data packets within the data submission range to the upper layer, the method further includes: The PDCP layer updates the receive status variable corresponding to the reordering window to complete the adjustment of the reordering window; the PDCP layer controls the reordering timer according to the updated receive status variable.

[0065] Among them, the receive status variables are core status parameters specified by the 3GPP protocol and used by the PDCP layer to maintain the reordering window and control the sequential delivery of data. The receive status variables include the starting count value RX_DELIV of the data packets to be delivered, the upper boundary count value RX_REORD of the reordering window, and the maximum count value RX_NEXT of the data packets already received.

[0066] The initial count value RX_DELIV is the lower bound of the reordering window, representing the complete count value COUNT corresponding to the first PDCP service data unit (SDU) to be delivered to the upper layer. It is the core benchmark for the PDCP layer to determine the starting position of data delivery. The upper bound count value RX_REORD is the upper bound of the reordering window, representing the maximum COUNT value recorded when the PDCP layer triggers the reordering timer. It is used to define the range of reordering waiting.

[0067] The maximum count value RX_NEXT of received data packets represents the maximum COUNT value of PDCP data protocol data units (PDUs) received by the PDCP receiving entity plus 1, used to identify the maximum boundary of currently received data packets. The adjustment of the reordering window is achieved by updating the above three core state variables to dynamically adjust the upper and lower boundaries of the reordering window, adapting to the current packet loss scenario and data reception status.

[0068] In this specific implementation, after the PDCP layer completes the upward submission of all PDCPSDUs within the data delivery range, it updates the receive state variables to dynamically adjust the reordering window. The PDCP layer uses the SN of the data packet that was determined to be lost in this instance. lost_m The corresponding COUNT value is RCVD_COUNT lost_m Based on this, RX_DELIV is updated to the COUNT value corresponding to the first PDCP SDU that has not yet been delivered to the upper layer, which is the receive queue lost packet sequence number SN. lost_m The next marker serial number SN lost_m+1 The corresponding COUNT value is RCVD_COUNT lost_m+1 This completes the update of the lower bound of the reordering window. Simultaneously, based on the updated RX_DELIV, the pre-adjustment of the upper bound RX_REORD of the reordering window is completed, thus completing the dynamic adaptation of the entire reordering window.

[0069] After updating the receive state variables, the PDCP layer strictly follows the protocol branch logic shown in the attached diagram, executing the reordering timer control process. The PDCP layer first checks the relationship between the updated RX_DELIV and the currently maintained RX_NEXT value to determine if there are still unreceived or undelivered valid data packets in the current receive queue. If the check finds that the updated RX_DELIV is less than RX_NEXT, it indicates that there are still received but discontinuous sequence numbers or undelivered data packets in the current receive queue, requiring the reordering wait mechanism to continue. In this case, the PDCP layer updates RX_REORD to the same COUNT value RCVD_COUNTlost_m+1 as the updated RX_DELIV and restarts the reordering timer, entering the next round of the reordering wait process. If the check finds that the updated RX_DELIV is greater than or equal to RX_NEXT, it indicates that there are no more valid data packets to be received or delivered in the current receive queue, and there is no need to continue the reordering wait. Therefore, the PDCP layer does not restart the reordering timer, ends the current packet loss handling process, and waits for subsequent new data packets to be received.

[0070] To more clearly illustrate the execution process of this embodiment, we will refer to the commercial base station service scenario example mentioned earlier. The data packet that was definitively lost in this instance has SN=3 and a corresponding COUNT value of RCVD_COUNT. lost_m The sequence number is [0,3], and its next serial number is SN. lost_m+1 For SN=4, the corresponding COUNT value is RCVD_COUNT. lost_m+1The value is [0,4]. The PDCP layer has completed the upward delivery of data packets corresponding to SN=1, 2, 4, 5, 6, 7, and 8. The largest data packet currently received is SN=8, and the corresponding RX_NEXT is [0,9]. After the PDCP layer completes the data delivery, it first updates RX_DELIV from the original [0,1] to [0,4], completing the adjustment of the lower bound of the reordering window. Then, it verifies the numerical relationship between the updated RX_DELIV=[0,4] and RX_NEXT=[0,9], confirming that RX_DELIV is less than RX_NEXT. Therefore, it updates RX_REORD to [0,4] and restarts the reordering timer, completing the entire process of this reordering window adjustment and timer control.

[0071] This embodiment achieves a complete closed loop for the PDCP reordering mechanism in deterministic packet loss scenarios by clearly defining the rules for updating state variables and adjusting the reordering window after data delivery, along with the corresponding timer management logic. This breaks the limitation of traditional protocols that can only adjust the window after a timer expires, and is fully compatible with the state variable management specifications of the 3GPP TS38.323 protocol, without causing any compatibility issues with subsequent data packet reception and reordering processing. Simultaneously, by accurately determining whether to restart the timer based on the updated state variables, invalid timer execution and buffer occupation are avoided. While ensuring data delivery in order, the low-latency processing capability of the PDCP layer is continuously maintained, adapting to the long-term stable transmission requirements of latency-sensitive services such as real-time video, industrial control, and vehicle networking in 5G unconfirmed mode.

[0072] In one possible implementation, the method further includes step S104.

[0073] S104: When the transmission status indicator indicates an initial transmission error warning state, the PDCP marks the first sequence number corresponding to the data packet identifier and monitors the continuity of data packets after the first sequence number.

[0074] The initial transmission error warning state refers to the transmission state marked when the Media Access Control (MAC) layer detects an initial decoding error in an uplink data packet, but the number of HARQ retransmissions for that data packet has not yet reached the preset maximum retransmission threshold. In this state, the data packet can still be recovered through subsequent HARQ retransmissions, and irreversible deterministic packet loss has not yet occurred.

[0075] The first lost sequence number refers to the PDCP sequence number SN to be verified that has changed after continuous verification and is likely to fail to be received normally. It corresponds to SN_lost recorded in the technical disclosure document of this solution.

[0076] In this embodiment, when the transmission status is confirmed to be in the initial transmission error warning state, the PDCP layer matches the corresponding first sequence number based on the data packet identifier carried in the message, marks the first sequence number as a sequence number to be verified, and then starts monitoring the continuity of sequence numbers of subsequent received data packets. The PDCP layer continuously receives PDCP data protocol data units (PDUs) submitted by the underlying RLC layer, performs real-time parsing and sorting verification of the PDCP sequence number of each newly received data packet, and focuses on verifying the sequential integrity of subsequently received data packets with sequence numbers greater than the first sequence number, based on the marked first sequence number, to determine whether a sequence number jump has occurred.

[0077] If the PDCP layer detects that a data packet with a sequence number greater than the first sequence number has been received, but the data packet corresponding to the first sequence number has not been received (i.e., the sequence numbers after the first sequence number show discontinuous jumps), it confirms that the data packet corresponding to the first sequence number is highly unlikely to be recovered through retransmission. The PDCP layer then officially records this marked first sequence number as the first lost sequence number. Simultaneously, the PDCP layer establishes a one-to-one binding relationship between this first lost sequence number and the data packet identifier in the current packet loss notification message, storing this association in a local packet loss sequence number mapping table. This provides a retrieval basis for quickly matching and locating the lost sequence number when the MAC layer reports the residual packet loss confirmation status later.

[0078] If the PDCP layer detects through verification that the data packet corresponding to the first sequence number has been successfully received, and that subsequent data packets with sequence numbers greater than the first sequence number are received in complete order without any jumps (i.e., the sequence numbers after the first sequence number are consecutive), then it is confirmed that the data packet with the initial transmission error has been successfully recovered through HARQ retransmission, and no actual packet loss occurred. Therefore, there is no need to further track and verify this sequence number. At this point, the PDCP layer immediately clears the verification mark for the first sequence number and deletes the temporary mapping relationship between the sequence number and the corresponding data packet identifier, ending the current continuous monitoring process and preventing invalid sequence number verification from consuming the base station protocol stack's processing resources.

[0079] This application's embodiments, through explicit sequence number continuity monitoring rules and dual-branch processing logic, achieve proactive prediction and full-process control of air interface transmission anomalies, serving as crucial pre-emptive support for the core low-latency capability of this solution. By pre-marking the sequence number to be verified and initiating continuous monitoring, the PDCP layer can overcome the limitation of traditional protocols that can only passively detect packet loss through reordering timer timeouts, enabling proactive prediction and location of packet loss risks. Through the associated storage of the first lost sequence number and the data packet identifier, when a residual packet loss acknowledgment notification is received from the MAC layer, the lost sequence number can be quickly and accurately matched without traversing the receive queue, significantly shortening the processing time after deterministic packet loss and further reducing data transmission latency.

[0080] To facilitate the description of the implementation of this method, the following example further illustrates the method. As an example, this application embodiment is based on a 5G NR macro base station uplink high-definition video live streaming service scenario, with the following preset basic configuration: the base station side is a commercial 5G macro base station; the uplink video service of the target user terminal is carried in PDCP unacknowledged mode, fully compliant with the 3GPP TS 38.323 protocol specification; the PDCP sequence number (SN) length is 12 bits; the maximum number of retransmissions for the Hybrid Automatic Repeat Request (HARQ) configured at the MAC layer is 4; and the default duration of the PDCP layer reordering timer t-Reordering is 200ms. Figure 2 As shown, the SN sequence of the uplink PDCP data packets transmitted in this case is 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, m, n, where n is greater than m, and m and n are both integers. Among them, the data packets with SN=4, 7, 10, m+1 have decoding errors in the air interface transmission.

[0081] The MAC layer continuously receives the uplink data packet decoding results reported by the physical layer. It detects that the initial decoding of data packets with SN=4, 7, 10, and m+1 fails. At this point, the HARQ retransmission count for all four data packets is 0, which is below the maximum threshold of 4. Recovery can still be achieved through subsequent retransmissions, and no irreversible packet loss occurs. The MAC layer strictly follows the interactive message structure format defined in this application to generate a corresponding packet loss notification message for each abnormal data packet. The message carries a u32UeId field uniquely identifying the target user, a u32Tag field uniquely identifying the abnormal data packet, and a u32TfState field representing the transmission status. u32TfState is configured to 0, representing an initial transmission error warning status. Subsequently, the four initial transmission error warning messages are sent to the corresponding user's PDCP receiving entity through the base station's internal inter-layer interface.

[0082] After receiving four packet loss notification messages from the MAC layer, the PDCP layer completes message parsing and field extraction, identifying that the u32TfState field in the message is 0, confirming that the current scenario is an initial transmission error warning. The PDCP layer matches the corresponding PDCP sequence number for each packet identifier, marking SN=4, 7, 10, and m+1 as sequence numbers to be verified. At the same time, it establishes a one-to-one mapping relationship between each u32Tag and its corresponding PDCP sequence number, specifically u32Tag=004 corresponds to SN=4, u32Tag=007 corresponds to SN=7, u32Tag=010 corresponds to SN=10, and u32Tag=00m+1 corresponds to SN=m+1. This mapping relationship is stored in a local mapping table, and the continuity monitoring of the sequence numbers of subsequently received data packets is initiated.

[0083] The PDCP layer continuously receives PDCP data PDUs submitted by the underlying RLC layer. It performs real-time verification of the serial number (SN) of each newly received data packet, focusing on verifying the sequential integrity of subsequent received data packets based on the four marked sequence numbers to be verified. Corresponding to the receive buffer queue diagram in this application, the PDCP layer successively receives data packets corresponding to SN=1, 2, 3, 5, 6, 8, 9, 11, 12, and n. Verification confirms that data packets corresponding to SN=4, 7, 10, and m+1 were not successfully received, and subsequent sequence numbers all exhibited jumps, disrupting sequence number continuity. The PDCP layer then, according to the rules of this application, officially records SN=4 as the SN. lost_1 SN=7 is recorded as SN lost_2 SN=10 is recorded as SN lost_3 SN=m+1 is recorded as SN lost_n Each tag is associated with and stored in the corresponding u32Tag field, and the tagging result is completely consistent with the schematic diagram of the receiving buffer queue.

[0084] After four HARQ retransmissions, the data packets with SN=4, 7, 10, and m+1 all failed to decode, reaching the preset maximum number of retransmissions. They could not be recovered via air interface retransmission, resulting in irreversible deterministic packet loss. The MAC layer then generated residual packet loss confirmation messages for the four confirmed lost data packets according to the structure format defined in this application. The u32UeId and u32Tag fields in these messages were completely consistent with the previous initial transmission warning messages, except that the u32TfState field was configured to 1, representing the residual packet loss confirmation status, i.e., the maximum number of retransmissions had been reached. Subsequently, the four residual packet loss confirmation messages were sent to the PDCP layer.

[0085] After receiving the residual packet loss confirmation message, the PDCP layer parses the u32TfState field to be 1, confirming that deterministic packet loss has occurred on the air interface. Taking the packet loss message corresponding to SN=4 as an example, the processing strictly follows the process defined in this application. The PDCP layer first quickly matches the u32Tag=004 in the message in the local pre-stored mapping table to obtain the corresponding first sequence number SN=4. Then, according to the 3GPP protocol rules, it calculates the complete count value RCVD_COUNT_lost_1=[0,4] corresponding to SN=4. This is used as the dividing benchmark to delineate the data delivery range, specifically the PDCPSDUs corresponding to SN=1, 2, and 3 with COUNT values ​​less than [0,4], and the PDCPSDUs corresponding to SN=5 and 6 with COUNT values ​​greater than or equal to [0,4] and continuous sequence numbers without jumps. Subsequently, the PDCP layer detected that the current reordering timer was running, and had only run for 12ms, far below the 200ms timeout threshold. It then immediately stopped and reset the reordering timer, and submitted all PDCPSDUs within the defined range to the upper layer in ascending order of the COUNT value.

[0086] After completing this data delivery, the PDCP layer strictly follows the rules defined in this application to update the core receive state variables corresponding to the reordering window, thus completing the dynamic adjustment of the reordering window. The PDCP layer updates the starting count value RX_DELIV of the data packet to be delivered to the COUNT value corresponding to the first PDCPSDU that has not yet been delivered to the upper layer, which is the COUNT value RCVD_COUNT_lost_2=[0,7] corresponding to the next lost sequence number SN_lost_2 (SN=7) after the current lost sequence number SN_lost_1, thus completing the update of the lower bound of the reordering window. At the same time, the pre-adjustment of the upper bound RX_REORD of the reordering window is completed simultaneously, thus completing the adaptation and adjustment of the entire reordering window.

[0087] After updating the receive state variables, the PDCP layer verifies the relationship between the updated RX_DELIV and the currently maintained maximum received count value RX_NEXT. The maximum received data packet SN is 12, corresponding to RX_NEXT [0,13]. Verification confirms that the updated RX_DELIV=[0,7] is less than RX_NEXT=[0,13], indicating that there are still received data packets in the receive queue with discontinuous sequence numbers and incomplete delivery. The PDCP layer then updates the upper boundary RX_REORD of the reordering window to [0,7], consistent with the updated RX_DELIV, and restarts the reordering timer, entering the next round of reordering waiting, completing the full closed loop of this packet loss processing. Subsequently, the PDCP layer will process the residual packet loss notification messages corresponding to SN=7, 10, and m+1 sequentially according to the same logic.

[0088] This application's embodiments fully reproduce the entire execution logic of the application's solution. After adopting the application's solution, the PDCP layer can complete the upward delivery of received valid data packets within tens of milliseconds after each data packet loss is confirmed, without waiting for the 200ms reordering timer to expire. The end-to-end data transmission latency is greatly reduced. At the same time, the received valid data packets can be immediately delivered and buffered, avoiding long-term invalid retention of data packets in the receive buffer. This effectively reduces the memory occupation of the PDCP layer and fully achieves the core inventive objective of reducing transmission latency and reducing memory resource waste.

[0089] Below, in conjunction with Figure 3The data transmission method provided in this application embodiment is described again. This solution is a low-latency data transmission processing solution applicable to the PDPCM mode of 5G systems. The overall process is driven by the real-time interaction of air interface packet loss status between the PDCP layer and the MAC layer. After the process starts, the PDCP layer continuously waits and listens for packet loss indication messages sent by the MAC layer in unacknowledged mode (UM). First, it checks whether the message has been received by the first judgment node. If the packet loss indication message is not received, it continues to maintain a loop listening state to ensure that it can detect abnormalities in air interface transmission as soon as possible.

[0090] like Figure 3 As shown, after the PDCP layer confirms receipt of the packet loss indication message from the MAC layer, it enters the core transmission status judgment stage to verify whether this packet loss indication is an initial transmission scenario. If it is determined to be an initial transmission error indication, it means that there was an error in the decoding of the data packet during its first transmission on the air interface, but irreversible deterministic packet loss has not yet occurred. The PDCP layer then marks the SN sequence number corresponding to this abnormal data packet and continuously checks the continuity of the sequence numbers of subsequent received data packets. If the subsequent received packet sequence numbers are continuous, it means that this error has not caused actual service packet loss, and the PDCP layer clears the SN mark and returns to the initial message listening state. If the subsequent received packet sequence numbers are not continuous, it means that there is a clear risk of packet loss. The PDCP layer officially records the packet loss sequence number SN_lost, completing the pre-marking of the packet loss risk, and also returns to the initial listening state to prepare data for subsequent residual packet loss processing.

[0091] If the PDCP layer determines that the packet loss indication is not the initial transmission, meaning that a residual error occurred in the air interface, confirming that a deterministic air interface packet loss that cannot be recovered through retransmission has occurred, it then uses the previously recorded packet loss sequence number (SN) in the receive buffer queue. lost_m and its complete count value RCVD_COUNTl ost_m The core packet loss handling process then begins. The PDCP layer first checks the running status of the t-Reordering timer. If the timer is not running, the PDCP layer clears all SNs. lost The relevant flags are handled in accordance with the reordering timer timeout scenario specified in the 3GPP protocol, returning to the initial waiting state; if the reordering timer is detected to be running, the PDCP layer immediately stops the reordering timer, completely breaking the limitation of traditional protocols that can only wait for the timer to expire before packet loss can be processed, thus avoiding the transmission delay caused by timer waiting from the root.

[0092] After the timer stops, the PDCP layer performs a batch-ordered data delivery operation, first delivering all stored data whose COUNT value is less than the current packet loss count value RCVD_COUNT. lost_mThe PDCP Service Data Unit (SDU) then delivers all stored PDCPSDUs with consecutively associated COUNT values, starting from RCVD_COUNT_lost_m. This delivers all received data packets without out-of-order risk before and after packet loss to the upper layer at once, without waiting for the reordering timer to expire. After data delivery, the PDCP layer updates the core receive status variable corresponding to the reordering window, updating the starting count value RX_DELIV of the data packets to be delivered to the COUNT value corresponding to the first PDCP SDU that has not yet been transmitted to the upper layer, which is the sequence number SN of this packet loss. lost_m The next marker serial number SN lost_m+1 The corresponding COUNT value is RCVD_COUNT lost_m+1 This allows for the dynamic adjustment of the reordered windows.

[0093] After updating RX_DELIV, the PDCP layer enters the final judgment stage of the process, verifying whether the updated RX_DELIV is less than the maximum count value of received data packets, RX_NEXT. If RX_DELIV is determined to be greater than or equal to RX_NEXT, it means that there are no more valid data packets waiting to be processed in the current receive queue, and the PDCP layer clears all SNs. lost The relevant flags are then returned to the initial message listening and waiting state. If RX_DELIV is determined to be less than RX_NEXT, it indicates that there are still undelivered non-contiguous data packets in the receive queue. The PDCP layer first updates the upper boundary count value of the reordering window, RX_REORD, to RCVD_COUNT. lost_m+1 Then, the t-Reordering timer is restarted to complete the entire closed loop of this packet loss handling process, returning to the initial message listening state and preparing for subsequent data packet reception and air interface exception handling.

[0094] This application also provides a data transmission device, such as... Figure 4 As shown, the device includes: The receiving module 401 is used to receive a packet loss notification message from the Media Access Control (MAC) layer, wherein the packet loss notification message includes a data packet identifier and a transmission status identifier. The determining module 402 is used to determine a first sequence number corresponding to the data packet identifier based on the data packet identifier when the transmission status identifier indicates a residual packet loss confirmation status, and to determine a data delivery range based on the first sequence number; Upload module 403 is used to stop the currently running reordering timer and submit the cached consecutive data packets within the data submission range to the upper layer.

[0095] In one possible implementation, the device further includes a detection module, which is used to mark the first sequence number corresponding to the data packet identifier when the transmission status identifier indicates an initial transmission error warning state, and to monitor the continuity of data packets with sequence numbers following the first sequence number.

[0096] In one possible implementation, the monitoring module monitors the continuity of data packets following the first sequence number. If a non-continuous sequence number is detected after the first sequence number, the marked sequence number is recorded as a first lost sequence number, and the first lost sequence number is associated with and stored with the identifier in the packet loss notification message. If a continuous sequence number is detected after the first sequence number, the marking of the first sequence number is cleared.

[0097] In one possible implementation, after submitting the cached consecutive data packets within the data submission range to the upper layer, the upload module 403 is specifically used to update the receiving status variable corresponding to the reordering window to complete the adjustment of the reordering window; wherein, the receiving status variable includes the starting count value RX_DELIV of the data packets to be submitted, the upper boundary count value RX_REORD of the reordering window, and the maximum count value RX_NEXT of the received data packets; the reordering timer is controlled according to the updated receiving status variable.

[0098] In one possible implementation, the upload module 403 is specifically used to verify the numerical relationship between the updated RX_DELIV and the updated RX_NEXT; if the updated RX_DELIV is less than the updated RX_NEXT, the updated RX_REORD is updated to the same count value as the updated RX_DELIV, and the reordering timer is restarted; if the updated RX_DELIV is greater than or equal to the updated RX_NEXT, the reordering timer is not restarted.

[0099] In one possible implementation, the determining module 402 is specifically used by the PDCP layer to query the first sequence number that uniquely corresponds to the data packet identifier based on the one-to-one mapping relationship between the data packet identifier and the sequence number.

[0100] In one possible implementation, the determining module 402 is specifically used to determine, based on the complete count value COUNT corresponding to the first sequence number, the data delivery range as cached and undelivered data packets with a count value less than the COUNT value corresponding to the first sequence number, and cached data packets with a count value greater than or equal to the COUNT value corresponding to the first sequence number and whose sequence numbers are consecutive without jumps.

[0101] In one possible implementation, the upload module 403 is specifically used to determine the running state of the reordering timer after determining the data delivery range; if the reordering timer is running, stop and reset the reordering timer; if the reordering timer is not running, directly submit data packets to the upper layer.

[0102] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the data upload method described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0103] Memory can store computer instructions. When the computer instructions stored in memory are executed by the processor, the processor can use them to perform data upload methods. Memory can also store data.

[0104] 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. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0105] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0106] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0107] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0108] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data transmission method, characterized in that, Applied to network devices, the method includes: The Packet Data Convergence Protocol (PDCP) layer receives a packet loss notification message from the Media Access Control (MAC) layer. The packet loss notification message includes a packet identifier and a transmission status identifier. When the transmission status indicator indicates a residual packet loss confirmation status, a first sequence number corresponding to the packet identifier is determined according to the packet identifier, and a data delivery range is determined based on the first sequence number; Stop the currently running reordering timer and submit the cached consecutive data packets within the data submission range to the upper layer.

2. The method according to claim 1, characterized in that, The method further includes: When the transmission status identifier indicates an initial transmission error warning state, the first sequence number corresponding to the data packet identifier is marked, and the continuity of data packets with the sequence number after the first sequence number is monitored.

3. The method according to claim 2, characterized in that, The continuity of the monitoring sequence number in data packets following the first sequence number includes: If a non-contiguous sequence number is detected after the first sequence number, the marked sequence number is recorded as the first lost sequence number, and the first lost sequence number is associated with and stored with the identifier in the packet loss notification message. If consecutive serial numbers are detected after the first serial number, the mark on the first serial number is cleared.

4. The method according to claim 1, characterized in that, After submitting the cached consecutive data packets within the data submission range to the upper layer, the method further includes: Update the receive status variables corresponding to the reordering window to complete the adjustment of the reordering window; wherein, the receive status variables include the starting count value RX_DELIV of the data packets to be delivered, the upper boundary count value RX_REORD of the reordering window, and the maximum count value RX_NEXT of the data packets already received; The reordering timer is controlled based on the updated receive status variables.

5. The method according to claim 4, characterized in that, The step of controlling the reordering timer based on the updated receive state variable includes: Verify the numerical relationship between the updated RX_DELIV and the updated RX_NEXT; If the updated RX_DELIV is less than the updated RX_NEXT, update the updated RX_REORD to the same count value as the updated RX_DELIV, and restart the reordering timer; If the updated RX_DELIV is greater than or equal to the updated RX_NEXT, the reordering timer is not restarted.

6. The method according to claim 1, characterized in that, The step of determining the first sequence number corresponding to the data packet identifier based on the data packet identifier includes: The PDCP layer queries the first sequence number that uniquely corresponds to the packet identifier based on the one-to-one mapping relationship between packet identifiers and sequence numbers.

7. The method according to claim 1, characterized in that, The step of determining the data delivery range based on the first sequence number specifically includes: Using the complete count value COUNT corresponding to the first sequence number as the dividing line, the data delivery range is determined to be data packets whose count value is less than the COUNT value corresponding to the first sequence number, which are cached but not yet delivered, and data packets whose count value is greater than or equal to the COUNT value corresponding to the first sequence number, which are cached and whose sequence numbers are consecutive without jumps.

8. The method according to claim 1, characterized in that, The stopping of the currently running reordering timer specifically includes: After determining the data submission range, determine the running status of the reordering timer; If the reordering timer is running, stop and reset the reordering timer. When the reordering timer is not running, data packets are directly submitted to the upper layer.

9. A data transmission device, characterized in that, The device includes: The receiving module is used to receive packet loss notification messages from the Media Access Control (MAC) layer, wherein the packet loss notification messages include packet identifiers and transmission status identifiers; The determination module is used to determine a first sequence number corresponding to the data packet identifier based on the data packet identifier when the transmission status identifier indicates a residual packet loss confirmation status, and to determine the data delivery range based on the first sequence number; The upload module is used to stop the currently running reordering timer and submit the cached consecutive data packets within the data submission range to the upper layer.

10. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the data transmission method as described in any one of claims 1-8.

Images