METHOD AND APPARATUS FOR ENERGY SAVING IN A WIRELESS COMMUNICATION SYSTEM USING AN OPEN RADIO ACCESS NETWORK

Abstract

Disclosed is a method performed a network entity in a wireless communication system using an open-radio access network (O-RAN), the network entity including at least one of a non-real-time RAN intelligent controller (non-RT RIC) and near-RT RIC, the method comprises configuring at least one node with a list of cell IDs representing cells to be activated or deactivated based on a condition in a network, and transmitting, to the at least one node, information including the list of cell IDs.

Claims

1. A method performed a network entity in a wireless communication system using an open-radio access network (O-RAN), the network entity including at least one of a non-real-time RAN intelligent controller (non-RT RIC) and near-RT RIC, the method comprising: configuring at least one node with a list of cell IDs representing cells to be activated or deactivated based on a condition in a network; and transmitting, to the at least one node, information including the list of cell IDs.

2. The method of claim 1, wherein the condition includes an operational load of the at least one node.

3. The method of claim 1, wherein the network is arranged using the O-RAN.

4. The method of claim 1, wherein the at least one node is a radio access network (RAN) in the wireless communication system.

5. The method of claim 1, comprising receiving, from the at least one node, parameters representing a result of dynamic cell activation or deactivation.

6. The method of claim 1, wherein the at least one node is an E2 node.

7. The method of claim 1, wherein the information represents status of the cells set to active or inactive for energy saving in the O-RAN.

8. The method of claim 1, where the network entity dynamically controls a policy related to energy saving, the policy including cell activation or deactivation targeting thresholds.

9. The method of claim 8, wherein the network entity controls cell activation or cell deactivation of the cells.

10. A method performed by a radio access network (RAN) intelligent controller (RIC) in a wireless communication system using an open-radio access network (O-RAN), the method comprising: transmitting a RIC control request message to an E2 node associated with a cell ID contained in a control header format; and receiving a RIC control confirmation message from the E2 node, wherein the RIC control request message includes at least one of information on a RAN function and information on a service model, and information on a RIC control result.

11. The method of claim 10, wherein the information on the RIC control result includes an event occurrence reason for a RAN function specific to the service model in a specific protocol.

12. A method performed by an E2 node in a wireless communication system using an open-radio access network (O-RAN), the method comprising: receiving a RIC control request message from a RAN control controller (RIC); and transmitting a RIC control confirmation message to the RIC, wherein the RIC control request message includes at least one of information on a RAN function and information on a service model, and information on a RIC control result.

13. The method of claim 12, wherein the information on the RIC control result includes an event occurrence reason for a RAN function specific to the service model in a specific protocol.

14. A network entity in a wireless communication system using an open-radio access network (O-RAN), the network entity including at least one of a non-real-time RAN intelligent controller (non-RT RIC) and near-RT RIC, the network entity comprising: a transceiver; and a processor configured to: configure at least one node with a list of cell IDs representing cells to be activated or deactivated based on a condition in a network, and transmit, to the at least one node via the transceiver, information including the list of cell IDs.

15. The network entity of claim 14, wherein the condition includes an operational load of the at least one node.

16. The network entity of claim 14, wherein the at least one node is a radio access network (RAN) in the wireless communication system, and wherein the at least one node comprises an E2 node.

17. The network entity of claim 14, wherein the processor is further configured to receive, via the transceiver from the at least one node, parameters representing a result of dynamic cell activation or deactivation.

18. The network entity of claim 14, wherein the information represents status of the cells set to active or inactive for energy saving in the O-RAN.

19. The network entity of claim 14, where the processor is further configured to dynamically control a policy related to energy saving, the policy including cell activation or deactivation targeting thresholds.

20. The network entity of claim 19, wherein the processor is further configured to control cell activation or cell deactivation of the cells.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0037] For a better understanding of the disclosure, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which:

[0038] FIG. 1 shows a general architecture of an O-RAN system as known in the prior art;

[0039] FIG. 2 shows a flowchart depicting an energy saving procedure as known in the prior art;

[0040] FIG. 3 shows a high level architecture for energy saving O-RAN using an xApp according to an embodiment of the disclosure;

[0041] FIG. 4 shows a high level architecture for energy saving using RAN control CONTROL service style according to an embodiment of the disclosure;

[0042] FIG. 5 shows E2 control message flows and Message Information Elements according to an embodiment of the disclosure;

[0043] FIG. 6 shows RIC Control Request Message format according to an embodiment of the disclosure;

[0044] FIG. 7 shows a flowchart depicting message flow and procedure according to an embodiment of the disclosure;

[0045] FIG. 8 shows a high level architecture for energy saving O-RAN using an rApp according to an embodiment of the disclosure; and

[0046] FIG. 9 shows a high level architecture for energy saving using an A1 policy according to an embodiment of the disclosure.

DETAILED DESCRIPTION

[0047] In describing embodiments of the disclosure, descriptions related to technical contents well-known in the art and not associated directly with the disclosure will be omitted. Such an omission of unnecessary descriptions is intended to prevent obscuring of the main idea of the disclosure and more clearly transfer the main idea.

[0048] For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted, or schematically illustrated. Further, the size of each element does not completely reflect the actual size. In the drawings, identical or corresponding elements are provided with identical reference numerals.

[0049] The advantages and features of the disclosure and ways to achieve them will be apparent by making reference to embodiments as described below in detail in conjunction with the accompanying drawings. However, the disclosure is not limited to the embodiments set forth below, but may be implemented in various different forms. The following embodiments are provided only to completely disclose the disclosure and inform those skilled in the art of the scope of the disclosure, and the disclosure is defined only by the scope of the appended claims. Throughout the specification, the same or like reference numerals designate the same or like elements. Further, in describing the disclosure, a detailed description of known functions or configurations incorporated herein will be omitted when it may make the subject matter of the disclosure unnecessarily unclear. The terms which will be described below are terms defined in consideration of the functions in the disclosure, and may be different according to users, intentions of the users, or customs. Therefore, the definitions of the terms should be made based on the contents throughout the specification.

[0050] Hereinafter, a base station is a subject that performs resource allocation to a user equipment (UE), and may be at least one of a gNode B, a gNB, an eNode B, an eNB, a Node B, a base station (BS), a radio access unit, a base station controller, or a node on a network. The base station may be an E2 node corresponding to a RAN in O-RAN system or a network entity, in an NR system, including at least one of an integrated access and backhaul (IAB)-donor that is a gNB which provides network access to a UE(s) via a network of backhaul and access links and an IAB-node that is a radio access network (RAN) node which supports NR access link(s) to a UE(s) and supports NR backhaul links to the IAB-donor or other IAB-nodes. A UE may be wirelessly connected via an IAB-node and may transmit or receive data to and from an IAB-donor connected to at least one IAB-node via a backhaul link.

[0051] A UE may include a terminal, a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions. In the disclosure, a “downlink” refers to a radio link via which a base station transmits a signal to a UE, and an “uplink” refers to a radio link via which a UE transmits a signal to a base station. Further, although the following description may be directed to an LTE or LTE-A system by way of example, embodiments of the disclosure may also be applied to other communication systems having similar technical backgrounds or channel types to the embodiments of the disclosure. Examples of other communication systems may include 5th generation mobile communication technologies (5G, new radio, NR) developed beyond LTE-A, and in the following description, the “5G” may be a concept that covers exiting LTE, LTE-A, and other similar services. In addition, based on determinations by those skilled in the art, the disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the disclosure.

[0052] Herein, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer usable or computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0053] Further, each block of the flowchart illustrations may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

[0054] Wireless communication systems have been developed from an initial wireless communication system providing a voice-oriented service to a broadband wireless communication system providing a high-speed and high-quality packet data service, such as those according to communication standards including a high-speed packet access (HSPA) of 3GPP, long-term evolution (LTE) (or evolved universal terrestrial radio access (E-UTRA)), LTE-advanced (LTE-A), LTE-Pro, high rate packet data (HRPD) of 3GPP2, ultra-mobile broadband (UMB), and 802.16e of IEEE.

[0055] In an LTE system, which is a representative example of the broadband wireless communication system, a downlink (DL) adopts an orthogonal frequency division multiplexing (OFDM) scheme and an uplink (UL) adopts a single carrier frequency division multiple access (SC-FDMA) scheme. The uplink refers to a radio link via which a UE transmits data or a control signal to a base station (BS) (or eNode B), and the downlink refers to a radio link via which a base station transmits data or a control signal to a UE. In such a multi-access scheme, normally data or control information of each user may be distinguished by assigning and operating time-frequency resources, at which the data or control information of each user is to be transmitted, so as not to overlap each other, that is, to establish orthogonality.

[0056] A 5G communication system, that is, a future communication system after LTE, should be able to freely reflect various requirements of users, service providers, etc., so that a service that concurrently satisfies various requirements should be supported. Services considered for the 5G communication system includes an enhanced mobile broadband (eMBB) communication, massive machine type communication (mMTC), ultra-reliability low latency communication (URLLC), and the like.

[0057] The eMBB aims to provide a data transmission rate that is more improved than a data transmission rate supported by existing LTE, LTE-A or LTE-Pro. For example, in the 5G communication system, an eMBB should be able to provide a maximum data rate (peak data rate) of 20 Gbps in a downlink and a peak data rate of 10 Gbps in an uplink from the perspective of one base station. The 5G communication system needs to provide a peak data rate while concurrently providing an increased actual user perceived data rate of a UE. In order to satisfy these requirements, improvement of various transmission or reception technologies including a more advanced multi-antenna (multi-input multi-output (MIMO)) transmission technology is required. A signal may be transmitted using a maximum transmission bandwidth of 20 MHz in a 2 GHz band used by LTE, whereas, in the 5G communication system, a data transmission rate, which is required by the 5G communication system, may be satisfied by using a frequency bandwidth wider than 20 MHz in a frequency band of 3 to 6 GHz or a frequency band of 6 GHz or higher.

[0058] Meantime, the mMTC is being considered to support application services, such as Internet of things (IoT), in the 5G communication system. In order to efficiently provide the IoT, the mMTC may require support of a large-scale UE access in a cell, coverage enhancement of a UE, an improved battery time, cost reduction of a UE, and the like. The IoT is attached to multiple sensors and various devices to support communication functions, so that the IoT should be able to support a large number of UEs (e.g., 1,000,000 UEs/km.sup.2) within a cell. Due to the nature of a service, a UE that supports the mMTC is likely to be located in a shaded region, which cannot be covered by a cell, such as the basement of a building, and therefore a wider coverage may be required compared to other services provided by the 5G communication system. The UE that supports the mMTC may be required to be a low-cost UE, and since it is difficult to frequently replace a battery of the UE, a very long battery lifetime, such as 10 to 15 years, may be required.

[0059] Finally, the URLLC corresponds to a cellular-based wireless communication service used for a specific purpose (mission-critical). For example, services, etc. used for a remote control of a robot or machinery, industrial automation, an unmanned aerial vehicle, remote health care, an emergency alert, and the like may be considered. Therefore, communication provided by the URLLC should also provide very low latency and very high reliability. For example, a service that supports the URLLC should satisfy an air interface latency less than 0.5 milliseconds and has requirements of a packet error rate of 10-5 or less at the same time. Therefore, for the service that supports the URLLC, the 5G system may be required to provide a transmit time interval (TTI) smaller than other services, and at the same time, design matters for allocating a wide resource in a frequency band may be required to secure the reliability of the communication link.

[0060] Three services of 5G, which are the eMBB, the URLLC, and the mMTC, may be multiplexed and transmitted in one system. Different transmission or reception techniques and transmission or reception parameters may be used between services in order to satisfy different requirements of respective services. 5G is not limited to the three services described above.

[0061] For convenience of description below, some terms and names defined in the 3GPP standard (standards of 5G, NR, LTE, or similar systems) may be used. However, the disclosure is not limited by the terms and names, and may be equally applied to systems conforming to other standards. Terms used for identifying an access node, terms indicating network entities, terms indicating messages, terms indicating interfaces between network entities, terms indicating various identification information, etc. used in the following description are illustrated for convenience of description. Therefore, the disclosure is not limited to the terms used herein, and other terms referring to objects having equivalent technical meanings may be used.

[0062] FIG. 1 shows a high level representation of the architecture of O-RAN. FIG. 1 shows a Service and Orchestration framework 101, which includes a Non-Real-time RAN Intelligent Controller, RIC, 102. This is connected via the A1 interface to a Near-Real-tile RIC 103 which is then further connected to one or more E2 nodes, 104, via the E2 interface. The E2 node(s) 104 may be directly connected to the Service and Orchestration Framework 101 via the O1 interface.

[0063] In a nutshell, an open radio access network (O-RAN) defines radio units (RU), digital units (DU), control units (CU)-control plane (CP), and user planes (UP) as O (O-RAN)-RU, O-DU, O-CU-CP, O-CU-UP.

[0064] The Non-RT RIC 102 is a logical function that enables non-real-time control and optimization of RAN elements and resources, Artificial Intelligence/Machine Learning (AI/ML) workflow including model training and updates, and policy-based guidance of applications/features in the near-RT RIC 103. The near-RT RIC 103 is a logical function that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. The E2 Node 104 is a logical node terminating the E2 interface. O-RAN nodes terminating the E2 interface may be O-CU-CP, O-CU-UP, O-DU or any combination for NR access or O-eNB for E-UTRA access. O-RAN Central Unit (O-CU) is a logical node hosting the O-CU-CP and the O-CU-UP. The O-RAN Central Unit-Control Plane (O-CU-CP) is a logical node hosting Radio Resource Control (RRC) and the control plane part of Packet Data Convergence Protocol (PDCP). The O-RAN Central Unit-User Plane (O-CU-UP) is a logical node hosting the user plane part of the PDCP and Service data association protocol (SDAP). The O-RAN Distributed Unit (O-DU) is a logical node hosting Radio Link Control (RLC)/Medium Access Control (MAC)/High-PHY layers based on a lower layer functional split. The O-RAN Radio Unit (O-RU) is a logical node hosting Low-PHY layer and radio frequency (RF) processing based on a lower layer functional split. This is similar to 3GPP's “Transmission/Reception Point (TRP)” or “remote radio head (RRH)” but more specific in including the Low-PHY layer. The A1 interface is an Interface between non-RT RIC 102 and Near-RT RIC 103 to enable policy-driven guidance of Near-RT RIC applications/functions, and support A1/ML workflow. The E2 interface is an interface connecting the Near-RT RIC 103 and one or more O-CU-CPs, one or more O-CU-UPs, and one or more O-DUs.

[0065] RIC is a logical node that can collect information on cell sites transmitted and received by a UE, O-eNB, O-DU, O-CU-CP, or O-CU-UP. The RIC can be implemented in the form of a server concentrated in one physical place or it can be implemented as a logical function within the base station, gNB. In the following, the nodes that are connected to RIC through the E2 interface, are referred to as E2 nodes. It is to be understood that embodiments of this disclosure are generally applied to E2 nodes, and it is one aim of embodiments of the disclosure to present new parameters and procedures over the E2 interface, regardless of what the individual E2 nodes are. Here, E2 nodes may be understood as objects constituting a RAN that can operate according to the O-RAN standard, and may be referred to as an E2 node. An E2 node may also refer to an O-eNB.

[0066] Applications, known as xApps, can be developed in Near-RT RIC and provide control to the RAN functions in the E2 nodes. Such examples can be found in the “O-RAN Architecture Description v4.0”. Applications, known as rApps, can developed in Non-RT RIC as a platform application that provide analytics related function and RAN governing policy function.

[0067] The interface with the RANs that can operate according to the O-RAN standard between RIC and E2 nodes uses an application protocol known as E2AP. As defined by O-RAN Working Group 3, WG3, a given RAN Function offers a set of services to be exposed over the E2 interface using E2AP defined procedures. In one E2 Service Model (SM), E2SM Radio control, E2SM-RC, the E2 Node terminating the E2 Interface is assumed to host one or more instances of the RAN Function “RAN Control” which performs the following functions: [0068] E2 REPORT services used to expose RAN control and UE context related information [0069] E2 INSERT services used to suspend RAN control related call processes [0070] E2 CONTROL services used to resume or initiate RAN control related call processes, modify RAN configuration and/or E2 service-related UE context information [0071] E2 POLICY services used to modify the behaviour of RAN control related processes

[0072] An embodiment of the disclosure relates to energy saving in a RAN.

[0073] FIG. 2 shows a prior art example of an existing energy saving scheme in O-RAN with static cell on/off threshold. FIG. 2 shows an example of a static threshold, usually set by operator. The FIG. 2 shows an energy saving procedure performed at the E2 node(s), assuming a cell on/off action is performed at a time interval, T, where T is e.g. 1 hour, although this can be varied as required.

[0074] At step 201, a determination is made if the load on the cell A is lower than a predefined threshold (e.g. 10%). If so, at step 202, UEs are reallocated to other cells and further access is barred to the cell in question. At step 203, the cell (cell A) is turned off. At step 204, controls the repeat cycle with a periodicity of T.

[0075] The disclosure relates to apparatus and procedures between RIC and E2 nodes, to achieve dynamic cell activation/deactivation, according to the traffic, for the purpose of energy saving. The skilled person will realise that the specific examples presented herein are exemplary and are not intended to be limiting.

[0076] Two major embodiments are described herein, each corresponding to, and resulting in, different parameters, interfaces, and procedures.

[0077] In a first embodiment, AI is used to dynamically control cell activation and deactivation, according to the cell load and cell performance, for the purpose of energy saving.

[0078] In a second embodiment, AI is used to dynamically control the policy related to the energy saving that includes cell activation and deactivation targeting thresholds.

[0079] In the following, new parameters, interfaces, and procedures are described for each embodiment, respectively.

[0080] Dealing with the first embodiment, the following are provided and relate to important features of the embodiment.

[0081] 1. A new enabler within near-RT RIC for RAN energy saving by dynamically turning cells on/off. This include a new xApp, namely the energy saving xApp, at near-RT RIC;

[0082] 2. A new RAN control E2 Service Model CONTROL service style between near-RT RIC and the RAN control RAN function at the E2 node(s), where the new control service allows the configuration of cell activation and cell deactivation according to the actions from the xApp claimed in 1.

[0083] 3. New E2 interface(s) between near-RT RIC and the E2 node(s), where the New E2 interface(s) are: 1) a list of the IDs of the cells to be activated; 2) a list of the IDs of the cells to be deactivated;

[0084] 4. Reporting of the Key Performance Indicators, KPIs, from E2 node(s) to near-RT RIC (e.g., cell throughput, instantaneous energy consumption, number of handovers) through E2 interface.

[0085] 5. Reporting of cell activation and deactivation status from E2 node(s) to near-RT RIC, through E2 interfaces.

[0086] 6. A procedure related to enabling the energy saving xApp and its control of cell activation/deactivation dynamically.

[0087] FIG. 3 shows a high level architecture for energy saving O-RAN using an xApp according to an embodiment of the disclosure. FIG. 3 refers to the high level architecture of the first embodiment. For a general description of each entity in FIG. 3, the above description of FIG. 1 may be referenced.

[0088] As illustrated in FIG. 3, the non-RT RIC 301a in service orchestration and management 301 enables non-real-time control and optimization of RAN elements and resources and policy-based guidance to the applications/features in Near-RT RIC 302 through the A1 interface.

[0089] In an embodiment, a new xApp is provided, i.e. the energy saving xApp 303 in Near-RT RIC 302. The xApp 303 uses cell statistics collected from non-RT RIC 301a, such as load statistics, and calculates the energy consumption of the E2 node(s) it connects to. It then makes a decision, according to the parameters obtained from E2 interface, e.g., instantaneous cell load and KPIs of the E2 node(s) and decides a list of cells to be activated and deactivated. The deactivation of the cells may occur, e.g., when cell load is low and the energy saving xApp 303 may decide to deactivate some cells and handover the UEs of these cells to the other cells, for energy saving purposes. The activation of the cells may occur, in circumstance when, e.g. 1) KPI degradations may occur, e.g., throughput drop, or 2) there is a (predicted) traffic increase, then the energy saving xApp shall activate a list of cells.

[0090] The decision made by xApp 303 may lead to an update of the list of the cells to be activated and/or deactivated. These parameters 304 shall be passed from near-RT RIC 302 to the E2 node(s) 306, and E2 node(s) 306 shall be activated and/or deactivated accordingly. The E2 node(s) 306 shall send their performance monitoring (e.g., throughput) to near-RT RIC 302, for xApp 303 to update its decisions accordingly. The E2 node(s) 306 shall also report status of cell activation and deactivation to near-RT RIC 302, such that the reported information can be used for other xApps, e.g., handover control. The parameters passed through E2 interface, from E2 nodes to near-RT RIC, are noted as 305 in FIG. 3.

[0091] FIG. 4 shows a high level architecture for energy saving using RAN control CONTROL service style according to an embodiment of the disclosure. Embodiment of FIG. 4 showing another embodiment of the FIG. 3, energy saving at the RAN is achieved by adding a new RAN control CONTROL service style 403: cell activation/deactivation. As illustrated in FIG. 4, the new service style is applied to modify the configuration and control cell activation/deactivation due to energy saving. Similarly numbered elements 403, 404, 405 and 406 are similar to those 303, 304, 305 and 306 shown in FIG. 3 and so descriptions thereof are omitted for brevity.

[0092] FIG. 5 shows E2 control message flows and Message Information Elements according to an embodiment of the disclosure.

[0093] Referring to FIG. 5, Near-RT RIC 502 is able to control E2 Node 505 through E2 Application Protocol message, E2AP RIC Control Request Message. The message flows and Message Information Elements are shown in FIG. 5. The Near-RT RIC 502 may be Near-RT RIC 302 of FIGS. 3, 4, and E2 Node 505 may be E2 Node 306, 406 of FIGS. 3, 4. FIG. 5 shows RIC CONTROL REQUEST sent from Near-RT RIC 102 to E2 Node 106 (step 511) and the RIC CONTROL ACKNOWLEDGE sent in the opposite direction (step 512). The various Information Elements, IE, included or possible in each message of steps 511, 512 are also shown in FIG. 5.

[0094] FIG. 6 shows RIC Control Request Message format according to an embodiment of the disclosure.

[0095] In FIG. 6, the RIC Control Request Message format is introduced in FIG. 5. The message format comprises at least one of a message type, RIC Request ID, RIC Call Process ID, and a RIC Control Header. The RIC Control header IE 601 indicate the choices of E2SM-RC (E2 service model for RAN “Control”) Control Message Header Format 1 or E2SM-RC Control Message Header Format 2. E2SM-RC Control Message Header Format 1 is that for the all CONTROL REQUEST messages carry the UEID in the Control Header, while E2SM-RC Control Message Header Format 2 is that for the all CONTROL REQUEST message for Cell basis or Slice basis RAN resource control.

[0096] Specifically, a new style, namely ‘cell activation’, is added as a new RIC style—type 9—in the following table, Table 1 which represents a CONTROL Service style list. It indicates that, based on O-RAN standard, the “RAN Control” RAN Function provides support of the CONTROL services on Cell Activation Control, which is used for modification of the configuration and to control cell activation/deactivation due to energy saving.

TABLE-US-00001 TABLE 1 RIC Style Type Style Name Style Description 1 Radio Bearer control Used to modify the configuration the Radio Bearer Control (RBC) related parameters and/or behaviours at the E2 Node for a specific UE 2 Radio resource Used to modify the configuration the Radio allocation control Resource Allocation control related parameters and/or behaviours at the E2 Node for a specific E2 Node, cell, slice, UE and/or QoS 3 Connected mode Used to initiate a connected mode mobility mobility control procedure (Handover or Conditional Handover), optionally with Dual Active Protocol Stack (DAPS), for a specific UE towards either a target cell (for HO) or a list of candidate cells (for CHO) 4 Radio access control Used to modify Radio access related functions used to control UE access to cells 5 Dual connectivity Used to initiate Dual connectivity (DC) (DC) control mechanisms 6 Carrier Aggregation Used to initiate Carrier Aggregation (CA) (CA) control mechanisms 7 Idle mode mobility Used to modify Idle mode mobility related control functions used to control UE reselection of cells 8 UE to RAN UE group Used to support POLICY services assignment 9 Cell activation Used to modify the configuration and control cell activation/deactivation due to energy saving

[0097] The CONTROL service style therefore further contains a CONTROL Service RIC Control Message IE, where the contents of the RIC Control Message is the list of cells to be activated and/or deactivated.

[0098] The following Table 2, below, shows RAN Parameter IDs and how these are used to control which cells are to be activated and/or deactivated accordingly.

TABLE-US-00002 TABLE 2 RAN RAN RAN Parameter Parameter Parameter ID Name Type Parameter description 1 Activated List of List of cell ID to be added to list cell list cell ID of cells to be activated 2 Deactivated List of List of cell ID to be added to the cell list cell ID list of cells to be deactivated

[0099] A person skilled in the art would appreciate the E2 nodes described above, could include but not be limited to, eNB, O-CU and O-DU. How the cells are configured within the E2 nodes according to the actions output from energy saving in near-RT RIC is irrelevant to embodiments of the present disclosure. As an example, the cell activation/deactivation configuration can be passed from O-CU to O-RU, to activate and deactivate RU. A person skilled in the art would also appreciate that the method can be straightforwardly extended to energy saving in DU. For example, the on/off configuration could be passed from O-CU to O-DU, to instruct servers in the O-DU to be turned on or off, for energy saving purposes.

[0100] The new CONTROL service style set out above further contains IEs exchanged between Near-RT RIC 302 and E2 nodes 306, 406. The following Table 3 below describes the message of the new E2SM-RC Control CONTROL service Style and the related IEs. These IEs, specified in Section 8.3 of O-RAN.WG3.E2SM-RC-v01.00.03, is detailed as follows.

TABLE-US-00003 TABLE 3 IE/Group IE type and Name Presence Range reference Semantics description CHOICE Cell M Identifier >NR >>NR Cell M BIT The leftmost bits of the NR Cell Identity STRING Identity IE correspond to the gNB (SIZE(36)) ID >E-UTRA >>E-UTRA M BIT The leftmost bits of the E-UTRA Cell Identity STRING Cell Identity IE correspond to the (SIZE(28)) ng-eNB ID

[0101] In another IE, a message is sent by the near-RT RIC 302 to E2 nodes 306, 406 to request the deactivation of one or multiple cells.

TABLE-US-00004 TABLE 4a IE type and IE/Group Name Presence Range reference Message Type M 38.423 9.2.3.1 CHOICE Served Cells To M Activate >NR Cells >>NR Cells List 1 >>>NR Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>NR CGI M 38.423 9.2.2.7 >E-UTRA Cells >>E-UTRA Cells List 1 >>>E-UTRA Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>E-UTRA CGI M 38.423 9.2.2.8 Range bound Explanation maxnoofCellsinNG-RANnode Maximum no. cells that can be served by an NG-RAN node. Value is 16384.

[0102] In yet another IE, a message is sent by the near-RT RIC 102 to E2 nodes 106 to request activation of one or multiple cells. This is described below in the following Table 4b.

TABLE-US-00005 TABLE 4b IE type and IE/Group Name Presence Range reference Message Type M 38.423 9.2.3.1 CHOICE Served Cells To M Deactivate >NR Cells >>NR Cells List 1 >>>NR Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>NR CGI M 38.423 9.2.2.7 >E-UTRA Cells >>E-UTRA Cells List 1 >>>E-UTRA Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>E-UTRA CGI M 38.423 9.2.2.8 Activation ID M INTEGER (0 . . . 255)

[0103] In yet another IE, a message is sent from E2 nodes 306, 406 to near-RT RIC 302 to report the list of one or multiple deactivated cells. This is described in the following Table 5a below.

TABLE-US-00006 TABLE 5a IE type and IE/Group Name Presence Range reference Message Type M 38.423 9.2.3.1 Activated cells M >NR Cells >>NR Cells List 1 >>>NR Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>NR CGI M 38.423 9.2.2.7 >E-UTRA Cells >>E-UTRA Cells List 1 >>>E-UTRA Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>E-UTRA CGI M 38.423 9.2.2.8

[0104] In yet another IE, a message is sent from E2 nodes 306, 406 to near-RT RIC 302 to report the list of one or multiple activated cells. This is described in Table 5b below.

TABLE-US-00007 TABLE 5b IE type and IE/Group Name Presence Range reference Message Type M 38.423 9.2.3.1 Deactivated cells M >NR Cells >>NR Cells List 1 >>>NR Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>NR CGI M 38.423 9.2.2.7 >E-UTRA Cells >>E-UTRA Cells List 1 >>>E-UTRA Cells item 1 . . . <maxnoofCellsinNG- RANnode> >>>>E-UTRA CGI M 38.423 9.2.28

[0105] Alternatively, in yet another IE, a message is sent from E2 nodes 106 to near-RT RIC 102 to report the status of the list of one or multiple cells, e.g. cell 0 is activated, cell 1 is deactivated, etc. The detail is described in the following Table 6, below.

TABLE-US-00008 TABLE 6 RAN Parameter RAN Parameter Name Type Parameter description Cell Activation BOOLEAN TRUE = Activated; status False = Deactivated

[0106] FIG. 7 shows a flowchart depicting message flow and procedure according to an embodiment of the disclosure.

[0107] FIG. 7 shows a message flow showing the procedure of energy saving in O-RAN, where steps 702, 704, 706 and 707 are the corresponding actions taken at different components in O-RAN, and steps 701, 703, 705, 708 and 709 are the corresponding information/data/parameters that are passed/transmitted between different components, the flow of which are indicated by the direction of the arrows. The non-RT RIC, near-RT RIC, and E2 node(s) in the embodiment of FIG. 7 may be non-RT RIC, near-RT RIC, and E2 node(s) in one or more embodiments of the disclosure, respectively.

[0108] In particular, as an example of the procedures forming an embodiment of the disclosure, FIG. 7 shows the following procedures:

[0109] Step 701. The non-RT RIC within Service orchestration and management would calculate the cell load statistics and pass/transmit the information to near-RT RIC.

[0110] Step 702. The near-RT RIC executes the function, as set out above in relation to the first embodiment, or service, as set out above in relation to the second embodiment, for energy saving. It is noted that here the function can be performed continuously at system initiation, periodically, according to a pre-configured time interval, or triggered when certain condition is met.

[0111] Step 703. The Near-RT RIC would request cell load from E2 node(s), and the E2 node(s) would return such cell load information to the Near-RT RIC through E2 interface.

[0112] Step 704. The Near-RT RIC generates a list of cells IDs, indicating the cells to be activated and/or deactivated, respectively, as the output of the intelligent module within near-RT RIC.

[0113] Step 705. The Near-RT RIC exposes/transmits the list of cell IDs to the E2 node(s).

[0114] Step 706. The E2 nodes configure cells activated and/or deactivated according to configuration instructed from the Near-RT RIC. It is noted that some operations of cell activation/deactivation may lead to success or fail at the E2 node(s).

[0115] Step 707. The E2 node(s) return status of the cells (activated/deactivated) and the status may be in a format of a list of cell IDs, or a Boolean variable indicating if a particular cell is active or inactive, as in FIG. 2. The E2 node(s) may also return network KPIs after the configuration. It is noted that the KPIs and status of cells may not be exposed at the same time slot. It is also noted that the exposure of network KPIs may be requested by other modules/services in the system, e.g., by monitoring functions.

[0116] Step 708, 709. The E2 node(s) report/transmit relevant network parameters, such as updates of the cell loads, to the non-RT RIC and/or Near-RT RIC.

[0117] According to embodiments of the present disclosure, a method performed by a radio access network (RAN) controlled controller (RIC) comprises the steps of: transmitting a RIC control request message to an E2 node; and receiving a RIC control confirmation message from the E2 node, wherein the RIC control request message includes information on a specific to RAN function specific to a service model, and the RIC control confirmation message for the function. The RIC control result information includes control result information, and the RIC control result information may include an event occurrence reason for the RAN function specific to the service model in a specific protocol.

[0118] According to embodiments of the present disclosure, a method performed by an E2 node comprises the steps of: receiving a RIC control request message from a radio access network (RAN) control controller (RIC); and transmitting a RIC control confirmation message to the RIC. The RIC control request message includes information on a specific to RAN function specific to a service model, and the RIC control confirmation message includes information on the RIC control function. The RIC control result information includes control result information, and the RIC control result information may include an event occurrence reason for the RAN function specific to the service model in a specific protocol.

[0119] In one embodiment of the disclosure, the energy saving xApp/procedure can run continuously, or be triggered by the operator or non-RT RIC (e.g., when KPI is not met by performance monitoring procedure).

[0120] The second embodiment of the present disclosure relates to energy saving and concerns semi-dynamically configuring the cell activation and deactivation policy. The optimal energy saving configuration parameters can be calculated in the analytics rApp from the non-RT RIC 101, according to analytics of the cell load data through the extended period. The new thresholds parameters can then be configured through the O1 interface to eNB, or through open fronthaul to O-RU. The cells are then activated or deactivated, once the cell load is lower than the specified thresholds. The thresholds can be updated periodically.

[0121] This embodiment may involve at least one of the following features 1) to 6):

[0122] 1) New enabler within Non-RT RIC for RAN energy saving by semi-dynamically turning cells on/off. This includes a new rApp, namely the energy saving rApp, at Non-RT RIC;

[0123] 2) Energy Saving RAN function that control Cell Activation and De-Activation at the E2 nodes. The configuration of cell activation and cell deactivation can also be configured at the O-RU.

[0124] 3) New O1 interfaces parameters between Non-RT RIC and the E2 nodes, where the interfaces are: (1) a list of the IDs of the cells to be activated; (2) a list of the IDs of the cells to be deactivated;

[0125] 4) Reporting of the KPIs from E2 nodes to Non-RT RIC (e.g., cell throughput, instantaneous energy consumption, number of handovers) through O1 interface.

[0126] 5) Reporting of cell activation and deactivation status from E2 nodes to Non-RT RIC, through O1 interfaces.

[0127] 6) A procedure related to enabling the energy saving rApp and its control of cell activation/deactivation Semi-dynamically.

[0128] FIG. 8 shows a high level architecture for energy saving O-RAN using an rApp according to an embodiment of the disclosure. For a general description of each entity in FIG. 8, the above description of FIG. 3 may be referenced.

[0129] As illustrated in FIG. 8, the non-RT RIC 301a in service orchestration and management 301 enables non-real-time control and optimization of RAN elements and resources to the applications/features in E2 Node(s) 306 based on the KPI report 304 and Cell Configuration 305 through O1 interface.

[0130] In one embodiment of the disclosure, it proposes to add a new rApp 803, i.e., the energy saving rApp 803 in Non-RT RIC 301a. The rApp 803 uses cell statistics collected from E2 Node(s) 306, such as load statistics, and calculates the energy consumption. It then makes a decision, according to the parameters obtained from O1 interface, e.g., instantaneous as well as average cell loads and KPIs of the E2 node(s), decides a list of cells to be activated and/or deactivated. The deactivation of the cells may occur, e.g., when cell load is low and the energy saving rApp 803 may decide to deactivate some cells and re-locate the UEs of these cells to the other cells, for energy saving purpose. The activation of the cells may occur, in circumstance when, e.g., 1) KPI degradations may occur, e.g., throughput drop, or 2) there is a (predicted) traffic increase and the energy saving rApp 803 shall activate a list of cells.

[0131] The decision made by rApp 803 may lead to update of the list of the cells to be activated and deactivated. These parameters 305 shall be passed from non-RT RIC 301a to the E2 node(s) 306, and E2 node(s) shall be activated and/or deactivated accordingly.

[0132] FIG. 9 shows a high level architecture for energy saving using an A1 policy according to an embodiment of the disclosure.

[0133] In another embodiment of the disclosure, energy saving at the RAN may be achieved by adding a new RAN control A1 Policy: cell activation/deactivation. As illustrated in FIG. 9, the new A1 Policy 905 may be applied to modify the configuration and control cell activation/deactivation due to energy saving. Near-RT RIC 302 is able to control E2 Node 306 through E2 control 907. For a general description of each entity in FIG. 9, the above description of FIG. 3 may be referenced.

[0134] Specifically, the Service Management and Orchestration (SMO) 301 (including non-RT RIC 301a) can perform one or more of the following: [0135] Retrieve necessary performance, configuration, and load statistics of the cells, and other data for defining and updating policies to guide the behaviour of energy saving. For example, the policy could relate to specifying different optimization objectives (e.g., minimising energy consumption). [0136] Training of potential Machine Learning, ML, models for energy optimization, which may respectively autonomously recognize traffic types, predict throughput and energy consumption under a certain traffic pattern. [0137] Send policies/intents to near-RT RIC 302 to drive energy saving at RAN level in terms of expected behaviour. [0138] Support communication of measurement configuration parameters to RAN nodes. [0139] Support communication of enrichment information to Near-RT RIC 302, e.g., cell throughput, etc.

[0140] The apparatus (e.g. non-RT RIC, near-RT RIC or E2 node) according to the above-described embodiments may be implemented by including a transceiver and a processor for controlling an operation according to a combination of at least one embodiment as well as each of the embodiments.

[0141] At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others.

[0142] Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[0143] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

[0144] Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0145] The disclosure is not restricted to the details of the foregoing embodiment(s). The disclosure extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.