Systems and methods for concatenation and preprocessing of data plane

Abstract

The disclosure relates to a fifth-generation (5G) or sixth-generation (6G) communication system for supporting higher data rates than fourth-generation (4G) communication systems such as Long Term Evolution (LTE). A system and method for optimizing the radio link control (RLC) mechanism of the data plane are also provided.

Description

Technical Field

[0001] This disclosure relates to wireless communication networks. More specifically, this disclosure relates to a system and method for optimizing radio link control (RLC) mechanisms in the data plane. Background Technology

[0002] Given the successive generations of wireless communication development, technologies have been developed primarily for services targeting humans, such as voice calls, multimedia services, and data services. Following the commercialization of 5G (5th generation) communication systems, the number of connected devices is expected to grow exponentially. These will increasingly connect to communication networks. Examples of connected things can include vehicles, robots, drones, home appliances, displays, smart sensors connected to various infrastructures, construction machinery, and factory equipment. Mobile devices are expected to evolve in various form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. To provide a wide range of services by connecting hundreds of billions of devices and things in the 6G (6th generation) region, efforts have been made to develop improved 6G communication systems. For these reasons, 6G communication systems are referred to as "beyond 5G" systems.

[0003] The 6G communication system, which is expected to be commercialized around 2030, will have peak data rates in the terabyte (1,000 gigabyte) range and radio latency of less than 100 microseconds (μs), and will therefore be 50 times faster than 5G communication systems and have 1 / 10 of their radio latency.

[0004] To achieve such high data rates and ultra-low latency, 6G communication systems have been considered for implementation in the terahertz band (e.g., the 95 GHz to 3 THz band). It is anticipated that technologies to ensure signal transmission distance (i.e., coverage) will become more critical due to the more severe path loss and atmospheric absorption in the terahertz band compared to the millimeter-wave (mmWave) band introduced in 5G. As key technologies for ensuring coverage, it is necessary to develop radio frequency (RF) components, antennas, new waveforms with better coverage than orthogonal frequency division multiplexing (OFDM) schemes, beamforming and massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, and multi-antenna transmission technologies such as massive MIMO. Furthermore, new technologies for improving the coverage of terahertz band signals have been discussed, such as metamaterial-based lenses and antennas, orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS).

[0005] Furthermore, to improve spectrum efficiency and overall network performance, the following technologies have been developed for 6G communication systems: full-duplex technology that allows uplink and downlink transmissions to use the same frequency resources simultaneously; network technologies for integrated utilization of satellites, High Altitude Platform Radios (HAPS), etc.; improved network architectures that support mobile base stations and allow for network operation optimization and automation; dynamic spectrum sharing technology based on spectrum usage prediction via conflict avoidance; the use of artificial intelligence (AI) in wireless communication to improve overall network operation by leveraging AI from the 6G development design phase and internalizing end-to-end AI support functions; and next-generation distributed computing technologies to overcome the limits of user equipment (UE) computing capabilities through achievable ultra-high-performance communication and on-network computing resources such as mobile edge computing (MEC) and the cloud. Additionally, efforts continue to be made to enhance connectivity between devices, optimize networks, promote the software-defined networking of network entities, and improve the openness of wireless communication by designing new protocols for use in 6G communication networks, developing mechanisms for achieving hardware-based secure environments and secure data usage, and developing technologies for maintaining implicit security.

[0006] The research and development of hyper-connected 6G communication systems, including human-to-machine (P2M) and machine-to-machine (M2M) communication, is expected to enable future hyper-connected experiences. Specifically, various services are anticipated to be available through 6G communication systems, such as truly immersive extended reality (XR), high-fidelity mobile holograms, and digital replicas. Furthermore, 6G communication systems will provide services such as remote surgery for enhanced security and reliability, industrial automation, and emergency response, enabling the application of this technology in various fields, including industry, healthcare, automotive, and home appliances.

[0007] Recently, various studies on Radio Link Control (RLC) have been conducted for next-generation communication systems to optimize the overhead of RLC header processing.

[0008] The above information is presented as background information only to aid in understanding this disclosure. No determination or assertion has been made as to whether any of the above items can be considered applicable prior art in connection with this disclosure. Summary of the Invention

[0009] Technical issues

[0010] With the increasing demands for data, high bandwidth, and processing power, the need for high-speed data processing in future modem communication protocol systems, especially in systems beyond 5G / 6G, is highly feasible. As the number of packets to be processed within shorter transmission time intervals (TTIs) increases, there is a need to improve data plane processing capabilities in all aspects to achieve extremely fast processing. Recently, many methods have been explored to improve multi-core architecture designs. However, current technologies need to simplify and accelerate the overhead of processing functions for future-generation protocols by providing reliable communication mechanisms for the application and transport layers.

[0011] To meet the aforementioned requirements, the communication protocol used for the modem should at least provide, for example, an efficient way to package information, minimal processing overhead, lightweight functionality, scalable solutions, and reliable mechanisms for serving upper layers.

[0012] Therefore, a new generation of RLC mechanisms needs to be defined to address at least one of these aspects of the overhead for optimizing RLC header processing.

[0013] Solution to the problem

[0014] The aspects of this disclosure are intended to address the aforementioned problems and / or disadvantages, and provide at least the following advantages. Therefore, one aspect of this disclosure provides a system and method for transmitting data. In this method, a Radio Link Control (RLC) layer receives multiple Protocol Data Unit (PDU) packets from a Packet Data Convergence Protocol (PDCP) layer, and preprocesses an RLC subheader of the RLC header of each received PDU packet based on the length of the Service Data Unit (SDU) received from the PDCP layer. The RLC layer concatenates a complete PDCP PDU packet along with RLC subheader length information into an RLC PDU based on available Media Access Control (MAC) permissions, and then segments the PDU packet into new PDCPPDU packets truncated due to fewer available MAC permissions. Furthermore, the method prepares an RLC PDU along with an RLC header, the RLC PDU comprising at least one concatenated complete PDCP PDU packet and at most one new PDCP PDU packet, and transmits the RLC PDU.

[0015] Additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description or may be learned by practice of the presented embodiments.

[0016] According to one aspect of this disclosure, a method is provided for transmitting data over a radio link established between a user equipment (UE) and a network node. The method includes: receiving a plurality of Protocol Data Unit (PDU) packets from a Packet Data Convergence Protocol (PDCP) layer by a Radio Link Control (RLC) layer; preprocessing an RLC subheader of the RLC header of each received PDU packet based on the Service Data Unit (SDU) length received from the PDCP layer for each of the plurality of PDU packets by the RLC layer; concatenating at least one complete PDCP PDU packet from the received plurality of PDU packets and RLC subheader length information into an RLC PDU by the RLC layer based on available Media Access Control (MAC) permissions; segmenting the plurality of Protocol Data Unit (PDU) packets into new PDCP PDU packets by the RLC layer, the new PDCP PDU packets being truncated due to fewer available MAC permissions; preparing an RLC PDU along with the RLC header, the RLC PDU including the concatenated at least one complete PDCP PDU packet and at most one new PDCP PDU packet segmented based on the available MAC permissions; and transmitting the RLC PDU down to a MAC layer by the RLC layer.

[0017] According to another aspect of this disclosure, an apparatus is provided for transmitting data over a radio link established between a UE and a network node. The device includes: a transceiver configured to transmit and receive signals; and a controller coupled to the transceiver and configured to: receive a plurality of Protocol Data Unit (PDU) packets from a Packet Data Convergence Protocol (PDCP) layer by a Radio Link Control (RLC) layer; preprocess an RLC subheader of the RLC header of each received PDU packet based on the Service Data Unit (SDU) length received from the PDCP layer for each of the plurality of PDU packets by the RLC layer; concatenate at least one complete PDCP PDU packet from the received plurality of PDU packets and RLC subheader length information into an RLC PDU based on available Media Access Control (MAC) permissions; segment the plurality of Protocol Data Unit (PDU) packets into new PDCP PDU packets, the new PDCP PDU packets being truncated due to fewer available MAC permissions, along with the RLC header to prepare an RLC PDU, the RLC PDU including the concatenated at least one complete PDCP packet. PDU packets and at most one new PDCP PDU packet segmented based on the available MAC license, and the RLC PDU transmitted from the RLC layer down to the (MAC) layer.

[0018] Other aspects, advantages, and distinctive features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the accompanying drawings, discloses various embodiments of the invention. Attached Figure Description

[0019] The above and other aspects, features, and advantages of some embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, wherein:

[0020] Figure 1 The illustration depicts a wireless communication system operating in fourth-generation (4G) wireless communication technology according to embodiments of the present disclosure.

[0021] Figure 2 An example of a data plane in Long Term Evolution (LTE) (4G) according to an embodiment of this disclosure is shown.

[0022] Figure 3 A basic RLC header structure in LTE (4G) according to an embodiment of the present disclosure is shown.

[0023] Figure 4 Various examples of RLC header structures in LTE (4G) according to embodiments of this disclosure are shown.

[0024] Figure 5 An example of a data plane in a novel radio (NR) (5G) according to an embodiment of the present disclosure is shown.

[0025] Figure 6 A basic RLC header structure in NR (5G) according to an embodiment of the present disclosure is shown.

[0026] Figure 7 A flowchart is shown for a method of cascading and preprocessing a data plane by configuring an RLC layer, according to an embodiment of the present disclosure.

[0027] Figure 8 Variation 1 of the data plane for a next-generation system according to embodiments of the present disclosure is shown.

[0028] Figure 9 A variant 1 of the RLC header according to an embodiment of the present disclosure is shown.

[0029] Figures 10a to 10b A variant 1 of the next-generation RLC header structure according to various embodiments of the present disclosure is shown.

[0030] Figure 11 The normal transmission (TX) process according to a variant 1 of the next-generation RLC header according to an embodiment of the present disclosure is illustrated.

[0031] Figure 12aThe retransmission and resegmentation mechanism according to embodiments of this disclosure is illustrated.

[0032] Figure 12b This illustrates yet another embodiment of the next-generation data plane during a retransmission process that performs a resegmentation mechanism, according to embodiments of the present disclosure.

[0033] Figure 13 The Unconfirmed Mode Data (UMD) PDU header structure in Variant 1 of an embodiment according to this disclosure is shown.

[0034] Figure 14 Another variant 3 of the next-generation RLC header according to an embodiment of this disclosure is shown.

[0035] Figure 15 A UMD PDU header according to variant 3 of an embodiment of the present disclosure is shown.

[0036] Figure 16 Another embodiment of the user plane according to the present disclosure is shown, which is a variant 1 / variant 3 of the data plane having a packed length sub-header.

[0037] Figure 17 Another embodiment of a variant 1 / 3 of a next-generation RLC header with a packed length subheader is shown according to an embodiment of the present disclosure.

[0038] Figure 18 Another embodiment of a UMDPDU header with a packed length subheading according to variant 1 is shown in accordance with the present disclosure.

[0039] Figure 19 Another embodiment of a UMDPDU header with a packed length subheading according to variant 3 of the present disclosure is shown.

[0040] Figure 20 This illustrates yet another embodiment of a next-generation user plane according to an embodiment of the present disclosure, which has a packed length sub-header but no final SDU length.

[0041] Figure 21 Another embodiment of the next-generation RLC header according to the present disclosure is shown, which has a packed length subheading but no final SDU length.

[0042] Figure 22 Another embodiment of the UMD PDU header according to the present disclosure is shown, which has a packed length sub-header but no final SDU length.

[0043] Figure 23Another embodiment of the UMD PDU header according to the present disclosure is shown, which has a packed length sub-header but no final SDU length.

[0044] Figure 24 Another embodiment of the next-generation RLC header according to the present disclosure is shown, which has a distributed length subheading but no final SDU length.

[0045] Figure 25 Another embodiment of the RLC UMD PDU header according to an embodiment of the present disclosure is shown, which has a distributed length sub-header but no final SDU length.

[0046] Figure 26 Another embodiment of the RLC UMD PDU header according to an embodiment of the present disclosure is shown, which has a distributed length sub-header but no final SDU length.

[0047] Figure 27 The differences between the next-generation RLC header according to embodiments of the present disclosure and the prior art RLC header structure are shown.

[0048] Figure 28 The differences between the RLC mechanism according to embodiments of this disclosure and the prior art RLC header structure are illustrated.

[0049] Figure 29 The advantages of a next-generation data plane according to embodiments of this disclosure over the prior art are demonstrated.

[0050] Figure 30 Another illustration of a network node according to an embodiment of this disclosure is shown.

[0051] Figure 31 This is an illustration showing the configuration of a terminal in a wireless communication system according to an embodiment of the present disclosure.

[0052] Throughout the accompanying drawings, it should be noted that the same reference numerals are used to describe the same or similar elements, features, and structures. Detailed Implementation

[0053] The following description, with reference to the accompanying drawings, is provided to aid in a thorough understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. Various specific details are included to aid understanding, but these will be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of this disclosure. Furthermore, for clarity and brevity, descriptions of well-known functions and configurations may be omitted.

[0054] The terms and words used in the following description and claims are not limited to their meanings in the bibliography, but are used solely by the inventors to enable a clear and consistent understanding of this disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of this disclosure is provided for illustrative purposes only and not for limiting the purpose of this disclosure as defined by the appended claims and their equivalents.

[0055] It should be understood that the singular forms “a,” “one,” and “the” include plural objects unless the context explicitly indicates otherwise. Thus, for example, referring to “component surface” includes referring to one or more such surfaces.

[0056] References to "one aspect," "another aspect," or similar language throughout this specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. Therefore, phrases such as "in an embodiment," "in another embodiment," and similar language appearing throughout this specification may, but do not necessarily, refer to the same embodiment.

[0057] The terms “comprising,” “including,” or any other variation thereof are intended to cover non-exclusive inclusion, such that a process or method that includes a series of operations includes not only those operations but may also include other operations not expressly listed or inherent to such process or method. Similarly, the inclusion of one or more devices, subsystems, elements, structures, or components preceding “comprising” does not exclude (without further constraints) the presence of other devices or subsystems or elements or structures or components, or additional devices or subsystems or elements or structures or components.

[0058] In recent years, several broadband wireless technologies have been developed to meet the growing number of broadband subscribers and provide better applications and services. Second-generation wireless communication systems have been developed to provide voice services while ensuring user mobility. Third-generation wireless communication systems support not only voice services but also data services. In recent years, fourth-generation (4G) wireless communication systems have been developed to provide high-speed data services.

[0059] Figure 1 The illustration depicts a wireless communication system operating in fourth-generation wireless communication technology according to embodiments of the present disclosure.

[0060] However, current fourth-generation (4G) wireless communication systems suffer from insufficient resources to meet the growing demand for high-speed data services. This problem is addressed by developing fifth-generation (5G) wireless communication systems to meet this ever-increasing demand. Furthermore, fifth-generation (5G) wireless communication systems offer ultra-high reliability and support low-latency applications.

[0061] With the increasing demands for data, high bandwidth, and processing power, next-generation wireless communication systems (i.e., 6G and above) must be able to meet these growing needs. To this end, communication protocols must be able to handle high-speed data. In LTE, the protocols present in the user plane include Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and PHY protocols. The control plane stack also includes Radio Resource Control (RRC) and Non-Access Stratum (NAS).

[0062] The RLC protocol layer exists in both the UE and eNodeb, and it is part of the LTE air interface control and data plane.

[0063] Figure 2 An example of a data plane in LTE (4G) according to an embodiment of the present disclosure is shown.

[0064] Figure 3 A basic RLC header structure in LTE (4G) according to an embodiment of the present disclosure is shown.

[0065] Figure 4 Various examples of RLC header structures in LTE (4G) according to embodiments of this disclosure are shown.

[0066] Furthermore, different types of RLC headers exist for different RLC SN (Sequence Number) lengths; however, as an example, Figure 4 Only four types are shown. The main functions of RLC in LTE (4G) are:

[0067] Error correction mechanism through ARQ (Automatic Repeat Request);

[0068] Sequential delivery mechanism;

[0069] Cascading mechanism;

[0070] Segmentation and reorganization mechanisms; and

[0071] Reordering mechanism.

[0072] According to the 4G mechanism, when the RLC receives a license from the lower layer, the transmitter entity concatenates multiple PDCP PDUs into the RLC Protocol Data Unit (PDU) and assigns an RLC SN to the RLC PDU.

[0073] refer to Figure 3 The FI field indicates the framing information field. This framing information field is updated to indicate whether the first and last bytes of the RLC PDU correspond to the first and last bytes of the RLC SDU, respectively.

[0074] E indicates an extension field. The extension field indicates whether it follows a data field to indicate the end of the header or whether it follows another extension, i.e., a set of E fields and LI fields.

[0075] The LI field indicates the length indicator field. The length indicator field indicates the length of the RLC SDU.

[0076] In 4G, the E and LI fields are not updated for the last cascaded PDCP PDU. Furthermore, according to... Figure 2 A complete RLC SN is only prepared after a license has been received.

[0077] In LTE (4G), a single RLC SN is allocated when a license is available from the MAC, and this single RLC SN is mapped to multiple PDCP PDUs through cascading. Therefore, when the size of a PDCP PDU is smaller than the available license, only a small number of RLC SNs are needed, even for a large number of PDCP PDU packets. If an RLC PDU is lost for the first time due to BLER, the generated status report only needs to report the completely lost RLC SN. Now, when retransmitting a NACKed RLC SN with fewer licenses available, an Acknowledgment Mode Data (AMD) PDU fragment is sent using the Re-fractionation Flag (RF) in the header. Therefore, an advantage of the LTE (4G) RLC header is that it requires fewer RLC SNs than a PDCP SN.

[0078] However, the RLC header in LTE presents various problems, such as, but not limited to, the variable size of the RLC header due to multiple header types. Since the number of PDCP PDUs to be packaged cannot be known in advance, the complete RLC header can only be prepared after permission is received. Therefore, the LI field in the RLC header structure can only be updated after permission is granted.

[0079] In the case of refraction, and with the retransmission of the NACK-enabled RLC SN, the RLC header needs to be updated to include the RF, LSF, and SO fields, and the LI information needs to be refilled based on the number of PDCP PDUs concatenated during refraction. The length of the last PDCP PDU included in the concatenated RLC PDUs is calculated by subtracting the RLC PDU LI fields of the other PDCP PDUs from the total MAC PDU length.

[0080] Therefore, it can be seen that the aforementioned problems arise from the LTE (4G) RLC header having a variable-size RLC header and not preprocessing the RLC.

[0081] Figure 5 An example of a data plane in NR (5G) according to an embodiment of the present disclosure is shown.

[0082] Figure 6 A basic RLC header structure in NR (5G) according to an embodiment of the present disclosure is shown.

[0083] The main functions of RLC in NR (5G) are:

[0084] Through ARQ error correction mechanism;

[0085] Sequential delivery mechanism;

[0086] Segmentation and reorganization mechanisms; and

[0087] Reordering mechanism.

[0088] Therefore, NR (5G) RLC lacks a cascading mechanism. Consequently, without a cascading mechanism, a single RLC SN maps to a single RLC SDU, i.e., a single PDCP PDU, which is extremely advantageous in terms of preprocessing.

[0089] refer to Figure 6 The SI field indicates the segmentation information field. The segmentation information field indicates whether the RLC PDU contains a complete RLC SDU or the first segment, intermediate segment, or intermediate segment of the RLC SDU.

[0090] The SO field indicates the segment offset field. The segment offset field indicates the location (in bytes) of the RLC SDU segment within the original RLC SDU. In the case of segmentation, without permission, the SI field is sufficient to indicate the first segment, since SO=0 is redundant.

[0091] The advantages of the NR(5G) RLC header can be listed as follows:

[0092] The NR(5G) RLC header has a fixed size;

[0093] A single RLC SN is assigned to a single PDCP PDU; and

[0094] It is even possible to prepare the RLC header before the license update operation.

[0095] Segmentation information can be easily filled without making too many changes to the pre-processed RLC complete PDU header, because for the first segment to be transmitted, only the SI bit needs to be updated.

[0096] During segmentation or resegmentation, RLC only needs to prepare an RLC fragment header with an SO field. Therefore, it can be seen that the NR(5G) RLC header provides at least a fixed-size RLC header, pre-processed RLC, and efficient segmentation information.

[0097] On the other hand, the NR (5G) RLC header can cause various problems, such as:

[0098] In NR(5G) RLC mechanisms, window maintenance requires a large number of RLC SNs because a single RLC SN is mapped to a single PDCP SN. Furthermore, the processing loop at the receiver end increases due to additional sequence numbers.

[0099] For each license, the MAC must prepare multiple MAC subheaders because the MAC subheader captures the length of the RLC PDU information.

[0100] The length of each RLC PDU or RLC PDU fragment is packed with the MAC subheader.

[0101] Furthermore, with the increasing demands for data, high bandwidth, and processing power, the need for high-speed data processing in future modem communication protocol systems, especially in systems beyond 5G / 6G, is highly feasible. As the number of packets to be processed within shorter transmission time intervals (TTIs) increases, there is a need to improve data plane processing capabilities in all aspects to achieve extremely fast processing. Recently, many methods have been developed to improve multi-core architecture designs. However, current technologies need to be simplified and the overhead of processing functions accelerated for future-generation protocols by providing reliable communication mechanisms for the application and transport layers.

[0102] To meet the aforementioned requirements, the communication protocol used for the modem should at least provide, for example, an efficient way to package information, minimal processing overhead, lightweight functionality, scalable solutions, and reliable mechanisms for serving upper layers.

[0103] Therefore, a new generation of RLC mechanisms needs to be defined to address at least one of these aspects of the overhead for optimizing RLC header processing.

[0104] This disclosure provides a system and method for optimizing the overhead of RLC header processing by limiting the number of headers and using a fixed header size. To reduce the number of RLC SNs and introduce a fixed-size RLC header, the following mechanism is reintroduced in the RLC mechanism for next-generation systems (beyond 5G / 6G systems):

[0105] cascading mechanism at RLC;

[0106] The RLC subheader used to allow for the length of the preprocessed PDCP PDU; and

[0107] An RLC PDU with a license indication from MAC TB (Transport Block).

[0108] This disclosure can be implemented efficiently by using a hardware accelerator (HWA) for header parsing. Segmentation remains the same as in NR. Various variations of the RLC header structure and process for transmission in different modes are explained in detail below.

[0109] According to embodiments of this disclosure, a method is disclosed for transmitting data over a radio link established between a UE and a network node by configuring the Radio Link Control (RLC) layer to receive multiple Protocol Data Unit (PDU) packets from a Packet Data Convergence Protocol (PDCP) layer. The RLC layer then preprocesses the RLC subheader of the RLC header of each received PDU packet based on RLC subheader length information. The RLC layer further concatenates complete PDCP PDU packets from the received multiple PDU packets, along with the RLC subheader length information, into an RLC PDU based on available Media Access Control (MAC) permissions. Subsequently, an RLC sequence number (SN) is assigned to at least one concatenated complete PDCP PDU packet. Furthermore, the method includes segmenting the multiple Protocol Data Unit (PDU) packets into second PDCP PDU packets by the RLC layer, which are truncated due to fewer available MAC permissions. Furthermore, a new RLC sequence number (SN) is assigned to the segmented second PDCP PDU packet, and an RLC PDU is prepared along with an RLC header, comprising at least one concatenated complete first PDCP PDU packet and at most one second PDCP PDU packet based on available MAC-licensed segments. Additionally, the RLC layer transmits the RLC PDU down to the MAC layer.

[0110] Figure 7 A flowchart is shown for a method of cascading and preprocessing a data plane by configuring an RLC layer, according to an embodiment of the present disclosure.

[0111] refer to Figure 7 In this implementation, method 700 can be implemented at a transmitter entity or a receiver entity. The transmitter entity or receiver entity can be located on the network side or at the user equipment (UE).

[0112] At operation 701, method 700 includes receiving multiple Protocol Data Unit (PDU) packets from the Packet Data Convergence Protocol (PDCP) layer by the Radio Link Control (RLC) layer. In an embodiment, the RLC layer is further configured to receive an availability grant from the MAC layer. The RLC header may have a predetermined fixed size.

[0113] At operation 703, method 700 includes an RLC subheader by which the RLC layer preprocesses the RLC header of each received PDU packet based on the length of the Service Data Unit (SDU) received from the PDCP layer for each of the plurality of PDU packets.

[0114] Subsequently, at operation 705, method 700 includes concatenating at least one complete PDCP PDU packet from a plurality of received PDU packets and RLC subheader length information into an RLCPDU by the RLC layer based on available media access control (MAC) permission.

[0115] Following the concatenation at operation 705, at operation 707, method 700 includes segmenting multiple Protocol Data Unit (PDU) packets into new PDCP PDU packets by the RLC layer, the new PDCP PDU packets being truncated due to fewer available MAC permissions. In an embodiment, method 700 further includes assigning a first RLC sequence number to at least one concatenated complete PDCP PDU packet and assigning a new RLC sequence number (SN) to the new PDCP PDU packets.

[0116] Subsequently, at operation 709, method 700 includes preparing an RLC PDU along with an RLC header, the RLC PDU comprising at least one concatenated complete PDCP PDU packet and at most one new PDCP PDU packet segmented based on available MAC permissions. In an implementation, the preparation of the RLC PDU includes the RLC layer determining whether the received available permissions are sufficient to include at least one complete PDCP PDU packet. Thereafter, based on the available permissions and available PDCP PDUs, the RLC layer segments multiple Protocol Data Unit (PDU) packets into at least one complete PDCP PDU packet and a new PDCP PDU packet. As an example, a new RLC sequence number (SN) is assigned to the new PDCP PDU packet and is different from the first RLC sequence number (SN) assigned to the at least one concatenated complete PDCP PDU packet. Furthermore, the new RLC header of the new PDCP PDU packet includes only the sequence number (SN) and does not include RLC subheader length information. The RLC PDU is then prepared by accommodating the new PDCP PDU packet segmented based on available MAC permissions and at least one complete PDCP PDU packet.

[0117] Therefore, after preparing the RLC PDU at operation 709, at operation 711, the RLC PDU is transmitted from the RLC layer to the lower (MAC) layer. Now, if the received available licenses and PDCP PDUs are insufficient, an RLC PDU is prepared using at least one complete PDCP PDU packet. Thus, the RLC PDU is transmitted using at least one complete PDCP PDU packet. Therefore, the current mechanism can be defined as a fast-packed ARQ.

[0118] In another embodiment, method 700 includes transmitting, in a subsequent PDU, the remaining portion of a new PDCP PDU packet with a newly assigned RLC sequence number (SN) that was not contained in the RLC PDU during the next MAC-licensed transmission cycle. As an example, at least one complete PDCP PDU packet is defined as a PDCP PDU packet that can be fully transmitted, and a new PDCP PDU packet is defined as a PDCP PDU packet that cannot be fully transmitted according to the available MAC license.

[0119] In another embodiment, method 700 includes receiving an available MAC license through the RLC layer for the next MAC license transmission cycle. As an example, the available MAC license received in this operation is used for the next MAC license transmission cycle. Thereafter, the RLC layer determines whether the received available license is sufficient to include at least one first complete PDCP PDU packet containing the remainder of a segmented new PDCP PDU packet. Subsequently, method 700 divides the remainder of the segmented new PDCP PDU packet into at least one first complete PDCP PDU packet and a second new PDCP PDU packet based on the received available license and the available PDCP PDU. Here, a new RLC sequence number (SN) is assigned to at least one first complete PDCP PDU packet. Thereafter, the method includes assigning another new RLC sequence number (SN) different from the new RLC sequence number (SN) to the second new PDCP PDU packet. Therefore, the new RLC header of the second new PDCP PDU packet only includes the other new RLC sequence number (SN) and does not include RLC subheader length information. The method further includes preparing an RLC PDU by accommodating at least one first complete PDCP PDU packet and a second new PDCP PDU packet based on available MAC licenses. Furthermore, the remainder of the second new PDCP PDU packet is transmitted in the next or upcoming MAC license transmission cycle.

[0120] In another embodiment, method 700 includes receiving an unsuccessful acknowledgment message associated with the transmission failure of the RLC PDU from a receiver entity. Thereafter, method 700 includes retransmitting the RLC PDU to the MAC layer in the next transmission cycle based on the receipt of the unsuccessful acknowledgment. Specifically, in the next transmission cycle, the RLC layer receives a newly available MAC clearance from the MAC layer. Thereafter, it is determined that the newly available clearance is sufficient to retransmit the RLC PDU in the next transmission cycle, and thereafter, based on sufficient determination of the newly available MAC clearance, the RLC layer retransmits an RLC PDU, along with an RLC header, to the MAC layer, which is similar to the RLC PDU of the failed transmission.

[0121] According to another embodiment, method 700 further includes determining, by the RLC layer, whether the newly received available MAC permission is insufficient to retransmit the RLC PDU using the newly received available permission. Therefore, based on the determination of the newly received available permission, the RLC PDU is further re-segmented. Re-segmentation corresponds to segmenting multiple Protocol Data Unit (PDU) packets into at least two RLC PDU packets that are truncated due to the limited availability of the newly received available MAC permission.

[0122] Figure 8 Variation 1 of the data plane for a next-generation system according to embodiments of the present disclosure is shown.

[0123] In one implementation of the data plane for next-generation systems, RLC subheadings of varying PDCP PDU lengths may not be permitted, and some PDCP PDUs may exist at the time of segmentation. Furthermore, the length of a PDCP PDU may be at least 1 byte. The structure of the next-generation RLC header will be explained in detail in the following paragraphs.

[0124] Figure 9 A variant 1 of the RLC header according to an embodiment of the present disclosure is shown.

[0125] According to this disclosure, a single RLC SN can be assigned to a location that can be determined based on the specified location. Figure 7 Operation 707 transmits the RLC SDU completely. An RLC length subheader is used to indicate the length of each RLC SDU in a concatenated RLC PDU. Furthermore, a separate RLC SN is assigned to each RLC SDU segmented according to Operations 705 and 707. The SI and SO fields, the same as in the NR, are used to indicate segmentation information. Each RLC PDU has an accompanying MAC subheader containing the total length of the RLC PDU. Finally, the length of the SDU is not included in the length subheader. Figure 9At the RLC layer, the PDCP PDU is delivered to the lower layer. The complete RLC PDU has a fixed header size of SN length (24 bits in this sample example) that can be prepared for all previous SNs.

[0126] like Figure 9 The RLC header shown includes:

[0127] D / C (Data / Control) bits (Data: 1 and Control: 0);

[0128] Polling bit (P bit);

[0129] Segmentation Information (SI) (2 bits) - Used only for PDU segments;

[0130] Extension bit (E bit) (1 bit) - Used to indicate the presence of an RLC-length subheader. (1: Yes, 0: No); and

[0131] SN (Serial Number - 16 bits) (Sample).

[0132] When a PDCP PDU is concatenated into a single RLC PDU, each PDCP PDU corresponds to an RLC subheader with a length field.

[0133] E bit (extension bit) 1 - a group of E bits, length 0 - this is the last PDCP PDU part of the RLC PDU.

[0134] - Length (15 bits) - The length of the PDCP PDU updated for the corresponding PDCP PDU. (Sample).

[0135] The MAC header contains the LCID (Logical Channel ID) and the total length of the RLC PDU. (Same as in NR)

[0136] Figures 10a to 10b A variant 1 of the next-generation RLC header structure according to various embodiments of the present disclosure is shown.

[0137] refer to Figure 10a and Figure 10b According to one implementation, in the data field of the next-generation RLC header structure, the portion belonging to the original AMD PDU can remain unchanged; that is, everything except the fixed-size RLC header belongs to the data. The SI bit is used only for AMD PDU fragments. A PDCP header consisting only of the D / C bit and the PDCP SN is assigned to each PDCP SDU, i.e., the IP (Internet Protocol) packet. (The SN length is considered to be 15 bits). The PDCP PDU is delivered to the lower layer at the RLC. The complete RLC PDU has a fixed header size of SN length (considered 24 bits) that can be prepared for all previous SNs.

[0138] According to variant 1, the next-generation RLC header can consist of the following:

[0139] D / C bit (data: 1 and control: 0);

[0140] Polling bit (P bit);

[0141] RF bit (0: AMD PDU, 1: AMD fragment PDU);

[0142] Fragmentation Information (FI) (2 bits) indicates whether the first and last bytes of the RLC PDU correspond to the first and last bytes of the RLC SDU, respectively;

[0143] Segmentation information (SI) (2 bits) is mainly used for PDU segments; and

[0144] SN (Serial Number - 16 bits) (used for indication purposes).

[0145] Each PDCP PDU should be accompanied by an RLC subheader, which can be placed before each PDCP PDU's length field.

[0146] Extension bits (E bits) 1 - a group of E bits, followed by the length and data PDU;

[0147] 0 - This is the last PDCP PDU part in the RLC PDU.

[0148] Length (15 bits) - The length of the PDCP PDU can be updated for all PDCP PDUs.

[0149] Figure 11 The normal transmission (TX) process according to a variant 1 of the next-generation RLC header according to an embodiment of the present disclosure is illustrated.

[0150] Initially, the PDCP header can be assigned by the PDCP layer, and packets can be delivered to the RLC.

[0151] -RLC can prepare all fixed-size RLC headers based on the configured SN length. (D / C: 1, P: 0, RF: 0, FI: 00, SI: 00)

[0152] Upon receiving a PDCP PDU, the RLC can prepare the RLC subheader and length field of the PDCP PDU length by assigning the E bit to 1. The length field can be prepared in the same memory just before the PDCP PDU or in a separate memory. This operation corresponds to... Figure 7 Operation 701. During parallel transmission, RLC can also choose to package interleaved PDCP SDUs into a single TB.

[0153] - Based on the received permission, RLC can pack the available PDCP PDU and its length header according to the order in which the packets are received and the FI field is updated.

[0154] - The E bit of the last PDCP belonging to this RLC PDU can be set to 0, indicating the end of the RLC PDU. Furthermore, the length field of the last RLC subheader can be updated to the actual length of the PDCP PDU segment it contains.

[0155] During the next license opportunity / cycle, the remaining PDCP PDU fragment, which has a new and updated RLC subheader with appropriate FI and length, can be transmitted.

[0156] A single RLC PDU with multiple cascaded PDCP PDUs can have a fixed-size RLC header consisting of a unique RLC SN.

[0157] The P bit in the RLC header can be set according to the polling conditions.

[0158] MAC can assign a single MAC subheader with E, LCID, and total length, along with an RLC PDU.

[0159] As an example, according to Figure 11Assuming the received available clearance is 7020, after RLC preprocessing, concatenation of one or more complete PDCP PDUs is performed, as shown in box 115. Subsequently, 0 is assigned as the first RLC SN to the concatenated complete PDCP PDU packets in box 115 at 111. Then, a new or unique RLC SN number, i.e., 113, is assigned to the new PDCPPDU packets 117 that are truncated due to fewer available MAC clearances. Therefore, this complete transport block is transmitted in this current transport cycle. Furthermore, new PDCP PDUs for the remaining segments are transmitted in the next transport cycle, assuming the next transport cycle occurs when the received MAC clearance exceeds 2012. Therefore, in the next transport cycle, the new PDCPPDUs for the remaining segments use the same SN number, i.e., 113. Therefore, in the next transport cycle, further segmentation of the new PDCP PDUs may be performed due to fewer available MAC clearances. In this case, the remaining portion of the segmented new PDCP PDUs is again divided into at least one more first complete PDCP PDU packet and a second new PDCP PDU packet. Here, the same new RLC sequence number (SN) is assigned to at least one other first complete PDCP PDU packet, and another new RLC sequence number (SN) is assigned to a second new PDCP PDU packet. Subsequently, an RLC PDU is prepared and transmitted by accommodating at least one first complete PDCP PDU packet and the second new PDCP PDU packet based on available MAC clearance. Furthermore, the remainder of the second new PDCP PDU packet will be transmitted in the next upcoming MAC clearance transmission cycle.

[0160] Figure 12a The retransmission and resegmentation mechanism according to embodiments of this disclosure is illustrated. The next-generation RLC header retransmission and resegmentation process will be explained thereafter.

[0161] - Initially, there may be no RLC AMD PDU fragments formed during the first transmission. However, RLC AMD PDU fragments may only be formed during resegmentation and retransmission.

[0162] - Based on state PDU reception, an ACKed RLC SN can be released. In particular, a complete, unsegmented PDCP PDU belonging to an ACKed RLCSN can be released.

[0163] - If each RLC SN is ACKed, then PDCP PDUs belonging to more than one RLC SN can be released.

[0164] - For an RLC SN that has been NACKed, the RLC SN payload can be completely retransmitted.

[0165] - If sufficient licenses are available, the complete RLCPDU previously formed for that RLC SN can be transmitted as is, without any changes to the header (except for the P bit).

[0166] If there are few available licenses from the MAC, the retransmitted RLC PDU can be further segmented.

[0167] For the first AMD PDU segment to be retransmitted, set the RF flag to 1 and the SI flag to 01 (indicating the first segment). It does not have an SO field because SO=0 is redundant information and FI can be updated based on the original AMD PDU.

[0168] On the next transmission opportunity, based on available licenses, an RLC AMD PDU fragment header can be created by assigning information to D / C-1, RF-1, SI-10 (for the end of the fragment) or SI-11 (for the middle of the fragment), SN (as the original AMD PDU), and SO (16 bits) according to the actual offset of the fragment PDU. FI can be updated based on the original AMD PDU.

[0169] Therefore, the FI bit (fragment information) can optionally be set to be packed in the RLC AMD PDU fragment rather than the actual cascaded PDCP PDU that retains the original FI of the AMD PDU fragment.

[0170] Figure 12b This illustration shows yet another embodiment of the next-generation data plane during a retransmission process implementing a resegmentation mechanism, according to embodiments of the present disclosure. References Figure 27 The process of re-segmenting is explained below.

[0171] Consider the scenario of RLC PDU loss. The transmitter entity receives a NACK from the receiver entity reporting the loss of the RLC SN, therefore these packets must be retransmitted. For retransmission, the RLC header and PDCP payload (i.e., the RLC PDU) are stored in the retransmission buffer entity. If sufficient clearance is available from the MAC to retransmit the complete PDU, the original RLC PDU is transmitted as is. If less clearance is available from the MAC, the RLC PDU is further segmented in a resegmentation mechanism, such as... Figure 27 As described. When retransmitting the first segment of the original RLC PDU, only the RF and SI bits are updated to 0 and 01 respectively to indicate that this segment is the first segment of the original RLC PDU corresponding to the NACKed RLC SN. During the next transmission opportunity, an RLC segment header indicating the correct SO is prepared, and the remaining segments of the RLC PDU are retransmitted without changing any original RLC PDU information.

[0172] The various variations of the RLC header structure will now be described in detail below.

[0173] Figure 13 The header structure of a UMD PDU according to a variant 1 of this disclosure is shown. If FI = 00, the UMD PDU may not contain a serial number (SN). If FI = 01, 10, or 11, the UMD PDU may contain a SN. A new RLC SN can be assigned to each subsequent UMD PDU where FI is any of 01, 10, or 11. Furthermore, there may be no UMD PDU fragment, and the interpretation of E and field lengths is the same as for AMD PDUs.

[0174] According to yet another embodiment, several variations of the next-generation RLC header structure will be explained thereafter. In one implementation of variation 3, instead of the E bit in the RLC length subheader, the number of PDCP PDUs added can be indicated by the RLC subheader of the NumSDU. Furthermore, in variations 1 and 3, the length of the RLC subheader can be distributed across the RLC PDU. However, the distributed RLC subheader length may not pose a problem if hardware (HW) parsing is complete. However, accessing memory across the entire extension of the RLC PDU to parse the distributed length of the RLC subheader during RLC header parsing in the SW can cause more cache misses and heavy processing. Therefore, all RLC subheader lengths can be bundled together at the beginning of the RLC header itself, and PDCP PDUs can continue to be placed thereafter. This approach may result in other variations of variations 1 and 3 as described above.

[0175] According to yet another embodiment, the total RLC PDU length can be included in the MAC subheader of the RLC PDU. Optionally, the length field of the last SDU in the RLC PDU may be redundant and may not be included. Its length can be calculated as (total RLC PDU length - (sum of the lengths of all other RLC SDUs)). This further produces more variations in which the length of the RLC SDU in the RLC PDU is not included. Regardless of any option, the AMD PDU fragment header remains the same for all options. Furthermore, the UMD PDU header follows the same packing of the length subheader based on the above selections.

[0176] Therefore, the next-generation RLC header structure can be implemented using any variant based on at least one of the following parameters:

[0177] Position of the RLC length subheader;

[0178] The distributed RLC length sub-header is placed exactly before each PDCP PDU;

[0179] Packed RLC length subheaders - all length subheaders are placed exactly after the RLC fixed header;

[0180] Indicator of length;

[0181] Use the E bit to indicate the next set of length fields that exist;

[0182] Use NumSDU to indicate the total length field of the total cascaded PDCP PDUs;

[0183] The length of the last SDU in the included RLC PDU; and

[0184] If not included, the length is calculated based on the total RLC PDU length in the MAC subheader - (the sum of the lengths of other SDUs).

[0185] Figure 14 This illustrates yet another variation 3 of the next-generation RLC header according to embodiments of the present disclosure. In one implementation, the length of the PDCP PDU can be 2 bytes preceding the PDCP PDU. The number of SDUs concatenated in the RLC PDU can be indicated by a field preceding the NumSDU (8 bits). All remaining parameter interpretations and procedures remain the same as described in the above embodiments. The AMD PDU fragment structure is the same as described above. Figure 8 The same as described in [the original text]. Except for the fixed-size RLC header, the remaining bytes of the original AMDPDU are considered the data portion of the AMD PDU fragment. Optionally, since NumSDU=1 is redundant information, this can be indicated using R bits indicating whether NumSDU is present (1) or absent (0).

[0186] Figure 15 A UMD PDU header according to a variant 3 of an embodiment of this disclosure is shown. The description of the UMD PDU header is consistent with that in... Figure 10a The explanation is the same as in the text. Therefore, for the sake of brevity, the description of the UMD PDU header is omitted here.

[0187] Figure 16 Another embodiment of the user plane according to the present disclosure is shown, which is a variant 1 / variant 3 of the data plane having a packed length sub-header.

[0188] Figure 17 Another embodiment of a variant 1 / 3 of a next-generation RLC header with a packed length subheader, according to embodiments of this disclosure, is shown. In this case, the AMD PDU has a 16-bit SN or the AMD PDU segment has a 16-bit SN without an SO.

[0189] Figure 18 Another embodiment of a UMDPDU header with a packed length subheading according to variant 1 is shown in accordance with the present disclosure.

[0190] Figure 19 Another embodiment of a UMDPDU header with a packed length subheading according to variant 3 of the present disclosure is shown.

[0191] Figure 20 This illustrates yet another embodiment of a next-generation user plane according to an embodiment of the present disclosure, which has a packed length sub-header but no final SDU length.

[0192] Figure 21 Another embodiment of the next-generation RLC header according to the present disclosure is shown, which has a packed length subheader but no final SDU length. Thus, the AMD PDU has a 16-bit SN, where N>1, or the AMD PDU fragment has a 16-bit SN without an SO, where N>1.

[0193] Figure 22 Another embodiment of the UMD PDU header according to the present disclosure is shown, which has a packed length sub-header but no final SDU length.

[0194] Figure 23 Another embodiment of the UMD PDU header according to an embodiment of the present disclosure is shown, which has a packed length sub-header but no final SDU length. Therefore, for FI = 00, the UMD PDU has no SN, where N > 1, or for FI! = 00, the UMD PDU has 16 SNs, where N > 1.

[0195] Figure 24 Another embodiment of the next-generation RLC header according to the present disclosure is shown, which has a distributed length subheader but no final SDU length. Thus, the AMD PDU has a 16-bit SN, where N>1, or the AMD PDU segment has a 16-bit SN without an SO, where N>1.

[0196] Figure 25 Another embodiment of the RLC UMD PDU header according to embodiments of the present disclosure is shown, which has a distributed length sub-header but no final SDU length. Thus, for FI = 00, the UMD PDU has no SN, where N > 1, or for FI! = 00, the UMD PDU has 16 SNs, where N > 1.

[0197] Figure 26Another embodiment of the RLC UMD PDU header according to an embodiment of the present disclosure is shown, which has a distributed length sub-header but no final SDU length. Thus, for FI = 00, the UMD PDU has no SN, where N > 1, or for FI not equal to 00, the UMD PDU has 16 SN, where N > 1.

[0198] Therefore, through the aforementioned variations of the RLC header structure, this disclosure achieves an optimal structure compared to the 4G and 5G RLC header structures. In particular, the advantage over 4G is that the current variations of the RLC header structure have a fixed-size RLC header and preprocessing. Regarding 5G, this disclosure provides a reduced number of RLC SNs and fewer MAC subheaders. Since the RLCPDU concatenates multiple PDCP PDUs into a single RLC PDU, the number of RLC SNs required at extremely high data rates is significantly reduced. Furthermore, the fixed RLC header size has a constant size because the length field of the PDCP PDU is pushed and segmented on the RLC PDU. This facilitates preprocessing, as explained above. Additionally, the RLC AMD PDU fragment header size has the same size as the first fragment and is therefore easier to interpret. In the case of fragments in the middle and at the end of the original AMD PDU, the RLCAMD PDU fragment header size has an additional 2-byte field for the SO. Furthermore, by having fixed positions and sizes for the MAC, RLC, and PDCP headers, all PDCP headers except those that are fragmented during concatenation can be parsed in HWA. However, if the minimum license guarantee supports the combined size of the MAC subheader, RLC header, PDCP PDU header length, and PDCP header, then for any AMD PDU (except AMD PDU fragments), HWA can be used to implement the RLC and MAC headers. Furthermore, the absence of fragments in the first transmission greatly simplifies RLC status report processing. Additionally, fragment processing is limited to the case of re-segmentation. Therefore, this disclosure provides a) a smaller number of RLC SNs, b) fixed-size RLC headers, c) preprocessing, and d) efficient fragmentation information.

[0199] In view of the foregoing, various advantageous features relating to this disclosure are provided:

[0200] Concatenating multiple packets consecutively packed in TB is particularly useful when packet sizes are smaller. For a standard 1500-byte IP packet, this can improve receive (RX) side performance by approximately 3x when the best possible permissions are available.

[0201] The proposed header structure packing, with its enhanced TX preprocessing and parallel TX implementation, allows for simplified RX processing.

[0202] This reduces the number of RLC SNs required at extremely high data rates because the RLC PDU cascades multiple PDCPPDUs into a single RLC PDU. This, in turn, reduces the RX processing load, and completed PDCP PDUs are delivered immediately once verified.

[0203] The RLC fixed header size has a constant size because the length field of the PDCP PDU is considered a separate RLC subheader.

[0204] The RLC AMD PDU fragment header size is easier to interpret because it has the same size as the first fragment. In the case of fragments in the middle and at the end of the original AMD PDU, the RLC AMD PDU fragment header size has an additional 2-byte field for the SO.

[0205] RLC status reporting processing is greatly simplified because the RLC SN is reduced by ~2 / N compared to NR, where N is the RLC SDU cascaded into a single RLC PDU.

[0206] The processing of RLC TX and RLC RX can be performed in parallel cores, thereby enhancing the entire process.

[0207] With fixed positions and sizes for MAC, RLC, and PDCP headers, and all PDCP headers except those that are (segmented), all headers can be parsed in HWA.

[0208] Figure 27 The differences between the next-generation RLC header according to embodiments of this disclosure and the prior art RLC header structure are illustrated. There is a variable-size RLC header, no preprocessing, and LI lacks byte alignment in LTE. NR requires a large number of RLC SNs and a MAC subheader for each PDU. The next-generation RLC header has the following advantages:

[0209] The RLC header has a fixed size and is prepared in memory.

[0210] The length subheader is byte-aligned and can be prepared in the parallel TX core for any upcoming RLC SDU.

[0211] The length information becomes part of the RLC subheader. Starting from the length subheader, the RLC PDU payload is considered.

[0212] The length field of the last packaged PDCP PDU is omitted from the header.

[0213] For consecutive PDCP PDUs that can be fully packaged in a TB, there exists a single RLC SN.

[0214] The first fragment of the transmitted PDCP PDU only needs to update the SI field = (01), and there is no SO for this.

[0215] In subsequent licenses, a new 5-byte RLC fragment header will be prepared only for the middle / final segments of this PDCP PDU.

[0216] Figure 28 The differences between the RLC mechanism according to embodiments of this disclosure and prior art RLC header structures are illustrated. In LTE, a single MAC TB contains only a single RLC SN per logical channel (LCH), while in the proposed RLC mechanism, a single MAC TB will contain a single RLC SN for all fully packed RLC SDUs and an RLC SN for each RLC segment. Furthermore, in LTE, segmentation / reassembly is based on the FI field and consecutive RLC SNs. The SI and SO fields are only used for segment retransmission or resegmentation, while in the new method, segmentation / reassembly can be based on the RLC SN, SI, and SO fields. The new method supports parallel TX processing. Additionally, in NR, the RLC SN space is the same as the PDCP SN space, while in the new RLC mechanism, the RLC SN space is the PDCP SN range * 2 / N, where N is the average number of RLC SDUs in each MAC TB.

[0217] Figure 29 Various simulation results according to embodiments of this disclosure are shown. Therefore, the advantages of next-generation RLC mechanisms over the prior art are then presented.

[0218] refer to Figure 29 The CPU cycles were compared with NR and the proposed RLC mechanism in a simulated environment. Simulated scenarios: license (G): 13686 bytes, size: 1500B, PDU loss rate (B): 0% and 10%. Because the number of RLC SNs is significantly reduced in the proposed method, the average number of cycles required for RX processing per PDCP SDU has an approximately ~40% gain (2350 cycles -> 1412 cycles).

[0219] Table 1 shows a feature comparison between LTE, NR, and the next-generation RLC mechanism. Features such as preprocessing, parallel TX, TX cycle, parallel RX, hardware-friendly architecture, SN space requirements, and Rx processing cycle are considered for comparison, and the advantages of the next-generation RLC mechanism over existing technologies are explained.

[0220] [Table 1]

[0221]

[0222] Figure 30Another illustration of a network node according to an embodiment of the present disclosure is shown. Network node 3000 may include a TX / RX 3005 (e.g., a communicator or communication interface), a memory unit 3003 (e.g., a storage device), and at least one processor 3001. Furthermore, network node 3000 may also include a cloud RAN (C-RAN), a central unit (CU), a core network (NW), a distributed unit (DU), or any other possible network (NW) entity. Various examples of network nodes have been explained above and are therefore omitted here for brevity. The TX / RX unit 3005 can be used as a transmitter or receiver entity to perform the function of transmitting and receiving signals via a wireless channel.

[0223] In the example, processor 3001 can be a single processing unit or multiple units, all of which can include multiple computing units. Processor 3001 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuit systems, and / or any means of manipulating signals based on operating instructions. Among other capabilities, processor 3001 is configured to acquire and execute computer-readable instructions and data stored in memory. A processor can include one or more processors. In this case, the one or more processors can be general-purpose processors such as central processing units (CPUs), application processors (APs), graphics processing units only such as graphics processing units (GPUs), vision processing units (VPUs), and / or dedicated AI processors such as neural processing units (NPUs). One or more processors control the processing of input data according to predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory. Predefined operating rules or AI models are provided through training or learning.

[0224] The memory may include any non-transitory computer-readable medium, including, for example, volatile memory (such as static random access memory (SRAM) and dynamic random access memory (DRAM)) and / or non-volatile memory (such as read-only memory (ROM)), erasable programmable ROM, flash memory, hard disk, optical disk and magnetic tape.

[0225] Figure 31 This is an illustration showing the configuration of a terminal in a wireless communication system according to an embodiment of the present disclosure. Figure 31 The configuration can be understood as part of the terminal's configuration. In the following text, it should be understood that terms ending with "unit" or "device" can refer to a unit for processing at least one function or operation, and can be implemented in hardware, software, or a combination of hardware and software.

[0226] refer to Figure 31Terminal 3100 may include a TX / RX unit 3103 (e.g., a communicator or communication interface), a storage unit 3105 (e.g., a storage device), and at least one processor 3101. By way of example, terminal 3100 may be user equipment, such as a cellular phone, or other device that communicates via multiple cellular networks, such as third-generation (3G), 4G, 5G or near-5G networks, 6G, or any future wireless communication networks. The TX / RX unit 3103 may be used as a transmitter entity or a receiver entity and may perform the function of transmitting and receiving signals via a wireless channel.

[0227] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. The systems, methods, and examples provided herein are illustrative only and are not intended to be limiting.

[0228] The benefits, other advantages, and solutions to the problems have been described above with reference to specific embodiments. However, the benefits, advantages, solutions to the problems, and any components that may make any benefit, advantage, or solution appear or become more significant should not be construed as being key, necessary, or essential features or components of any or all claims.

[0229] Although this disclosure has been shown and described with reference to various embodiments, those skilled in the art will understand that various changes in form and detail may be made without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method for transmitting data over a radio link established between a user equipment (UE) and a network node, the method comprising: The Radio Link Control (RLC) layer receives multiple Protocol Data Unit (PDU) packets from the Packet Data Convergence Protocol (PDCP) layer; The RLC layer preprocesses the RLC subheader of the RLC header of each of the multiple PDU packets based on the length of the Service Data Unit (SDU) received from the PDCP layer for each of the multiple PDU packets; The RLC layer concatenates at least one complete PDCP PDU packet and RLC subheader length information from the plurality of PDU packets into the RLC PDU based on available media access control (MAC) permission; The RLC layer segments the multiple PDU packets into new PDCP PDU packets, which are truncated due to fewer available MAC permissions. The RLC PDU is prepared together with the RLC header, the RLC PDU comprising at least one complete PDCPPDU packet concatenated and at most one new PDCP PDU packet segmented based on the available MAC permission; as well as The RLC PDU is transmitted from the RLC layer to the MAC layer below.

2. The method according to claim 1, further comprising: Assign the first RLC sequence number (SN) to at least one complete PDCP PDU packet in the cascade; as well as Assign the new RLC SN to the new PDCP PDU group.

3. The method according to claim 1, further comprising: The RLC layer receives an available MAC license from the lower MAC layer, wherein the RLC header includes a predetermined fixed size.

4. The method of claim 2, wherein preparing the RLC PDU comprises: The RLC layer determines whether the available MAC license is sufficient to include the at least one complete PDCP PDU packet; Based on available MAC permissions and available PDCP PDUs, the plurality of PDU packets are divided into at least one complete PDCPPDU packet and the new PDCP PDU packet, wherein a new RLC SN is assigned to the new PDCP PDU packet and is different from the first RLC SN assigned to the at least one concatenated complete PDCP PDU packet, wherein the new RLC header of the new PDCP PDU packet includes only the new RLC SN and does not include the RLC subheader length information; as well as The RLC PDU is prepared by accommodating the new PDCP PDU packet and the at least one complete PDCP PDU packet based on the available MAC license. The at least one complete PDCP PDU packet is defined as a PDCP PDU packet that can be fully transmitted, and the new PDCP PDU packet is defined as a PDCP PDU packet that cannot be fully transmitted according to the available MAC permission. Specifically, based on the availability of MAC licenses and the insufficient number of PDCP PDUs, the RLC PDU is prepared using at least one complete PDCP PDU packet, and The RLC PDU is transmitted using at least one complete PDCP PDU packet.

5. The method of claim 4, further comprising: In subsequent PDUs, the remaining portion of a new PDCP PDU packet with a newly assigned RLC SN that was not contained in the RLC PDU is transmitted in the next MAC-licensed transmission cycle.

6. The method of claim 5, further comprising: The RLC layer receives the available MAC license in the next MAC license transmission cycle; The RLC layer determines whether the available MAC license is sufficient to include at least one first complete PDCP PDU packet from the remaining portion of the new PDCP PDU packet; The remaining portion of the new PDCP PDU packet is divided into the at least one first complete PDCP PDU packet and the second new PDCP PDU packet based on the available MAC license and available PDCP PDU, wherein a new RLC SN is assigned to the at least one first complete PDCP PDU packet; A new RLC SN different from the new RLC SN is assigned to the second new PDCP PDU packet, wherein the new RLC header of the second new PDCP PDU packet includes only the new RLC SN and does not include the RLC subheader length information; as well as The RLC PDU is prepared by accommodating the at least one complete PDCP PDU packet and the second new PDCP PDU packet based on the available MAC license, wherein the remainder of the second new PDCP PDU packet is transmitted in the next MAC license transmission cycle.

7. The method of claim 1, further comprising: Receive an unsuccessful acknowledgment message associated with the transmission failure of the RLC PDU from the receiver entity; Based on the receipt of the unsuccessful acknowledgment message, the RLC PDU is retransmitted to the lower MAC layer in the next transmission cycle; The RLC layer receives a newly available MAC license from the lower MAC layer in the next transmission cycle; Determine that the newly available MAC license is sufficient to retransmit the RLC PDU in the next transmission cycle; The RLC layer retransmits the RLC PDU, which is similar to the RLC PDU that failed to transmit, and the RLC header to the lower MAC layer based on the sufficient availability of the newly available MAC permission; The RLC layer determines whether the newly available MAC license is insufficient to retransmit the RLC PDU using the newly available MAC license; as well as The RLC PDU is re-segmented based on the result of determining whether the newly available MAC license is insufficient, wherein the re-segmentation corresponds to segmenting the plurality of PDU packets into at least two RLC PDU packets that are truncated due to the limited availability of the newly available MAC license.

8. An apparatus for transmitting data over a radio link established between a user equipment (UE) and a network node, the apparatus comprising: A transceiver configured to transmit and receive signals; as well as A processor, coupled to the transceiver and configured to: The Radio Link Control (RLC) layer receives multiple Protocol Data Unit (PDU) packets from the Packet Data Convergence Protocol (PDCP) layer. The RLC layer preprocesses the RLC subheader of the RLC header of each of the multiple PDU packets based on the length of the Service Data Unit (SDU) received from the PDCP layer for each of the multiple PDU packets. The RLC layer concatenates at least one complete PDCP PDU packet from multiple PDU packets, along with RLC sub-header length information, into an RLC PDU based on available Media Access Control (MAC) permissions. The RLC layer segments the multiple PDU packets into new PDCP PDU packets, which are truncated due to the reduced availability of MAC permissions. The RLC PDU is prepared together with the RLC header, the RLC PDU comprising at least one concatenated complete PDCPPDU packet and at most one new PDCPPDU packet segmented based on the available MAC permission, and The RLC PDU is transmitted from the RLC layer to the MAC layer below.

9. The device of claim 8, wherein the processor is further configured to: Assign the first RLC sequence number (SN) to at least one complete PDCP PDU packet in the cascade, and Assign the new RLC SN to the new PDCP PDU group.

10. The device of claim 8, wherein the processor is further configured to: The RLC layer receives available MAC permissions from the underlying MAC layer, and The RLC header mentioned therein includes a predetermined fixed size.

11. The device of claim 9, wherein the processor is further configured to: The RLC layer determines whether the available MAC license is sufficient to include the at least one complete PDCP PDU packet. Based on available MAC permissions and available PDCP PDUs, the plurality of PDU packets are divided into at least one complete PDCPPDU packet and the new PDCP PDU packet, wherein a new RLC SN is assigned to the new PDCP PDU packet and is different from the first RLC SN assigned to the at least one concatenated complete PDCP PDU packet, wherein the new RLC header of the new PDCP PDU packet includes only the new RLC SN and does not include the RLC subheader length information, and The RLC PDU is prepared by accommodating the new PDCP PDU packet and the at least one complete PDCP PDU packet based on the available MAC license. The at least one complete PDCP PDU packet is defined as a PDCP PDU packet that can be fully transmitted, and the new PDCP PDU packet is defined as a PDCP PDU packet that cannot be fully transmitted according to the available MAC permission. in, Based on the availability of MAC licenses and the insufficiency of the PDCP PDU, the RLC PDU is prepared using at least one complete PDCP PDU packet, and The RLC PDU is transmitted using at least one complete PDCP PDU packet.

12. The device of claim 11, wherein the processor is further configured to: In a subsequent PDU, the remaining portion of the new PDCP PDU packet with the assigned new RLC SN that was not contained in the RLC PDU is transmitted in the next MAC licensed transmission cycle.

13. The device of claim 12, wherein the processor is further configured to: The RLC layer receives the available MAC license in the next MAC license transmission cycle. The RLC layer determines whether the available MAC license is sufficient to include at least one first complete PDCP PDU packet from the remaining portion of the new PDCP PDU packet. The remaining portion of the new PDCP PDU packet is divided into at least one first complete PDCP PDU packet and a second new PDCP PDU packet based on available MAC licenses and available PDCP PDUs, wherein the new RLC SN is assigned to the at least one first complete PDCP PDU packet. Assign a new RLC SN, different from the new RLC SN, to the second new PDCP PDU packet, wherein the new RLC header of the second new PDCP PDU packet includes only the new RLC SN and does not include the RLC subheader length information. The RLC PDU is prepared by accommodating the at least one complete PDCP PDU packet and the second new PDCP PDU packet based on the available MAC license, wherein the remainder of the second new PDCP PDU packet is transmitted in the next MAC license transmission cycle.

14. The device of claim 8, wherein the processor is further configured to: Receive an unsuccessful acknowledgment message associated with the transmission failure of the RLC PDU from the receiver entity. Based on the receipt of the unsuccessful acknowledgment message, the RLC PDU is retransmitted to the lower MAC layer in the next transmission cycle. The RLC layer receives the newly available MAC license from the lower MAC layer in the next transmission cycle. Determine that the newly available MAC license is sufficient to retransmit the RLC PDU in the next transmission cycle. The RLC layer, based on sufficient newly available MAC permissions, retransmits the RLC PDU, similar to the failed RLC PDU, and the RLC header to the lower MAC layer. The RLC layer determines whether the newly available MAC license is insufficient to retransmit the RLCPDU using the newly available license, and The RLC PDU is re-segmented based on the result of determining whether the newly available MAC licenses are insufficient, wherein the re-segmentation corresponds to segmenting the plurality of PDU packets into at least two RLC PDU packets that are truncated due to the limited availability of the newly available licenses.

15. The device of claim 8, wherein the device comprises a transmitter entity or a receiver entity.

16. The device of claim 15, wherein the transmitter entity or receiver entity is located on the network side or in the user equipment (UE).

17. The device of claim 9, wherein the new RLC SN assigned to the new PDCP PDU packet is different from the first RLC SN.

18. The device of claim 8, wherein preprocessing of the RLC sub-header is performed after receiving a plurality of PDU packets and before concatenating at least one complete PDCP PDU packet.

Images