Method and apparatus for parallel processing of radio link control protocol data units

Abstract

A method and apparatus for parallel processing of radio link control protocol data units is provided, the method including receiving a radio link control (RLC) protocol data unit (PDU) from a lower layer of a radio protocol stack. The RLC PDU is received on a data path associated with a respective sequence number (SN) space, and the RLC PDU received on each of the data paths includes a data path identifier identifying the data path. The method includes constructing a status PDU including a status report, per data path, for one or more of the data paths in the data path identified in the status PDU by the data path identifier. And the method further includes transmitting the status PDU to a peer RLC entity from which the RLC PDU originated.

Description

Technical Field

[0001] This disclosure relates generally to telecommunications, and more specifically to the processing of radio link control protocol data units in telecommunications systems. Background Technology

[0002] A telecommunications system can be considered a facility that facilitates communication between two or more entities, such as between two user equipments (UEs), between a UE and a base station, between two base stations, between a UE and a network function of a communication network, and / or between a base station and other nodes. A telecommunications system may include a communication network and one or more UEs. A communication session may include, for example, communication of data used to carry communications such as voice, video, email, text messages, multimedia, and / or content data. Non-limiting examples of services provided include two-way or multi-way calling, data communication or multimedia services, and access to data network systems such as the Internet.

[0003] In telecommunications systems that include wireless communication networks, at least a portion of a communication session between at least two sites occurs via a radio link. Examples of wireless communication networks include Public Land Mobile Networks (PLMNs), satellite-based communication networks, and various wireless local networks, such as Wireless Local Area Networks (WLANs). Some wireless communication networks can be divided into cells and are therefore often referred to as cellular networks.

[0004] Users can access telecommunications systems using appropriate communication equipment or terminals. A user's communication equipment can be referred to as user equipment (UE) or user device. The communication equipment is provided with appropriate signal receiving and transmitting means to enable communication, such as enabling access to a communication network or direct communication with other users. The communication equipment can access, for example, a carrier provided by a base station in a cell, and transmit and / or receive communication on that carrier.

[0005] Telecommunications systems have undergone multiple generations of development, each advancing in speed, capacity, and functionality. Evolved Packet System (EPS) represents the 4G architecture, which includes Long Term Evolution (LTE) and LTE-A Advanced (LTE-A) as its radio access technologies. 5G systems (5GS) are based on EPS and introduce 5G New Radio (5G NR) to enhance mobile broadband, massive machine-type communications, and ultra-reliable low-latency communications. Future 6G systems (6GS) are expected to further revolutionize telecommunications with even more advanced capabilities. These systems are interconnected, and 5GS is designed to interoperate with EPS for seamless service continuity. The 3rd Generation Partnership Project (3GPP) plays a crucial role in developing and maintaining standards for these telecommunications systems, ensuring global interoperability and evolution from the Universal Mobile Telecommunications System (UMTS) (3G) to the emerging 6G technology. Summary of the Invention

[0006] The example implementations of this disclosure are geared towards the telecommunications field, and specifically towards radio link control protocol data unit processing in telecommunications systems. Therefore, this disclosure includes, but is not limited to, the following example implementations.

[0007] Some example implementations provide an apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute the instructions such that the apparatus at least: receives Radio Link Control (RLC) Service Data Units (SDUs) from a higher layer of the radio protocol stack; distributes RLC Protocol Data Units (PDUs) of the RLCSDUs to data paths associated with corresponding sequence number (SN) spaces; associates each of the RLCSDUs with a data path identifier that identifies a data path in a data path associated with a corresponding SN space; constructs one or more RLCPDUs for each RLC SDU, each RLC PDU including the RLC SDU or a fragment of the RLC SDU, the data path identifier associated with the RLC SDU, and an SN from a corresponding SN space; and submits the RLC PDUs on the data paths toward a lower layer of the radio protocol stack.

[0008] Some example implementations provide a method comprising: receiving Radio Link Control (RLC) Service Data Units (SDUs) from a higher layer of the radio protocol stack; distributing RLC Protocol Data Units (PDUs) of the RLC SDUs to data paths associated with corresponding sequence number (SN) spaces; associating each of the RLC SDUs with a data path identifier that identifies a data path in a data path associated with a corresponding SN space in the corresponding SN space; constructing one or more RLC PDUs for each RLC SDU, each RLC PDU comprising the RLC SDU or a fragment of the RLC SDU, the data path identifier associated with the RLC SDU, and an SN from a corresponding SN space in the corresponding SN space; and submitting the RLC PDUs on the data paths toward a lower layer of the radio protocol stack.

[0009] Some example implementations provide an apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute instructions such that the apparatus at least: receives Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of a radio protocol stack, the RLC PDUs being received on data paths associated with corresponding Sequence Number (SN) spaces, wherein each RLC PDU received on a data path includes: a data path identifier identifying the data path, and an SN from the corresponding SN space associated with the data path; detects at least one missing RLC PDU per data path based on the data path identifier identifying the data path and the SN from the SN space associated with the data path; reports the at least one missing RLC PDU; reassembles an RLC Service Data Unit (SDU) from the RLC PDU; and submits an RLC Service Data Unit (RLCSDU) to a higher layer of the radio protocol stack.

[0010] Some example implementations provide a method comprising: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of a radio protocol stack, the RLC PDUs being received on data paths associated with corresponding Sequence Number (SN) spaces, the RLC PDUs received on each data path including a data path identifier for identifying the data path, and an SN from the corresponding SN space associated with the data path; detecting at least one missing RLC PDU per data path based on the data path identifier for identifying the data path and the SN from the SN space associated with the data path; reporting the at least one missing RLC PDU; reconstructing an RLC Service Data Unit (SDU) from the RLC PDUs; and submitting the RLC SDU to a higher layer of the radio protocol stack.

[0011] Some example implementations provide an apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute instructions such that the apparatus at least: receives Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of a radio protocol stack, the RLC PDUs being received on data paths associated with corresponding sequence number (SN) spaces, and each RLC PDU received on a data path including a data path identifier identifying the data path; constructs a state PDU including a status report per data path for one or more data paths of the RLC PDUs identified by the data path identifier in the state PDU; and sends a state PDU to a peer RLC entity, the RLC PDUs originating from the peer RLC entity.

[0012] Some example implementations provide a method comprising: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of the radio protocol stack, the RLC PDUs being received on data paths associated with corresponding sequence number (SN) spaces, and the RLC PDUs received on each data path including a data path identifier that identifies the data path; constructing a state PDU, the state PDU including a status report per data path for one or more data paths of the RLC PDUs identified by the data path identifier in the state PDU; and sending the state PDUs to a peer RLC entity, the RLC PDUs originating from the peer RLC entity.

[0013] Some example implementations provide an apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory and execute instructions such that the apparatus at least: receives Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of a radio protocol stack, the RLC PDUs being received on data paths associated with corresponding Sequence Number (SN) spaces, wherein at least some of the RLC PDUs received on at least one of the data paths in the data paths include: an RLC Service Data Unit (SDU) fragment, a data path identifier identifying the data path, and an SN from the corresponding SN space associated with the data path; detects at least one missing RLC PDU for at least one RLC SDU fragment according to each of the at least one data path in the data paths, based on the data path identifier identifying the data path and the SN from the SN space associated with the data path; reassembles the RLC SDU fragments from the RLC PDUs into an RLC SDU according to the data path, based on the data path identifier identifying the data path; and submits the RLC SDU to a higher layer of the radio protocol stack.

[0014] Some example implementations provide a method comprising: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of a radio protocol stack, the RLC PDUs being received on a data path associated with a corresponding Sequence Number (SN) space, wherein at least some of the RLC PDUs received on at least one data path in the data path include: an RLC Service Data Unit (SDU) fragment, a data path identifier identifying the data path, and an SN from the corresponding SN space associated with the data path; detecting at least one missing RLC PDU for at least one RLC SDU fragment according to each data path in the at least one data path, based on the data path identifier identifying the data path and the SN from the SN space associated with the data path; reassembling the RLC SDU fragments from the RLC PDUs into an RLC SDU according to the data path, based on the data path identifier identifying the data path; and submitting the RLC SDUs to a higher layer of the radio protocol stack.

[0015] These and other features, aspects, and advantages of this disclosure will become apparent from the following detailed description and the accompanying drawings, which are briefly described below. This disclosure includes any combination of two, three, four, or more features or elements set forth herein, whether or not such features or elements are explicitly combined in the particular example implementation described herein or otherwise described. This disclosure is intended to be read in its entirety; therefore, unless the context of this disclosure expressly specifies otherwise, any separable feature or element in any aspect of this disclosure and any example implementation should be considered composable.

[0016] Therefore, it should be understood that the content of this invention is provided only to summarize some exemplary implementations in order to provide a basic understanding of some aspects of this disclosure. Accordingly, it should be understood that the above-described exemplary implementations are merely examples and should not be construed as limiting the scope or spirit of this disclosure in any way. Other exemplary implementations, aspects, and advantages will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of some of the described exemplary implementations. Attached Figure Description

[0017] Having provided a general description of the exemplary implementation of this disclosure, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale. In the drawings:

[0018] Figure 1 The illustration shows a telecommunications system implemented according to some examples of the present disclosure, which includes one or more public land mobile networks (PLMNs) coupled to one or more external data networks.

[0019] Figure 2 The diagram illustrates a PLMN implementation based on some examples;

[0020] Figure 3 The diagram illustrates a partial overview of a radio protocol stack architecture implemented based on some examples;

[0021] Figure 4 The diagram illustrates a model of the radio link control (RLC) layer of a radio protocol stack implemented according to some examples, which includes a transmit RLC entity at the radio access network (RAN) node and a receive RLC entity at the user equipment (UE).

[0022] Figure 5 , Figure 6 , Figure 7 and Figure 8 The illustration shows an example of an Acknowledgment Mode (AM) Data (AMD) Protocol Data Unit (PDU) implemented according to some examples, where the Data Path Identifier (DPID) and Sequence Number (SN) can be carried in separate fields in the RLC header;

[0023] Figure 9 and Figure 10 The illustration shows an example of an unacknowledged mode (UM) data (UMD) PDU implemented according to some examples, where the DPID and SN can be carried in separate fields in the RLC header;

[0024] Figure 11 , Figure 12 , Figure 13 and Figure 14 The illustration shows an example of an AMD PDU implemented according to some examples, where the DPID can be carried in the SN field of the RLC header;

[0025] Figure 15 and Figure 16 The illustration shows an example of a UMD PDU implemented according to some examples, where the DPID can be carried in the SN field of the RLC header;

[0026] Figure 17 The diagram illustrates the detection of (multiple) missing RLC PDUs along the data path, and the reporting of (multiple) missing RLC PDUs across the data path, based on some example implementations.

[0027] Figure 18 and Figure 19 This is a diagram illustrating the detection and reporting of (multiple) missing RLC PDUs across data paths, based on some examples.

[0028] Figure 20 The illustration shows an example of a status PDU that includes a status report for a corresponding data path, implemented according to some examples, which includes DPIDs for the corresponding data path(s).

[0029] Figure 21 The illustration shows an example of a status PDU that includes a status report for a single data path, implemented according to some examples, which includes the DPID of that single data path;

[0030] Figure 22 The illustration shows a more specific example of a status PDU that includes a status report for the corresponding data path, based on some examples, which includes the DPID for the corresponding data path;

[0031] Figure 23 This is a flowchart illustrating the steps in a method implemented based on various examples;

[0032] Figure 24A , Figure 24B , Figure 24C and Figure 24D This is a flowchart illustrating the steps in a method implemented based on various examples;

[0033] Figure 25It is a flowchart illustrating the steps in a method implemented based on various examples;

[0034] Figure 26A and Figure 26B It is a flowchart illustrating the steps in a method implemented according to various examples; and

[0035] Figure 27 The diagram illustrates a device implemented based on some examples. Detailed Implementation

[0036] Some implementations of this disclosure will be described more fully below with reference to the accompanying drawings, which illustrate, but are not exhaustive, implementations of this disclosure. In fact, various implementations of this disclosure may be embodied in many different forms and should not be construed as limited to the implementations set forth herein; rather, these example implementations are provided to make this disclosure exhaustive and to fully communicate the scope of this disclosure to those skilled in the art. The same reference numerals throughout refer to the same elements.

[0037] Unless otherwise stated or the context clearly indicates, references to first, second, etc., should not be construed as implying a particular order. A feature described as above another feature (unless otherwise stated or the context clearly indicates) may actually be below it, and vice versa; similarly, a feature described as to the left of another feature may actually be to its right, and vice versa. Furthermore, although this document may reference quantitative measurements, numerical values, geometric relationships, etc., any one or more (if not all) of these may be absolute or approximate values ​​to account for reasonable deviations that may occur, such as those caused by engineering tolerances, etc., unless otherwise stated.

[0038] As used herein, unless otherwise specified or the context clearly indicates otherwise, "OR" in the operand set is "inclusive OR," and therefore true if and only if one or more of the operands are true, not "exclusive OR," which is false if all operands are true. Thus, for example, "[A] OR [B]" is true if [A] is true, or if [B] is true, or if both [A] and [B] are true. Furthermore, unless otherwise specified or the context clearly indicates a singular form, the articles "a" and "an" mean "one or more." Additionally, it should be understood that, unless otherwise specified, the terms "data," "content," "digital content," "information," and similar terms are sometimes used interchangeably. The term "network" can refer to a group of interconnected computers, including clients and servers; and within a network, these computers can be interconnected directly or indirectly in various ways, including via one or more switches, routers, gateways, access points, etc.

[0039] This disclosure discusses telecommunications systems and mobile or cellular networks and their user equipment. While specific terms may be used, these terms are broadly applicable to a wide range of technologies. For example, while this disclosure may refer to radio access technologies such as 5G NR and Advanced 5G, it is equally relevant to next-generation radio access technologies such as 6G. The exemplary implementations of this disclosure described herein also refer to Public Land Mobile Networks (PLMNs) and Mobile Network Operators (MNOs), but the exemplary implementations are equally applicable to Standalone Non-Public Networks (SNPNs).

[0040] While some examples and figures focus on radio access networks (RANs), particularly those operating according to 3GPP standards for 5G NR (often referred to as 3GPP access or 3GPP access network), the example implementations are applicable to any type of access network. This includes not only 3GPP access networks but also non-3GPP access networks, such as wired access, untrusted non-3GPP access networks, and trusted non-3GPP access networks that connect to the core network of a mobile or cellular network (e.g., a 5G core network (5GC) or a 6G core network (6GC)) using radio access gateway functions (W-AGF), non-3GPP interoperability functions (N3IWF), or trusted non-3GPP gateway functions (TNGF).

[0041] Furthermore, as used in this application, the term "circuit system" may refer to one or more or all of the following: (a) a hardware circuit implementation (such as an implementation of an analog and / or digital circuit system only); (b) a combination of hardware circuitry and software, such as (if applicable): (i) a combination of (multiple) analog and / or digital hardware circuitry and software / firmware, and (ii) any portion of (multiple) hardware processors (including (multiple) digital signal processors), software, and (multiple) memories having software, which work together to enable a device (such as a mobile phone or a server) to perform various functions; or (c) (multiple) hardware circuitry and / or (multiple) processors, such as (multiple) microprocessors or portions thereof, which require software (e.g., firmware) to operate, but may be absent when the software is not required to operate.

[0042] The above definition of "circuit system" applies to all uses of the term in this application, including all uses in any claim. As a further example, as used herein, the term "circuit system" also covers implementations of hardware circuitry or processors (or processors) or portions thereof and their accompanying software and / or firmware. For example, and where applicable to specific claim elements, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0043] Figure 1 The illustration depicts a telecommunications system 100 implemented according to various examples of this disclosure. Examples of suitable telecommunications systems include UMTS, EPS, and 5GS, as well as future 6GS. A telecommunications system (also referred to as a system) typically includes one or more mobile or cellular networks, and these mobile or cellular networks can interoperate between different telecommunications systems. As shown, for example, the system includes one or more PLMNs 102 coupled to one or more other external data networks 104—particularly including wide area networks (WANs), such as the Internet. It should be understood that the PLMN can be a standalone PLMN including a 5GC, or a non-standalone PLMN including an evolved packet core (EPC) and a 5GC connected to a RAN.

[0044] Each PLMN 102 includes a core network (CN) 106, such as EPC, 5GC, or 6GC; and each CN is coupled to one or more RANs 108 implementing one or more Radio Access Technologies (RATs). Examples of these RANs include the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) for 4G LTE, the Next Generation Radio Access Network (NG-RAN) for 5G NR, and 6G RAN. As used herein, “network equipment” refers to any suitable equipment in the RAN or core network of a telecommunications system. Examples of suitable network equipment are described in more detail below.

[0045] Examples of RATs include 3GPP radio access technologies such as GSM, CDMA2000 1xEV-DO (HRPD), CDMA2000 1x (1xRTT), UTRA, E-UTRA, 5G NR, Advanced 5G, and 6G. Other examples of RATs include IEEE 802 technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.15 (including 802.15.1 (WPAN / Bluetooth), 802.15.4 (Zigbee), and 802.15.6 (WBAN)), Bluetooth, Bluetooth Low Energy (BLE), Ultra Wideband (UWB), and so on. Generally, RAT can refer to any 2G, 3G, 4G, 5G, 6G, or higher generation RAT and its different versions, as well as any other RAT that can be configured to interoperate with such RATs to provide access to CN 106 of the MNO.

[0046] Telecommunication system 100 also includes one or more communication devices, which may have different names, such as User Equipment (UE) 110, terminal device, terminal equipment, mobile station, etc. A UE typically refers to a device configured to communicate with network equipment in the telecommunications system (e.g., access nodes, such as RAN nodes in RAN 108) or other UEs. A UE can be a portable computer (e.g., laptop, notebook, tablet), a mobile phone (e.g., mobile phone, smartphone), a wearable computer (e.g., smartwatch), etc. In other examples, a UE can be an Internet of Things (IoT) device, an Industrial IoT (IIoT) device, a vehicle equipped with Vehicle-to-Everything (V2X) communication technology, etc. As cited by 3GPP, in some examples, a UE can be a Narrowband IoT (NB-IoT) device, an enhanced machine-type communication (eMTC) device, a RedCap device, an environmental IoT device, etc.

[0047] In operation, UE110 can connect to one or more RAN nodes of RAN 108 based on its specific RAT, thereby accessing a specific CN 106 of PLMN 102, or accessing one or more external data networks 104 (e.g., the Internet) or services provided by the PLMN. External data networks can provide Internet access or third-party services. For example, the International Telecommunication Union (ITU) classifies 5G mobile network services (e.g., services provided by 5G mobile networks) into three categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC) or massive Internet of Things (MIoT).

[0048] In various examples, RAN 108 can be configured to provide one or more macro cells, micro cells, pico cells, femto cells, etc. RAN typically includes one or more RAN nodes that interact with UE 110. In various examples, RAN nodes can be referred to as base stations (BS), access points (AP), or base transceiver stations (BTS). Examples of RAN nodes include NodeB (NB), evolved NB (eNB), macro BS, macro NB (MNB) or macro eNB (MeNB), home BS, home NB (HNB) or home eNB (HeNB), next-generation NB (gNB), enhanced gNB (en-gNB), next-generation eNB (ng-eNB), 6G NB (6gNB), etc. The term "gNB" in 5G NR can correspond to eNB in ​​4G LTE. In addition, NG-RAN nodes can refer to gNB or ng-eNB. Unless otherwise specified, gNB in ​​5G NR or 6gNB in ​​6G can sometimes be commonly referred to as (6)gNB or simply gNB.

[0049] RAN 108 may include some type of network control / management entity responsible for controlling RAN nodes. The network control / management entity and RAN nodes may be separate or integrated into a single device. The network control / management entity may include a processing circuitry system configured to perform various management functions, etc., for controlling the RAN nodes. The processing circuitry system may be associated with a memory, computer-readable storage medium, or a data storage device, including a database, for maintaining the information required for the various management functions.

[0050] Figure 2 The illustration shows an example of a PLMN 102 communicating with a UE 110 of a telecommunications system 100 and an external data network 104, such as a 4G LTE, 5G NR, or 6G PLMN. As shown, a RAN 108 (e.g., E-UTRAN, NG-RAN, 6G RAN) includes one or more RAN nodes 202 configured to connect one or more UEs to the RAN, thereby accessing CN 106 (e.g., EPC, 5GC, 6GC). In 4G LTE, the UE, E-UTRAN, and EPC constitute the EPS. Similarly, in 5G NR, the UE, NG-RAN, and 5GC constitute the 5GS. And in 6G, the UE, 6G RAN, and 6GC constitute the 6GS.

[0051] In various scenarios, a single UE 110 (dual-mode or multi-mode UE) can support carrier aggregation (CA), dual connectivity (DC), or multiple connectivity (MC). In this regard, CA allows the UE to connect to cells on multiple carriers simultaneously, enabling the UE to achieve higher throughput and fast time-scale load balancing across multiple carriers. As described herein, the term "carrier aggregation" (or "CA") broadly encompasses carrier aggregation, dual connectivity, and multiple connectivity, and can be used individually or in combination.

[0052] UE 110 typically has a primary cell, referred to as PCell, which is usually the cell through which the UE initially connects to RAN 108. The RAN (usually via PCell) can provide the UE with additional configuration information to enable it to simultaneously connect to cells on other carriers besides PCell; these cells are referred to as the UE's secondary cells or SCells. PCell RAN node 202 can be referred to as the primary node, and SCell RAN node can be referred to as the secondary node. Relatedly, the primary cell group (MCG) refers to the serving cell group associated with the primary node, and the MCG includes PCell. The secondary cell group (SCG) refers to the serving cell group associated with the secondary node, and the SCG includes the primary cell referred to as the primary-secondary cell (PSCell). A special cell (SpCell) refers to a PCell in the MCG or a PSCell in the SCG.

[0053] In some implementations, the operation of the gNB or other RAN node 202 can be distributed or functionally broken down into multiple components, including one or more Remote Radio Heads (RRHs) or Radio Units (RUs) and Baseband Units (BBUs); and in some implementations, the BBU can be broken down into Central Units (CUs) (central nodes) and Distributed Units (DUs) (distributed nodes). For example, a CU can be a server, host, or node. In some implementations, the RRH / RU and DU can co-located at the same network device. Furthermore, the operation of the gNB or RAN node can also be distributed across multiple servers, hosts, or nodes.

[0054] It should also be understood that the distribution of work between core network operations and RAN node operations may vary depending on the implementation. For example, 5G or 6G network architectures may be based on so-called CU-DU splitting. One gNB-CU (CU) can control one or more gNB-DUs (DUs). A gNB-CU can control multiple spatially separated gNB-DUs that at least act as transmit / receive (Tx / Rx) nodes. However, in some example implementations, a gNB-DU may include, for example, the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and the Physical (PHY) layer, while the gNB-CU may include layers above the RLC layer, such as the Packet Data Convergence Protocol (PDCP) layer, the Radio Resource Control (RRC) layer, and the Internet Protocol (IP) layer. Other functional splitting is also possible. Those skilled in the art are considered familiar with the Open Systems Interconnection (OSI) model and the functionality within each layer.

[0055] In some example implementations, the server or CU can generate a virtual network through which the server communicates with the radio nodes. Generally, a virtual network may involve the process of combining hardware and software network resources and network functionality into a single software-based management entity (i.e., the virtual network). Such a virtual network can provide flexible distribution of operations between the server and the radio head end / node. In practice, any digital signal processing task can be performed in the CU or DU, and the boundaries of responsibility transfer between the CU and DU can be chosen depending on the implementation.

[0056] Figure 3 The diagram illustrates a portion of the radio protocol stack 300 architecture between UE 110 and RAN node 202, implemented according to some examples. As shown, the radio protocol stack has two distinct stacks depending on the data types it handles. User data is transmitted via the User Plane (UP) stack 302, and signaling messages are transmitted via the Control Plane (CP) stack 304. Both the UP and CP stacks consist of the same structure, including Layer 1 (L1) with a PHY layer 306 and Layer 2 (L2) with sublayers including a MAC layer 308, an RLC layer 310, and a PDCP layer 312. Layer 3 (L3) sits above the PHY / MAC / RLC / PDCP layers and includes distinct sublayers between the CP and UP. In the UP, L3 includes a sublayer called the Serving Data Adaptation Protocol (SDAP) 314, which can connect to the User Plane Function (UPF) or other suitable Network Functions (NF) in CN106. In CP, L3 includes two sublayers, referred to as RRC 316 and Non-Access Layer (NAS) 318, and the NAS layer connects to the Access and Mobility Function (AMF) or other suitable NF in CN.

[0057] The data flow between the source and destination (such as UE 110 and RAN node 202) is top-down across communication lines in the source and bottom-up in the destination. Each time user data is passed down from one layer to the next in the source, more processing information is added. When this information is removed and processed by the peer layer in the destination, various tasks (error correction, flow control, etc.) are triggered.

[0058] Typically, each layer of the radio protocol stack 300 performs a specific data communication task, providing services to the layers preceding it. The process of each layer performing this task can be likened to placing a letter into a series of envelopes before it is mailed through a postal system. Each subsequent envelope adds a layer of processing or overhead information necessary for the transaction. All envelopes work together to ensure the letter reaches the correct address and that the received message is exactly the same as the sent message. Once the entire package reaches its destination, the envelopes are opened one by one until the letter itself is exactly as written.

[0059] For example, in the radio protocol stack 300, the PDCP layer 312 can perform header compression and / or decompression, reordering, transmission of user data, encryption and / or decryption, and time-based Service Data Unit (SDU) discarding. In examples involving carrier aggregation, PDCP can also perform: routing PDCP Protocol Data Units (PDUs) to associated links. At least some of the above functions of PDCP rely on the PDCP Sequence Number (SN) located in the PDCP header of the PDCP PDU.

[0060] Below PDCP layer 312 is RLC layer 310, which helps facilitate the transmission of higher-layer PDUs and performs error correction through Automatic Repeat Request (ARQ) for RLC Acknowledged Mode (AM) data transmissions. The RLC layer can also perform segmentation and resegmentation for RLC Unacknowledged Mode (UM) and RLC AM data transmissions, reassembly of RLC SDUs, duplicate detection for RLC UM and RLC AM data transmissions, and / or protocol error detection for RLC AM data transmissions. In some examples, these functions performed by the RLC layer may rely on or be based on the RLC SN derived from the RLC header of the RLC PDU.

[0061] Below PDCP layer 312 and RLC layer 310 is MAC layer 308. The MAC sublayer includes the mapping between logical channels and transport channels, as well as the multiplexing / demultiplexing of MAC SDUs belonging to one or more different logical channels that are delivered to / from the physical layer on the transport channel. The MAC layer can also assist in scheduling information reporting, error correction via hybrid ARQ, priority handling between logical channels of a user equipment, priority handling between user equipments by means of dynamic scheduling, transmission format selection, and / or padding.

[0062] According to existing regulations, RLC PDUs can be constructed in RLC layer 310 using RLC SN spaces (RLC SN space and RLC SN are sometimes simply referred to as "SN space" and "SN"). In the case of CA, only a single SN space is used even across multiple cells because adding a second SN space requires approval of the configuration of additional RLC instances and additional overhead. More specifically, regarding CA, it has been observed that UE 110 cannot efficiently handle data processing, and in the case of data splitting across active CA cells, these UEs cannot enable distributed computing if each cell does not use consecutive RLC SNs. Sending consecutive RLC SNs from each cell would cause inefficient data splitting at the transmitter of RAN node 202, as this could immediately create RLC SN gaps at the receiving entity, leading to the invocation of the RLC reassembly process.

[0063] In the case of RLC AM, one drawback lies in the reassembly handling at UE 110. Data splitting and different data rates on each cell in the CA can lead to high RLC retransmission rates. While this high RLC retransmission rate can be avoided by configuring a longer reassembly timer value, this defeats the purpose of the reassembly function, which is to address HARQ retransmission issues and appropriately trigger RLC retransmissions in the event of HARQ failure.

[0064] The aforementioned problems can be mitigated to some extent by configuring multiple RLC instances for a single radio bearer. However, configuring multiple RLC instances is inefficient because RLC instances cannot be dynamically enabled / disabled; instead, they must be enabled during CA configuration, regardless of whether the Scell ​​is active. Furthermore, as indicated, configuring multiple RLC instances is not optimal in terms of performance due to overhead in RLC status reporting signaling and air interface resource consumption. Given the static nature of RLC instances' association with lower layers, this configuration is inflexible and has limited applicability. In the case of RLC UM, the protocol is difficult to extend to a distributed architecture for CA implementation. One key reason is the segmentation of RLC SDUs. In RLC UM, the RLC SN is only associated with segmented RLC SDUs, and this requires coordination across all CA tributaries because segmentation is only known during UE scheduling and MAC transport block (TB) preparation.

[0065] In light of the foregoing, the example implementations of this disclosure provide solutions that enable distributed processing of RLC AM and RLC UM operations by introducing data paths to distribute RLC PDUs for RLC SDUs and by introducing associations between the corresponding SN space and data paths. RLC PDUs for RLC SDUs can be distributed in several different ways. In various examples, data paths can correspond to cells of RAN 108 (e.g., for CA), bandwidth portions (BWP) of the RAN, Quality of Service (QoS) flows, etc. For example, in CA, each cell can be mapped to a different data path for a single radio bearer, and each data path can carry RLC SDUs for a given radio bearer in parallel.

[0066] As will be explained in more detail below, the corresponding SN spaces associated with the data path can be independent of each other and do not interfere with each other, and are used to derive the SN for RLC PDUs in RLC AM, or to derive the SN for RLC PDUs including SDU fragments in RLC UM. In some examples, ARQs in RLC AM can operate in parallel across the data path and are not constrained by RLC status report processing, and can trigger RLC retransmissions (multiple) from the transmitting entity as needed.

[0067] Several example implementations of solutions may provide a process for RLC reassembly that is not constrained by parallel transmissions and different data rates, resulting in RLC PDUs being received at the receiving entity from each data path. In some of these solutions, the intended function of RLC reassembly to overcome latency caused by HARQ retransmissions may be preserved. Additionally or alternatively, several example implementations of solutions may provide a structure and process for RLC status reporting, which may enable parallel processing of status reports for each data path at the transmitting entity via distributed computing, wherein multiple RLC retransmissions may be triggered efficiently along the data path.

[0068] Figure 4 The diagram illustrates a model of RLC layer 310 implemented according to several examples, including a transmit RLC entity 310A located at RAN node 202 and a receive RLC entity 310B located at UE 110. In some examples, the transmit RLC entity is an AMRLC entity, and the receive RLC entity is an AM RLC entity. In other examples, the transmit RLC entity is a transmit UM RLC entity, and the receive RLC entity is a receive UM RLC entity. In this model, the transmit RLC entity can distribute RLC PDUs for RLC SDUs to data paths associated with the corresponding SN space, which enables parallel and synchronous transmission of RLC SDUs. As indicated above, the data path can correspond to a cell in RAN 108 (e.g., for CA), the cell's BWP, QoS flow, etc. The distribution of RLC SDUs across data paths can help avoid invoking the RLC reassembly function at the receive RLC entity due to data rate imbalances from each data path.

[0069] As shown in the figure, the transmitting RLC entity 310A can receive RLC SDUs from a higher layer (PDCP layer 312A) of the radio protocol stack 300 at RAN node 202. The transmitting RLC entity can distribute RLC PDUs for the RLC SDUs to data paths associated with the corresponding SN spaces, and associate each RLC SDU with a Data Path Identifier (DPID), which identifies a data path in a data path associated with a corresponding SN space within the corresponding SN space. For example, in the case of CA, RLC SDUs can be distributed across active cells, and each active cell can be associated with a corresponding SN space within the corresponding SN space and identified by a DPID. The transmitting RLC entity can construct one or more RLC PDUs for each RLC SDU, where each RLC PDU includes the RLC SDU or a fragment of an RLC SDU, the DPID associated with the RLC SDU, and the SN from a corresponding SN space within the corresponding SN space. The transmitting RLC entity can also submit the RLC PDUs on the data paths to a lower layer (MAC layer 308A) of the radio protocol stack.

[0070] Each RLC PDU can be constructed in several different ways to accommodate the DPID of a data path within a data path. In some examples, each RLC PDU may include data fields carrying an RLC SDU or a segment of an RLC SDU, as well as an RLC header (sometimes simply called the "header") with separate fields carrying the DPID and SN. By adding additional bits to the RLC header to carry the DPID according to the data path, each data path can be allocated the full SN space range based on the length of the SN used for a given radio bearer.

[0071] Figure 5 , Figure 6 , Figure 7 and Figure 8 The illustration shows an example of an AM Data (AMD) PDU, where the DPID and SN can be carried in separate fields within the RLC header. In these examples, the DPID is a 4-bit DPID, which can be used to address up to 16 data paths with a full range of SNs (depending on the configured SN length). Figure 5 and Figure 6 The diagram illustrates the no-fragment offset (SO) ( Figure 5 ) and SO ( Figure 6 AMD PDU with a 12-bit SN. Figure 7 and Figure 8 The diagram illustrates the absence of SO ( Figure 7 ) and SO ( Figure 8This refers to an AMD PDU with an 18-bit serial number (SN). It's worth noting that the same format can be extended to any of several different SN lengths.

[0072] Figure 9 and Figure 10 The illustration shows an example of a UM Data (UMD) PDU, where the DPID and SN can be carried in different fields of the RLC header. As before, in these examples, the DPID is a 4-bit DPID, which can be used to address up to 16 data paths with a full range of SNs (depending on the configured SN length). Figure 9 and Figure 10 A more detailed illustration shows the absence of SO ( Figure 9 ) and SO ( Figure 10 The AMD PDU has a 12-bit serial number. Similarly, the same format can be extended to any of several different serial number lengths.

[0073] In some other examples, each RLC PDU may include a data field carrying an RLC SDU or a fragment of an RLC SDU, and an RLC header with an SN field carrying both the DPID and the SN. In these examples, multiple bits from the SN field may be used for the DPID, which could shorten the SN space. Therefore, for a given radio bearer, each data path can be allocated a series of SNs based on the remaining SN length (after removing the bits allocated to the DPID). However, since RLC SDUs are distributed across multiple data paths with their respective SN spaces, a shorter SN bit length may not be considered a constraint on the available data rate.

[0074] Figure 11 , Figure 12 , Figure 13 and Figure 14 The illustration shows an example of an AMD PDU where the DPID can be carried in the SN field of the RLC header. In these examples, the DPID is a 4-bit DPID, which can be used to address up to 16 data paths with a remaining 8-bit SN range. Figure 11 and Figure 12 The diagram illustrates the absence of SO ( Figure 11 ) and SO ( Figure 12 ) , an AMD PDU with a 12-bit SN. Figure 13 and Figure 14 The diagram illustrates the absence of SO ( Figure 13 ) and SO ( Figure 14 This refers to an AMD PDU with an 18-bit serial number (SN). It's worth noting that the same format can be extended to any of several different SN lengths.

[0075] Figure 15 and Figure 16 The illustration shows an example of a UMD PDU where the DPID can be carried in the SN field of the RLC header. As before, in these examples, the DPID is a 4-bit DPID, which can be used to address up to 16 data paths with a remaining 8-bit SN range. Figure 15 and Figure 16 A more detailed illustration shows the absence of SO ( Figure 15 ) and SO ( Figure 16 This is an AMD PDU with a 12-bit SN. Similarly, this format can be extended to any of several different SN lengths.

[0076] Back Figure 4 In RLC AM, the receiving RLC entity 310B (AM RLC entity) can, in some examples, receive RLC PDUs from a lower layer (MAC layer 308B) of the radio protocol stack 300 at UE110. RLC PDUs can be received on data paths associated with the corresponding SN space. An RLC PDU received on each data path may include a DPID identifying the data path, and an SN from the corresponding SN space associated with the data path. The receiving RLC entity can detect (multiple) any missing RLC PDUs per data path based on the DPID identifying the data path and the SN from the SN space associated with the data path. The receiving RLC entity can report (multiple) missing RLC PDUs, such as through an RLC status report. Furthermore, the receiving RLC entity can reassemble RLC SDUs from the RLC PDUs and submit the RLC SDUs to a higher layer of the radio protocol stack (PDCP layer 312B).

[0077] The receiving RLC entity 310B can implement a reassembly timer (also known as a "t-reassembly timer"), a status disable timer, and a status reporting procedure when detecting and reporting (multiple) missing RLC PDUs along the data path. In this regard, the receiving RLC entity can implement this procedure to manage the reassembly of RLC SDUs, adjust the frequency of status PDUs, and use the transmission of status PDUs to report successful reception (ACK) and unsuccessful reception or missing RLC PDUs (NACK). As explained in more detail below, in various examples, (multiple) missing RLC PDUs can be detected and reported along the data path, detected along the data path and reported across data paths, or detected and reported across data paths.

[0078] In some examples, missing RLC PDUs are detected and reported along the data path, and the t-reassembly, state disabling, and state reporting processes can be applied along the data path (i.e., along the SN space). In these examples, the current RLC reassembly functionality and state report can be applied separately to each data path. For each data path, the receiving RLC entity 310B can detect missing SNs from the SN space associated with that data path based on the SNs in the RLC PDUs received on that data path. When a missing SN is detected, the receiving RLC entity can start a t-reassembly timer associated with that data path, and when the t-reassembly timer expires, detect any missing RLC PDUs. When the t-reassembly timer expires (or upon receiving a polling request), and when enabled based on the state disabling functionality, the receiving RLC entity can construct a state PDU that includes the state report of the RLC PDUs received on the data path. And, as described in more detail below, this state report can be enhanced to include the DPID of the data path.

[0079] In some other examples, missing RLC PDUs can be detected along the data path and reported across the data path. In some of these examples, missing RLC PDUs can be detected along the data path in a similar manner to those described above, where a t-reassembly timer associated with the data path can be started when a missing SN from the SN space associated with that data path is detected. However, instead of reporting the missing RLC PDUs when the t-reassembly timer expires, another timer can be started and run, and any status reports are delayed for the duration of the timer to avoid excessive / overly frequent status reports for the receiving RLC entity. In some examples, the duration of the timer can be flexibly configured according to the QoS requirements of the service mapped to the radio bearer.

[0080] A timer called an offset timer (e.g., status_offset) ensures that the first t-reorganization timer will not generate a status report if the status disable timer is not running. Even when the status disable timer is not running, the offset timer allows the receiving RLC entity 310B to bind status reports by waiting for the duration of the offset timer. Without the offset timer, the receiving RLC entity can generate status PDUs from one data path and is prohibited from generating another status PDU from any other data path until the status disable timer expires.

[0081] The receiving RLC entity 310B may start an offset timer when the t-reassembly timer associated with the data path expires. The receiving RLC entity may detect any missing RLC PDUs for at least one of the missing other data paths when the offset timer expires. In some examples, if the receiving RLC entity 310B receives a polling request for a status report while the offset timer is running, the receiving RLC entity may defer the status report until the offset timer expires. Then, when the offset timer expires, the receiving RLC entity may report any missing RLC PDUs for the data path(s), and any missing RLC PDUs for the other data paths(s), such as via a common status PDU.

[0082] Figure 17 This diagram illustrates the detection of (multiple) missing RLC PDUs along a data path and the reporting of (multiple) missing RLC PDUs across data paths, based on some example implementations. As shown, a first data path (DPID=1) can be associated with a first SN space (SN space 1), and a second data path (DPID=2) can be associated with a second SN space (SN space 2). Also as shown, for example, when a missing SN 2 from SN space 2 is detected, a t-recombination timer associated with the second data path can be started. Similarly, when a missing SN 3 from SN space 1 is detected, a t-recombination timer associated with the first data path can be started.

[0083] When the t-recombination timer associated with the second data path expires, instead of reporting the missing RLCPDU(s), missing SN2 and SN5 from SN space 2 can be recorded, and an offset timer can be started. While the offset timer is running, the t-recombination timer associated with the first data path expires, and missing SN3 from SN space 1 can also be recorded. Then, when the offset timer expires, missing SN3 from SN space 1 and missing SN2 and SN5 from SN space 2 can be reported. As also shown, this process can continue for other missing SNs from SN space 1 and SN space 2.

[0084] In some other examples, (multiple) missing RLC PDUs can be detected and reported across data paths. In some of these examples, t-reassembly, state disabling, and state reporting procedures can be applied across data paths (i.e., across SN spaces). A t-reassembly timer can be applied such that it is started for any missing SN from any SN space. The t-reassembly timer can run while the receiving RLC entity 310B is waiting for (multiple) missing RLC PDUs across data paths (i.e., across SN spaces). And when the t-reassembly timer expires, the receiving RLC entity can report (multiple) any missing RLC PDUs across data paths.

[0085] In some of these examples, where any missing RLC PDU(s) can be detected and reported across the data path, instead of starting a t-reassembly timer when a missing SN from any SN space is detected, another timer can be started and run, and the t-reassembly timer can be delayed for its duration. This timer can also be referred to as an offset timer (e.g., a t-reassembly offset timer). While the offset timer is running, any missing SN(s) in the corresponding SN space associated with the data path can be logged, allowing the timer to act as a collection timer for all missing RLC PDUs across the corresponding SN space. This offset timer can help monitor for missing SNs across the corresponding SN space for its duration before starting a t-reassembly timer for missing RLC PDUs across the corresponding SN space. And if there are missing RLC SN(s) that are missing when the offset timer expires, the t-reassembly timer can be started for the missing RLC SN(s) across the corresponding SN space. If there are no missing RLC SNs when the offset timer expires, no further action is invoked.

[0086] More specifically, for example, the receiving RLC entity 310B can detect missing SNs from the SN space associated with any data path, based on the SNs in the RLC PDUs received on any data path in the data path. When a missing SN is detected, the receiving RLC entity can start an offset timer; and when a missing SN or any other missing SN across the corresponding SN space is detected when the offset timer expires, the receiving RLC entity can start a reassembly timer. When the reassembly timer expires, the receiving RLC entity can detect any missing SN across the corresponding SN space for the missing RLC PDU(s) across the data path(s). Furthermore, the receiving RLC entity can also report the missing RLC PDU(s) for any one or more missing data paths in the missing data path when the reassembly timer expires.

[0087] Figure 18 and Figure 19 This diagram illustrates the detection and reporting of (multiple) missing RLC PDUs across data paths, based on several example implementations. As shown, the four data paths can be associated with SN space 1, SN space 2, SN space 3, and SN space 4, respectively. For example, ... Figure 18 As shown, a missing SN3 for SN space 1 is detected. However, instead of starting the t-recombination timer upon detecting the missing SN3, an offset timer (t-recombination offset timer) can be started. When the offset timer expires, multiple missing SNs across SN spaces are detected, including SN3 and SN9 from SN space 1, SN7 from SN space 2, and SN5 from SN space 3. At this point, the t-recombination timer can be started. Then, when the t-recombination timer expires, the missing SNs across SN spaces can be reported. Figure 18 and Figure 19 As shown, this process can be continued for other missing SNs.

[0088] In various examples, the offset timer and the t-recombination timer can be configured independently. If the t-recombination timer is configured to be much longer than the offset timer, it may result in multiple t-recombination timers running in parallel for different sets of SNs across the corresponding SN spaces. However, since these timers are spaced based on the expiration times of consecutive offset timers, status reports triggered based on the expiration of the t-recombination timer can also be spaced out for at least the duration of the offset timer. This also... Figure 18 and Figure 19 It is shown in the middle.

[0089] As explained above, in some examples, the receiving RLC entity 310B can construct a status PDU that includes status reports of RLC PDUs received on a data path, and this status report can be enhanced to include the DPID of the data path. In some examples, the status PDU can include status reports per data path for one or more data paths identified by the data path identifier in the status PDU, which the receiving RLC entity can then send to a peer RLC entity from which the RLC PDUs originate. As shown, each status report for a data path includes: a DPID identifying the data path, and an offset pointing to any next status report for another data path(s). In some examples, the offset can be set to the first octet pointing to the beginning of any next status report. To count the number of octets occupied by the Nth report, the count can begin from the octet following the offset field.

[0090] Figure 20 The illustration shows an example of a status PDU including status reports for a given data path, implemented according to some examples. This includes the DPID for each data path(s). As shown, each status report for a data path includes: the DPID identifying the data path, and an offset pointing to any next data path status report for another data path(s). In the example, a 12-bit SN is assumed, but the same format can be extended to any of several different SN lengths. As shown, each status report for a data path includes an acknowledgment SN (ACK_SN) field, which, in an RLC PDU successfully received from the data path, indicates the highest SN from the corresponding SN space associated with that data path. The status report also includes zero or more negative acknowledgment SN (NACK_SN) fields, which indicate zero or more missing RLCPDUs by the SN from the SN space associated with that data path.

[0091] The format of status PDUs can be flexible so that (multiple) status reports can be sent simultaneously from a single data path or multiple data paths. Figure 21 The illustration shows an example of a status PDU that includes a status report for a single data path, implemented according to some examples, and includes the DPID for that single data path. As shown, when the status PDU includes only one status report for a single data path, the offset can be set to a value (e.g., offset = 0) that indicates that the status PDU does not include the next status report following that one status report. Figure 22 The illustration shows a more specific example of a status PDU that includes a status report for a corresponding data path, implemented according to some examples, and includes the DPID for that data path. In this more specific example, the offset for each of the multiple status reports (excluding the last one among multiple status reports) is set to a value that points to the next status report for another data path. The offset for the last status report among the multiple status reports can be set to a value (e.g., offset = 0) that indicates the status PDU does not include the next status report after the last status report among the multiple status reports.

[0092] The format of the status PDU can be easily parsed to retrieve each status report via DPID and offset. Status PDUs also enable efficient processing of (multiple) status reports at peer RLC entities (such as at the transmitter in a distributed architecture), from which the RLC PDU originates. Status reports for each data path can be processed independently of each other without depending on other data paths. Status reports also enable more efficient retransmission from each data path in the event that (multiple) negative acknowledgments are reported for (multiple) missing RLC PDU reports.

[0093] The above example implementations primarily focus on RLC AM, where missing RLC PDUs (multiple) can be detected and reported. Some example implementations are also applicable to RLC UM. Returning to... Figure 4 In the RLC UM, the receiving RLC entity 310B (receiving UM RLC entity) can, in some examples, receive RLC PDUs from a lower layer (MAC layer 308B) of the radio protocol stack 300 at UE 110. As before, RLC PDUs can be received on the data path associated with the corresponding SN space. In the RLC UM, at least some of the RLC PDUs received on each of at least one data path in the data path may include RLC SDU fragments, a DPID identifying the data path, and an SN from the corresponding SN space associated with the data path.

[0094] The receiving RLC entity 310B can, based on the DPID identifying the data path and the SN from the SN space associated with the data path, detect for at least one RLC SDU segment of each of the multiple data paths, such as in a manner similar to the detection of missing RLC PDUs of the multiple data paths described above. The receiving RLC entity can, based on the DPID identifying the data path, reassemble RLC SDU segments from the RLC PDUs into an RLC SDU according to the data path and submit the RLC SDU to a higher layer of the radio protocol stack (PDCP layer 312B).

[0095] Figure 23This is a flowchart illustrating the various steps of method 2300 implemented according to various examples. The method includes: receiving Radio Link Control (RLC) Service Data Units (SDUs) from a higher layer of the radio protocol stack, as shown in box 2302. The method includes: distributing RLC Protocol Data Units (PDUs) for RLC SDUs to data paths associated with corresponding sequence number (SN) spaces, as shown in box 2304. The method includes: associating each RLC SDU with a data path identifier that identifies a data path in a data path associated with a corresponding SN space in the corresponding SN space, as shown in box 2306. The method includes: constructing one or more RLC PDUs for each RLC SDU, each RLC PDU including an RLC SDU or a fragment of an RLC SDU, a data path identifier associated with that RLC SDU, and an SN from a corresponding SN space in the corresponding SN space, as shown in box 2308. The method includes submitting RLC PDUs on the data path toward a lower layer of the radio protocol stack, as shown in box 2310.

[0096] In some examples, the data path corresponds to a cell of the radio access network, or a portion of the bandwidth of the cell of the radio access network.

[0097] In some examples, the data path corresponds to the quality of service flow.

[0098] In some examples, each RLC PDU includes: a data field carrying an RLC SDU or a fragment of an RLC SDU, and a header with separate fields carrying a data path identifier and a SN.

[0099] In some examples, each RLC PDU includes: a data field carrying an RLC SDU or a fragment of an RLC SDU, and a header having an SN field carrying both a data path identifier and a serial number (SN).

[0100] Figures 24A-24D This is a flowchart illustrating the various steps of method 2400 implemented according to various examples. The method includes: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of the radio protocol stack, the RLC PDU being received on a data path associated with a corresponding Sequence Number (SN) space. Each RLC PDU received on a data path includes a data path identifier for identifying that data path, and an SN from the corresponding SN space associated with the data path, such as in... Figure 24AAs shown in box 2402. The method includes: detecting at least one missing RLC PDU according to the data path based on a data path identifier that identifies the data path and an SN in the SN space associated with the data path, as shown in box 2404. The method includes: reporting the at least one missing RLCPDU, as shown in box 2406. The method includes: reconstructing an RLC Service Data Unit (SDU) from the RLC PDU, as shown in box 2408. And the method includes: submitting the RLC SDU to a higher layer of the radio protocol stack, as shown in box 2410.

[0101] In some examples, the data path corresponds to a cell of the radio access network or a portion of the bandwidth of the cell of the radio access network.

[0102] In some examples, the data path corresponds to the quality of service flow.

[0103] In some examples, each RLC PDU includes a data field carrying an RLC SDU or a fragment of an RLC SDU, as well as a header with separate fields carrying a data path identifier and a SN.

[0104] In some examples, each RLC PDU includes a data field carrying an RLC SDU or a fragment of an RLC SDU, and a header with an SN field carrying both a data path identifier and a serial number (SN).

[0105] In some examples, at least one missing RLC PDU is detected at box 2404 and reported at block 2406 along the data path.

[0106] In some examples, at least one missing RLC PDU is detected along the data path at box 2404 and reported across the data path at box 2406.

[0107] In some examples, at least one missing RLC PDU across the data path is detected at box 2404 and reported at box 2406.

[0108] In some examples, at least one missing RLC PDU is detected at box 2404 along the data path. In some instances of these examples, detecting at least one missing RLC PDU along the data path includes: for a data path within the data path, detecting a missing SN from the SN space associated with that data path, based on the SN in the RLC PDU received on that data path, such as... Figure 24BAs shown in box 2412. Detecting at least one missing RLC PDU includes: when a missing SN is detected, starting a reassembly timer associated with the data path, as shown in box 2414. And detecting at least one missing RLC PDU includes: when the reassembly timer expires, for the at least one missing RLC PDU, detecting at least one missing SN from the SN space, as shown in box 2416.

[0109] In some examples, at least one missing RLC PDU is reported across the data path at box 2406. In some of these examples, method 2400 also includes: starting an offset timer when the reassembly timer associated with the data path expires, as in Figure 24C As shown in box 2418. The method includes: detecting at least one missing RLC PDU when an offset timer expires for at least one other data path in the data path, as shown in box 2420. And reporting at least one missing RLC PDU across data paths at box 2406 includes: reporting at least one missing RLC PDU for that data path and at least one missing RLC PDU for at least one other data path when the offset timer expires, as shown in box 2422.

[0110] In some examples, at least one missing RLC PDU is detected across the data path at box 2404. In some of these examples, detecting at least one missing RLC PDU across the data path includes: detecting the missing SN from the SN space associated with any data path, based on the SN in the RLC PDU received on any data path within the data path, such as in... Figure 24D As shown in box 2424. Detecting at least one missing RLC PDU includes: starting an offset timer when a missing SN is detected, as shown in box 2426. Detecting at least one missing RLC PDU includes: starting a reassembly timer when the missing SN or any other missing SN in the corresponding SN space is detected when the offset timer expires, as shown in box 2428. And detecting at least one missing RLC PDU includes: when the reassembly timer expires, detecting at least one missing SN across the corresponding SN space for at least one missing RLC PDU across the data path, as shown in box 2430.

[0111] In some examples, at least one missing RLC PDU is reported across the data path at box 2406, and includes: reporting at least one missing RLC PDU for a data path in the data path and at least one missing RLC PDU for at least one other data path in the data path when the reassembly timer expires.

[0112] Figure 25 This is a flowchart illustrating the various steps of method 2500 implemented according to various examples. The method includes: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of the radio protocol stack, the RLC PDUs being received on data paths associated with corresponding sequence number (SN) spaces, each RLC PDU received on a data path including a data path identifier identifying that data path, as shown in box 2502. The method includes: constructing a state PDU, the state PDU including a status report for one or more data paths identified by the data path identifier in the state PDU, according to the RLC PDUs of the data paths, as shown in box 2504. And the method includes: sending the state PDU, the RLC PDU originating from the peer RLC entity, to a peer RLC entity, as shown in box 2506.

[0113] In some examples, each status report for a data path in one or more data paths includes: a data path identifier that identifies the data path, and an offset that points to any next status report for another data path in one or more data paths.

[0114] In some examples, the status PDU includes a status report for one data path in the data path, and the offset is set to a value that indicates that the status PDU does not include the next status report following that status report.

[0115] In some examples, the status PDU includes multiple status reports for multiple data paths in the data path, and the offset for each of the multiple status reports, except for the last one, is set to a value that points to the next status report for another data path.

[0116] In some examples, the offset for the last state report among multiple state reports is set to a value that indicates that the state PDU is not included in the next state report after the last state report among multiple state reports.

[0117] In some examples, method 2500 further includes: detecting at least one missing RLC PDU for at least one of one or more data paths, the status PDU being constructed for the one or more data paths, and a status report for each of the at least one data path in the one or more data paths, the at least one missing RLC PDU being indicated by an SN from the SN space associated with the data path from the corresponding SN space.

[0118] Figure 26A and Figure 26B This is a flowchart illustrating the various steps of method 2600 implemented according to various examples. The method includes: receiving Radio Link Control (RLC) Protocol Data Units (PDUs) from a lower layer of the radio protocol stack, the RLC PDUs being received on a data path associated with a corresponding SN space; at least some of the RLC PDUs received on at least one of the data paths in the data path include: RLC Service Data Unit (SDU) fragments, a data path identifier identifying the data path, and an SN from the corresponding SN space associated with the data path, such as in... Figure 26A As shown in box 2602, the method includes: detecting at least one missing RLC PDU for at least one RLC SDU segment, according to each data path in at least one data path, based on a data path identifier that identifies the data path and an SN from the SN space associated with the data path, as shown in box 2604. The method also includes: reassembling RLC SDU segments from RLCPDUs into RLC SDUs according to the data path, based on the data path identifier that identifies the data path, as shown in box 2606. Furthermore, the method includes: submitting the RLC SDU to a higher layer of the radio protocol stack, as shown in box 2608.

[0119] In some examples, the data path corresponds to a cell of the radio access network or a portion of the bandwidth of the cell of the radio access network.

[0120] In some examples, the data path corresponds to the quality of service flow.

[0121] In some examples, each RLC PDU in at least some RLC PDUs includes a data field carrying an RLC SDU fragment, as well as a header with separate fields carrying a data path identifier and a SN.

[0122] In some examples, each RLC PDU in at least some RLC PDUs includes a data field carrying an RLC SDU fragment, and a header having an SN field carrying both a data path identifier and an SN.

[0123] In some examples, detecting at least one missing RLC PDU along a data path at box 2604 includes: for at least one data path in the data path, detecting a missing SN from the SN space associated with the data path, based on the SN in the RLCPDU received on that data path, such as... Figure 26B As shown in box 2610. Detecting at least one missing RLC PDU includes: when a missing SN is detected, starting a reassembly timer associated with the data path, as shown in box 2612. And detecting at least one missing RLC PDU includes: when the reassembly timer expires, for the at least one missing RLC PDU, detecting at least one missing SN from the SN space, as shown in box 2614.

[0124] According to the example implementations of this disclosure, the telecommunications system 100 or PLMN 102 and its components (such as UE 110, CN 106, RAN 108 and / or RAN node 202) can be implemented in a variety of ways. Components used to implement the system and its components may include hardware, firmware, software, or a combination thereof. In some examples, one or more devices may be configured to implement, or otherwise implement, the system and its components shown and described herein. In examples involving more than one device, the respective devices may be interconnected or communicate with each other in a variety of different ways, such as directly or indirectly via wired or wireless networks.

[0125] Based on some example implementations, see references. Figure 23 At least some steps in the described method 2300 can be performed by a device including components for performing functions corresponding to the steps of the method. Similarly, refer to Figures 24A to 24D At least some steps in the described method 2400 can be performed by a device including components for performing functions corresponding to the steps of the method. Similarly, refer to Figure 25 At least some steps in the described method 2500 can be performed by a device including components for performing functions corresponding to the steps of the method; and refer to Figure 26A and Figure 26BAt least some steps in the described method 2600 can be performed by means including components for performing functions corresponding to the steps of the method. Examples of suitable means may include user equipment, user device, user terminal, etc. Other examples of suitable means may include RAN nodes (e.g., ng-eNB, gNB, gNB-DU, gNB-CU) or any suitable means such as a server, host, or node.

[0126] Figure 27 The illustration shows an apparatus 2700 implemented according to some examples of the present disclosure, wherein components for performing various operations include hardware that can operate independently or under the guidance of one or more computer programs from a computer-readable storage medium or other memory, such as computer memory. The apparatus may include one or more of each of a plurality of components, such as, for example, a processing circuitry system 2702 connected to a computer-readable storage medium or other memory 2704.

[0127] The processing circuit system 2702 may be comprised of one or more processors individually or in combination with one or more computer-readable storage media. The processing circuit system is typically any computer hardware capable of processing information such as, for example, data, computer programs, computer code, and / or other suitable electronic information. The processing circuit system consists of an assembly of electronic circuits, some of which may be packaged as integrated circuits or multiple interconnected integrated circuits (integrated circuits are sometimes more generally referred to as "chips"). The processing circuit system may be configured to execute computer programs, which may be stored on the processing circuit system or in memory 2704 (on the same device or other devices).

[0128] Depending on the specific implementation, the processing circuitry system 2702 may include multiple processors, multi-core processors, or some other type of processor, such as a central processing unit, graphics processing unit, tensor processing unit, or accelerator. Furthermore, the processing circuitry system may be implemented using multiple heterogeneous processor systems, where a main processor and one or more auxiliary processors reside on a single chip. As another illustrative example, the processing circuitry system may be a symmetric multiprocessor system containing multiple processors of the same type. In another example, the processing circuitry system may be implemented as or otherwise include one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc. Therefore, while the processing circuitry system may be able to execute a computer program to perform one or more functions, the various example processing circuitry systems may also be able to perform one or more functions without the assistance of a computer program. In either case, the processing circuitry system can be appropriately programmed to perform functions or operations according to the example implementations of this disclosure.

[0129] Memory 2704 is typically any computer hardware capable of storing information such as, for example, data, computer programs, instructions 2706 (e.g., computer-readable program code), and / or other suitable information, whether on a temporary or permanent storage basis. Memory may include volatile and / or non-volatile memory and may be fixed or removable. Examples of suitable memory include recording media, random access memory (RAM), read-only memory (ROM), hard disk drives, flash memory, thumb drives, removable computer floppy disks, optical disks, or combinations thereof.

[0130] Memory 2704 is a non-transient device capable of storing information. An example of a suitable memory is a computer-readable storage medium, which differs from a computer-readable transmission medium capable of carrying information from one location to another. Examples of suitable computer-readable transmission media include electronic carrier signals, telecommunication signals, or combinations thereof. As used herein, the term "non-transient" is a limitation of the medium itself (i.e., tangible, not signaling), not a limitation of the persistence of data storage (e.g., RAM versus ROM). The computer-readable medium described herein generally refers to a computer-readable storage medium or a computer-readable transmission medium. A computer-readable medium is any entity or device capable of storing and carrying information, such as one or more computer programs or portions thereof.

[0131] In addition to memory 2704 (e.g., a computer-readable storage medium), processing circuitry 2702 may also be connected to one or more interfaces for displaying, sending, and / or receiving information. Interfaces may include communication interface 2708 and / or one or more user interfaces. Communication interfaces may be configured to send and / or receive information, such as to and / or from (multiple) other devices, (multiple) networks, etc. Communication interfaces may be configured to send and / or receive information via physical (wired) and / or wireless communication links. Examples of suitable communication interfaces include network interface controllers (NICs), wireless NICs (WNICs), and so on.

[0132] The user interface may include a display 2710 and / or one or more user input interfaces 2712. The display may be configured to present or otherwise display information to a user; suitable examples include liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic LED (OLED) displays, active-matrix OLEDs (AMOLEDs), and so on. The user input interfaces may be wireless or wired and may be configured to receive information from the user into the device, such as for processing, storage, and / or display. Examples of suitable user input interfaces include microphones, image or video capture devices, keyboards or keys, joysticks, touch surfaces (separate from or integrated into the touchscreen), biometric sensors, and so on. The user interface may also include one or more interfaces for communicating with peripheral devices such as printers, scanners, and so on.

[0133] The processing circuitry system 2702 executes instructions 2706 or stores instructions in memory 2704, supporting various combinations of operations for implementing exemplary implementations of this disclosure. In this way, the apparatus 2700 may include at least one processing circuitry system and at least one memory coupled to the at least one processing circuitry system, wherein the at least one processing circuitry system is configured to execute instructions stored in the at least one memory. It should also be understood that one or more functions, and combinations thereof, may be implemented by a dedicated hardware-based computer system and / or processing circuitry system performing a specific function, or by a combination of dedicated hardware and program code instructions.

[0134] Some example implementations of this disclosure can also be executed as a computer process defined by one or more computer programs or portions thereof. Example implementations of this disclosure can be implemented by executing at least one portion of a computer program including instructions. The computer program can be in source code form, object code form, or some intermediate form. The computer program can be stored on a computer-readable medium that can be read by a computer, processing circuitry system, or other suitable means. As indicated above, for example, the computer program can be stored in memory, such as a computer-readable storage medium. Additionally or alternatively, for example, the computer program can be stored on a computer-readable transmission medium. The coding of the software used to implement the example implementations of this disclosure is entirely within the scope of those skilled in the art.

[0135] It should be understood that any suitable instructions can be loaded from memory or a computer-readable medium (e.g., a computer-readable storage medium, a computer-readable transmission medium) into a computer, processing circuitry, or other programmable means to produce a particular machine, thereby making that particular machine a component for implementing the functions specified herein. Instructions can also be stored in a computer-readable medium that can direct a computer, processing circuitry, or other programmable means to operate in a particular manner to produce a particular machine or a particular article of manufacture. In some examples, instructions stored in a computer-readable medium can produce an article of manufacture, wherein the article of manufacture becomes a component for implementing the functions described herein. Instructions can be retrieved from a computer-readable medium and loaded into a computer, processing circuitry, or other programmable means to configure the computer, processing circuitry, or other programmable means to perform operations to be performed on or by the computer, processing circuitry, or other programmable means.

[0136] The retrieval, loading, and execution of instructions, including program code instructions, can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some example implementations, retrieval, loading, and / or execution can be performed in parallel, thereby retrieving, loading, and / or executing multiple instructions simultaneously. The execution of program code instructions can produce a computer-implemented process, enabling the instructions, executed by a computer, processing circuitry system, or other programmable device, to provide operations for implementing the functions described herein.

[0137] Benefiting from the teachings presented in the foregoing description and associated drawings, those skilled in the art to which this disclosure pertains will conceive of numerous modifications and other implementations of this disclosure set forth herein. Therefore, it should be understood that this disclosure is not limited to the specific implementations disclosed, and that modifications and other implementations are intended to be included within the scope of the appended claims. Furthermore, although the foregoing description and associated drawings depict exemplary implementations in the context of certain example combinations of elements and / or functions, it should be understood that different combinations of elements and / or functions can be provided by alternative implementations without departing from the scope of the appended claims. In this regard, combinations of elements and functions different from those expressly described above may also be considered, for example, as set forth in some of the appended claims. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

[0138] Some additional examples:

[0139] Example 1. An apparatus comprising: At least one memory, configured to store instructions; and At least one processing circuit system, configured to access at least one memory and execute instructions such that the device at least: Radio Link Control (RLC) Protocol Data Units (PDUs) are received from lower layers of the radio protocol stack. RLC PDUs are received on data paths associated with corresponding sequence number (SN) spaces. Each RLC PDU received on a data path includes a data path identifier that identifies the data path. Construct a status PDU, which includes a status report for one or more RLC PDUs identified by a data path identifier in the status PDU; and Send status PDUs to peer RLC entities. RLC PDUs originate from peer RLC entities.

[0140] Example 2. According to the apparatus of Example 1, each status report for a data path in one or more data paths includes: a data path identifier that identifies the data path, and an offset that points to any next status report for another data path in one or more data paths.

[0141] Example 3. According to the apparatus of Example 2, wherein the status PDU includes: a status report for a data path in the data path, and an offset is set to a value that indicates that the status PDU does not include the next status report following a status report.

[0142] Example 4. The apparatus according to Example 2 or Example 3, wherein the status PDU includes: multiple status reports for multiple data paths in the data path, and the offset of each status report in the multiple status reports other than the last status report in the multiple status reports is set to a value that points to the next status report for another data path.

[0143] Example 5. According to the apparatus of Example 4, the offset for the last state report among multiple state reports is set to a value that indicates that the state PDU does not include the value of the next state report after the last state report among the multiple state reports.

[0144] Example 6. An apparatus according to any one of Examples 1 to 5, wherein for each status report of a data path in one or more data paths, the highest SN in the SN space associated with the data path is indicated from an RLC PDU that has been successfully received on the data path.

[0145] Example 7. An apparatus according to any one of Examples 1 to 6, wherein at least one processing circuitry system is configured to execute instructions to cause the apparatus to further: detect at least one missing RLC PDU for at least one of one or more data paths, a status PDU is constructed for one or more data paths, and The status report for each data path in at least one of one or more data paths indicates at least one missing RLCPDU by means of the SN from the SN space associated with the data path in the corresponding SN space.

[0146] Example 8. A method comprising: Radio Link Control (RLC) Protocol Data Units (PDUs) are received from lower layers of the radio protocol stack. RLC PDUs are received on data paths associated with corresponding sequence number (SN) spaces. Each RLC PDU received on a data path includes a data path identifier that identifies the data path. Construct a status PDU, which includes a status report for one or more RLC PDUs identified by a data path identifier in the status PDU; and Send status PDUs to peer RLC entities. RLC PDUs originate from peer RLC entities.

[0147] Example 9. According to the method of Example 8, each status report for a data path in one or more data paths includes: a data path identifier that identifies the data path, and an offset that points to any next status report for another data path in one or more data paths.

[0148] Example 10. According to the method of Example 9, the status PDU includes: a status report for a data path in the data path, and the offset is set to a value that indicates that the status PDU does not include the next status report after a status report.

[0149] Example 11. According to the method of Example 9 or 10, wherein the status PDU includes: multiple status reports for multiple data paths in the data path, and the offset of each status report in the multiple status reports other than the last status report in the multiple status reports is set to a value that points to the next status report for another data path.

[0150] Example 12. According to the method of Example 11, the offset for the last status report among multiple status reports is set to a value that indicates that the status PDU does not include the value of the next status report after the last status report among multiple status reports.

[0151] Example 13. According to the method of any one of Examples 8 to 12, wherein for each status report of a data path in one or more data paths, the highest SN in the SN space associated with the data path is indicated from the RLC PDU that was successfully received on the data path.

[0152] Example 14. A method according to any one of Examples 8 to 13, wherein the method further comprises: by data path, detecting at least one missing RLC PDU for at least one of one or more data paths, a status PDU being constructed for one or more data paths, and The status report for each data path in at least one of one or more data paths indicates at least one missing RLC PDU via an SN from the SN space associated with the data path in the corresponding SN space.

[0153] Example 15. An apparatus comprising components for performing the method of any one of Examples 8 to 14.

[0154] Example 16. A computer-readable medium including instructions that, in response to execution by at least one processing circuitry system, cause a device to perform the method of any one of Examples 8 to 14.

[0155] Example 17. A computer-readable storage medium including instructions that, in response to execution by at least one processing circuitry system, cause a device to perform the method of any one of Examples 8 to 14.

[0156] Example 18. A computer program including instructions that, in response to execution by at least one processing circuitry system, cause a device to perform the method of any one of Examples 8 to 14.

Claims

1. An apparatus for telecommunications, comprising: At least one memory, the at least one memory being configured to store instructions; as well as At least one processing circuitry system is configured to access the at least one memory and execute the instructions such that the device at least: Radio Link Control (RLC) Protocol Data Units (PDUs) are received from lower layers of the radio protocol stack. The RLC PDUs are received on data paths associated with corresponding sequence number (SN) spaces. Each RLC PDU received on a data path includes a data path identifier that identifies the data path. Construct a status PDU, the status PDU including a status report of the RLC PDU for one or more data paths identified by the data path identifier in the status PDU; as well as The status PDU, which originates from the peer RLC entity, is sent to the peer RLC entity.

2. The apparatus of claim 1, wherein each status report for a data path of the one or more data paths comprises: The data path identifier that identifies the data path, and the offset that points to any next status report for another data path in the one or more data paths.

3. The apparatus of claim 2, wherein the status PDU comprises: A status report for one data path in the data path, wherein the offset is set to a value indicating that the status PDU does not include the next status report following the status report.

4. The apparatus of claim 2, wherein the status PDU comprises: For multiple status reports of multiple data paths in the data path, and for each status report of the multiple status reports except for the last status report in the multiple status reports, the offset is set to a value that points to the next status report for another data path.

5. The apparatus of claim 4, wherein the offset for the last status report among the plurality of status reports is set to a value that indicates that the status PDU does not include the next status report following the last status report among the plurality of status reports.

6. The apparatus according to any one of claims 1 to 5, wherein for each status report of a data path in the one or more data paths, the highest SN in the SN space associated with the data path is indicated from an RLC PDU successfully received on the data path.

7. The apparatus according to any one of claims 1 to 5, wherein the at least one processing circuitry is configured to execute the instructions to cause the apparatus to further: detect, by data path, at least one missing RLC PDU for at least one of the one or more data paths, the status PDU being constructed for the one or more data paths, and The status report for each of the at least one data path in the one or more data paths indicates the at least one missing RLC PDU by means of the SN from the SN space associated with the data path in the corresponding SN space.

8. A method for telecommunications, comprising: Radio Link Control (RLC) Protocol Data Units (PDUs) are received from lower layers of the radio protocol stack. The RLC PDUs are received on data paths associated with corresponding sequence number (SN) spaces. The RLC PDUs received on each data path include a data path identifier that identifies the data path. Constructing a status PDU, the status PDU including, by data path, a status report for the RLC PDU for one or more data paths identified by the data path identifier in the status PDU; and The status PDU, which originates from the peer RLC entity, is sent to the peer RLC entity.

9. The method of claim 8, wherein for each status report of a data path in the one or more data paths, the highest SN in the SN space associated with the data path is indicated from an RLC PDU successfully received on the data path.

10. The method according to claim 8 or claim 9, wherein the method further comprises: According to the data path, detect at least one missing RLC PDU for at least one of the one or more data paths, the state PDU is constructed for the one or more data paths, and The status report for each of the at least one data path in the one or more data paths indicates the at least one missing RLC PDU by means of an SN in the SN space associated with the data path from the corresponding SN space.

Images