ric

Abstract

Example embodiments of the present disclosure relate to Radio Access Network (RAN) Intelligent Controller (RIC). According to example embodiment, a Near-Real-Time (Near-RT) RIC may be configured to: obtain a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and provide, to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.

Description

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to the U.S. Provisional Patent Application No. 63 / 700,964, filed with the U.S. Patent and Trademark Office on September 30, 2024, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to Radio Access Network (RAN) Intelligent Controller (RIC).BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor-specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, differenttypes of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form, or could be in physical hardware form.SUMMARY

[0006] Example embodiments of the present disclosure provide devices, systems, methods, and the like, that provide or implement a RIC.

[0007] According to example embodiments, a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC) may be configured to obtain a list of candidate subarray patterns and Physical Downlink Shared Channel (PDSCH) power offsets. Further, the Near- RT RIC may be configured to provide, to a network node, the list of candidate sub-array patterns PDSCH power offsets as potential choices for a transmission.

[0008] According to example embodiments, a method may include obtaining, by a Near- RT RIC, a list of candidate sub-array patterns and PDSCH power offsets. Further, the method may include providing, by the Near-RT RIC and to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.

[0009] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method. The method may include obtaining, by a Near-RT RIC, a list of candidate sub-array patterns and PDSCH power offsets. Further, the method may include providing, by the Near-RT RIC and to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.

[0010] According to example embodiments, a network node may be configured to receive, from a Near-RT RIC, a list of candidate sub-array patterns and PDSCH power offsets. Further, thenetwork node may be configured to configure a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

[0011] According to example embodiments, a method may include receiving, by a network node and from a Near-RT RIC, a list of candidate sub-array patterns and PDSCH power offsets. The method may further include configuring a UE to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

[0012] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method. The method may include receiving, from a Near-RT RIC, a list of candidate sub-array patterns and PDSCH power offsets. The method may further include configuring a UE to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

[0013] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0015] FIG. 1 illustrates an example 0-RAN architecture, according to one or more example embodiments;

[0016] FIG. 2 illustrates an example use case that involves various candidate sub-array patterns, according to one or more example embodiments;

[0017] FIG. 3 illustrates an example use case that involves various candidate PDSCH power offsets, according to one or more example embodiments;

[0018] FIG. 4A and FIG. 4B illustrate an example use case for implementing Network Energy Saving (NES) spatial and power domains optimization, according to one or more example embodiments;

[0019] FIG. 5 and FIG. 6 each illustrates an example use case for implementing a Near- RT RIC to control the NES spatial and power domains optimization, according to one or more example embodiments;

[0020] FIG. 7 and FIG. 8 each illustrates an example use case for implementing a Non- Real-Time (Non-RT) RIC to control the NES spatial and power domains optimization, according to one or more example embodiments;

[0021] FIG. 9 to FIG. 12 each illustrates an example method, according to one or more example embodiments;

[0022] FIG. 13 illustrates an example device for implementing one or more example embodiments; and

[0023] FIG. 14 illustrates an example environment for implementing one or more example embodiments.DETAILED DESCRIPTION

[0024] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is notintended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0025] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0026] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0027] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0028] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc. In addition, expressions such as “a processor may be configured to perform an operation,” are to be understood as the processor may be configured to execute computer-executable instructions or programming codes to thereby perform an operation. Namely, the instructions or programming codes may be configured to cause the processor to perform an operation.

[0029] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” “one or more example embodiments,” “example embodiments,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” “according to exampleembodiments,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0030] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0031] In the present disclosure, specific tasks may be performed using Artificial Intelligence and / or Machine Leaning (AI / ML) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc. In the following, terms like “the Al model” may refer to “one or more Al models,” “one or more ML models,” “one or more Al models and ML models,” and the like.

[0032] Although Al and ML may be explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve their performance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0033] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, transductive learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, and is not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0034] It should be noted that the AI / ML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0035] Further, it should be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “Near-RT RIC,” “Non-RT-RIC,” “E2 Node,” “SMO,” “xApp,” “rApp,” “sub-array pattern,” “PDSCH,” “E2 control command,” “E2 policy,” “E2 control command,” “Al policy,” “UE context,” “E2 measurement metric,” “E2 KPI,” “E2 node functions target,” “traffic steering,” “access control operation,” “radio propagation channel,” “CA,” “RACH backoff,” “RRC Connection,” “Access Barring,” “CSI measurement” and the like,as well as the associated features, operations, and messages, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0036] Network Energy Saving (NES) is an important aspect in optimizing energy consumption and efficiency in a telecommunication network. In this regard, several NES optimization approaches have been introduced for an O-RAN-based telecommunication network, such as: dynamically switching network cell and carrier on and off according to the traffic load, reconfiguring Radio Frequency (RF) channels of Multiple Input Multiple Output (MIMO) antenna arrays according to the utilization conditions, employing advanced sleep modes in Radio Unis (RUs) to maximize sleep periods of network cells during deactivation of the RUs, optimizing the cloud resources by shutting down unused server nodes and managing the CPU configuration (e.g., lowering CPU frequency, adjusting CPU C-state and P-state, etc.), and the like.

[0037] On the other hand, 3 GPP Release- 18 (Rel-18) introduces an NES feature “spatial and power domain adaptation” to enable energy savings in the gNB’s downlink by adjusting transceiver (or antenna) activity and transmission power based on UE feedback. Specifically, the gNB may configure a user equipment (UE) to measure and report Channel State Information Reference Signal (CSI-RS) sub-reports, each of which is associated with a specific spatial domain configuration (e.g., a candidate sub-array pattern that defines a subset of active antenna ports) and / or a specific power domain configuration (e.g., a candidate Physical Downlink Shared Channel (PDSCH) power offset). Accordingly, the UE may measure channel state for each of the spatial and / or power domain configurations (e.g., measure the channel state for each candidate sub-array pattern and / or power offset), and then report the measurement(s) to the gNB in CSI subreports. Subsequently, based on the CSI sub-reports provided by the UE, the gNB may dynamically configure the transceiver array and / or power offset (e.g., selecting a specific sub-array pattern,lowering power offset, etc.). Namely, these features enable the gNB to dynamically adjust the number of active antenna elements and transmission power based on UE channel conditions. In the spatial domain, adaptive control allows antenna elements to be turned on or off depending on demand, while in the power domain, transmission power may be adjusted according to the CSI reports provided by UEs. These adaptations optimize the energy consumption of, for example, the Transceiver Unit (TXRU) and Power Amplifier (PA) while maintaining service quality.

[0038] The present disclosure introduces and specifies various example embodiments for implementing the 3GPP Rel-18 NES feature “spatial and power domain adaptation” in the 0-RAN architecture, thereby advantageously further optimizing the NES in the O-RAN-based networks. Specifically, example embodiments of the present disclosure specify various system configurations and operations among the O-RAN components (e.g., the Non-RT RIC, Near-RT RIC, E2 nodes, etc.) via the existing O-RAN interface.

[0039] For instance, according to example embodiments, a Near-RT RIC may obtain or derive a list of candidate sub-array patterns and / or PDSCH power offsets (e.g., based on data obtained from the E2 nodes, based on an Al policy obtained from the Non-RT RIC, etc.) and provide the list of candidate sub-array patterns and / or PDSCH power offsets to the E2 node(s) as potential choices for a transmission. Further, the Near-RT RIC may also perform one or more steering operations on the UEs, thereby steering Rel-18 UEs towards and / or steering non-Rel-18 UEs out of a network cell optimized for energy saving spatial and power domains adaptation and advantageously further optimizing the energy efficiency thereof. The Near-RT RIC may perform the control and operations via the E2 interface, e.g., via utilizing one or more E2 service models(e.g., E2SM-RAN Control, etc.).

[0040] As another example, according to example embodiments, one or more network nodes, such as one or more E2 nodes (e.g., O-RAN Central Unit (O-CU), O-RAN Distributed Unit(O-DU), etc.), may be configured to receive, from the Near-RT RIC (e.g., via the E2 interface), a list of candidate sub-array patterns and / or PDSCH power offsets, and then configure one or more UEs to perform one or more measurements according thereto. Accordingly, the E2 node(s) may select, based on the measurement, a sub-array pattern and / or a PDSCH power offset for a transmission. Advantageously, the selected sub-array pattern and / or PDSCH power offset may be dynamically determined based on the channel conditions reported by the UE(s).

[0041] Further, example embodiments also provide several additional or alternative optimizations, where the Near-RT RIC may take full control of the implementation of the NES spatial and power domains adaptation, the Non-RT RIC may control the implementation of the NES spatial and power domains adaptation without the involvement of the Near-RT RIC, and the like.

[0042] In addition, as further described below, example embodiments of the present disclosure specify and supplement several features, mechanisms, and use cases in at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN.WG3.TS.UCR), thereby introducing clear, specified, and standardized mechanisms and approaches for implementing the NES spatial and power domains adaptation in the O-RAN-based networks.

[0043] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0044] In an O-RAN-based telecommunication network, the RAN functions may be disaggregated into a central unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0045] FIG. 1 illustrates an example 0-RAN architecture 100, according to one or more example embodiments. RAN functions in the 0-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the O- RAN system, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types: a Non-Real-Time RIC (Non-RT RIC) 120 and a Near-Real-Time RIC (Near-RT RIC) 130.

[0046] The Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within a Service Management and Orchestration (SMO) framework 110. Its functionalities may be implemented through modular applications called rApps, and may include: providing policy-based guidance and enrichment across the Al interface, which is the interface that enables communication between the Non-RT RIC 120 and the Near-RT RIC 130; performing data analytics; Artificial Intelligence / Machine Learning (AI / ML)training and inference for RAN optimization; and / or recommending configuration management actions over the 01 interface, which may be the interface that connects the SMO to RAN managed elements (e.g., 0-RAN Central Unit (0-CU) 140, 0-RAN Distributed Unit (0-DU) 150, etc.).

[0047] The Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be communicatively coupled to the underlying network nodes, such as the O-CU 140 and O-DU 150, via the E2 interface. Thus, the O-CU 140 and 0-DU 150 may also be collectively referred to as the “E2 nodes” herein. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes, etc.) over a near-real-time control loop. The Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes via policies. For example, the Near-RT RIC 130 may set policy parameters on activated functions of the E2 nodes. Further, the Near-RT RIC 130 may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc.

[0048] The two types of RICs work together to optimize the 0-RAN. For example, the Non-RT RIC 120 may provide the policies, data, and AI / ML models (that may be enforced and used by the Near-RT RIC 130) to the Near-RT RIC 130 for RAN optimization, and the Near-RT RIC 130 may return policy feedback (e g., how the policy set by the Non-RT RIC 120 works) to the Non-RT RIC 120.

[0049] The O-CU 140, the 0-DU 150, and the O-RUs 160 may constitute a base station, such as a gNodeB (gNB) of 5GNR, a node in Next Generation Radio Access Network (NG-RAN), a base station of a 6G network, and the like. In some example implementations, the system may include a plurality of O-DUs 150, and the O-CU 140 may be communicatively coupled to the plurality of O-DUs. Similarly, as illustrated, the system may include a plurality of O-RUs 160, andthe O-DU 150 may be communicatively coupled to the plurality of O-RUs via one or more of the Open Fronthaul (O-FH) Control (C), User (U), Synchronization (S), and Management (M) plane interfaces.

[0050] According to example embodiments, the O-CU 140 and the O-DU 150 may be defined in software form and may be deployed in one or more apparatus, devices, hardware components, and / or any other suitable network elements. As described above, the O-CU 140 and O-DU 150 may also be collectively referred to as the “network nodes” or “E2 nodes” herein. In some example implementations, the O-CU 140 and the O-DU 150 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU 140 and the O-DU 150 may be deployed in the same E2 node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in the same server and / or different servers in the same data center). According to example embodiments, the O-CU 140 and the O-DU 150 may be deployed in different E2 nodes and / or may be located at different geographical locations. For instance, the O-CU 140 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 150 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers). The O-CU 140 and the O-DU 150 may communicate with each other via Fl interface.

[0051] Further, a single O-DU 150 may host or serve multiple network cells formed by multiple O-RUs 160-1 to 160-N (where N is any suitable natural number). According to example embodiments, the O-DU 150 may implement various radio technologies, such as massive multipleinput multiple-output (MIMO), beamforming, and the like, to optimize radio communicationamong the multiple cells and the O-CU 140. In some example implementations, the O-DU 150 may concurrently host or serve hundreds (e.g., 256, 512, etc.) of cells at a time.

[0052] The O-RU(s) 160 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 150. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pi co cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 160, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0053] The O-RU 160 may be configured to manage multiple antenna arrays, such as transmitter (tx) arrays, receiver (rx) arrays, or a combination thereof (e.g., transceiver (trx) arrays). The full antenna arrays may be partitioned into sub-array with various patterns, each of which defines a subset of antenna ports that can be activated or deactivated. Thus, by appropriately selecting the sub-array patterns (e.g., deactivating a specific antenna sub-array, etc.), the utilization of the antenna arrays (and ultimately the NES of the network) may be optimized.

[0054] The UE 170 may include any suitable device or equipment that may be utilized by a user (e.g., a network operator, an end user, etc.) to communicate with the network. For instance, the UE 170 may include at least one of: a mobile device (e.g., a smartphone, a laptop, a tablet, a wearable device like smartwatches and smartglasses, a portable hotspot, etc.), a static device (e.g., an Internet of Things (loT) device like sensors and smart home / office devices, a workstation, etc.), and the like.

[0055] According to example embodiments, the UE 170 may utilize a Channel StateInformation Reference Signal (CSI-RS) to measure or estimate the downlink channel conditions, such as the conditions of the Physical Downlink Shared Channel (PDSCH). A “CSI measurement” describes herein may refer to the process or operation by which the UE 170 measures or estimates the downlink channel conditions based on the CSI-RS (and / or any other suitable reference signals). The power offset between the CSI-RS and PDSCH is a configurable parameter that defines the differences in transmission power levels therebetween. By adjusting the PDSCH power offsets, the transmission power of the PDSCH may be reduced, thereby optimizing the NES of the network.

[0056] According to example embodiments, the UE 170 may be configured by one or more upstream O-RAN components to perform multiple CSI measurements according to various CSI report sub-configurations. Each of the CSI report sub-configurations may define a candidate subarray pattern and / or a candidate power offset that the UE 170 may measure. Accordingly, the UE 170 may measure the CSI for each candidate sub-array pattern and / or candidate power offset, and report the measurements to the upstream O-RAN component(s) via CSI sub-reports. Accordingly, based on the CSI sub-reports, the upstream O-RAN component(s) may select the appropriated subarray pattern and / or power offset for energy-saving purposes. In this regard, the present disclosure introduces various example embodiments and approaches to determine a list of candidate subarray patterns and / or candidate power offsets that may potentially improve the energy efficiency, configure the CSI report sub-configurations, receive CIS sub-reports, select appropriate (e.g., optimal) sub-array pattern and / or power offset, and implement the selected sub-array pattern and / or power offset, thereby advantageously optimizing the network energy saving efficiency of an O-RAN-based network by leveraging the NES spatial and power domains adaptation of 3GPPRel-18.

[0057] According to example embodiments, a list of candidate sub-array patterns and / orPDSCH power offsets may be determined or derived by the upstream components (e.g., Non-RTRIC 120, Near-RT RIC 130). FIG. 2 illustrates an example use case 200 that involves various candidate sub-array patterns, while FIG. 3 illustrates an example use case 300 that involves various candidate PDSCH power offsets, according to one or more example embodiments.

[0058] Referring to FIG. 2, an antenna array 210 may include a plurality of antenna ports that can be selectively activated or deactivated. In the example of FIG. 2, all antenna ports of the antenna array 210 are initially activated. In order to optimize the NES without affecting the network performance, the Near-RT RIC 130 may determine or derive various candidate sub-array patterns, which are the logical grouping of antenna ports of the antenna array 210 that may be activated or deactivated. In some example embodiments, a candidate sub-array pattern may include an on / off (or activate / deactivate) mask over the antenna array 210. In example use case 200, three example candidate sub-array patterns 211 to 213 are illustrated. Each of the candidate sub-array patterns may define a subset of antenna ports that may be activated or deactivated. For instance, the candidate sub-array pattern 211 may define the indexes of the right half of the antenna ports that may be activated, and / or the indexes of the left half of the antenna ports that may be deactivated. The information of each of the candidate sub-array patterns 211 to 213 may be included in a respective CSI report sub-configuration, to which the UE 170 may refer to measure the CSI and provide the associated measurements in a respective CSI sub-report.

[0059] Referring next to FIG. 3, an antenna array 310 may transmit the PDSCH via various power offsets. In the example of FIG. 3, four candidate PDSCH power offsets 311 to 314 are illustrated. Each of the candidate PDSCH power offsets may define a specific power offset value for the transmission of the PDSCH (e.g., the number of dB the PDSCH is transmitted in relativeto the CSI-RS). For instance, a candidate PDSCH power offset may refer to a potential value (e.g., a number of dB) that may be utilized by the associated O-DU and O-RU (e.g., O-DU 150 and O-RU 160) to determine how much higher or lower the PDSCH should be transmitted with respect to the associated CSI-RS. In operation, the O-RU may transmit the PDSCH at each candidate PDSCH power offset, and the UE 170 may measure the CSI of each candidate and report the measurement in a CSI sub-report.

[0060] Referring back to FIG. 1, according to example embodiments, the Near-RT RIC 130 may be configured to dynamically (or continuously) determine potential improvement to energy efficiency and update the candidate sub-array patterns and / or PDSCH power offsets, in real-time (or near-real-time). For instance, the Near-RT RIC 130 may receive an Al policy from the Non- RT RIC 120 via the Al interface, and then interpret the Al policy to determine one or more optimum changes it can make according to the Al policy. By way of an example, the Near-RT RIC 130 may trigger an E2 procedure and related control and / or policies so as to obtain network performance that may fulfill the criteria identified in the Al policy. Further, the Near-RT RIC 130 may leverage the Al enrichment information to make more informed decisions. In some example implementations, the Near-RT RIC 130 may also operate without the Al policy guidance from the Non-RT RIC 120. Descriptions of an example embodiment associated therewith are provided below with reference to FIG. 4A and FIG. 4B.

[0061] According to example embodiments, the Near-RT RIC 130 may suggest or provide a list of candidate sub-array patterns and / or candidate PDSCH power offsets to one or more underlying E2 nodes (e.g., O-CU 140, O-DU-150) via the E2 interface as potential choices for a transmission (e.g., a downlink (DL) transmission, etc.). Specifically, the list of candidate sub-array patterns and / or candidate PDSCH power offsets may provide or define the potential sub-arraypatterns and / or potential PDSCH power offsets, each of which may deliver a certain level of network energy saving when being selected and implemented for the transmission. The E2 node(s) may then configure the UE 170 to measure for the candidate choices and select the optimal subarray pattern and / or PDSCH power offset based on the UE measurements. Further descriptions of an example embodiment associated therewith are provided below with reference to FIG. 5.

[0062] According to example embodiments, in addition to or in alternative to providing the list of candidate sub-array patterns and / or candidate PDSCH power offsets to the E2 node(s), the Near-RT RIC 130 may directly configure the CSI report sub-configurations and provide the same to the UE 170 (via the E2 node(s)). Accordingly, the Near-RT RIC 130 may collect the CSI sub-reports from the UE (via the E2 node(s)), select the optimal sub-array pattern and / or PDSCH power offset based on the CSI sub-reports, and directly instruct the E2 node(s) to implement the selected sub-array pattern and / or PDSCH power offset. Further descriptions of an example embodiment associated therewith are provided below with reference to FIG. 6.

[0063] According to example embodiments, the Non-RT RIC 120 may determine or derive the list of candidate sub-array patterns and / or PDSCH power offsets, and then provide one or more Al policies associated therewith to the Near-RT RIC 130. In this regard, an Al policy may refer to the policy provided by the Non-RT RIC 120 to the Near-RT RIC 130 via the Al interface and may specify the candidate sub-array patterns and / or PDSCH power offsets, as well as other parameters such as Quality of Service (QoS) and NES objectives and requirements, PDSCH power management policies, and the like. Accordingly, based on the Al policy(s), the Near-RT RIC 130 may determine, derive, and provide the list of candidate sub-array patterns and / or PDSCH power offsets to the E2 node(s), and the E2 node(s) may configure the CSI report sub-configurationsbased thereon. Further descriptions of an example embodiment associated therewith are provided below with reference to FIG. 7.

[0064] According to example embodiments, in addition to or in alternative to providing the Al policy(s) to the Near-RT RIC 130, the Non-RT RIC 120 may also directly determine or provide the list of candidate sub-array patterns and / or PDSCH power offsets to the E2 node(s) via the 01 interface, without requiring the involvement of the Near-RT RIC. The E2 node(s) may then configure the UE 170 to measure for the candidate choices and select the best sub-array pattern and / or PDSCH power offset based on the UE measurements. Further descriptions of an example embodiment associated therewith are provided below with reference to FIG. 8.

[0065] According to example embodiments, the Near RT-RIC 130 may be configured to perform a traffic steering operation to steer the UE 170 towards a network cell (e.g., a network cell that is associated with the list of candidate sub-array patterns and / or the PDSCH power offset). In this case, a traffic steering operation may refer to an operation or process initiated by the network (e g., Near-RT RIC 130) to direct or shift a UE’s connection to a target network cell. For instance, if the UE 170 is compatible with 3GPP Rel-18 (“Rel-18 UE” herein), namely, the UE 170 supports the NES spatial and power domains adaptation feature as defined in 3GPP Rel-18, the Near-RT RIC 130 may perform one or more mobility control operations to steer the UE 170 toward a network cell optimized for the NES spatial and power domains adaptation, in order to achieve more energy saving for the cell. In some example implementations, the following mobility control procedures may be utilized to steer the UE 170 towards the optimized network cell: performing a handover operation (e.g., handover a UE connection from the source / serving cell to the optimized cell), configuring a handover restriction list (e.g., configuration / reconfiguration of handover restriction list), configuring an idle mode mobility parameter (e.g., configuration / reconfigurationof one or more idle mode mobility parameters), managing carrier aggregation (CA)(e.g., enable, disable, or modify CA), and managing dual connectivity (e.g., enable, disable, or modify dual connectivity). In this regard, a handover list may refer to a list that defines which cells (or network entities) a UE can or cannot be handed over to. Further, an idle mode mobility parameter may refer to one or more parameters (e.g., cell selection / re-selection priority, threshold, timer, etc.) that define how a UE may select / reselect a serving network cell. Furthermore, CA may refer to a feature that enables a UE to transmit and / or receive data simultaneously on multiple carriers (e.g., frequency bands). In addition, dual connectivity may refer to a feature that enables a UE to simultaneously connect to multiple serving nodes (e.g., a Master node and a Secondary node). The Near-RT RIC 130 may perform the above-mentioned mobility control operation(s) by implementing at least one of RIC POLICY and RIC CONTROL (e.g., the Near-RT RIC 130 may send an E2 policy and / or an E2 control command to the E2 node(s) via the E2 interface such that the E2 node(s) may implement the mobility control operation(s) based thereon).

[0066] According to example embodiments, the Near RT-RIC 130 may be configured to perform a traffic steering operation to steer the UE 170 out of a network cell (e.g., a network cell that is associated with the list of candidate sub-array patterns and / or the PDSCH power offset). In this case, a traffic steering operation may refer to an operation or process initiated by the network (e.g., Near-RT RIC 130) to direct or shift a UE’s connection away from a target network cell. For instance, if the UE 170 is not a Rel-18 UE (i.e., the UE 170 is a non-Rel 18 UE), namely, the UE 170 does not support the NES spatial and power domains adaptation feature as defined in 3GPP Rel-18, the Near-RT RIC 130 may perform one or more radio access control operations to restrict access of the UE 170 for the optimized cell, in order to achieve more energy savings for the cell. Thus, a traffic steering operation for steering a UE out of a network cell may also be referred to asan “access control operation”. In this regard, a cell-level, UE-level, and / or slice-level access control can be applied. At least four categories of radio access control, as indicated in the following, may be applied: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, and an Access Barring operation. In this regard, an RACH backoff operation may refer to an operation or procedure in which the network (e.g., Near-RT RIC, O-DU, etc.) instructs or configures a UE to wait for a period of time before starting / restarting the RACH procedure. Further, an RRC Connection Reject operation may refer to an operation or procedure in which the network (e g., O- CU, etc.) rejects an RRC Connection Request received from a UE, thereby avoiding the UE from accessing a network cell. Furthermore, an RRC Connection Release operation may refer to an operation or procedure in which the network (e.g., O-CU, etc.) instruct a UE to terminate the current connection with a network cell. In addition, an Access Barring operation may refer to an operation or procedure in which the network (e.g., O-DU, O-CU, etc.) provides, to a UE, barring parameters / configurations (e.g., cellBarred parameter in System Information Block Type (SEB 1 ), etc.) that define a barred network cell, such that the UE may avoid attempting connection to the barred network cell. The Near-RT RIC 130 may perform the above-mentioned radio access control operation(s) by implementing at least one of RIC POLICY and RIC CONTROL (e g., the Near- RT RIC 130 may send an E2 policy and / or an E2 control command to the E2 nodes such that the E2 nodes may implement the access control operation(s) based thereon).

[0067] Further descriptions of each of the above-mentioned embodiments are provided in the following, with reference to FIG. 4A to FIG. 8.Example Embodiments: Energy Saving Spatial and Power Domain Optimization

[0068] As described above, according to example embodiments, a Near-RT RIC may receive one or more Al policies via the Al interface, and then interpret the Al policy(s) to determine one or more optimum changes it can make according to the Al policy(s). Specifically, the Near-RT RIC may trigger an E2 procedure and related control and / or policies so as to obtain network performance that may fulfill the criteria defined (e.g., identified, required, etc.) in the Al policy(s). Further, the Near-RT RIC may also leverage Al enrichment information to make more informed decisions. In some example implementations, the Near-RT RIC may also operate (e.g., in Background Processing, etc.) without the Al policy guidance from the Non-RT RIC. Descriptions of an example embodiment associated therewith are provided below with reference to FIG. 4A and FIG. 4B.

[0069] FIG. 4A and FIG. 4B illustrate an example use case 400 for implementing an NES spatial and power domains optimization, according to one or more example embodiments. As illustrated in FIG. 4A, example use case 400 may involve various components from the SMO side 410 and the O-RAN side 420. Specifically, at the SMO 410 side, an Operations, Administrations, and Maintenance (0AM) function 111 and a Non-RT RIC 412 may be involved; on the other hand, at the O-RAN 420 side, a Near-RT RIC 421 and an E2 node 422 may be involved. The SMO 410, Non-RT RIC 412, and Near-RT RIC 421 in example use case 400 may be similar to the SMO 110, Non-RT RIC 120, and Near-RT RIC 130 in FIG. 1, respectively. Further, the E2 node 422 may include one or more of the O-CU 140 and O-DU 150 in FIG. 1.

[0070] Furthermore, example use case 400 may also involve one or more of the three processing modes, i.e., Baseline mode (mode 0), Background mode (mode 1), and Al Policy-based mode (mode 2), as described for Traffic Steering use case in at least one O-RAN standard specification (e.g., O-RAN. WG3.TS.UCR). These modes represent the way the Near-RT RIC 421may operate on a given group ofUEs, and may not be the operation of any component as a whole. As such, the Near-RT RIC 421 could be operating in multiple modes (e.g., operating in both modes 1 and 2, etc.) for different sets ofUEs. For example, the transition from mode 0 / 1 to 2 may occurs only for a group of EEs defined in the Al policy scope. At the same time, other EE groups may still be handled in mode 0 and / or mode 1.

[0071] Generally, in the Baseline mode (mode 0), the 0AM function 411 may utilize 01 configuration to set up a desired baseline performance monitoring of the E2 node 422. In this mode, the Near-RT RIC 421 may not be involved. In the Background mode (mode 1), the 0AM function 411 may utilize 01 configuration of the Near-RT RIC 421 to set up a desired background Near- RT RIC behavior. In this mode, the Near-RT RIC 421 may set up E2 mechanisms to monitor the E2 node 422 to achieve the desired background behavior. In the Al Policy-based mode (mode 2), the Non-RT RIC 412 uses one or more Al policies to specify an Al guided behavior for a targeted subset of E2 nodes or EEs. In this mode, the Near-RT RIC 421 may set up or modify E2 mechanisms used to monitor the E2 node 422 to obtain the desired behavior. In this regard, the processing associated with the Al Policy-based mode (mode 2) may contain an “outer loop” and an “inner loop”. In the inner loop, a number of different “E2 mechanisms” can be used (e.g., policy, report / control, insert / control, etc.) towards a number of different E2 nodes or target RAN functions. For descriptive purposes, one or more of the above-mentioned processing modes may also be referred to as the respective “Energy Saving (ES) mode” herein. For instance, the Background mode (mode 1) may also be referred to as the “ES mode 1”, the Al Policy-based mode (mode 2) may also be referred to as the “ES mode 2”, and the like.

[0072] One of the goals of the example use case 400 is to drive energy saving spatial and power domain optimization in accordance with RAN 0AM configured background behavior (ESmode 1) and / or policies information from the Non-RT RIC 412 using Al interface (ES mode 2).Generally, the OAM function 411 may collect data from the E2 node 422 through the 01 interface, and provide the data to the Non-RT RIC 412. The Non-RT RIC 412 may be configured to create and / or update one or more Al policies, as well as to provide Al enrichment information when required. The Near-RT RIC 421 may be configured to enforce the one or more Al policies (sent by the Non-RT RIC 412) and then generate an E2 control command (may also be referred to as “RIC CONTROL” or “Es optimization RIC CONTROL” herein) and / or an E2 policy (may also be referred to “POLICY” or “ES optimization POLICY” herein) based thereon. In this regard, an E2 policy may refer to one or more policies or rule sets that the Near-RT RIC 421 transmitted to the E2 node 422 over the E2 interface, while an E2 control command may refer to one or more instructions that the Near-RT RIC 421 transmitted to the E2 node 422 over the E2 interface. According to example embodiments, the Near-RT RIC 421 may transmit the E2 policy and / or E2 command to the E2 node 422 in near-real-time (e.g., within a timeframe of 10 milliseconds to 1 second). The E2 node 422 may be configured to execute the E2 control command and / or E2 policy (e g., RIC CONTROL and / or POLICY) and create a report to the Near-RT RIC 421 (may be referred to as “RIC REPORT” herein).

[0073] It may be assumed that, in example use case 400, all relevant functions and components are instantiated, the connectivity of the Al interface, 01 interface, and E2 interfaces are established, and the scope of the Al policy is defined. Further, it may be considered that, in example use case 400, the following pre-conditions are satisfied: (1) network is operational with default configuration, (2) OAM function 411 has configured a baseline measurement configuration and the Non-RT RIC 412 has access to the associated data, (3) OAM function 411 has configured baseline ES parameters in the E2 node 422 through 01 interface, (4) optionally, in ES mode 1 , theOAM function 411 has configured background ES behavior to the Near-RT RIC 421 through 01 interface, (5) Non-RT RIC 412 may analyze the historical data from the E2 node 422 for training the relevant AI / ML models to be deployed or updated in the Near-RT RIC 421, as well as AI / M1 models required for non-real-time optimization of configuration and policies. Further, example use case 400 may begin when energy saving spatial and power domains optimization is activated, and / or when a trigger defined by a network operator is detected.

[0074] Referring to FIG. 4A, example use case 400 may start with an outer loop control. At step 1, if ES mode 2 is activated, the OAM function 411 may collect data (illustrated as “RAN Data” in FIG. 4A) from the E2 node 422 through the 01 interface. At step 2, the Non-RT RIC 412 may retrieve, from the OAM function 411, data or information related to energy saving (illustrated as “ES related performance information” in FIG. 4A). Accordingly, at step 3, the Non-RT RIC 412 may evaluate the collected data and create / update an ES optimization policy based thereon, if required or applicable.

[0075] Further, at step 4, the Non-RT RCI 412 may send the ES optimization policy to the Near-RT RIC 421 via the Al interface. Thus, the ES optimization policy may also be referred to as an “Al policy” herein. According to example embodiments, the Non-RT RIC 412 may utilize a policy management function to setup or update one or more Al policies in the Near-RT RIC 421. For instance, the Non-RT RIC 412 may send the created / updated ES optimization policy to the Near-RT RIC 421 and request the Near-RT RIC 421 to update a previously provided Al policy based thereon.

[0076] At optional step 5, the Non-RT RIC 120 may send ES-related enrichment information to the Near-RT RIC 130 via the Al interface. Thus, the ES-related enrichment information may also be referred to as “ES related Al enrichment information” herein. Accordingto example embodiments, the Non-RT RIC 412 may utilize an Al enrichment information service (Al-EI) to provide Al enrichment information obtained from (or derived from data obtained from) various information sources (e.g., O-RAN internal information sources and / or O-RAN external information sources). Accordingly, if ES mode 1 is activated, at step 6, the Near-RT RIC 421 may collect data from the E2 node 422 through the E2 interface. Subsequently, at step 7, the Near-RT RIC 421 may evaluate the collected data, and then generate or update the internal background mode ES optimization targets and / or policies, if required.

[0077] Referring to FIG. 4B, an inner loop control may start at step 8, at which the Near- RT RIC 421 may subscribe to UE context information and measurement metrics via the E2 interface. According to example embodiments, the Near-RT RIC 421 may initiate a RIC Subscription procedure by sending a RIC SUBSCRIPTION REQUEST message to the E2 node 422, thereby establishing a subscription of the UE context information and measurement metrics on the E2 node 422. Subsequently, at step 9, the E2 node 422 may report the UE context information and E2 measurement metrics (as well as E2 Key Performance Indicators (KPIs), in some example implementations) to the Near-RT RIC 421. Specifically, the E2 node 422 may utilize a RIC REPORT service (e.g., by sending a RIC INDICATION message containing the UE context information and measurement metrics to the Near-RT RIC 421) periodically and / or based on detecting an event trigger. According to example embodiments, the UE context information may include static or semi-static information associated with one or more UEs, such as the identify or identifier of the UE(s) (e.g., Radio Network Temporary Identifier (RNTI), International Mobile Subscriber Identity (IMSI), etc.), the capabilities of the UE(s) (e.g., supported frequency bands and modes, maximum modulation and coding schemes, maximum transmission power, etc.), the mobility configurations / restrictions (e.g., Mobility Restriction List (MRL), Service AreaRestrictions (SAR), etc.), and the like. On the other hand, the measurement metrics may include real-time (or near-real-time) information that the E2 node 422 advertises and streams over the E2 interface, such as performance data (e.g., signal quality, throughput, etc.), UE traffic (e.g., collected and / or predicted UE traffic data), channel quality-related metrics (e.g., a series of E2 measurement metrics, a series of E2 KPIs, etc.), channel and location prediction (e.g., collected and / or predicted radio propagation channel condition data, collected and / or predicted UE location data, etc.), and the like. According to example embodiments, the Near-RT RIC 421 may obtain one or more information, such as the channel and location prediction, knowledge of the O-RU capability information, and the like, with / without utilizing the UE context information and the measurement metrics.

[0078] At step 10, the Near-RT RIC 421 may be configured to evaluate the data obtained from the E2 node 422 and find one or more potential improvements to energy efficiency indicated in the Al policy (e.g., received from the Non-RT RIC 412 at step 4) and / or internal targets of the Near-RT RIC 421 (e.g., internal Near-RT RIC Energy Saving (ES) target, etc.). For instance, the Near-RT RIC 421 may compare the obtained data against one or more performance targets (e.g., minimum throughput, maximum block-error rate, target energy consumption, target energy efficiency or target energy saving etc.) defined in the Al policy and / or the internal targets. Based on the evaluation, the Near-RT RIC 421 may determine that new candidate sub-array patterns and / or PDSCH power offsets may possibly improve the energy efficiency of the network. According to example embodiments, the data may include CSI sub-reports that include measurements on previously determined candidate sub-array patterns and / or PDSCH power offsets. In some example implementations, the Near-RT RIC 421 may implement one or more AI / ML models or technologies to evaluate the data and determine the potential improvementsbased thereon. For instance, the Near-RT RIC 421 may input the data into one or more AI / ML models and then determine, based on the output(s) of the AI / ML model(s), if there is any potential improvements to be made.

[0079] If a potential improvement is determined, the Near-RT RIC 421 may be configured to obtain or derive an E2 policy content associated with the candidate sub-array patterns and / or the candidate PDSCH power offsets. Specifically, at step 11, based on the UE context information and E2 measurement metrics (and E2 KPIs, in some example implementations)(e.g., obtained from the E2 node 422 via RIC REPORT), as well as an Al policy (e.g., ES optimization policy obtained from the Non-RT RIC 412), the Near-RT RIC 421 may generate a new E2 policy and / or modify an existing E2 policy, and then send the newly generated / modified E2 policy to the E2 node 422. The content of the E2 policy (e.g., E2 node functions target, etc.) may be associated with or define the candidate sub-array patterns and / or candidate PDSCH power offsets (e.g., determined via the evaluation at step 10). In this regard, an E2 node function(s) target may refer to the function attributes inside an E2 node that the E2 policy is allowed to read, configure, or adjust. Namely, when an E2 policy includes an E2 node function(s) target that is associated with or defines the candidate sub-array patterns and / or candidate PDSCH power offsets, the E2 policy may be utilized by an associated E2 node (e.g., E2 node 422) to adjust the local candidate sub-array patterns and / or candidate PDSCH power offsets based on those defined in the E2 node function(s) target. The E2 policy may also be referred to as an “ES optimization policy” herein. According to example embodiments, the Near-RT RIC 421 may initiate a RIC Subscription procedure by sending a RIC SUBSCRIPTION REQUEST message to the E2 node 422, thereby sending the E2 optimization policy to the E2 node 422.

[0080] Additionally or alternatively, if a potential improvement is determined, the Near- RT RIC 421 may be configured to generate, obtain, or derive a control command associated with the candidate sub-array patterns and / or the candidate PDSCH power offsets. Specifically, in addition to or in alternative to step 11, based on the UE context information and E2 measurement metrics (and E2 KPIs, in some example implementations)(e.g., obtained from the E2 node 422 via RIC REPORT), as well as an Al policy (e.g., ES optimization policy obtained from the Non-RT RIC 412), the Near-RT RIC 421 may generate a new E2 control command and / or modify an existing E2 control command, and then send the newly generated / modified E2 control command to the E2 node 422 at step 12. The content of the E2 control command (e.g., E2 node functions target, etc.) may be associated with or define the candidate sub-array patterns and / or candidate PDSCH power offsets (e.g., determined via the evaluation at step 10). In this regard, an E2 node function(s) target may refer to the function attributes inside an E2 control command that the E2 control command is allowed to read, configure, or adjust. Namely, when an E2 control command includes an E2 node function(s) target that is associated with or defines the candidate sub-array patterns and / or candidate PDSCH power offsets, the E2 control command may be utilized by an associated E2 node (e.g., E2 node 422) to adjust the local candidate sub-array patterns and / or candidate PDSCH power offsets based on those defined in the E2 node function(s) target. The control command may also be referred to as an “ES optimization RIC control command” herein. According to example embodiments, the Near-RT RIC 421 may initiate a RIC Control procedure by sending a RIC CONTROL REQUEST message to the E2 node 422, thereby sending the E2 control command to the E2 node 422.

[0081] Steps 8 to 12 may be repeatedly or iteratively performed for at least a predetermined period of time until, for example, an event is detected (e.g., a target energy saving is achieved,energy saving over a period of time is achieved, etc.). Accordingly, the inner loop control may be ended. Subsequently, if the ES mode 2 is activated, at step 13, the Near-RT RIC 421 may send anAl policy feedback to the Non-RT RIC 412 via the Al interface. Steps 1 to 13 may be repeatedly or iteratively performed for at least a predetermined period of time until, for example an event is detected (e.g., Non-RT RIC 412 decides to delete the ES optimization policy, ES optimization is deactivated, an operator-defined trigger is detected, etc.). Accordingly, the outer loop control may be ended.

[0082] Referring still to FIG. 4B, upon ending the outer loop control, if ES mode 2 is activated, the Non-RT RIC 412 may decide to delete the ES optimization policy. Thus, at step 14, the Non-RT RIC 412 may send the related messages to the Near-RT RIC 421 to delete the ES optimization policy. According to example embodiments, the Non-RT RIC 412 may utilize the policy management function to delete the ES optimization policy (e.g., via initiating an Al policy delete procedure, etc.). Upon receiving Al policy deletion-related messages from the Non-RT RIC 412 (in case of ES mode 2) and / or based on detecting an internal trigger (in case of ES mode 1), at step 15, the Near-RT RIC 421 may terminate the ES optimization procedure. Accordingly, at step 16, the Near-RT RIC 421 may delete the related RIC Subscriptions. According to example embodiments, the Near-RT RIC 421 may send a RIC SUBSCRIPTION DELETE REQUEST message to the E2 node 422, thereby requesting the deletion of the existing subscriptions in the E2 node 422

[0083] In view of the above, the present disclosure introduces various example operations to implement the Near-RT RIC 421 to interoperate with other components (e.g., Non-RT RIC 412, E2 node 422, etc.) to dynamically (or continuously) determine, derive, or update, in real-time or near-real-time, the candidate sub-array patterns and / or candidate PDSCH power offsets that maypotentially improve the energy efficiency, and provide the information associated therewith to the E2 node 422 (e.g., in the form of E2 policy and / or E2 control command). Accordingly, an optimal sub-array pattern and / or PDSCH power offset may be selected from among the candidate subarray patterns and / or candidate PDSCH power offsets, thereby efficiently and effectively adapting to the NES spatial and power domain optimizations.

[0084] It is contemplated that the features and operations described above with reference to FIG. 4A and FIG. 4B are merely examples, and the scope of the present disclosure should not be limited thereto. Specifically, in addition to or in alternative to the Near-RT RIC 421, the Non- RT RIC 412 may also be configured to determine the potential improvement s) to the energy efficiency. For instance, upon obtaining the ES-related performance data or information from the 0AM function 411, the Non-RT RIC 412 may determine or derive the candidate sub-array patterns and / or PDSCH power offsets that may improve the energy efficiency of the network based thereon. In some example embodiments, the Non-RT RIC 412 may implement one or more AI / ML models or technologies to evaluate the data and determine the potential improvement(s) based thereon. For instance, the Near-RT RIC 421 may input the data into one or more Al / AIL models (trained for predicting the potential improvement based on the input data) and then determine, based on the output(s) of the AI / ML model(s), if there is any potential improvement to be made. Upon determining the potential improvement, the Non-RT RIC 412 may provide the information to the Near-RT RIC 421 via the Al interface (e g., including the information in an Al policy and provide the Al policy to the Near-RT RIC 421), and / or provide the information to the information to the E2 node 422 via the 01 interface.Example Embodiments: Near-RT RIC-Driven Optimizations

[0085] As described above, the present disclosure provides several example embodiments where the NES spatial and power domains optimization may be controlled by the Near-RT RIC.Descriptions of several example use cases associated therewith are provided below with reference to FIG. 5 and FIG. 6.

[0086] FIG. 5 illustrates a first example use case 500 for implementing the Near-RT RIC to control the NES spatial and power domain optimization, according to one or more example embodiments. As illustrated in FIG. 5, example use case 500 may involve a Near-RT RIC 510, a plurality of E2 nodes 520, and a UE 530. The Near-RT RIC 510 may be similar to the Near-RT RIC 130 in FIG. 1, and may be configured to implement at least one xApp 511 which may, upon being executed, perform one or more operations of the Near-RT RIC 510 described herein. The E2 nodes 520 may include an O-CU 521 and an 0-DU 522, which may be similar to the O-CU 140 and the 0-DU 150 in FIG. 1, respectively. The E2 nodes may also be referred to herein as the “network nodes”. The UE 530 may be similar to the UE 170 in FIG. 1. It may be understood that the configuration in FIG. 5 may be simplified for descriptive purposes, and the scope of the present disclosure should not be limited thereto. For instance, in the actual implementations, one or more O-RUs (e.g., O-RUs 160) may be located between the E2 nodes 520 and the UE 530, and may transmit messages or data packets therebetween.

[0087] Referring to FIG. 5, at step 1, the Near-RT RIC 510 may provide an E2 policy and / or E2 control command to at least one of the E2 nodes 520 via the E2 interface. For instance, the Near-RT RIC 510 may implement the xApp 511 to send the E2 policy and / or E2 control command to the O-CU 521 via the E2 interface. The E2 policy and / or E2 control command may include information associated with a list of candidate sub-array patterns (or candidate antenna port subset) and / or candidate PDSCH power offsets. The information of the list of candidate sub-array patterns and / or candidate PDSCH power offsets may be determined or derived by the Near- RT RIC 510 (or the associated xApp 511) via, for example, implementing the call flow of FIG. 4A and FIG. 4B. Alternatively or additionally, the information of the list of candidate sub-array patterns and / or candidate PDSCH power offsets may be determined or derived by the Near-RT RIC 510 (or the associated xApp 511) based on data or information obtained from the E2 nodes 520 (e.g., based on the UE traffic, the channel and location prediction, the knowledge of the 0-RU capability information, etc.), with / without involving the policy information from a Non-RT RIC. According to example embodiments, the data / information obtained from the E2 nodes 520 may include at least one of a collected UE traffic data, a predicted UE traffic data, a collected radio propagation channel condition data, a predicted radio propagation channel condition data, a collected UE location data, a predicted UE location data, or the O-RU capability information.

[0088] Upon receiving the E2 policy and / or E2 control command, at step 2 the E2 node(s)520 may configure CSI report sub-configurations based thereon. For instance, the O-CU 521 may generate an RRC message (e.g., RRC Reconfiguration message) that includes an Information Element (IE) that defines the list of candidate sub-array patterns and / or PDSCH power offsets, and then provide the RRC message to the UE 530. For instance, in some example embodiments, the information of the candidate sub-array patterns and / or candidate PDSCH power offsets may be included in the CSI-ReportConfig IE as defined in 3GPP Rel-18. The O-CU 521 may provide the RRC message to the UE 530 via the O-DU 522 (e.g., O-CU 521 may provide the RRC message to the O-DU 522 via the Fl interface, and the O-DU 522 may then forward the RRC message to the UE 530).

[0089] Upon receiving the CSI report sub-configurations from the E2 node(s) 520, the UE530 may update the associated RRC configurations and initialize any new CSI reportingconfiguration (including CSI reporting sub-configurations). For instance, the UE 530 may determine or update a reporting type (e.g., periodic, semi-persistent, aperiodic), a list of port subset indicators each of which defines a candidate sub-array pattern associated with a CSI sub-report, a list of power offsets each of which is associated with a CSI sub-report, and the like.

[0090] Subsequently, the UE 530 may perform CSI measurements at each CSI-RS occasion. For instance, the UE 530 may perform channel estimation on the specified antenna ports and / or PDSCH power offset for each CSI report sub-configuration, and then compute one or more CSI parameters associated therewith, such as Channel Quality Indicator (CQI), Precoding Matrix Indicator (PMI), CSI-RS Resource Indicator (CRI), Synchronization Signal (SS) / Physical Broadcast Channel (PBCH) Block Resource Indicator (SSBRI), Layer Indicator (LI), Rank indicator (RI), Layer 1 Reference Signal Received Power (Ll-RSRP), Layer 1 Signal-to-Inference- plus-Noise Ratio (Ll-SINR), Capability Index, Time-Domain Channel Properties (TDCP), and the like. Each CSI sub-report may include one or more CSI parameters associated with one CSI configuration (e g., one candidate sub-array pattern, one candidate PDSCH power offset, a combination of one candidate sub-array pattern and one candidate PDSCH power offset, etc.).

[0091] Upon performing the CSI measurements, at step 3, the UE 530 may provide the CSI sub-reports to the E2 node(s) 520. For instance, the UE 530 may provide the CSI sub-reports to the 0-DU 522 on the Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH). In some example implementations, the UE 530 may aggregate the CSI subreports into a single CSI report and provide the CSI report to the E2 nodes 520.

[0092] Upon receiving the CSI sub-reports, at step 4, the E2 node(s) 520 may select an appropriate sub-array pattern and / or PDSCH power offset for a transmission. For instance, the O- DU 522 may receive the CSI sub-reports from the UE 530 and then select, based on the CSI sub-reports and from among the candidate sub-array patterns and / or candidate PDSCH power offsets, a sub-array pattern and / or PDSCH power offset for downlink (DL) transmissions. As a nonlimiting example, the O-DU 522 may evaluate the one or more CSI parameters (e.g., CQI, PMI, RI, etc.) included in the CSI sub-reports against target Quality-of-Service (QoS) requirements (e g. throughput, latency, error rate etc). Accordingly, the O-DU 522 may select, from among the candidate sub-array patterns and / or candidate PDSCH power offsets, the sub-array pattern and / or PDSCH power offset that consumes the lowest amount of energy while still satisfying the QoS requirements.

[0093] In some example embodiments, upon selecting the appropriate or optimal sub-array pattern and / or PDSCH power offset, the E2 nodes 520 may provide information associated therewith to one or more O-RUs. For example, the O-DU 521 may communicate with an underlying O-RU via the O-FH M-plane / C-plane and provide information of the selected sub-array pattern and / or PDSCH power offset thereto. Accordingly, the O-RU may adjust the configurations of the associated antenna arrays (e.g., activate and deactivate the antenna ports according to the selected sub-array pattern, etc.) and / or the power settings (e.g., configure the digital power scaling and power amplifier settings to apply the selected PDSCH power offset, etc.).

[0094] FIG. 6 illustrates a second example use case 600 for implementing the Near-RT RIC to control the NES spatial and power domains optimization, according to one or more example embodiments. Similar to example use case 500 in FIG. 5, example use case 600 may also involve a Near-RT RIC 610, a plurality of E2 nodes 620, and a UE 630. The Near-RT RIC 610 may be similar to the Near-RT RIC 130 in FIG. 1 or Near-RT RIC 510 in FIG. 5, and may be configured to implement at least one xApp 611 which, upon being executed, perform one or more operations of the Near-RT RIC 610 described herein. The E2 nodes 620 may include an O-CU 621 and an O-DU 622, which may be similar to the O-CU 140 and the 0-DU 150 in FIG. 1 or 0-CU 521 and O- DU 522 in FIG. 5, respectively. The E2 nodes may also be referred to herein as the “network nodes”. The UE 630 may be similar to the UE 170 in FIG. 1 or UE 530 in FIG. 5. It may be understood that the configuration in FIG. 6 may be simplified for descriptive purposes, and the scope of the present disclosure should not be limited thereto. For instance, in the actual implementations, one or more O-RUs (e.g., O-RUs 160) may be located between the E2 nodes 620 and the UE 630 and may transmit messages or data packets therebetween.

[0095] One or more operations in example use case 600 may be similar to those described above with reference to example use case 500 in FIG. 5. Specifically, step 2 and step 3 in example use case 600 may be similar to step 2 and step 3 in example use case 500, respectively. Thus, detailed descriptions associated therewith may be omitted herein for conciseness. It is also contemplated that one or more operations in example use case 600 may be performed together with one or more operations in example use case 500, in any suitable sequential manner.

[0096] Example use case 600 is different from example use case 500 in that, instead of providing a list of candidate sub-array patterns and / or candidate PDSCH power offsets to the E2 nodes and allowing the E2 nodes to determine the CSI report sub-configurations, receive the CSI sub-reports from the UE, and select the appropriate sub-array pattern and / or PDSCH power offset, the Near-RT RIC 610 in example use case 600 may be configured to directly configure the CSI report sub-configurations, receive the CSI sub-reports, and select the appropriate sub-array pattern and / or PDSCH power offset based thereon.

[0097] Referring to FIG. 6, at step 1, the Near-RT RIC 610 may provide an E2 policy and / or E2 control command to the E2 nodes 620 via the E2 interface. For instance, the Near-RTRIC 610 may implement the xApp 61 1 to send the E2 policy and / or E2 control command to theO-CU 621 via the E2 interface. The E2 policy and / or E2 control command may include information associated with one or more CSI report sub-configurations determined by the Near-RT RIC 610 (or the associated xApp 611) based on a list of candidate sub-array patterns (or candidate antenna port subset) and / or candidate PDSCH power offsets. The information of the candidate sub-array patterns and / or candidate PDSCH power offsets may be determined or derived by the Near-RT RIC 610 (or the associated xApp 611) via, for example, implementing the call flow of FIG. 4A and FIG. 4B, based on one or more data / information obtained from the E2 nodes 620 (with / without involving the policy information from the Non-RT RIC), and the like. According to example embodiments, the data / information obtained from the E2 nodes 620 may include at least one of a collected UE traffic data, a predicted UE traffic data, a collected radio propagation channel condition data, a predicted radio propagation channel condition data, a collected UE location data, a predicted UE location data, or the 0-RU capability information.

[0098] Upon receiving the information associated with the CSI report sub-configurations from the Near-RT RIC 610 (or the xApp 611 associated therewith), at step 2, the E2 node(s) 620 may be configured to provide the information associated with the CSI report sub-configurations to the UE 630. For instance, the O-CU 621 may generate an RRC message (e.g., RRC Reconfiguration message, etc.) that includes one or more IES that define the CSI report subconfigurations, and then provide the RRC message to the UE 630. The O-CU 621 may provide the RRC message to the UE 630 via the 0-DU 622 (e.g., O-CU 621 may provide the RRC message to the 0-DU 622 via the F 1 interface, and the 0-DU 622 may then forward the RRC message to the UE 630).

[0099] Upon receiving the information associated with the CSI report sub-configurations from the E2 node(s) 620, the UE 630 may perform the CSI measurements and provide the CSIsub-reports (which may also be aggregated into a single CSI report) to the E2 node(s) 620. Accordingly, at step 4, the E2 node(s) 620 may forward the CSI sub-reports to the Near-RT RIC 610 (or the associated xApp 611) via the E2 interface.

[0100] Upon receiving the CSI sub-reports, the Near-RT RIC 610 (or the associated xApp 611) may select an appropriate sub-array pattern and / or PDSCH power offset for a transmission based thereon. For instance, the Near-RT RIC 610 (or the associated xApp 611) may compare the CSI parameter(s) with the associated threshold(s), and select the sub-array pattern and / or PDSCH power offset that consume the minimum energy while satisfying the condition(s) defined by the associated threshold(s). The operations associated therewith may be similar to those described above with reference to step 4 in example use case 500 of FIG. 5.

[0101] Accordingly, at step 5, the Near-RT RIC 610 (or the associated xApp) may provide the information of the selected sub-array pattern and / or PDSCH power offset to the E2 node(s) 610. For instance, the Near-RT RIC 610 (or the associated xApp) may include said information in an E2 control command and / or an E2 policy, and then provide the E2 control command and / or the E2 policy to the 0-DU 622, thereby directly instructing the 0-DU 622 which sub-array pattern (e.g., which port subset) and / or power offset to use, in real-time (or near-real-time).

[0102] In view of the above, example embodiments introduce several mechanisms and approaches to efficiently and effectively implement the Near-RT RIC and the existing 0-RAN interfaces (e.g., E2 interface, Fl interface, etc.) to control the NES spatial and power domains optimization. It is contemplated that the operations and features described above with reference to FIG. 5 and FIG. 6 are merely examples, and the scope of the present disclosure should not be limited thereto.Example Embodiments: Non-RT RIC-Driven Optimizations

[0103] As described above, the present disclosure provides several example embodiments where the NES spatial and power domains optimization may be controlled by the Non-RT RIC.Descriptions of several example use cases associated therewith are provided below with reference to FIG. 7 and FIG. 8. One or more operations in the example use cases of FIG. 7 and / or FIG. 8 may be performed in addition to or in alternative to one or more operations in the example use cases of FIG. 5 and / or FIG. 6.

[0104] FIG. 7 illustrates a first example use case 700 for implementing the Non-RT RIC to control the NES spatial and power domains optimization, according to one or more example embodiments. As illustrated in FIG. 7, example use case 700 may involve an SMO 710 (that implements a Non-RT RIC 720), a Near-RT RIC 730, a plurality of E2 nodes 740, and a UE 750, each of which may be similar to the corresponding component described above with reference to FIG. 1 to FIG. 6. The Non-RT RIC 720 may be configured to implement at least one rApp 721, while the Near-RT RIC 730 may be configured to implement at least one xApp 731. The communications between the Non-RT RIC 720 (or the associated rApp 721) and the Near-RT RIC 730 (or the associated xApp 731) may be performed via the Al interface. It may be understood that the configuration in FIG. 7 may be simplified for descriptive purposes, and the scope of the present disclosure should not be limited thereto. For instance, in the actual implementations, one or more O-RUs (e.g., O-RUs 160) may be located between the E2 nodes 740 and the UE 750, and may transmit messages or data packets therebetween.

[0105] One or more operations in example use case 700 may be similar to one or more operations described above with reference to example use case 500 in FIG. 5 and / or example use case 600 in FIG. 6. For instance, steps 2, 3, 4, and 5 in example use case 700 may be similar to steps 1, 2, 3, and 4 in example use case 500, respectively. As another example, step 5 in exampleuse case 700 may (but not necessarily) involve steps 4 and 5 in example use case 600 in FIG. 6.Thus, detailed descriptions associated therewith may be omitted below for conciseness.

[0106] Example use case 700 is different from example use cases 500 and 600 in that, in example use cases 500 and 600, the NES spatial and power domains optimization is controlled and implemented by the Near-RT RIC; on the other hand, in example use case 700, the NES spatial and power domains optimization is controlled and implemented by the Non-RT RIC.

[0107] Referring to FIG. 7, at step 1, the Non-RT RIC 720 may provide an Al policy to the Near-RT RIC 730. For instance, the Non-RT RIC 720 may implement the rApp 721 to generate a new Al policy and / or update an existing Al policy based on, for example, one or more energy saving-related performance data / information obtained from the E2 nodes 740 (via an 0AM function of the SMO 710, etc.). The new / updated Al policy may include information of candidate sub-array patterns (e.g., candidate port subset patterns), candidate PDSCH power offsets, QoS objectives or requirements, NES objectives or requirements, power management requirements, and / or the like. According to example embodiments, the Non-RT RIC 720 (or the associated rApp 721) may implement one or more trained / fine-tuned AI / ML models or technologies to determine the potential improvements based thereon. For instance, the Non-RT RIC 720 (or the associated rApp 721) may input the energy saving-related performance data / information into one or more AI / ML models and then determine, based on the output(s) of the AI / ML model(s), the candidate sub-array patterns and / or candidate PDSCH power offsets. Subsequently, the Non-RT RIC 720 (or the associated rApp 721) may include the information associated therewith into the new / updated Al policy. Upon obtaining the new / updated Al policy, the Non-RT RIC 720 (or the associated rApp 721) may provide the new / updated Al policy to the Near-RT RIC 730 (or the associated xApp 731) via the Al interface.

[0108] Upon receiving the Al policy from the Non-RT RIC 720 (or the associated rApp721), the Near-RT RIC 730 (or the associated xApp 731) may be configured to obtain or derive anE2 policy and / or E2 control command based thereon, and then provide the E2 policy and / or E2 control command to at least one of the E2 nodes 740 via the E2 interface (at step 2). For instance, the E2 policy and / or E2 control command may include information of the candidate sub-array patterns and / or candidate PDSCH power offsets (defined in the Al policy) as described above with reference to example use case 500 in FIG. 5, or may include information of CSI report subconfigurations determined based on the candidate sub-array patterns and / or candidate PDSCH power offsets as described above with reference to example use case 600 in FIG. 6.

[0109] Upon receiving the E2 policy and / or E2 control command from the Near-RT RIC 730 (or the associated xApp 731), the E2 node(s) 740 may provide the CSI report subconfigurations to the UE 750 (at step 3). For instance, assuming that the O-CU 741 receives the E2 policy and / or E2 control command that includes the candidate sub-array patterns and / or candidate PDSCH power offsets, the O-CU 741 may determine the CSI report sub-configurations based thereon, include the associated information into one or more IES of an RRC message (e.g., RRC Reconfiguration message), and then provide the RRC message to the UE 750. As another example, assuming that the O-CU 741 receives the E2 policy and / or E2 control command that includes the CSI report sub-configurations, the O-CU 741 may simply include the information of the CSI report sub-configurations into one or more IEs of an RRC message (e.g., RRC Reconfiguration message) and provide the RRC message to the UE 750.

[0110] Upon receiving the CSI report sub-configurations, the UE 750 may perform the CSI measurements based thereon and provide CSI sub-reports to at least one of the E2 nodes 740 (at step 4). In this regard, at step 5, the at least one of the E2 nodes 740 may either select an appropriatesub-array pattern (or antenna port subset) and / or PDSCH power offset based on the CSI subreports (as described above with reference to example use case 500 in FIG. 5), or may provide theCSI sub-reports to the Near-RT RIC 730 (or the associated xApp 731) such that the Near-RT RIC 730 (or the associated xApp 731) may select the appropriate sub-array pattern (or antenna port subset) and / or PDSCH power offset based on the CSI sub-reports (as described above with reference to example use case 600 in FIG. 6).[OHl] FIG. 8 illustrates a second example use case 800 for implementing the Non-RT RIC to control the NES spatial and power domains optimization, according to one or more example embodiments.

[0112] As illustrated in FIG. 8, example use case 800 may involve an SMO 810 (that implements a Non-RT RIC 820), a plurality of E2 nodes 830 (i.e., at least one O-CU 831 and at least one 0-DU 832), and a UE 840, each of which may be similar to the corresponding component described above with reference to FIG. 1 to FIG. 7. The Non-RT RIC 820 may be configured to implement at least one rApp. The communications between the Non-RT RIC 820 (or the associated rApp) and the E2 nodes 830 may be performed via the 01 interface. It may be understood that the configuration in FIG. 8 may be simplified for descriptive purposes, and the scope of the present disclosure should not be limited thereto. For instance, in the actual implementations, one or more O-RUs (e.g., O-RUs 160) may be located between the E2 nodes 830 and the UE 840, and may transmit messages or data packets therebetween.

[0113] One or more operations in example use case 800 may be similar to one or more operations described above with reference to example use case 500 in FIG. 5, example use case 600 in FIG. 6, and / or example use case 700 in FIG. 7. For instance, steps 2, 3, and 4 in example use case 800 may be similar to steps 2, 3, and 4 in example use case 500 or steps 3, 4, and 5 inexample use case 7, respectively. Thus, detailed descriptions associated therewith may be omitted below for conciseness. Example use case 800 is different from the previous example use cases in that, the energy saving spatial and power domains optimization is controlled and implemented by the Non-RT RIC, without requiring the involvement of the Near-RT RIC.

[0114] Referring to FIG. 8, at step 1, the Non-RT RIC 820 may provide information associated with a list of candidate sub-array patterns (or antenna port subsets) and / or candidate PDSCH power offsets to the E2 nodes 830 (via the 01 interface). The list of candidate sub-array patterns and / or candidate PDSCH power offsets may be determined or derived by the Non-RT RIC 820 (or the associated rApp) in a similar manner as described above with reference to one or more of FIG. 1 to FIG. 7.

[0115] Upon receiving the information of the candidate sub-array patterns and / or candidatePDSCH power offsets from the Non-RT RIC 820 (or the associated rApp), at step 2, the E2 node(s) 830 may determine and provide CSI report sub-configurations to the UE 840. For instance, assuming that the O-CU 831 receives the information associated with the candidate sub-array patterns and / or candidate PDSCH power offsets, the O-CU 831 may determine the CSI report subconfigurations based thereon, include the associated information into one or more IES of an RRC message (e.g., RRC Reconfiguration message), and then provide the RRC message to the UE 840.

[0116] Upon receiving the CSI report sub-configurations, at step 3, the UE 840 may perform the CSI measurements based thereon and provide CSI sub-reports to at least one of the E2 nodes 830. Subsequently, at step 4, the at least one of the E2 nodes 830 may select an appropriate sub-array pattern (or antenna port subset) and / or PDSCH power offset based on theCSI sub-reports (as described above with reference to example use case 500 in FIG. 5)

[0117] In view of the above, example embodiments introduce several mechanisms and approaches to efficiently and effectively implement the Non-RT RIC and the existing 0-RAN interfaces (e.g., Al interface, E2 interface, 01 interface, Fl interface, etc.) to control the NES spatial and power domains optimization. It is contemplated that the operations and features described above with reference to FIG. 7 and FIG. 8 are merely examples, and the scope of the present disclosure should not be limited thereto.Example Embodiments: Traffic Steering

[0118] As described above, example embodiments of the present disclosure may utilize the Non-RT RIC and / or Near-RT RIC to optimize spatial and power domains energy savings by determining an optimal sub-array pattern and / or PDSCH power offset and implementing the same. In this regard, a network cell may be deemed as “optimized for spatial and power domains energy savings” if the network cell has applied the optimal sub-array pattern (e.g., only the minimal subset of antenna ports is activated, etc.) and / or the optimal PDSCH power offset (e g., only the minimal amount of required RF power is applied, etc ). In order to further optimize the energy savings, the present disclosure further describes several example embodiments to steer the UEs that support the 3GPP Rel-18 NES feature (i.e., Rel-18 UEs) to the network cell optimized for spatial and power domains energy savings, and steer the UEs that do not support the 3 GPP Rel-18 NES feature (i.e., non-Rel-18 UEs) out of the network cell optimized for spatial and power domains energy savings.

[0119] According to example embodiments, the Near-RT RIC may be configured to perform a traffic steering operation to steer the Rel-18 UEs toward the network cell optimized for spatial and power domains energy savings. For instance, the following procedures may be used for mobility control to steer the Rel-18 UEs towards the optimized network cell : a handover operation,a management of a handover restriction list, a configuration of an idle mode mobility parameter, a management of CA, and a management of dual connectivity.

[0120] According to example embodiments, the Near-RT RIC 130 may be configured to perform a steering operation to steer the non-Rel-18 UEs out of the network cell optimized for spatial and power domains energy savings. For instance, one or more radio access procedures may be implemented to restrict access of the non-Rel-18 UEs for the optimized network cell. Thus, a steering operation that steers a UE out of the network cell may also be referred to as an “access control operation”. In this regard, a cell-level, UE-level, and / or slice-level access control can be applied. At least four categories of radio access control, as indicated in the following, may be applied: an RACH backoff operation, an RRC Connection Reject operation, an RRC Connection Release operation, and an Access Barring operation.

[0121] In some example embodiments, the Near-RT RIC may determine or identify (e.g., based on UE capability information received during the RRC setup or reconfiguration stage, etc.) the type of each of the UEs within or associated with the optimized network cell. Based on determining that one or more of the UEs are Rel-18 UEs, the Near-RT RIC may initiate E2 control procedures to perform one or more of the above-mentioned mobility control procedures on the UEs determined as the Rel-18 UEs. On the other hand, based on determining that one or more of the UEs are non-Rel-18 UEs, the Near-RT RIC may initiate E2 control procedures to perform one or more of the above-mentioned radio access control procedures on the UEs determined as the non-Rel-18 UEs. The Near-RT RIC may generate and provide E2 policy and / or E2 control command to the downstream components (e.g., O-CU, 0-DU, etc.) to implement the mobility control procedure(s) and / or radio access control procedure(s).

[0122] In view of the above, example embodiments introduce several mechanisms and approaches to effectively and efficiently implement the Near-RT RIC to control access and mobility of UEs towards / away from a network cell optimized for NES spatial and power domains adaptation, thereby further optimizing the energy efficiency. It is contemplated that the operations and features described above are merely examples, and the scope of the present disclosure should not be limited thereto.Example Methods and Operations

[0123] As described above with reference to FIG. 1 to FIG. 8, the 0-RAN components (e.g., Non-RT RIC, Near-RT RIC, O-CU, O-DU, etc.) may interoperate and perform one or more methods and operations to adapt spatial and power domains energy saving optimizations. Several example methods and operations, according to one or more example embodiments, are described below with reference to FIG. 9 to FIG. 12. One or more features, parameters, and operations associated with FIG. 9 to FIG. 12 may be similar to or involve one or more operations, messages, data, information, mechanism, and the like, described above with reference to FIG. 1 to FIG. 8, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0124] For descriptive purposes, the methods and operations may be mainly described as being performed by one or more specific network entities or components, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure. For instance, an operation of a Near-RT RIC providing a data to a network node (e.g., an E2 node) may suggest or indicate an operation of the network node receiving the data from the Near-RT RIC, and the like.

[0125] According to example embodiments, one or more operations of described herein may be implemented in one or more devices or hardware components. For instance, the Near-RTRIC / network node (or one or more associated operations) may be implemented in an apparatus or a device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations associated therewith.

[0126] FIG. 9 illustrates a first example method 900, according to one or more example embodiments. One or more operations in method 900 may be implemented by a Near-RT RIC or an application (e.g., an xApp) associated therewith.

[0127] Referring to FIG. 9, at operation S910, the Near-RT RIC (or the associated xApp) may be configured to obtain or derive a list of candidate sub-array patterns and / or PDSCH power offsets. For instance, the Near-RT RIC (or the associated xApp) may obtain or derive the list of candidate sub-array patterns and / or PDSCH power offsets based on at least one of a User Equipment (UE) traffic (e.g., a UE traffic data collection, a UE traffic data prediction, etc.), a channel and location collection / prediction (e.g., a radio propagation channel condition data prediction, a radio propagation channel condition data collection, a location data collection, a location data prediction, etc.), or Open RAN Radio Unit (0-RU) capability information. In this regard, the UE traffic may refer to the uplink and / or downlink data packet load associated with a UE, such as queue size, buffer status, and the like. The UE traffic data may be collected by the Near-RT RIC (or the associated xApp) from, for example, one or more E2 nodes (e.g., O-CU, O- DU, etc.) and / or one or more upstream components (e.g., Non-RT RIC, etc.). Additionally or alternatively, the UE traffic data may be predicted by, for example, the Near-RT RIC (or theassociated xApp), one or more E2 nodes (e.g., O-CU, O-DU, etc.) and / or one or more upstream components (e.g., Non-RT RIC, etc.), with or without the implementation of AI / ML models. The channel and location collection / prediction may refer to the collection and / or prediction of data associated with the radio propagation channel condition / state and geographical location / position of the UE. The radio propagation channel condition data and / or the location data may be collected by the Near-RT RIC (or the associated xApp) from, for example, one or more E2 nodes (e.g., O- CU, O-DU, etc.) and / or one or more upstream components (e.g., Non-RT RIC, etc.). Additionally or alternatively, radio propagation channel condition data and / or the location data may be predicted by, for example, the Near-RT RIC (or the associated xApp), one or more E2 nodes (e.g., O-CU, O-DU, etc.) and / or one or more upstream components (e.g., Non-RT RIC, etc ), based on, for example, historical data (e.g., historical CSI measurement, historical mobility data, etc.), with or without the implementation of AI / ML models. The O-RU capability information may refer to the features and configurations supported by an O-RU, such as the supported antenna configurations, power ranges, carrier bands, software configurations, and the like.

[0128] According to example embodiments, the Near-RT RIC (or the associated xApp) may be configured to obtain an Al policy from a Non-RT RIC (or an rApp associated therewith), and then obtain or derive the list of candidate sub-array patterns and / or PDSCH power offsets based on the Al policy (as described in the example embodiments and use cases in FIG. 4A to FIG. 4B, and FIG. 7). According to example embodiments, the Near-RT RIC (or the associated xApp) may obtain or derive an E2 policy and / or an E2 control command associated with the candidate sub-array patterns and / or PDSCH power offsets, based on the Al policy sent by theNon-RT RIC (or the rApp associated therewith).

[0129] At operation S920, the Near-RT RIC (or the associated xApp) may be configured to provide, to an E2 node, the list of candidate sub-array patterns and / or PDSCH power offsets as potential choices for a transmission. The E2 node may include an O-CU and / or an 0-DU. According to example embodiments, the Near-RT RIC (or the associated xApp) may send, to the E2 node, an E2 policy and / or an E2 control command associated with the candidate sub-array patterns and / or PDSCH power offsets.

[0130] FIG. 10 illustrates a second example method 1000, according to one or more example embodiments. One or more operations in method 1000 may be implemented by a Near- RT RIC or an application (e.g., an xApp) associated therewith. For instance, one or more operations in method 1000 may (but not necessarily) be performed by the Near-RT RIC (or the associated xApp) that performs one or more operations in method 900. In this regard, one or more operations in method 1000 may be performed in any suitable sequential manner in relation to one or more operations in method 900 (e.g., operation S1010 may be performed in between operations S910 and S920 in method 900, etc.).

[0131] Referring to FIG. 10, at operation S1010, the Near-RT RIC (or the associated xApp) may be configured to obtain or derive an E2 policy and / or an E2 control command associated with the candidate sub-array patterns and / or the PDSCH power offsets. For instance, the Near-RT RIC may be configured to obtain or derive the E2 policy and / or E2 control command based on an Al policy sent by a Non-RT RIC (as described in the example embodiments and use cases in FIG. 4A to FIG. 4B, and FIG. 7).

[0132] According to example embodiments, the operation S1010 may further include operations S 1011 to S 1013. At operations S 1011, the Near-RT RIC (or the associated xApp) may be configured to obtain, from the E2 node, a UE context and an E2 measurement metric. In someexample embodiments, the Near-RT RIC (or the associated xApp) may be further configured to obtain, from the E2 node, a series of E2 measurement metrics and a series of E2 KPIs. In this regard, an E2 measurement metric may refer to the data (e.g., collected and provided by one or more E2 nodes) that defines the real-time or near-real-time measurement on the network performance. According to example embodiments, the E2 measurement metric may include one or more CSI parameters (measured and reported by the UE to the one or more E2 nodes), such as CQI, RSRP, SINR, and any other suitable parameters or information. On the other hand, an E2 KPI may refer to a parameter aggregated or derived based on one or more E2 measurement metrics (e.g., average cell throughput that may be defined in terms of Mbps / mins, handover success rate that may be defined in terms of percentage, energy-efficiency score that may be defined in terms of Mbps / Watts, etc.). Accordingly, at operation S1012, the Near-RT RIC (or the associated xApp) may be configured to determine a potential improvement to energy efficiency defined (e.g., indicated, requested, etc.) in the Al policy. For instance, the Near-RT RIC (or the associated xApp) may evaluate the UE context and E2 measurement metric(s) (as well as the E2 KPIs, when applicable) to determine the potential improvement. If the potential improvement is determined, at operation S 1013, the Near-RT RIC (or the associated xApp) may be configured to obtain or derive the E2 policy and / or the E2 control command based on the UE context, the E2 measurement metric(s) (as well as the E2 KPIs, when applicable), and the Al policy. For instance, the Near-RT RIC (or the associated xApp) may generate a new E2 policy and / or a new E2 control command. As another example, the Near-RT RIC (or the associated xApp) may modify the E2 policy (e.g., an existing E2 policy) and / or the E2 control command (e.g., an existing E2 control command). In either case, the E2 node functions target of the derived E2 policy (e.g., newly generated E2 policy, modified E2 policy, etc.) and / or the derived E2 control command (e.g., newly generated E2 controlcommand, modified E2 control command, etc.) may include information of the candidate subarray patterns and / or the candidate PDSCH power offsets.

[0133] FIG. 11 illustrates a third example method 1100, according to one or more example embodiments. One or more operations in method 1100 may be implemented by a Near-RT RIC or an application (e.g., an xApp) associated therewith. For instance, one or more operations in method 1100 may (but not necessarily) be performed by the Near-RT RIC (or the associated xApp) that performs one or more operations in method 900 and / or method 1000. In this regard, one or more operations in method 1100 may be performed in any suitable sequential manner in relation to one or more operations in method 900 and / or method 1000 (e.g., operation Si l 10 may be performed subsequent to operation S920 in method 900, etc ).

[0134] Referring to FIG. 11 , at operation S 1110, the Near-RT RIC (or the associated xApp) may be configured to determine a type of a UE within or associated with a network cell (e.g., a network cell that is associated with the list of candidate sub-array patterns and / or PDSCH power offsets, a network cell optimized for spatial and power domains energy savings according to an optimal sub-array pattern and / or PDSCH power offset selected from the list of candidate sub-array patterns and / or PDSCH power offsets, etc.). For instance, the Near-RT RIC (or the associated xApp) may determine or identify whether the UE is a Rel-18 UE or a non-Rel-18 UE based on, for example, UE capability information received during the RRC setup or reconfiguration stage. Based on determining that the UE is a Rel-18 UE, method 1100 may proceed to operation SI 120. On the other hand, based on determining that the UE is non-Rel-18 UE, method 1100 may proceed to operation SI 130.

[0135] At operation S 1120, the Near-RT RIC (or the associated xApp) may be configured to perform a traffic steering operation to steer the UE towards the network cell. In this regard, thetraffic steering operation may include at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing (e.g., enabling, disabling, modifying, etc.) carrier aggregation (CA), managing (e.g., enabling, disabling, modifying, etc.) dual connectivity, or any other suitable mobility control operation.

[0136] At operation SI 130, the Near-RT RIC (or the associated xApp) may be configured to perform a traffic steering operation (or an access control operation) to steer the UE out of the network cell. In this regard, the traffic steering operation (or access control operation) may include at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, an Access Barring operation, or any other suitable radio access control operation.

[0137] FIG. 12 illustrates a fourth example method 1200, according to one or more example embodiments. One or more operations in method 1200 may be implemented by one or more apparatuses, devices, or network elements, such as one or more network nodes / E2 nodes (e.g., O-CU and 0-DU) described herein. For descriptive purposes, it may be assumed herein that one or more operations in method 1200 is implemented by a network node (e.g., an E2 node).

[0138] Referring to FIG. 12, at operation S1210, the network node (e.g., E2 node) may be configured to receive, from a Near-RT RIC, a list of candidate sub-array patterns and / or PDSCH power offsets. The network node (e.g., E2 node) may include at least one of: an O-CU or an O- DU. For instance, at this operation, the O-CU may receive the list of candidate sub-array patterns and / or PDSCH power offsets from the Near-RT RIC via the E2 interface. Additionally or alternatively, the O-DU may also receive the list of candidate sub-array patterns and / or PDSCH power offsets from the Near-RT RIC via the E2 interface, or from the O-CU via the Fl interface.

[0139] According to one or more example embodiments, at least one of an E2 control command or an E2 policy may be associated with the candidate sub-array patterns and / or thePDSCH power offsets. For instance, the network node (e.g., E2 node) may receive, from the Near- RT RIC, an E2 control command and / or an E2 policy that may include an E2 functions target that defines or is associated with the candidate sub-array patterns and / or the PDSCH power offsets.

[0140] Referring still to FIG. 12, at operation S 1220, the network node (e.g., E2 node) may be configured to configure a UE to perform a measurement according to the list of candidate subarray patterns and / or PDSCH power offsets. The measurement may include a CSI measurement.

[0141] Accordingly, at operation S1230, the network node (e.g., E2 node) may be configured to select, based on the measurement, a sub-array pattern and / or a PDSCH power offset for a transmission. For instance, at this operation, the network node (e.g., E2 node) may receive the measurement from the UE and select, based on the measurement and from among the list of candidate sub-array patterns and / or PDSCH power offset, the sub-array pattern and / or a PDSCH power offset for a DL transmission. As a non-limiting example, the O-DU may receive the measurement (e.g., CSI sub-reports, etc.) from the UE and select the sub-sub-array pattern and / or a PDSCH power offset for the DL transmission based thereon.

[0142] In view of the above, example embodiments provide methods and operations for effectively implementing the NES spatial and power domains optimization in an O-RAN-based network. Specifically, operations of FIG. 9 to FIG. 10 may be automatically triggered such that the Near-RT RIC may implement the NES spatial and power domains optimization by providing, to the E2 node(s), the information of candidate sub-array patterns and / or PDSCH power offsets (which may potentially improve the energy efficiency of the network). Further, operations of FIG. 11 may be automatically triggered such that the Near-RT RIC may appropriately steer the UEstowards and / or away from a network cell optimized for NES spatial and power domain adaptation, thereby further optimizing the energy efficiency of the network. In addition, operations of FIG. 12 may be automatically triggered such that the network node (e.g., E2 node) may receive the information of the candidate sub-array patterns and / or PDSCH power offsets from the Near-RT RIC and select an appropriate / optimal sub-array pattern and / or PDSCH power offset therefrom. It is contemplated that the methods and operations described above with reference to FIG. 9 to FIG. 12, as well as the technical advantages associated therewith, are merely examples, and the example embodiments may be applicable to any other suitable operations without departing from the scope of the present disclosure.Examples of Device

[0143] One or more components of the example embodiments (e.g., Non-RT RIC, Near- RT RIC, network nodes / E2 nodes such as O-CU and 0-DU, etc.), as well as the operations associated therewith, may include or be implemented in one or more devices or hardware components. For instance, one or more components / operations of the Near-RT RIC may include or be implemented in one or more devices like a server(s), and the like.

[0144] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with a Near-RT RIC may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0145] FIG. 13 illustrates an embodiment of a device 1300. As shown in FIG. 13, the device 1300 may include a processor 1310, a memory 1320, a storage component 1330, an input component 1340, an output component 1350, a communication interface 1360, and a bus 1370.

[0146] The processor 1310, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1310 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 1310 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0147] Memory 1320 includes a non-transitory computer readable medium. Memory 1320 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 1310. The memory 1320 comprises machine-readable instructions which are executable by the processor 1310. These machine-readable instructions when executed by the processor 1310 cause the processor 1310 to perform one or more method steps of an embodiment described above.

[0148] Storage component 1330 stores information and / or software related to the operation and use of the device 1300. For example, storage component 1330 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0149] Input component 1340 is configured to receive information, such as user input. For example, the input component 1340 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 1340 may include a sensor for sensing information (e g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0150] Output component 1350 is configured to provide output information from the device 1300. For example, the output component 1350 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0151] Communication interface 1360 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1360 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1300 and other devices. In other words, the standard of the communication interface 1360 is not limited.

[0152] The bus 1370 acts as an interconnect between the processor 1310, the memory 1320, the storage component 1330, the input component 1340, the output component 1350, and the communication interface 1360 of the device 1300. The bus 1370 may include a wired interconnection or a wireless interconnection.

[0153] The number and arrangement of components shown in FIG. 13 are provided as an example. In practice, device 1300 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 13. Additionally, or alternatively, a set of components (e.g., one or more components) of device 1300 may perform one or more functions described as being performed by another set of componentsof device 1300. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 1300 in communication with one another.Example Implementation Environment

[0154] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0155] FIG. 14 illustrates a block diagram of an example environment 1400 in which systems and / or method, described herein, may be implemented. The implementation environment 1400 includes a UE (User equipment) 1410, a service environment 1420, and a network 1430. The service environment 1420 includes one or more sub-environments 1421. To illustrate this, FIG. 14 shows, for convenience, examples of a 1st sub-environment 1421-1, a 2nd sub-environment 1421- 2, and an N-th sub-environment 1421-N (where N is any natural number).

[0156] The UE 1410 is connected to the network 1430, and the network 1430 is connected to the service environment 1420. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1410 and the service environment 1420 are connected via the network 1430.

[0157] The UE 1410 is a device that communicates with the service environment 1420. The UE 1410 receives information from the service environment 1420 and / or sends information to the service environment 1420. Also, the UE 1410 may generate and / or store information to be transmitted, as necessary. Also, the UE 1410 may store and / or process information that is received, as necessary.

[0158] The example FIG. 14 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,”“communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0159] For example, the UE 1410 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0160] The service environment 1420 is an environment that communicates with the UE 1410 to provide one or more services. The service environment 1420 receives information from the UE 1410 and / or sends information to the UE 1410. Also, the service environment 1420 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1420 may store and / or process information that is received, as necessary. For example, the service environment 1420 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0161] The example FIG. 14 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted.For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0162] The one or more services provided by the service environment 1420 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1410, a service that stores information from the UE 1410, or a service that performs processing based on information from the UE 1410 and returns the results of the processing.

[0163] In an embodiment, the Service Environments 1420 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0164] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodimentsimplemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0165] The service environment 1420 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1420 can be determined as appropriate. Additionally, if the service environment 1420 includes one or more sub-environments 1421, the placement of devices can be determined based on predetermined policies for each sub-environment 1421. For example, devices related to the first service may be placed in the 1st sub-environment 1421-1, and devices related to the second service may be placed in the 2nd sub-environment 1421-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1421-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1421-2. In this way, specific devices can be placed in specific sub-environments 1421. Conversely, each sub-environment 1421 can be specialized for a particular purpose.

[0166] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0167] The network 1430 is a network that exchanges information between the UE 1410 and the service environment 1420. The network 1430 includes one or more wired and / or wireless networks.

[0168] For example, the network 1430 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc ), a public land mobile network (PLMN), alocal area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0169] The network 1430 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1430 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1420 could be in the core network, in which case the network 1430 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0170] The number and arrangement of devices and networks shown in FIG. 14 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0171] As described above, example embodiments efficiently and effectively implement spatial and power domain optimizations for energy saving in an O-RAN-based network. Among others, example embodiments introduces new mechanisms and features (e.g., the end-to-end system architecture, the interoperations between the O-RAN components, the mechanisms for utilizing existing O-RAN interfaces, etc.) for leveraging 3GPP Rel-18 NES feature “spatial and power domain optimization” in the O-RAN architecture. As a non-limiting example, example embodiments specify and supplement several features, mechanisms, and use cases in at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN. WG3.TS.UCR), as detailed below.

[0172] To begin with, example embodiments of the present disclosure supplement the goal of example use cases in energy saving spatial and power domain optimization, as detailed in Table1 below,Table 1: Goal of the Example Use Cases

[0173] Further, example embodiments of the present disclosure also supplement an example use case for implementing energy saving spatial and power domain optimization, as detailed in Table 2 below. The call flow may be consistent with, for example, the call flow illustrated in FIG. 4 A and FIG. 4B.Table 2: Example Use Casesmechanisms and features associated with the control over E2 interface, as detailed in Table 3 below.Table 3: Control over E2

[0175] In addition, example embodiments of the present disclosure also supplement the functional requirements of the O-RAN components for implementation of the energy savingspatial and power domain adaptation use case, as detailed in detailed in Table 4 below.Table 4: Functional Requirements

[0176] In view of the above, example embodiments introduce specified and standardized approaches for implementing the NES spatial and power domain optimization or adaptation, as introduced in the 3GPP Rel-18, in the O-RAN architecture. Specifically, example embodiments clarify how specifically the components in the O-RAN architecture (e.g., Non-RT RIC, Near-RT RIC, E2 nodes, etc.) and the existing O-RAN interfaces (e.g., Al interface, E2 interface, 01 interface, Fl interface, etc.) can be utilized to implement the NES spatial and power domain optimization or adaptation in the O-RAN architecture. Accordingly, said NES feature may be implemented in the O-RAN-based networks in a clear and standardized manner to optimize the energy efficiency of the O-RAN-based networks.

[0177] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely examples of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0178] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed.Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0179] Some embodiments may relate to a device, a system, a method, and / or a computer- readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer- readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0180] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readablestorage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0181] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0182] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0183] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In thelater scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0184] These computer-readable 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 / acts specified in the flowchart and / or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0185] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchartand / or block diagram block or blocks.

[0186] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0187] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0188] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:\Item [1] : A Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC) configured to: obtain a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and provide, to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item [2]: The Near-RT RIC according to item [1], wherein the Near-RT RIC is configured to obtain the list by: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (0-RU) capability information.Item [3]: The Near-RT RIC according to one or more of items

[0001] -[2], wherein the Near-RT RIC is further configured to: obtain an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy.Item [4]: The Near-RT RIC according to one or more of items

[0001] -[2], wherein the Near-RT RIC is further configured to: send, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.Item [5]: The Near-RT RIC according to one or more of items

[0001] -[4], wherein the network node comprises an Open RAN (0-RAN) Central Unit (O-CU).Item [6]: The Near-RT RIC according to item [3], wherein further configured to: obtain, from the network node, a User Equipment (UE) context and an E2 measurementmetric; and determine a potential improvement to energy efficiency indicated in the Al policy.Item [7]: The Near-RT RIC according to item [6], wherein the Near-RT RIC is configured to obtain the E2 policy by: obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.Item [8]: The Near-RT RIC according to one or more of items [6]-[7], wherein the Near-RT RIC is configured to obtain the E2 policy by: generating a new E2 policy, wherein an E2 node functions target of the newly generated E2 policy comprises the candidate subarray patterns and the candidate PDSCH power offsets.Item [9] : The Near-RT RIC according to one or more of items [6]-[7], wherein the Near-RT RIC is configured to obtain the E2 policy by: modifying the E2 policy, wherein an E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0010] : The Near-RT RIC according to one or more of items [l]-[9], wherein the Near-RT RIC is further configured to: perform a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.Item

[0011] : The Near-RT RIC according to one or more of items [l]-

[0010] , wherein the Near-RT RIC is further configured to: perform a traffic steering operation to steer a user equipment (UE) out of a network cell, wherein the traffic steering operation comprises at least one of: performing a Radio Access Channel (RACH) backoff operation, performinga Radio Resource Control (RRC) Connection Reject operation, performing an RRC Connection Release operation, or performing an Access Barring operation.Item

[0012] : A method comprising: obtaining, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item

[0013] : The method according to item

[0012] , wherein the obtaining the list of candidate sub-array patterns and PDSCH power offsets comprises: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (O- RU) capability information.Item

[0014] : The method according to one or more of items

[0012] -

[0013] , further comprising: obtaining an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0015] : The method according to one or more of items

[0012] -

[0013] , further comprising: sending, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0016] : The method according to one or more of items

[0012] -

[0015] , wherein the network node comprises an Open RAN (O-RAN) Central Unit (O-CU).Item

[0017] : The method according to item

[0014] , further comprising: obtaining, from the network node, a UE context and an E2 measurement metric; and determining a potential improvement to energy efficiency indicated in the Al policy.Item

[0018] : The method according to item

[0017] , wherein the obtaining the E2 policy comprises: obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.Item

[0019] : The method according to item

[0017] , wherein the obtaining the E2 policy comprises: generating a new E2 policy, wherein an E2 node functions target of the newly generated E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0020] : The method according to item

[0017] , wherein the obtaining the E2 policy comprises: modifying the E2 policy, wherein an E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0021] : The method according to one or more of items

[0012] -

[0020] , further comprising: performing a traffic steering operation to steer a user equipment (UE) towards a network cell; wherein the traffic steering operation comprises at least one of: a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.Item

[0022] : The method according to one or more of items

[0012] -

[0021] , further comprising: performing a traffic steering operation to steer a user equipment (UE) out of a network cell, wherein the traffic steering operation comprises at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.Item

[0023] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a methodcomprising: obtaining, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item

[0024] : The non-transitory computer-readable recording medium according to item

[0023] , wherein the obtaining the list of candidate sub-array patterns and PDSCH power offsets comprises: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (O-RU) capability information.Item

[0025] : The non-transitory computer-readable recording medium according to one or more of items

[0023] -

[0024] , wherein the method further comprises: obtaining an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0026] : The non-transitory computer-readable recording medium according to one or more of items

[0023] -

[0024] , wherein the method further comprises: sending, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0027] : The non-transitory computer-readable recording medium according to one or more of items

[0023] -

[0026] , wherein the network node comprises an Open RAN (O- RAN) Central Unit (O-CU).Item

[0028] : The non-transitory computer-readable recording medium according to item

[0025] , wherein the obtaining the E2 policy comprises: obtaining, from the network node,a UE context and an E2 measurement metric; and determining a potential improvement to energy efficiency indicated in the Al policy.Item

[0029] : The non-transitory computer-readable recording medium according to item

[0028] , wherein the obtaining the E2 policy comprises: obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.Item

[0030] : The non-transitory computer-readable recording medium according to item

[0028] , wherein the obtaining the E2 policy comprises: generating a new E2 policy, wherein an E2 node functions target of the newly generated E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsetsItem

[0031] : The non-transitory computer-readable recording medium according to item

[0028] , wherein the obtaining the E2 policy comprises: modifying the E2 policy, wherein an E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0032] : The non-transitory computer-readable recording medium according to one or more of items

[0023] -

[0031] , wherein the method further comprises: performing a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.Item

[0033] : The non-transitory computer-readable recording medium according to one or more of items

[0023] -

[0032] , wherein the method further comprises: performing a traffic steering operation to steer a user equipment (UE) out of a network cell, wherein the trafficsteering operation comprises at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.Item

[0034] : A network node configured to: receive, from a Near-Real -Time (Near- RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate subarray patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configure a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.Item

[0035] : The network node 34 according to item

[0034] , wherein the network node is further configured to: select, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0036] : The network node according to one or more of items

[0034] -

[0035] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate subarray patterns and the PDSCH power offsets.Item

[0037] : The network node according to one or more of items

[0034] -

[0036] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0038] : The network node according to one or more of items

[0034] -

[0035] , wherein the network node is further configured to receive, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0039] : The network node according to one or more of items

[0034] -

[0038] , wherein the network node comprises an Open RAN (O-RAN) Central Unit (O-CU).Item

[0040] : The network node according to item

[0035] , wherein the network node comprises an O-RAN Distributed Unit (O-DU).Item

[0041] : A method comprising: receiving, by a network node and from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.Item

[0042] : The method according to item

[0041] , further comprising: selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0043] : The method according to one or more of items

[0041] -

[0042] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0044] : The method according to one or more of items

[0041] -

[0043] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0045] : The method according to one or more of items

[0041] -

[0042] , further comprising: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0046] : The method according to one or more of items

[0041] -

[0045] , wherein the network node comprise an Open RAN (O-RAN) Central Unit (O-CU).Item

[0047] : The method according to item

[0042] , wherein the network node comprise an Open RAN (O-RAN) Distributed Unit (O-DU).Item

[0048] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: receiving, from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical DownlinkShared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.Item

[0049] : The non-transitory computer-readable recording medium according to item

[0048] , wherein the method further comprises: selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0050] : The non-transitory computer-readable recording medium according to one or more of items

[0048] -

[0049] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0051] : The non-transitory computer-readable recording medium according to one or more of items

[0048] -

[0050] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0052] : The non-transitory computer-readable recording medium according to one or more of items

[0048] -

[0049] , wherein the method further comprises: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0053] : The non-transitory computer-readable recording medium according to one or more of items

[0048] -

[0050] , wherein the apparatus comprises an Open RAN (0-RAN) Central Unit (O-CU).Item

[0054] : The non-transitory computer-readable recording medium according to item

[0049] , wherein the apparatus comprises an Open RAN (0-RAN) Distributed Unit (O-DU).Item

[0055] : A Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC) configured to: derive a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and provide, to an E2 node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item

[0056] : The Near-RT RIC according to item

[0055] , wherein the Near-RT RIC is further configured to: obtain the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic data collection, a UE traffic data prediction, a radio propagation channel condition data prediction, a radio propagation channel condition data collection, a location data collection, a location data prediction, or an Open RAN Radio Unit (O-RU) capability information collection.Item

[0057] : The Near-RT RIC according to one or more of items

[0055] -

[0056] , wherein the Near-RT RIC is further configured to: obtain at least one of: an E2 policy or an E2 control command associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy sent by a Non-Real-Time (Non-RT) RIC.Item

[0058] : The Near-RT RIC according to one or more of items

[0055] -

[0057] , wherein the Near-RT RIC is further configured to: send, to the E2 node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0059] : The Near-RT RIC according to one or more of items

[0055] -

[0058] , wherein the E2 node comprises at least one of: an Open RAN (O-RAN) Central Unit (O-CU) or anO-RAN Distributed Unit (O-DU).Item

[0060] : The Near-RT RIC according to item

[0057] , wherein the Near-RT RIC is further configured to: obtain, from the E2 node, a UE context, a series of E2 measurement metrics, and a series of E2 Key Performance Indicators (KPIs); and determine a potential improvement to energy efficiency defined in the Al policy.Item

[0061] : The Near-RT RIC according to item

[0060] , wherein the Near-RT RIC is further configured to: derive at least one of: the E2 policy or the E2 control command based on the UE context, the series of E2 measurement metrics, the series of E2 KPIs, and the Al policy, if the potential improvement is determined.Item

[0062] : The Near-RT RIC according to one or more of items

[0060] -

[0061] , wherein the Near-RT RIC is further configured to: generate at least one of: a new the E2 policy or a new E2 control command, wherein an E2 node functions target of the at least one of the newly generated E2 policy or the newly generated E2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0063] : The Near-RT RIC according to one or more of items

[0060] -

[0061] , wherein the Near-RT RIC is further configured to: modify at least one of the E2 policy or the E2 control command, wherein an E2 node functions target of the at least one of the modified E2 policy or the modified E2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0064] : The Near-RT RIC according to one or more of items

[0060] -

[0063] , wherein the Near-RT RIC is further configured to: perform a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handoverrestriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.Item

[0065] : The Near-RT RIC according to one or more of items

[0060] -

[0063] , wherein the Near-RT RIC is further configured to: perform an access control operation to steer a user equipment (UE) out of a network cell, wherein the access control operation comprises at least one of: performing a Radio Access Channel (RACH) backoff operation, performing a Radio Resource Control (RRC) Connection Reject operation, performing an RRC Connection Release operation, or performing an Access Barring operation.Item

[0066] : A method comprising: deriving, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to an E2 node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item

[0067] : The method according to item

[0066] , further comprising: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic data collection, a UE traffic data prediction, a radio propagation channel condition data prediction, a radio propagation channel condition data collection, a location data prediction, a location data prediction, or Open RAN Radio Unit (O-RU) capability information.Item

[0068] : The method according to one or more of items

[0066] -

[0067] , further comprising: obtaining at least one of: an E2 policy or an E2 control command associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy sent by a Non-Real-Time (Non-RT) RIC.Item

[0069] : The method according to one or more of items

[0066] -

[0068] , further comprising: sending, to the E2 node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0070] : The method according to one or more of items

[0066] -

[0069] , wherein the E2 node comprises at least one of: an Open RAN (O-RAN) Central Unit (O-CU) or an O-RAN Distributed Unit (0-DU).Item

[0071] : The method according to item

[0068] , further comprising: obtaining, from the E2 node, a UE context, a series of E2 measurement metrics, and a series of E2 Key Performance Indicators (KPIs); and determining a potential improvement to energy efficiency defined in the Al policy.Item

[0072] : The method according to item

[0071] , further comprising: deriving at least one of: the E2 policy or the E2 control command based on the UE context, the series of E2 measurement metrics, the series of E2 KPIs, and the Al policy, if the potential improvement is determined.Item

[0073] : The method according to one or more of items

[0071] -

[0072] , further comprising: generating at least one of: a new E2 policy or a new E2 control command, wherein an E2 node functions target of the at least one of the newly generated E2 policy or the newly generated E2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0074] : The method according to one or more of items

[0071] -

[0072] , further comprising: modifying at least one of the E2 policy or the E2 control command, wherein an E2 node functions target of the at least one for the modified E2 policy or the modifiedE2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0075] : The method according to one or more of items

[0066] -

[0074] , further comprising: performing a traffic steering operation to steer a user equipment (UE) towards a network cell; wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.Item

[0076] : The method according to one or more of items

[0066] -

[0074] , further comprising: performing an access control operation to steer a user equipment (UE) out of a network cell, wherein the access control operation comprises at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.Item

[0077] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: deriving, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to an E2 node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.Item

[0078] : The non-transitory computer-readable recording medium according to item

[0077] , wherein the method further comprises: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic data collection, a UE traffic data prediction, a radio propagation channel condition dataprediction, a radio propagation channel data collection, a location data collection, a location data prediction, or Open RAN Radio Unit (O-RU) capability information.Item

[0079] : The non-transitory computer-readable recording medium according to one or more of items

[0077] -

[0078] , wherein the method further comprises: obtaining at least one of: an E2 policy or an E2 control command associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy sent by a Non-Real-Time (Non-RT) RIC.Item

[0080] : The non-transitory computer-readable recording medium according to one or more of items

[0077] -

[0079] , wherein the method further comprises: sending, to the E2 node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsetsItem

[0081] : The non-transitory computer-readable recording medium according to one or more of items

[0077] -

[0080] , wherein the E2 node comprises at least one of: an Open RAN (0-RAN) Central Unit (O-CU) or an O-RAN Distributed Unit (O-DU).Item

[0082] : The non-transitory computer-readable recording medium according to item

[0079] , wherein the method further comprises: obtaining, from the E2 node, a UE context, a series of E2 measurement metrics, and a series of E2 Key Performance Indicators (KPIs); and determining a potential improvement to energy efficiency defined in the Al policy.Item

[0083] : The non-transitory computer-readable recording medium according to item

[0082] , wherein the method further comprises: deriving at least one of: the E2 policy and the E2 control command based on the UE context, the series of E2 measurementmetrics, the series of E2 KPIs, and the Al policy, if the potential improvement is determined.Item

[0084] : The non-transitory computer-readable recording medium according to one or more of items

[0082] -

[0083] , wherein the method further comprises: generating at least one of: a new E2 policy or a new E2 control command, wherein an E2 node functions target of the at least one of the newly generated E2 policy or the newly generated E2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0085] : The non-transitory computer-readable recording medium according to one or more of items

[0082] -

[0083] , wherein the method further comprises: modifying at least one of: the E2 policy or the E2 control command, wherein an E2 node functions target of the at least one of the modified E2 policy or the modified E2 control command comprises the candidate sub-array patterns and the candidate PDSCH power offsets.Item

[0086] : The non-transitory computer-readable recording medium according to one or more of items

[0077] -

[0085] , wherein the method further comprises: performing a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA),or managing dual connectivity.Item

[0087] : The non-transitory computer-readable recording medium according to one or more of items

[0077] -

[0085] , wherein the method further comprises: performing an access control operation to steer a user equipment (UE) out of a network cell, wherein the access control operation comprises at least one of: a Radio Access Channel (RACH)backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.Item

[0088] : An E2 node configured to: receive, from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configure a User Equipment (UE) to perform a measurement according to the list of candidate subarray patterns and PDSCH power offsets.Item

[0089] : The E2 node according to item

[0088] , wherein the E2 node is further configured to: select, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0090] : The E2 node according to one or more of items

[0088] -

[0089] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0091] : The E2 node according to one or more of items

[0088] -

[0090] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0092] : The E2 node according to one or more of items

[0088] -

[0089] , wherein the E2 node is further configured to receive, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0093] : The E2 node according to one or more of items

[0088] -

[0092] , wherein the E2 node comprises an Open RAN (0-RAN) Central Unit (O-CU).Item

[0094] : The E2 node according to item

[0089] , wherein the E2 node comprises anO-RAN Distributed Unit (O-DU).Item

[0095] : A method comprising: receiving, by an E2 node and from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.Item

[0096] : The method according to item

[0095] , further comprising: selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0097] : The method according to one or more of items

[0095] -

[0096] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0098] : The method according to one or more of items

[0095] -

[0097] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0099] : The method according to one or more of items

[0095] -

[0096] , further comprising: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0100] : The method according to one or more of items

[0095] -

[0099] , wherein the E2 node comprise an Open RAN (O-RAN) Central Unit (O-CU).Item

[0101] : The method according to item

[0096] , wherein the E2 node comprise an Open RAN (O-RAN) Distributed Unit (O-DU).Item

[0102] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: receiving, from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical DownlinkShared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.Item

[0103] : The non -transitory computer-readable recording medium according to item

[0102] , wherein the method further comprises: selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.Item

[0104] : The non-transitory computer-readable recording medium according to one or more of items

[0102] -

[0103] , wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.Item

[0105] : The non-transitory computer-readable recording medium according to one or more of items

[0102] -

[0050] , wherein the measurement comprises a Channel State Information (CSI) measurement.Item

[0106] : The non-transitory computer-readable recording medium according to one or more of items

[0102] -

[0103] , wherein the method further comprises: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.Item

[0107] : The non-transitory computer-readable recording medium according to one or more of items

[0102] -

[0106] , wherein the apparatus comprises an Open RAN (0-RAN) Central Unit (O-CU).Item

[0108] : The non-transitory computer-readable recording medium according to item

[0103] , wherein the apparatus comprises an Open RAN (O-RAN) Distributed Unit (O-DU).

[0189] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC) configured to: obtain a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and provide, to a network node, the list of candidate sub-array patterns and PDSCH power offsets as potential choices for a transmission.

2. The Near-RT RIC according to claim 1, wherein the Near-RT RIC is configured to obtain the list by: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (O-RU) capability information.

3. The Near-RT RIC according to claim 1 , wherein the Near-RT RIC is further configured to: obtain an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy.

4. The Near-RT RIC according to claim 1, wherein the Near-RT RIC is further configured to: send, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.

5. The Near-RT RIC according to claim 1, wherein the network node comprises an Open RAN (O-RAN) Central Unit (O-CU).

6. The Near-RT RIC according to claim 3, wherein the Near-RT RIC is further configured to: obtain, from the network node, a UE context and an E2 measurement metric; and determine a potential improvement to energy efficiency indicated in the Al policy.

7. The Near-RT RIC according to claim 6, wherein the Near-RT RIC is configured to obtain the E2 policy by: obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.

8. The Near-RT RIC according to claim 6, wherein the Near-RT RIC is configured to obtain the E2 policy by: generating a new E2 policy, wherein an E2 node functions target of the newly generated E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

9. The Near-RT RIC according to claim 6, wherein the Near-RT RIC is configured to obtain the E2 policy by: modifying the E2 policy, wherein an E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

10. The Near-RT RIC according to claim 1, wherein the Near-RT RIC is further configured to: perform a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.

11. The Near-RT RIC according to claim 1, wherein the Near-RT RIC is further configured to: perform a traffic steering operation to steer a user equipment (UE) out of a network cell , wherein the traffic steering operation comprises at least one of: performing a Radio Access Channel (RACH) backoff operation, performing a Radio Resource Control (RRC) Connection Reject operation, performing an RRC Connection Release operation, or performing an Access Barring operation.

12. A method comprising: obtaining, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to a network node, the list of candidate subarray patterns and PDSCH power offsets as potential choices for a transmission.

13. The method according to claim 12, wherein the obtaining the list of candidate sub-array patterns and PDSCH power offsets comprises: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (O-RU) capability information.

14. The method according to claim 12, further comprising: obtaining an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets based on an Al policy.

15. The method according to claim 12, further comprising: sending, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.

16. The method according to claim 12, wherein the network node comprises an Open RAN (O- RAN) Central Unit (O-CU).

17. The method according to claim 14, further comprising: obtaining, from the network node, a UE context and an E2 measurement metric; and determining a potential improvement to energy efficiency indicated in the Al policy.

18. The method according to claim 17, wherein the obtaining the E2 policy comprises:obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.

19. The method according to claim 17, wherein the obtaining the E2 policy comprises: generating a new E2 policy, wherein E2 node functions target of the newly generated E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

20. The method according to claim 17, wherein the obtaining the E2 policy comprises: modifying the E2 policy, wherein E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

21. The method according to claim 12, further comprising: performing a traffic steering operation to steer a user equipment (UE) towards a network cell; wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA), or managing dual connectivity.

22. The method according to claim 12, further comprising: performing a traffic steering operation to steer a user equipment (UE) out of a network cell,wherein the traffic steering operation comprises at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.

23. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: obtaining, by a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and providing, by the Near-RT RIC and to a network node, the list of candidate subarray patterns and PDSCH power offsets as potential choices for a transmission.

24. The non-transitory computer-readable recording medium according to claim 23, wherein the obtaining the list of candidate sub-array patterns and PDSCH power offsets comprises: obtaining the list of candidate sub-array patterns and PDSCH power offsets based on at least one of: a User Equipment (UE) traffic, a channel and location prediction, or Open RAN Radio Unit (O-RU) capability information.

25. The non-transitory computer-readable recording medium according to claim 23, wherein the method further comprises: obtaining an E2 policy associated with the candidate sub-array patterns and thePDSCH power offsets based on an Al policy.

26. The non-transitory computer-readable recording medium according to claim 23, wherein the method further comprises: sending, to the network node, at least one of: an E2 control command or an E2 policy associated with the candidate sub-array patterns and the PDSCH power offsets.

27. The non-transitory computer-readable recording medium according to claim 23, wherein the network node comprises an Open RAN (O-RAN) Central Unit (O-CU).

28. The non-transitory computer-readable recording medium according to claim 25, wherein the obtaining the E2 policy comprises: obtaining, from the network node, a UE context and an E2 measurement metric; and determining a potential improvement to energy efficiency indicated in the Al policy.

29. The non-transitory computer-readable recording medium according to claim 28, wherein the obtaining the E2 policy comprises: obtaining the E2 policy based on the UE context, the E2 measurement metric, and the Al policy, if the potential improvement is determined.

30. The non-transitory computer-readable recording medium according to claim 28, wherein the obtaining the E2 policy comprises: generating a new E2 policy,wherein E2 node functions target of the newly generated E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

31. The non-transitory computer-readable recording medium according to claim 28, wherein the obtaining the E2 policy comprises: modifying the E2 policy, wherein E2 node functions target of the modified E2 policy comprises the candidate sub-array patterns and the candidate PDSCH power offsets.

32. The non-transitory computer-readable recording medium according to claim 23, wherein the method further comprises: performing a traffic steering operation to steer a user equipment (UE) towards a network cell, wherein the traffic steering operation comprises at least one of: performing a handover operation, configuring a handover restriction list, configuring an idle mode mobility parameter, managing carrier aggregation (CA),or managing dual connectivity.

33. The non-transitory computer-readable recording medium according to claim 23, wherein the method further comprises: performing a traffic steering operation to steer a user equipment (UE) out of a network cell,wherein the traffic steering operation comprises at least one of: a Radio Access Channel (RACH) backoff operation, a Radio Resource Control (RRC) Connection Reject operation, an RRC Connection Release operation, or an Access Barring operation.

34. A network node configured to: receive, from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configure a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

35. The network node according to claim 34, wherein the network node is further configured to: select, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.

36. The network node according to claim 34, wherein at least one of an E2 control command or an E2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.

37. The network node according to claim 34, wherein the measurement comprises a ChannelState Information (CSI) measurement.

38. The network node according to claim 34, wherein the network node is further configured to receive, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.

39. The network node according to claim 34, wherein the network node comprises an Open RAN (0-RAN) Central Unit (O-CU).

40. The network node according to claim 35, wherein the network node comprises an 0-RAN Distributed Unit (0-DU).

41. A method comprising: receiving, by a network node and from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

42. The method according to claim 41, further comprising: selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.

43. The method according to claim 41, wherein at least one of an E2 control command or anE2 policy is associated with the candidate sub-array patterns and the PDSCH power offsets.

44. The method according to claim 41, wherein the measurement comprises a Channel State Information (CSI) measurement.

45. The method according to claim 41, further comprising: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.

46. The method according to claim 41, wherein the network node comprise an Open RAN (O- RAN) Central Unit (O-CU).

47. The method according to claim 42, wherein the network node comprise an Open RAN (O- RAN) Distributed Unit (0-DU).

48. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: receiving, from a Near-Real-Time (Near-RT) Radio Access Network (RAN) Intelligent Controller (RIC), a list of candidate sub-array patterns and Physical Downlink Shared Channel (PDSCH) power offsets; and configuring a User Equipment (UE) to perform a measurement according to the list of candidate sub-array patterns and PDSCH power offsets.

49. The non-transitory computer-readable recording medium according to claim 48, wherein the method further comprises:selecting, based on the measurement, a sub-array pattern and a PDSCH power offset for a transmission.

50. The non-transitory computer-readable recording medium according to claim 48, wherein at least one of an E2 control command or an E2 policy is associated with the candidate subarray patterns and the PDSCH power offsets.

51. The non-transitory computer-readable recording medium according to claim 48, wherein the measurement comprises a Channel State Information (CSI) measurement.

52. The non-transitory computer-readable recording medium according to claim 48, wherein the method further comprises: receiving, from the Near-RT RIC, an E2 policy associated with the sub-array patterns and the PDSCH power offsets based on an Al policy.

53. The non-transitory computer-readable recording medium according to claim 48, wherein the apparatus comprises an Open RAN (O-RAN) Central Unit (O-CU).

54. The non-transitory computer-readable recording medium according to claim 49, wherein the apparatus comprises an Open RAN (O-RAN) Distributed Unit (0-DU).

Images