Optimizing downlink and uplink split bearer operation in o-ran networks

Abstract

In a Radio Access Network system including a multi-radio access technology dual connectivity (Multi-RAT DC), a 4G Master eNodeB distributed unit DU (MeNB.DU) and a 5G gNB distributed unit DU (SgNB.DU) of a base station are configured with traffic splitting modules and updated interfaces to coordinate to optimize performance for uplink (UL) and downlink (DL) split bearers.

Description

OPTIMIZING DOWNLINK AND UPLINK SPLIT BEARER OPERATION IN O-RAN NETWORKS DESCRIPTION OF RELATED TECHNOLOGY 1. Field

[0001] The present disclosure is related to Open Radio Access Network (O-RAN)wireless networks and relates more particularly to performance optimization of split bearer operation in O-RAN networks including a multi-radio access technology dual connectivity architecture. 2. Description of Related Art

[0002] Next Generation Radio Access Network (NG-RAN) architecture and 5G NewRadio (NR) stacks include user and control plane functions with a monolithic gNB. The user plane, PHY (physical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers originate in the User Equipment (UE) and are terminated in the gNB on the network side.

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

[0004] In an EN-DC (E-UTRA-NR Dual Connectivity) architecture, the UE has a singleRRC (Radio Resource Control) state, based on MN (Master Node) RRC, and a single C-plane (Control plane) connection towards the MME (Mobility Management Entity) of 4G EPC (Evolved Packet Core). LTE eNB is the MN (denoted as Master eNB or MeNB) and 5G gNodeB is the SN (Secondary Node), denoted as SgNB (or Secondary gNB), in this EN-DC architecture. NR RRC messages can be routed from SgNB to MeNB via the X2-C interface and to the UE via the LTE-Uu air-interface.

[0005] The data (user) plane for this EN-DC architecture. MeNB is connected to S-GW (Serving Gateway) of 4G EPC via the S1-U interface. Similarly, the SgNB is connected to the S-GW via the S1-U interface. For SN terminated split bearer, 4G EPC communicates data with SgNB via the S1-U interface and for MN terminated split bearer, 4G EPC communicated data with MeNB via the S1-U interface. X2-U is used for user plane traffic between MeNB and SgNB. SUMMARY

[0006] Described are implementations of a system, a method, and a computerprogram product for a Radio Access Network (RAN). In an implementation, a method comprises: configuring a 4G Master eNodeB distributed unit DU (MeNB.DU) and a 5G gNB distributed unit DU (SgNB.DU) of a base station to coordinate over a D2 interface to have the RAN optimize performance of UL and DL split bearers for user equipment (UE); measuring, by a SgNB Centralized Unit – User Plane (SgNB.CU-UP): an average latency over an F1-U interface for communication between the SgNB.CU-UP and the SgNB.DU, and an X2-U interface for communication between the SgNB.CU-UP; and an average Packet Error Rate (PER) over mid-haul paths of the F1-U interface and the X2-U interface; determining, by the SgNB.CU-UP, one of the mid-haul paths of the F1-U and theX2-U are a better performing mid-haul path; classifying, by a traffic splitting module at the SgNB.CU-UP, Data Radio Bearer (DRBs) into two classes denoted as Class A and Class B; continuing, by the traffic splitting module, a traffic split for split bearers for the Class A split bearers. choosing, by the SgNB.CU-UP, the better performing mid-haul path for the Class B split bearers.

[0007] For the Class A split bearers, the method can comprise continuing, at thetraffic splitting module at the SgNB.CU-UP, to split DL traffic for SN terminated split bearersalong an ‘SgNB.CU-UP to MeNB.DU’ path and an ‘SgNB.CU-UP to SgNB.DU’ path. The method can comprise receiving (New Radio) NR Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDUs) at the SgNB-DU for each Class A bearer and Class B bearer, a DL split bearer from the SgNB.CU-UP in corresponding Radio Link Control (RLC) (Service Data Unit SDU) queues; taking, by a traffic splitting module at the SgNB-DU, traffic splitting decisions for incoming the NR PDCP PDUs for each Class B split bearer at the SgNB-DU, deciding, by the traffic splitting module at the SgNB-DU, whether to let a given RLC SDU stay in a NR RLC SDU queue at the SgNB.DU or route the RLC SDU towards a MeNB.DU, and if so, routing the NR PDCP PDU a corresponding Long Term Evolution (LTE) RLC queue of the split bearer at the MeNB.DU via the D2 interface; and considering, by an NR MAC scheduler at the SgNB.DU, only the RLC SDUs or NR PDCP PDUs for the Class B split bearers that have been decided to be sent to UE after taking traffic splitting decision at the SgNB- DU, wherein other NR PDCP PDUs that are sent to MeNB.DU via the D2 interface are scheduled via an LTE MAC scheduler at the MeNB.DU.

[0008] The method can comprise establishing an upper threshold bound for a datarate of traffic to be sent via t less preferred path for the Class B split bearer , wherein DL data traffic for the Class B split bearer is sent over an X2-U path is bound the upper threshold bound.

[0009] The method can comprise:sending, by the MeNB.CU-CP, an ‘SgNB Addition Request’ that indicates that it is a Class B or Class A split bearer to the SgNB.CU-CP ; processing, by the SgNB.CU-CP, an ‘SgNB Addition Request’ received from MeNB; and establishing a UE context at the SgNB-DU and a GPRS Tunnelling Protocol – User Plane (GTP-U) tunnel across an D2-U interface to carry traffic between SgNB.DU and MeNB.DU for the Class B split bearer.

[0010] The method can comprise:sending, by the MeNB.DU, the Downlink (DL) Data Delivery Status (DDDS) to the SgNB.CU-UP for Class A SN terminated split bearers and the DDDS to the SgNB.DU for Class B SN terminated split bearers.

[0011] The method can comprise:sending, by the MeNB.DU, Assistance Information Data (AID) to the SgNB.DU and providing radio information of the MeNB to the SgNB.DU.

[0012] The method can comprise:classifying DRBs carrying traffic for applications with low delay and / or high reliability applications as the Class B split bearer, wherein the SgNB.CU-UP is configured to keep monitoring delay, packet error rate, and congestion information received as part of AID from the MeNB.DU and from the SgNB.DU and uses this to decide whether to classify a new split bearer as the Class B split bearer or the Class A split bearer.

[0013] The method can comprise: receiving uplink data at the MeNB.DU for the ClassB split bearer; routing the uplink data for the Class B split bearer to the SgNB.CU-UP via the D2- U interface from the MeNB.DU to the SgNB.DU and the F1-U interface from SgNB.DU to the SgNB.CU-UP; receiving uplink data at the MeNB.DU for the Class A split bearer; and routing the uplink data for the Class A split bearer to the SgNB.CU-UP via the X2-U interface from the MeNB.DU to the SgNB.CU-UP and the F1-U interface from the SgNB.DU to the SgNB.CU-UP.

[0014] The method can comprise:initiating, at the MeNB.DU, a release of the SgNB for the Class B split bearer; and tearing down a GPRS Tunnelling Protocol – User Plane (GTP-U tunnel) for the Class B split bearer; and releasing the SgNB.

[0015] The method can comprise:sending an SgNB Release Request to the SgNB.CU-UP,informing, by the SgNB.CU-CP, the SgNB.CU-UP about the SgNB Release Request; buffering, by the SgNB.CU-UP, data including 4G EPC downlink packets and stopping the DL splitting; sending by the SgNB.CU-UP, all the buffered data to the SgNB.DU, tearing down the GTP-U tunnel across the F1-U interface for the Class B split bearer, and messaging the SgNB.DU; on receipt of the message by the SgNB.DU, stopping, by the SgNB.DU, splitting DL data for the Class B split bearer and sending the buffered data to the MeNB.DU; initiating, by the SgNB.DU tearing down of the GTP-U tunnel across a D2-U interface for the Class B split bearer, after the SgNB.DU has sent all the data for the bearer, informing SgNB.CU-UP and removing a state of the Class B split bearer from SgNB.DU; informing, by the SgNB.CU-UP, the SgNB.CU-CP across the E1 interface and removing the state of the Class B split bearer from SgNB.CU-UP; and sending, by the SgNB.CU-CP, a SgNB Release Request Acknowledgment to the MeNB.CU.

[0016] In an implementation, described is a Radio Access Network systemcomprising: a 4G Master eNodeB distributed unit DU (MeNB.DU) and a 5G gNB distributed unit DU (SgNB.DU) of a base station configured to coordinate over a D2 interface to improve performance for UL and DL split bearers; a SgNB Centralized Unit – User Plane (SgNB.CU-UP) configured to measure: an average latency over an F1-U interface for communication between the SgNB.CU-UP and the SgNB.DU, and an X2-U interface for communication between the SgNB.CU-UP; and an average Packet Error Rate (PER) over mid-haul paths of the F1-U interface and the X2-U interface; the SgNB.CU-UP comprising a traffic splitting module, the SgNB CU-UP being configured todetermine, one of the mid-haul paths of the F1-U and the X2-U are a better performing mid-haul path; the traffic splitting module at the SgNB.CU-UP being configured to: classify Data Radio Bearer (DRBs) into two classes denoted as Class A and Class B; continue a traffic split for split bearers for the Class A split bearers; and choose the better performing mid-haul path for the Class B split bearers.

[0017] The traffic splitting module at the SgNB.CU-UP can be configured to, for theClass A split bearers, split DL traffic for SN terminated split bearers along an ‘SgNB.CU-UP to MeNB.DU’ path and an ‘SgNB.CU-UP to SgNB.DU’ path.

[0018] The SgNB-DU can be configured to receive (New Radio) NR Packet DataConvergence Protocol (PDCP) Protocol Data Unit (PDUs) for each Class A bearer and Class B bearer and a DL split bearer from the SgNB.CU-UP in corresponding Radio Link Control (RLC) (Service Data Unit SDU) queues; and the SgNB-DU can comprise an SgNB-DU traffic splitting module configured to: take traffic splitting decisions for incoming the NR PDCP PDUs for each Class B split bearer at the SgNB-DU; and decide whether to let a given RLC SDU stay in a NR RLC SDU queue at the SgNB.DU or route the RLC SDU towards a MeNB.DU, and if so, route the NR PDCP PDU a corresponding Long Term Evolution (LTE) RLC queue of the split bearer at the MeNB.DU via the D2 interface.

[0019] The SgNB-DU can comprise an NR MAC scheduler configured to consideronly the RLC SDUs or NR PDCP PDUs for the Class B split bearers that have been decided to be sent to UE after the traffic splitting decision at the SgNB-DU is taken, wherein other NR PDCP PDUs that are sent to MeNB.DU via the D2 interface are scheduled via an LTE MAC scheduler at the MeNB.DU. .

[0020] The system can be configured with an upper threshold bound for a data rateof traffic to be sent via the less preferred path for the Class B split bearer , wherein DL data traffic for the Class B split bearer is sent over an X2-U path is bound the upper threshold bound.

[0021] The MeNB.CU-CP can be configured to send an ‘SgNB Addition Request’ toSgNB.CU-CP; The SgNB.CU-CP can be configured to send an ‘SgNB Addition Request’ received from MeNB; and the SgNB.DU can be configured to establish a UE context and a GPRS Tunnelling Protocol – User Plane (GTP-U) tunnel across an F1-U interface to carry traffic between SgNB.DU and MeNB.DU for the Class B split bearer.

[0022] The MeNB.DU can be configured to send a Downlink (DL) Data DeliveryStatus (DDDS) to the SgNB.CU-UP for Class A SN terminated split bearers and the DDDS to the SgNB.DU for Class B SN terminated split bearers.

[0023] The MeNB.DU can be configured to send Assistance Information Data (AID)to the SgNB.DU and providing radio information of the MeNB to the SgNB.DU; and the SgNB.CU-UP is configured to keep monitoring delay and congestion information received as part of the AID from the MeNB.DU and from the SgNB.DU and uses this to decide whether to classify a new split bearer as the Class B split bearer or the Class A split bearer.

[0024] The MeNB.DU can be configured to:receive uplink data for the Class B split bearer and route the uplink data for the Class B split bearer to the SgNB.CU-UP via the D2-U interface from the MeNB.DU to the SgNB.DU and the F1-U interface from SgNB.DU to the SgNB.CU-UP; and receive uplink data at the MeNB.DU for the Class A split bearer; and route theuplink data for the Class A split bearer to the SgNB.CU-UP via the X2-U interface from theMeNB.DU to the SgNB.CU-UP and the F1-U interface from the SgNB.DU to the SgNB.CU-UP.

[0025] The MeNB.DU can be configured to send a release of the SgNB for the Class Bsplit bearer; and the system is configured in response to tear down a GPRS Tunnelling Protocol – User Plane (GTP-U tunnel) for the Class B split bearer and release the SgNB.

[0026] The MeNB.DU can be configured to send an SgNB Release Request to theSgNB.CU-UP; the SgNB.CU-CP can be configured to inform the SgNB.CU-UP about the SgNB Release Request; the SgNB.CU-UP can be configured to buffer data including 4G EPC downlink packets and stopping the DL splitting; the SgNB.CU-UP can be configured to send all the buffered data to the SgNB.DU, tear down the GTP-U tunnel across the F1-U interface for the Class B split bearer, and message the SgNB.DU; on receipt of the message by the SgNB.DU, the SgNB.DU can be configured to stop splitting DL data for the Class B split bearer and send the buffered data to the MeNB.DU; the SgNB.DU can be configured to tear down of the GTP-U tunnel across a D2-U interface for the Class B split bearer, the SgNB.DU can be configured to inform the SgNB.CU-UP and remove a state of the Class B split bearer from SgNB.DU after the SgNB.DU has sent all the data for the Class B split bearer, the SgNB.CU-UP can be configured to inform the SgNB.CU-CP across the E1 interface and remove the state of the Class B split bearer from SgNB.CU-UP; and the SgNB.CU-CP can be configured to send a SgNB Release Request Acknowledgment to the MeNB.CU. BRIEF DESCRIPTION OF THE DRAWINGS’

[0027] FIG 1a shows a system architecture.

[0028] FIG. 1b shows an architecture for a user plane.

[0029] FIG. 2 shows an architecture for a control plane.

[0030] FIG. 3 shows an NG-Radio Access Network (NG-RAN) architecture.

[0031] FIG. 4 shows an NG-Radio Access Network (NG-RAN) architecture.

[0032] FIG. 5 shows a Layer 2 (L2) structure of 5G NR.

[0033] FIG. 6 shows an L2 structure of 5G NR.

[0034] FIG. 7 shows an L2 structure of 5G NR.

[0035] FIG. 8 shows an O-RAN architecture.

[0036] FIG. 9 shows O-RAN messaging protocols.

[0037] FIG. 10 shows a PDU session.

[0038] FIG. 10 shows an implementation architecture for PDU sessions.

[0039] FIG. 11 shows an implementation architecture for PDU sessions.

[0040] FIG. 12 shows an implementation architecture for PDU sessions.

[0041] FIG. 13 shows a flow for DU User Data for CU-UP and DU nodes.

[0042] FIG. 14 shows a flow for DU User Data Delivery Status for CU-UP and DUnodes.

[0043] FIG. 15 shows a flow for Assistance Information Data (AID) to a CU-UP.

[0044] FIG. 16 shows format and contents of an AID message.

[0045] FIG. 17 shows an E-UTRA-NR Dual Connectivity (EN-DC) architecture.

[0046] FIG. 18 shows a data plane for an EN-DC architecture.

[0047] FIG. 19 shows an MCG (Master Cell Group), SCG (Secondary Cell Group) andsplit bearers from a UE perspective.

[0048] FIG. 20 shows an MCG, SCG and split bearers from a base station perspective.

[0049] FIG. 21 shows an EN-DC architecture with downlink split bearer operation.

[0050] FIG. 22 shows a flow for steps for secondary node addition and a downlinktraffic splitting procedure.

[0051] FIG. 23 shows a flow for steps for secondary node addition and a downlinktraffic splitting procedure.

[0052] FIG. 24 shows an architecture and flow for split bearer operations.

[0053] FIG. 25 shows an architecture and flow for split bearer operations.

[0054] FIG. 26 shows an architecture and flow for split bearer operations.

[0055] FIG. 27 shows a flow for steps for an uplink traffic splitting procedure.

[0056] FIG. 28 shows a flow for steps for an uplink traffic splitting procedure.

[0057] FIG. 29 shows an RLC queue for terminated split bearers.

[0058] FIG. 30 shows an RLC queue for terminated split bearers.

[0059] FIG. 31 an architecture and flow for split bearer operations.

[0060] FIG. 32 an architecture and flow for a split bearer operations.DETAILED DESCRIPTION

[0061] RAN System Architecture

[0062] The following section is an overview of the Next Generation Radio AccessNetwork (NG-RAN) architecture and 5G New Radio (NR) stacks.5G NR (New Radio) user and control plane functions with monolithic gNB (gNodeB) 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), PHY (physical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet DataConvergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers originate in the UE 101 and are terminated in the gNB 102 on the network side.

[0063] As shown in FIG. 1b, which is a block diagram illustrating the user planeprotocols stacks for a 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 an N3 interface to the Intermediate UPF (I-UPF) 903a portion of the UPF 903, which I-UPF 903a is in turn connected via anN9 interface to the PDU session anchor 903b portion of the UPF 903, and which PDU session anchor 903b is connected to the DN 9011. CU-UP of AN 902 is connected to UPF 903b via a Backhaul (BH) path. 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.

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

[0065] NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 isshown in FIGS.3-4. As shown in FIG.3, the NG-RAN 301 comprises of 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 (see FIG.3). As shown in FIG.4 (which illustrates separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane)), E1 is the interface between gNB- CU-CP (CU-Control Plane) 304a and gNB-CU-UP (CU-User Plane) 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-DUinstances) 305. One gNB-DU 305 is connected to one gNB-CU-CP 304a, and gNB-CU-UP 304b is connected to one gNB-CU-CP 304a.

[0066] In this section, an overview of Layer 2 (L2) of 5G NR is disclosed inconnection with FIGS.5-7. L2 of 5G NR is split into the following sublayers (in accordance with 3GPP TS 38.300): 1) Medium Access Control (MAC) 501 in FIGS.5-7: Logical Channels (LCs) are SAPs (Service Access Points) 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 Physical layer as Transport Blocks (TBs). For the uplink direction, it receives transport blocks (TBs) from the physical layer, processes these and sends them to the RLC layer using the LCs. 2) Radio Link Control (RLC) 502 in FIGS.5-7: The RLC sublayer presents RLC channels to the Packet Data Convergence Protocol (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 ARQ (Automatic Repeat Request) protocol for RLC-AM mode. 3) Packet Data Convergence Protocol (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. 4) Service Data Adaptation Protocol (SDAP) 504 in FIGS.5-7: The SDAP maps QoS flows within a PDU session to a specific Data Radio Bearer. FIG.5 is a block diagram illustrating DL L2 structure, in accordance with 3GPP TS 38.300. FIG.6 is a block diagram illustrating UL L2 structure, in accordance with 3GPP TS 38.300. FIG.7 is a block diagram illustrating L2 data flow example, in accordance with 3GPP TS 38.300 (in FIG.7, H denotes headers or sub-headers).

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

[0068] As shown in FIG. 8, 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 could host 24 cells) and each cell can support many users. For example, one cell can support 800 Radio Resource Control (RRC)-connected users and out of these 800, there can be 250 Active users (i.e., users that have data to send at a given point of time).

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

[0070] The DU can be located in a private data center, or it could be located at a cell-site. The CU could 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, could be tens of kilometers apart. The CU communicates with a 5G core system, which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider). A RU (Radio Unit) (shown as O-RU 803 in FIG.8) is located at a cell-site and communicates with the DU via a front-haul (FH) interface.

[0071] The E2 nodes (CU and DU) are connected to the near-real-time RIC 132 usingthe 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.8) using the A1 interface. The applications that are hosted at non-RT-RIC are called rApps. Also shown in FIG.8 are 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).

[0072] In this section, some of the protocol messages used for Near-RT-RIC aredescribed. As in FIG.9, 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 and 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 E2 node, e.g. it could ask E2 node to REPORT subscribed parameters periodically to the xApp or to REPORT these subscribed parameters based on certain events to the xApp. E2 node communicates subscribed parameters to Near-RT-RIC (and the xApp) using RIC INDICATION as shown in FIG.9. After analyzing received parameters from the E2 nodes (and based on network operator policies), Near- RT-RIC can send RIC CONTROL REQUEST to take an action at the E2 node (e.g. influence mobility decision). E2 node acknowledges this message by sending RIC CONTROL ACKNOWLEDGE to Near-RT-RIC while E2 node acts as asked by the Near-RT-RIC

[0073] In this section, PDU sessions, DRBs, and Quality of Service (QoS) flows arediscussed. 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 Connecitivity 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 5QI (5G QoS Identifier). A PDU session comprises of the following: Data Radio Bearers which are between UE and CU in RAN; and an NG-U GTP tunnel which is between CU and UPF (User Plane Function) in the core network. FIG.10 illustrates an example PDU session (in accordance with 3GPP TS 23.501) comprising of multiple DRBs, where each DRB can comprise of multiple QoS flows. In FIG.10, three components are shown for the PDU session 901: UE 101; access network (AN) 902; and UPF 903, which includes Packet Detection Rules (PDRs) 9031.

[0074] The following should be noted for 3GPP 5G network architecture, which isillustrated in FIG.11 (in the context of multiple PDU sessions involving multiple DRBs and QoS Flow Identifiers (QFIs), which PDU sessions are implemented involving UE 101, gNodeB 102, UPF 903, and DNNs 9011a and 9011b) and FIG.12 (in the context of Radio Resource Management (RRM) for connecting UE 101 to the network via RU 306 with a MAC Scheduler 1001): 1) The transport connection between the base station (i.e., CU-UP 304b of FIG.12) and the UPF 903 uses a single GTP-U tunnel per PDU session, as shown in FIGS.11 and 12. The PDU session is identified using GTP-U TEID (Tunnel Endpoint Identifier). 2) The transport connection between the DU 305 and the CU-UP 304b of FIG.12 uses a single GTP-U tunnel per DRB (see also FIG.11 and FIG.12). 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. 3) SDAP:a) The SDAP (Service Adaptation Protocol) 504 Layer receives downlink data from the UPF 903 across the NG-U interface (see FIG.12). 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. 4) GTP-U protocol includes a field to identify the QoS flow and is present between CU and UPF 903 (in the core network). 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.12. Separate logical queues can exist in DU for packets that are to be retransmitted to UE.

[0075] In this section, standardized 5QI to QoS characteristics mapping will bediscussed. As per 3GPP TS 23.501, the one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in Table 1 shown below. 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 Priority5QI, 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 maximimum data burst volume for delay-critical GBR types. The seventh column represents averaging window for GBR, delay critical GBR types. Note that only a subset of 5QI values defined in 3GPP TS 23.501 are shown in Table 1 below.

[0076] For example, as shown in Table 1, 5QI value 1 is of resource type GBR withthe default priority value of 20, PDB of 100ms, PER of 0.01, and averaging window of 2000 ms. Conversational voice falls under this catogery. Similarly, as shown in Table 1, 5QI value7 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 catogery. Table 1

[0077] In this section, Radio Resource Management (RRM) is disclosed (a blockdiagram for an example RRM with a MAC Scheduler is shown in FIG.12). L2 methods (such as MAC scheduler) play a critical role in allocating radio resources to different UEs in a cellular network.

[0078] FIG. 13 shows an F1-U interface flow for DU User Data for CU-UP and DUnodes. FIG.14 shows a flow for DU User Data Delivery Status for CU-UP and DU nodes. DU can send Assistance Information Data (AID) to CU-UP as shown in FIG.15 and this provides radio information to CU-UP over the F1-U interface. Format and contents of this AID message are shown in FIG.16. AID PDU is sent from DU to CU-UP.

[0079] AID comprises Assistance Information type such as average CQI, averageHARQ retransmissions, DL radio quality index (DL RQI), UL RQI, power headroom report and the like. The DL Radio Quality Index is a numerical index expressing the radio quality of the DRB or the RLC entity in DL, where the value 0 represents the lowest quality. The UL Radio Quality Index is a numerical index expressing the radio quality of the DRB or the RLC entity in UL, where the value 0 represents the lowest quality.

[0080] If DL Delay Indicator is set to 1, the AID also comprises DL Delay DU Resultfield which indicates DL delay measured at the corresponding node (i.e. DU) in milliseconds for the concerned DRB over the Uu interface.

[0081] If UL Delay Indicator is set to 1, the AID comprises UL Delay DU Result fieldwhich indicates UL delay measured at the corresponding node (i.e. DU) in milliseconds forthe concerned DRB over the Uu interface.

[0082] If UL Congestion Information Indicator field is set to 1 in the AID field, in thatcase AID field also comprises UL Congestion Information. For the cases of ECN (Explicit Congestion Notification) marking Request, the UL Congestion Information field indicates the percentage of UL IP packets up to two decimal points that should be ECN marked for a DRB.

[0083] If DL Congestion Information Indicator field is set to 1 in the AID field, in thatcase AID field also comprises DL Congestion Information. For the cases of ECN marking Request, the DL Congestion Information field indicates the percentage of DL IP packets up to two decimal points that should be ECN marked for a DRB.

[0084] EN-DC (E-UTRA-NR Dual Connectivity) architecture is shown in FIG. 17 andFIG.18. In this architecture, the UE has a single RRC (Radio Resource Control) state, based on MN (Master Node) RRC and a single C-plane (Control plane) connection towards the MME (Mobility Management Entity) of 4G EPC (Evolved Packet Core) as shown in FIG.17. LTE eNB is the MN (denoted as Master eNB or MeNB) and 5G gNodeB is the SN (Secondary Node), denoted as SgNB (or Secondary gNB), in this EN-DC architecture. NR RRC messages can be routed from SgNB to MeNB via the X2-C interface and to the UE via the LTE-Uu air- interface.

[0085] FIG. 18 shows the data (user) plane for this EN-DC architecture. MeNB isconnected to S-GW (Serving Gateway) of 4G EPC via the S1-U interface. Similarly, the SgNB is connected to the S-GW via the S1-U interface. For SN terminated split bearer, 4G EPC communicates data with SgNB via the S1-U interface and for MN terminated split bearer, 4G EPC communicated data with MeNB via the S1-U interface. X2-U is used for user plane traffic between MeNB and SgNB.

[0086] FIG. 19 shows MCG (Master Cell Group), SCG (Secondary Cell Group) and splitbearers from a UE perspective (as in 3GPP TS 37.340). In the EN-DC architecture, MCG comprises of group of 4G LTE cells and SCG comprises of group of 5G NR cells. As in this figure, NR-PDCP is used for at higher layers, and LTE (E-UTRA) RLC / MAC / PHY and NR RLC / MAC / PHY are used at lower layers for split bearer.

[0087] FIG. 20 (as in 3GPP TS 37.340) shows MCG, SCG and split bearers from basestation perspective. For SN terminated split bearer, NR-PDCP is used for at higher layers, and LTE (E-UTRA) RLC / MAC / PHY and NR RLC / MAC / PHY are used at lower layers for split bearer.

[0088] EN-DC (E-UTRA-NR Dual Connectivity) architecture with downlink splitbearer operation is described in FIG.21. In this FIG.21, DL data (i.e. IP packets or NR PDCP SDUs) is communicated from 4G EPC to SgNB-CU-UP across the S1-U interface and the DL traffic splitting operation for split bearer is carried out at the SgNB-CU-UP after doing NR PDCP processing at the SgNB-CU-UP. Note that incoming downlink NR PDCP SDUs (or IP packets) at the SgNB-CU-UP are transformed to NR PDCP PDUs after NR PDCP processing at the SgNB-CU-UP.

[0089] In FIG. 21, V1 is the interface between MeNB-DU and MeNB-CU. S1-C (S1-Control plane) interface exists between MeNB-CU and 4G EPC for SN terminated split bearers.

[0090] DDDS and AID messages are sent from SgNB-DU to SgNB-CU-UP across theF1-U interface as shown in FIG.21. Also, DDDS and AID messages are sent from MeNB-DU to SgNB-CU-UP via the X2-U interface.

[0091] Note that UE can start with a MCG bearer (i.e. along the UE – MeNB – 4G EPC)path and MeNB can decide to switch this bearer to SN terminated split bearer. Alternatively, MeNB can directly decide to establish a SN terminated split bearer for a UE.

[0092] As part of DL traffic splitting operation at the SgNB-CU-UP, some of these NRPDCP PDUs are communicated from SgNB-CU-UP to SgNB-DU (across the F1-U interface as in FIG.21) and eventually to the UE via the 5G NR-Uu air-interface. These also get processed via NR RLC and NR MAC at SN (i.e. at SgNB-DU) as shown in FIG.20.

[0093] Some other NR PDCP PDUs are communicated from SgNB-CU-UP to MeNB-DU (across the X2-U interface as in FIG.21) and eventually to the UE via the 4G LTE-Uu air- interface. Note that these NR PDCP PDUs are also processed via E-UTRA RLC and E-UTRA MAC at MN (i.e. at MeNB-DU) as shown in FIG.20 for split bearers.

[0094] Some of the steps for secondary node (i.e. SgNB in the EN-DC architecture)addition and downlink traffic splitting procedure based on 3GPP TS 37.340 are shown in FIG.22 and FIG.23.

[0095] As part of step 1a) in FIG. 22, MeNB sends ‘SgNB Addition Request’ to SgNB-CU-CP. It comprises information about the bearer for which SN (i.e. SgNB) split bearer needs to be established. In step 2a), SgNB.CU-CP sends ‘Bearer Context Setup Request’ message to SgNB.CU-UP using the E1AP protocol. As part of step 3a), SgNB.CU-UP sends ‘Bearer Context Setup Response’ message to SgNB.CU-CP. Along with other parameters, QoS information about bearer is shared with SgNB.CU-UP as part of steps 2a) and 3a).

[0096] In step 4a), ‘UE Context Setup Request’ message is sent from SgNB.CU-CP toSgNB.DU across the F1-C interface using the F1AP protocol. In Step 5a), SgNB.DU responds with ‘UE Context Setup Response’ message to SgNB.CU-CP. Along with other parameters, QoS information about the bearer is shared with SgNB.DU as part of steps 5a) and 6a) in FIG.22.

[0097] In step 6a), ‘Bearer Context Setup Request’ is sent from SgNB.CU-CP toSgNB.CU-UP and in step 7a), ‘Bearer Context Setup Response’ message is sent from SgNB.CU-UP to SgNB.CU-CP as in FIG.22. In step 8a), SgNB.CU-CP sends ‘SgNB Addition Request Acknowledge’ message to MeNB.

[0098] GTP-U tunnel to carry traffic between SgNB.CU-UP and SgNB.DU for 5G leg ofSgNB terminated split bearer is also established as part of the steps shown in FIG.22.

[0099] FIG. 23 shows some additional steps with which GTP-U tunnel to carry trafficon 4G leg is completely established between SgNB.CU-UP and MeNB (or specifically between SgNB.CU-UP and MeNB.DU for disaggregated base station architecture). It also shows the part where UE carries out random access procedure with SgNB to directly start getting data via SgNB (for the 5G leg).

[0100] In step 9a) of FIG. 23, MeNB sends RRC Connection Reconfiguration to (EN-DC) UE and in step 10a), this UE responds with ‘RRC Reconfiguration Complete’ message. In step 11a), MeNB sends ‘SgNB Reconfiguration Complete’ to SgNB.CU-CP. As part of step 12a), UE carries out random access procedure with SgNB. In step 13a), MeNB sends ‘SN Status Transfer’ to SgNB-CU-CP’ (if bearer is using RLC AM).

[0101] Data forwarding from MeNB to SgNB.CU-UP happens as part of steps 14) and15a) in FIG.23. Next, SgNB.CU-UP also starts splitting traffic across 5G and 4G legs of the network. DL Data towards 4G leg is sent as part of steps 16a) and 17a). DL data towards 5G leg is sent as part of steps 18a) and 19a). As part of step 20a), MeNB interacts with 4G EPC to carry out path switch to make it SN terminated split bearer. 4G EPC starts sending DL data towards SgNB.CU-UP as part of step 21a) after the path switch operation. SgNB.CU-UP continues to split traffic across 4G and 5G legs of the network.

[0102] EN-DC architecture with UL split bearer operation is shown in FIG. 24. Forthe UL split bearer in the EN-DC (NSA) architecture, uplink data from the EN-DC UE 105 towards the SgNB-DU 152 and MeNB.DU 142 is split at the (EN-DC) UE 105. After splitting, some packets are sent on the 5G leg 154 (towards SgNB.CU-UP 151) and others on the 4G leg 144 of the network (towards SgNB.CU-UP 151). SgNB.CU-UP eventually sends these towards 4G EPC 140.

[0103] EN-DC UE UL splitting procedure is specified in 3GPP TS 36.323. The gNB106 provides a threshold value, indicated as ul-DataSplitThreshold, to each (EN-DC) UE 105 for each split DRB.

[0104] UL-DataSplitThreshold ::= ENUMERATED { b0, b100, b200, b400, b800,b1600, b3200, b6400, b12800, b25600, b51200, b102400, b204800, b409600, b819200, b1228800, b1638400, b2457600, b3276800, b4096000, b4915200, b5734400, b6553600, infinity, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}

[0105] Here b100 means 100 bytes, b400 means 400 bytes and so on. If UL dataaccumulated at EN-DC UE for a split DRB is above this threshold, UE can split data across 5G leg 154 and 4G leg 144 of the network using its own internal logic. If UL data accumulated at (EN-DC) UE 105 is below a threshold, the (EN-DC) UE 105 sends data for that DRB along the primary path. In general, the primary path is 5G leg 154 and secondary path is 4G leg 144 for UL split bearers.

[0106] In FIG. 24, V1234 is the interface between MeNB.DU 142 and MeNB.CU 141.S1-C (S1-Control plane) interface exists between MeNB.CU 141 and 4G EPC 140. EN-DC UE 105 uses RRC signalling 231 between itself and MeNB.CU 141.

[0107] Inter-DU interface can be used for DU to DU communication. One suchinterface, denoted as D2 interface, is defined in the patent application with a preliminary serial number of 18 / 591,782 having a filing date of February 29, 2024 with focus on Inter- vDU Carrier Aggregation.

[0108] D2-AP (D2-Application Layer) protocol running over SCTP between differentDUs can be used for inter-vDU control plane communication and GTP-U tunnels over UDP / IP can be used for inter-vDU user plane communication.

[0109] Description of Implementations

[0110] For SN terminated split bearer scenario considered in FIG. 21, DDDS andoptionally AID messages are sent from SgNB.DU to SgNB.CU-UP (across F1-U interface) and from MeNB.DU to SgNB.CU-UP (across X2-U interface). As discussed earlier, each DDDS message carries DBS (Desired Buffer Size) and optionally DDR (Desired Data Rate). Each AID can also carry information related to the radio link quality of the corresponding air- interface.

[0111] In several deployment scenarios, DU can be located at a cell site or at aprivate data center, and CU can be located in a public cloud. The DU-CU mid-haul can comprise one or more links. Each of these links can use optical fiber, microwave or other communication technologies. IP routers or other devices can connect one link to another link over this mid-haul. Some of these links (such as point-to-point optical fiber links) can result in packet error rate (PER) of less than 1 percent while some links (such as microwave) can result in high error rate (e.g., varying between 1 – 15 percent or higher) during some time intervals.

[0112] One way latency between CU-UP and DU includes propagation delay,transmission delay and queuing delay at various nodes (e.g. at CU-UP, DU and at intermediate routers and switches) and the hardware / software processing delays over the mid-haul. There is also additional delay due to retransmissions between CU-UP and DU when there is packet loss over the mid-haul and the hardware / software processing delays. This one-way latency over the mid-haul can vary from few ms (e.g.2 ms) to higher value (e.g. few 210s of ms or even much higher.

[0113] Latency and packet error rate across F1-U (for data communication betweenSgNB.CU-UP and SgNB.DU) and X2-U (for data communication between MeNB.DU and SgNB.CU-UP) interfaces can also be different. For example, optical fiber can be used for links across F1-U and microwave can be used for links across X2-U. In such cases, F1-U can result in lower latency and higher reliability (i.e. lower PER) compared to X2-U. As SgNB.CU-UP sends PDCP PDUs for split bearer across F1-U and X2-U, this can result in higher number of out of sequence arrivals (and thus reordering issues) at the UE and this can degrade application performance.

[0114] DDDS and AID messages are sent from DU to CU-UP (specifically fromMeNB.DU to SgNB.CU-UP and from SgNB.DU to SgNB.CU-UP as shown in FIG.21), but can be delayed due to reasons as discussed above. Thus, the DL data splitting module at SgNB.CU-UP works with information which can be already X ms old (where X can vary from few ms to few 10s of ms) and can take poor splitting decisions, for example during the time intervals when one of these cells are or can be getting overloaded. The present disclosure describes implementation where a 4G DU (i.e. MeNB.DU) and 5G DU (i.e. SgNB.DU) coordinate with each other to help SgNB.CU-UP take more effective DL splitting decisions.

[0115] For a UL split bearer scenario as shown in FIG. 24, UE takes the UL splittingdecision and decides how to split UL traffic across 4G and 5G legs. UL splitting decision taken by each individual UE may not be good at the cell (or DU) level as each UE is only taking decisions based on the local information it has (and not the glabal information which is available with the DU). Base station can influence the way the UE takes splitting decisions by changing the value of ul-DataSplitThreshold, but there is delay and overhead associatedwith changing the value of ul-DataSplitThreshold very often. Implementations as described herein advantageously allow the base station to influence each UE to take more effective UL splitting decisions. This disclosure thus describes an implementation where 4G DU (i.e. MeNB.DU) and 5G DU (i.e. SgNB.DU) coordinate with each other to help the UE take more effective UL splitting decisions.

[0116] IMPLIMENTATION IA – Optimized DL Split Bearer Method

[0117] In this method, MeNB.DU and SgNB.DU coordinate with each other over theD2 interface as shown in FIG.25 and as described below.

[0118] SgNB.CU-UP measures the average latency over the F1-U (for communicationbetween SgNB.CU-UP and SgNB.DU) and X2-U (for communication between SgNB.CU-UP and MeNB.DU). It also measures average PER over the F1-U and X2-U mid-haul paths.

[0119] If SgNB.CU-UP finds that one of these mid-hauls (e.g. F1-U) is performingbetter than the other mid-haul (e.g. X2-U in this case), the traffic splitting module at the SgNB.CU-UP starts classifying DRBs into two classes denoted as Class A and Class B. This classification can be done based on operator policies. For example, a DRB carrying traffic for an application with low latency and / or high reliability may be classified as Class B data radio bearer (or Class B split bearer). Similarly, a DRB carrying data for an application (such as web browsing or file transfer) can be classified as Class A application.

[0120] For Class A DRBs, the traffic splitting module at the SgNB.CU-UP continues tosplit DL traffic for SN terminated split bearers along the ‘SgNB.CU-UP to MeNB.DU’ and ‘SgNB.CU-UP to SgNB.DU’ paths. For example, 30% traffic for a Class A split bearer could be sent along the ‘SgNB.CU-UP to MeNB.DU’ path and 70% traffic along the ‘SgNB.CU-UP to SgNB.DU’ path during a given time period.

[0121] For a given Class B split bearer, SgNB.CU-UP chooses a path (i.e. F1-U or X2-U) which is better than the other path in terms of latency and reliability and this path is called the ‘preferred’ path for that Class B split bearer. For example, optical fiber can be used for the F1-U (i.e. SgNB.CU-UP to SgNB.DU) path and microwave can be used for theX2-U (i.e. SgNB.CU-UP to MeNB.DU’) path. For example, iIf one path (e.g. F1-U) is resulting in lower latency and / or higher reliability than the other path (e.g. X2-U), then this (i.e. F1-U in this example) is considered as the preferred path for that Class B split bearer. In addition, delay and / or reliability (or PER) across SgNB.CU-UP to UE (via SgNB.DU) and SgNB.CU-UP to UE (via MeNB.DU) can also be considered to choose a preferred path.

[0122] As shown in FIG. 25, SgNB.CU-UP can send all the DL traffic to SgNB.DU alongthis preferred F1-U path for this Class B split bearer.

[0123] NR PDCP PDUs are received at the SgNB-DU for each (Class A and Class B) DL(split) bearer from the SgNB.CU-UP in the corresponding RLC SDU queues. A new traffic splitting module is used at the SgNB-DU which takes traffic splitting decisions for incoming NR PDCP PDUs for each Class B split bearer at the SgNB-DU as shown in FIG.25. As DL NR PDCP PDUs are received in the corresponding RLC SDU queue (at the SgNB.DU) for a Class B split bearer, this traffic splitting module decides whether to let this RLC SDU stay in the NR RLC SDU queue at the SgNB.DU (to transmit to UE over the 5G NR air-interface) or route this towards the MeNB.DU for the corresponding LTE RLC SDU queue (to transmit to the UE via the 4G LTE air-interface). If the traffic splitting module at the SgNB.DU decides to route a NR PDCP PDU of a Class B split bearer towards the MeNB.DU, this NR PDCP PDU is routed towards the corresponding LTE RLC queue of this split bearer at the MeNB.DU using the D2 interface which interfaces SgNB.DU with MeNB.DU. Note that the delay between SgNB.DU and MeNB.DU can be even less than 1 ms if SgNB.DU and MeNB.DU are hosted in the same DU server, few ms if they are hosted in the same data center and higher otherwise. PER on D2 interface can also vary. The traffic splitting module at the SgNB.DU takes into account these along with various other parameters (e.g. its buffer occupancy, quality of F1-U interface, QoS requirements of the application etc) while taking traffic splitting decisions.

[0124] NR MAC scheduler at the SgNB-DU considers only those newly added RLCSDUs (or NR PDCP PDUs) for Class B split bearers which have been decided to be sent to UE via the NR Uu air-interface after taking traffic splitting decision at the SgNB.DU. Other NRPDCP PDUs which are sent to MeNB.DU via the D2 interface (after taking traffic splitting decision at SgNB.DU) are scheduled via the LTE MAC scheduler at the MeNB.DU.

[0125] In an alternate method shown in FIG. 26, an upper threshold can be specifiedto bound the data rate (or volume) of traffic to be sent via less preferred path (i.e. X2-U in the example being considered here) for any given Class B split bearer. In this case, DL data traffic for Class B split bearer is sent via F1-U as well as X2-U path though the data rate at which it is sent across the X2-U path is upper bounded by a pre-defined threshold (or a dynamically computed threshold based on network conditions). In addition, DL traffic for Class B split bearer is also split at SgNB.DU and sent to MeNB.DU across the D2 interface (and eventually to UE via the LTE air-interface) and to UE via the 5G NR air-interface.

[0126] IMPLIMENATION IB: Optimized DL Split Bearer Procedure

[0127] For a SN terminated split bearer ‘s’, one GTP-U tunnel (denoted by g(s, F1-U))is established to carry traffic over the F1-U interface and another GTP-U tunnel (denoted by g(s, X2-U)) is established to carry traffic over the X2-U interface. This already happens as part of the existing SN terminated split bearer operation for the EN-DC architecture (as in 3GPP TS 37.340).

[0128] In the method specified here, another GTP-U tunnel for split bearer ‘s’(denoted by g(s, D2)) is established over the D2 interface and traffic splitting operation for split bearer ‘s’ is carried out at the SgNB.DU also if this split bearer ‘s’ is a Class B split bearer. This tunnel g(s, D2) carries traffic from SgNB-DU to MeNB.DU after performing the traffic splitting operation for Class B split bearer ‘s’ at the SgNB.DU.

[0129] At step 1b), MeNB.CU-CP sends ‘SgNB Addition Request’ to SgNB.CU-CP as inFIG.27. This request message is enhanced to indicate if this includes a request for a Class B SN terminated split bearer.

[0130] At step 2b) SgNB.CU-CP processes ‘SgNB Addition Request’ received fromMeNB. As part of t steps 2b) and 3b) it also establishes bearer context at gNB.CU-CP startsestablishing UE context at SgNB-DU and GTP-U tunnel across the F1-U interface as per step 4b) of as in FIG.27.

[0131] If SgNB.CU-CP finds that the ‘SgNB Addition Request’ includes a request for aClass B SN terminated bearer (‘s’), it communicates this information to SgNB.DU by enhancing the ‘UE Context Setup Request’ message which is sent over the F1AP protocol, as shown in step 4b) of FIG.27. If SgNB.DU is planning to accept this request for split bearer ‘s’, it moves to step 4b-A) in FIG.27.

[0132] In step 4b-A), SgNB.DU establishes UE context at MeNB.DU and GTP-U tunnelto carry traffic between SgNB.DU and MeNB.DU for Class B split bearer ‘s’.

[0133] Thus, if SgNB is planning to accept the ‘SgNB Addition Request’ which wassent to it as part of step 1b) in FIG.27 and if SgNB finds that this request is for a Class B split bearer ‘s’, it also takes help of SgNB.DU to establish GTP-U tunnel for this bearer ‘s’ across the D2 interface between SgNB.DU and MeNB.DU (as part of step 4b-A in FIG.27). After this SgNB.DU indicates success to the SgNB-CU-CP (as part of step 5b in FIG.27) for GTP-U tunnel establishment across D2 and UE context creation at SgNB-DU.

[0134] Note that such GTP-U tunnels over the D2 interface are established only forthe Class B split bearers and not for the Class A split bearers.

[0135] For each Class B split bearer ‘s’, it results in GTP-U tunnels across F1-U, X2-Uand D2 interfaces in the radio access network. Out of these, g(s, F1-U) and g(s, X2-U) are created using existing mechanisms, and g(s, D2) is created using the method described here. As described earlier, data rate (or volume) across the tunnel g(s, X2-U) for Class B split bearer ‘s’ is upper bounded by a pre-specified (or a dynamically computed) threshold.

[0136] For each Class A SN terminated split bearer, it results in GTP-U tunnelsacross the F1-U and X2-U interfaces. No GTP-U tunnel is established for Class A split bearer across D2 interface.

[0137] Step 6b, 7b and 8b of FIG. 27 are similar to step 6a, 7a and 8a of FIG. 22. Splitbearer operation as per step 9a to step 21a of FIG.23 continues after step 8b of FIG.27 but splitting for Class B split bearer is done as per the method described above.

[0138] Note that MeNB.CU-UP is not explicitly shown in FIG. 27 as CU-UP for MeNBand SgNB can be common. Thus, SgNB.CU-UP can perform functions of SgNB.CU-UP as well as MeNB.CU-UP.

[0139] NR PDCP PDUs communicated using g(s, X2-U) and g(s, D2) are enqueued inthe same RLC SDU queue in the MeNB.DU in FIG.26. For this to happen, MeNB.DU needs to know that tunnels g(s,X2-U) and g(s,D2) correspond to the same split bearer ‘s’. Message 11b-A and 11b-B in FIG.28 are added for this purpose. With message 11b-A, SgNB.CU-CP informs identity of GTP-U tunnel g(s, X2-U) to SgNB.DU. This is done by enhancing the F1AP protocol running over the F1-C interface. For the identity of a tunnel for split bearer ‘s’, IP addresses and tunnel ids on both ends of the tunnel (along with other relevant information) are communicated using the F1AP protocol.

[0140] With message 11b-B in FIG. 28, identity of tunnel g(s, X2-U) for split bearer iscommunicated from SgNB.DU to MeNB.DU using the D2AP protocol across the D2-C interface.

[0141] MeNB.DU already knows the identity of tunnel g(s, D2-U) for Class B splitbearer ‘s’ and with above steps, it also gets to know the identity of tunnel g(s, X2-U) for this Class B split bearer ‘s’. MeNB.DU uses this information to enqueue incoming NR PDCP PDUs over the X2-U interface from SgNB.CU-UP and incoming NR PDCP PDUs over the D2-U interface from SgNB.DU for Class B split bearer ‘s’ in the same RLC queue at MeNB.DU.

[0142] MeNB scheduler at DU works across these RLC queues and schedules datatowards EN-DC UE using the 4G LTE air-interface.

[0143] Note that step 9b, 10b and 11b in FIG. 28 are same as step 9a, 10a and 11a inFIG.23.

[0144] Step 11b-A and 11b-B are steps in FIG. 28 as described above.

[0145] Step 12b to 15b in FIG. 28 are same as step 12 to 15 in FIG. 23.

[0146] At this point, SgNB.CU-UP starts splitting DL data across X2-U and F1-Uinterfaces.

[0147] For Class A SN terminated split bearer, step 1b6 to 19b in FIG. 28 are same asstep 16b to 19b in FIG.23.

[0148] For Class B split bearer in FIG. 28, SgNB.CU-UP splits traffic in way such thatthe DL data rate (or volume) for such a bearer across X2-U is upper bounded by a pre- defined (or a dynamically computed) threshold (as in step 16b).

[0149] In step 17 of FIG. 28, DL data is sent from MeNB.DU to EN-DC UE.

[0150] In step 18b of FIG. 28, data rate (or volume) of DL traffic for Class B splitbearer along the F1-U path can potentially be more than the data rate (or volume) of DL traffic for Class B split bearer in FIG.23.

[0151] In this method, SgNB.DU performs traffic splitting for Class B split bearers. Itsends traffic for Class B split bearer along D2-U (as in step 18b-A) and along the 5G NR air- interface towards EN-DC UE as in step 19b after performing traffic splitting operation. In step 18b-B of FIG.28, MeNB.DU sends received traffic over D2-U interface for Class B split bearer to EN-DC UE.

[0152] Path switching operation is performed in steps 20b and 21b.

[0153] IMPLIMENTATION IC: Flow Control enhancements

[0154] With existing methods, MeNB.DU sends flow control feedback, DDDS (DLData Delivery Status), to SgNB.CU-UP along the X2-U interface for all the SN terminated split bearers in the EN-DC architecture (as shown in FIG.21).

[0155] With the method specified here and shown in FIG. 25, MeNB.DU sends DDDSto SgNB.CU-UP for Class A SN terminated split bearers (across the X2-U interface) and MeNB.DU sends DDDS to SgNB.DU for Class B SN terminated split bearers (across the D2-Uinterface). This is also shown in FIG.29 with respect to a RLC queue (for the corresponding bearer) in MeNB.DU which stores and processes DL NR PDCP PDUs.

[0156] In addition, SgNB.DU continues to send DDDS towards SgNB.CU-UP acrossF1-U interface for Class A and Class B SN terminated split bearers.

[0157] With the method specified here and shown in FIG. 26, MeNB.DU sends DDDSto SgNB.CU-UP for Class A and Class B SN terminated split bearers, and MeNB.DU sends DDDS to SgNB.DU for Class B SN terminated split bearers. This is also shown in FIG.30 with respect to a RLC queue (for the corresponding bearer) in MeNB.DU which stores and processes DL NR PDCP PDUs.

[0158] Note that DDDS is to be sent to SgNB.CU-UP as well as SgNB.DU for Class B SNterminated bearer from the same RLC queue of MeNB.DU (for the same Class B nearer) as shown in FIG.30 (corresponding to the overall method shown in FIG.26).

[0159] As described earlier, each DDDS message comprises DBS (Desired BufferSize) and optionally DDR (Desired Data Rate). In FIG.30, DBS and DDR are being sent to two different nodes (i.e. SgNB.CU-UP and SgNB.DU) from the same RLC queue in the MeNB.DU for Class B SN terminated split bearer. Also, data rate (or volume) of Class B SN terminated bearer which is sent via the X2-U interface (from SgNB.CU-UP to MeNB.DU) is upper bounded by a pre-defined (or a dynamically computed) threshold. MeNB.DU takes into account this constraint while computing suitable values of DBS and DDR while which sending DDDS message towards SgNB.CU-UP across the X2-U interface. SgNB.CU-UP also ensures that it sends data for Class B SN terminated bearer towards MeNB.DU across the X2-U interface such that it does not violate the upper threshold which is defined across X2- U interface for this split bearer.

[0160] In addition, SgNB.DU continues to send DDDS towards SgNB.CU-UP acrossF1-U interface for Class A and Class B SN terminated split bearers.

[0161] IMPLIMENATION ID: AID related Enhancements

[0162] To assist SgN.DU take splitting decision for each Class B split bearer ‘s’,MeNB.DU sends Assistance Information Data (AID) to SgNB.DU over the D2 interface and provides radio information of MeNB to SgNB.DU. As in FIG.16, this also includes Delay DU Result and Congestion Information.

[0163] With existing methods, MeNB.DU sends AID to SgNB.CU-UP across the X2-Uinterface to help SgNB.CU-UP take splitting decisions. With the method specified here, MeNB.DU sends AID to SgNB.DU across the D2-U interface to help SgNB.DU take splitting decision for Class B split bearer, and MeNB.DU sends AID to SgNB.CU-UP across the X2-U interface to help SgNB.CU-UP take splitting decision for Class A and Class B split bearers.

[0164] For the scenario where DL traffic for Class B split bearer is sent fromSgNB.CU-UP to SgNB.DU only via F1-U interface (and no DL traffic for this bearer is sent via X2-U to MeNB.DU), DL traffic for this Class B split bearer is split at SgNB.DU and sent to UE using the 5G NR air-interface and to MeNB.DU using the D2 interface (and eventually to UE using the 4G LTE air-interface from MeNB.DU). In this case, MeNB.DU sends AID comprising MeNB.DU congestion and delay information to SgNB.DU across the DU-U interface in the method specified here. In addition, this method provides an option to allow SgNB.DU to communicate congestion and delay information for MeNB.DU to SgNB.CU-UP via the F1-U interface. Thus, SgNB.CU-UP can receive AID from SgNB.DU sent across the F1- U interface and AID from MeNB.DU sent across D2-U and F1-U interfaces. This allows SgNB.CU-UP to get more up-to-date congestion and delay information for MeNB.DU via the D2-U and F1-U interfaces.

[0165] IMPLIMENATION IE: Selection of Class B split bearers

[0166] In the method specified here, DRBs carrying traffic for applications with highreliability and low latency requirements ) can be classified as Class B split bearer and DRBs carrying data for other applications (such as web browsing) can be classified as Class A split bearer. In addition, SgNB.CU-UP (for SN terminated bearers) keeps monitoring delay and congestion information received as part of AID from MeNB.DU and from SgNB.DU, and uses this to decide whether to classify a new split bearer as Class B or Class A split bearer.

[0167] For example, if SgNB.CU-UP finds higher congestion being indicated bySgNB.DU, it can reduce the number of split bearers which it is classifying as Class B split bearers. This can be used to reduce the downlink traffic to SgNB.DU as SgNB.CU-UP can start sending higher amount of DL traffic to MeNB.DU via X2-U for some such bearers.

[0168] IMPLIMENATION II – Optimized UL Split Bearer Method

[0169] As discussed earlier, UE sends UL traffic across 4G LTE and 5G NR air-interfaces after splitting UL traffic. It is eventually communicated to SgNB.CU-UP via the X2-U and F1-U interfaces as shown in FIG.24.

[0170] In the method described here, uplink data received at MeNB.DU for Class Bsplit bearer is routed via D2-U (i.e. from MeNB.DU to SgNB.DU) and F1-U (i.e. from SgNB.DU to SgNB.CU-UP) interfaces to SgNB.CU-UP. For Class A split bearer, uplink data is routed via X2-U (i.e. from MeNB.DU to SgNB.CU-UP) and F1-U (i.e. from SgNB.DU to SgNB.CU-UP) interface. This is shown in FIG.31 for UL traffic (and the corresponding DL scenario was shown in FIG.25).

[0171] In another method, uplink data received at MeNB.DU for Class B split beareris split at MeNB.DU. Part of it is sent to SgNB.CU-UP across the X2-U interface, and another part to SgNB.DU via the D2-U interface (and eventually to SgNB.CU-UP across the F1-U interface) as shown in FIG.31. Data rate (or volume) of UL traffic for Class B split bearer which is sent from MeNB.DU to SgNB.CU-UP is upper bounded by a pre-specified or a dynamically computed threshold.

[0172] MeNB.DU keeps collecting information for UL delay across the X2-U interface,UL delay across the D2-U interface, UL delay across the F1-U interface and UL congestion at SgNB.DU and uses this to classify each bearer as Class A or Class B split bearer. Split bearers carrying traffic for applications needing higher reliability and / or lower latency can be classified as Class B split bearers and routed along a path which results in higher reliability and / or lower delay for packets belonging to this bearer.

[0173] In addition to delay and / or reliability, other performance measures (such asjitter and throughput) can also be used along the D2-U, X2-U, F1-U and other interfaces to select an optimal path (e.g. with lower delay, lower jitter, higher reliability or lower delay, higher throughput and higher reliability).

[0174] Methods specified here result in lower delay (and higher reliability asneeded) for split bearers in the DL and the UL direction for the EN-DC architecture. Though these methods are described for SN terminated split bearers, these are also applicable for MN terminated split bearers. Methods specified here are also applicable to Multi-RAT Dual Connectivity (MR-DC) architectures and (Single-RAT) Dual Connectivity architectures.

[0175] Latency and reliability for various interfaces (e.g. X2-U, F1-U and the like)and associated paths can vary due to nature of connectivity technologies used and / or due to congestion over these interfaces. This disclosure analyzes behavior of different interfaces and specifies solutions to improve performance of DL and UL split bearer operation in the EN-DC / NSA architectures. It specifies methods where 4G DU and 5G DU coordinate with each other to help SgNB.CU-UP take more effective DL traffic splitting decisions. It also provides methods to improve performance in the UL direction. Methods specified here are also applicable to Multi-RAT Dual Connectivity (MR-DC)_and (Single- RAT) Dual Connectivity architectures.

[0176] MeNB initiated SgNB release for Class B split bearer

[0177] MeNB can monitor various performance measures and initiate release ofSgNB. For this MeNB sends ‘SgNB Release Request’ to SgNB.CU-CP. Next, SgNB.CU-CP informs SgNB.CU-UP about this across the E1 interface.

[0178] SgNB.CU-UP starts buffering downlink packets that it is receiving from 4GEPC and stops the DL splitting operation. Once it has sent all the buffered data to SgNB.DU across F1-U, it initiates tearing down GTP-U tunnel for this bearer across the F1-U interface and informs SgNB.DU about this. On receipt of above message for a Class B split bearer, SgNB.DU also stops splitting DL data for Class B split bearer, sends all the buffered data toMeNB.DU across D2-U interface (and eventually to the UE across the 4G air-interface) or to the UE across the 5G NR air-interface from SgNB.DU.

[0179] SgNB.DU initiates tearing down of GTP-U tunnel across the D2-U interface forthis bearer. After SgNB.DU has sent all the data for this bearer, it informs SgNB.CU-UP about this and removes state of this bearer from SgNB.DU. Next, SgNB.CU-UP informs SgNB.CU-CP about this across E1 interface removes state of this bearer from SgNB.CU-UP. SgNB.CU-CP sends ‘SgNB Release Request Acknowledge’ message to MeNB.CU.

[0180] For UL, MeNB also stops splitting UL traffic at MeNB.DU as part of the aboveprocess and stops communicating UL data across the D2-U interface to SgNB.DU.

[0181] MeNB also informs UE via RRCConnectionReconfiguration message. Otherparts of the procedure continue as per the MN initiated SN release procedure given in 3GPP TS 37.340.

[0182] Reference is made to Third Generation Partnership Project (3GPP), O-RANAlliance 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), O-RAN Alliance and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions.3GPP, O-RAN and IETF technical specifications (TS), standards (including proposed standards), technical reports (TR), RFCs and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow. 3GPP TS 23.501 V 18.1.02024-06-26 3GPP TS 38.300 V 18.1.04-03-2024 3GPP TS 38.401 V 18.1.02024-03-29 3GPP TS 38.473 version 18.1.02024-03-293GPP TS 38.425 version 18.0.02024-01-12 3GPP TS 37.304 version 18.1.02024-04-03 O-RAN Near-RT-Architecture 6.0, O-RAN.WG3.RICARCH-R003-v06.00, R003, June 2024 O-RAN E2 Service Model (E2SM) KPM 5.0, O-RAN.WG3.E2SM-KPM-R003-v05.00, R003, June 2024 O-RAN E2 Application Protocol (E2AP) 5.0, O-RAN.WG3.E2AP-R003-v05.00, R003, February 2024 O-RAN A1 Interface: Application Protocol 4.02, O-RAN.WG2.A1AP v04.02, R003, June 2024

[0183] Abbreviations5GC: 5G Core Network 5G NR: 5G New Radio 5QI: 5G QoS Identifier ACK: Acknowledgement AI: Artificial Intelligence AI / ML (or AIML): Artificial Intelligence and Machine Learning AID: Assistance Information Data AM: Acknowledged Mode APN: Access Point Name ARP: Allocation and Retention Priority BLER: Block Error Rate BO: Buffer Occupancy BS: Base StationBSR: Buffer Status Report CMS: Centralized (or Configuration) Management System CNN: Convolution Neural Network CP: Control Plane CSI: Channel State Information CU: Centralized Unit CU-CP: Centralized Unit – Control Plane CU-UP: Centralized Unit – User Plane D2: DU-DU interface D2-U: D2-User Plane (for D2 interface) D2-C: D2-Control Plane (for D2 interface) D2AP: D2 Application Protocol (running over the D2-C interface) DBS: Desired Buffer Size DL: Downlink DDDS: DL Data Delivery Status DDR: Desired Data Rate DNN: Data Network Name DNN: Deep Neural Network DQN: Deep Q Network DRB: Data Radio Bearer DU: Distributed Unit eNB: evolved NodeB (or eNodeB) eNodeB: Evolved NodeB (or eNB) EPC: Evolved Packet CoreEN-DC: E-UTRAN New Radio Dual Connectivity (E-UTRA-NR Dual Connectivity) F1-U: F1-User Plane F1-C: F1-Control Plane F1AP: F1 Application Protocol GBR: Guaranteed Bit Rate gNB: gNodeB GTP-U: GPRS Tunnelling 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 LESS: Low Energy Scheduler Solution LSTM: Long Short-Term Memory LTE: Long Term Evolution MAC: Medium Access Control MDP: Markov Decision Process MCG: Master Cell Group MeNB: Master eNB (or Master eNodeB) MeNB.DU: DU of MeNB MeNB.CU-CP: CU-CP of MeNB MeNB.CU-UP: CU-UP of MeNB MIB: Master Information BlockML: Machine Learning MN: Master Node MR-DC: Multi-RAT Dual Connectivity MSS: Maximum Segment Size MU-MIMO: Multi-User Multiple-Input Multiple-Output NACK: Negative Acknowledgement NAS: Non-Access Stratum NG-RAN: Next Generation Radio Access Network NR-U: New Radio – User Plane NSI: Network Slice Instance NSSI: Network Slice Subnet Instance NWDAF: Network Data Analytics Function O-RAN: Open Radio Access Network OAM: Operations, Administration Maintenance PDB: Packet Delay Budget PDCP: Packet Data Convergence Protocol PDU: Protocol Data Unit PER: Packet Error Rate PF: Proportional Fair PHY: Physical Layer PRB: Physical Resource Block QCI: QoS Class Identifier QFI: QoS Flow Identifier QoS : Quality of ServiceRAN: Radio Access Network RAT: Radio Access Technology RB: Resource Block RDI: Reflective QoS Flow to DRB Indication RL: Reinforcement Learning RLC: Radio Link Control RLC-AM: RLC Acknowledged Mode RLC-UM: RLC Unacknowledged Mode RNN: Recurrent Neural Networks RQI: Radio Quality Indication RRC: Radio Resource Control RRM: Radio Resource Management RTP: Real-Time Transport Protocol RTCP: Real-Time Transport Control Protocol RU: Radio Unit SCG: Secondary Cell Group SCTP: Stream Control Transmission Protocol SD: Slice Differentiator SDAP: Service Data Adaptation Protocol SDU: Service Data Unit SgNB: Secondary gNB (or Secondary gNodeB) SgNB.CU: CU of SgNB SgNB.CU-CP: CU-CP of SgNB SgNB.CU-UP: CU-UP of SgNBSgNB.DU: DU of SgNB SIB: System Information Block SLA: Service Level Agreement SN: Secondary Node S-NSSAI: Single Network Slice Selection Assistance SST: Slice / Service Type SU-MIMO: Single User Multiple-Input Multiple-Output TB: Transport Block TCP: Transmission Control Protocol TEID: Tunnel Endpoint Identifier UE: User Equipment UP: User Plane UL: Uplink UM: Unacknowledged Mode UPF: User Plane Function X2-U: X2-User Plane X2-C: X2-Control Plane X2AP: X2 Application Protocol

Claims

CLAIMS 1. A method for a Radio Access Network system comprising: configuring a 4G Master eNodeB distributed unit DU (MeNB.DU) and a 5G gNB distributed unit DU (SgNB.DU) of a base station to coordinate over a D2 interface to have the RAN optimize performance of uplink (UL) and downlink (DL) split bearers for user equipment (UE); measuring, by a SgNB Centralized Unit – User Plane (SgNB.CU-UP): an average latency over an F1-U interface for communication between the SgNB.CU-UP and the SgNB.DU, and an X2-U interface for communication between the SgNB.CU-UP; and an average Packet Error Rate (PER) over mid-haul paths of the F1-U interface and the X2-U interface; determining, by the SgNB.CU-UP, a better performing mid-haul path from one ofthe mid-haul paths of the F1-U and the X2-U; classifying, by a traffic splitting module at the SgNB.CU-UP, Data Radio Bearer (DRBs) into two classes denoted as Class A and Class B; continuing, by the traffic splitting module, a traffic split for split bearers for the Class A split bearers. choosing, by the SgNB.CU-UP, the better performing mid-haul path for the Class B split bearers.

2. The method of claim 1, further comprising: for the Class A split bearers, continuing, at the traffic splitting module at the SgNB.CU-UP, to split DL traffic for SN terminated split bearers along an ‘SgNB.CU-UP to MeNB.DU’ path and an ‘SgNB.CU-UP to SgNB.DU’ path.

3. The method of claim 1, further comprising: receiving (New Radio) NR Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDUs) at the SgNB-DU for each Class A bearer and Class B bearer, a DL splitbearer from the SgNB.CU-UP in corresponding Radio Link Control (RLC) (Service Data Unit SDU) queues; taking, by a traffic splitting module at the SgNB-DU, traffic splitting decisions for incoming the NR PDCP PDUs for each Class B split bearer at the SgNB-DU, deciding, by the traffic splitting module at the SgNB-DU, whether to let a given RLC SDU stay in a NR RLC SDU queue at the SgNB.DU or route the RLC SDU towards a MeNB.DU, and if so, routing the NR PDCP PDU a corresponding Long Term Evolution (LTE) RLC queue of the split bearer at the MeNB.DU via the D2 interface; and considering, by an NR MAC scheduler at the SgNB.DU, only the RLC SDUs or NR PDCP PDUs for the Class B split bearers that have been decided to be sent to UE after taking traffic splitting decision at the SgNB-DU, wherein other NR PDCP PDUs that are sent to MeNB.DU via the D2 interface are scheduled via an LTE MAC scheduler at the MeNB.DU.

4. The method of claim 1, further comprising: establishing an upper threshold bound for a data rate of traffic to be sent via t less preferred path for the Class B split bearer , wherein DL data traffic for the Class B split bearer is sent over an X2-U path is bound the upper threshold bound.

5. The method of claim 1, further comprising: sending, by the MeNB.CU-CP, an ‘SgNB Addition Request’ including an indicationthat it is Class B or Class A split bearer to SgNB.CU-CP; processing, by the SgNB.CU-CP, an ‘SgNB Addition Request’ received from MeNB; and establishing a UE context at the SgNB-DU and a GPRS Tunnelling Protocol – User Plane (GTP-U) tunnel across an D2-U interface to carry traffic between SgNB.DU and MeNB.DU for the Class B split bearer.

6. The method of claim 1, further comprising: sending, by the MeNB.DU, the Downlink (DL) Data Delivery Status (DDDS) to the SgNB.CU-UP for Class A SN terminated split bearers and the DDDS to the SgNB.DU for Class B SN terminated split bearers.

7. The method of claim 1, further comprising: sending, by the MeNB.DU, Assistance Information Data (AID) to the SgNB.DU and providing radio information of the MeNB to the SgNB.DU.

8. The method of claim 7, further comprising: classifying DRBs carrying traffic for applications with low delay and / or high reliability applications as the Class B split bearer, wherein the SgNB.CU-UP is configured to keep monitoring delay, packet error rate, and congestion information received as part of AID from the MeNB.DU and from the SgNB.DU and uses this to decide whether to classify a new split bearer as the Class B split bearer or the Class A split bearer.

9. The method of claim 1, wherein the method further comprises: receiving uplink data at the MeNB.DU for the Class B split bearer; routing the uplink data for the Class B split bearer to the SgNB.CU-UP via the D2- U interface from the MeNB.DU to the SgNB.DU and the F1-U interface from SgNB.DU to the SgNB.CU-UP; receiving uplink data at the MeNB.DU for the Class A split bearer; and routing the uplink data for the Class A split bearer to the SgNB.CU-UP via the X2-U interface from the MeNB.DU to the SgNB.CU-UP and the F1-U interface from the SgNB.DU to the SgNB.CU-UP.

10. The method of claim 1, further comprising: initiating, at the MeNB.DU, a release of the SgNB for the Class B split bearer; and tearing down a GPRS Tunnelling Protocol – User Plane (GTP-U tunnel) for the Class B split bearer; and releasing the SgNB.

11. The method of claim 10, further comprising: sending an SgNB Release Request to the SgNB.CU-UP; informing, by the SgNB.CU-CP, the SgNB.CU-UP about the SgNB Release Request;buffering, by the SgNB.CU-UP, data including 4G EPC downlink packets and stopping the DL splitting; sending by the SgNB.CU-UP, all the buffered data to the SgNB.DU, tearing down the GTP-U tunnel across the F1-U interface for the Class B split bearer, and messaging the SgNB.DU; on receipt of the message by the SgNB.DU, stopping, by the SgNB.DU, splitting DL data for the Class B split bearer and sending the buffered data to the MeNB.DU; initiating, by the SgNB.DU tearing down of the GTP-U tunnel across a D2-U interface for the Class B split bearer; after the SgNB.DU has sent all the data for the bearer, informing SgNB.CU-UP and removing a state of the Class B split bearer from SgNB.DU; informing, by the SgNB.CU-UP, the SgNB.CU-CP across the E1 interface and removing the state of the Class B split bearer from SgNB.CU-UP; and sending, by the SgNB.CU-CP, a SgNB Release Request Acknowledgment to the MeNB.CU.

12. A Radio Access Network system comprising: a 4G Master eNodeB distributed unit DU (MeNB.DU) and a 5G gNB distributed unit DU (SgNB.DU) of a base station configured to coordinate over a D2 interface to improve performance for uplink (UL) and downlink (DL) split bearers; a SgNB Centralized Unit – User Plane (SgNB.CU-UP) configured to measure: an average latency over an F1-U interface for communication between the SgNB.CU-UP and the SgNB.DU, and an X2-U interface for communication between the SgNB.CU-UP; and an average Packet Error Rate (PER) over mid-haul paths of the F1-U interface and the X2-U interface; the SgNB.CU-UP comprising a traffic splitting module, the SgNB CU-UP being configured to determine, one of the mid-haul paths of the F1-U and the X2-U are a better performing mid-haul path; the traffic splitting module at the SgNB.CU-UP being configured to:classify Data Radio Bearer (DRBs) into two classes denoted as Class A and Class B; continue a traffic split for split bearers for the Class A split bearers; and choose the better performing mid-haul path for the Class B split bearers.

13. The system of claim 12, wherein the traffic splitting module at the SgNB.CU-UP is configured to, for the Class A split bearers, split DL traffic for SN terminated split bearers along an ‘SgNB.CU-UP to MeNB.DU’ path and an ‘SgNB.CU-UP to SgNB.DU’ path.

14. The system of claim 12, wherein the SgNB-DU is configured to receive (New Radio) NR Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDUs) for each Class A bearer and Class B bearer and a DL split bearer from the SgNB.CU-UP in corresponding Radio Link Control (RLC) (Service Data Unit SDU) queues; and the SgNB-DU comprises an SgNB-DU traffic splitting module configured to: take traffic splitting decisions for incoming the NR PDCP PDUs for each Class B split bearer at the SgNB-DU; decide whether to let a given RLC SDU stay in a NR RLC SDU queue at the SgNB.DU or route the RLC SDU towards a MeNB.DU, and if so, route the NR PDCP PDU to a corresponding Long Term Evolution (LTE) RLC queue of the split bearer at the MeNB.DU via the D2 interface; and the SgNB-DU comprises an NR MAC scheduler configured to consider only the RLC SDUs or NR PDCP PDUs for the Class B split bearers that have been decided to be sent to UE after the traffic splitting decision at the SgNB-DU is taken, wherein other NR PDCP PDUs that are sent to MeNB.DU via the D2 interface are scheduled via an LTE MAC scheduler at the MeNB.DU. .

15. The system of claim 12, wherein the system is configured with an upper threshold bound for a data rate of traffic to be sent via the less preferred path for the Class B split bearer , and wherein DL data traffic for the Class B split bearer is sent over an X2-U path is bound the upper threshold bound.

16. The system of claim 1, wherein: the MeNB.CU-CP is configured to send an ‘SgNB Addition Request’ to SgNB.CU- CP; the SgNB.CU-CP is configured to send an ‘SgNB Addition Request’ received from MeNB; and the SgNB.DU is configured to establish a UE context and a GPRS Tunnelling Protocol – User Plane (GTP-U) tunnel across an D2-U interface to carry traffic between SgNB.DU and MeNB.DU for the Class B split bearer.

17. The system of claim 12, wherein: the MeNB.DU is configured to send a Downlink (DL) Data Delivery Status (DDDS) to the SgNB.CU-UP for Class A SN terminated split bearers and the DDDS to the SgNB.DU for Class B SN terminated split bearers; the MeNB.DU is configured to send Assistance Information Data (AID) to the SgNB.DU and providing radio information of the MeNB to the SgNB.DU; and the SgNB.CU-UP is configured to keep monitoring delay and congestion information received as part of the AID from the MeNB.DU and from the SgNB.DU and uses this to decide whether to classify a new split bearer as the Class B split bearer or the Class A split bearer.

18. The system of claim 12, wherein the MeNB.DU is configured to: receive uplink data for the Class B split bearer and route the uplink data for the Class B split bearer to the SgNB.CU-UP via the D2-U interface from the MeNB.DU to the SgNB.DU and the F1-U interface from SgNB.DU to the SgNB.CU-UP; receive uplink data at the MeNB.DU for the Class A split bearer; and route the uplink data for the Class A split bearer to the SgNB.CU-UP via the X2-Uinterface from the MeNB.DU to the SgNB.CU-UP and the F1-U interface from the SgNB.DU to the SgNB.CU-UP.

19. The system of claim 1, wherein:the MeNB.DU is configured to send a release of the SgNB for the Class B split bearer; and the system is configured in response to tear down a GPRS Tunnelling Protocol – User Plane (GTP-U tunnel) for the Class B split bearer and release the SgNB.

20. The method of claim 19, wherein: the MeNB.DU is configured to send an SgNB Release Request to the SgNB.CU-UP; the SgNB.CU-CP is configured to inform the SgNB.CU-UP about the SgNB Release Request; the SgNB.CU-UP is configured to buffer data including 4G EPC downlink packets and stopping the DL splitting; the SgNB.CU-UP is configured to send the buffered data to the SgNB.DU, tear down the GTP-U tunnel across the F1-U interface for the Class B split bearer, and message the SgNB.DU; on receipt of the message by the SgNB.DU, the SgNB.DU is configured to stop splitting DL data for the Class B split bearer and send the buffered data to the MeNB.DU; the SgNB.DU is configured to tear down of the GTP-U tunnel across a D2-U interface for the Class B split bearer, the SgNB.DU is configured to inform the SgNB.CU-UP and remove a state of the Class B split bearer from SgNB.DU after the SgNB.DU has sent all the data for the Class B split bearer, the SgNB.CU-UP is configured to inform the SgNB.CU-CP across the E1 interface and remove the state of the Class B split bearer from SgNB.CU-UP; and the SgNB.CU-CP is configured to send a SgNB Release Request Acknowledgment to the MeNB.CU.

Images