Coptimizing radio resources management in high load o-ran networks

Abstract

Described are a system, apparatus and method for optimized radio resource management (RMM) in a high load cell in the presence of a high data rate low latency application comprising an RMM Optimization module configured to compute a scheduling metric for each logical channel (LC) m, corresponding to a Data Radio Bearer (DRB), of a plurality of logical channels P LC,m with an additional boost, conditionalBoost LC,m .

Description

COPTIMIZING RADIO RESOURCES MANAGEMENT IN HIGH LOAD O-RAN NETWORKS BACKGROUND OF THE DISCLOSURE 1. Field of the Disclosure

[0001] The present disclosure relates to Open Radio Access Network (O-RAN)wireless networks and relates more particularly to optimized radio resource management (RRM) policies in the presence of high data rate low latency (e.g. AR / VR / XR) traffic in O- RAN Networks. 2. Description of Related Art

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

[0003] In an embodiment, there is a method for optimized radio resourcemanagement in high load cell in the presence of a high data rate low latency application comprising: computing a scheduling metric for each logical channel (LC) m, corresponding to a Data Radio Bearer (DRB), of a plurality of logical channels , with an additionalboost,,^,= , + , ;using a first condition to check if an elapsedSchedInterval for LC m corresponding to UE h is above a pre-defined threshold elapsedThreshold(QI(m)), wherein QI(m) denotes the Quality of Service (QoS) Identifier for LC m;determining if a second conditon QDelayRLC is greater than a pre-defined threshold qdelayThreshold(QI(m)), wherein QDelayRLC is a Queuing delay at an RLC; and when both the first condition and the second condition are true for LC m, setting a conditioalBoostLC above a pre-specified threshold value.

[0004] The method can further comprise: generating a candidate set of LCs forwhich the first condtion and the second condition are true, wherein the candidate set of LCs in a cell at time t is denoted as candidateElapsedSet(t).

[0005] The method can further comprise: for each LC m which is in the candidate setof LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), the conditionalBoostLC,mis chosen as( ) for each such LC m while computing the scheduling metric for LC m suchthat ,= ( )if LC m is in the candidateElapsedSet(t) at time t and if the number of LCs in the candidateElapsedSet(t) < numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

[0006] The method can further comprise:for each LC m which is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), the conditionalBoostLC,mis chosen as for each such LC m while computing the scheduling metric for LC m such that=if LC m is in the candidateElapsedSet(t) at time t and if the number of LCs in the candidateElapsedSet(t) numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

[0007] The method can further comprise:communicating, from a DU to an RRM Optimization module, scheduling metric parameters for calculating the additional boost comprising: a lastScheduledTime(h,m;t) when a DRB m corresponding to a UE h was scheduled for service by a scheduler running at DU, wherein “t” is the current time at which the report is sent from the DU to the Near-RT-RIC; the candidateElapsedSet(t); a QoS class for each LC in candidateElapsedSet(t); a Buffer occupancy for each DRB m in candidateElapsedSet(t); a waiting time of a first number of packets from an RLC queue for each LC in the candidateElapsedSet(t); and a Cell load (e.g. PRB utilization); selecting, by the RMM Optimization module, the LCs to be given the additional boost; and communicating, by the RMM Optimization module to the DU, the identity of the selected LCs to the DU along with conditionalBoostLC. The RRM Optimization module can be located at a Near-RT-RIC. The method can further comprise: enhancing a RIC SUBSCRIPTION REQUEST to allow Near-RT-RIC to subscribe to the scheduling metric parameters from the DU; enhancing an RIC INDICATION message to communicate thescheduling metric parameters from the DU to the Near-RT-RIC; and enhancing an RIC CONTROL message to communicate the identity of the selected LCs alongwith , from the Near-RT-RIC to the DU.

[0008] The RRM Optimization module can be located at a CU-CP or CU-UP. Then theRRM Optimization module is located at a CU-CP, an F1 Application Protocol running across an F1-C interface can be enhanced to communicate the scheduling metric parameters for the additional boost from DU to CU-CP, and the method further can comprise communicating, by the CU-CP, the identity of the selected LCs to the DU along with the , over the F1-C interface.

[0009] In an implimentation, a system for optimized radio resource management inhigh load cell in the presence of a high data rate low latency application comprises an RRM Optimization module configured to: compute a scheduling metric for each logical channel (LC) m, corresponding to a Data Radio Bearer (DRB), of a plurality of logical channels , with an additionalboost,,^,= , + , ;for LC m corresponding to UE h is above a pre-defined threshold elapsedThreshold(QI(m)), wherein QI(m) denotes the Quality of Service (QoS) Identifier for LC m; determine if a second conditon QDelayRLC is greater than a pre-defined threshold qdelayThreshold(QI(m)), wherein QDelayRLC is a Queuing delay at an RLC; and when both the first condition and the second conditiion are true for LC m, set a , above a pre-specified threshold value.

[0010] The system RRM can further be configured to generate a candidate set of LCsfor which the first condtion and the second condition are true, wherein the candidate set of LCs in a cell at time t is denoted as candidateElapsedSet(t).

[0011] The RRM Optimization module can be further configured: for each LC mwhich is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), tochoose the conditionalBoostLC,m as ( ) for each such LC m while computing thescheduling metric for LC m such that ,= ( )if LC m is in theof LCs in the candidateElapsedSet(t) < numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

[0012] The RRM Optimization module can furtherbe configured: for each LC mwhich is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), to choose the conditionalBoostLC,m as for each such LC m while computing the scheduling metric for LC m such,=m (t) at time t and if the number of LCs in the candidateElapsedSet(t) numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

[0013] The RRM Optimization module can be further configured to:receive, from a distributed unit (DU), scheduling metric parameters for calculatingthe additional boost comprising: a lastScheduledTime(h,m;t) when a DRB m corresponding to a UE h was scheduled for service by a scheduler running at DU, wherein “t” is the current time at which the report is sent from the DU to the Near-RT-RIC; the candidateElapsedSet(t); a QoS class for each LC in candidateElapsedSet(t); a Buffer occupancy for each DRB m in candidateElapsedSet(t); a waiting time of a first number of packets from an RLC queue for each LC in the candidateElapsedSet(t); a Cell load (e.g. PRB utilization); select the LCs to be given the additional boost; and communicate, to the DU, the identity of the selected LCs to the DU along with conditionalBoostLC.

[0014] The RRM Optimization module can be located at a Near-RT-RIC. The systemcan be configured with: an enhanced RIC SUBSCRIPTION REQUEST configured to allow Near-RT-RIC to subscribe to the scheduling metric parameters from the DU; an enhanced RIC INDICATION message configured to communicate the scheduling metric parameters from the DU to the Near-RT-RIC; and an enhanced RIC CONTROL message configured to communicate the identity of the selected LCs along with the,from the Near-RT-RIC to the DU.

[0015] The RRM Optimization module can be located at a CU-CP or CU-UP. The RRMOptimization module can be located at a CU-CP, and an F1 Application Protocol running across an F1-C interface can enhanced to communicate the scheduling metric parameters for the additional boost from DU to CU-CP, and the RRM Optimization Module can furtherbe configured to communicate, by the CU-CP, the identity of the selected LCs to the DU along with the,over the F1-C interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1a is a block diagram of a system architecture.

[0017] FIG. 1b shows an example of a User Plane Stack.

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

[0019] FIG. 3 shows an example of high-level NG-RAN including a gNB CU and DU.

[0020] FIG.4 shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 5G gNB.

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

[0022] FIG. 6 shows block diagram illustrating UL (Uplink) L2 Structure.

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

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

[0025] FIG. 8b shows an example of an O-RAN flow.

[0026] FIG. 9 illustrates a PDU Session architecture.

[0027] FIG. 10 illustrates a PDU Session architecture comprising of multiple DRBsand multiple QoS Flows.

[0028] FIG. 11 illustrates an architecture for Resource Management (RRM) forconnecting UE to a network va RU with a MAC Scheduler.

[0029] FIG. 12 illustrates a method for computing a scheduling metric with anadditional factor for a logical channel.

[0030] FIG. 13 illustrates a method for computing a scheduling metric with anadditional factor for a logical channel at an RRM-Optimization module. DETAILED DESCRIPTION

[0031] RAN Architecture

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

[0033] In the following sections, overview of Next Generation Radio Access Network(NG-RAN) architecture and 5G New Radio (NR) stacks will be discussed.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 Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers originate in the UE 101 and are terminated in the gNB 102 on the network side.

[0034] 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 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.

[0035] 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.

[0036] 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 includes 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 include 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.

[0037] In this section, an overview of Layer 2 (L2) of 5G NR will be provided 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 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 sublayersupports 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).

[0038] 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.8a.

[0039] As shown in FIG. 8a, the CU (shown split as O-CU-CP 801a and O-CU-UP801b) 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. 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).

[0040] A cell site can comprise multiple sectors, and each sector can supportmultiple cells. For example, one site can comprise three sectors and each sector cansupport eight cells (with each cell being on a different frequency band in a given sector). One CU-CP (CU-Control Plane) can support multiple DUs and thus multiple cells. For example, a CU-CP can support 500 cells and around 100,000 User Equipments (UEs). Each UE can support multiple Data Radio Bearers (DRBs) and there can be multiple instances of CU-UP (CU-User Plane) to serve these DRBs. For example, each UE can 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).

[0041] The DU can be located 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 tens of kilometers apart. 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 (Radio Unit) (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.

[0042] 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.8a) using the A1 interface. The applications that are hosted at non-RT-RIC are called rApps. Also shown in FIG.8a 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).

[0043] As in FIG. 8b, E2 node (which is DU or CU) and Near-RT-RIC establish E2session using E2 SETUP REQUEST and E2 SETUP RESPONSE. Near-RT-RIC can subscribe tocertain 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 can 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.8b. 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 takes action as asked by the Near-RT-RIC.

[0044] In this section, PDU sessions, DRBs, and Quality of Service (QoS) flows will bediscussed. 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 includes: 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.9 illustrates an example PDU session (in accordance with 3GPP TS 23.501) including multiple DRBs, where each DRB can include multiple QoS flows. In FIG.9, 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.

[0045] The following should be noted for 3GPP 5G network architecture, which isillustrated in FIG.10 (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.11 (in the context of RadioResource 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.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 TEID (Tunnel Endpoint Identifier). 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. 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. 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.11. Separate logical queues can exist in DU for packets that are to be retransmitted to UE.

[0046] 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.

[0047] 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 widnow of 2000 ms. Conversational voice falls under this catogery. 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 catogery.Table 1

[0048] In this section, Radio Resource Management (RRM) will be discussed (a blockdiagram for an example RRM with a MAC Scheduler is shown in FIG.11). L2 methods (suchas 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 using one of the following (or some other variant) for a LC sending data in the downlink direction: PLC = W5QI*P5QI+ WGBR*PGBR+WPDB* PPDB +WBO*PBO + WPF*PPF, or PLC= (W5QI*P5QI+ WPF*PPF) * maximum (WGBR*PGBR, WPDB* PPDB) + WBO*PBO, or PLC= (W5QI*P5QI+ WPF*PPF) + maximum (WGBR*PGBR, WPDB* PPDB) + WBO*PBO,or PLC= (W5QI*P5QI) *(WPF*PPF) * (WGBR*PGBR)*(WPDB* PPDB) Once one of the above methods is used to compute scheduling priority of a logical channel corresponding to a UE in a cell, the same method is used for all other UEs and these scheduling priorities are used to determine the resources to be allocated to each LC in each cell.

[0049] In the above expressions, the parameters are defined as follows:

[0050] a) P5QI is the priority metric corresponding to the QoS class (5QI) of thelogical channel. Incoming traffic from a DRB is mapped to Logical Channel (LC) at RLC level. P5QIis a function of the default 5QI priority value, Priority5QI, of a QoS flow that is mapped to the current LC. The lower the value of Priority5QIthe higher the priority of the corresponding QoS flow. For example, Voice over New Radio (VoNR) (with 5QI of 1) will have a higher P5QIcompared to web browsing (with 5QI of 9).

[0051] b) PGBR is the priority metric corresponding to the target bit rate of thecorresponding logical channel. The GBR metric PGBR represents the fraction of data that must be delivered to the UE within the time left in the current averaging window Tavg_win (as per 5QI table, default is 2000 msec.) to meet the UE’s GBR requirement. PGBR is calculated as follows: PGBR = remData / targetDatawhere targetData is the total data bits to be served in each averaging window Tavg_win in order to meet the GFBR (Guaranteed Flow Bit Rate) of the given QoS flow; remData is the amount of data bits remaining to be served within the time left in the current averaging window; PGBRis reset to 1 (or some other suitable value) at the start of each averaging window Tavg_win, and should go down to 0 towards the end of this window if the GBR criterion is met; and PGBR= 0 for non-GBR flows.

[0052] For GBR DRB m corresponding to UE h, remData at time t (or in the slot t) isdenoted as remData(h, m; t) and targetData at time t is denoted as targetData(h, m; t).

[0053] c) PPDB is the priority metric corresponding to the packet delay budget at DUfor the corresponding logical channel. PPDB = 1 if PDBDU<=QDelayRLC and PPDB = 1 / (PDBDU- QDelayRLC) if PDBDU> QDelayRLC where both PDBDU(Packet Delay Budget at DU) and RLC Queuing delay, QDelayRLC, are measured in terms of slots (scheduling). QDelayRLC = (t – TRLC) is the delay of the oldest RLC packet in the QoS flow that has not been scheduled yet, and it is calculated as the difference in time between the SDU insertion in RLC queue to current time where t := current time instant, TRLC:= time instant when oldest SDU was inserted in RLC. Packet delay budget at DU is denoted as PDBDU.

[0054] Waiting time for HoL RLC packet for DRB m corresponding to UE h at time t(i.e. in slot t) is denoted as QDelayRLC(h, m; t).

[0055] d) PPF is the priority metric corresponding to proportional fair metric of theUE. PPF is the PF Metric, calculated on a per UE basis as =wherer: It is the UE’s achievable data rate. DU considers CSI (Channel Status Information) which also includes CQI (Channel Quality Indication), reported by UE to compute this; Ravg = a.Ravg + (1-a).b , UE’s average throughput, where b>=0 is the number of bits scheduled in current TTI (Transmission Time Interval) and 0 < a <= 1 is the IIR filter coefficient; and are configurable parameters. For example, if one sets =1 and = 0,the priority metric, PPF, works in greedy way and favors UEs in good channel conditions. This helps to improve cell throughput but need not be fair to individual logical channels and some of these LCs may not meet their QoS requirements. For some existing systems, and are in the range of 0 to 1. Allow to be upper bounded by _max (and lower bounded by zero). As a LC is eventually selected by the overall scheduling priority of a logical channel (PLC) which has multiple other factors (and not only the PPF metric), allow _max to be even higher than one (for example, _max = 1.2) to help design and enforce various type of policies (and associated service level agreements at per-cell, per-DU andper-logical channel level). Similarly, , is upper bounded by _ , and lower bounded byzero.

[0056] For UE h, achievable data rate in slot t is denoted as r(h; t) and this isinflucned by CSI reported by UE h for slot t which is denoted as CSI(h; t). Also, UE’s weighted average throughput for UE h at the beginning of slot t or at the end of the slot (t- 1) is denoted as Ravg(h; t-1).

[0057] e) BO is the (normalized) buffer occupancy in the RLC queue (e.g. in the RLCqueue at DU for traffic in downlink direction for a DRB). PBO is the normalized value of buffer occupancy across all DRBs which can be proportional to the value of BO.

[0058] RLC queue (normalized) BO for DRB m corresponding to UE h at time t isdenoted as RLCBO(h, m; t).

[0059] f) In addition, the following weights are defined: W5QI is the weight of P5QI;WGBR is the weight of PGBR; WPDB is the weight of PPDB; WBO is the weight of PBO and WPF is the weight of PPF. For example, each of the above weights can be set to a value between 0 and 1 though other suitable set of values can be chosen too.

[0060] AR (Augmented reality) applications deal with multi-dimensional data andrequire high data rate (e.g.100 Mbps) and low latency. AR applications continue to gain in popularity and use of these in wireless networks is also increasing. Applications with 5QI 80 (such as AR and other low latency enhanced mobile broadband applications) have default priority level of 68, and packet delay budget requirement of 10 ms.

[0061] Consider a UE with two non-GBR DRBs with each carrying traffic from videoor some other high data rate application. For example, one DRB (or the corresponding logical channel, denoted as LC1) can be carrying data traffic for 5QI 80 (which has default priority level of 68) and another DRB or the corresponding logical channel (denoted as LC2) can be carrying traffic for 5QI 9 (which has default priority level of 90). Note that 5QI 9 is a widely used 5QI for several applications including for some of the popular TCP based video streaming applications and 5QI 80 is being used for emerging high data rate low latency applications such as AR / VR / XR.

[0062] Scheduling metric for each logical channel (or the corresponding DRB) iscomputed as: PLC= (W5QI*P5QI+ WPF*PPF) * maximum (WGBR*PGBR, WPDB* PPDB), or one of its variants is used.

[0063] As each DRB is non-GBR in the above example, the weight corresponding toGBR, i.e. WGBR , is set to zero. Thus, the scheduling metric for each LC (i.e. LC1 and LC2) is computed as follows: PLC,1 = (W5QI*P5QI=80 + WPF*PPF) * (WPDB* PPDB)LC1 PLC,2 = (W5QI*P5QI=9 + WPF*PPF) * (WPDB* PPDB)LC2

[0064] Here, (WPDB* PPDB)LC1 denotes the PDB metric for LC1 and (WPDB* PPDB)LC2denotes the PDB metric for LC2.

[0065] Note that the proportional fair term, WPF*PPF, corresponds to the UE and iscommon for PLC,1 and PLC,2 as LC1 and LC2 correspond to the same UE in the example here.

[0066] 5QI metric for 5QI 80, i.e. W5QI*P5QI=80 , is greater than the 5QI metric for 5QI9, i.e. W5QI*P5QI=9 , as 5QI 80 has default priority level of 68 and 5QI 9 has default priority level of 90, and as described earlier, a DRB (or the corresponding logical channel) with a lower priority level has higher value of 5QI metric compared to another DRB with higher priority level. Note that the weight W5QIcan be common for all 5QIs or can also be different for different 5QIs but a DRB with lower default priority level is given higher priority.

[0067] In a congested (or a loaded) cell, waiting time for packets for each logicalchannel in the corresponding RLC queue becomes quite high (and reaches close to its PDB target in the DU). In such a case, value of the PDB metric, WPDB* PPDB, reaches close to its maximum value for each LC. For the above example, (WPDB* PPDB)LC1 becomes equal to (WPDB* PPDB)LC2 in such cases and it becomes difficult to differentiate between these DRBs (or the corresponding logical channels) based on PDB metric of the scheduler.

[0068] For the case above, relative value of PLC for DRBs LC1 and LC2 belonging tothe same UE, largely gets influenced by the 5QI metric W5QI*P5QIand there is PLC,1> PLC,2as W5QI*P5QI=80> W5QI*P5QI=9. In such cases, LC1 gets prioritized over LC2 while taking scheduling decisions. As LC1 is high data rate low latency DRB, it may always have non- zero buffer occupancy in the DL RLC queue in the DU and LC2 can starve (or get very limited opportunities to be served).

[0069] The scenario described above can also occur for the case when there aremultiple UEs in a cell and some of the low priority DRBs can get very limited service compared to the high priority DRBs especially when these DRBs are carrying data traffic for applications such as video streaming, video conferencing, AR (augmented reality) / VR (virtual reality) / XR (extended reality) and during high load situation in the cell. For multi- UE case, computation of scheduling metric for a LC could be influenced by (W5QI*P5QI+ WPF*PPF) during such high load scenarios.

[0070] This behavior is not desirable in a high load O-RAN system which supportsapplications with diverse QoS requirements. This disclosure provides methods for optimized radio resource management in a cell with high load in the presence of high data rate low latency applications (such as AR / VR / XR with 5QI 80, live video streaming with 5QI 7 or other similar applications).

[0071] IMPLEMENTATIONS

[0072] METHOD IA

[0073] In this method, an additional factor, conditionalBoostLC, is used to compute ascheduling metric for logical channel m (i.e. LC m) as below: ^ ,= , + ,

[0074] Here, , is the scheduling metric for LC m and is computed using one ofthe methods given earlier.^, is the enhanced scheduling metric which is computed using the (conditional boost) factor,,, for LC m.

[0075] A default value of conditioalBoostLC is zero for each logical channel. It is set toa non-zero value based on certain conditions (and during specific time intervals) as described below. It helps in giving boost to the scheduling metric, PLC, for logical channels which are not getting proper service due to presence of other high data rate low latency applications in a congested cell.

[0076] As discussed above, the age of HoL (Head-of-Line) or the oldest DL RLC SDUfor DRB m corresponding to UE h in DU at time t is given as, QDelayRLC(h, m; t) = (t – TRLC(h,m)). Here, TRLC(h,m) is the time instant when the HoL or the oldest SDU was inserted in the RLC queue for DRB m corresponding to UE h.

[0077] Take DRB m (corresponding to UE h) as last scheduled at time,lastScheduledTime(h,m;t). Here “t” is the current time. The elapsed time interval since the DRB m was last scheduled for UE h is denoted as elapsedSchedInterval(h,m;t) and is givenas ( , ; ) = ( , ; ). This is also shown inFIG.12.

[0078] The lastScheduledTime(h,m;t) is initialized to zero and is updated each timeLC m corresponding to UE h is served.

[0079] Two conditions are specified (denoted as Condition I and Condition II).

[0001] Condition I: checks to see if elapsedSchedInterval(h,m;t) for LC mcorresponding to UE h is above a pre-defined threshold, denoted as elapsedThreshold(QI(m)). :( , ; ) > ( ( ))

[0080] Here, QI(m) denotes the QoS Identifier for LC m. For 5G networks, this QoSIdentifier is given by the 5QI (5G QoS Indicator) value for LC m and for 4G networks, it is given by the QCI (QoS Class Identifier) value of the LC m.

[0081] If LC m does not get proper service due to the presence of other high datarate low latency applications, its elapsedSchedInterval(h,m;t) can become greater than elapsedThreshold(QI(m)) at some point of time t and Condition I gets satisfied for this LC m.

[0082] Condition II: checks to see if QDelayRLC(h, m; t) is greater than a pre-definedthreshold, denoted as qdelayThreshold(QI(m)). :( , ; ) > ( ( ))

[0083] For the second condition, value of qdelayThreshold(QI(m)) can be set basedon various policies. For example, it can be set equal to PDB of this DRB m multiplied by anageFactor denoted as ageFactor(QI(m)), i.e. qdelayThreshold QI(m) = PDB QI(m)ageFactor(QI(m)).

[0084] Here PDB(QI(m)) denotes the packet delay budget of DRB m (which is sameas packet delay budget of any LC with QoS class indicator QI(m)) and ageFactor(QI(m)) is a pre-defined value which can depend on QoS class of that DRB m.

[0085] If LC m does not get proper service due to the presence of other high datarate low latency applications, its RLC packets may not get served and Condition II can also get satisfied.

[0086] If both of these conditions are true for LC m, conditionalBoostLC is set to avery high value (e.g. above a pre-specified threshold). As part of scheduling decisions, LCs with the highest value of scheduling metric are selected and thus this LC m gets higher scheduling opportunities with this. This helps improve performance of LC m in the presence of other high data rate low latency applications.

[0087] In the example considered above with two LCs (i.e. LC1 and LC2) in a UE, onewith 5QI 80 and another with 5QI 9, in a congested cell environment, there PLC,1 > PLC,2 as W5QI*P5QI=80 > W5QI*P5QI=9. With the enhancements described above, this methodensures that the updated scheduling metric, ^, < ^, for some time slots, and LC2 alsogets opportunities to be served by the MAC scheduler at the DU.

[0088] METHOD IB

[0089] This method uses Condition I and II as in the previous method and creates acandidate set of LCs (or corresponding DRBs) for which these conditions are true. This candidate set of LCs in a cell at time t is denoted as candidateElapsedSet(t). Note that Buffer Occupancy (BO) in the corresponding RLC queue is non-zero for each LC which is part of this candidate set.

[0090] Note also that membership of LCs in this set keeps changing. Some LCs jointhis set when they satisfy Conditions I and II, and some LCs exit this candidate set as they get served and when either Condition I or II is no longer true for these LCs.

[0091] For each LC m which is in the candidate set, candidateElapsedSet(t), at time t,if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold(denoted as numThresholdElapsed), the conditioalBoostLC,m is chosen as ( ) foreach such LC m while computing scheduling metric for LC m.

[0092] Thus, , = ( ) for LC m if LC m is in the(t) <

[0093] Here, is normalized buffer occupancy for DRB m (in the RLC queue inDU) which is in the candidateElapsedSet(t), at time t. Note that this BO is normalized taking into account BOs for other LCs which are in the candidateElapsedSet(t).

[0094] is the weight associated with LC m which is in the candidate set,candidateElapsedSet(t), at time t. It can be dependent on the QoS class of LC m (e.g. on 5QI of LC m for 5G network).

[0095] For LC m which is in the candidate set, candidateElapsedSet(t), at time t, andif the number of LCs in the candidateElapsedSet(t) is greater than (or equal to) a pre- defined threshold (which is denoted thresholdElapsed), the conditioalBoostLCis chosen as for each such LC m while computing scheduling metric for LC m. is in the(t) numThresholdElapsed

[0097] As before, BO is normalized taking into account BOs for other LCs which arein the candidateElapsedSet(t).

[0098] In this case, there are several LCs which are not able to get service (e.g. dueto high load in the cell) and it may not be possible to serve all these LCs within reasonable time. A policy is adopted where a LC with less BO is given higher preference. Note again that it is only for those LCs which are in the candidateElapsedSet(t), at time t.

[0099] METHOD IC

[0100] In this method, a module, denoted as ‘RRM-Optimization module’, takesabove radio resource management (i.e. scheduling) decisions and is located at the Near-RT- RIC. It provides additional flexibility in applying various radio resource management policies for the scenarios discussed above.

[0101] In this method, at block 202 DU, acting as an E2 node, keeps communicatingthe following for each LC (or DRB) in the cell to the RRM Optimization module (or xApp) hosted at the Near-RT-RIC: -lastScheduledTime(h,m;t): Last time when DRB m (corresponding to UE h) wasscheduled for service by the scheduler running at DU. Here “t” is the current time at which this report is sent from DU to Near-RT-RIC. -candidateElapsedSet(t): List of LCs which are members of this set at any given pointof time. Conditions I and II are evaluated to decide this as specified in Method IB. -QoS class for each LC which is part of candidateElapsedSet(t),- Buffer occupancy for each DRB m which is part of candidateElapsedSet(t)- Waiting time of first few packets from RLC queue for each LC which is part ofcandidateElapsedSet(t) -Cell load (e.g. PRB utilization)- Other parameters as specified in Method IA and IB

[0102] At block 202, a RIC SUBSCRIPTION REQUEST as shown in FIG. 13 is enhancedto allow Near-RT-RIC to subscribe to these parameters from DU.

[0103] At block 204 RIC INDICATION messages as shown in FIG. 13 are enhanced tocommunicate these parameters from the DU to Near-RT-RIC.

[0104] The elapsed time interval since the DRB m was last scheduled for UE h isdenoted as elapsedSchedInterval(h,m;t) and is given as ( , ; ) =( , ; ).

[0105] In this case, the RRM Optimization module, or xApp, at the Near-RT-RICconsiders LCs which are not getting proper service and selects the LCs to give additional boost using various RRM policies deployed at the Near-RT-RIC. For example, RRM methods given in Method IA and IB can be hosted at Near-RT-RIC and LCs can be selected to give additional boost using these methods.

[0106] At block 206 Near-RT-RIC communicates identity of these selected LCs to DUvia RIC CONTROL REQUEST along with the additional boost to be given for computation of scheduling metrics for these LCs as shown in FIG.13. The RIC CONTROL REQUEST message is enhanced for this purpose.

[0107] METHOD ID

[0108] In this method, the RRM-Optimization module is hosted at the CU. It can behosted at the CU-CP or CU-UP. The example method below is described where the module is hosted at the CU-CP.

[0109] DU keeps communicating the following for each LC (or DRB) in the cell to theRRM Optimization module hosted at the CU-CP: -lastScheduledTime(h,m;t): Last time when DRB m (corresponding to UE h) wasscheduled for service by the scheduler running at DU. Here “t” is the current time at which this report is sent from DU to Near-RT-RIC. -candidateElapsedSet(t): List of LCs which are members of this set at any given pointof time. Conditions I and II are evaluated to decide this as specified in Method IB. -QoS class for each LC which is part of candidateElapsedSet(t),- Buffer occupancy for each DRB m which is part of candidateElapsedSet(t)- Waiting time of first few packets from RLC queue for each LC which is part ofcandidateElapsedSet(t) -Cell load (e.g. PRB utilization)- Other parameters as specified in Method IA and IB

[0110] F1AP (F1 Application Protocol) running across F1-C interface is enhanced tocommunicate above parameters from DU to CU-CP.

[0111] In this case, the RRM Optimization module at CU-CP considers LCs which arenot getting proper service and selects the LCs to give the additional boost using various RRM policies deployed at the CU-CP. For example, RRM methods given in Method IA and IB can be hosted at CU-CP and LCs can be selected to give additional boost to these LCs using these methods.

[0112] CU-CP communicates identity of these selected LCs to DU along with theadditional boost to be given for computation of scheduling metrics for these LCs. F1AP running over F1-C interface is enhanced for this purpose.

[0113] Reference is made to Third Generation Partnership Project (3GPP) and theInternet 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 define the related terms and architecture reference models that follow.

[0002] Acronyms5GC: 5G Core Network 5G NR: 5G New Radio5QI: 5G QoS Identifier ACK: Acknowledgement AI: Artificial Intelligence AI / ML (or AIML): Artificial Intelligence and Machine Learning AM: Acknowledged Mode APN: Access Point Name ARP: Allocation and Retention Priority BO: Buffer Occupancy BS: Base Station BSR: Buffer Status Report 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 DL: Downlink DDDS: DL Data Delivery Status DNN: Data Network Name DNN: Deep Neural Network DQN: Deep Q Network DRB: Data Radio Bearer DU: Distributed Unit eNB: evolved NodeBEPC: Evolved Packet Core EN-DC: E-UTRAN New Radio Dual Connectivity 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 MAC: Medium Access Control MDP: Markov Decision Process MIB: Master Information Block ML: Machine Learning MR-DC: Multi-RAT Dual Connectivity 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 InstanceNWDAF: 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 Service RAN: 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: Reflective QoS Indication RRC: Radio Resource ControlRRM: 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 SIB: System Information Block SLA: Service Level Agreement S-NSSAI: Single Network Slice Selection Assistance SST: Slice / Service Type 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

[0114] It will be understood that implementations and embodiments can beimplemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, so 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 so that theinstructions, 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

CLAIMS1. A method for optimized radio resource management (RRM) in high load cell in thepresence of a high data rate low latency application comprising: computing a scheduling metric for each logical channel (LC) m, corresponding to aData Radio Bearer (DRB), of a plurality of logical channels , with an additionalboost,,^,= , + , ;using a first condition to check if an elapsedSchedInterval for LC m corresponding to UE h is above a pre-defined threshold elapsedThreshold(QI(m)), wherein QI(m) denotes the Quality of Service (QoS) Identifier for LC m; determining if a second conditon QDelayRLC is greater than a pre-defined threshold qdelayThreshold(QI(m)), wherein QDelayRLC is a Queuing delay at an RLC; and when both the first condition and the second conditiion are true for LC m, setting a conditioalBoostLC above a pre-specified threshold value.

2. The method of claim 1, further comprising:generating a candidate set of LCs for which the first condtion and the second condition are true, wherein the candidate set of LCs in a cell at time t is denoted as candidateElapsedSet(t).

3. The method of claim 2, further comprising:for each LC m which is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold(numThresholdElapsed), the conditionalBoostLC,m is chosen as ( ) for eachsuch LC m while computing the scheduling metric for LC m such that ,= ( )if LC m is in the candidateElapsedSet(t) at time t and if the number of LCs in the candidateElapsedSet(t) < numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

4. The method of claim 2, further comprising:for each LC m which is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), the conditionalBoostLC,m is chosen as for each such LC m while computing the scheduling metric for LC m such that,=(t) at time t and if the number of LCs in the candidateElapsedSet(t) numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

5. The method of claim 2, further comprising:communicating, from a DU to an RRM Optimization module, scheduling metric parameters for calculating the additional boost comprising: a lastScheduledTime(h,m;t) when a DRB m corresponding to a UE h was scheduled for service by a scheduler running at DU, wherein “t” is the current time at which the report is sent from the DU to the Near-RT-RIC; the candidateElapsedSet(t);a QoS class for each LC in candidateElapsedSet(t); a Buffer occupancy for each DRB m in candidateElapsedSet(t); a waiting time of a first number of packets from an RLC queue for each LC in the candidateElapsedSet(t); and a Cell load (e.g. PRB utilization); selecting, by the RMM Optimization module, the LCs to be given the additional boost; and communicating, by the RMM Optimization module to the DU, the identity of the selected LCs to the DU along with conditionalBoostLC.

6. The method of claim 5, wherein the RRM Optimization module is located at a Near-RT-RIC.

7. The method of claim 5, further comprising:enhancing a RIC SUBSCRIPTION REQUEST to allow Near-RT-RIC to subscribe to the scheduling metric parameters from the DU; enhancing a RIC INDICATION message to communicate the scheduling metric parameters from the DU to the Near-RT-RIC; and enhancing a RIC CONTROL message to communicate the identity of the selected LCs along with , from the Near-RT-RIC tothe DU.

8. The method of claim 5, wherein the RRM Optimization module is located at a CU-CPor CU-UP.

9. The method of claim 8, wherein the RRM Optimization module is located at a CU-CP.

10. The method of claim 9, further comprising an F1 Application Protocol runningacross an F1-C interface that is enhanced to communicate the scheduling metric parameters for the additional boost from DU to CU-CP, and the method further comprises: communicating, by the CU-CP, the identity of the selected LCs to the DU along with the,over the F1-C interface. 11.A system for optimized radio resource management in high load cell in the presence of a high data rate low latency application comprising a RRM Optimization module configured to: compute a scheduling metric for each logical channel (LC) m, corresponding to aData Radio Bearer (DRB), of a plurality of logical channels , with an additionalboost,,^,= , + , ;for LC m corresponding to UE h is above a pre-defined threshold elapsedThreshold(QI(m)), wherein QI(m) denotes the Quality of Service (QoS) Identifier for LC m; determine if a second conditon QDelayRLC is greater than a pre-defined threshold qdelayThreshold(QI(m)), wherein QDelayRLC is a Queuing delay at an RLC; and when both the first condition and the second conditiion are true for LC m, set a , above a pre-specified threshold value.

12. The system of claim 11, wherin the RRM Optimization module is further configuredto: generate a candidate set of LCs for which the first condtion and the second condition are true, wherein the candidate set of LCs in a cell at time t is denoted as candidateElapsedSet(t).

13. The system of claim 12, wherein the RRM Optimization module is furtherconfigured:for each LC m which is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), to choose the conditionalBoostLC,m as ( ) for eachsuch LC m while computing the scheduling metric for LC m such that ,= ( )if LC m is in the candidateElapsedSet(t) at time t and if the number of LCs in the candidateElapsedSet(t) < numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

14. The system of claim 12, wherein the RRM Optimization module is furtherconfigured: for each LC m which is in the candidate set of LCs candidateElapsedSet(t), if the number of LCs in the candidateElapsedSet(t) is less than a pre-defined threshold (numThresholdElapsed), to choose the conditionalBoostLC,m as for each such LC m while computing the scheduling metric for LC m such,=m (t) at time t and if the number of LCs in the candidateElapsedSet(t) numThresholdElapsed, wherein is normalized buffer occupancy for the corresponding DRB m in the candidateElapsedSet(t) and is a weight associated with LC m in the candidate set, candidateElapsedSet(t).

15. The system of claim 12, wherein the RRM Optimization module is further configuredto:receive, from a distributed unit (DU), scheduling metric parameters for calculating the additional boost comprising: a lastScheduledTime(h,m;t) when a DRB m corresponding to a UE h was scheduled for service by a scheduler running at DU, wherein “t” is the current time at which the report is sent from the DU to the Near-RT-RIC; the candidateElapsedSet(t); a QoS class for each LC in candidateElapsedSet(t); a Buffer occupancy for each DRB m in candidateElapsedSet(t); a waiting time of a first number of packets from a RLC queue for each LC in the candidateElapsedSet(t); a Cell load (e.g. PRB utilization); and select the LCs to be given the additional boost; and communicate, to the DU, the identity of the selected LCs to the DU along with conditionalBoostLC.

16. The system of claim 15, wherein the RRM Optimization module is located at a Near-RT-RIC.

17. The system of claim 16, wherein the system is configured with:an enhanced RIC SUBSCRIPTION REQUEST configured to allow Near- RT-RIC to subscribe to the scheduling metric parameters from the DU; an enhanced RIC INDICATION message configured to communicate the scheduling metric parameters from the DU to the Near-RT-RIC; and an enhanced RIC CONTROL message configured to communicate the identity of the selected LCs along with the,from theNear-RT-RIC to the DU.

18. The system of claim 15, wherein the RRM Optimization module is located at a CU-CPor CU-UP.

19. The system of claim 18, wherein the RRM Optimization module is located at a CU-CP.

20. The system of claim 19, further comprising an F1 Application Protocol runningacross an F1-C interface that is enhanced to communicate the scheduling metric parameters for the additional boost from DU to CU-CP, and the system further comprises: communicating, by the CU-CP, the identity of the selected LCs to the DU along with the,over the F1-C interface.

Images