Optimized uplink du–CU error and flow control in o-ran networks for applications with high reliability requirements

Abstract

A RAN system comprises a Distributed Unit (DU) and a Centralized Unit (CU) comprising a Centralized-Unit-User-Plane (CU-UP). The system is configured so that the DU sends a UL User data (UUD) PDU including a UL NR-U Sequence Number. The CU-UP identifies a sequence of lost UL NR-U sequence numbers based on the UL NR-U sequence numbers received and sends feedback as part of a UL Data Delivery Status (UDDS) PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, or sends the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with a downlink user data (DUD) PDU. The CU-UP requests the DU to retransmit to the CU-UP the missing UL NR-U sequence numbers for each DRB for which UL error control has been activated.

Description

OPTIMIZED UPLINK DU–CU ERROR AND FLOW CONTROL IN O-RAN NETWORKS FOR APPLICATIONS WITH HIGH RELIABILITY REQUIREMENTSDESCRIPTION OF THE RELATED TECHNOLOGY1. Field of the Disclosure

[0001] The present disclosure relates to Open Radio Access Network (O-RAN) systems and relates more particularly to optimizing DU-CU uplink error and flow control in O-RAN networks. 2. Description of Related Art

[0002] In cloud-based Radio Access Networks (RAN) , a significant portion of the RAN layer processing is performed at a control unit (CU) and a distributed unit (DU) . Both CUs and DUs are also known as baseband units (BBUs) . CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed. The radio functions and real-time critical functions can be processed in the remote radio unit (RU) .

[0003] Next Generation Radio Access Network (NG-RAN) architecture and 5G New Radio (NR) stacks include user and control plane functions. User plane Physical (PHY) , Medium Access Control (MAC) , Radio Link Control (RLC) , Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) are sublayers that originate in User Equipment and are terminated in a gNodeB (gNB) on the network side. The gNB includes a gNB CU and one or more gNB-DUs. The gNB CU includes a Control Unit-Control Plane (CU-CP) and Control Unit-User Plane (CU-UP) . The gNB can comprise a gNB-CU-CP, multiple gNB-CU-UPs (or gNB-CU-UP instances) and multiple gNB-DUs (or gNB-DU instances) . SUMMARY OF THE DISCLOSURE

[0004] In an implementation, described is A RAN system comprising: Centralized Unit (CU) comprising a Centralized-Unit-User-Plane (CU-UP) ; a Distributed Unit (DU) comprising: an Uplink (UL) midhaul (MH) interface to the CU-UP; a transmission logical queue for each DRB; a retransmission logical queue for each DRB; and a GTP-U tunnel between the DU and the CU-UP for each DRB. The DU is configured to send an UL User data (UUD) PDU comprising a plurality of fields including a UL NR-U Sequence Number, and wherein the CU-UP is configured to at least: identify a sequence of lost UL NR-U sequence numbers based on the UL NR-U sequence numbers received; send feedback as part of a UL Data Delivery Status (UDDS) PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, or send the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with a downlink user data (DUD) PDU, or both; and request the DU to retransmit to the CU-UP the missing UL NR-U sequence numbers for each DRB for which UL error control has been activated.

[0005] The UDDS PDU can comprise a PDU type field, a UL Lost Packet Report field; and Indication of congestion between CU-UP and Core Network field; a CU-UP –Core Network Delay Indicator field; a UL Desired buffer size for the data radio bearer (UL DBS) ; a Number of lost UL NR-U Sequence Number ranges reported field; a Start of lost UL NR-U Sequence Number range field; an End of lost UL NR-U Sequence Number range field; and a Delay between CU-UP and Core Network field. The DU cab be configured to add PDUs coming from a UE to the RLC transmission queue, and add UL NR-U sequence number to each such PDU before sending it to CU-UP via the GTP-U tunnel across an F1-U interface, wherein once a PDU with the UL NR-U sequence number is sent from DU to CU-UP, a corresponding RLC SDU is moved to the retransmission queue from the transmission queue and, based on the UDDS feedback from CU-UP to DU over the F1-U interface, the successfully received RLC SDUs are removed from the retransmission queue of the DU.

[0006] The CU-UP can be configured to periodically send the UDDS feedback messages. The CU-UP can be configured to start a retransmission timer after sending UDDS for a DRB to DU, and if the CU-UP does not receive a response for the lost packet report before the expiry of this timer, the CU-UP can be configured to resend the UDDS for a number of retransmission attempts. The CU-UP can be configured to send UDDS feedback messages based on a predetermined event at the CU-UP, the predetermined event comprising a lost number of PDCP PDUs exceeding a threshold.

[0007] If the Indication of congestion between CU-UP and Core Network indicates congestion a situation on a CU-UP-CN interface to the DU, the DU can be configured to reduce a UL data rate towards the CU-UP. Reducing the data rate towards the CU-UP can comprise buffering packets for DRBs at the DU or reducing UL DBS which the CU-UP is indicating to DU as part of the UDDS message for each the DRB, or both. If the DU starts running out of buffer space for a DRB, then the DU can be configured to send a message to CU-UP to increase the DBS. The DU can be configured to estimate a delay budget for scheduling packets for each DRB to the CU-UP based on the UDDS message indicating a delay between CU-UP and CN.

[0008] If there is a continuous downlink data flow from CU-UP to DU along with the uplink data, then the CU-UP can be configured to send feedback from CU-UP to DU. The missing UL NR-U Sequence Numbers is sent together with the downlink user data DUD PDU. A spare bit available in the DUD PDU is used to indicate a presence or absence of a UL lost packet report and another spare bit is used to indicate a presence or absence of the UL desired buffer size (UL DBS) field.

[0009] When a deep packet inspection DPI at CU-UP finds that UL traffic for a given DRB is being sent over UDP, the CU-UP can be configured to continue to send the feedback as part of the UDDS PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers; and if the DPI at CU-UP finds that TCP traffic is being used for a given DRB, the CU can be configured to dynamically switch from sending the feedback as part of the UDDS PDU message to the DU to the feedback from CU-UP to DU about the the missing UL NR-U Sequence Numbers is sent together with the DUD PDU. If there is downlink user data at CU-UP when feedback also needs to be sent in DL, the CU can be configured to send the DL data with the DUD PDU, and the CU is configured to send the downlink user data separately in the UDDS PDU.

[0010] In an implementation, described is a method for RAN system comprising a CU comprising a CU-UP and a DU comprising: an Uplink (UL) midhaul (MH) interface to the CU-UP; a transmission logical queue for each DRB; a retransmission logical queue for each DRB; and a GTP-U tunnel between the DU and the CU-UP for each DRB, the method comprising: sending, by the DU, a UL User data (UUD) PDU comprising a plurality of fields  including a UL NR-U Sequence Number; identifying, by the CU-UP, a sequence of lost UL NR-U sequence numbers  based on the UL NR-U sequence numbers received; sending, by the CU-UP, feedback as part of a UL Data Delivery Status (UDDS)  PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, or sending the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with a downlink user data (DUD) PDU, or both; and requesting, by the CU-UP, the DU to retransmit to the CU-UP the missing UL  NR-U sequence numbers for each DRB for which UL error control has been activated.

[0011] The UDDS PDU comprises a PDU type field, a UL Lost Packet Report field; and Indication of congestion between CU-UP and Core Network field; a CU-UP –Core Network Delay Indicator field; a UL Desired buffer size for the data radio bearer (UL DBS) ; a Number of lost UL NR-U Sequence Number ranges reported field; a Start of lost UL NR-U Sequence Number range field; an End of lost UL NR-U Sequence Number range field; and a Delay between CU-UP and Core Network field.

[0012] The method can comprise, at the DU: adding PDUs coming from a UE to the RLC transmission queue; adding the UL NR-U sequence number to each such PDU before sending it to CU-UP via the GTP-U tunnel across an F1-U interface; once a PDU with the UL NR-U sequence number is sent from DU to CU-UP, moving a corresponding RLC SDU the retransmission queue from the transmission queue; and based on the UDDS feedback from CU-UP to DU over the F1-U interface, removing the successfully received RLC SDUs from the retransmission queue of the DU.

[0013] The method can further comprise: periodically sending, by the CU-UP, the UDDS feedback messages; and / or sending, by the CU-UP, the UDDS feedback messages based on a predetermined event at the CU-UP, the predetermined event comprising a lost number of PDCP PDUs exceeding a threshold. The method can further comprise, at the CU-UP: starting a retransmission timer after sending the UDDS for a DRB to the DU; and if the CU-UP does not receive a response for the lost packet report before the expiry of the timer, resending the UDDS for a number of retransmission attempts.

[0014] The method can further comprise, at the DU, if the Indication of congestion between CU-UP and Core Network indicates congestion a situation on a CU-UP-CN interface to the DU, reducing a UL data rate towards the CU-UP. The method can further comprise, at the DU: reducing the data rate towards the CU-UP by buffering packets for DRBs at the DU or reducing UL DBS which the CU-UP is indicating to DU as part of the UDDS message for each the DRB, or both; and at least one of: if the DU starts running out of buffer space for a DRB, sending a message to CU-UP to increase the DBS; and estimating a delay budget for scheduling packets for each DRB to the CU-UP based on the UDDS message indicating a delay between CU-UP and CN.

[0015] The method can further comprise, at the CU-UP, if there is a continuous downlink data flow from CU-UP to DU along with the uplink data, sending the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with the downlink user data DUD PDU. A spare bit available in the DUD PDU is used to indicate a presence or absence of a UL lost packet report and another spare bit is used to indicate a presence or absence of the UL desired buffer size (UL DBS) field. The method can further comprise, at the CU-UP: when a deep packet inspection DPI at CU-UP finds that UL traffic for a given DRB is being sent over UDP, continuing to send the feedback as part of the UDDS PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers; and if the DPI at CU-UP finds that TCP traffic is being used for a given DRB, dynamically switching from sending the feedback as part of the UDDS PDU message to the DU to the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers is sent together with the DUD PDU; and / or if there is downlink user data at CU-UP when feedback also needs to be sent in DL, sending the DL data with the DUD PDU, and sending the downlink user data separately in the UDDS PDU.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1A shows an example of a User Plane Stack.

[0017] FIG. 1B is a block diagram illustrating the user plane protocols stacks for a PDU session.

[0018] FIG. 2 shows an example of a Control Plane Stack.

[0019] FIG. 3 shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) .

[0020] FIG. 4 is an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) .

[0021] FIG. 5 shows a DL (Downlink) Layer 2 Structure.

[0022] FIG. 6 shows an exemplary logical flow for implementing an RB allocation policy.

[0023] FIG. 7 shows an L2 Data Flow example.

[0024] FIG. 8A shows an example of an O-RAN architecture.

[0025] FIG. 8B shows a flow for an E2 node and Near-RT-RIC.

[0026] FIG. 9 illustrates an example PDU session.

[0027] FIG. 10 illustrates a 5G network architecture with multiple PDU sessions.

[0028] FIG. 11 illustrates Radio Resource Management a 5G network architecture.

[0029] FIG. 12A shows a flow for Downlink User Data (DUD) PDU from CU-UP to DU.

[0030] FIG. 12B shows a DL DUD PDU message from CU-UP to DU.

[0031] FIG. 12C shows a flow for DL Data Delivery Status (DDDS) PDU from DU to CU-UP.

[0032] FIG. 12D shows a DL DDDS PDU message from DU to CU-UP.

[0033] FIG. 12E illustrates a flow for transfer of Assistance Information.

[0034] FIG. 13A illustrates a flow for Uplink User Data (UUD) from DU to CU-UP.

[0035] FIG. 13B illustrates a UUD PDU message from DU to CU-UP.

[0036] FIG. 13C illustrates a flow for UL Data Delivery Status (UDDS) from CU-UP to DU.

[0037] FIG. 13D illustrates a UDDS message from CU-UP to DU.

[0038] FIG. 14A illustrates a flow for UUD PDU message in a downlink user data (DUD) PDU between DU to CU-UP.

[0039] FIG. 14B illustrates a DUD PDU message from DU to CU-UP.

[0040] FIG. 14C illustrates a DUD PDU message from DU to CU-UP.DETAILED DESCRIPTION

[0041] Reference is made to Third Generation Partnership Project (3GPP) and the Internet Engineering Task Force (IETF) and related standards bodies in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions. 3GPP and IETF technical specifications (TS) , standards (including proposed standards) , technical reports (TR) and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.

[0042] 3GPP TS 23.501 V 18.1.0

[0043] 3GPP TS 38.300 V 17.4.0

[0044] 3GPP TS38.473 V, 18.1.0

[0045] 3GPP TS38.425 version 18.0.0

[0046] Acronyms 3GPP: 3rd Generation Partnership Project 5GC: 5G Core Network 5G NR: 5G New Radio 5QI: 5G QoS Identifier ACK: Acknowledgement AM: Acknowledged Mode APN: Access Point Name ARP: Allocation and Retention Priority BS: Base Station CP: Control Plane CQI: Channel Quality Indicator CU: Centralized Unit CU-CP: Centralized Unit –Control Plane CU-UP: Centralized Unit –User Plane DBS: Desired Buffer Size DL: Downlink DDDS: DL Data Delivery Status DDR: Desired Data Rate DNN: Data Network Name DRB: Data Radio Bearer DU: Distributed Unit DUD: DL User Data eNB: evolved NodeB EPC: Evolved Packet Core GBR: Guaranteed Bit Rate gNB: gNodeB GTP-U: GPRS Tunneling Protocol –User Plane IP: Internet Protocol L1: Layer 1 L2: Layer 2 L3: Layer 3 L4S: Low Latency, Low Loss and Scalable Throughput LC: Logical Channel MAC: Medium Access Control MCS: Modulation and Coding Scheme NACK: Negative Acknowledgement NAS: Non-Access Stratum NR-U SN: New Radio –User Plane, Sequence Number NR-UP SN: New Radio –User Plane, Sequence Number (used interchangeably with  NR-U SN) NSI: Network Slice Instance NSSI: Network Slice Subnet Instance O-RAN: Open Radio Access Network PDB: Packet Delay Budget PDCP: Packet Data Convergence Protocol PDU: Protocol Data Unit PHY: Physical Layer PRB: Physical Resource Block QCI: QoS Class Identifier QFI: QoS Flow Id QoS: Quality of Service QFI: QoS Flow Identifier RAT: Radio Access Technology RDI: Reflective QoS Flow to DRB Indication RLC: Radio Link Control RLC-AM: RLC Acknowledged Mode RLC-UM: RLC Unacknowledged Mode RQI: Reflective QoS Indication RRC: Radio Resource Control RRM: Radio Resource Management RTP: Real-Time Transport Protocol RTCP: Real-Time Transport Control Protocol RU: Radio Unit SCTP: Stream Control Transmission Protocol SD: Slice Differentiator SDAP: Service Data Adaptation Protocol SLA: Service Level Agreement S-NSSAI: Single Network Slice Selection Assistance SN: Sequence Number SST: Slice  / Service Type TB: Transport Block TCP: Transmission Control Protocol TEID: Tunnel Endpoint Identifier UDDS: UL Data Delivery Status UE: User Equipment UP: User Plane UL: Uplink UM: Unacknowledged Mode UPF: User Plane Function UUD: UL User Data

[0047] RAN Architectures

[0048] An overview of Next Generation Radio Access Network (NG-RAN) architecture and 5G New Radio (NR) stacks is presented below. 5G NR (New Radio) user and control plane functions with monolithic gNodeB (gNB) are shown in FIGS. 1A, 1B and 2. For the user plane (shown in FIG. 1A, which is in accordance with 3GPP TS 38.300) , Physical (PHY) , Medium Access Control (MAC) , Radio Link Control (RLC) , Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) are sublayers that originate in the UE 101 and are terminated in the gNB 102 on the network side.

[0049] As shown in FIG. 1B, which is a block diagram illustrating the user plane protocols stacks for a Protocol Data Unit (PDU) session, in accordance with 3GPP TS 23.501, PDU layer 9010 corresponds to the PDU carried between the UE 101 and the data network (DN) 9011 over the PDU session. As shown in FIG. 1B, UE 101 is connected to the 5G Access Network (AN) 902, which AN 902 is in turn connected via the N3 interface to the Intermediate UPF (I-UPF) 903a portion of the UPF 903, which I-UPF 903a is in turn connected via the N9 interface to the PDU session anchor 903b portion of the UPF 903, and which PDU session anchor 903b is connected to the DN 9011. The PDU session can correspond to IPv4, IPv6, or both types of IP packets, when the PDU session is of type IPv4, IPv6 or IPv4v6, respectively. GTP-U shown in FIG. 1B supports tunnelling user plane data over N3 and N9 interfaces and provides encapsulation of end user PDUs for N3 and N9 interfaces.

[0050] For the control plane (shown in FIG. 2, which is in accordance with 3GPP TS 38.300) , Radio Resource Control (RRC) , PDCP, RLC, MAC and PHY sublayers originate in the UE 101 and are terminated in the gNB 102 on the network side, and Non-Access Stratum (NAS) originate in the UE 101 and is terminated in the Access Mobility Function (AMF) 103 on the network side.

[0051] NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 is shown in FIGS. 3 and 4. As shown in FIG. 3, the NG-RAN 301 comprises a set of gNBs 302 connected to the 5GC 303 through the NG interface. Each gNB comprises gNB-CU 304 and one or more gNB-DU 305 (FIG. 3) . As shown in FIG. 4, which illustrates separation of Control Unit-Control Plane (CU-CP) and Control Unit-User Plane (CU-UP) , E1 is the interface between gNB-CU-CP 304a and gNB-CU-UP 304b; F1-C is the interface between gNB-CU-CP 304a and gNB-DU 305; and F1-U is the interface between gNB-CU-UP 304b and gNB-DU 305. As shown in FIG. 4, gNB 302 can comprise a gNB-CU-CP 304a, multiple gNB-CU-UPs (or gNB-CU-UP instances) 304b and multiple gNB-DUs (or gNB-DU instances) 305. One gNB-DU 305 is connected to only one gNB-CU-CP 304a, and one gNB-CU-UP 304b is connected to only one gNB-CU-CP 304a.

[0052] Note that F1-Application Protocol (F1-AP) running on F1-C is specified in 3GPP TS38.473 version 18.1.0, and NR User Plane (NR-U) running on F1-U is specified in 3GPP TS38.425 version 18.0.0.

[0053] An overview of Layer 2 (L2) of 5G NR is provided in connection with FIGS. 5-7. L2 of 5G NR is split into the following sublayers (in accordance with 3GPP TS 38.300) :

[0054] 1) MAC 501 in FIGS. 5-7: Logical Channels (LCs) are Service Access Points (SAPs) between the MAC and RLC layers. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers) . For the downlink direction, the MAC layer processes and sends RLC PDUs received on LCs to the PHY as Transport Blocks (TBs) . For the uplink direction, it receives TBs from the PHY, processes these and sends the TBs to the RLC layer using the LCs.

[0055] 2) RLC 502 in FIGS. 5-7: The RLC sublayer presents RLC channels to the PDCP sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM) , RLC-Unacknowledged Mode (RLC-UM) and RLC-Acknowledgement Mode (RLC-AM) . RLC configuration is per logical channel. It hosts Automatic Repeat Request (ARQ) protocol for RLC-AM mode.

[0056] 3) PDCP 503 in FIGS. 5-7: The PDCP sublayer presents Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane.

[0057] 4) SDAP 504 in FIGS. 5-7: The SDAP maps (Quality of Service) QoS flows within a PDU session to a specific Data Radio Bearer.

[0058] Referring now to FIGS. 5 –7, FIG. 5 is a block diagram illustrating DL L2 structure, FIG. 6 is a block diagram illustrating UL L2 structure, and FIG. 7 is a block diagram illustrating L2 data flow example where “H” denotes headers or sub-headers. FIGS. 5 –7 are provided in accordance with 3GPP TS 38.300.

[0059] Open Radio Access Network (O-RAN) is based on disaggregated components, which are connected through open and standardized interfaces based on 3GPP NG-RAN. An overview of O-RAN with disaggregated Centralized Unit (CU) , Distributed Unit (DU) , and Radio Unit (RU) , near-real-time Radio Intelligent Controller (RIC) and non-real-time RIC is illustrated in FIG. 8A.

[0060] As shown in FIG. 8A, the CU (shown split as O-CU-CP 801a and O-CU-UP 801b) and the DU (shown as O-DU 802) are connected using the F1 interface (with F1-C for control plane and F1-U for user plane traffic) over a mid-haul (MH) path. One DU can host multiple cells (e.g., one DU can host 24 cells) and each cell can support many users. In one example, one cell can support 800 Radio Resource Control (RRC) -connected users and out of these 800, there can be subset of 250 Active users (i.e., users that have data to send at a given point of time) .

[0061] A cell site can comprise multiple sectors, and each sector can support multiple cells. As an example, one site can comprise three sectors and each sector can support eight cells (with each cell being on a different frequency band in each sector) . One CU-Control Plane (CU-CP) can support multiple DUs and thus multiple cells. For example, a CU-CP can support 500 cells and around 100, 000 different User Equipment (UE) . Each UE can support multiple Data Radio Bearers (DRBs) and there can be multiple instances of CU-User Plane (CU-UP) to serve these DRBs. For example, each UE can support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UE) can be served by five CU-UP instances (and one CU-CP instance) .

[0062] The DU can be in a private data center, or it can be located at a cell-site. The CU can also be in a private data center or even hosted on a public cloud system. The DU and CU, which are typically located at different physical locations, can be located many kilometers from each other. The CU communicates with a 5G core system, which can also be hosted in the same public cloud system (or can be hosted by a different cloud provider) . A RU (shown as O-RU 803 in FIG. 8A) is located at a cell-site and communicates with the DU via a front-haul (FH) interface.

[0063] The E2 nodes (CU and DU) are connected to the near-real-time RIC 132 using the E2 interface. The E2 interface is used to send data (e.g., user and / or cell KPMs) from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC 132. The applications or services at the near-real-time RIC 132 that deploys the control actions and policies to the RAN are called xApps. During the E2 setup procedures, the E2 node advertises the metrics it can expose, and an xApp in the near-RT RIC can send a subscription message specifying key performance metrics which are of interest. The near-real-time RIC 132 is connected to the non-real-time RIC 133, which is shown as part of Service Management and Orchestration (SMO) Framework 805 in FIG. 8A using the A1 interface. The applications that are hosted at non-RT-RIC are called rApps. Also shown in FIG. 8A are Open evolved Node B (O-eNB) 806, which is shown as being connected to the near-real-time RIC 132 and the SMO Framework 805 and O-Cloud 804, which is shown as being connected to the SMO Framework 805.

[0064] As in FIG. 8B, E2 node (which is DU or CU) and Near-RT-RIC establish E2 session using E2 SETUP REQUEST and E2 SETUP RESPONSE. Near-RT-RIC can subscribe to certain parameters from the E2 node on behalf the xApp running at Near-RT-RIC using the RIC SUBSCRIPTION REQUEST. The E2 node acknowledges this message by sending RIC SUBSCRIPTION RESPONSE to the Near-RT-RIC. As part of this, xApp running at the Near-RT-RIC also provides the event triggers to the E2 node (e.g., it can ask the E2 node to REPORT subscribed parameters periodically to the xApp or to REPORT these subscribed parameters based on certain events to the xApp) . The E2 node communicates subscribed parameters to the Near-RT-RIC and the xApp using RIC INDICATION as shown in FIG. 8B. After analyzing received parameters from the E2 nodes and based on network operator policies, the Near-RT-RIC can send RIC CONTROL REQUEST to take an action at the E2 node (e.g., influence mobility decision) . The E2 node acknowledges this message by sending RIC CONTROL ACKNOWLEDGE to Near-RT-RIC while E2 node functions as instructed by the Near-RT-RIC.

[0065] PDU sessions, DRBs, and Quality of Service (QoS) flows will now be discussed. In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a Data Network (DN) identified by a Data Network Name (DNN) . The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE. The DNN defines the interface to a specific external data network. One or more QoS flows can be supported in a PDU session. All the packets belonging to a specific QoS flow have the same 5G QoS Identifier (5QI) . A PDU session comprises the following: Data Radio Bearers that are between UE and CU in RAN; and an NG-U GTP tunnel that is between CU and User Plane Function (UPF) in the core network. FIG. 9 illustrates an example PDU session (in accordance with 3GPP TS 23.501) comprising multiple DRBs, where each DRB can comprise multiple QoS flows. In FIG. 9, three components are shown for the PDU session 901: UE 101; AN 902; and UPF 903, which includes Packet Detection Rules (PDRs) 9031.

[0066] 3GPP 5G network architecture is illustrated in FIGS. 10 and 11. FIG. 10 is provided in the context of multiple PDU sessions involving multiple DRBs and QoS Flow Identifiers (QFIs) , which PDU sessions are implemented involving UE 101, gNB 102, UPF 903, and DNNs 9011a and 9011b. FIG. 11 is provided in the context of Radio Resource Management (RRM) for connecting UE 101 to the network via RU 306 with a MAC Scheduler 1001. The following should be noted:

[0067] 1) The transport connection between the base station (i.e., CU-UP 304b of FIG. 11) and the UPF 903 uses a single GTP-U tunnel per PDU session, as shown in FIGS. 10 and 11. The PDU session is identified using GTP-U Tunnel Endpoint Identifier (TEID) .

[0068] 2) The transport connection between the DU 305 and the CU-UP 304b of FIG. 11 uses a single GTP-U tunnel per DRB (see also FIG. 10 and FIG. 11) . The DU is provided with an UL GTP-U TEID and the CU is provided with the corresponding DL GTP-U TEID to allow for data communication for that DRB between DU and CU-UP.

[0069] 3) SDAP: a) The SDAP (Service Adaptation Protocol) 504 Layer receives downlink data from  the UPF 903 across the NG-U interface (see FIG. 11) . b) The SDAP 504 maps one or more QoS Flow (s) onto a specific DRB. c) The SDAP header is present between the UE 101 and the CU (when reflective QoS  is enabled) , and includes a field to identify the QoS flow within a specific PDU session.

[0070] 4) GTP-U protocol includes a field to identify the QoS flow and is present between CU and UPF 903 (in the core network) .

[0071] 5) One (logical) DU (or RLC) queue exists per DRB (or per logical channel) for RLC PDUs that are to be transmitted for the first time, as shown in FIG. 11. Separate logical queues can exist in DU for packets that are to be retransmitted to UE.

[0072] In this section, standardized 5QI to QoS characteristics mapping is discussed. As per 3GPP TS 23.501, the one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in Table 1. The first column represents the 5QI value. The second column lists the different resource types, i.e., as one of Non-GBR, GBR, Delay-critical GBR. The third column ( “Default Priority Level” ) represents the priority level Priority 5QI, for which lower the value the higher the priority of the corresponding QoS flow. The fourth column represents the Packet Delay Budget (PDB) , which defines an upper bound for the time that a packet can be delayed between the UE and the N6 termination point at the UPF. The fifth column represents the Packet Error Rate (PER) . The sixth column represents the maximum data burst volume for delay-critical GBR types. The seventh column represents an averaging window for GBR and delay critical GBR types. Note that only a subset of 5QI values defined in 3GPP TS 23.501 are shown in Table 1. Table 1

[0073] For example, as shown in Table 1, 5QI value 1 is of resource type GBR with the default priority value of 20, PDB of 100ms, PER of 0.01, and averaging window of 2000 ms. Conversational voice falls under this category. Similarly, as shown in Table 1, 5QI value 7 is of resource type Non-GBR with the default priority value of 70, PDB of 100ms and PER of 0.001. Voice, video (live streaming) , and interactive gaming fall under this category.

[0074] Radio Resource Management (RRM) is now discussed (ablock diagram for an example RRM with a MAC Scheduler is shown in FIG. 11) . L2 methods (such as MAC scheduler) play a critical role in allocating radio resources to different UEs in a cellular network. For example, the scheduling priority of a logical channel (PLC) can be determined as part of MAC scheduler for downlink and uplink using various parameters.

[0075] In this section, flow control between CU and DU will be discussed. In disaggregated architecture, gNB functionality is distributed among logical nodes CU-CP, CU-UP, DU and RU. DU and CU are connected through F1 interface. E1 interface connects CU-CP and CU-UP. The control plane interface F1-C is defined between CU-CP and DU, and the user plane interface F1-U is defined between CU-UP and DU. F1-U interface, the procedures and functionality of which interface are defined in 3GPP TS 38.425, supports NR User Plane (NR-UP) protocol, which provides support for flow control and reliability between CU-UP and DU. Communication over F1-U interface is achieved through exchange of three PDU types (or messages) : 1) Downlink User Data (DUD) PDU from CU-UP to DU (as shown in FIG. 12A and FIG.  12B) : These are used to carry PDCP PDUs from CU-UP to DU for each DRB. 2) Downlink (DL) Data Delivery Status (DDDS) PDU from DU to CU-UP (as shown in  FIG. 12C and FIG. 12D) . a) The DDDS message conveys Desired Buffer Size (DBS) , Desired Data Rate  (DDR) and some other parameters from DU to CU-UP for each DRB as part of flow control feedback. If value of the DBS is zero for a DRB, the NR PDCP hosting node (e.g., the CU-UP in this example) shall stop sending data for that DRB from the CU-UP to the DU. If value of the DBS is greater than zero, the NR PDCP hosting node (e.g., CU-UP) can send up to this amount of data for that DRB. The value of DDR is the amount of data desired to be received every second by the DU (from CU-UP) for that DRB. b) The corresponding node (e.g., DU in this example) can also transfer uplink  data from the DU to the CU-UP for the concerned DRB along with the DDDS frame in the same GTP-U tunnel. 3) Transfer of Assistance Information (TAI) PDU from DU to CU-UP (as shown in  FIG. 12E) . To recap, FIG. 12A illustrates DL user data (i.e., PDCP PDUs) from the node hosting NR  PDCP 1401 (CU-UP in this example) to RLC SDU queues at the corresponding node 1402 (DU in this example) . FIG. 12C illustrates DL Data Delivery Status (DDDS) PDU (flow control feedback) being sent from the corresponding node 1402 (DU in this example) to the node hosting NR PDCP 1401 (CU-UP in this example) for each DRB. FIG. 12E illustrates transfer of (Radio) Assistance Information from the corresponding node 1402 (DU in this example) to the node hosting NR PDCP 1401 (CU-UP in this example) . The structure of DL Data PDU is shown in FIG. 12B and structure of DDDS is shown in FIG. 12D.

[0076] CU-UP sends PDCP PDUs to DU using NR-U protocol. Each such PDCP PDU is carried using data PDU format (shown in FIG. 12B) , and NR-U Sequence Number (NR-U SN) is added to each such data PDU. In the present disclosure, “NR-U SN” and “NR-UP SN” are used interchangeably. The DDDS message (shown in FIG. 12D) conveys, among other information, Desired Buffer Size (DBS) in bytes, and Desired Data Rate (DDR) in units of bytes / second from DU to CU-UP. If the value of the DBS is zero for a DRB, the NR PDCP hosting node (e.g., the CU-UP in this example) shall stop sending data for that DRB from the CU-UP to the DU. If the value of the DBS is greater than zero, the NR PDCP hosting node (e.g., CU-UP) can send up to this amount of data for that DRB. The value of DDR is the amount of data desired to be received every second by the DU (from CU-UP) for that DRB. FIG. 12D illustrates the details of DL Data Delivery Status (DDDS) sent from the corresponding node (DU in this example) to the node hosting NR PDCP (CU-UP in this example) .

[0077] Just like DDDS which is sent in the uplink direction from DU to CU-UP for DL data being sent from CU-UP to DU, Uplink Data Delivery Status (UDDS) can also be sent in downlink direction from CU-UP to DU for data which is sent in the uplink direction from DU to CU-UP. This can help improve reliability of data over the mid-haul between DU and CU-UP.

[0078] Problem identification

[0079] In this section, DU-CU uplink error control issues caused by midhaul impairments are discussed. Usually, the air interface is the bottleneck in a mobile wireless network, and thus conventional flow control mechanisms are based only on air-interface impairments. However, in certain deployments, MH can also become a potential bottleneck. The MH transport network that connects DU with CU-UP can comprise optical fibers, switches and routers. Occasionally, due to busy-hour conditions or transient traffic spike events, switches and / or routers drop packets to avoid congestion in the network. The MH transport network can also be based on microwave links, which are susceptible to adverse (and / or unpredictable) radio channel conditions, and such networks can have higher packet drop rate compared to MH based on optical fibers.

[0080] In the case of applications designed over TCP, the source application can reduce the transmission rate, thus adversely affecting the application performance. In some cases (or over some time intervals) , midhaul losses are so high that the midhaul becomes the bottleneck link, and the air interface is no longer the bottleneck link in the 5G network. However, conventional mitigation techniques for MH impairments are limited to downlink data transmission over midhaul (i.e., for data flow from CU-UP to DU) and are not optimized for uplink data flow over midhaul (i.e., for UL data transmission from DU to CU-UP) .

[0081] In some scenarios, NG-U interface between CU-UP and UPF in 5G networks (or the S1-U interface between CU-UP and Serving Gateway in 4G networks) may experience congestion. Due to this, delay between CU-UP and UPF can start going up and some packets may also need to be dropped at different nodes. This can also impact end-to-end performance of TCP and other applications.

[0082] In some of the above scenarios, CU-UP can also start running out of buffer space to store and process UL RLC SDUs (or UL PDCP PDUs) being received from multiple DUs. The present disclosure advantageously provides suitable UL flow control mechanisms are needed between DU and CU-UP for such scenarios.

[0083] Accordingly, the present disclosure provides a system and method to advantageously achieve an improved DU-CU error and flow control for uplink data over midhaul in O-RAN networks. Such a system and method also should be able to handle scenarios when the path between CU-UP and UPF experiences congestion. SOLUTION–IMPLEMENTATION I

[0084] This implementation specifies UL re-transmission capability at the DU to improve the mid-haul reliability (for data going from DU to CU-UP over the midhaul) . For the mid-haul reliability, two logical queues at the DU are maintained for each DRB (for data which is being sent in the UL direction from DU to CU-UP) . One of these is used for transmission and another one for retransmission for each DRB (for UL data sent from DU to CU-UP) . A separate GTP-U tunnel is established for each DRB between DU and CU-UP.

[0085] This implementation defines a PDU type, Uplink User Data (UUD) , from DU to CU-UP as shown in FIG. 13A. F1-U interface is enhanced to communicate this from DU to CU-UP. Fields used in UUD PDU are shown in FIG. 13B and listed below:

[0086] PDU Type: The PDU type is in bit 4 to bit 7 in the first octet of the frame. For example, PDU type 3 can be used for this UUD PDU.

[0087] User data existence flag: This parameter indicates whether the DU is communicating user data as part of this UUD PDU for the corresponding DRB. The bit set to ‘0’to indicate that no user data is being communicated as part of this UUD PDU and it is set to ‘1’ to indicate that user data is being communicated as part of UUD PDU for this DRB.

[0088] Retransmission flag: This parameter indicates whether the data PDU sent from DU to CU-UP is a retransmission NR-U PDU. The bit when set to ‘0’ indicates that it is a new NR-U PDU and when set to ‘1’ , it indicates that it is carrying a retransmission NR-U PDU.

[0089] UL NR-U Sequence Number: This parameter indicates the UL NR-U sequence number assigned by the DU for this UL RLC SDU (or UL PDCP PDU) .

[0090] Based on the UL NR-U sequence numbers received, CU-UP identifies the sequence numbers of the missing or lost UL NR-U sequence numbers. CU-UP sends the feedback as part of UL Data Delivery Status (UDDS) message to the DU with the sequence numbers of the lost UL NR-U sequence numbers (as shown in FIG. 13C and FIG. 13D) and requests to retransmit these to CU-UP for each DRB for which UL error control has been activated.

[0091] Fields used in UDDS are shown in FIG. 13D and listed below:

[0092] PDU Type: The PDU type is in bit 4 to bit 7 in the first octet of the frame. For example, PDU type 4 can be used for this UDDS PDU.

[0093] UL Lost Packet Report: This is one bit field. This parameter indicates the presence (or absence) of the following in the UDDS PDU as shown in FIG. 13D: Number of lost UL NR-U Sequence Number ranges reported, Start of lost UL NR-U Sequence Number range and End of lost UL NR-U Sequence Number range. If it is set to ‘1’ indicates the presence of these fields. If it is set to ‘0’ , it indicates absence of these fields.

[0094] IA: ‘Indication of congestion between CU-UP and Core Network’ . A newly added field in the UDDS message in the method is specified here. Here, Core Network (CN) indicates UPF for 5G networks and Packet (or Serving) Gateway for 4G networks. If this parameter is set to ‘1’ , it indicates that the path between CU-UP and CN is getting congested. If it is set to ‘0’ , it indicates that the oath between CU-UP and CN is not congested.

[0095] IB: ‘CU-UP –Core Network Delay Indicator’ : A newly added field in the UDDS message in the method is specified here. Here, Core Network (CN) indicates UPF for 5G networks and Packet (or Serving) Gateway for 4G networks. This bit is used to indicate presence or absence of the field which gives the value of ‘Delay between CU-UP and Core Network’ . If this bit is set to “1” , it indicates presence of the field which gives the value of delay between CU-UP and CN. Otherwise, it indicated absence of the field giving value of delay between CU-UP and CN.

[0096] Spare or reserved bits are as needed.

[0097] UL Desired buffer size for the data radio bearer (UL DBS) : This parameter indicates the desired buffer size in bytes for the corresponding DRB. Here, UL DBS indicates the amount of data (in bytes) which DU can send to CU-UP at that time (or until it receives a new value of UL DBS from CU-UP for that DRB) .

[0098] Number of lost UL NR-U Sequence Number ranges reported: This parameter indicates the number of UL NR-U Sequence Number ranges reported to be lost.

[0099] Start of lost UL NR-U Sequence Number range: This parameter indicates the start of an UL GTP-U sequence number range reported to be lost.

[0100] End of lost UL NR-U Sequence Number range: This parameter indicates the end of UL GTP-U sequence number range reported to be lost.

[0101] IB: Delay between CU-UP and Core Network: This new field is added to UDDS and it gives a value of the delay between CU-UP and CN. Downlink as well as uplink delay between CU-UP and CN is specified in this field.

[0102] At the DU, PDUs coming from the UE are added to new RLC transmission queue. An UL NR-U sequence number is added to each such PDU before sending it to CU-UP via the corresponding GTP-U tunnel across the F1-U interface. Once a PDU with UL NR-U sequence number is sent from DU to CU-UP, the corresponding RLC SDU is (logically) moved to the retransmission queue (from the transmission queue) . Based on the UDDS feedback from CU-UP to DU over the F1-U interface, the successfully received RLC SDUs are removed from the retransmission queue of the DU.

[0103] UDDS feedback messages can be sent periodically (e.g. a periodic interval can be chosen based on QoS class of that traffic being communicated on that DRB) or it can be sent based on a certain event at CU-UP (e.g., if number of RLC SDUs or the corresponding PDCP PDUs that are lost is above a threshold) .

[0104] For suppose DU sent the UL NR-U sequence numbers x1, x2, ...., xn, where CU-UP received a subset of them with UL NR-U SNs y1, y2, ..., ym-1, ym (m<=n) . For suppose at time ‘t’ , CU-UP is sending lost packet report to DU over UDDS.

[0105] UL NR-U PDUs sent via GTP-U tunnel can take different paths between DU and CU-UP, and can arrive out of order at CU-UP. At time t, CU-UP sends the lost packet report for the received PDU SNs till time ‘t-delta1’ . For example at time ‘t’ , SNs y1, y2, ...., yk, yk+2, ..., ym-3, ym are received at CU-UP. By the time ‘t-delta1’ , the received UL NR-U PDU SNs received at CU-UP are y1, y2, .... ., yk, yk+2, then the lost packet report is based on the PDUs with SNs y1, y2, .... ., yk, yk+2.

[0106] Alternatively, CU-UP sends the lost packet report for the UL NR-U SNs till (SNmax minus delta2) . Here SNmax is the highest received UL NR-U SN for that DRB at the CU-UP and delta2 is a configurable non-negative number.

[0107] To handle cases where UDDS sent from CU-UP to DU is lost, CU-UP starts a retransmission timer after sending UDDS for a DRB to DU. If CU-UP does not receive the response for the lost packet report before the expiry of this timer, it sends the UDDS again. Maximum number of retransmission attempts for UDDS message is configured for each DRB.

[0108] IC: Congestion over the path between CU-UP and CN can result in loss of packets or higher delay over the interface between CU-UP and CN. For this, CU-UP uses the “Indication of congestion between CU-UP and CN” bit to indicate congestion situation on CU-UP-CN interface to the DU. With this, DU reduces UL data rate towards CU-UP for certain DRBs (e.g., depending on their QoS class) and starts buffering packets for such DRBs at the DU if possible (for the transient duration until the congestion over the interface between CU-UP and CN is alleviated) . Also, CU-UP can reduce UL data rate (over the DU to CU-UP mid-haul interface) by reducing UL DBS which it is indicating to DU as part of the UDDS message for each such DRB and this can help reduce the UL data rate from CU-UP to CN.

[0109] ID: If DU starts running out of buffer space for a DRB, then DU sends a message to CU-UP to increase the DBS. This is to take care of DU buffer overflow issues. This is communicated using a spare bit in the UL data PDU being sent from DU to CU-UP or using a new message over the F1-U interface for that DRB. If CU-UP can increase DBS for that DRB, it sends UDDS with higher DBS.

[0110] IE: As discussed earlier, CU-UP also keeps informing DU about the delay between CU-UP and CN using the UDDS message specified in the method here. DU uses this to run its MAC scheduler for more effectively. The MAC scheduler at DU knows the Packet Delay Budget (PDB) between UE and CN for each QoS class (i.e. for each QCI in 4G network or 5QI in 5G network) . DU can also estimate delay over the mid-haul between itself and CU-UP. With the UDDS message indicating delay between CU-UP and CN, DU can use this to estimate the delay budget which it can use while scheduling packets for each DRB. IMPLEMENTATION II

[0111] II-A: If there is a continuous downlink data flow from CU-UP to DU along with the uplink data (e.g., a DRB carrying video conferencing traffic) then the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers is sent by piggybacking this along with the downlink user data (DUD) as shown in FIG. 14A, FIG. 14B and FIG. 14C.

[0112] From the spare bits available in DUD PDU, one spare bit is used to indicate presence or absence of UL lost packet report and one more spare bit is used to indicate presence or absence of the UL desired buffer size (UL DBS) field. This is shown in FIG. 14B and these newly added fields in the DUD PDU are listed below:

[0113] UL lost packet report field is set to ‘1’ to indicate the presence of following fields in the DUD PDU: number of lost UL NR-U sequence number ranges reported, start of lost UL NR-U sequence number range, end of lost UL NR-U sequence number range as shown in FIG. 14B.

[0114] If the bit for UL lost packet report’ is set to ‘0’ indicates the absence of these fields.

[0115] UL desired buffer size (UL DBS) field is set to ‘1’ indicates the presence of UL desired buffer size for the data radio bearer, set to ‘0’ indicates the absence of the UL DBS for the DRB. By default, this bit is set to ‘1’ .

[0116] II-B: An alternative way to communicate the missing packet information from CU-UP to DU is shown in FIG. 14C. Here, one spare bit from the DUD PDU is used to indicate presence or absence of the UL information field. If it is set to ‘0’ then there is no uplink (feedback) information in that DUD PDU. If it is set to '1’ , it indicates the presence of uplink (feedback) information in the DUD PDU.

[0117] If spare bit in the DUD being used for UL information is set to ‘1’ then the UL DBS is sent as shown in FIG. 14C.

[0118] In the UL information related octet, if the ‘UL lost packet report’ field is set to ‘1’ , it indicates the presence of following fields in the DUD PDU: number of lost UL NR-U sequence number ranges reported, start of lost UL NR-U sequence number range, end of lost UL NR-U sequence number range. If the bit for UL lost packet report’ is set to ‘0’ indicates the absence of these fields.

[0119] For above, the DUD message (from 3GPP TS38.425) is enhanced which is sent from CU-UP to DU as shown in FIG. 14A, FIG. 14B and FIG. 14C.

[0120] II-C: When the GTP-U PDUs are sent from the DU to the CU-UP, deep packet inspection (DPI) can be performed on the initial few packets at CU-UP to check if bidirectional (such as TCP) traffic is being carried for that DRB. In such cases, this Implementation II can be activated. Implementation I can also be used but Implementation II results in lower overhead compared to Implementation II for such cases. Alternatively, if it is found that that DRB is carrying bi-directional data, Implementation II can be directly activated.

[0121] In another variant, Implementation I (with UDDS) can be used initially. With DPI at CU-UP, if it is found that UL traffic for a given DRB is being sent over UDP, use of Implementation I continues. If DPI at CU-UP finds that TCP traffic is being used for a given DRB, a midhaul traffic management module can dynamically switch from Implementation I to Implementation II for such scenarios.

[0122] The midhaul traffic management module can also use a hybrid method. If there is a downlink user data at CU-UP when feedback also needs to be sent in DL, then the feedback can be piggybacked with DL data (i.e., with DUD PDU) . Otherwise, it can be sent separately as proposed in UDDS PDU.

[0123] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

Claims

1.A RAN system comprising:Centralized Unit (CU) comprising a Centralized-Unit-User-Plane (CU-UP) ;a Distributed Unit (DU) comprising:an Uplink (UL) midhaul (MH) interface to the CU-UP;a transmission logical queue for each DRB;a retransmission logical queue for each DRB; anda GTP-U tunnel between the DU and the CU-UP for each DRB,wherein the DU is configured to send an UL User data (UUD) PDU comprising a plurality of fields including a UL NR-U Sequence Number;wherein the CU-UP is configured to at least:identify a sequence of lost UL NR-U sequence numbers based on the UL NR-U sequence numbers received;send feedback as part of a UL Data Delivery Status (UDDS) PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, or send the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with a downlink user data (DUD) PDU, or both; andrequest the DU to retransmit to the CU-UP the missing UL NR-U sequence numbers for each DRB for which UL error control has been activated.2.The system of claim 1, wherein the UDDS PDU comprises a PDU type field, a UL Lost Packet Report field, and Indication of congestion between CU-UP and Core Network field; a CU-UP –Core Network Delay Indicator field, a UL Desired buffer size for the data radio bearer (UL DBS) , a Number of lost UL NR-U Sequence Number ranges reported field, a Start of lost UL NR-U Sequence Number range field, an End of lost UL NR-U Sequence Number range field and a Delay between CU-UP and Core Network field.3.The system of claim 1, wherein the DU is configured to add PDUs coming from a UE to the RLC transmission queue, and add UL NR-U sequence number to each such PDU before sending it to CU-UP via the GTP-U tunnel across an F1-U interface, and wherein once a PDU with the UL NR-U sequence number is sent from DU to CU-UP, a corresponding RLC SDU is moved to the retransmission queue from the transmission queue and, based on the UDDS feedback from CU-UP to DU over the F1-U interface, the successfully received RLC SDUs are removed from the retransmission queue of the DU.4.The system of claim 1, wherein the CU-UP is configured to periodically send the UDDS feedback messages.5.The system of claim 4, wherein the CU-UP starts a retransmission timer after sending UDDS for a DRB to DU, and if the CU-UP does not receive a response for the lost packet report before the expiry of this timer, the CU-UP resends the UDDS for a number of retransmission attempts.6.The system of claim 1, wherein the CU-UP is configured to send UDDS feedback messages based on a predetermined event at the CU-UP, the predetermined event comprising a lost number of PDCP PDUs exceeding a threshold.7.The system of claim 1, wherein if the Indication of congestion between CU-UP and Core Network indicates congestion a situation on a CU-UP-CN interface to the DU, the DU is configured to reduce a UL data rate towards the CU-UP.8.The system of claim 7, wherein reducing the data rate towards the CU-UP comprises buffering packets for DRBs at the DU or reducing UL DBS which the CU-UP is indicating to DU as part of the UDDS message for each the DRB, or both.9.The system of claim 7, wherein if the DU starts running out of buffer space for a DRB, then DU is configured to send a message to CU-UP to increase the DBS.10.The system of claim 7, wherein the DU is configured to estimate a delay budget for scheduling packets for each DRB to the CU-UP based on the UDDS message indicating a delay between CU-UP and CN.11.The system of claim 1, wherein if there is a continuous downlink data flow from CU-UP to DU along with the uplink data, then the CU-UP is configured to send feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers is sent together with the downlink user data DUD PDU, and a spare bit available in the DUD PDU is used to indicate a presence or absence of a UL lost packet report and another spare bit is used to indicate a presence or absence of the UL desired buffer size (UL DBS) field.12.The system of claim 1, wherein when a deep packet inspection DPI at CU-UP finds that UL traffic for a given DRB is being sent over UDP, the CU-UP is configured to continue to send the feedback as part of the UDDS PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, and wherein if the DPI at CU-UP finds that TCP traffic is being used for a given DRB, the CU is configured to dynamically switch from sending the feedback as part of the UDDS PDU message to the DU to the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers is sent together with the DUD PDU.13.The system of claim 1, wherein if there is downlink user data at CU-UP when feedback also needs to be sent in DL, the CU is configured to send the DL data with the DUD PDU, the CU is configured to send the downlink user data separately in the UDDS PDU.14.A method for RAN system comprisinga Centralized Unit (CU) comprising a Centralized-Unit-User-Plane (CU-UP) ; anda Distributed Unit (DU) comprising:an Uplink (UL) midhaul (MH) interface to the CU-UP;a transmission logical queue for each DRB;a retransmission logical queue for each DRB; anda GTP-U tunnel between the DU and the CU-UP for each DRB;the method comprising:sending, by the DU, a UL User data (UUD) PDU comprising a plurality of fields including a UL NR-U Sequence Number;identifying, by the CU-UP, a sequence of lost UL NR-U sequence numbers based on the UL NR-U sequence numbers received;sending, by the CU-UP, feedback as part of a UL Data Delivery Status (UDDS) PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, or sending the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers together with a downlink user data (DUD) PDU, or both; andrequesting, by the CU-UP, the DU to retransmit to the CU-UP the missing UL NR-U sequence numbers for each DRB for which UL error control has been activated.15.The method of claim 14, further comprising, at the DU:adding PDUs coming from a UE to the RLC transmission queue;adding the UL NR-U sequence number to each such PDU before sending it to CU-UP via the GTP-U tunnel across an F1-U interface;once a PDU with the UL NR-U sequence number is sent from DU to CU-UP, moving a corresponding RLC SDU the retransmission queue from the transmission queue; andbased on the UDDS feedback from CU-UP to DU over the F1-U interface, removing the successfully received RLC SDUs from the retransmission queue of the DU.16.The method of claim 14, further comprising:periodically sending, by the CU-UP, the UDDS feedback messages; and / orsending, by the CU-UP, the UDDS feedback messages based on a predetermined event at the CU-UP, the predetermined event comprising a lost number of PDCP PDUs exceeding a threshold.17.The method of claim 16, further comprising, at the CU-UP:starting a retransmission timer after sending the UDDS for a DRB to the DU; andif the CU-UP does not receive a response for the lost packet report before the expiry of the timer, resending the UDDS for a number of retransmission attempts.18.The method of claim 14, further comprising, at the DU:if the Indication of congestion between CU-UP and Core Network indicates congestion a situation on a CU-UP-CN interface to the DU, reducing a UL data rate towards the CU-UP.19.The method of claim 18, further comprising, at the DU:reducing the data rate towards the CU-UP by buffering packets for DRBs at the DU or reducing UL DBS which the CU-UP is indicating to DU as part of the UDDS message for each the DRB, or both; and at least one of:if the DU starts running out of buffer space for a DRB, sending a message to CU-UP to increase the DBS; andestimating a delay budget for scheduling packets for each DRB to the CU-UP based on the UDDS message indicating a delay between CU-UP and CN.20.The method of claim 14, further comprising, at the CU-UP:when a deep packet inspection DPI at CU-UP finds that UL traffic for a given DRB is being sent over UDP, continuing to send the feedback as part of the UDDS PDU message to the DU with the sequence numbers of the lost UL NR-U sequence numbers, and wherein if the DPI at CU-UP finds that TCP traffic is being used for a given DRB, dynamically switching from sending the feedback as part of the UDDS PDU message to the DU to the feedback from CU-UP to DU about the missing UL NR-U Sequence Numbers is sent together with the DUD PDU; and / orif there is downlink user data at CU-UP when feedback also needs to be sent in DL, sending the DL data with the DUD PDU, and sending the downlink user data separately in the UDDS PDU.

Images