Description:TECHNICAL FIELD
[0001] The present disclosure relates to wireless communication and networks and more specifically relates to methods and a network controller for handling energy optimization in a disaggregated fifth-generation radio access network (5G RAN).

BACKGROUND
[0002] Energy costs for telecom operators can be as high as 10% of the total operating expenditure. Various studies and researches show that about a third of RAN (Radio Access Network) capacity can be put to “sleep” at various hours of low loads without affecting customer experience. In order to ensure service availability, a minimum number of coverage cells is to be kept on all the time and then selectively put other cells in the coverage area (“capacity cells”) to sleep or wake them up, based on traffic. But, in the fifth generation (5G) context, the coverage cells can be the adequate minimum number of macro cells and capacity cells can be the remaining macro cells and small cells in a coverage footprint of the macro cells. Both macro cells and small cells provide 5G connectivity, and their signal propagation and building penetration capabilities differ greatly. Signal propagation and coverage radius are the key difference between the macro cells and the small cells. The macro cells provide low-frequency coverage for miles, while the small cells provide high-frequency coverage for around 100 yards. Below are described some energy saving schemes in the 5G RAN:
[0003] FIG. 1 is an example graph (100) illustrating a capacity that can be put to sleep and woken up based on a need basis, according to the prior art. The overall capacity in a given region is based on one or more cells that can serve that region. The cellular geographic service area is a combination of the service areas of different cells that serve a specific region. These cells could have different operating frequency ranges, and different service areas based on the site locations for the cells, different spectral efficiencies of the cells, the transmission power utilized by the cell, the signal reception sensitivity of a cell, the number of transmitting and receiving antennas, advanced techniques such as MIMO (for both transmission and reception) and beam-forming capabilities, the azimuth and tilt associated with these antennas, etc. The available capacity at a serving region is dependent on the ability of the different cells across different sites to serve that location or region. It is desirable that each serving region can always provide at least a minimum capacity utilizing one or more available cells in that region. As the traffic load increases in that serving region, additional cells could be turned on to provide additional capacity in the serving region. Conversely, as the traffic load reduces, such additional cells can be turned off to reduce the available dynamic capacity in that serving region while ensuring that the required minimum capacity requirements are met.
[0004] FIG. 2 is an example scenario (200) in which radio units (RUs) are put to sleep/woken up based on a load, according to the prior art. As shown in FIG. 2, the RUs can be macro cells or small cells. Consider an example, 100 RUs, 10 distributed units (DUs), and 3 centralized units (CUs) are present in the network (i.e., 5G RAN). The RUs are put to sleep/woken up based on the load, so as to save energy in the network. Correspondingly, the DUs and the CUs can be instantiated, managed, and scaled up/down, thereby further saving energy. In an example, 30 RUs managed by 3 DUs managed by one CU. This may save energy in the network.
[0005] FIG. 3 illustrates a spatial and temporal distribution of demand, according to the prior art. FIG. 3 shows different types of traffic distribution with different levels of peaks (p) happening at different times (t). The network resource requirements (such as the overall traffic load or the number of connected or idle devices in the network) can vary as a function of time (temporally) at a given location. For example, such resource requirements can experience peaks at different times such as in the mid-morning or late afternoon or evening and taper off in the wee hours of the morning. The extent of this demand can also vary spatially. For example, the magnitude of the traffic load can vary in different serving regions at a given time (such as at 10 am). Thus, the demand on the network can vary both spatially and temporally.
[0006] WO2021048831A1 discloses a method performed by a non-real time radio access network intelligent controller (Non-RT-RIC) network node that obtains data to improve radio resource management (RRM) of a radio access network (RAN).
[0007] A non-patent literature entitled “Capacity dimensioning for 5G mobile heterogeneous networks” discloses an interface through which the macro cell can manage the small cells. The interface will allow the macro cell to activate/deactivate the small cells for energy saving purposes and to participate in the radio resource management to help mitigate the interference.
[0008] Another non-patent literature entitled “Cloud technologies for flexible 5G radio access networks” discloses that 5G backhaul networks are more flexible and adaptive to the use cases and actual traffic as well as service characteristics. Depending on the user demand and network status, the network controller may switch off jointly parts of the RAN and backhaul to reduce energy consumption.
[0009] Another existing systems and methods have implemented node sleep and wake up as a Distributed Self-Organizing Network (DSON) functionality in a node (e.g., eNB/gNB or the like). Further, according to other existing systems and methods, sleep/wake-up is provided based on load thresholds or based on Radio Resource Control (RRC) connections and Primary Resource Block (PRB) utilization, which are configurable parameters.
[0010] Conclusively, the deficiencies of the existing systems and methods are: sleep/wake up is done on a node-by-node basis (i.e., no holistic view of the network), the sleep/wakeup thresholds are to be manually determined and managed for each site, hardwired wakeup strategy, (i.e., in an example, when the load on coverage cells go up, all capacity cells are woken up to protect performance), difficult to coordinate with other applications, slow wake-up time, and performance loss issues, to name a few. Further, none of the prior art references discloses energy consumption optimization in a disaggregated radio access network (RAN) without any human intervention. In light of the above-stated discussion, there is a need to overcome the above stated disadvantages.

OBJECT OF THE DISCLOSURE
[0011] A principal object of the present disclosure is to provide methods and network controllers to optimize energy consumption in a disaggregated RAN. The proposed disclosure can be used to provide a policy-driven sleep/wake-up strategy that is pushed into xApps in a Near-Real Time RAN Intelligent Controller (Near RT-RIC) from rApps in a Non-Real Time RAN Intelligent Controller (Non-RT-RIC). The sleep/wake-up strategy is automatically and adaptively adjusted on a fly by the xApps in accordance with the policies set by the rApps based on performance.

SUMMARY
[0012] Accordingly, the present disclosure provides methods and a network controller to optimize energy consumption in a disaggregated RAN. The disaggregated RAN network is defined by a plurality of sites, where each site has a plurality of cells. The method includes managing, by a network controller, at least one of a site sleep threshold and a site wakeup threshold for one or more sites in the disaggregated RAN network. The plurality of cells comprises at least one of a plurality of macro cells, a plurality of micro cells and a plurality of small cells. The at least one of the site sleep threshold and the site wakeup threshold for the one or more sites from the plurality of sites in the disaggregated RAN network are managed by checking one or more site-states for the one or more sites in the disaggregated RAN network by the network controller through network interfaces, determining and informing about the one or more site-states of a cell, configuring the cell in at least one of radio unit (RU) and a distributed unit (DU), updating the one or more site-states by the network controller, and maintaining a dynamic database of the one or more site-states by the network controller. The cell-state comprises at least one of an inactive cell-state, an active cell-state, and a reactivable cell-state. The one or more site states correspond to number of cells in at least one of an inactive state, an active state and a reactivable state.
[0013] Alternatively, the at least one of the site sleep threshold and the site wakeup threshold for the one or more sites in the disaggregated RAN network are managed by re-activating each cell in response to determining traffic usage for each cell and monitoring performance in neighborhood of inactive cells.
[0014] These and other aspects herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the invention herein without departing from the spirit thereof.

BRIEF DESCRIPTION OF FIGURES
[0015] The invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the drawings. The invention herein will be better understood from the following description with reference to the drawings, in which:
[0016] FIG. 1 is an example graph illustrating a capacity that can be put to sleep and woken up based on a need basis, according to the prior art.
[0017] FIG. 2 is an example scenario in which RUs are put to sleep/woken up based on a load, according to the prior art.
[0018] FIG. 3 illustrates a spatial and temporal distribution of demand, according to the prior art.
[0019] FIG. 4 illustrates an overview of general O-RAN architecture.
[0020] FIG. 5 illustrates a high level architecture in which a disaggregated RAN network optimizes energy consumption, according to the present disclosure.
[0021] FIG. 6 illustrates various operations to optimize energy consumption in the disaggregated RAN network explained in conjunction with FIG. 5.
[0022] FIG. 7 is a flow chart illustrating a method to optimize the energy consumption in the disaggregated RAN network, according to the present disclosure.

DETAILED DESCRIPTION
[0023] In the following detailed description of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be obvious to a person skilled in the art that the invention may be practiced with or without these specific details. In other instances, well known methods, procedures and components have not been described in details so as not to unnecessarily obscure aspects of the invention.
[0024] Furthermore, it will be clear that the invention is not limited to these alternatives only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without parting from the scope of the invention.
[0025] The accompanying drawings are used to help easily understand various technical features and it should be understood that the alternatives presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.
[0026] The present disclosure provides methods and network controllers to optimize energy consumption in a disaggregated RAN network. The disaggregated RAN network is defined by a plurality of sites, where each site has a plurality of cells. The method includes managing, by a network controller, at least one of a site sleep threshold and a site wakeup threshold for one or more sites in the disaggregated RAN network. The plurality of cells comprises at least one of a plurality of macro cells, a plurality of micro cells and a plurality of small cells.
[0027] The deficiencies in previous techniques (as discussed in the background section) can be solved by the proposed disclosure that can be used for enabling energy savings in the disaggregated RAN architecture using a non-RT-RIC/rApp(s). The non-RT-RIC has visibility to multiple radio units, hence holistic sleep/wake-up decisions can be made. Further, the proposed method provides a policy driven sleep/wake-up strategy making the management of this capability easier and efficient. The non-RT-RIC provides flexibility and control to re-assure that no performance degradation is caused. The proposed method creates an AI/ML (Artificial Intelligence/Machine Learning) based sleep policy, so that the sleep strategy could be automatically adjusted without any human intervention, adaptively and coordination and conflict resolution with other automation capabilities can easily be done. The overall strategy for turning small cells on/off for energy savings is avoiding a bad “side effect” of densification. Because of the continuous traffic growth in mobile broadband, mobile network deployments are adapted to cope with the high demand. Two of the requirements for 5G networks are to provide extreme network capacity and extreme data rates for the users and for both the requirements, the densification of the RAN plays a key role. The network densification is done by deploying more macro cell sites and maintaining a homogeneous network. This approach reduces the Inter-Site Distance (ISD), thus increasing the traffic per square km without a corresponding increase in the traffic that needs to be handled by each macro cell.
[0028] Now referring to the figures, where FIG. 4 illustrates a general overview architecture of an O-RAN (400). The O-RAN (400) is a part of a telecommunications system which connects individual devices to other parts of a network through radio connections. The O-RAN (400) provides a connection of user equipment (UE) such as mobile phones or computer with a core network of the telecommunication systems. The RAN is an essential part of the access layer in the telecommunication systems which utilizes base stations (such as eNodeB, and gNodeB) for establishing radio connections. The O-RAN (Open-Radio Access Network) (400) is an evolved version of prior radio access networks, making the prior radio access networks more open and smarter than previous generations. The O-RAN (400) provides real-time analytics that drives embedded machine learning systems and artificial intelligence back end modules to empower network intelligence. Further, the O-RAN (400) includes virtualized network elements with open and standardized interfaces. The open interfaces are essential to enable smaller vendors and operators to quickly introduce their own services, or enables operators to customize the network to suit their own unique needs. Open interfaces also enable multivendor deployments, enabling a more competitive and vibrant supplier ecosystem. Similarly, open-source software and hardware reference designs enable faster, more democratic and permission-less innovation. Further, the O-RAN (400) introduces a self-driving network by utilizing new learning-based technologies to automate operational network functions. These learning-based technologies make the O-RAN intelligent. Embedded intelligence, applied at both component and network levels, enables dynamic local radio resource allocation and optimizes network wide efficiency. In combination with O-RAN’s open interfaces, AI-optimized closed-loop automation is a new era for network operations.
[0029] The O-RAN (400) may comprise a Service Management and Orchestrator (SMO) (can also be termed as “Service Management and Orchestration Framework”) (402), a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) (404) residing in the SMO (402), a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (406), an Open Evolved NodeB (O-eNB) (408), an Open Central Unit Control Plane (O-CU-CP) (410), an Open Central Unit User Plane (O-CU-UP) (412), an Open Distributed Unit (O-DU) (414), an Open Radio Unit (O-RU) (416), and an Open Cloud (O-Cloud) (418).
[0030] The SMO (402) is configured to provide SMO functions/services such as data collection and provisioning services of the ORAN (400). The data collection of the SMO (402) may include, for example, data related to a bandwidth of a wireless communication network and at least one of a plurality of user equipments (not shown in figures). That is, the SMO (402) oversees all the orchestration aspects, management and automation of ORAN elements and resources and supports O1, A1 and O2 interfaces.
[0031] The Non-RT-RIC (404) is a logical function that enables non-real-time control and optimization of the ORAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT-RIC (406). It is a part of the SMO Framework (402) and communicates to the Near-RT-RIC (406) using the A1 interface. The Near-RT-RIC (406) is a logical function that enables near-real-time control and optimization of the O-RAN elements and resources via fine-grained data collection and actions over E2 interface.
[0032] Non-Real Time (Non-RT) control functionality (>1s) and Near-Real Time (Near-RT) control functions (<1s) are decoupled in an RIC (RAN Intelligent Controller). The Non-RT functions include service and policy management, RAN analytics and model-training for some of the near-RT-RIC functionality, and non-RT-RIC optimization.
[0033] The O-eNB (408) is a hardware aspect of a fourth generation RAN that communicates with at least one of the plurality of user equipments via wireless communication networks such as a mobile phone network. The O-eNB (408) is a base station and may also be referred to as e.g., evolved Node B (“eNB”), “eNodeB”, “NodeB”, “B node”, gNB, or BTS (Base Transceiver Station), depending on the technology and terminology used. The O-eNB (408) is a logical node that handles the transmission and reception of signals associated with a plurality of cells (not shown in figures). The O-eNB (408) supports O1 and E2-en interfaces to communicate with the SMO (402) and the Near-RT-RIC (406) respectively.
[0034] Further, the O-CU (Open Central Unit) is a logical node hosting RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol) and PDCP (Packet Data Convergence Protocol). The O-CU is a disaggregated O-CU and includes two sub-components: O-CU-CP (410) and O-CU-UP (412). The O-CU-CP (410) is a logical node hosting the RRC and the control plane part of the PDCP. The O-CU-CP (410) supports O1, E2-cp, F1-c, E1, X2-c, Xn-c and NG-c interfaces for interaction with other components/entities.
[0035] Similarly, the O-CU-UP (412) is a logical node hosting the user plane part of the PDCP and the SDAP and uses O1, E1, E2-up, F1-u, X2-u, NG-u and Xn-u interfaces.
[0036] The O-DU (414) is a logical node hosting RLC/MAC (Medium access control)/High-PHY layers based on a lower layer functional split and supports O1, E2-du, F1-c, F1-u, OFH CUS–Plane and OFH M-Plane interfaces.
[0037] The O-RU (416) is a logical node hosting Low-PHY layer and RF (Radio Frequency) processing based on a lower layer functional split. This is similar to 3GPP’s “TRP (Transmission And Reception Point)” or “RRH (Remote Radio Head)” but more specific in including the Low-PHY layer (FFT/iFFT, PRACH (Physical Random Access Channel) extraction). The O-RU (416) utilizes OFH CUS–Plane and OFH M-Plane interfaces.
[0038] The O-Cloud (418) is a collection of physical RAN nodes (that host various RICs, CUs, and DUs), software components (such as operating systems and runtime environments) and the SMO (402), where the SMO manages and orchestrates the O-Cloud (418) from within via O2 interface. The O-Cloud (418) refers to a collection of O-Cloud resource pools at one or more location and the software to manage nodes and deployments hosted on them. The O-Cloud (418) will include functionality to support both deployment-plane and management services.
[0039] Now referring to the various interfaces used in the ORAN (400) as mentioned above.
[0040] The O1 interface is element operations and management interface between management entities in the SMO (402) and O-RAN managed elements, for operation and management, by which FCAPS (fault, configuration, accounting, performance, security) management, Software management, File management shall be achieved. The O-RAN managed elements include the Near RT-RIC (406), the O-CU (the O-CU-CP (410) and the O-CU-UP (412)), the O-DU (414), the O-RU (416) and the O-eNB (408). The management and orchestration functions are received by the aforesaid O-RAN managed elements via the O1 interface. The SMO (402) in turn receives data from the O-RAN managed elements via the O1 interface for AI model training.
[0041] The O2 interface is a cloud management interface, where the SMO (402) communicates with the O-Cloud (418) it resides in. Typically, operators that are connected to the O-Cloud (418) can then operate and maintain the O-RAN (400) with the O1 or O2 interfaces.
[0042] The A1 interface enables communication between the Non-RT-RIC (404) and the Near-RT-RIC (406) and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT-RIC (406).
[0043] The E1 interface connects the two disaggregated O-CUs i.e., the O-CU-CP (410) and the O-CU-UP (412) and transfers configuration data (to ensure interoperability) and capacity information between the O-CU-CP (410) and the O-CU-UP (412). The capacity information is sent from the O-CU-UP (412) to the O-CU-CP (410) and includes the status of the O-CU-UP (412).
[0044] The Near-RT-RIC (406) connects to the O-CU-CP (410), the O-CU-UP (412), the O-DU (414) and the O-eNB (408) (combinedly called as an E2 node) with the E2 interface (i.e., E2-cp, E2-up, E2-du and E2-en respectively) for data collection. The E2 node can connect only to one Near-RT-RIC, but one Near-RT-RIC can connect to multiple E2 nodes. Typically, protocols that go over the E2 interface are control plane protocols that control and optimize the elements of the E2 node and the resources they use.
[0045] The F1-c and F1-u interfaces (combinedly an F1 interface) connect the O-CU-CP (410) and the O-CU-UP (412) to the O-DU (414) to exchange data about frequency resource sharing and network statuses. One O-CU can communicate with multiple O-DUs via F1 interfaces.
[0046] Open fronthaul interfaces i.e., the OFH CUS-Plane (Open Fronthaul Control, User, Synchronization Plane) and the OFH M-Plane (Open Fronthaul Management Plane) connect the O-DU (414) and the O-RU (416). The OFH CUS-Plane is multi-functional, where the control and user features transfer control signals and user data respectively and the synchronization feature synchronizes activities between multiple RAN devices. The OFH M-Plane optionally connects the O-RU (416) to the SMO (402). The O-DU (414) uses the OFH M-Plane to manage the O-RU (416), while the SMO (402) can provide FCAPS (fault, configuration, accounting, performance, security) services to the O-RU (416).
[0047] An X2 interface is broken into the X2-c interface and the X2-u interface. The former is for the control plane and the latter is for the user plane that send information between compatible deployments, such as a 4G network’s eNBs or between an eNB and a 5G network’s en-gNB.
[0048] Similarly, an Xn interface is also broken into the Xn-c interface and the Xn-u interface to transfer control and user plane information respectively between next generation NodeBs (gNBs) or between ng-eNBs or between the two different deployments.
[0049] The NG-c (control plane interface) and the NG-u (user plane interface) connect the O-CU-CP (410) and the O-CU-UP (412) respectively to a 5G core. The control plane information is transmitted to a 5G access and mobility management function (AMF) that receives connection and session information from the user equipment and the user plane information is relayed to a 5G user plane function (UPF), which handles tunnelling, routing and forwarding, for example.
[0050] FIG. 5 illustrates a high-level architecture in which a disaggregated RAN network (500) optimizes energy consumption, according to the present disclosure. The disaggregated RAN network (500) is defined by a plurality of sites, where each site has a plurality of cells. The disaggregated RAN network (500) includes a network controller (518) managing at least one of a site sleep threshold and a site wakeup threshold for one or more sites in the disaggregated RAN network (500). The network controller (518) includes the Near-real-time RIC (406) and the Non-real-time RIC (404). The plurality of cells can be, for example, but not limited to a plurality of macro cells, a plurality of micro cells and a plurality of small cells. The at least one of the site sleep thresholds and the site wakeup threshold ensures service availability, and coverage cells, and selectively puts other cells in the coverage area to sleep or wake the cell(s) based on traffic.

[0051] For example, there are three cells whose service areas overlap in a given serving region. It is possible that only one of them is typically used as a coverage cell to provide at least a minimum capacity threshold, and the other two cells could be used as capacity enhancing cells which are turned on or off based on dynamic network demand. These capacity-enhancing cells can be turned on in sequence as the traffic demand progressively increases. The decision to turn a capacity-enhancing cell on or off can be based on these site wakeups (in the increasing direction) and site sleep thresholds (in a decreasing direction) being crossed respectively. In the case where there are two capacity-enhancing cells, there can be two thresholds based on the dynamic traffic demand for wakeup, wherein a first site wakeup threshold for the first capacity-enhancing cell, and a second site wakeup threshold for the second capacity-enhancing cell for a further increased demand.

[0052] Similarly, there can be two sleep thresholds based on dynamic traffic demand, the first site sleep threshold for the first capacity enhancing cell, and a higher sleep threshold for the second capacity-enhancing cell. In the simpler case, where there are just two cells whose service areas overlap in a given serving region, with one cell providing the function of a coverage cell, and the other cell providing the function of a capacity-enhancing cell. In this case, the site wakeup threshold based on increasing dynamic network demand is utilized to turn on the capacity-enhancing cell, and the site sleep threshold based on a decreasing dynamic network demand is utilized to turn off the capacity-enhancing cell. When these thresholds are a function of the network demand, the system could configure these sleep and wakeup thresholds as being identical in value. Alternatively, and preferably, the system could choose to keep the site sleep threshold lower than the site wakeup threshold for a capacity-enhancing cell and choose to keep an adequate but small separation between these threshold values which can help to avoid energy hysteresis or ping-pong effects related to rapid turning a capacity-enhancing cell on or off. In addition, the system can also seek a consistent increased network demand beyond the site wakeup threshold to turn on a capacity-enhancing cell to avoid turning on a capacity-enhancing cell based on a short transient or spurious increase in network demand. Similarly, the system can seek a consistent decreased network demand beyond the site sleep threshold to turn off a capacity-enhancing cell to avoid turning off a capacity-enhancing cell based on a short transient or spurious decrease in network demand.
[0053] The Non-real-time RIC (404) controls a RAN network node and performs a network optimisation action in the disaggregated RAN network (500), wherein the RAN network node comprises at least one of the central unit (CU or O-CU) (508) and the Distributed Unit (DU or O-DU) (414).
[0054] The at least one of the site sleep threshold and the site wakeup threshold for the one or more sites from the plurality of sites in the disaggregated RAN network (500) is managed by checking one or more site-states for the one or more sites in the disaggregated RAN network (500) by the network controller (518) through network interfaces; determining and informing about the one or more site-states of the cell; configuring the cell in at least one of the radio unit (RU or O-RU) (416) and the DU (414); updating the one or more site-states by the network controller (518); and maintaining a dynamic database (not shown) of the one or more site-states by the network controller (518). The one or more site-states for the one or more sites in the disaggregated RAN network (500) is checked by checking a cell-state for each cell of a site to arrive at the one or more site-states. The cell-state can be, for example, but not limited to an inactive cell-state, an active cell-state, and a reactivable cell-state. The one or more site-states correspond to number of cells in at least one of an inactive state, an active state and a reactivable state.
[0055] Alternatively, the at least one of the site sleep threshold and the site wakeup threshold for the one or more sites in the disaggregated RAN network (500) is managed by re-activating the cell in response to determining traffic usage for each cell and monitoring performance in neighborhood of inactive cells.
[0056] Further, one or more rApps (504) running in the SMO (402) configure one or more xApps (506) with guidance about a policy to be applied to the disaggregated RAN network (500) to manage energy and capacity of the plurality of cells. The one or more rApps (504)run in the Non-RT-RIC (404), and the one or more xApps (506) run in the Near-RT-RIC (406).
[0057] The network controller (518) updates the one or more site-states by using at least one of artificial intelligence (AI) and machine learning (ML) techniques through the one or more rApps (504) and determines coverage macro cells based on a performance requirement and a historic traffic for each macro site and underlying small cells. Further, the network controller (518) creates at least one of AI based sleep policy and an ML based sleep policy and automatically adjusts sleep time and wakeup time for the one or more sites in the disaggregated RAN network (500) based on the at least one of the AI based sleep policy creation and the ML based sleep policy creation.
[0058] The one or more rApps (504) (in the Non-RT RIC (404)) determine macro site and underlying small cells, based on performance requirements of historic traffic using the AI/ML techniques, and earmark the coverage macro cells (typically one or two low band carriers). Rest of the macro cells and small cells are capacity cells. The classification analysis of the macro site and the underlying small cells to be re-evaluated periodically. Along with that, the one or more rApps (504) determine (using AI/ML techniques applied to historic traffic data), the PRB utilization and RRC connection thresholds. These thresholds are constantly updated automatically. The sleep strategy is pushed as policies into the one or more xApps (506) in the Near-RT RIC (406). The one or more xApps (506) put cells into sleep/wakeup modes. The performance is monitored via O1 interface by the one or more rApps (504). The sleep/wakeup is then adjusted on-the fly by the one or more rApps (504) with the help of the one or more xApps (506) based on performance. The cloud resources are spun up/down based on DU/CU requirement.
[0059] The disaggregated RAN network (500) further includes a fronthaul (512) that refers to a link between the RU (416) and the DU (414), a mid-haul (514) that refers to a link between the DU (414) and the CU (508), and lastly a backhaul (516) that is representing the link between the CU (508) and a core network (510). The operations and functions of the RU (416), the DU (414) and the CU (508) are already explained in connection with FIG. 4. The disaggregated RAN network (500) also includes a RAN operation and management (O&M) function block (502) that supports network commissioning, deployment of the network nodes, O&M and monitoring of the network nodes in the disaggregated RAN network (500). Further, the RAN O&M function block (502) handles the network performance evaluation and traffic analysis in the disaggregated RAN network (500).
[0060] FIG. 6 illustrates various operations to optimize energy consumption in the disaggregated RAN network (500) explained in conjunction with FIG. 5.
[0061] At step 1, a service is established for the energy/capacity use case in the SMO (402). At Step 2, the one or more rApps (504) and the one or more xApps (506) are deployed to manage energy and capacity. The one or more rApps (504) configure the one or more xApps (506) with guidance about the use case policy. At step 3, the one or more rApps (504) and the one or more xApps (506) consume network data about usage per cell. At step 4, the one or more rApps (504) determine that cell can be de-activated to save energy, and configure the cell in the RU (416)/the DU (414). At step 5, the one or more rApps (504) send a message to the SMO (402). At step 6, the SMO (402) determines that the cloud resources (such as processing cores, or bandwidth, or memory) are typically shared across different tenants or processing threads that utilize these shared resources. If the cloud resources for a DU or RU are released, then that could be used to save energy by switching the power states of one or more servers to a lower power state or an off state. Alternatively, the released resources could be utilized by other tenants or processing threads (not related to the DU or RU processing). At step 7, the one or more xApps (506) and the one or more rApps (504) monitor performance in neighborhood of inactive cells, where the inactive cells are ready to be re-activated as needed. At step 8, the one or more rApps (504) decide that the DU (414)/the RU (416) need to be revived, and accordingly request the cloud resources. At step 9, the SMO (402) assigns the cloud resources based on the requirement. At Step 10, the cell is activated as needed.
[0062] FIG. 7 is a flow chart (700) illustrating a method to optimize the energy consumption in the disaggregated RAN network (500), according to the present disclosure.
[0063] The operation (702) is handled by the network controller (518). For the sake of brevity, the operations and functions of the network controller (518) are not repeated again in the present disclosure. At step 702, the method includes managing at least one of a site sleep threshold and a site wakeup threshold for the one or more sites in the disaggregated RAN network (500). The disaggregated RAN network (500) is defined by the plurality of sites, wherein each site has the plurality of cells.
[0064] The proposed method can be used to provide the policy driven sleep/wake-up strategy that is pushed into the one or more xApps (506) running in the Near-RT-RIC (406) from the one or more rApps (504) running in the Non-RT-RIC (404). The sleep/wake-up strategy is automatically and adaptively adjusted on the fly by the one or more xApps (506) in accordance with the policies set by the one or more rApps (504) based on performance.
[0065] The various actions, acts, blocks, steps, or the like in the flow chart (700) may be performed in the order presented, in a different order or simultaneously. Further, in some implementations, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.
[0066] The embodiments disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.
[0067] It will be apparent to those skilled in the art that other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention. While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope of the invention. It is intended that the specification and examples be considered as exemplary, with the true scope of the invention being indicated by the claims.
[0068] The methods and processes described herein may have fewer or additional steps or states and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied in, and fully or partially automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in specialized computer hardware.
[0069] The results of the disclosed methods may be stored in any type of computer data repository, such as relational databases and flat file systems that use volatile and/or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM and/or solid state RAM).
[0070] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
[0071] Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general-purpose processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
[0072] The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.
[0073] Conditional language used herein, such as, among others, "can," "may," "might," "may," “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain alternatives include, while other alternatives do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more alternatives or that one or more alternatives necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular alternative. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
[0074] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain alternatives require at least one of X, at least one of Y, or at least one of Z to each be present.
[0075] While the detailed description has shown, described, and pointed out novel features as applied to various alternatives, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the scope of the disclosure. As can be recognized, certain alternatives described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.
, Claims:We Claim:
1. A method to optimize energy consumption in a disaggregated radio access network (RAN) network (500), wherein the disaggregated RAN network (500) is defined by a plurality of sites, wherein each site has a plurality of cells, the method comprising:
managing, by a network controller (518), at least one of a site sleep threshold and a site wakeup threshold for one or more sites in the disaggregated RAN network (500).

2. The method as claimed in claim 1, wherein the plurality of cells comprises at least one of a plurality of macro cells, a plurality of micro cells and a plurality of small cells.

3. The method as claimed in claim 1, wherein managing at least one of the site sleep threshold and the site wakeup threshold for the one or more sites from the plurality of sites in the disaggregated RAN network (500) comprises:
checking one or more site-states for the one or more sites in the disaggregated RAN network (500) by the network controller (518) through network interfaces, wherein the network controller (518) comprises at least one of a Near-real-time RIC (Radio Access Network Intelligent Controller) (406) and a Non-real-time RIC (404), wherein the Non-real-time RIC (404) controls a RAN network node and performs a network optimisation action in the disaggregated RAN network (500), wherein the RAN network node comprises at least one of a central unit (CU) (508) and a Distributed Unit (DU) (414);
determining and informing about the one or more site-states of a cell;
configuring the cell in at least one of a radio unit (RU) (416) and the DU (414);
updating the one or more site-states by the network controller (518); and
maintaining a dynamic database of the one or more site-states by the network controller (518).

4. The method as claimed in claim 3, wherein checking the one or more site-states for the one or more sites in the disaggregated RAN network (500) comprises checking a cell-state for each cell of a site to arrive at the one or more site-states.

5. The method as claimed in claim 4, wherein the cell-state comprises at least one an inactive cell-state, an active cell-state, and a reactivable cell-state.

6. The method as claimed in claim 4, wherein the one or more site states correspond to a number of cells in at least one of an inactive state, an active state and a reactivable state.

7. The method as claimed in claim 1, wherein managing at least one of the site sleep thresholds and the site wakeup threshold for the one or more sites in the disaggregated RAN network (500) comprises:
determining traffic usage for each cell;
monitoring performance in the neighborhood of inactive cells; and
re-activating each cell in response to determining traffic usage for each cell and monitoring performance in the neighborhood of the inactive cells.

8. The method as claimed in claim 3, wherein at least one rApp (504) running in a Service Management and Orchestration (SMO) (402) configures at least one xApp (506) with guidance about a policy to be applied to the disaggregated RAN network (500) to manage energy and capacity of the cells, wherein the at least one rApp (504) is running in the Non-RT-RIC (404) and the at least one xApp (506) is running in the Near-RT-RIC (406).

9. The method as claimed in claim 1, wherein the at least one of the site sleep threshold and the site wakeup threshold ensures service availability, and coverage cells, and selectively puts other cells in the coverage area to sleep or wake the cell based on traffic.

10. The method as claimed in claim 3, wherein the method further comprises:
updating the one or more site-states by using at least one artificial intelligence (AI) technique and a machine learning (ML) technique through at least one rApp (504); and
determining coverage macro cells based on a performance requirement and historic traffic for each macro site and underlying small cells.

11. The method as claimed in claim 1, wherein the method further comprises:
creating, by the network controller (518), at least one of an AI based sleep policy and an ML based sleep policy; and
automatically adjusting, by the network controller (518), sleep time and wakeup time for the one or more sites in the disaggregated RAN network (500) based on the at least one of the AI based sleep policy creation and the ML based sleep policy creation.

12. A network controller (518) for optimizing energy consumption in a disaggregated radio access network (RAN) network (500), wherein the disaggregated RAN network (500) is defined by a plurality of sites, wherein each site has a plurality of cells, the network controller (518) is configured to:
manage at least one of a site sleep threshold and a site wakeup threshold for one or more sites in the disaggregated RAN network (500), wherein the network controller (518) comprises at least one of a Near-real-time RIC (Radio Access Network Intelligent Controller) (406) and a Non-real-time RIC (404).