Jointly optimizing coordinated multipoint transmission and energy saving operations for inter / intra-du scenarios in o-ran networks

A joint optimization framework integrating CoMP and energy saving operations with machine learning in O-RAN networks addresses inefficiencies in resource allocation and energy use, enhancing network performance and efficiency.

WO2026122740A1PCT designated stage Publication Date: 2026-06-11MAVENIR SYST INC

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
MAVENIR SYST INC
Filing Date
2025-12-04
Publication Date
2026-06-11

AI Technical Summary

Technical Problem

Existing O-RAN networks face challenges in optimizing coordinated multipoint transmission and energy saving operations, particularly in inter/intra-DU scenarios, leading to inefficiencies in resource allocation and increased energy consumption.

Method used

Implementing a joint optimization framework that integrates Coordinated Multipoint Transmission (CoMP) techniques with energy saving operations, utilizing machine learning algorithms like Deep Q-Networks (DQN) and LSTM networks to dynamically adjust resource allocation and energy management across distributed units (DUs) in O-RAN networks.

🎯Benefits of technology

Enhances network performance by optimizing resource allocation and reducing energy consumption, thereby improving user experience and operational efficiency in O-RAN networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025058024_11062026_PF_FP_ABST
    Figure US2025058024_11062026_PF_FP_ABST
Patent Text Reader

Abstract

To address cell interference, a Coordinated Multipoint Transmission module is configured to decide Physical Resource Blocks to be blanked for each region of a cell along with a time interval for each cell. An Artificial Intelligence and Machine Learning assisted Low Energy Scheduling Solution module is configured to finds time intervals where a Distributed Unit for the cell does not communicate any data with the User Equipment in that cell and such time intervals can be used by a Radio Unit to switch to energy saving state. Decisions are taken to reduce interference and reduce energy consumption with joint optimization of Coordinated Multipoint Transmission and Low Energy Scheduler Solution.
Need to check novelty before this filing date? Find Prior Art

Description

JOINTLY OPTIMIZING COORDINATED MULTIPOINT TRANSMISSION AND ENERGY SAVING OPERATIONS FOR INTER / INTRA-DU SCENARIOS IN O-RAN NETWORKSDESCRPTION OF RELATED TECHNOLOGY1. Field of the Disclosure

[0001] This disclosure relates to Joint Optimization of Inter / Intra-DU Coordinated Multipoint Transmission and Energy Saving operations in Open Radio Access Network (O-RAN) networks.SUMMARY OF THE DISCLOSURE

[0002] Described are implementations of a computer system, computer system components, computer apparatus, a method, and computer program products configured to execute program instructions for the method for radio access network, and operation, administration and management of various network elements of 4G, 5G, and further generations of the radio access network system. The method is performed by a computer system that comprises one or more processors and a computer-readable storage medium encoded with instructions executable by at least one of the processors and operatively coupled to at least one of the processors.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1A is a diagram of a system architecture.

[0004] FIG. 1B is a diagram of a system architecture.

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

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

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

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

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

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

[0011] FIG. 8A shows an example of an 0-RAN architecture.

[0012] FIG. 8B shows an example of an 0-RAN 0AM architecture.

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

[0014] FIG. 10 illustrates a PDU Session architecture comprising multiple DRBs and multiple QoS Flows.

[0015] FIG. 11 shows a Resource Allocation MAC Scheduler, DL Data, and Flow Control Feedback for 5G Network.

[0016] FIG. 12 shows an Inter-DU CoMP example.

[0017] FIG. 13A shows an example of cell interference.

[0018] FIG 13B shows an architectural flow.

[0019] FIG. 14A shows a CoMP_RRM_Initiate_Request.

[0020] FIG. 14B shows a CoMP_RRM_Initiate_Request.

[0021] FIG. 15A shows a CoMP_RRM_Response.

[0022] FIG. 15B shows a CoMP_RRM_Response.

[0023] FIG. 16A shows a CoMP RRM flow.

[0024] FIG. 16B shows a CoMP RRM flow.

[0025] FIG. 17 shows a CoMP_RRM_Update_Request.

[0026] FIG. 18A shows a CoMP_RRM_Update_Request.

[0027] FIG. 18B shows a CoMP_RRM_Update_Request.

[0028] FIG. 19 shows PRBs for a cell region.

[0029] FIG. 20 shows a CoMP RRM flow.

[0030] FIG. 21 shows a LESS_ES_TimeSlices message.

[0031] FIG. 22 shows an example of a time interval with usable PRBs in different cell regions.

[0032] FIG. 23A shows a CoMP_RRM_ES_Update_Response.

[0033] FIG. 23B shows a CoMP_RRM_ES_Update_Response.

[0034] FIG. 24 shows messages used across a D2 interface for inter-DU CoMP optimized for LESS.DETAILED DESCRIPTION OF THE DISCLOSURE

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

[0036] 3GPP TS 23.501 V 18.1.0 2023-04-05

[0037] 3GPP TS 38.300 V 17.4.0 03-28-2023

[0038] 3GPP TS 38.401 V 17.4.0 2023-04-03

[0039] 3GPP TS 38.425 18.0.0, 2024-01-12

[0040] 3GPP TS38.473 version 18.1.0, 2024-01-12

[0041] Acronyms5GC: 5G Core Network5G NR: 5G New Radio5QI: 5G QoS IdentifierACK: AcknowledgementAl: Artificial IntelligenceAI / ML (or AIML): Artificial Intelligence and Machine Learning AM: Acknowledged ModeAPN: Access Point NameARFCN: Absolute Radio-Frequency Channel Number ARP: Allocation and Retention PriorityBO: Buffer OccupancyBS: Base StationBSR: Buffer Status ReportCNN: Convolution Neural NetworkCMS: Centralized Management SystemCN: Core NetworksCoMP: Coordinated Multipoint (Transmission)CP: Control PlaneCSI: Channel State InformationCSI-RS: Channel State Information Reference Signal CU: Centralized UnitCU-CP: Centralized Unit - Control PlaneCU-UP: Centralized Unit - User PlaneDC: Dual ConnectivityDL: DownlinkDDDS: DL Data Delivery StatusDNN: Data Network NameDNN: Deep Neural NetworkDQN: Deep Q NetworkDRB: Data Radio BearerDSS: Dynamic Spectrum SharingDU: Distributed UniteNB: evolved NodeB (4G LTE Base Station)en-gNB: NR Node B (5G Base Station)EPC: Evolved Packet CoreEN-DC: E-UTRA-NR Dual ConnectivityE-UTRA: Evolved UMTS Terrestrial Radio Access ES: Energy SavingEWMA: Exponentially Weighted Moving Average GBR: Guaranteed Bit RategNB: gNodeB (5G NR Base Station)GTP-U: GPRS Tunnelling Protocol - User Plane IP: Internet ProtocolLI: Layer 1L2: Layer 2L3: Layer 3L4S: Low Latency, Low Loss and Scalable Throughput LC: Logical ChannelLESS: Low Energy Scheduler SolutionLTE: Long Term EvolutionMAC: Medium Access ControlMDP: Markov Decision ProcessMeNB: Master eNodeBMIB: Master Information BlockML: Machine LearningMN: Master NodeMR: Multi-RATMR-DC: Multi-RAT Dual ConnectivityMR-SS: Multi-RAT Spectrum SharingNACK: Negative AcknowledgementNAS: Non-Access StratumNG-RAN: Next Generation Radio Access Network NR: New RadioNR-U: New Radio - User PlaneNSA: Non-StandaloneNSI: Network Slice InstanceNSSI: Network Slice Subnet InstanceNWDAF: Network Data Analytics FunctionO-RAN: Open Radio Access NetworkOAM: Operations, Administration Maintenance PCI: Physical Cell IdentityPDB: Packet Delay BudgetPDCP: Packet Data Convergence Protocol PDU: Protocol Data UnitPER: Packet Error RatePF: Proportional FairPHY: Physical LayerPRB: Physical Resource BlockQCI: QoS Class IdentifierQFI: QoS Flow IdentifierQoS: Quality of ServiceRAN: Radio Access NetworkRAT: Radio Access TechnologyRB: Resource BlockRDI: Reflective QoS Flow to DRB Indication RL: Reinforcement LearningRLC: Radio Link ControlRLC-AM: RLC Acknowledged ModeRLC-UM: RLC Unacknowledged ModeRNN: Recurrent Neural NetworksRQI: Reflective QoS IndicationRRC: Radio Resource ControlRRM: Radio Resource ManagementRSRP: Reference Signal Received PowerRSRQ: Reference Signal Received QualityRTP: Real-Time Transport ProtocolRTCP: Real-Time Transport Control Protocol RU: Radio UnitS1-U: S1 User PlaneS1-C: S1 Control PlaneSA: StandaloneSCTP: Stream Control Transmission Protocol SD: Slice DifferentiatorSDAP: Service Data Adaptation ProtocolSIB: System Information BlockSINR: Signal to Interference Noise RatioSLA: Service Level AgreementSN: Secondary NodeS-NSSAI: Single Network Slice Selection Assistance SpCell: Special CellSSB: Synchronization Signal BlockSST: Slice / Service TypeTB: Transport BlockTCP: Transmission Control ProtocolTEID: Tunnel Endpoint IdentifierUE: User EquipmentUP: User PlaneUL: UplinkUM: Unacknowledged ModeUPF: User Plane FunctionvDU: Virtual DUX2-C: X2 Control planeX2-U: X2-User plane

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] The E2 nodes (CU and DU) are connected to the near-real-time RIC 132 using the E2 interface. The E2 interface is used to send data (e.g., user and / or cell KPMs] from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC 132. The applications or services at the near-real-time RIC 132 that deploy 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 sends 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 Al interface. The applications that are hosted at non-RT-RIC are called rApps. Also shown in FIG.8 are Open evolved Node B (O-eNB) 806, which is shown as being connected to the near-real-time RIC 132 and the SMO Framework 805 and O-Cloud 804, which is shown as being connected to the SMO Framework 805.

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

[0059] PDU sessions, DRBs, and Quality of Service (QoS) flows will now be discussed. In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a Data Network (DN) identified by a Data Network Name (DNN). The PDU 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 5G QoS Identifier (5QI). A PDU session comprises the following: Data Radio Bearers that are between UE and CU in RAN; and an NG-U GTP tunnel that is between CU and User Plane Function (UPF) in the core network. FIG. 9 illustrates an example PDU session (in accordance with 3GPP TS 23.501) comprising multiple DRBs, where each DRB can comprise multiple QoS flows. In FIG. 9, three components are shown for the PDU session 901: UE 101; AN 902; and UPF 903, which includes Packet Detection Rules (PDRs) 9031.

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

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

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

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

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

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

[0066] In this section, standardized 5QI to QoS characteristics mapping is discussed. As per 3GPP TS 23.501, the one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in Table 1. The first column represents the 5QI value. Thesecond 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 PrioritysQi, 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 may 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.50! Resource Default packet Packet Default Sefauit SxarnpJe Value Typ* Priority Delay Error Maximum AveragingLevel Budget Rate Data Burst(NOTE a;* Volume(NOTE 2)2» 1 X? ms uyz- N< A 2(.-8i) BB •i-onversaticmas Voice GSR (NOTE 11,NOTE W* (NOTE 11 4& 55C ms i8'?N< A 2880 ms Conversamna: Vwec- (NOTE 5NOTE W3 30 50 ms B>"2NiA zC’UQ me Reat Time Gaming,(NOTE 11, V2K messages (see NOTE 13? TO 23287 fl2?})Eier.tricdy <iistri?flXi«r> - meiliwn wrfSsge.Frsxsss aatom a&sm amnitar-rig4 58 31X1 ms co ' NfA 2G88 ms Non • Ooavet srslOmt?(NO TE 1 1, Video (SiiSemONOTE 13) Skesmsm;85?& ms N< A 2083 ms Missicat Critical s®er (NOTE 9, (NOTE 7. ny^ Narie Push To T’slk MOTE 1Z> NOTE 8,1 voice (e.si., MCPTT?11X1 ms N)A 3(;80 ms Non-Mission-Crfiicai {& OTE 2(1 (NOTE 18, W2user tiiam; Posit To NOTE 131 Talk verae67 55 1 GO cis X'7N / A 2080 ms Missal Critical Vkte* (NOTE 12) (NOTE Hi, userNOTE 13?(ROTE 14)?i 55 5 SO uys NiA 2880 ms 'Live* vphTisfc(NOTE 1 $,NOTfc n is 2-3.23aNOTE 35}72 S6 388 IBS l(f NZA 20< X: ms •'LNsT ijpimk(NOTE n Streamer Gc cNOTE 13 TS 28 233 [78$NOTE 151< -< 56 3iX? ms 18’’ NIA 2800 ”Lmy(NOTE I s. Siire^«'s:«p fe 9MOTE 13. TS {?$3>NOTE 15)^>5 530 css l8'i;NiA 2888 ms “Live* Uplmk: NO O'. 1 1. Str& BmOg {e.«.NOTE 151 TS 28238 (78)'?5£ »X1 Cis uy* NIA 2680 ms ■'Live- 8p1mk(NOTE 11, SVeaming {«.».NOTE 13. TS 25233 [76#NOTE 15?Nor.-(33R 18 IGO to<:N / A N-ANOTE 10.NOTE 13?e (MOTE 1) N / A NAA Vkieo<38 3'3.1 ms w4Stfean?^}(NOTE 10. TCP-b»s««:A?.9..NOTE 13? chat ftp- pi'p S:e shamg. progressive vaierp etc )? NiA NiA Voice.78 1G8ms W"5Vifjw i; Uve(MOTE 10, Sfreanwg*NOTE 13? foterectiYe SpmicgTable 1

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

[0068] Radio Resource Management (RRM) is now discussed (a block diagram for an example RRM with a MAC Scheduler is shown in FIG. 11). L2 methods (such as MAC scheduler) play a critical role in allocating radio resources to different UEs in a cellular network. For example, the scheduling priority of a logical channel (PLC) can be determined as part of MAC scheduler 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, orPLC = (W5QI*P5QI) *(WPF*PPF) * (WGBR*PGBR)*(WPDB* PPDB), orPLC = (W5QI*P5QI+ WPF*PPF) * maximum (WGBR*PGBR, WPDB* PPDB) + WBO*PBO, or PLC = (W5QI*P5QI+ WPF*PPF) + maximum (WGBR*PGBR, WPDB* PPDB) + WBO*PBO

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

[0070] For this application the following terms and definitions shall apply:

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

[0072] PGBR is the priority metric corresponding to the target bit rate of the corresponding 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;PGBR is 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; andPGBR = 0 for non-GBR flows.For GBR DRB m corresponding to UE h, remData at time t is denoted as remData(h, m; t) and targetData at time t is denoted as targetData(h, m; t).

[0073] PPDB is the priority metric corresponding to the packet delay budget at DU for the corresponding logical channel. PPDB = 1 if PDBDU<=QDelayRLc and PPDB = 1 / (PDBDU-QDelay Lc) if PDBDU> QDelayR c where both PDBDU(Packet Delay Budget at DU) and RLC Queuing delay, QDelayRLc, are measured in terms of (time) slots. For example, each (time) slot can be equal to 1 ms or 0.5 ms.

[0074] ‘Slot’ and ‘time slot’ are used interchangeably in this document.

[0075] 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 SDUinsertion in RLC queue to current time where t:= current time instant, TRLC:= time instant when oldest SDU was inserted in RLC.

[0076] Packet delay budget at DU is denoted as PDBDU. Waiting time for HoL RLC packet for DRB m corresponding to UE h at time t (i.e. in slot t) is denoted as QDelayRLcfh, m; t).

[0077] PPF is the priority metric corresponding to proportional fair metric of the UE.rα1PPF is the PF Metric, calculated on a per UE basis as PPF= rα1 / Ravgβ1Where,r: 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. Specifically, Ravg(t)= a *Ravg(t-1) + (1-a) *b(t), UE's exponentially weighted moving average throughput, where b(t)>=0 is the number of bits scheduled in the current slot t and parameter ‘a’ is selected such that 0 < a <= 1.

[0078] α1 and β1 are configurable parameters. For example, if one sets α1=1 and β1 = 0, the priority metric, PPF, 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.

[0079] For some existing systems, α1 and β1 are in the range of 0 to 1. Allow α to be upper bounded by α1_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 α1_max to be even higher than one (for example, α1_max = 1.2) to help design and enforce various type of policies (and associated service level agreements at per-cell, per-DU and per-logical channel level). Similarly, β1, is upper bounded by β1_max, and lower bounded by zero.

[0080] For UE h, achievable data rate in slot t is denoted as r(h; t), which is influenced by CSI reported by UE h for slot t 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).

[0081] BO is the (normalized] buffer occupancy in the RLC queue (e.g., in the RLC queue at DU for traffic in the 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.

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

[0083] In addition, the following weights are defined:WSQI is the weight of PSQI;WGBR is the weight of PGBR;WPDB is the weight of PPDB;WBO is the weight of PBO;WPF is the weight of PPF.Each of the above weights can be set to a value between 0 and 1 though other suitable set of values can be chosen.

[0084] DL CoMP (Downlink Coordinated Multipoint Transmission)

[0085] An RRC_CONNECTED UE derives cell measurement results by measuring one or multiple beams associated per cell as configured by the network. Network configures UE to report Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal to Interference Noise Ratio (SINR) and the like based on certain reporting criteria. The UE measures many different signals where the main ones are based on the SSB (Synchronization Signal Block] and CSI-RS (Channel State Information Reference Signal].

[0086] The channel State Information (CSI) Reference Signal is a multi-purpose downlink transmission. The Base Station can configure the UE to use the CSI Reference Signal for procedures such as CSI Reporting, Beam Management and Connected Mode Mobility. UE provides CSI reports based upon measurements from the CSI Reference Signal. CSI report includes Channel Quality Indicators (Wide-band CQI and Sub-band CQI), Rank Indicators (RI) and Precoding Matrix Indicators (PMI).

[0087] For CSI reporting, a UE can be configured via higher layer signaling with one out of two possible sub-band sizes, where a sub-band is defined as NPRBSBcontiguous PRBs and depends on the total number of PRBs in the bandwidth part according to an example table below:8»tt<iwidi it pari (PRBs)i. 24 - 72.. 4?8.i _ 7T •_M4 _ _ & £6 _J45T275 16, 32

[0088] The reportFreqConfiguration contained in a CSI-ReportConfig indicates the frequency granularity of the CSI Report. A CSI Reporting Setting configuration defines a CSI reporting band as a subset of sub-bands of the bandwidth part, where the reportFreqConfiguration indicates- the csi-ReportingBand as a contiguous or non-contiguous subset of sub-bands in the bandwidth part for which CSI shall be reported.- wideband CQI or sub-band CQI reporting, as configured by the higher layer parameter cqi-Formatlndicator. When wideband CQI reporting is configured, a wideband CQI is reported for each codeword for the entire CSI reporting band. When sub-band CQI reporting is configured, one CQI for each codeword is reported for each sub-band in the CSI reporting band- wideband PMI or sub-band PMI reporting as configured by the higher layer parameter pmi-Formatlndicator.

[0089] Inter-Cell interference, generally caused by using the same resources in neighboring cells is major problem for wireless networks and it can degrade overall network and per-user performance. The interfering cell can be in the same gNB-DU as serving cell (intra-DU) or different gNB-DU but under same gNB-CU (inter-DU) or different gNB-CU (inter-CU).

[0090] CoMP (Coordinated Multi-Point Transmission) techniques are used to improve cell-edge performance by coordinating transmission and reception in neighboring cells. Downlink CoMP (DL CoMP) is a relatively general term referring to different types of coordination in the downlink transmission from multiple geographically separated transmission points (TPs). This includes coordination in the scheduling, including any beam-forming functionality, between geographically separated transmission points and joint transmission from geographically separated transmissions points. Note that the gNB-DUs are synchronized using a common source.

[0091] As part of CoMP, cell-edge UEs are identified for each cell (e.g., by measuring received signal strength by the UEs of that cell). Next, identity of interfering (neighboring) cells is identified for these cell-edge UEs. For example, a UE being served by one cell can be in overlapping coverage area of two other cells and these cells can cause interference for this UE. For a given cell-edge UE, the interfering neighbor can be in the same DU or in a different DU.

[0092] For intra-DU CoMP, serving cell and neighboring intra-frequency cell are in the same DU and this is referred to as intra-DU CoMP. An Inter-DU CoMP scenario is shown in FIG. 12 where the serving cell (i.e., cell 1) and neighboring intra-frequency cell (i.e., cell 5) are in different DUs for the cell-edge UE for which serving cell is cell 1.

[0093] Inter-DU Interface (D2 interface):

[0094] Inter-DU interface can be used for DU to DU communication. This interface is denoted as D2 in this document. Control plane of D2, denoted as D2-C, allows for exchange of control information between two different DUs. An application protocol D2AP (D2 Application Protocol) runs over D2-C interface, and this is used to exchange parametersbetween different DUs. This D2AP protocol runs over SCTP / IP, and it provides reliable transmission with SCTP (Streaming Control Transmission Protocol).

[0095] To create logical D2-C connection between two different DUs, the first DU uses IP address of second DU to establish a SCTP connection. After that, this DU (which had sent SCTP establishment request) sends D2 Setup Request to the second DU and receives D2 Setup Reply. Alternatively, other DU can also initiate D2 establishment.

[0096] As part of initial D2AP protocol exchanges over the D2 interface between DUs, DUs exchange information regarding the cells served by them.

[0097] LESS (Low Energy Scheduler Solution)

[0098] Low Energy Scheduler Solution (LESS) is described here. Radio access networks account for large part of energy use for an operator. Major part of this energy is used within the Radio Unit (RU) with Power Amplifiers (PAs) consuming good part of it. In a wireless base station (such as 5G gNB or LTE eNB), Low-Energy Scheduler Solution (LESS) at DU intends to schedule data transmission to find opportunities to move RU to a low power state for multiple time intervals where each such interval can be even few milliseconds or longer (such as 10s of ms or even higher). This can result in good level of power saving for the base station.

[0099] As part of this, an energy saving metric, denoted as ρES, is computed for each cell. This metric is computed taking into account various factors such as radio conditions of the UEs, load in that cell (e.g. in terms of PRB utilization, number of active users and other factors), buffer occupancy of each logical channel in the RLC queues in DU, latency constraints for applications for which data is being carried by the DRBs of that UE, data rate requirements for GBR applications and other factors depending on various policies used for this purpose.

[0100] As an example policy, MAC scheduler at DU for a given cell can decide not to serve any data packets in a slot if value of this energy saving metric is less than a threshold and if no mandatory control information needs to be sent in that slot. Power amplifier atRU can go to energy saving mode for such time intervals and this results in energy saving for the base station.

[0101] Long Short-Term Memory (LSTM) networks

[0102] In this section, basic structures and characteristics of neural networks will be discussed. Recurrent neural networks (RNNs] are a family of neural networks that are suited for handling sequential data. RNNs use a hidden state associated with each time-step and the output at each time step is computed using the input and the previous hidden state.

[0103] RNN architectures suffer from some limitations. First, RNNs fail to store information for a long period of time and thus don’t handle the situations well in which a reference to certain information stored quite a longtime ago is required to predict the current output. Second, there is no fine control to select which part of the context needs to be carried forward and or can be "forgotten". Also, in RNNs, gradients in early layers are computed as the product of terms from later layers. With this, gradients in early layers can grow exponentially large (e.g., if the terms in later layers are large enough] or can exponentially decrease (e.g., if terms in later layers are small].

[0104] Long Short-Term Memory (LSTM] networks, which are an extension of recurrent neural networks (RNNs], have been introduced to handle situations where RNNs do not work well. The basic difference between the architectures of RNNs and LSTMs is that the hidden layer of LSTM is a gated unit or a gated cell, which includes four layers that interact with one another in a way to produce the output of that cell along with the cell state. The output and the cell state are then passed onto the next hidden layer. Unlike RNNs which have only a single neural net layer of tanh (hyperbolic tangent], LSTMs comprise three logistic sigmoid gates and one tanh layer. It should be noted that output of sigmoid activation function is in the range (0 to 1] for any real value as input, while the output of tanh is in the range (-1 to 1].

[0105] Gates are provided in LSTM in order to limit the information that is passed through the cell, i.e., the gates determine which part of the information will be needed by the next cell and which part is to be discarded. The output is usually in the range of 0 to 1,where "0” means "reject all”, and “1" means "include all". Information is retained by the cells, and the memory manipulations are done by the gates. Three gates are provided in LSTM: 1) forget gate; 2] input gate; and 3] output gate.

[0106] The present disclosures identifies and provides implementations to, inter alia, advantageously address the need for joint optimization for inter-cell RRM (including], LESS and other related methods to improve overall system performance.

[0107] Implementations

[0108] Method I A

[0109] Cell j belonging to DU k is denoted as c(j, k).

[0110] A UE can be in the coverage area of one or more cells. If a UE is in the (overlapping) coverage area of more than one cell, this UE can experience interference due to these cells.

[0111] Set of interfering cells for a UE, x, is denoted by I-UE(x). One of these is the serving cell for this UE at a given point of time and other cells are causing interference to this UE. Note that the serving cell of UE x is also included in I-UE(x] even though that itself is not causing interference on its own for this UE.

[0112] For example, if UE x is in the (overlapping] coverage areas of three cells, say c(j 1, kl], c(hl, k2], c(nl, k3], as in FIG. 13A. For this example: I-UE(x] = { c(j 1, kl], c(hl, k2], c(nl, k3]}. One of these is acting as serving cell for this UE x and others are causing interference for this UE. Here, c(jl, kl] denotes cell jl corresponding to DU kl, c(hl, k2] denotes cell hl corresponding to DU k2 and c(nl, k3] denotes cell nl corresponding to DU k3. DU kl, k2 and k3 can correspond to three different DUs or two DUs (or can be same DU also].

[0113] Example scenario shown in FIG. 13A shows four overlapping (or interfering] regions (or areas] and three non-overlapping regions.

[0114] Overlapping (or interfering) regions are those (virtual) regions where each UE in that region gets (radio) signal strength from two or more cells (of the same frequency) and where the received signal strength by the UE from each such cell is above a pre-specified threshold and is good enough to cause interference for UEs in this region. Note that a (virtual) region is not necessarily a fixed geographical partition as it depends on the received signal strength by the UE from different neighboring cells.

[0115] Non-overlapping (or non-interfering) regions are those (virtual) regions where each UE in that region is served by its serving cell only and does not experience interference from any neighboring cell.

[0116] Overlapping (or interfering) and non-overlapping (or non-interfering) regions for UEs for the example scenario considered in FIG. 13A are listed below:

[0117] If I-UE(y) = {c(jl, kl), c(hl, k2)} for any UEy, this UE is classified to be part of region Rl. Thus this region R1 includes those UEs for which received signal strength from c(j 1, kl) and c(hl, k2) is above a threshold (which is good enough to cause interference for UEs in this region Rl). For UEs in this region Rl, received signal strength from cell c(nl, k3) is very low and below a (pre-specified) threshold.

[0118] If I-UE(x) = {c(j 1, kl), c(hl, k2), c(nl, k3)} for any UE x, this UE x is part of Region R2. Each UE in region R2 gets served by one of the cells from the set I-UE(x) and experiences interference from other cells from the set I-UE(x).

[0119] If I-UE(vl) = {c(hl, k2), c(nl, k3)} for any UE vl, this UE is classified to be part of Region R3. Each UE in region R3 gets served by one of the cells from the set I-UE(vl) and experiences interference from other cells from the set I-UE(vl).

[0120] If I-UE(v2) = { c(j 1, kl), c(nl, k3)} for any UE v2, this UE is classified to be part of Region R4. Each UE in region R4 gets served by one of the cells from the set I-UE(v2) and experiences interference from other cells from the set I-UE(v2).

[0121] If I-UE(hl) = {c(jl, kl)} for any UE hl, this UE is classified to be part of Region R5. UEs in region R5 get served by cell c(jl,kl) and do not experience interference from any other cell in the example considered here.

[0122] If I-UE(h2) = {c(nl,k3)} for any UE h2, this UE is classified to be part of Region R6. UEs in region R6 get served by cell c(nl,k3) and do not experience interference from any other cell in the example considered here.

[0123] If I-UE(h3) - {c(hl, k2)} for any UE h3, this UE is classified to be part of Region R7. UEs in region R7 get served by c(hl,k2) and do not experience interference from any other cell in the example considered here.

[0124] For the example shown in FIG. 13A, cell c(j 1, kl) have UEs which are in region R1 or R2 or R4 or R5. Similarly, cell c(hl, k2) have UEs which are in region R1 or R2 or R3 or R7. Also, cell c(nl, k3) have UEs which are in region R2, R3, R4 or R6.

[0125] For a given cluster of cells, a Master DU is chosen based on the configuration or using some policies. For example, DU kl is chosen as the Master DU for the example scenario shown in FIG. 13A.

[0126] Each cell corresponding to a DU which has a UE which is facing interference from the neighboring cells sends a message, CoMP_RRM_Initiate_Requestto the Master DU.

[0127] As part of CoMP_RRM_Initiate_Request, each cell informs the following to the Master DU (as shown in FIG. 14A and FIG. 14B also):Protocol version,Message category (for CoMP in this case),Massage id (for CoMP_RRM_Initiate_Request)Identity of the Source DUIdentity of the Destination DU (i.e. identity of the Master DU in thiscase]Message sequence numberCell Id, ARFCN, Bandwidth for this cell, MIMO configurationCell load (e.g., PRB utilization, number of active UEs, number of connected UEs etc.]Type of MAC scheduler being used in that cell such as Generalized Proportional Fair (GPF], Enhanced Proportional Fair, Greedy etc.Indicator to indicate if DSS (Dynamic spectrum sharing] is being used in that cell (and related parameters if DSS is being used]Timestamp when this message is sentNumber of (virtual] regions of this cell (as estimated by the requesting DU]. For example, a cell can have 3 virtual regions (or higher or lower]Bitmap to indicate (virtual] regions for which additional information is included. Each bitindicates whether or not additional information for that region is included in that messageInformation specific to each of the virtual regions of this cell

[0128] Information specific to each of the virtual region of the cell which is communicated to the Master DU as part of CoMP_RRM_Initiate_Request includes the following (as also shown in FIG. 14B]:Region id (or region identifier] for which following information is being communicated from the corresponding cell to the Master DUNumber of UEs with active DRBs (Data Radio Bearers] in this regionNumber of DRBs with their corresponding 5QIs. For example, if UEs in that region have total of 50 DRBs and if these DRBs correspond to 5 QoS classes, value of number of (QoS Class, number of DRBs for this QoS Class) pairs can be 5. Here, QoS class refers to 5QI for 5G networks and QCI for 4G networks.Sub-band CSI reports of the UEs from this (virtual) regionRadio Quality Indicator (RQI) for UEs for this (virtual) region. This RQI can be computed taking into radio conditions of the UE, channel bandwidth of the cell, MIMO configuration of the cell and other factors. RQI for each UE from this region can be communicated. Alternatively, this information can be communicated in condensed format. For example, UEs can be divided into certain number of groups based on RQIs and number of UEs in each group (along with group related information) can be communicated to reduce the overhead over the D2 interface.Aggregate data rate requirements of GBR data bearers for this regionReserved bitsIdentifiers of cells which cause interference for UEs in this (virtual) region. Identifiers of these cells help define this virtual region.Number of UEs from this region which are involved for CA (Carrier Aggregation) and identity of these other CCs (Component Carriers) which are being used for CA

[0129] Other related parameters and reserved bits (as needed) can also be included in the CoMP_RRM_Initiate_Request message as shown in FIG. 14B.

[0130] Contents of CoMP_RRM_Initiate_Request message (which is sent via D2AP protocol over D2-C interface) from a cell (and its corresponding DU) to the Master DU are shown in FIG. 14A and FIG. 14B and explained above. Note that FIG. 14B is continuation of FIG. 14A and these are sent in the same CoMP_RRM_Initiate_Request message. Note that FIG. 14A uses Message Category as 4 (for CoMP) and Message id as 1 (for CoMP_RRM_Initiate_Request) but other suitable values can be used too.

[0131] Master DU analyzes information received from various cells (and their corresponding DUs) for UEs associated with different regions and decides the PRBs to be blanked along with a time interval for each cell (as needed for CoMP). Note that “PRBs to be blanked” does not necessarily mean that these PRBs are to be fully blanked. A cell can still use these PRBs by transmitting over these PRBs with lower transmit power (and thus use for UEs which are close to the base station and not in the overlapping areas of neighboring cells). The Master DU sends CoMP_RRM_Response message to each such cell (and corresponding DU) with this decision.

[0132] FIG. 13B shows the case where Master DU, DU(kl), sends CoMP_RRM_Response to DU(k3) and DU(k2) in response to CoMP_RRM_Initiate_Request message sent by DU(k3) and DU(k2) to DU(kl).

[0133] As part of CoMP_RRM_Response message from the Master DU to each cell (and the corresponding DU from where CoMP_RRM_Initiate_Request message was sent to the Master DU), following is provided (and this is shown in FIG. 15A and 15B too):Protocol version number,Message category (for CoMP),Message id (for CoMP_RRM_Response message)Identity of the Source DU. In this case, source DU is the Master DU as it is sending this Response message to a cell hosted on another DU.Identity of the Destination DUMessage sequence numberCell idTimestamp when this message was sentNumber of (virtual) regions of this cell (as estimated by the Master DU)Bitmap to indicate (virtual) regions for which additional information is included. Each bit indicates whether or not additional information for that region is included in that messageInformation specific to each of the virtual regions of this cell

[0134] Additional information provided for each region of this cell in the CoMP_RRM_response message contains the following:Region id- Time interval (tx, ty) for which CoMP (or RRM) decisions are sent as part of this message from the Master DU- An indicator field indicating if this message communicates usable PRBs for this region or the set of PRBs to be blanked for this regionReserved bitsSet of usable PRBs for this region of the cell for the time interval (tx, ty). It is denoted as usablePRBs(cell id, Region id, (tx, ty))Set of PRBs which should be blanked for UEs in this region for this cell for the time interval (tx, ty). This set is denoted astobeBlankedPRBs(cell id, Region id, (tx, ty))

[0135] As in FIG. 15B, other related parameters (and reserved bits as needed) can also be included in the CoMP_RRM_Response message.

[0136] FIG. 15A and FIG. 15B also shows some of the contents carried in the CoMP_RRM_Response message. Note that FIG. 15B is continuation of FIG. 15A and both of these are sent as part of the same CoMP_RRM_Response message.

[0137] As in FIG. 15B, each CoMP_RRM_Response message provides set of PRBs which can be used or are to be blanked for each region of a cell for a given time interval such as (tx, ty) where ty is greater than tx. Multiple such responses are sent for different consecutive time intervals in response to CoMP_RRM_Initiate_Request message as shown in FIG. 16A.

[0138] Note that FIG. 15A uses Message Category as 4 (for CoMP) and Message id as 2 (for CoMP_RRM_Response) but other suitable values can be used too.

[0139] As in FIG. 16A, each cell which received CoMP_RRM_Response from the Master DU, provides performance feedback to the Master DU. This performance feedback is provided using CoMP_RRM_Perf_Feedback message as shown in FIG. 16A and FIG. 16B.

[0140] As part of CoMP_RRM_Perf_Feedback, each cell informs the following to Master DU (as shown in FIG. 16B too):Protocol version,Message category (for CoMP),Massage id (for CoMP_RRM_Perf_Feedback)Identity of the Source DUIdentity of the Destination DU (i.e. identity of Master DU in this case)Message sequence number- Cell Id, ARFCNNumber of (virtual) regions of this cell for which additional information is includedBitmap to indicate (virtual) regions for which additional information is included. Each bit indicates whether or not additional information for that region is included in that message Timestamp when this message is sentInformation specific to each of the virtual regions of this cell. This includes region id and RRM (or CoMP) efficiency measure for this region. For example, it can indicate percentage of DRBs which are able to meet their QoS requirements in that region of the cell.

[0141] Note that FIG. 16B uses Message Category as 4 (for CoMP) and Message id as 10 (for CoMP_RRM_Perf_Feedback) but other suitable values can be used too.

[0142] Some of the parameters which were communicated as part of CoMP_RRM_Initiate_Request message from a cell to the Master DU can change. For example, some UEs can move from one region to another region of that cell or can get handed over to a different cell or new UEs can be handed over to this cell. For such cases, that cell sends CoMP_RRM_Update_Request as shown in FIG. 17. Local CoMP module of a cell can decide to trigger this message based on certain events (e.g. when number of UEs in a region has changed beyond a pre-specified threshold).

[0143] Contents of CoMP_RRM_Update_Request are shown in FIG. 18A and FIG. 18B. Some of the fields (such as cell load, number of UEs in a region etc.) can carry absolute values in this update request (as per the current situation in the cell) or can carry relative differences from the absolute values communicated in the CoMP_RRM_Initiate_Request. As shown in FIG. 18B, this update message carries information only for those regions of a cell where something has changed which needs to be communicated to the Master DU.

[0144] Note that FIG. 18A uses Message Category as 4 (for CoMP) and Message id as 3 (for CoMP_RRM_Update_Request) but other suitable values can be used too. Also note that FIG. 18B is continuation of FIG. 18A and both of these are sent as part of the same CoMP_RRM_Update_Request message.

[0145] If CoMP_RRM_Update_Request message is being sent from a cell to the Master DU, it can also communicate efficiency measure for each region of that cell and in that case, CoMP_RRM_Perf_Feedback message does not need to be sent separately.

[0146] For inter-DU CoMP scenarios, cells which are not hosted on the Master DU communicate CoMP_RRM_Initiate_Request and CoMP_RRM_Update_Request messages to the Master DU via the D2 interface. Also, the Master DU communicates CoMP_RRM_Response to cells which are not hosted on the Master DU via the D2 interface.

[0147] For cells which are hosted on the Master DU itself, communication between CoMP decision making entity at the Master DU and different cells at Master DU is internal to DU but this also uses the CoMP RRM initiate, response, update and performance feedback messages as described earlier. This is also the case for intra-DU CoMP.

[0148] As a result of above CoMP operation, each PRB in a given region of a cell is either usable for that region in that cell or is not usable (and is to be blanked) for that region in that cell.

[0149] FIG. 19 shows (part of) this for the cell c(nl,k3) for the example considered in FIG. 13A where this cell has four regions (indicated as R2, R3, R4 and R6 in FIG. 13A). Each PRB in FIG. 19 is either usable or not usable (and this needs to blanked) for each of the regions R2, R3, R4 and R6. Also, this marking as usable or to be blanked will keep changing with time in typical deployment scenarios.

[0150] For the example scenario considered in FIG. 13A, the Master DU, DU(kl), informs cell c(nl,k3) about the resources (i.e. PRBs) which this cell can use for each of its regions and the resources which are to be blanked for each of its regions with the above CoMP operation:Region id of Set of usable PRBs for different Set of PRBs to be blanked for cell c(nl,k3) regions at the cell c(nl,k3) different regions at the cell during the time interval (tx, ty) c(nl.k3) during the time interval(tx, ty)R2 of cell usablePRBs(c(nl,k3), R2, tobeBlankedPRBs(c(nl,k3), R2, c(nl,k3) (tx,ty)) (tx,ty))R3 of cell usablePRBs(c(nl,k3), R3, tobeBlankedPRBs(c(nl,k3), R3, c(nl,k3) (tx,ty)) (tx,ty))R4 of cell usablePRBs(c(nl,k3), R4, tobeBlankedPRBs(c(nl,k3), R4, c(nl,k3) (tx,ty)) (tx,ty))R6 of cell usablePRBs(c(nl,k3), R6, tobeBlankedPRBs(c(nl,k3), R6, c(nl,k3) (tx,ty)) (tx,ty))Table 2: Set of usa )le and 'to be blanked’ PRBs for different regions of cell c(nl,k3) at DU k3

[0151] Similarly, Master DU, DU(kl), informs cell c(hl,k2) at DU k2 about the resources (i.e., PRBs) which this cell can use for its different regions and the resources which need to blanked for different regions of this cell with the above CoMP operation:Region id of cell c(hl,k2) Set of usable PRBs for Set of PRBs to be blanked different regions of the cell for different regions of the c(hl,k2) during the time cell c(hl,k2) during the interval (tx, ty) time interval (tx, ty) R1 of cell c(hl,k2) usablePRBs(c(hl,k2), Rl, tobeBlankedPRBs(c(hl,k2),(tx,ty)) Rl, (tx,ty))R2 of cell c(hl,k2) usablePRBs(c(hl,k2), R2, tobeBlankedPRBs(c(hl,k2),(tx,ty)) R2, (tx,ty))R3 of cell c(hl,k2) usablePRBs(c(hl,k2), R3, tobeBlankedPRBs(c(hl,k2),(tx,ty)) R3, (tx,ty))R7 of cell c(hl,k2) usablePRBs(c(hl,k2), R7, tobeBlankedPRBs(c(hl,k2),(tx,ty)) R7, (tx,ty))Table3: Set of usable and 'to 3e blanked’ PRBs for different regions of cell c(hl,k2) at DU k2

[0152] Also, cell c(jl,kl) which is hosted at the (Master) DU kl itself, is directly informed about the resources (i.e., PRBs) which this cell can use for its different regionsand the resources which need to blanked for different regions of this cell with the above CoMP operation:Region id of cell Set of usable PRBs for Set of PRBs to be blanked c(jl,kl) different regions of the for different regions of the cell c(jl,kl) during the cell c(j l,kl) during the time time interval (tx, ty) interval (tx, ty)R1 of cell c(jl,kl) usablePRBs(c(jl,kl), Rl, tobeBlankedPRBs(c(j l,kl),(tx,ty)) R1, (tx,ty))R2 of cell c(j1,k1) usablePRBs(c(j1,k1), R2, tobeBlankedPRBs(c(j1,k1),(tx,ty)) R2, (tx,ty))R4 of cell c(j1,k1) usablePRBs(c(j1,k1), R4, tobeBlankedPRBs(c(j1,k1),(tx,ty)) R4, (tx,ty))R5 of cell c(j1,k1) usablePRBs(c(j1,k1), R5, tobeBlankedPRBs(c(j1,k1),(tx,ty)) R5, (tx,ty))Table 4: Set of usable and 'to be blanked’ PRBs for different regions of cell c(jl,kl)

[0153] Method IA takes CoMP related decisions for inter-DU and intra-DU scenarios. FIG. 13B shows some of the messages used across D2 interface for inter-DU CoMP with this Method.

[0154] Meth od IB (AIML Assisted LESS)

[0155] Each cell also runs low energy scheduling solution (LESS) to help save energy at the base station. As part of this operation, an energy saving module for each cell finds time intervals where DU for that cell does not communicate any data with the UEs in that cell and such time intervals can be used by the RU to switch to energy saving state. As part of this, an energy saving metric at time t, denoted as pES(t), is computed for each cell. Some of the factors that this metric takes into account are listed below:QoS indicator (e.g. 5QI in 5G networks or QCI in 4G networks) of each logical channel for which packets are being communicated for that cell,Buffer Occupancy (BO) of each logical channel in the RLC queues in DU,Latency constraints (and observed latency for different packets) for applications for which data is being carried by the DRBs of that UE,Data rate requirements for GBR applications andLoad in that cell (e.g., in terms of PRB utilization, number of active users and other factors),Radio conditions of the UEs,other factors depending on various policies

[0156] In the method specified here, buffer occupancy (BO) is modeled as a Time Series for each logical channel (or DRB) and its value is predicted for next few slots using LSTM or Transformer or other DNN (Deep Neural Networks) based models. Similarly, cell load (e.g., in terms of percentage PRB utilization) is modeled as a Time Series and its value is predicted for next few slots using LSTM or Transformer or other DNN based models.

[0157] Next, an enhanced energy saving metric, denoted asis computed as follows:PESe(t)=w0* pES(t) + ∑k=1mwk* pESpred(t + k)= w0* ρES(t) + wx* p£Jed(t+l) + w2* p^'ed(t+2) + + wm* p^ed(t+m)

[0158] Here, ρES(t), is the value of current energy saving metric computed taking into account various measured or observed parameters as discussed earlier. In general, ρES(t), can be computed using various policies.

[0159] pESpred(t + k) is the predicted value of energy saving metric computed using some predicted parameters for time slot (t+k) where k is between 1 and m as above (with m greater or equal to 1).w0is the weight assigned to ρES(t) and wkis the weight assigned to p^ed(t + fc). Also, w0+ ∑k=1mwk= 1

[0160] In one example policy, pESpred(t + k) is computed using predicted value of BO for each DRB (or LC) in that cell, QoS class for each LC in that cell and the predicted value of Cell Load for that cell.

[0161] Predicted value of BO metric pBOpred(j; t + k) for slot (t+k) is computed as follows.

[0162] BO for LC (or DRB) j for time slot t is denoted as BO(j; t). Value of BO metric for LC j for time slot t (using measured or observed data) is denoted as pB0(j; t) and it is computed as follows.. r BO0;t) JPBO(J> 0 = minimum — - —, 1kQthres(j) )

[0163] Here, Qthresh(j) for LC j is computed as minimum of Qmax(j) and Qthresh_5QI(j), i.e. Qthresh(j) = minimum {Qmax(J), Qthresh_5QI(J)}

[0164] Qmax(j), a non-zero value, is the maximum queue size for LC j for which packets belonging to LC j can be stored in the DU. It is the maximum queue size allowable for LC j for a given buffer management policy in a base station. It can also be a configured value for a given base station.

[0165] Qthresh_5QI(j), a non-zero value, is a threshold value which depends on the value of QoS class (e.g., 5QI for 5G network or QCI for 4G network) for LC j. For each QoS class, it can be separately configured for a given base station.

[0166] Value of pB0(j; t) is kept between 0 and 1 for each LC j for each time slot t.

[0167] Predicted value of BO for LC (or DRB) j for time slot ( t+k) is denoted as BOpred(j; t + fc). Predicted value of BO metric for LC j for time slot (t+k) is denoted as pBOpred(j; t + k) and it computed using predicted value of BO for time slot (t+k), i.e. using BOpred(j; t + k), as followsρBOpred(j; t + k) = minimum { BOpred(j; t)(j; t + k) = minimum { BOpred(j; t) / Qthres(j), 1 }so J( Qthres(j) J

[0168] Valueof pBOpred(j; t + k) is kept between 0 and 1 for each LC j for each slot (t+k).

[0169] For each LC (or DRB) j, another metric, ppred(J; t + k) is computed asρpred(j; t + k) = wBO* pBOpred(j; t + k) + wQoS* pQoS(j)

[0170] Here, ρQoS(j) is a metric computed for each LC j based on QoS class (i.e., 5QI for 5G networks or QCI for 4G networks) for LC j. For example, value of ρQoS(j) will be chosen to be higher than value of ρQoS(k) if LC j is carrying traffic from a delay critical application (such as voice or video conferencing) and LC k is carrying traffic from a nondelay sensitive application (such as web browsing). Value of ρQoS(j) is kept between 0 and 1 for each LC j.

[0171] Here, wBOis the weight assigned to pBOpred(j; t + k) for each LC j and can take value between 0 and 1. Also, wQoSis the weight assigned to ρQoS(j) for each LC j and can take value between 0 and 1. In addition, wBO+ wQoS= 1.

[0172] Value of ppred(j; t + k) is between 0 and 1 for each LC j for each time slot

[0173] At cell level, another metric denoted as ρaggrpred(t + k) is computed taking into account ρpred(j; t + k) for each LC j in that cell for time slot (t+k). For example, ρaggrpred(t + k) can be computed by taking (weighted) mean of ρpred(j; t + k) for each LC j in that cell. Value of ρaggrpred(t + k) is kept between 0 and 1 for each time slot (t+k) for any given cell.

[0174] This method also computes predicted value of cell load metric ρCLpred(t + k) for slot (t+k) as follows.

[0175] Cell load (e.g., PRB utilization) for a given cell for time t is denoted as CL(t). Value of cell load metric for a cell for time slot t (for LESS related decisions) is denoted as ρCL(t) and it is computed as a function of CL(t) using different policies. In general, value of ρCL(t) can decrease (or stay same) as value of cell load decreases. Value of ρCL(t) is kept between 0 and 1.

[0176] Predicted value of cell load at time (t+k) is denoted as CLpred(t + k).Predicted value of cell load metric for time slot (t+k) is denoted as pp[ed(t + k) and is computed as a function of CLpred(t + k). In general, value of pp edt + k) can decrease (or stay same) as cell load decreases in the cell. Value of pp ed(t + k) is kept between 0 and 1 for each slot (t+k).

[0177] Predicted value of energy saving metric for slot (t+k) is computed as follows:ρESpred(t + k) = y1* ρaggrpred(t + k) + y2*

[0178] Here, y1is the weight assigned to ρaggrand is assigned a value between 0 and 1. Also, y2is the weight assigned to ρCLpred(t + k) and it is assigned a value between 0 and 1. These weights are chosen such that y1+ y2= 1

[0179] As specified earlier, energy saving metric for a cell (at time slot t) is given as: PρESe(t)=w0* ρES(t) + ∑k=1mwk* ρESpred(t + k).

[0180] For a given time slott, if ρESe(t) is less than a pre-specified threshold, and if no mandatory information needs to be sent in that slot, the LESS entity at the DU can decide not to communicate data to any UE in that slot and this can be used by the PA in RU to save energy consumption.

[0181] If it is decided by the LESS entity not to serve any user in that cell at the time slot t (as described above), an additional check is done as follows for next few consecutive slots: If ρESpred(t + k) is less than a pre-specified threshold for n consecutive slots, i.e. ρESpred(t + k) < ThreshEES(t -I- k), with k varying from 1 to n, the LESS entity at the DU can decide not to serve any UE in that slot for n consecutive slots and this information is communicated to lower layers (including the RU).

[0182] Here, ThreshEES(t + k) is a threshold for time slot (t+ k). Its value can be pre-specified (or configured). An operator can specify this value taking into account goals related to carbon credits of that organization and other policies. For example, its value can also be same for each slot where predicted information is used. Alternatively, its value can decrease as k increases from 1 to n.

[0183] If it is decided to go to energy saving mode from slot t to (t+k) where k is greater than 1, energy saving metric ρESis not computed for these k slots (i.e. for slot t+1,...., t+k). Also, if mandatory system information needs to be sent in a slot, energy saving mode is not used for that slot for that cell.

[0184] This enables RU to go into energy saving mode for (1+n) consecutive slots (i.e., slot t, t+1, t+2,...., t+n) and this can help to save more power.

[0185] Method 1C (Joint Optimization of CoMP and LESS)

[0186] With CoMP and LESS modules activated at the same time for a cell, the LESS module takes into account PRBs which can be used for different regions of that cell while computing PRE utilization as a measure of cell load.

[0187] For example, LESS module (in the presence of CoMP) will consider usable PRBs for each of the region R2, R3, R4 and R6 of the cell c(nl,k3), (i.e. usablePRBs(c(nl,k3), R2, (tx,ty)), usablePRBs(c(nl,k3), R3, (tx,ty)), usablePRBs(c(nl,k3), R4, (tx,ty)) and usablePRBs(c(nl,k3), R6, (tx,ty)), and will look for utilized PRBs in each region to compute the overall PRB utilization in that cell.

[0188] In the method specified here, if the LESS module of a cell finds a time interval of length equal to or greater than a pre-specified threshold (e.g.2 time slots or 2 ms) where it is not going to communicate with any UEs in that cell, it sends a message LESS_ES_TimeSlices to the Master DU (i.e. the DU which is acting as the Master DU for the CoMP operation) as shown in FIG. 20. Here " TimeSlice” refers to " Time Interval” such as time interval (ta, tb) in FIG. 22.

[0189] Contents of this LESS_ES_TimeSlices message are given below (and shown in FIG.21 too):Protocol version,Message category (for Energy Saving),Massage id (for LESS_ES_TimeSlices)Identity of the Source DUIdentity of the Destination DU (i.e. identity of the Master DU in this case)Message sequence numberCell Id, ARFCN, Bandwidth for this cell, MIMO configurationCell load (e.g., PRB utilization)Type of MAC scheduler being used in that cell such as Generalized Proportional Fair (GPF), Enhanced Proportional Fair, Greedy etc.Indicator to indicate if DSS (Dynamic spectrum sharing) is being used in that cell (and related parameters if DSS is being used)Timestamp when this message is sentTime interval when this cell is not going to communicate with any UEs (and as discussed earlier, this time interval can be used for energy saving at the RU)Other related parameters can also be sent as part of this message

[0190] Note that FIG. 21 uses Message Category as 5 (for Energy Saving) and Message id as 1 (for LESS_ES_TimeSlices) but other suitable values can be used too.

[0191] As discussed earlier. Master DU analyzes information received as part of CoMP_RRM_Initiate_Request or CoMP_RRM_Update_Request and decides PRBs to be used or to be blanked for different regions of each cell for certain time interval (e.g., for time interval (tx, ty)) and communicates this to respective cells using the CoMP_RRM_Response message.

[0192] FIG. 22 shows an example where a cell is provided a set of PRBs which it can use in different regions of the cell during the time interval (tx, ty). This information is provided to this cell from the Master DU which is running CoMP decision making module for this cell. LESS module for this cell decides that this cell is not going to communicate with any UE during (ta, tb) and informs about this to the Master DU using the LESS_ES_TimeSlices messages.

[0193] Next, Master DU analyzes information received as part of LESS_ES_TimeSlices messages from different cells.

[0194] Note that a cell may have been allowed to use certain PRBs in each region of that cell (via the CoMP operation) but this cell is not going to use even these PRBs in certain time intervals as decided by the LESS module of that cell. For example, cell cl is not going to use any PRBs during the time interval (ta, tb) in FIG. 22 due to the LESS operation eventhough it has been allowed to use certain PRBs for each region during the time interval (tx, ty) with the CoMP operation. Note that tx < ta < tb < ty in this example scenario.

[0195] For such combined CoMP and LESS scenarios in this method, Master DU decides whether or not some of the cells can be allowed to use additional PRBs in certain regions of these cells during the time intervals when some other neighboring cells are not communicating with any UEs due to the LESS operation.

[0196] For example, cell ck in FIG. 22 is allowed to use certain additional PRBs during the time interval (tc, tb) as cell cl is not communicating with any UEs during the time interval (ta, tb). Here, ta < tc < tb. During the time interval (ta, tc), cell cl sends LESS_ES_TimeSlices message to the Master DU which decides to allow cell ck to use additional PRBs for certain regions during the time interval (tc, tb) and sends CoMP_RRM_ES_Update_Response message to cell ck along with set of additional (or usable) PRBs which this cell is allowed to use for the time interval (tc, tb).

[0197] Time interval (ta, tc) in FIG. 22 is used for transport delay from cell ck to the Master DU, processing delay at the Master DU and cell ck, and transport delay from the Master DU to cell ck. For example, one-way transport delay here can be 200 us and the time interval (tl, tc) can be 1 ms.

[0198] FIG. 22 also shows another time interval (tal,tbl) where cell cl is not going to communicate with any of its UEs as decided by the LESS module for that cell. Cell ck is given additional PRBs during the time interval (tcl,tbl) in this example using the method specified here. Here, tai < tel < tbl.

[0199] Contents of the CoMP_RRM_ES_Update_Response are given below (and shown in FIG. 23A and FIG. 23B too):Protocol version number,Message category (for Energy Saving and RRM),Message id (for CoMP_RRM_ES_Update message)Identity of the Source DU. In this case, Source DU is the Master DU as it is sending this Response message to a cell hosted on another DU.Identity of the Destination DUMessage sequence numberCell idTimestamp when this message was sentNumber of (virtual) regions of this cell.Bitmap to indicate (virtual) regions for which additional information is included. Each bit indicates whether or not additional information for that region is included in that messageInformation specific to each of the virtual regions of this cell

[0200] Additional information provided for each region of this cell in the CoMP_RRM_ES_Update_Response message contains the following:Region id

[0201] Time interval (tc, tb) for which CoMP (or RRM) decisions are sent as part of this message from the Master DUAn indicator field indicating if this message communicates usable PRBs for this region or the set of PRBs to be blanked for this regionReserved bitsSet of usable PRBs for this region of the cell for the time interval (tc, tb). It is denoted as usablePRBs(cell id, Region id, (tc, tb))

[0202] Set of PRBs which should be blanked for UEs in this region for this cell for the time interval (tc, tb). This set is denoted as tobeBlankedPRBs(cell id, Region id, (tc, tb))

[0203] This message also includes fields for other related parameters which may need to be sent and reserved bits. Note that FIG. 23B is continuation of FIG. 23A and both of these are sent as part of the same CoMP_RRM_ES_Update_Response message.

[0204] Also, note that FIG. 23A uses Message Category as 6 (for Energy Saving and RRM) and Message id as 1 (for CoMP_RRM_ES_Update_Response) but other suitable values can be used too.

[0205] In this method. Master DU sends CoMP_RRM_Response message to a cell informing it which PRBs can be used or need to be blanked for different regions of that cell for a given time interval (such as (tx,ty)). Master DU uses CoMP_RRM_ES_Update_Response message across the D2 interface to inform cell about the additional PRBs which this cell can use for a smaller time interval (such as (tc,tb)) where this smaller time interval (i.e. (tc,tb)) is a subset of the time interval (tx,ty). This is used to provide additional resources to certain cells when some cells go to energy saving mode for short time duration or due to any other policy based decisions.

[0206] This method takes CoMP related decisions for inter-DU and intra-DU scenarios and optimizes these for the case when LESS is also used in some or all the cells in a cluster of cells where CoMP is being used. FIG. 24 shows the messages used across D2 interface for inter-DU CoMP which is also optimized for LESS. Details of this method have been described above.

[0207] Method ID

[0208] In addition, Master DU analyzes variety of parameters received as part of this method and provides recommendations to improve QoS of users or to improve spectrum efficiency of a cell (or for cluster of cells] or to improve energy saving for the base station. For this purpose. Master DU sends a message, RRM_Recommendations, to a cell across the D2 interface and provides recommendations to improve QoS or spectrum efficiency or energy saving. As part of this, the Master DU recommends to move a subset of UEs from one cell (i.e., source cell] to another cell (i.e., target cell] during a certain time period.Alternatively, this recommendation can ask for this cell to accept request for movement of UEs from another cell to this cell during a certain time period. In another embodiment, Master DU interacts with Near-RT-RIC [on behalf of cluster of cells for which it is acting as the Master for CoMP and LESS related decisions] using the E2 interface and such decisions are taken jointly at the Near-RT-RIC and the Master DU.

[0209] It may not be possible for one Master DU to take CoMP and related energy saving decisions for a large-scale network due to latencies between different DUs and Master DU, and due to higher processing requirements. To deal with this, a large-scale network can be partitioned into certain clusters and there can be a one Master DU for each cluster.

[0210] Master DU for each cluster (e.g., Master DU mdul for cluster xl) processes information related to cells from its own cluster (i.e., cluster xl) and neighboring cells from other clusters which are causing interference to UEs which have serving cells in the cluster xl.

[0211] If a cell has some UEs that are experiencing interference from cells belonging to another cluster, then this cell has to send CoMP and LESS related information to Master DUs from these different cluster of cells. In this case, such a cell has to send CoMP_Initiate_RRM_Request, CoMP_RRM_Update_Request and LESS_ES_TimeSlices messages to Master DUs from each of these clusters.

[0212] Alternatively, such a cell can send these CoMP and LESS related requests to one Master DU and this Master DU can send it to Master DU (of other Clusters) as needed.

[0213] These Master DUs from different Cluster of cells coordinate with each other to decide resource allocation for different regions of such cells.

[0214] Each Master DU continues to take CoMP and LESS related decisions for the cells which belong only to its cluster of cells.

[0215] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can beprovided 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 the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

Claims

CLAIMS1. A method comprisinga cell j belonging to Distributed Unit (DU) k denoted as c(j, k);interfering cells for a UE, x, denoted as I-UE(x), wherein the interfering cells include a serving cell of the interfering cells for the UE at a given point of time and other cells of the interfering cells causing interference to the UE;wherein the interfering cells each comprising coverage areas, the coverage area for each interfering cell including an overlapping coverage area and a non-overlapping coverage area;choosing a Master DU for the interfering cells;sending, by a Coordinated Multipoint Transmission (CoMP) module of each DU having a UE that experiences interference from a neighboring cell, a CoMP_RRM_Initiate_Request including cell information and virtual (or interfering) region specific information to the Master DU;analyzing, by the Master DU, the cell information and virtual region specific information and deciding Physical Resource Blocks (PRBs) to be blanked (or PRBs for which transmit power from the base station is to be reduced below a threshold) for each region of the cell along with a time interval for each cell;sending, by the Master DU, a CoMP_RRM_Response to the DUs including the PRBs to be blanked along with a time interval for each cell; andproviding, by each DU that receives the CoMP_RRM_Response, performance feedback to the Master DU in a CoMP_RRM_Perf_Feedback message.

2. The method of claim 1, wherein the CoMP_RRM_Response includes at least one of:a Region id;a time interval (tx, ty) for which CoMP or RRM decisions are sent as part of the message from the Master DU;an indicator field indicating if this message communicates usable PRBs for this region or the set of PRBs to be blanked for this region;reserved bits;a set of usable PRBs for the region of the cell for the time interval (tx, ty), usablePRBs(cell id, Region id, (tx, ty)); anda set of PRBs which should be blanked for UEs in the region (or for which transmit power should be reduced before a threshold) for the cell for the time interval (tx, ty), tobeBlankedPRBs(cell id, Region id, (tx, ty)).

3. The method of claim 1, wherein the CoMP_RRM_Perf_Feedback comprises at least one of:protocol version, Message category (for CoMP), Massage id (for CoMP_RRM_Perf_Feedback);an identity of the source DU;an identity of the destination DU;a message sequence number;a Cell Id, Absolute Radio-Frequency Channel Number (ARFCN);a number of virtual regions of the cell for which additional information is included;a bitmap to indicate virtual regions for which additional information is included;a timestamp when the message is sent; andinformation specific to each of the virtual regions of the cell, including region id and Radio Resource Management(RRM) or CoMP efficiency measure for the region.

4. The method of claim 1, further comprising:sending, by the DU when a parameter of the DU's CoMP_RRM_Update_Request has changed, a CoMP_RRM_Update_Request to the Master DU.

5. The method of claim 1, further comprising:sending the CoMP_RRM_Initiate_Request, the CoMP_RRM_Response, and the CoMP_RRM_Perf_Feedback message over a DU - DU D2 interface when corresponding cells are located at different DUs.

6. The method of claim 1, further comprising:sending, by the DU, a Low Energy Scheduling Solution (LESS) message for saving energy at a base station, wherein an energy saving LESS module for the cell finds time intervals where the DU for the cell does not communicate any data with the UEs in that cell and such time intervals can be used by a Radio Unit (RU) to switch to energy saving state.

7. The method of claim 6, wherein the energy saving LESS module comprises an Artificial Intelligence and Machine Learning (AI / ML) supported LESS module.

8. The method of claim 6, further comprising:computing an energy saving metric at time t, ρES- (t), for each cell;computing a metric, ρpred(j; t + k), for each LC j for time slot (t+k), taking into account predicted value of buffer occupancy and QoS class for that LC;computing an aggregate metric for all LCs in that cell, ρaggrpred(t + k), taking into account pρpred(j; t + k) for each LC j in that cell for time slot (t+k);computing a predicted value of cell load metric ρCLpred(t + k) for slot (t+k); computing predicted value of ρES- for time slot (t+k), ρESpred(t + k), using ρCLpred(t + k) and Pagegdrt + k)>' computing an enhanced energy saving metric at time t, ρESe(t) using Pzs^tt + k) for the predicted values for the time interval [t, t+k] and current value ρES(t) for time t,wherein, if a given time slot t, if ρESe(t) is less than a pre-specified threshold, and if no mandatory information needs to be sent in that slot, the DU can decide not to communicate data to any UE in that slot to save energy consumption.

9. The method of claim 6, further comprising:sending the LESS message over a DU - DU D2 interface when corresponding cells are located at different DUs.

10. The method of claim 6, further comprising:when the CoMP module and the LESS module are activated at the same time for a cell, the CoMP module and the LESS module determine which PRBs can be used for different regions of the cell while computing PRE utilization as a measure of cell load.

11. The method of claim 10, further comprising:sending, by the DU when the LESS module finds a time interval of length equal to or greater than a pre-specified threshold where it is not going to communicate with any UEs in that cell, a LESS_ES_TimeSlices message to the Master DU;analyzing, by the Master DU, information of different cells received from the LESS module and the CoMP module;sending, by the Master DU, a CoMP_RRM_ES_Update_Response message to other cells to allow certain cells to use additional PRBs for a time period if their interfering cells are not using PRBs due to activation of energy saving via the LESS module.

12. The method of claim 11, further comprising:sending the LESS_ES_TimeSlices message and the CoMP_RRM_ES_Update_Response message over a DU - DU D2 interface when corresponding cells are located at different DUs.

13. The method of claim 11, wherein the LESS_ES_TimeSlices message includes at least one of:a protocol version and message category;a message id;an identity of the Source DU;an identity of the destination DU;a message sequence number;a Cell Id, Absolute Radio-Frequency Channel Number ARFCN, bandwidth for the cell, and Multiple Input Multiple Output (MIMO) configuration;a Cell load;a timestamp when the message is sent; anda time interval when this cell is not going to communicate with any UEs.

14. The method of claim 11, wherein the CoMP_RRM_ES_Update_Response message includes at least one of:a protocol version and message category;a message id;an identity of the Source DU;an identity of the destination DU;a message sequence number;a Cell id;a timestamp when the message is sent;a number of virtual regions of the cell;a Bitmap to indicate the virtual regions for which additional information is included, wherein each bit indicates whether or not the additional information for the virtual regions is included in that message;information specific to each of the virtual regions of the cell;Region id;a time interval (tc, tb] for which CoMP (or RRM) decisions are sent as part of the message from the Master DU;an indicator field indicating if this message communicates usable PRBs for this region or the set of PRBs to be blanked for this region; anda set of usable PRBs for this region of the cell for the time interval (tc, tb],15. The method of claim 6, further comprising:analyzing, by the Master DU, COMP parameters and / or LESS parameters; and providing recommendations to improve QoS of users or to improve spectrum efficiency of a cell or to improve energy saving for the base station.