HOL blocking elimination methods and systems in wireless communication systems

Abstract

This application discloses a method and system for eliminating HOL congestion in a wireless communication system, relating to wireless mobile communication and applied to a first communication device. The method includes: encapsulating a data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer transmitting entity; wherein the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; and transmitting the data PDU to a second communication device, so that a first protocol layer receiving entity in the second communication device delivers the data PDU differently based on the service identifier. This avoids low-priority data blocking high-priority data during mixed transmission of multiple services, thus alleviating HOL congestion in the wireless communication system.

Description

Technical Field

[0001] This invention relates to the field of wireless mobile communication, and particularly to a method and system for eliminating HOL congestion in wireless communication systems. Background Technology

[0002] In 5G wireless communication systems, terminals and base stations often carry a variety of mixed services, including real-time voice transmission, industrial control commands, high-definition video playback, and background network data. Different services have varying QoS (Quality of Service) requirements in terms of transmission latency, packet delivery order, and data loss tolerance. Under the existing traditional PDCP (Packet Data Convergence Protocol) transmission architecture, all PDCP data PDUs (Protocol Data Units) corresponding to all service data streams are uniformly accessed through a shared receive buffer queue. The receiving PDCP entity generally adopts a globally unified, sequential delivery mechanism, relying solely on a fixed global receive delivery window to complete data sorting and upper-layer delivery processing. This fails to provide fine-grained differentiation and control over different service streams. When network fluctuations occur, or some low-priority non-real-time service data packets experience delays, loss, or retransmission waiting, these delayed data packets continuously occupy the global delivery boundary, blocking subsequently received high-priority, latency-sensitive service data, thus triggering a typical HOL (Head of Loss) scenario. Line (i.e., line head / queue head blocking) blocking issues cause increased latency jitter in real-time services and delayed delivery of critical control commands, severely impacting the quality of transmission services in multi-service concurrent scenarios.

[0003] In current wireless transmission scenarios, transmission performance is improved solely through air interface scheduling optimization and queue rate limiting. Various service data are cached, sorted, and delivered to the upper layer according to unified rules. Service data of different priorities are coupled and related to each other. The transmission status of a single fluid will synchronously affect the overall delivery process. Various services cannot match and adapt their cache management and delivery methods according to their own operational needs. When high and low priority services are mixed and transmitted, queue head blocking is likely to occur, which continuously affects the transmission latency and overall communication quality in multi-service concurrent scenarios, making it difficult to meet the stable transmission needs of differentiated services.

[0004] In summary, how to avoid low-priority data blocking high-priority data during mixed transmission of multiple services, thereby alleviating HOL congestion in wireless communication systems, is a problem that needs to be solved in this field. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method and system for eliminating HOL congestion in a wireless communication system, thereby preventing low-priority data from blocking high-priority data during mixed transmission of multiple services and alleviating HOL congestion in the wireless communication system. The specific solution is as follows: In a first aspect, this application discloses a method for eliminating HOL (Homologous Orifice) congestion in a wireless communication system, applied to a first communication device, comprising: The first protocol layer sending entity encapsulates the data unit to be sent into a data PDU carrying a service identifier; wherein, the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; The data PDU is sent to the second communication device so that the first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier.

[0006] Secondly, this application discloses a HOL blocking elimination system in a wireless communication system, comprising a first communication device and a second communication device, wherein: The first communication device is configured to encapsulate the data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer transmission entity, and transmit the data PDU to the second communication device; wherein, the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; The second communication device is used to control the first protocol layer receiving entity to deliver the data PDU in a differentiated manner according to the service identifier.

[0007] Beneficial effects of this application: This application is applied to a first communication device, comprising: encapsulating a data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer transmitting entity; wherein the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; and transmitting the data PDU to a second communication device, so that a first protocol layer receiving entity in the second communication device delivers the data PDU differently according to the service identifier. Therefore, this application, by using a first protocol layer sending entity on the first communication device side to encapsulate the data unit to be transmitted and add data stream identifiers and / or traffic category identifiers and / or delivery type identifiers, can complete the fine-grained marking of different service data streams and different traffic priority levels during the native encapsulation stage of the data packet. This allows each PDCP data PDU to carry explicit identifier information of its own service stream attribute and priority attribute, breaking the limitation of homogeneous processing under the traditional PDCP transmission mechanism where all service data adopts the same set of sorting, caching, and delivery rules. Subsequently, the first communication device can transmit the PDCP data PDUs carrying such identifiers layer by layer to the second communication device. The first protocol layer receiving entity in the second communication device can accurately distinguish each data unit based on the service identifier carried by the PDCP data PDU. Each data PDU corresponds to a service data stream and its corresponding traffic priority level, thus no longer being restricted by the lagging data blocking of low-speed, high-latency, and non-critical services. It can flexibly match differentiated delivery strategies such as out-of-order delivery, in-order delivery, and selective discarding according to the latency requirements, order requirements, and packet loss tolerance requirements of different services. This enables high-priority latency-sensitive service data to be delivered and processed independently without being restricted by low-priority blocking data. It avoids the problem of low-speed, long-latency service data packets blocking subsequent high-priority small packets and real-time service packets caused by all service data sharing a single receive buffer window and a unified delivery order in the traditional mechanism. This reduces the transmission latency of real-time services, improves the flexibility of data transmission scheduling and the overall transmission efficiency in multi-service mixed transmission scenarios, and ultimately achieves the core effect of specifically eliminating HOL blocking in wireless communication systems. Attached Figure Description

[0008] 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0009] Figure 1 This application discloses a flowchart of a method for eliminating HOL congestion in a wireless communication system. Figure 2 This is a schematic diagram of a specific queue management logic disclosed in this application; Figure 3 This is a schematic diagram of a HOL blocking elimination device in a wireless communication system disclosed in this application; Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0010] The technical solutions of the embodiments of this 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 invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0011] In the 3GPP NR (New Radio) system, the user plane protocol stack, from top to bottom, includes: SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical Layer). Specifically, the SDAP layer is responsible for mapping QoS flows to data radio bearers (DRBs); the PDCP layer is responsible for sequence number (SN) allocation, header compression, encryption, integrity protection, reordering, and in-order delivery; the RLC layer is responsible for segmentation, ARQ retransmission (AM mode), duplicate detection, and reassembly; and the MAC layer is responsible for HARQ, scheduling, and logical channel priority processing (LCP).

[0012] Each DRB is associated with one PDCP entity. Each PDCP entity can be associated with one or more RLC entities (such as splitbearer, PDCP duplication, etc.). A PDCP entity maintains a receive window, and its core state variables include: RX_DELIV: The COUNT value of the first PDCP SDU that has not yet been delivered to the upper layer, i.e., the lower edge of the delivery window; RX_NEXT: The COUNT value of the next PDCP SDU expected to be received; RX_REORD: The COUNT value that triggers the t-Reordering timer; Window_Size: Reorder window size, equal to 2 (pdcp-SN-SizeDL-1) .

[0013] Key behaviors of the PDCP receiver: When a PDCP Data PDU is received, after decryption and integrity verification, if RCVD_COUNT = RX_DELIV, consecutive PDCP Data PDUs are delivered to the upper layer in ascending order of COUNT, and RX_DELIV is updated. If there is a SN gap (i.e., a data packet with a certain COUNT value has not yet arrived), the PDCP receive window will be blocked. Subsequent correctly arrived PDUs, even if their COUNT value is greater than RX_DELIV, cannot be delivered to the upper layer until the missing PDU arrives or t-Reordering times out.

[0014] HOL blocking is a long-standing and fundamental problem in the NR protocol stack. Based on the level and cause of blocking, it can be categorized as follows: Type 1: Cross-flow HOL blocking Within the same DRB, packets from different QoS flows share the same PDCP SN space and the same delivery window. When a PDCP SDU (e.g., a TCP ACK packet) from a low-priority / non-delay-sensitive QoS flow is lost or arrives late during transmission, the PDCP layer cannot deliver it to the upper layer even if subsequent PDCP SDUs from high-priority / delay-sensitive QoS flows (e.g., XR video frames or industrial control commands) have arrived correctly at the receiver. This is because PDCP's in-order delivery mechanism requires all COUNT values ​​to be consecutive; missing low-COUNT value packets block the entire delivery window. This blocking is known as cross-flow HOL blocking.

[0015] Type 2: Cross-packet HOL blocking

[0016] In a PDU Set (such as an XR frame) scenario, a PDU Set consists of multiple PDCP SDUs. If a data packet in a PDU Set (such as a slice in an I-frame) is lost, other data packets that have arrived correctly in the entire PDU Set cannot be delivered to the upper-layer decoder, leading to increased decoding latency or even decoding failure. This type of blocking can be called cross-packet HOL blocking.

[0017] Type 3: Low-layer HOL blocking

[0018] At the RLC and MAC layers, when a segment of an AMD PDU in RLC AM mode is lost at the HARQ layer, the RLC receiver needs to wait for the retransmission and reassembly of that segment, causing all subsequent RLC SDUs of that RLC SDU to be unable to be delivered to the PDCP layer. This blocking stems from the in-order reassembly mechanism of the RLC layer and the HARQ retransmission at the CBG (Code Block Group) level of the MAC layer.

[0019] Therefore, this application provides a HOL blocking elimination scheme in a wireless communication system to avoid low-priority data blocking high-priority data when multiple services are transmitted together, thereby alleviating HOL blocking in the wireless communication system.

[0020] See Figure 1 As shown in the embodiment of this application, a method for eliminating HOL congestion in a wireless communication system is disclosed, applied to a first communication device, comprising: Step S11: Encapsulate the data unit to be sent into a data PDU carrying a service identifier using the first protocol layer sending entity; wherein the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier.

[0021] The first communication device includes a PDCP transmitting entity, an RLC transmitting entity, a MAC transmitting entity, a PHY layer, and an air interface. The first communication device sequentially transmits the received data units to be transmitted to the PDCP transmitting entity, RLC transmitting entity, MAC transmitting entity, and PHY layer, and then transmits them to the air interface of the second communication device through the air interface of the first communication device. Wherein, the first communication device is a terminal and the second communication device is a base station, or vice versa; that is, the terminal can transmit data to the base station, or the base station can transmit data to the terminal.

[0022] When the service identifier includes a delivery type identifier, the delivery strategy corresponding to the delivery type includes any one or more of the following strategies: out-of-order delivery strategy, in-order delivery strategy, and selective discard strategy.

[0023] Furthermore, the first protocol layer transmitting entity in the first communication device has a flexible implementation form. It can be configured as a separate PDCP transmitting entity to independently complete data encapsulation and identifier addition, or it can adopt a collaborative form combining the PDCP (Packet Data Convergence Protocol) transmitting entity and the RLC (Radio Link Control) transmitting entity. The PDCP transmitting entity is responsible for data encapsulation and header identifier configuration, and the RLC transmitting entity undertakes subsequent queue management and data delivery. This adapts to different protocol architecture deployment scenarios and improves the flexibility of the solution implementation.

[0024] The following describes the processing flow of the first protocol layer sending entity in the first communication device.

[0025] In this embodiment, the step of encapsulating the data unit to be sent into a data PDU carrying a service identifier using the first protocol layer sending entity includes: encapsulating the data unit to be sent using the first protocol layer sending entity to obtain an initial PDCP data PDU, and adding a flow indicator flag and a service identifier to the header of the initial PDCP data PDU to obtain a PDCP data PDU carrying a service identifier; wherein, when the flow indicator flag is a first preset value, it indicates that the PDCP data PDU does not carry a service identifier, and when the flow indicator flag is a second preset value, it indicates that the PDCP data PDU carries a service identifier.

[0026] First, the data unit to be sent is encapsulated using the standard protocol layer. The data unit's format is standardized and protocol fields are encapsulated according to the protocol specifications to generate an initial PDCP data PDU in basic format. Further, an identifier field is reserved in the header of the initial PDCP data PDU, and a flow indicator flag F and a service identifier are embedded. The service identifier includes a data flow identifier SDF_ID and / or a traffic category identifier TC and / or a delivery type identifier. By explicitly adding a dedicated identifier field to the message header, additional markings are added to the PDCP data PDU attributes, ultimately forming a complete PDCP data PDU carrying identifier information. The flow indicator flag uses a dual-preset value definition method to distinguish states. The flow indicator flag is configured... When the flow indicator flag is set to the first preset value, it explicitly indicates that the current PDCP data PDU header does not have any service identifier configured, maintaining the traditional protocol message format and backward compatibility. When the flow indicator flag is configured to the second preset value, it explicitly indicates that the current PDCP data PDU header has a complete service identifier configured. This allows the receiving end to quickly determine the presence of a service identifier by first checking the flow indicator flag when parsing the message, and can quickly jump to the corresponding processing logic without redundant parsing. By relying on the combined setting of the flow indicator flag and the service identifier, it is possible to achieve message-level marking of different service data streams and their traffic priority levels, while also taking into account the normal transmission adaptation of traditional data packets, ensuring that the old and new message formats can coexist, be recognized, and be transmitted compatiblely in the same communication system; as shown in Table 1: Table 1

[0027] In this embodiment, the data stream identifier is used to characterize the service data stream to which the PDCP data PDU belongs, and the traffic category identifier is used to characterize the traffic category to which the service data stream belongs or the traffic priority level of the service data stream; wherein, if the service identifier only includes the data stream identifier, the data stream identifier is also used to deduce the traffic priority level of the service data stream.

[0028] In scenarios where both SDF_ID and TC are standardized, they work together to achieve synergistic effects. SDF_ID enables fine-grained division of service flows, distinguishing up to seven independent service data flows. TC, on the other hand, provides a four-level unified priority mapping, which can further differentiate the urgency of different messages within the same service data flow. It can map different priority forms of video services, such as I-frames and P-frames, to the corresponding TC levels, achieving multi-level differentiated management within the same flow.

[0029] In scenarios where only SDF_ID or only TC is standardized, one type of identifier can be omitted as needed. When only SDF_ID is used, it can distinguish service flows on its own. Priority can be implicitly inferred from the identifier value, and corresponding TC mapping values ​​can be configured for each SDF_ID using RRC signaling. That is, if the service identifier only includes the data flow identifier, the data flow identifier is also used to infer the traffic priority level of the service data flow. When only TC is used for standardization, SDF_ID can be omitted, and four priority levels can be divided using 2 bits of TC. The RLC sender performs queue scheduling based on TC, and the PDCP receiver completes differentiated delivery based on TC.

[0030] The PDU format (12-bit SN) is illustrated below: Byte 0: D / C(1) | F(1) | R | PDCP SN (highest 5 bits); Byte 1: PDCP SN (lower 7 bits) | SDF_ID (3 bits) [or TC (2 bits) + R]; Byte 2: TC (2 bits) | R (6 bits) [or SDF_ID (3 bits) + R (3 bits)]; Byte 3+: Data.

[0031] In this embodiment, the data unit to be sent is a PDCPSDU obtained using the SDAP layer of the first communication device; the encapsulation of the data unit to be sent by the first protocol layer sending entity to obtain an initial PDCP data PDU includes: obtaining QoS flow information associated with the data unit to be sent; wherein, the QoS flow information includes any one or more of the following: QoS flow identifier, PDU Set identifier, IP 5-tuple, and differentiated service code point; mapping the QoS flow information to a service identifier using the first protocol layer sending entity, and performing header compression, decompression, encryption, and integrity protection processing on the data unit to be sent to obtain the PDCP data PDU.

[0032] Specifically, taking the PDCP sending entity as an example, the first protocol layer sending entity first receives the data unit to be sent from the upper protocol layer. The first protocol layer sending entity receives higher-layer data and obtains QoS information. Specifically, when the PDCP receiving entity receives the PDCP SDU from the upper layer (SDAP layer), it simultaneously obtains the associated QoS flow information. This information may include at least one of the following: QFI (QoS Flow Identifier, 6 bits), from the SDAP header; PDU Set identifier, used by XR services to indicate the PDU Set to which the SDU belongs; IP 5-tuple (source / destination IP, source / destination port, protocol type); DSCP (Differentiated Services Code Point, 6 bits) comes from the IP header; The upper layer transmits the above information to the PDCP sending entity through the PDCP-SAP primitive.

[0033] Secondly, the first protocol layer sending entity maps QoS flow information to service identifiers. The sending end PDCP entity maps the QoS flow information provided by the upper layer to an identifier field according to the "SDF mapping table" pre-configured by RRC. The mapping rules are as follows: 1) If SDF differentiation is not configured (`sdf-DifferentiationEnabled = FALSE`), then SDF_ID=0 (default stream), F=0, and no extended header is carried. This is backward compatibility mode.

[0034] 2) If SDF differential processing is configured, the entries in the SDF mapping table are traversed (in descending order of priority), and the QoS flow information is matched with the matching rules (qfi-list / 5-tuple / dscp-range) of each entry.

[0035] 3) If a match is successful, the corresponding SDF_ID and TC are returned; if no match is found, SDF_ID=0 and F=0.

[0036] Specifically, the mapping rules for service identifiers include data flow identifiers and / or traffic category identifiers: When only SDF_ID is standardized (i.e., the service identifier only includes the data flow identifier): the TC field is absent or reserved, and the scheduling and delivery policies are based entirely on the priority determined by the SDF_ID.

[0037] When only TC is standardized (i.e., the service identifier only includes the traffic category identifier): SDF_ID does not exist or is reserved, and the scheduling and delivery strategy is directly determined based on TC.

[0038] When both are standardized (i.e., the service identifier includes the data flow identifier and / or traffic category identifier): SDF_ID is used for flow level differentiation, and TC is used for priority scheduling.

[0039] Next, the data units to be sent undergo header compression, decompression, encryption, and integrity protection to obtain PDCP data PDUs. It's important to note that there are two processing methods at this point: First, if SDF differentiation processing is not configured (i.e., the flow indicator flag is the first preset value of 0), the traditional process should be followed. Second, if SDF differentiation processing is configured (i.e., the flow indicator flag is the second preset value of 1), the PDCP data PDU is constructed and its header fields are set.

[0040] The first procedure is as follows: Associate the COUNT value (= TX_NEXT) with this PDCP SDU; Start discardTimer (if configured); Perform header compression (ROHC / EHC) and decompression; Perform uplink data compression (if configured); Perform integrity protection and encryption.

[0041] The second process is as follows: When constructing PDCP data PDUs, the header fields are set according to the mapping results: If `flow_enabled=TRUE` and `SDF_ID≠0`, then set F=1, fill in the SDF_ID and TC fields, and perform header compression, decompression, encryption, and integrity protection. Otherwise, set F=0 to exclude extended fields.

[0042] Finally, the PDCP data PDU is submitted to the lower layer, the PDCP SN is set, and TX_NEXT is incremented. The completed PDCP data PDU is submitted to the lower layer RLC sending entity (i.e., the second protocol layer sending entity), and TC information is transmitted through the cross-layer interface (if the standardization only includes SDF_ID, then the default TC mapped by SDF_ID is transmitted).

[0043] Step S12: Send the data PDU to the second communication device so that the first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier.

[0044] In the process of sending the data PDU to the second communication device, the PDCP data PDU is sent sequentially to the second protocol layer sending entity, the MAC sending entity, and the PHY sending entity, and then transmitted to the air interface of the second communication device through the air interface of the first communication device.

[0045] Specifically, sending the data PDU to the second communication device so that the first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier includes: sequentially sending the PDCP data PDU to the second protocol layer sending entity, the MAC sending entity, and the PHY sending entity, and transmitting it through the air interface of the first communication device to the air interface of the second communication device, so that the PDCP data PDU can be sequentially transmitted through the PHY receiving entity, the MAC receiving entity, and the second protocol layer receiving entity of the second communication device to the first protocol layer receiving entity, and the first protocol layer receiving entity can deliver the PDCP data PDU differently according to the service identifier.

[0046] The first communication device delivers the encapsulated PDCP data PDU, carrying the service identifier, layer by layer down to the second protocol layer sending entity, MAC sending entity, and PHY sending entity. Then, it completes wireless transmission through the air interface of the first communication device and delivers it to the air interface side of the second communication device. Subsequently, the second communication device sequentially parses and transmits the PDCP data PDU through its own PHY receiving entity, MAC receiving entity, and second protocol layer receiving entity, and finally delivers it completely to the first protocol layer receiving entity. The first protocol layer receiving entity identifies the service identifier carried by the PDCP data PDU and performs differentiated delivery processing on the PDCP data PDU according to the service flow attributes and priority rules corresponding to the identifier.

[0047] The execution process of the second protocol layer sending entity is described in detail below. The core is to split the single buffer of the RLC sending entity into multiple independent priority queues and adopt a strict priority scheduling strategy; data PDUs are inserted into the queues of the corresponding priorities according to the SDF_ID and / or TC information provided by the PDCP layer, ensuring that high-priority data is always scheduled first.

[0048] In this embodiment, the second protocol layer sending entity includes a data PDU queue, wherein the data PDU queue includes multiple sub-queues; sending the PDCP data PDUs sequentially to the second protocol layer sending entity and the MAC sending entity includes: if the PDCP data PDU is a data type PDU, then inserting the PDCP data PDU into the corresponding sub-queue in the data PDU queue based on the service identifier; in the current transmission opportunity, scheduling the data type PDUs in each sub-queue of the data PDU queue and delivering them to the MAC sending entity.

[0049] Specifically, the queue architecture for sending entities at the second protocol layer consists of the following: The RLC sending entity maintains the following independent queues: 1) Control PDU Queue (CPQ): This queue is specifically used to store control PDUs.

[0050] 2) Data PDU Queue (DPQ): Divided into 4 sub-queues based on traffic category SDF_ID and / or TC, as follows (the following example uses TC to distinguish data by queue): Q0 (TC=0, Delay Critical): Delay-critical data, highest priority; Q1 (TC=1, Streaming): Streaming data; Q2 (TC=2, Interactive): Interactive data; Q3 (TC=3, Best Effort): Best-effort data, lowest priority; 3) Priority Merger: In each transmission opportunity, it selects PDUs from the above queues according to strict priority and submits them to the MAC layer.

[0051] First, the RLC sending entity performs PDU type identification and TC acquisition. When the RLC sending end receives a PDU from the PDCP layer, the PDCP layer transmits the following information through the cross-layer interface: PDU type: Data PDU or Control PDU; If it is a data PDU: the TC value (0-3) is also transmitted. This TC value comes from the TC field in the PDCP data PDU header (or is obtained by mapping from SDF_ID). If it is a control PDU: it is marked as a control PDU and has no TC value.

[0052] Next, perform the enqueue operation. Insert the PDCP data PDU into the corresponding subqueue in the data PDU queue, specifically as follows: Figure 2 As shown.

[0053] In scenarios where both SDF_ID and TC are standardized, the RLC layer uses the traffic category identifier TC as the main basis for queue classification to complete the queue insertion of data PDUs. At the same time, it uses the data flow identifier SDF_ID to achieve more granular business flow division, and completes accurate flow level differentiation and management within the same priority under a unified priority framework.

[0054] In scenarios where only SDF_ID standardization or only TC standardization is used, the RLC layer adapts different queue mapping logics after receiving the identification information sent by the PDCP layer. When only SDF_ID standardization is used, the RLC assigns the data PDU to the corresponding priority queue according to the SDF_ID and priority mapping relationship configured by the RRC signaling. When only TC standardization is used, the RLC directly inserts the data PDU into the matching scheduling queue according to the received 2-bit TC value.

[0055] Based on the type of PDU, there are two specific cases: Scenario A: Control PDU arrives. Insert the control PDU into the CPQ (Control PDU Queue). The CPQ uses a FIFO order, but PDUs in the CPQ take precedence over PDUs in any DPQ.

[0056] Scenario B: Data PDU arrives. Insert the data PDU into the corresponding DPQ sub-queue based on the TC value: If TC=0 (DelayCritical), then insert into queue Q0; If TC=1 (Streaming), then insert into queue Q1; If TC=2 (Interactive), then insert into queue Q2; If TC=3 (BestEffort), then insert into queue Q3; Each sub-queue is arranged in FIFO order.

[0057] Next, segmentation is performed. When an RLC PDU needs to be segmented (UM / AM mode), the segmentation operation is performed independently within each queue. The segmented RLC PDU fragments inherit the TC classification (or mapped priority) of their parent PDU and remain in the original queue.

[0058] Furthermore, in the current transmission opportunity, the second protocol layer sending entity schedules the data class PDUs of each sub-queue in the data PDU queue and submits them to the MAC sending entity.

[0059] In this embodiment, the data class PDUs of each sub-queue in the data PDU queue are scheduled in the following ways: according to the priority of each sub-queue in the data PDU queue, the data class PDUs of each sub-queue are scheduled sequentially; or, the data class PDUs of each sub-queue are scheduled in a weighted round-robin manner.

[0060] Enqueueing rules: PDCP data PDUs are inserted into the corresponding DPQ subqueues according to TC (or TC mapped by SDF_ID).

[0061] Scheduling rule: CPQ > Q0 > Q1 > Q2 > Q3 (strict priority).

[0062] Transparent to the MAC layer: The MAC layer still sees a data stream of a logical channel. The multi-queue implementation inside the RLC is completed inside the RLC layer.

[0063] This embodiment has two scheduling methods. The first scheduling method is as follows: In each MAC transfer opportunity, the priority merger executes the following strict priority scheduling algorithm: Scheduling order: (1) Check the CPQ (Control PDU queue): If CPQ is not empty, take a control PDU from the CPQ header, construct an RLC PDU and submit it to the MAC layer; If CPQ is empty, proceed to step (2).

[0064] (2) Check Q0 (Delay Critical queue): If Q0 is not empty, take a data PDU (or its segment) from the head of Q0, construct an RLC PDU and submit it to the MAC layer; If Q0 is empty, proceed to step (3).

[0065] (3) Check Q1 (Streaming queue): Similar to the logic described above.

[0066] (4) Check Q2 (Interactive queue): Similar to the logic described above.

[0067] (5) Check Q3 (Best Effort queue): Similar to the logic described above.

[0068] The second scheduling method is as follows: When a certain throughput guarantee is required for low-priority queues, weighted round-robin can be used, with the weights dynamically adjusted via RRC signaling configuration or MAC CE. 1) Prioritize CPQ service (always prioritize). 2) For Q0-Q3, resources are allocated in a round-robin fashion according to the configured weights (e.g., 8:4:2:1).

[0069] In this embodiment, the delivery to the MAC sending entity includes: if the second protocol layer sending entity receives a retransmission instruction, determining the data unit to be retransmitted from the data PDU queue according to the retransmission instruction; wherein, the data unit to be retransmitted is a PDCP data PDU or a segment of a PDCP data PDU; keeping the traffic category classification and mapping priority of the data unit to be retransmitted unchanged; if the traffic category of the data unit to be retransmitted is not empty, inserting the data unit to be retransmitted into the head of the corresponding sub-queue in the data PDU queue based on the traffic category of the data unit to be retransmitted; if the traffic category of the data unit to be retransmitted is empty, inserting the data unit to be retransmitted into the head of the highest priority sub-queue in the data PDU queue.

[0070] It is important to note the retransmission handling in AM mode. When an RLC AM entity receives a STATUS PDU indicating that a certain RLC SDU or SDU segment needs to be retransmitted: Retransmitted SDUs / segments retain their original TC classification (or mapped priority). Retransmitted data is inserted at the head of the corresponding TC queue (with priority over new data in the queue) to ensure that retransmitted data is scheduled as soon as possible; If the TC=0 (Delay Critical) of the retransmitted SDU, it is inserted at the head of the Q0 queue and obtains the highest scheduling priority (second only to CPQ).

[0071] Finally, the second protocol layer sends the data to the MAC layer, and the data selected by the scheduler (RLC PDU) is submitted to the MAC layer for transmission. In AM mode, the RLC maintains both the retransmission buffer and the ARQ state variable.

[0072] In this embodiment, transmitting PDCP data PDUs to the first protocol layer receiving entity through the second protocol layer receiving entity of the second communication device includes: identifying the type of PDCP data PDUs through the second protocol layer receiving entity of the second communication device; if the PDCP data PDU is a control type PDU, submitting the PDCP data PDU to the RLC layer to transmit the PDCP data PDU to the first protocol layer receiving entity; if the PDCP data PDU is a data type PDU, reassembling and reordering the PDCP data PDU before transmitting the PDCP data PDU to the first protocol layer receiving entity.

[0073] The processing flow for the RLC receiving entity is as follows: 1) PDU reception and type identification: After receiving the RLC PDU from the MAC layer of the second communication device, the RLC receiver first identifies the PDU type. If it is a control PDU (RLC STATUS PDU): it is immediately submitted to the RLC control plane for processing without going through any data queue; if it is a data PDU (AMD / UMD PDU): it enters the RLC reassembly buffer and is reassembled and sorted according to the RLC SN.

[0074] 2) Reassembly and data extraction: In UM mode, the complete RLC SDU is reassembled based on SN and segment offset; in AM mode, the complete RLC SDU is reassembled based on SN and segment offset and moved into the reordering buffer.

[0075] 3) Delivery to the PDCP layer of the second communication device. The reassembled RLC SDU is delivered to the PDCP layer in the order of RLC SN. The RLC layer does not need to know the SDF_ID or TC information inside the PDU; all differentiation processing can be completed at the RLC sender.

[0076] 4) STATUS PDU Generation and Feedback. When the RLC receiver detects missing data (e.g., t-Reassembly timeout or receipt of the POLL flag), it generates a STATUS PDU. This STATUS PDU serves as an RLC control PDU and is sent via CPQ (see Scheme 3), without being blocked by the data queue.

[0077] It should be noted that the second protocol layer sending entity also includes a control PDU queue and a priority merger; sending the PDCP data PDU to the MAC sending entity includes: receiving the PDCP data PDU using the second protocol layer sending entity; if the PDCP data PDU is a control class PDU generated by the second protocol layer sending entity, inserting the PDCP data PDU at the tail of the control PDU queue; if the PDCP data PDU is a control class PDU generated by the first protocol layer sending entity, inserting it into the corresponding position in the control PDU queue according to the urgency of the PDCP data PDU; in the current transmission opportunity, checking whether the control PDU queue is empty using the priority merger; if the control PDU queue is not empty, retrieving the PDCP data PDU from the head of the control PDU queue and transmitting it to the MAC sending entity; if the control PDU queue is empty, jumping to the steps of data class PDUs in each sub-queue of the scheduling data PDU queue.

[0078] The core of this embodiment is to completely separate the control PDU from the data PDU queue, establish an independent control PDU queue (CPQ), and assign the CPQ super priority so that it can preempt the data PDU transmission resources in any transmission opportunity.

[0079] The RLC transmitter receives control PDUs from the following two sources: Internal generation: The STATUS PDU generated by the RLC AM entity itself is triggered by the RLC internal state machine; STATUSPDU: used for ARQ feedback, reporting the receiver's reception status and triggering the sender to retransmit. Triggering conditions include: receiving the polling (POLL) flag, t-Reassembly timeout, or t-StatusProhibit timer timeout.

[0080] External reception: PDCP control PDUs submitted by the PDCP entity through a cross-layer interface, carrying a "control PDU" indication and / or an Urgent flag. Specifically, this includes the following types: PDCP Status Report: Used for faster feedback, triggering PDCP layer retransmission; Interspersed ROHC Feedback: Header compressed feedback information used for ROHC channel status maintenance; EHC Feedback: EHC (Ethernet Header Compression) feedback; UDC Feedback: Uplink data compression feedback; PDCP SN Gap Report: Used to report PDCP SN gaps.

[0081] Enhanced Urgent Flag for Control PDUs: To further differentiate the urgency level of control PDUs, a U (Urgent) flag is introduced into the PDCP control PDU header. U=0: Normal control PDU; U=1: Emergency control PDU, which requires the highest priority transmission.

[0082] For control PDUs, differentiated queuing processing is performed according to their source and urgency. Status PDUs generated by RLC are directly stored at the tail of the control PDU queue. PDCP control PDUs with U identifier 0 are also inserted at the tail of the control PDU queue, while emergency PDCP control PDUs with U identifier 1 are inserted at the head of the control PDU queue, so that they can be scheduled and sent with priority over other control PDUs in the queue.

[0083] During each MAC transmission opportunity, the priority merger performs queue scheduling according to fixed scheduling rules. First, it checks the status of the control PDU queue. If the queue is not empty, it takes the control PDU from the head of the queue, encapsulates it into an RLC PDU, and submits it to the MAC layer. If the queue is empty, it switches to the data PDU queue for scheduling. It is important to note that a preemption mechanism is set as a key enhancement strategy. Even in the same transmission opportunity, if a new control PDU enters the queue during the transmission of data PDUs, the control PDU can be scheduled first in the next transmission opportunity. During scheduling, the control PDU queue must be checked first. When it is not empty, the transmission of the current data PDU can be interrupted at the segment boundary to transmit the control PDU first. After the control PDU is transmitted, the interrupted data PDU transmission process is resumed from the remaining segment position.

[0084] In this embodiment, it further includes: when the control PDU queue changes from empty to non-empty, the control second protocol layer sending entity notifies the MAC sending entity through cross-layer signaling to prioritize the scheduling of the logical signal bound to the control PDU queue.

[0085] When the control PDU queue changes from an idle state to a data buffered state, the RLC can send a notification to the MAC layer through cross-layer signaling to request priority scheduling of the bound logical channel, thereby further reducing the scheduling latency of the control PDU. After receiving the cross-layer notification, the MAC layer will prioritize the allocation of air interface transmission resources for the corresponding logical channel in the logical channel priority processing flow.

[0086] The RLC receiving entity maintains a simple and efficient processing style for control PDUs: 1) PDU type identification: After receiving the RLC PDU from the MAC layer of the second communication device, the RLC receiving entity parses the D / C field (data / control indication) in the PDU header: D / C=0: Control PDU; D / C=1: Data PDU.

[0087] 2) Prioritize control PDU processing: When a control PDU (RLC STATUS PDU) is received, it is submitted immediately, that is, directly submitted to the RLC layer for processing, without going through any data queue or waiting for reassembly; no waiting: there is no need to wait for data PDUs that have arrived but not yet been processed, nor is there a need to wait for the order of RLC SNs.

[0088] 3) Normal processing of data PDUs: If a data PDU is received, it is reassembled and sorted before being delivered to the PDCP layer of the second communication device.

[0089] The first protocol layer receiving entity has a flexible deployment and adaptation mode. It can be deployed as a separate PDCP receiving entity to independently complete the entire process of protocol data unit parsing, service identifier identification, and differentiated delivery. Alternatively, it can adopt a combination of PDCP receiving entity and RLC receiving entity working together. The RLC receiving entity first completes data reassembly, reordering, and frame processing before submitting it to the PDCP receiving entity. Then, the PDCP receiving entity completes the subsequent identification, interpretation, and differentiated delivery control based on the service identifier. It can adapt to the deployment requirements of different wireless communication protocol architectures, improving the overall compatibility and flexibility of the solution.

[0090] The following section provides a detailed explanation of the execution process of the receiving entity at the first protocol layer.

[0091] The first protocol layer receiving entity in the second communication device delivers the data PDU differently based on the service identifier, including: parsing the PDCP data PDU and calculating a reception count value based on the reception sequence number and global reception delivery parameters of the PDCP data PDU; decrypting and verifying the integrity of the PDCP data PDU using the reception count value; if the integrity verification is successful, performing a duplicate detection using the reception count value; if the duplicate detection result indicates that the PDCP data PDU has not been received, then delivering the PDCP data PDU differently based on the service identifier of the PDCP data PDU.

[0092] In this embodiment, the data PDU is delivered in a differentiated manner according to the service identifier of the data PDU, including: if the flow indicator flag of the PDCP data PDU or the data flow identifier is a first preset value, the PDCP data PDU is delivered to the target application in sequence; if the flow indicator flag of the PDCP data PDU is a second preset value and the data flow identifier is not a first preset value, the PDCP data PDU is selectively delivered to the target application.

[0093] If the flow indicator flag or data flow identifier of the PDCP data PDU is a first preset value of 0, the PDCP data PDU will be delivered to the target application in sequence; if the flow indicator flag of the PDCP data PDU is a second preset value of 1 and the data flow identifier is not a first preset value of 0, the PDCP data PDU will be delivered to the target application selectively.

[0094] In this embodiment, the selective delivery of the PDCP data PDU to the target application includes: storing the PDCP data PDU in the corresponding SDF receive queue and sorting it according to the receive count value; updating the single-stream expected receive value and the global expected receive value of the SDF receive queue; determining the delivery strategy of the PDCP data PDU according to the service data stream to which the PDCP data PDU belongs, and delivering the PDCP data PDU to the target application according to the delivery strategy; wherein, the delivery strategy is any one of the out-of-order delivery strategy, the in-order delivery strategy, and the selective discard strategy.

[0095] The specific differentiated data delivery strategy of the PDCP receiver is as follows: 1. If the delivery strategy is an out-of-order delivery strategy, the PDCP SDU corresponding to the PDCP data PDU is delivered to the upper protocol layer, the single-stream receive delivery parameters of the service data stream to which the PDCP data PDU belongs are updated, and the PDCP data PDUs that have arrived and are consecutive in the SDF receive queue are detected and delivered to the target application synchronously. Then the global receive delivery parameters are updated. 2. If the delivery strategy is an in-order delivery strategy, then check whether all PDCP data PDUs corresponding to consecutive count values ​​starting from the single stream expected reception value in the SDF receiving queue have been received. If all have been received, then deliver consecutive PDCP data PDUs in batches and update the single stream receiving delivery parameters. If there are missing PDCP data PDUs in the SDF receiving queue, then pause delivery and wait for the missing PDCP data PDUs, and update the global receiving delivery parameters. 3. If the delivery strategy is a selective discard strategy, then the PDCP data PDUs that arrive consecutively are delivered in order. If the reordering timer times out, the PDCP data PDUs that time out and are missing in the SDF receive queue are marked as discarded PDCP data PDUs. The PDCP data PDUs that arrive consecutively after the discarded PDCP data PDUs are delivered, and the global receive delivery parameters are updated.

[0096] It should be noted that in this embodiment, it also includes: the first protocol layer receiving entity in the second communication device obtains differentiated delivery authorization licenses from the network side by differentially delivering the data PDU based on the service identifier.

[0097] If the second communication device is a terminal device, the network side needs to uniformly configure the terminal's Data Radio Bearer (DRB) which supports differentiated delivery of data streams with three processing policies in advance: out-of-order delivery, in-order delivery, and selective discarding. Only after the network side completes the configuration authorization can the terminal choose to enable the corresponding processing method to process the received protocol data according to the actual data reception situation. It does not have to use only one mode and can flexibly switch delivery and discarding rules according to the actual transmission needs of the business.

[0098] The PDCP receiver determines which delivery method to use for a given data packet based primarily on the SDF_ID (Service Flow Identifier) ​​and / TC (Traffic Category Identifier) ​​carried in the packet header, as shown in the table below. The delivery method for each packet can be determined through a predefined table, and the receiver confirms the packet delivery strategy based on the TC value.

[0099] Table 2

[0100] Alternatively, a mapping table between SDF_ID and submission strategy can be considered, as shown in Table 3: Table 3

[0101] Optionally, a separate bit can be used in the PDCP packet header to indicate the delivery mechanism, i.e., a DeliveryType field can be added to the header, which is a delivery type identifier. The receiving end can directly deliver the corresponding data packet based on this field, as shown in Table 4: Table 4

[0102] For PDCP receivers to perform Per-SDF differentiated delivery, it is necessary to consider enhancing the receiver's state variables. The following are the newly enhanced PDCP receiver window variables: Table 5

[0103] The specific process is as follows: Phase 1: PDU header parsing and stream identification.

[0104] 1) Parsing the PDU header: 1.1) After receiving PDCP data PDU from the lower layer, the receiving PDCP entity parses the header, reads the D / C field, and confirms that it is a data PDU (D / C=1). 1.2) Read the F flag: If F=0: the PDU does not contain the SDF_ID and TC fields, and is processed according to the existing PDCP receiving procedure and assigned to the default stream (SDF_ID=0); if F=1: continue to read the SDF_ID (3 bits) and TC (2 bits) fields.

[0105] 2) COUNT value calculation: RCVD_COUNT is calculated using RCVD_SN and RX_DELIV. The COUNT value derivation is still based on the global RX_DELIV, rather than the per-SDF rx_deliv_sdf, to ensure the safety of the derivation.

[0106] Phase Two: Decryption and Integrity Verification.

[0107] 3) Decryption and Integrity Verification: Decryption and integrity verification are performed using RCVD_COUNT as input. If integrity verification fails, the PDU is discarded and a failure is reported; if successful, the process continues.

[0108] Phase 3: Repeated testing and discarding.

[0109] 4) Duplicate detection: If RCVD_COUNT < RX_DELIV or the PDU corresponding to RCVD_COUNT has already been received, discard the duplicate PDU.

[0110] Phase 4: Processing based on SDF_ID.

[0111] 5) Determine the processing path: If F=0 (i.e., the first preset value 0) or SDF_ID=0 or the SDF is not enabled for differentiated processing: enter the traditional processing path (strictly delivered in sequence); if F=1 (i.e., the second preset value 1) and SDF_ID>0 and the SDF is enabled for differentiated processing: enter the enhanced processing path (Per-SDF selective delivery).

[0112] Phase 5: Strictly in sequence delivery.

[0113] 6.a) Strictly in order of delivery: 6.a.1) Store the PDCP SDU in the default receive buffer; 6.a.2) If RCVD_COUNT >= RX_NEXT, update RX_NEXT = RCVD_COUNT + 1; 6.a.3) If RCVD_COUNT == RX_DELIV, starting from RX_DELIV, deliver consecutive PDCP SDUs to the upper layer in ascending order of COUNT, and update RX_DELIV to the first COUNT value that has not yet been delivered; 6.a.4) t-Reordering management: If the timer is running and RX_DELIV >= RX_REORD, stop and reset the timer; if it is not running and RX_DELIV < RX_NEXT, set RX_REORD = RX_NEXT and start the timer.

[0114] Phase Six (Enhanced Path): Per-SDF Selective Delivery.

[0115] 6.b), which includes the following sub-steps: 6.b.1) Store in SDF receive queue: Store the decrypted PDCP SDU into the logical receive queue corresponding to SDF_ID, sorted by COUNT value to ensure that the queue is always ordered.

[0116] 6.b.2) Update SDF state variables: Update the expected receive value and global expected receive value of this SDF, as follows: If RCVD_COUNT >= per_sdf[sdf_id].rx_next_sdf: per_sdf[sdf_id].rx_next_sdf = RCVD_COUNT + 1; If RCVD_COUNT >= RX_NEXT: RX_NEXT = RCVD_COUNT + 1; 6.b.3) Perform selective delivery based on delivery policy: Perform differentiated delivery decisions based on `per_sdf[sdf_id].delivery_policy`.

[0117] In this embodiment, delivering the PDCP data PDU to the target application according to the delivery strategy includes: if the delivery strategy is an out-of-order delivery strategy, then delivering the PDCP corresponding to the PDCP data PDU to the target application. The SDU is delivered to the upper protocol layer, updating the single-stream receive delivery parameters of the service data stream to which the PDCP data PDU belongs. It also detects arrived and consecutively received PDCP data PDUs in the SDF receive queue for synchronous delivery to the target application, and then updates the global receive delivery parameters. If the delivery strategy is an in-order delivery strategy, it checks whether all PDCP data PDUs corresponding to consecutive counts from the single-stream expected receive value in the SDF receive queue have been received. If all have been received, consecutively received PDCP data PDUs are delivered in batches, and the single-stream receive delivery parameters are updated. If there are missing PDCP data PDUs in the SDF receive queue, delivery is paused, and the missing PDCP data PDUs are awaited, while the global receive delivery parameters are updated. If the delivery strategy is a selective discard strategy, consecutively arriving PDCP data PDUs are delivered in order first. If the reordering timer times out, the timed-out missing PDCP data PDUs in the SDF receive queue are marked as discarded PDCP data PDUs, and PDCP data PDUs arriving consecutively after the discarded PDCP data PDUs are delivered, while the global receive delivery parameters are updated.

[0118] Specifically as follows: Case A: Delivery strategy is OUT_OF_ORDER (out-of-order delivery); Applicable scenarios: Traffic with extremely high latency sensitivity (TCP ACK, VoIP voice packets, industrial control commands).

[0119] Processing logic: 1. Immediately deliver the current PDCP SDU to the upper protocol layer (execute header decompression); 2. Update `per_sdf[sdf_id].rx_deliv_sdf = RCVD_COUNT + 1`; 3. Check if there are any other arrived consecutive SDUs in the SDF queue that can be delivered together; 4. Proceed to substep 6b-4 to update global RX_DELIV.

[0120] Case B: The delivery strategy is IN_ORDER (deliver in order); Applicable scenarios: Traffic that needs to maintain order (video I-frame fragmentation, file transfer blocks).

[0121] Processing logic: 1. Check if all SDUs with consecutive COUNT values ​​starting from `per_sdf[sdf_id].rx_deliv_sdf` in the SDF queue have arrived; 2. If so, deliver these consecutive SDUs to the upper layer and update `per_sdf[sdf_id].rx_deliv_sdf` to the first COUNT value that has not yet been delivered; 3. If not, do not execute the delivery, and wait for the missing SDU to arrive; 4. Proceed to step 6.b.4) Update global RX_DELIV.

[0122] Case C: Delivery strategy is SELECTIVE_DISCARD (selective discard); Applicable scenarios: Traffic that can tolerate a small amount of packet loss (non-critical video frames, background data).

[0123] Processing logic: 1. Similar to IN_ORDER, SDUs arriving consecutively are delivered in order; 2. When t-Reordering times out, for missing SDUs in the SDF queue whose COUNT value is less than RX_REORD, mark them as "discarded"; 3. Submit subsequent SDUs to the upper layer; 4. Proceed to step 6.b.4) Update global RX_DELIV.

[0124] 6.b.4) Global RX_DELIV Update (Window Movement Logic) This is the most critical part of this embodiment. After selective delivery, the delivery edges of each SDF may be inconsistent. The global RX_DELIV needs to correctly reflect the delivery progress of all SDFs.

[0125] In a specific update embodiment, updating the global receive delivery parameters includes: selecting the minimum value among the single-stream receive delivery parameters corresponding to each service data stream as the update reference value of the global receive delivery parameters; if the update reference value is greater than the current global receive delivery parameters and the current global receive delivery parameters are greater than the delivery lower edge of each service data stream and less than or equal to the upper limit of the receive window, then the current global receive delivery parameters are determined as the updated global receive delivery parameters.

[0126] Global RX_DELIV advancement rules: RX_DELIV_new = min( The traditional default stream's rx_deliv_sdf, / / delivery falling edge when SDF_ID=0 or F=0; per_sdf[1].rx_deliv_sdf, / / Delivery edge of SDF 1; per_sdf[2].rx_deliv_sdf, / / Delivery edge of SDF 2; ... per_sdf[7].rx_deliv_sdf / / Delivery edge of SDF 7; ) If RX_DELIV_new > RX_DELIV: RX_DELIV = RX_DELIV_new; Detailed Rules Explanation: Safety boundary rule: The global RX_DELIV cannot exceed the delivery edge of any SDF. This ensures that no SDF data is "lost" before global delivery.

[0127] Continuous advancement rule: After RX_DELIV advances, check whether it can continue to advance, and use a cyclic advancement method until convergence.

[0128] Window protection rule: RX_DELIV cannot exceed RX_NEXT - 1, meaning it cannot advance to a region where no stream has yet been received.

[0129] In another specific update embodiment, updating the global receive delivery parameters includes: if the service identifier only includes a data stream identifier, then updating the global receive delivery parameters based on the minimum value among the single-stream receive delivery parameters corresponding to each service data stream; if the service identifier only includes a traffic category identifier, then updating the global receive delivery parameters based on the minimum value of the single-stream delivery lower edge of the traffic category of each service data stream.

[0130] When only TC is normalized, the global RX_DELIV is the minimum of all per-TC delivery falling edges; when only SDF_ID is normalized, it is the minimum of all per-SDF delivery falling edges.

[0131] Step 6.b.4) t-Reordering timer management

[0132] If t-Reordering is running and RX_DELIV >= RX_REORD: Stop and reset t-Reordering; If t-Reordering is not running and RX_DELIV < RX_NEXT: Set RX_REORD = RX_NEXT; Start t-Reordering; The activation of t-Reordering depends on the relationship between the global RX_DELIV and RX_NEXT, and is not affected by the state of a single SDF. t-Reordering will run as long as there is a missing packet in any SDF.

[0133] When t-Reordering times out, the first protocol layer receiving entity of the second communication device performs the following enhanced delivery procedure: Phase 1: Forced delivery with a global low COUNT value.

[0134] All stored PDCP SDUs (regardless of which SDF they belong to) with a COUNT value < RX_REORD are submitted to the upper layer. These SDUs are considered "safe" after the t-Reordering timeout, even if there are missing COUNT values, they are considered lost.

[0135] Phase 2: Per-SDF selective discard processing.

[0136] For each SDF f with the SELECTIVE_DISCARD policy enabled: Check the range from per_sdf[f].rx_deliv_sdf to RX_REORD-1 in the SDF queue; The SDUs that have arrived are submitted to the upper layer; Mark missing SDUs as "discarded"; Update per_sdf[f].rx_deliv_sdf to the first COUNT value that has not yet been delivered (or marked as discarded).

[0137] Phase 3: Global state update.

[0138] Update global RX_DELIV = min(rx_deliv_sdf of all SDFs); If RX_DELIV < RX_NEXT, set RX_REORD = RX_NEXT and restart t-Reordering.

[0139] In traditional transmission architectures, control PDUs and data PDUs are scheduled in a mixed manner. High-urgency control signaling is easily blocked by ordinary data packets, causing delays in the transmission of control information such as status reports, compression feedback, and sequence number gap reporting. This slows down retransmission triggering and link status maintenance efficiency. Therefore, this embodiment establishes an independent control queue, differentiated queuing rules, preemptive scheduling, and cross-layer notification mechanisms to ensure that control PDUs are prioritized for transmission, reduce control signaling latency, and avoid link anomalies and service interruptions caused by signaling blockage.

[0140] The configuration process will be explained in detail below.

[0141] In this embodiment, the service identifier mapping rules, delivery strategies, and the number and scheduling methods of each sub-queue in the data PDU queue are configured semi-statically based on RRC signaling. The service identifier mapping rules, differentiated delivery strategies, and the number and scheduling methods of each sub-queue in the data PDU queue are all configured semi-statically based on RRC signaling, and the relevant parameter configurations can be customized and fixed in advance according to the actual network scenario.

[0142] This embodiment also includes: dynamically updating the mapping relationship between service data streams and traffic category identifiers using SDF mapping adjustment MAC control unit; or, dynamically adjusting the scheduling weights and priority parameters of each sub-queue in the data PDU queue using queue weight adjustment MAC control unit. This semi-static configuration combined with a dynamic adjustment mechanism can both refresh the binding relationship between service data streams and traffic category identifiers in real time through SDF mapping adjustment MAC control unit, and dynamically modify the scheduling weights and priority parameters of each sub-queue through queue weight adjustment MAC control unit. This can adapt to changes in service load and channel state fluctuations, flexibly optimize queue scheduling logic and identifier mapping relationship, improve queue resource utilization and service transmission adaptability, and ensure that high and low priority services are always scheduled and transmitted in an orderly manner according to reasonable rules.

[0143] The network side sends HOL blocking-related configuration information to the UE via either the `RRCReconfiguration` message (RRC connection reconfiguration) or the `RRCSetup` message (RRC establishment). The configuration process is as follows: 1) DRB establishment / reconfiguration trigger: The SDAP layer of the core network or gNB determines the set of QoS flows that the DRB needs to carry, as well as the QoS parameters (5QI, etc.) of each QoS flow.

[0144] 2) gNB generates RRC configuration: The gNB's RRC layer generates HOL blocking configurations based on QoS requirements, including: SDF differential configuration of PDCP layer (SDF mapping table, delivery strategy); RLC layer queue configuration (Per-TC queue switch, scheduling mode); Global HOL configuration (enabling / disabling various functions).

[0145] 3) RRC message transmission and UE response: The gNB sends an `RRCReconfiguration` message via SRB1. Upon receiving the message, the UE parses the HOL configuration, configures the PDCP and RLC entities, and sends an `RRCReconfigurationComplete` message to confirm.

[0146] Add the following IE to `PDCP-Config` and `RLC-Config`: New features added to PDCP-Config: SDF Differentiation Configuration Example of asn.1: SDF-Differentiation-Config ::= SEQUENCE { sdf-DifferentiationEnabled BOOLEAN, -- Whether to enable SDF differential processing; maxNumberOfSDFs INTEGER (1..7), -- Maximum number of SDFs; -- SDF mapping table: mapping from QFI / 5-tuple / DSCP to SDF_ID+TC; sdf-MappingList SEQUENCE (SIZE(1..7)) OF SDF-Mapping; -- Default SDF configuration (SDF_ID=0, i.e., PDU with F=0); defaultDeliveryPolicy ENUMERATED {inOrder, outOfOrder, selectiveDiscard}; } SDF-Mapping ::= SEQUENCE { sdf-id INTEGER (1..7), -- SDF identifier; traffic-class ENUMERATED {delayCritical, streaming, interactive, bestEffort}, delivery-policy ENUMERATED {inOrder, outOfOrder, selectiveDiscard}, -- Matching rules (at least one must be configured); qfi-List SEQUENCE (SIZE(1..16)) OF QFI OPTIONAL, ip-5-tuple-filter IP-Filter OPTIONAL, dscp-range SEQUENCE {start INTEGER(0..63), end INTEGER(0..63)}OPTIONAL, -- Alternative parameters only when SDF_ID is normalized (TC is obtained by mapping SDF_ID); sdf-to-tc-mapping INTEGER (0..3) OPTIONAL, -- Alternative parameters only when TC is standardized (TC directly determines the delivery strategy); tc-direct-policy ENUMERATED {inOrder, outOfOrder, selectiveDiscard}OPTIONAL; } SDF_ID standardization only: The `traffic-class` field is optional; an `sdf-to-tc-mapping` field is added for mapping SDF_ID to priority. TC standardization only: The `sdf-id` field is optional; `delivery-policy` is now directly specified by `tc-direct-policy` based on TC.

[0147] Both are standardized: all fields work together, SDF_ID is used for flow-level differentiation, and TC is used for priority scheduling.

[0148] New features added to RLC-Config: Queue configuration. An example of asn1 is shown below: RLC-Queue-Config ::= SEQUENCE { perTcQueueEnabled BOOLEAN, -- Whether to enable the Per-TC queue; schedulingMode ENUMERATED {strictPriority, weightedRoundRobin,hybrid}, queueWeights SEQUENCE (SIZE(4)) OF INTEGER (0..15) OPTIONAL, controlPduQueueEnabled BOOLEAN, --Whether to enable the control PDU queue (CPQ); -- Queue mapping only when SDF_ID is normalized; sdfToQueueMapping SEQUENCE (SIZE(1..7)) OF SDF-Queue-MappingOPTIONAL; } SDF-Queue-Mapping ::= SEQUENCE { sdf-id INTEGER (1..7), queueIndex INTEGER (0..3) -- The queue index to which the data is mapped; } MAC CE is used to dynamically adjust SDF mappings and queue configurations without requiring RRC reconfiguration, offering advantages such as low latency and low overhead.

[0149] The following describes the process of adjusting the MAC CE in SDF mapping.

[0150] Function: Dynamically updates the mapping relationship between SDF_ID and QFI within a specific DRB, or adjusts the SDF delivery strategy. Supports the following operations: Activate a new SDF mapping (specify SDF_ID, TC, and delivery strategy); Deactivate an existing SDF mapping; Modify the delivery strategy of an SDF (e.g., change it from IN_ORDER to OUT_OF_ORDER).

[0151] MAC CE format (illustrated): LCID: Newly allocated index (e.g., 45); Fixed size, 1 byte; Action (2-bit): 00 = Deactivate the mapping of SDF_ID; 01 = Activate SDF_ID(delivery strategy=IN_ORDER); 10 = Activate SDF_ID(delivery strategy=OUT_OF_ORDER); 11 = Activate SDF_ID (delivery policy=SELECTIVE_DISCARD); When only SDF_ID is standardized: TC information is implicitly associated through the RRC configuration of SDF_ID, and MAC CE only carries SDF_ID and Action; when only TC is standardized: SDF_ID can be replaced with TC value (2 bits), and Action indicates the delivery strategy change of the TC; when both are standardized: MAC CE can carry both SDF_ID and TC information at the same time, or can be quickly adjusted through MAC CE based on the pre-configured RRC.

[0152] Sending process: 1. Triggering conditions: The SDAP layer of the core network or gNB detects a change in the mapping relationship of QoS flows, or the network side decides to adjust the delivery strategy based on the service load.

[0153] 2. Assembly: The base station MAC layer constructs the MAC CE. The MAC subheader contains the reserved LCID value.

[0154] 3. Transmission: The MAC CE is sent to the UE via the downlink shared channel (DL-SCH). Upon receiving the MAC CE, the UE immediately applies the new mapping relationship in the processing of the next PDCP PDU.

[0155] 4. UE Response: The UE updates its PDCP layer's SDF mapping table and delivery policy configuration, and subsequent PDU processing adopts the new configuration.

[0156] The following describes the queue weight adjustment MAC CE process: Function: Dynamically adjusts the scheduling parameters of the Per-TC queue at the RLC transmitter, including: Adjust the scheduling weight of a specific TC queue (in weighted round-robin mode). Modify the absolute priority order of a specific TC queue; Temporarily activate / deactivate a Per-TC queue when at full load.

[0157] MAC CE format (illustrated): LCID: Newly allocated index (e.g., 46); Fixed size, 1 byte; TC (2 bits): The TC value of the target queue; Weight (4 bits): New weight value or scheduling priority operation; When only SDF_ID is standardized: the `TC` field can be replaced with `QueueIndex` (2 bits) to indicate the target queue; when only TC is standardized: the `TC` field directly identifies the target queue; when both are standardized: the `TC` field is the primary field, and `QueueIndex` is an optional extension.

[0158] Sending process: 1. Triggering conditions: The network side detects changes in service load or QoS requirements, requiring adjustments to the scheduling behavior of the RLC layer.

[0159] 2. Assembly: The base station MAC layer constructs MAC CE, which includes target TC, weight value or priority operation.

[0160] 3. Transmission: The MAC CE is sent to the UE via DL-SCH. After receiving the MAC CE, the UE immediately applies the new queue scheduling parameters in the next MAC transmission opportunity.

[0161] 4. UE response: The UE updates the Per-TC queue scheduling configuration of its RLC transmitter, and subsequent scheduling decisions are executed based on the new parameters.

[0162] The beneficial effects of this application are as follows: This application is applied to a first communication device, comprising: encapsulating a data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer sending entity; wherein the service identifier includes a data stream identifier and / or a traffic category identifier; and sending the data PDU to a second communication device, so that a first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier. Therefore, this application, by using a first protocol layer sending entity on the first communication device side to encapsulate the data unit to be transmitted and add a service identifier containing a data stream identifier and / or a traffic category identifier, can complete the fine-grained marking of different service data streams and different traffic priority levels during the native encapsulation stage of the data packet. This allows each PDCP data PDU to carry explicit identification information of its own service stream attribute and priority attribute, breaking the limitation of homogeneous processing under the traditional PDCP transmission mechanism where all service data uniformly adopts the same set of sorting, caching, and delivery rules. Subsequently, the first communication device can transmit the PDCP data PDU carrying this type of identifier layer by layer to the second communication device, and the first protocol layer receiving entity in the second communication device can accurately distinguish each data PDU based on the service identifier carried by the PDCP data PDU. Based on the service data stream corresponding to the PDU and its corresponding traffic priority level, it is no longer restricted by the lagging data blocking of low-speed, high-latency, and non-critical services. It can flexibly match differentiated delivery strategies such as out-of-order delivery, in-order delivery, and selective discarding according to the latency requirements, order requirements, and packet loss tolerance requirements of different services. This enables high-priority latency-sensitive service data to be delivered and processed independently without being restricted by low-priority blocking data. It avoids the problem of low-speed, long-latency service data packets blocking subsequent high-priority small packets and real-time service packets caused by all service data sharing a single receive buffer window and a unified delivery order in the traditional mechanism. This reduces the transmission latency of real-time services, improves the flexibility of data transmission scheduling and the overall transmission efficiency in multi-service mixed transmission scenarios, and ultimately achieves the core effect of targeted elimination of HOL blocking in wireless communication systems.

[0163] See Figure 3 As shown in the figure, this application discloses a HOL blocking elimination system in a wireless communication system, including a first communication device 11 and a second communication device 12, wherein: The first communication device 11 is configured to encapsulate the data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer transmission entity, and send the data PDU to the second communication device; wherein, the service identifier includes a data stream identifier and / or a traffic category identifier; The second communication device 12 is used to control the first protocol layer receiving entity to deliver the data PDU in a differentiated manner according to the service identifier.

[0164] In one specific embodiment, the first communication device is a terminal and the second communication device is a base station, or the first communication device is a base station and the second communication device is a terminal.

[0165] Furthermore, embodiments of this application also provide an electronic device. Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0166] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the HOL blocking elimination method in a wireless communication system disclosed in any of the foregoing embodiments.

[0167] In this embodiment, the power supply 23 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0168] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0169] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0170] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system can be Windows, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the HOL blocking elimination method in a wireless communication system executed by the electronic device as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0171] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned HOL blocking elimination method in a wireless communication system. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0172] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0173] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. The software module may be located in random access memory (RAM), memory, read-only memory (ROM), electrically programmable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), register, hard disk, removable disk, CD-ROM (Compact Disc Read-Only Memory), or any other form of storage medium known in the art.

[0174] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0175] The above provides a detailed description of the HOL blocking elimination method and system in a wireless communication system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for eliminating HOL (Household Occlusion) blocking in a wireless communication system, characterized in that, Applied to a first communication device, including: The first protocol layer sending entity encapsulates the data unit to be sent into a data PDU carrying a service identifier; wherein, the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; The data PDU is sent to the second communication device so that the first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier.

2. The method for eliminating HOL congestion in a wireless communication system according to claim 1, characterized in that, The data stream identifier is used to characterize the service data stream to which the PDCP data PDU belongs, and the traffic category identifier is used to characterize the traffic category to which the service data stream belongs or the traffic priority level of the service data stream; wherein, if the service identifier only includes the data stream identifier, the data stream identifier is also used to deduce the traffic priority level of the service data stream.

3. The method for eliminating HOL congestion in a wireless communication system according to claim 1, characterized in that, When the service identifier includes a delivery type identifier, the delivery strategy corresponding to the delivery type includes any one or more of the following strategies: out-of-order delivery strategy, in-order delivery strategy, and selective discard strategy.

4. The method for eliminating HOL congestion in a wireless communication system according to claim 1, characterized in that, The process of encapsulating the data unit to be sent into a data PDU carrying a service identifier using the first protocol layer sending entity includes: The first protocol layer sending entity encapsulates the data unit to be sent to obtain the initial PDCP data PDU, and adds a flow indicator flag and service identifier to the header of the initial PDCP data PDU to obtain a PDCP data PDU carrying the service identifier. Wherein, when the flow indicator flag is a first preset value, it indicates that the PDCP data PDU does not carry a service identifier, and when the flow indicator flag is a second preset value, it indicates that the PDCP data PDU carries a service identifier.

5. The method for eliminating HOL congestion in a wireless communication system according to claim 4, characterized in that, The data unit to be transmitted is a PDCP SDU obtained using the SDAP layer of the first communication device; The encapsulation of the data unit to be transmitted using the first protocol layer transmitting entity to obtain the initial PDCP data PDU includes: Obtain the QoS flow information associated with the data unit to be sent; wherein, the QoS flow information includes any one or more of the following: QoS flow identifier, PDU Set identifier, IP 5-tuple, and differentiated service code point; The QoS stream information is mapped to a service identifier using the first protocol layer sending entity, and the data unit to be sent is subjected to header compression, decompression, encryption and integrity protection processing to obtain PDCP data PDU.

6. The method for eliminating HOL congestion in a wireless communication system according to claim 4, characterized in that, In the second communication device, the first protocol layer receiving entity delivers the data PDU in a differentiated manner according to the service identifier, including: In the second communication device, the first protocol layer receiving entity parses the PDCP data PDU and counts the receiving count value based on the receiving sequence number of the PDCP data PDU and the global receiving delivery parameters. The received count value is used to decrypt and verify the integrity of the PDCP data PDU. If the integrity verification is successful, the received count value is used for duplicate detection. If the repeated detection result indicates that the PDCP data PDU has not been received, then the PDCP data PDU will be delivered in a differentiated manner according to the service identifier of the PDCP data PDU.

7. The method for eliminating HOL congestion in a wireless communication system according to claim 6, characterized in that, Also includes: In the second communication device, the first protocol layer receiving entity delivers the data PDU based on the service identifier to obtain a differentiated delivery authorization license from the network side.

8. The method for eliminating HOL congestion in a wireless communication system according to claim 6, characterized in that, Differentiated delivery of the data PDU based on its service identifier includes: If the stream indicator flag of the PDCP data PDU or the data stream identifier is a first preset value, the PDCP data PDU is delivered to the target application in sequence; If the flow indicator flag of the PDCP data PDU is a second preset value and the data flow identifier is not a first preset value, then the PDCP data PDU will be selectively delivered to the target application.

9. The method for eliminating HOL congestion in a wireless communication system according to claim 8, characterized in that, The selective delivery of the PDCP data PDU to the target application includes: The PDCP data PDU is stored in the corresponding SDF receive queue and sorted according to the receive count value; Update the single-stream expected reception value and the global expected reception value of the SDF receive queue; The delivery strategy of the PDCP data PDU is determined based on the service data stream to which the PDCP data PDU belongs, and the PDCP data PDU is delivered to the target application according to the delivery strategy; wherein the delivery strategy is any one of the following strategies: out-of-order delivery strategy, in-order delivery strategy, and selective discarding strategy.

10. The method for eliminating HOL congestion in a wireless communication system according to claim 9, characterized in that, The delivery of the PDCP data PDU to the target application according to the delivery strategy includes: If the delivery strategy is an out-of-order delivery strategy, then the PDCP SDU corresponding to the PDCP data PDU is delivered to the upper protocol layer, the single stream receive delivery parameters of the service data stream to which the PDCP data PDU belongs are updated, and the arrived and continuous PDCP data PDUs in the SDF receive queue are detected to be delivered synchronously to the target application, and then the global receive delivery parameters are updated. If the delivery strategy is an in-order delivery strategy, then it is detected whether all PDCP data PDUs corresponding to consecutive count values ​​starting from the single stream expected reception value in the SDF receiving queue have been received. If all have been received, then consecutive PDCP data PDUs are delivered in batches and the single stream receiving delivery parameters are updated. If there are missing PDCP data PDUs in the SDF receiving queue, then delivery is paused and the missing PDCP data PDUs are waited for, and the global receiving delivery parameters are updated. If the delivery strategy is a selective discard strategy, then the PDCP data PDUs that arrive consecutively are delivered in order. If the reordering timer times out, the PDCP data PDUs that time out and are missing in the SDF receive queue are marked as discarded PDCP data PDUs. The PDCP data PDUs that arrive consecutively after the discarded PDCP data PDUs are delivered, and the global receive delivery parameters are updated.

11. The method for eliminating HOL congestion in a wireless communication system according to claim 1, characterized in that, The step of sending the data PDU to the second communication device, so that the first protocol layer receiving entity in the second communication device can deliver the data PDU differently according to the service identifier, includes: The PDCP data PDU is sequentially sent to the second protocol layer sending entity, the MAC sending entity, and the PHY sending entity, and then transmitted through the air interface of the first communication device to the air interface of the second communication device. This allows the PDCP data PDU to be sequentially transmitted through the PHY receiving entity, the MAC receiving entity, and the second protocol layer receiving entity of the second communication device to the first protocol layer receiving entity. The first protocol layer receiving entity then delivers the PDCP data PDU in a differentiated manner based on the service identifier.

12. The method for eliminating HOL congestion in a wireless communication system according to claim 11, characterized in that, The second protocol layer sending entity includes a data PDU queue, wherein the data PDU queue includes multiple sub-queues; sending the PDCP data PDUs sequentially to the second protocol layer sending entity and the MAC sending entity includes: If the PDCP data PDU is a data class PDU, then the PDCP data PDU is inserted into the corresponding sub-queue in the data PDU queue based on the service identifier; In the current transmission opportunity, the data class PDUs in each sub-queue of the data PDU queue are scheduled and delivered to the MAC sending entity.

13. The method for eliminating HOL congestion in a wireless communication system according to claim 12, characterized in that, The data class PDUs in each sub-queue of the scheduling data PDU queue include: Data PDUs in each sub-queue are scheduled sequentially according to their priority. Alternatively, data PDUs in each sub-queue can be scheduled using a weighted round-robin method.

14. The method for eliminating HOL congestion in a wireless communication system according to claim 12, characterized in that, The entity that submits the data to the MAC sender includes: If the second protocol layer transmitting entity receives a retransmission instruction, it determines the data unit to be retransmitted from the data PDU queue according to the retransmission instruction; wherein, the data unit to be retransmitted is a PDCP data PDU or a segment of a PDCP data PDU; The traffic category classification and mapping priority of the data unit to be retransmitted remain unchanged; If the traffic category of the data unit to be retransmitted is not empty, then the data unit to be retransmitted is inserted into the head of the corresponding sub-queue in the data PDU queue based on the traffic category of the data unit to be retransmitted. If the traffic category of the data unit to be retransmitted is empty, then the data unit to be retransmitted is inserted into the head of the highest priority sub-queue in the data PDU queue.

15. The method for eliminating HOL congestion in a wireless communication system according to claim 11, characterized in that, Transmitting PDCP data PDU to the first protocol layer receiving entity through the second protocol layer receiving entity of the second communication device includes: The type of PDCP data PDU is identified by the entity receiving the data at the second protocol layer of the second communication device. If the PDCP data PDU is a control class PDU, then the PDCP data PDU is submitted to the RLC layer to transmit the PDCP data PDU to the first protocol layer receiving entity; If the PDCP data PDU is a data type PDU, then after reassembling and reordering the PDCP data PDU, the PDCP data PDU is transmitted to the first protocol layer receiving entity.

16. The method for eliminating HOL congestion in a wireless communication system according to claim 12, characterized in that, The second protocol layer sending entity further includes a control PDU queue and a priority merger; sending the PDCP data PDU to the MAC sending entity includes: The second protocol layer sending entity receives PDCP data PDU; If the PDCP data PDU is a control class PDU generated by the second protocol layer sending entity, then the PDCP data PDU is inserted at the tail of the control PDU queue; If the PDCP data PDU is a control class PDU generated by the first protocol layer sending entity, then insert it into the corresponding position in the control PDU queue according to the urgency flag of the PDCP data PDU; In the current transmission opportunity, the priority merger is used to check whether the control PDU queue is empty; If the control PDU queue is not empty, the PDCP data PDU is taken from the head of the control PDU queue and transmitted to the MAC sending entity; If the control PDU queue is empty, then proceed to the steps of the data class PDUs in each sub-queue of the scheduling data PDU queue.

17. The method for eliminating HOL congestion in a wireless communication system according to claim 16, characterized in that, Also includes: When the control PDU queue changes from empty to non-empty, the control second protocol layer sending entity notifies the MAC sending entity through cross-layer signaling to prioritize the scheduling of logical signals bound to the control PDU queue.

18. The method for eliminating HOL congestion in a wireless communication system according to any one of claims 13 to 17, characterized in that, The mapping rules, delivery strategies, number of sub-queues and scheduling methods of the service identifiers are based on semi-static configuration using RRC signaling.

19. The method for eliminating HOL congestion in a wireless communication system according to claim 18, characterized in that, Also includes: The mapping relationship between service data streams and traffic category identifiers is dynamically updated by using SDF mapping to adjust the MAC control unit; Alternatively, the scheduling weight and priority parameters of each sub-queue in the data PDU queue can be dynamically adjusted using the queue weight adjustment MAC control unit.

20. A HOL blocking elimination system in a wireless communication system, characterized in that, It includes a first communication device and a second communication device, wherein: The first communication device is configured to encapsulate the data unit to be transmitted into a data PDU carrying a service identifier using a first protocol layer transmission entity, and transmit the data PDU to the second communication device; wherein, the service identifier includes a data stream identifier and / or a traffic category identifier and / or a delivery type identifier; The second communication device is used to control the first protocol layer receiving entity to deliver the data PDU in a differentiated manner according to the service identifier.

21. The HOL blocking elimination system in a wireless communication system according to claim 20, characterized in that, The first communication device is a terminal and the second communication device is a base station, or the first communication device is a base station and the second communication device is a terminal.

Images