SYSTEM AND METHOD FOR CARRIER AND / OR CELL SWITCH OFF / ON OPTIMIZATION BASED ON A1 POLICY IN TELECOMMUNICATION NETWORKS - Patent application

Abstract

A method for implementing carrier and / or cell switch off / on optimization in an O-RAN based on an A1 policy, the method including: deploying, by an NRT-RIC framework, an AI / ML model to the nRT-RIC; providing, by an rApp, an A1 policy for preparing and performing cell and / or carrier switch off / on optimization to the nRT-RIC through the NRT-RIC framework; collecting, by the nRT-RIC, data for performing cell and / or carrier switch off / on from an O-RU via an E2 node through an E2 interface; evaluating, by the nRT-RIC, the collected data; generating, by the nRT-RIC, an E2 message; transmitting, by the nRT-RIC, the E2 message to the O-RU via the E2 node; performing cell and / or carrier switch off / on optimization in the O-RAN by the E2 node and the O-RU; and receiving, by the rApp, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through the NRT-RIC framework.

Description

[Technical Field]

[0001] Systems and methods consistent with example embodiments of the present disclosure relate to implementing carrier and / or cell switch off / on optimization based on A1 policies in telecommunications networks. [Background technology]

[0002] The Radio Access Network (RAN) is a critical component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various Network Elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0003] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software for telecommunication systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU is a logical node for hosting the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU is a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul (FH). These entities have open protocols and interfaces between them, so they can be developed by different vendors.

[0004] Figure 1 shows the O-RAN architecture of related technology. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by RICs. RICs are software-defined components that implement modular applications to facilitate the multi-vendor operability required in O-RAN systems. RICs also automate and optimize RAN operations. RICs are divided into two types: non-real-time RICs (NRT-RIC) and near-real-time RICs (nRT-RIC).

[0005] The NRT-RIC is the control point for non-real-time control loops and operates on sub-second timescales within a Service Management and Orchestration (SMO) framework. Its functionality is implemented through modular applications called rApps (rApp1, ..., rAppN) and includes providing policy-based guidance and enrichment over the A1 interface, which is an interface enabling communication between the NRT-RIC and the nRT RIC; performing data analytics, artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions via the O1 interface, which is an interface connecting the SMO to RAN management elements (e.g., nRT-RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0006] The nRT-RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (split into the O-CU Control Plane (O-CU-CP) and O-CU User Plane (O-CU-UP)), and Open evolved NodeB (O-eNB) via the E2 interface. The nRT-RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / Network Functions (NFs)) via near-real-time control loops. The nRT-RIC monitors, suspends / stops, overrides, and controls the E2 node(s) (O-CU, O-DU, O-eNB) via policies. For example, the nRT-RIC sets policy parameters for activated functions of the E2 nodes. Additionally, the nRT-RIC hosts xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, the NRT-RIC provides policies, data, and artificial intelligence / machine learning (AI / ML) models implemented and used by the nRT-RIC for RAN optimization via the A1 interface, and the nRT-RIC returns policy feedback (i.e., how the policies set by the NRT-RIC are working).

[0007] The SMO framework, in which the NRT-RIC is located, manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates what is called the O-Ran Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS).

[0008] On the other hand, the O-Cloud is a cloud computing platform that includes a collection of physical infrastructure nodes that meet the O-RAN requirements for hosting relevant O-RAN functions (e.g., nRT-RIC, O-CU-CP, O-CU-UP, O-DU, etc.), supporting software components (operating systems, virtual machine monitors, container runtimes, etc.), and appropriate management and orchestration functions.

[0009] The SMO framework in which the NRT-RIC is located manages and orchestrates RAN elements through four main interfaces: the A1 interface between the NRT-RIC and nRT-RIC within the SMO for RAN optimization, the O1 interface between the SMO and O-RAN network functions for FCAPS support, the open fronthaul M-plane interface between the SMO and O-RU for FCAPS support in the hybrid model, and the O2 interface between the SMO and O-Cloud for platform resource and workload management.

[0010] In related technology, O-RAN utilizes multiple frequency layers (carriers) to cover the same service area. Under low network traffic loads (e.g., when the predicted traffic volume is lower than a fixed threshold), energy saving (i.e., high energy efficiency and / or low energy consumption) can be achieved by shutting down (i.e., switching off) one or more carriers or entire cells without impairing the O-RAN user experience. In the case of shutting down (i.e., switching off) one or more carriers or entire cells, O-RAN users (i.e., user equipment (UE) connected to the O-RAN) previously served by one or more carriers or cells are offloaded to one or more new target carriers or cells by an E2 node before shutting down (i.e., switching off).

[0011] Furthermore, considering the local or network-wide impact of a shutdown in O-RAN, there is a trade-off between system performance and energy conservation. This trade-off drives decisions regarding switching off or on non-trivial (critical) tasks. For example, other carriers and / or cells may have to cover (i.e., take over or service) additional network traffic, and network traffic changes over time. Furthermore, E2 node(s) may have to support several technologies that affect energy consumption, which may also depend on the load (e.g., network traffic or number of users).

[0012] As a result, it may even be possible that the energy consumption of the entire network of the O-RAN increases while the energy savings of the switched-off carrier(s) and / or cell(s) are maximized on a local basis. In this case, the local deployment of energy saving optimization measures based on switching off / on of carriers and / or cells leads to a degradation of the energy efficiency of the entire network and / or the energy consumption of the O-RAN. Summary of the Invention [Means for solving the problem]

[0013] According to embodiments, systems and methods are provided that enable an O-RAN operator to flexibly configure carrier and cell switch-off / on parameters (e.g., data required to perform cell and / or carrier switch-off / on) of a cell or cluster of cells based on an A1 policy formulated by an rApp. In particular, the systems and methods enable evaluation of data required to perform cell and / or carrier switch-off / on (i.e., using AI / ML model inference) in the nRT-RIC while AI / ML model training is hosted in the SMO (e.g., the nRT-RIC or an rApp).

[0014] For example, the system and method enable network operators to flexibly configure carrier and / or cell switch off / on parameters within a cell or cluster of cells to optimize energy efficiency management in O-RAN based on A1 policies formulated by rApp.

[0015] According to an embodiment, there is provided a system for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, the system comprising: a memory that stores instructions; and at least one processor configured to implement a service management and orchestration (SMO) framework, a near real-time radio intelligent controller (nRT-RIC), a non-real-time radio intelligent controller (NRT-RIC), the NRT-RIC framework, and an rApp, wherein the at least one processor executes the instructions to collect, via the rApp, data required to perform cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via the nRT-RIC through the NRT-RIC framework and / or the SMO framework; retrain, via the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; and, among the at least one retrained AI / ML, one processor configured to execute the instructions to collect, via the rApp, data required to perform cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via the nRT-RIC through the NRT-RIC framework and / or the SMO framework; Deploying the retrained AI / ML model to the nRT-RIC; providing, by the rApp, an A1 policy to the nRT-RIC through the NRT-RIC framework for preparing and executing cell and / or carrier switch off / on optimization; collecting, by the nRT-RIC, data necessary to execute cell and / or carrier switch off / on from the O-RU via the E2 interface based on the provided A1 policy; evaluating, by the nRT-RIC, the collected data necessary to execute cell and / or carrier switch off / on based on the deployed AI / ML model and the provided A1 policy; generating, by the nRT-RIC, at least one E2 message for preparing and executing cell and / or carrier switch off / on optimization based on the evaluation; transmitting, by the nRT-RIC, at least one E2 message via the E2 node to the O-RU; implementing, by the E2 node and the OR, the cell and / or carrier switch off / on optimization within the O-RAN based on the implementation;The rApp is configured to receive A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through the NRT-RIC framework.

[0016] According to an embodiment, there is provided a method for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, the method comprising: collecting, by an rApp, data required to perform cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via an E2 node through an nRT-RIC framework and / or an SMO framework; retraining at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; deploying, by the NRT-RIC framework, one retrained AI / ML model to the nRT-RIC among the at least one retrained AI / ML; providing, by the rApp, an A1 policy to the nRT-RIC through the NRT-RIC framework for preparing and performing cell and / or carrier switch off / on optimization; and, based on the provided A1 policy, deploying, by the nRT-RIC framework, an A1 policy to the nRT-RIC. and (c) collecting, by the nRT-RIC via the E2 node, data necessary to perform cell and / or carrier switch off / on from the O-RU via the E2 interface; evaluating, by the nRT-RIC based on the deployed AI / ML model and the provided A1 policy, the collected data necessary to perform cell and / or carrier switch off / on; generating, by the nRT-RIC based on the evaluation, at least one E2 message for preparing and performing cell and / or carrier switch off / on optimization; transmitting, by the nRT-RIC, the at least one E2 message to the O-RU via the E2 node; implementing, by the E2 node and the O-RU based on the at least one E2 message, the cell and / or carrier switch off / on optimization within the O-RAN; and receiving, by the rApp based on the implementation, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through the NRT-RIC framework.

[0017] According to an embodiment, a non-transitory computer-readable storage medium storing instructions executable by at least one processor, wherein the at least one processor is further configured to execute a method for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, the method including: collecting, by an rApp, data required to perform cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via an E2 node through an nRT-RIC framework and / or an SMO framework; retraining, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; deploying, by the NRT-RIC framework, one retrained AI / ML model to the nRT-RIC among the at least one retrained AI / ML; and implementing, by the rApp, the A1 policy for preparing and performing cell and / or carrier switch off / on optimization through the NRT-RIC framework. and receiving, by the rApp through the NRT-RIC framework, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC based on the implementation.

[0018] 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 learned by practice of the presented embodiments of the present disclosure.

[0019] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0020] [Figure 1] Figure 1 shows the O-RAN architecture in the related art.

[0021] [Figure 2] FIG. 2 shows a diagram of an exemplary environment in which the systems and / or methods disclosed herein may be implemented.

[0022] [Figure 3] FIG. 3 shows a diagram of exemplary components of a device, according to one embodiment.

[0023] [Figure 4] FIG. 4 illustrates an SMO / NRT-RIC framework system architecture configured to implement carrier and / or cell switch off / on optimization based on A1 policy, according to one embodiment.

[0024] [Figure 5] FIG. 5 illustrates a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to one embodiment.

[0025] [Figure 6] FIG. 6 shows a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0026] [Figure 7] FIG. 7 shows a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0027] [Figure 8] FIG. 8 shows a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0028] [Figure 9] FIG. 9 shows a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0029] [Figure 10] FIG. 10 shows a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0030] [Figure 11] FIG. 11 illustrates a data collection flow according to one embodiment.

[0031] [Figure 12] FIG. 12 illustrates an AI / ML model training flow in the NRT-RIC according to one embodiment.

[0032] [Figure 13] FIG. 13 illustrates an AI / ML model training flow in rApp, according to one embodiment.

[0033] [Figure 14] FIG. 14 illustrates a method for generating and implementing E2 message(s) for preparing and performing cell and / or carrier switch off / on based on A1 policy, according to one embodiment.

[0034] [Figure 15] FIG. 15 illustrates a method for modification of A1 policy based on A1 policy feedback via an E2 interface, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0035] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Moreover, one or more features or components of one embodiment may be combined with or incorporated into another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be permuted.

[0036] It will be apparent that the 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 limiting of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0037] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, 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 depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0038] No element, act, or instruction used herein should be construed as critical or required unless expressly stated 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." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0039] 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. As shown in FIG. 2, environment 200 may include a user device 210, a platform 220, and a network 230. The devices in environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described with reference to FIG. 1 above may be performed by any combination of elements shown in FIG. 2.

[0040] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 220. For example, user device 210 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 smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or similar device. In some implementations, user device 210 may send and receive information to and from platform 220.

[0041] Platform 220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 220 may include a cloud server or a group of cloud servers. In some implementations, platform 220 may be designed to be modular, such that particular software components can be swapped in or out depending on particular needs. Thus, platform 220 may be easily and / or quickly reconfigured for different uses.

[0042] In some implementations, as shown, platform 220 may be hosted in a cloud computing environment 222. In particular, although the implementations described herein describe platform 220 as being hosted within cloud computing environment 222, in some implementations platform 220 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0043] Cloud computing environment 222 includes an environment that hosts platform 220. Cloud computing environment 222 may provide services such as computing, software, data access, storage, etc. that do not require end-user (e.g., user device 210) knowledge of the physical location and configuration of the system(s) and / or device(s) that host platform 220. As shown, cloud computing environment 222 may include a group of computing resources 224 (collectively referred to as “computing resources 224” and individually as “computing resource 224”).

[0044] Computing resource(s) 224 may include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resource(s) 224 may host platform 220. Cloud resources may include compute instances running on computing resource(s) 224, storage devices provided on computing resource(s) 224, data transfer devices provided by computing resource(s) 224, etc. In some implementations, computing resource(s) 224 may communicate with other computing resources 224 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0045] As further shown in FIG. 2, the computing resource(s) 224 include a group of cloud resources, such as one or more applications ("APP") 224-1, one or more virtual machines ("VM") 224-2, virtualized storage ("VS") 224-3, and one or more hypervisors ("HYP") 224-4.

[0046] Application 224-1 includes one or more software applications that may be provided to or accessed by user device 210. Application 224-1 may eliminate the need for a software application to be installed and run on user device 210. For example, application 224-1 may include software associated with platform 220 and / or any other software that may be provided via cloud computing environment 222. In some implementations, one application 224-1 may send information to or receive information from one or more other applications 224-1 via virtual machine 224-2.

[0047] Virtual machine 224-2 includes a software-implemented machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 224-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 224-2 matches an actual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may execute a single program and support a single process. In some implementations, virtual machine 224-2 may run on behalf of a user (e.g., user device 210) and manage the infrastructure of cloud computing environment 222, such as data management, synchronization, or long-term data transfer.

[0048] Virtualized storage 224-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of computing resource(s) 224. In some implementations, in the context of storage systems, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed regardless of the physical storage or heterogeneous structure. The separation may allow storage system administrators to gain flexibility in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable performance optimization of storage usage, server consolidation, and / or non-disruptive file migration.

[0049] Hypervisor 224-4 may provide hardware virtualization techniques that allow multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as computing resource 224. Hypervisor 224-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of different operating systems may share virtualized hardware resources.

[0050] Network 230 may include one or more wired and / or wireless networks. For example, network 230 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), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., a Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical-based fiber network, etc., and / or a combination of these or other types of networks.

[0051] The number and arrangement of devices and networks shown in Figure 2 are provided as an example. In practice, there may be more, fewer, different, or differently arranged devices and / or networks than those shown in Figure 2. Furthermore, two or more devices shown in Figure 2 may be implemented within a single device, or a single device shown in Figure 2 may be implemented as multiple distributed devices. Additionally, or instead, a set of devices in environment 200 (e.g., one or more devices) may perform one or more functions that are described as being performed by another set of devices in environment 200.

[0052] 3 shows a diagram of example components of device 300. Device 300 may correspond to user device 210 and / or platform 220. As shown in FIG. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and a communication interface 370.

[0053] Bus 310 includes components that enable communication between components of device 300. Processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 320 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 320 includes one or more processors that can be programmed to perform functions. Memory 330 may include random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 320.

[0054] Storage component 340 stores information and / or software related to the operation and use of device 300. For example, storage component 340 may include a hard disk (e.g., a magnetic disk, optical disk, optical-magnetic disk, and / or solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. Input component 350 includes components that enable device 300 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input component 350 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output components 360 include components that provide output information from device 300 (eg, a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0055] Communications interface 370 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 370 may enable device 300 to receive information from and / or provide information to another device. For example, communications interface 370 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0056] Device 300 may perform one or more processes described herein. Device 300 may perform these processes in response to processor 320 executing software instructions stored by a non-transitory computer-readable medium, such as memory 330 and / or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0057] Software instructions may be loaded into memory 330 and / or storage component 340 from another computer-readable medium or from another device via communication interface 370. The software instructions stored in memory 330 and / or storage component 340, when executed, may cause processor 320 to perform one or more processes described herein.

[0058] Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. The number and arrangement of components shown in Figure 3 are provided as an example. In practice, device 300 may include additional, fewer, different, or differently arranged components than those shown in Figure 3. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions that are described as being performed by another set of components of device 300.

[0059] In embodiments, any one of the actions or processes of Figures 4, 5, 6, 7, and 8 may be implemented by or using any one of the elements shown in Figures 1, 2, and 3. It is understood that other embodiments may be implemented in a variety of different architectures (e.g., without limitation, a bare metal architecture, any cloud-based or deployment architecture such as Kubernetes, Docker, OpenStack, etc.).

[0060] FIG. 4 illustrates an SMO / NRT-RIC framework system architecture configured to perform carrier and / or cell switch off / on optimization based on A1 policies, according to one embodiment.

[0061] 4, the NRT-RIC represents a subset of the functionality of the SMO framework. The NRT-RIC can access other SMO framework functions, thereby affecting (i.e., controlling and / or executing) what is conveyed across the O1 and O2 interfaces (e.g., Configuration Management (CM) and / or Performance Management (PM) execution).

[0062] The SMO framework system architecture includes an SMO function that includes an O1 termination that enables communication between the SMO framework and E2 nodes (i.e., O-CU, O-DU, etc.) over the O1 interface.

[0063] The NRT-RIC includes an NRT-RIC framework, which includes, among other functions, an R1 service exposure function that handles the R1 services provided in the exemplary embodiment. In general, the NRT-RIC functions within the NRT-RIC framework support authorization, authentication, registration, discovery, communication support, etc. for rApps.

[0064] In general, R1 services may include a collection of services including, but not limited to, service registration and discovery services, authentication and authorization services, AI / ML workflow services, and A1, O1, and O2 interface related services.

[0065] NRT-RIC Applications (rApps) are applications that leverage functionality available in the NRT-RIC framework and / or SMO framework to provide value-added services related to RAN operation and optimization. The scope of rApps includes, but is not limited to, radio resource management, data analysis, etc., and information enrichment. In general, rApps refer to applications designed to consume and / or produce R1 services.

[0066] To this end, the NRT-RIC framework produces and / or consumes R1 services according to embodiments of the present invention via an R1 interface, which terminates at an R1 termination of the NRT-RIC framework, which connects to the NRT-RIC framework and rApps via the R1 interface, allowing the NRT-RIC framework and rApps to exchange messages / data (i.e., requests and responses configured in data models) to access the R1 services via the R1 interface.

[0067] In general, the R1 interface is defined as the interface between an rApp and the NRT-RIC framework, through which R1 services can be produced and consumed.

[0068] Additionally, the NRT-RIC framework includes A1-related functions, such as supporting A1 logical termination, A1 policy coordination and catalog, and A1-EI coordination and catalog.

[0069] In particular, the NRT-RIC framework and the A1-related functions therein provide A1 policies (i.e., sets of rules used to manage and control the change and / or maintenance of the state of one or more managed objects) based on guidance and enrichment over the A1 interface, which is an interface that enables communication between the NRT-RIC and the nRT-RIC (i.e., A1 policies are a type of declarative policy expressed using formal statements that, according to related art, enable the NRT-RIC in the SMO to guide the nRT-RIC, and therefore the RAN, towards better realization of RAN intent (e.g., predetermined performance goals)).

[0070] The Data Management and Exposure Services within the NRT-RIC framework distribute data generated or collected by data producers to data consumers via the O1 interface according to their needs (e.g., distributing Function Management (FM) / Consumption Management (CM) / Production Management (PM) data to rApps, or CM changes from rApps to the O-RAN).

[0071] The NRT-RIC framework further comprises external terminations that support the exchange of data between the NRT-RIC framework and external AI / ML functions, Enrichment Information (EI) sources, or external oversight, for example.

[0072] Within the NRT-RIC framework, AI / ML workflow services provide access to AI / ML workflows. For example, the AI / ML workflow services may assist in model training, monitoring AI / ML models deployed to the NRT-RIC, etc. As a result, the NRT-RIC framework and the AI / ML workflow services therein enable artificial intelligence and machine learning (AI / ML) training and inference for RAN optimization.

[0073] Additionally, the NRT-RIC framework provides A2 related functions that support, for example, A2 logical termination, A2 policy coordination and catalogs.

[0074] 4, the NRT-RIC framework (e.g., the NRT-RIC and / or at least one rApp hosted by the NRT-RIC framework) enables flexible configuration of carrier and / or cell switch off / on parameters within a cell or cluster of cells by providing, via the A1 interface, an A1 policy formulated by the NRT-RIC (e.g., by the NRT-RIC and / or at least one rApp hosted by the NRT-RIC framework assisted by machine learning (ML) techniques) to the nRT-RIC, where the nRT-RIC may perform deployment of the configured carrier and / or cell switch off / on parameters to one or more E2 nodes via E2 interface actions.

[0075] To this end, before shutting down (i.e., switching off) one or more carriers and / or cells, the E2 node may need to perform preparatory actions for shutting down (i.e., switching off) one or more carriers and / or cells (e.g., the E2 node may check for ongoing emergency calls and / or warning messages, engage in (e.g., enable, disable, modify, etc.) carrier aggregation and / or dual connectivity, trigger High Occupancy (HO) data traffic and User Entities (UEs) from one or more cells and / or carriers to other cells or carriers, notify neighboring nodes via the X2 / Xn interface, etc.).

[0076] Furthermore, before switching on one or more carriers and / or cells, the E2 node may need to perform preparatory actions for switching on (e.g., the E2 node may perform cell probing, notify neighboring nodes via the X2 / Xn interface, etc.).

[0077] Referring to FIG. 4, the SMO and NRT-RIC framework is configured to collect data required to perform cell and / or carrier switch off / on optimization, such as configuration, performance indicators, and measurement reports (e.g., cell load related information and traffic information, energy efficiency EE and / or energy consumption EC measurement reports, geographical location information, etc.) from E2 node(s) (i.e., O-CU, O-DU, etc.) and O-RU (via E2 node(s)).

[0078] The data collected from E2 node(s) (i.e., O-CU, O-DU, etc.) necessary to perform cell and / or carrier switch off / on optimization may include relevant information of the corresponding O-RU(s), where its configuration, performance indicators, and measurement reports (e.g., cell load-related information and traffic information, energy efficiency EE and / or energy consumption EC measurement reports, geographical location information, etc.) make it possible to identify the individual functions of the O-RU(s) (e.g., the internal system architecture of the O-RU, its performance, its functionality, etc. for optimally managing the O-RU and / or its RF transceiver chain).

[0079] The collected data can be used for the purposes of (re)training and inference of AI / ML models that support EE / ES functions to optimize energy efficiency EE and / or energy consumption EC for nRT-RIC through the SMO / NRT-RIC framework supported by machine learning (ML) techniques.

[0080] As mentioned above, it is assumed here that the configuration, performance indicators, and measurement reports (i.e., data required to perform cell and / or carrier switch-off / on optimization) collected from an E2 node (e.g., O-DU) include relevant information of the corresponding O-RU(s).

[0081] According to an exemplary embodiment, the data collected as described above may be collected from an E2 node via an O1 interface and / or directly from an O-RU.

[0082] According to another exemplary embodiment, the data collected as described above may be collected from the O-RU via the open FH M-plane through the E2 interface.

[0083] Generally, energy efficiency EE is defined as the relationship between useful output and energy / electricity consumption, while energy consumption EC is defined as the integral of electricity consumption over time.

[0084] In particular, the SMO and NRT-RIC framework is configured to formulate an A1 policy (e.g., optimization triggers, optimization goals, and intent-based policies (e.g., energy saving intents such as setting an energy target to 50% of peak power consumption)) and provide this A1 policy (e.g., via an A1 interface) to the nRT-RIC (e.g., the SMO and NRT-RIC framework may include R1 / O1 and / or R1 / A1 consumer services and / or production services).

[0085] Additionally, the SMO and NRT-RIC frameworks can be configured to, for example, train (retrain), update, configure, etc., EE / ES AI / ML models within the NRT-RIC.

[0086] In an example embodiment, the SMO and NRT-RIC framework (e.g., the NRT-RIC and / or at least one rApp hosted by the NRT-RIC framework) may be configured to trigger EE / ES AI / ML model training and / or retraining within the NRT-RIC.

[0087] Further, in an exemplary embodiment, the SMO and NRT-RIC may be configured to deploy, update, configure, etc., energy-efficient EE / energy-saving ES AI / ML models within the NRT-RIC (e.g., the SMO and NRT-RIC framework may include R1 / O1 and / or R1 / A1 consumer and / or production services for deploying, updating, configuring, etc., EE / ES AI / ML models).

[0088] 4, one or more rApps hosted in the NRT-RIC framework may be configured to collect data necessary to perform cell and / or carrier switch-off / on optimization from an open radio unit (O-RU) via an E2 node via the nRT-RIC through the NRT-RIC framework and the SMO framework. For example, based on A1 control feedback provided to the E2 node(s) and O-RU via the nRT-RIC, the rApps may be configured to collect configurations, performance indicators, measurement reports (i.e., EE / EC measurement reports), etc. from the E2 node and O-RU for purposes of training and running associated AI / ML models (e.g., EE / ES AI / ML models) and for purposes of monitoring at least one performance objective (e.g., performance of the EE / ES AI / ML models with respect to the objective).

[0089] Additionally, the rApp hosted by the NRT-RIC may be configured to perform actions necessary for EE / ES optimization (i.e., consume and / or produce services over the R1 interface) (e.g., the rApp may check for ongoing emergency calls and alert messages over the R1 / O1 interface and perform some preparatory actions for shutdown (i.e., switch off) to one or more carriers and / or cells). In an example embodiment, the rApp may be configured to enable, disable, modify carrier aggregation and / or dual connectivity, etc., to trigger HO traffic and UEs from one or more cells and / or carriers to other cells or carriers, and notify neighboring nodes over the X2 / Xn interface.

[0090] In another exemplary embodiment, one or more rApps hosted by the NRT-RIC may be configured to perform actions necessary for EE / ES optimization (i.e., consuming and / or producing service via the R1 interface) to prepare for the switch-on of one or more carriers and / or cells (e.g., one or more rApps hosted by the NRT-RIC may be configured to perform cell probing, notify neighboring nodes via the X2 / Xn interface, etc.).

[0091] Additionally, rApps hosted by the NRT-RIC may be configured to initiate fallback measures, for example, to train (retrain), update, configure, etc., EE / ES AI / ML models (e.g., may comprise R1 / O1 consumer services and / or production services and / or R1 / A1 consumer and / or production services).

[0092] Additionally, one or more rApps hosted by the NRT-RIC may be configured to apply AI / ML model inference to formulate at least one optimized A1 policy for the EE / ES based on data collected using the R1 interface (e.g., modify, update, or delete an optimized A1 policy for the EE / ES that does not meet performance targets for the O-RAN optimization intent).

[0093] For this purpose, one or more E2 node(s) in FIG. 1 (i.e., O-DU, O-CU, etc.) are configured to report, for example, cell configuration, performance indicators, measurement reports (e.g., cell load-related information, traffic information, EE / EC measurement reports, etc.) to the SMO via the O1, O2, A1 interfaces, where SMO functionality, such as the O1, O2 termination and / or A1 termination of the NRT-RIC framework, enables the SMO, NRT-RIC, and rApp to communicate with the E2 node (e.g., O-DU).

[0094] Still referring to FIG. 4, the O-RU of FIG. 1 is configured to report energy consumption EC and energy efficiency EE related information to the E2 node (i.e., O-DU) via the open FH M plane interface.

[0095] In an exemplary embodiment, one or more O-RUs of FIG. 1 may be configured to report energy consumption EC and energy efficiency EE related information directly to the SMO / NRT-RIC.

[0096] Additionally, one or more O-RUs in FIG. 1 may be configured to support the actions necessary to perform EE / ES optimization and report updated carrier configurations (e.g., to report configuration status, e.g., configuration states such as activated, deactivated, sleep, etc.).

[0097] For example, according to communication between the O-DU and the O-RU, the E2 node(s) can identify the individual capabilities of the O-RU(s), where the O-RU(s) can be configured to support all actions required to perform EE / ES optimization (e.g., according to the A1 policy).

[0098] FIG. 5 illustrates a flow diagram of a method for performing carrier and / or cell switch off / on optimization according to one embodiment.

[0099] 5, a method for performing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy may include functions such as a service management and orchestration (SMO) framework, a near real-time radio intelligent controller (nRT-RIC), a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, and one or more rApps. The SMO framework / NRT-RIC framework and the nRT-RIC may act as mediators between the rApps in the O-RAN according to FIGS. 1 and 4 and the E2 node(s) and the O-RU (via the E2 node).

[0100] In step 501, the rApp collects data (i.e., optimization data) required to perform cell and / or carrier switch off / on optimization through the NRT-RIC framework and SMO framework from the O-RU via the nRT-RIC.

[0101] In an example embodiment, collecting the optimization data provision may include sending, by the rApp, an optimization data collection request to the E2 node via the R1 interface through an SMO function (e.g., A1, O1, O2 termination) within the NRT-RIC framework and the SMO framework. The E2 node may receive the optimization data collection request from the SMO function and collect the optimization data from the O-RU via the open fronthaul management plane FH M plane interface between the E2 node and the open radio unit O-RU.

[0102] In an exemplary embodiment, with respect to collecting optimization data, the E2 node may activate measurement reporting (i.e., EE / EC measurement reporting) to the O-RU, and the O-RU may provide measurement data (i.e., input data) for the measurement reporting.

[0103] In step 502, based on the collected optimization data, the SMO (i.e., rApp or NRT-RIC) (re)trains at least one artificial intelligence / machine learning (AI / ML) model. Further, upon a request from, for example, an rApp to the NRT-RIC framework, the NRT-RIC framework may deploy the retrained AI / ML model to the nRT-RIC.

[0104] In an example embodiment, the input data for training the AI / ML model may include the following measurement data for monitoring the energy consumption and energy efficiency EC / EE of one or more E2 nodes and one or more O-RUs: Downlink Packet Data Convergence Protocol Service Data Unit (DL PDCP) SDU data volume per interface (DL data volume delivered from O-CU-UP to O-DU per public land mobile network (PLMN), per quality of service (QoS) level, per slice, per F1-U interface, Xn-U interface, X2-U interface); Uplink Packet Data Convergence Protocol Service Data Unit (UP PDCP) per interface SDU data volume (UL data volume delivered from O-CU-UP to O-DU per public land mobile network (PLMN), per quality of service QoS level, per slice, per F1-U interface, Xn-U interface, X2-U interface); reference signal received quality RSRQ measurement value per synchronization signal block (SSB) per cell; reference signal received power RSRP measurement value per SSB per cell; signal to interference and noise ratio SINR measurement value per SSB per cell; energy consumption; power consumed by hardware components; transmit power, etc.

[0105] In an exemplary embodiment, the NRT-RIC framework may (re)train at least one AI / ML model. According to this exemplary embodiment, an rApp may select an AI / ML model from multiple AI / ML models and send an initiation request to the NRT-RIC framework to retrain the AI / ML model. The rApp may monitor the retrained AI / ML model parameters and, based on the retrained AI / ML model parameters, determine to update or retrain the retrained AI / ML model from the NRT-RIC framework.

[0106] In step 503, the rApp provides the nRT-RIC with an A1 policy for preparing and performing cell and / or carrier switch off / on optimization through the NRT-RIC framework.

[0107] In an example embodiment, the A1 policy may be formulated based on a retrained AI / ML model from the NRT-RIC framework.

[0108] In step 504, based on the provided A1 policy, the nRT-RIC collects data (i.e., implementation data) required to perform cell and / or carrier switch-off / on from the O-RU (e.g., via the E2 node, from the O-RU, via the E2 interface).

[0109] Further, in step 504, based on the deployed AI / ML model and the provided A1 policy, the nRT-RIC evaluates the collected data (i.e., implementation data) necessary to perform cell and / or carrier switch-off / on.

[0110] According to an example embodiment, the optimization and implementation may include the same data required to perform cell and / or carrier switch-off / on in the O-RU.

[0111] According to an example embodiment, the optimization data and implementation data may be data required to perform cell and / or carrier switch-off / on in the O-RU, collected via different interfaces (O1, O2, A1, E2, etc.) within the O-RAN.

[0112] For example, the nRT-RIC interprets the provided A1 policy and applies AI / ML model inference to the collected data (i.e., implementation data) required to perform cell and / or carrier switch-off / on.

[0113] In step 505, the nRT-RIC generates at least one E2 message for preparing and performing cell and / or carrier switch off / on optimization based on the evaluation, and transmits the at least one E2 message to the O-RU via the E2 node.

[0114] In an exemplary embodiment, the nRT-RIC may generate at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU and transmit the E2 control command and / or at least one E2 policy command to the E2 node via the E2 interface to meet predetermined performance targets (e.g., EE / ES performance targets formulated in the provided A1 policy).

[0115] In step 506, based on the at least one E2 message, the E2 node and the O-RU implement cell and / or carrier switch off / on optimization in the O-RAN.

[0116] For example, upon receiving at least one E2 message, the E2 node may convert the at least one E2 message for preparing and performing cell and carrier switch off / on into an implementation command for the O-RU, where the implementation command for the O-RU instructs the O-RU to perform cell and / or carrier switch off / on via the open FH M plane.

[0117] In step 507, based on the implementation, the rApp receives A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through the NRT-RIC framework.

[0118] For example, the O-RU may notify the E2 node via the FH M plane interface about the completion of the implementation of cell and / or carrier switch off / on. When the E2 node receives the notification from the O-RU, it notifies the nRT-RIC via the E2 interface. When the NRT-RIC receives the notification from the nRT-RIC, it notifies the rApp via the R1 interface through the NRT-RIC framework.

[0119] In another example embodiment, after implementation in step 506, the rApp may monitor the performance of the (re)trained AI / ML model via the NRT-RIC framework and determine that predetermined performance goals are not being achieved, in which case the rApp and / or NRT-RIC may initiate a fallback mechanism and / or initiate an update or retraining of the AI / ML model.

[0120] As a result, training an AI / ML model within the SMO / NRT-RIC framework and providing the trained AI / ML model together with an A1 policy to the nRT-RIC enables the generation of E2 messages and their implementation feedback (i.e., A1 policy feedback to initiate fallback measures related to performance targets). This has the advantage that network operators can flexibly configure optimal carrier and / or cell and / or carrier switch-off / on parameters in a cell or cluster of cells (i.e., generate optimal E2 control command(s) and / or E2 policy command(s)) to maximize energy efficiency management in O-RAN.

[0121] FIG. 6 illustrates a flow diagram of a method for implementing carrier and / or cell switch off / on optimization based on A1 policy according to one embodiment.

[0122] Referring to FIG. 6, during collection of data necessary for performing cell and / or carrier switch-off / on by the nRT-RIC, in step 601, the nRT-RIC interprets the A1 policy provided for cell and / or carrier switch-off / on (i.e., the A1 policy provided by the rApp via the NRT-RIC).

[0123] In step 602, based on the interpretation of the A1 policy, the nRT-RIC sends a data collection request to the E2 node via the E2 interface.

[0124] In step 603, the E2 node receives a data collection request from the nRT-RIC and collects the data necessary to perform cell and / or carrier switch-off / on from the O-RU (e.g., via the open FH M-plane interface).

[0125] In step 604, the E2 node transmits the collected data necessary to perform cell and / or carrier switch-off / on to the nRT-RIC via the E2 interface.

[0126] As a result, the interpretation of A1 policy in the nRT-RIC enables the generation of the latest E2 messages (i.e., generating optimal E2 control commands and / or E2 policy commands) based on the latest (updated or modified) A1 policy. The A1 policy feedback action of the rApp (i.e., initiation of fallback measures) has the advantage that the nRT-RIC can generate optimal E2 control policies within a cell or cell cluster to maximize energy efficiency management within the O-RAN and flexibly meet changing conditions within the O-RAN.

[0127] 7 shows a flow diagram of a method for performing carrier and / or cell switch off / on optimization based on an A1 policy according to one embodiment. Referring to FIG. 7, during evaluating data required to perform cell and / or carrier switch off / on, in step 701, the nRT-RIC receives collected data required to perform cell and / or carrier switch off / on from the E2 node via the E2 interface.

[0128] In step 702, the nRT-RIC applies AI / ML model inference to evaluate at least one E2 message based on the collected data required to perform cell and / or carrier switch-off / on.

[0129] In step 703, while generating at least one E2 message for preparing and performing cell and / or carrier switch off / on optimization, the nRT-RIC generates at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference.

[0130] In step 704, the nRT-RIC transmits at least one E2 control command and / or at least one E2 policy command to the E2 node (eg, via the E2 interface).

[0131] As a result, according to the embodiment shown in FIG. 7, the AI / ML model inference in the nRT-RIC provides E2 control commands and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU in near real time (e.g., within a latency of 10 ms to 1 s), thereby enabling the network operator to flexibly (i.e., quickly) configure switch off / on parameters of carriers and / or cells within a cell or cluster of cells to optimize energy efficiency management in the O-RAN.

[0132] FIG. 8 shows a flow diagram of a method for performing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0133] Referring to FIG. 8, while receiving A1 policy feedback from the O-RU, in step 801, the O-RU notifies the rApp of the A1 policy feedback based on feedback regarding at least one E2 message from the O-RU through the NRT-RIC framework and the SMO framework.

[0134] In step 802, the E2 node notifies the nRT-RIC (e.g., via the E2 interface) of E2 message feedback based on the completion of the implementation of turning the cell and / or carrier off / on (i.e., based on the notification of the O-RU in step 801).

[0135] In step 803, the nRT-RIC notifies the rApp of A1 control feedback based on the E2 message feedback through the NRT-RIC framework / SMO framework.

[0136] As a result, individual notifications can provide detailed A1 control feedback that includes feedback data from all lower network layer functions (i.e., O-DU, O-CU, O-RU, etc.). This detailed A1 control feedback enables precise reformulation of A1 policies to maximize the achievement of performance targets or enhance the training of AI / ML models to achieve optimal AI / ML model inference in the nRT-RIC. Individual notifications have the advantage of allowing precise implementation of ES / EE to maximize O-RAN energy efficiency.

[0137] FIG. 9 shows a flow diagram of a method for performing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0138] Referring to FIG. 9, in step 901, the nRT-RIC notifies the rApp, through the NRT-RIC framework and / or the SMO framework, of A1 policy feedback based on feedback regarding at least one E2 message from the O-RU.

[0139] In step 902, the rApp monitors at least one performance goal (i.e., based on A1 policy feedback, performance indicators, performance of the AI / ML model, etc.). For example, the rApp may analyze A1 policy feedback.

[0140] In step 903, the rApp determines, based on the communicated A1 control feedback, that at least one predetermined performance goal is not being achieved.

[0141] For example, the rApp may monitor and analyze performance objective(s) related to achieving the O-RAN's intent to optimize carrier and / or cell switch-off / on in O-RU(s) (e.g., to allow the operator to flexibly configure carrier and cell switch-off / on parameters for EE / ES management of the O-RU(s)).

[0142] For this purpose, the rApp may, for example, constantly monitor the performance and energy consumption of the E2 node, as well as the energy consumption of the O-RU.

[0143] In step 904, the rApp initiates a fallback mechanism associated with at least one predetermined performance goal.

[0144] In step 905, while initiating the fallback mechanism, the rApp modifies the A1 policy to prepare and execute cell and / or carrier switch-off / on based on predetermined performance targets.

[0145] In step 906, the rApp requests the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC.

[0146] Alternatively, while initiating the fallback mechanism, in steps 905 and 906, the rApp may initiate updating and / or retraining the AI / ML model based on predetermined performance goals. To this end, the rApp may send an initiation request to retrain the AI / ML model to the NRT-RIC framework. Upon receiving the request, the NRT-RIC (re)trains the AI / ML model via the NRT-RIC framework. During training, the rApp may monitor the retrained AI / ML model parameters, and based on the retrained AI / ML model parameters, the rApp may decide to request the NRT-RIC to deploy the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC.

[0147] As a result, the initiation of a fallback mechanism (i.e., fallback measure) associated with the O-RAN's intent to optimize at least one E2 control command and / or at least one E2 policy command based on a predetermined performance target may result in the generation of a modified A1 policy and / or updated AI / ML model that takes into account changing conditions on the O-RAN.

[0148] This has the advantage that a flexible configuration of carrier and / or cell off / on parameters can be achieved within a cell or cluster of cells, and this configuration can be optimally adapted to changing conditions within the O-RAN.

[0149] FIG. 10 shows a flow diagram of a method for performing carrier and / or cell switch off / on optimization based on A1 policy according to another embodiment.

[0150] Referring to FIG. 10, while retraining at least one AI / ML model according to an alternative fallback strategy in step 904 of FIG. 9, in step 1001, the rApp selects one AI / ML model from multiple AI / ML models.

[0151] In step 1002, the rApp sends an initiation request to the NRT-RIC framework to retrain the AI / ML model.

[0152] In step 1003, the NRT-RIC (re)trains the AI / ML model according to the NRT-RIC framework.

[0153] In step 1004, the rApp monitors the retrained AI / ML model parameters, and based on the retrained AI / ML model parameters, the rApp requests the NRT-RIC to deploy the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC.

[0154] As a result, the initiation of fallback mechanisms related to the O-RAN intent to optimize E2 configuration data for preparing and executing cell and / or carrier switch-off / on based on predetermined performance targets allows optimally trained AI / ML models that take into account changing conditions on the O-RAN. This has the advantage that flexible configuration of carrier and / or cell off / on parameters can be achieved within a cell or cluster of cells, and this configuration can be optimally adapted to changing conditions within the O-RAN.

[0155] Figure 11 illustrates a method for data collection, according to one embodiment. Referring to Figure 11, data collection is intended to enable A1 policy-based carrier and / or cell switch off / on energy saving functionality in the O-RAN through configuration parameter changes and actions controlled by the nRT-RIC, and to enable AI / ML-based generation of configuration data required to perform carrier and cell switch off / on in the O-RU.

[0156] To this end, the SMO framework and the NRT-RIC framework include A1 and O1 termination functions to enable O1 and A1 interface communications within the O-RAN. The NRT-RIC framework and / or rApp(s) may perform carrier and cell switch off / on optimization. The E2 node and the O-RU may perform (i.e., implement) carrier and cell switch off / on optimization configurations.

[0157] 11, once R1 and O1 interface connectivity, A1 interface connectivity, and open FH M plane interface connectivity are established, communication paths are established between the rApp(s) and the E2 node(s) and O-RU, as well as between the NRT-RIC and nRT-RIC, and the O-RAN is operational. Furthermore, depending on the state of the operational O-RAN infrastructure, the nRT-RIC acquires knowledge about overlapping carriers / cells and their coverage (e.g., which carriers / cells are coverage layers and which carriers / cells are capacity layers).

[0158] To optimize EE / ES in the O-RAN, a network operator may set performance targets for the energy-saving ES function in the NRT-RIC (i.e., predetermined performance parameters for EE / ES in the O-RAN, e.g., one or more predetermined performance goals for EE / EC in the O-RAN). These targets for the energy-saving ES function in the NRT-RIC may be formulated in a separate A1 policy.

[0159] As a result, the method for optimizing carrier and / or cell switch off / on based on A1 policies may begin once the network operator enables the optimization rApp along with the initial AI / ML models of carrier and cell switch off / on ES functions and the E2 nodes and O-RUs are operational.

[0160] In operation 1, a method for performing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy may begin when a network operator enables an optimization rApp with initial AI / ML models of carrier and cell switch off / on energy saving ES functions and the E2 node(s) and O-RU(s) become operational. At this point, in operation 1, the rApp requests collection of optimization data (i.e., data required to perform cell and / or carrier switch off / on optimization), such as configuration, performance indicators, and measurement data (e.g., cell load-related information and traffic information, EE / EC measurement reports, cell-level configurations) via the R1 interface to the SMO framework and / or NRT-RIC framework.

[0161] In operation 2, the SMO framework function and / or the NRT-RIC framework function requests collection of optimization data from the E2 node and (via the E2 node) the O-RU.

[0162] For example, the SMO framework function and / or the NRT-RIC framework function may request collection of optimization data from the E2 node via the O1 interface.

[0163] In operation 3, upon receiving a request from the SMO framework function and / or the NRT-RIC framework function, the E2 node (i.e., O-CU, O-DU, etc.) requests and collects data (i.e., configuration data, configured measurement data) required to optimize carrier and / or cell switch-off / on from the O-RU. For example, the E2 node collects data from the O-RU via an open FH M-plane interface.

[0164] In operation 4, the E2 nodes (i.e., O-CU, O-DU, etc.) send optimization data, such as configuration data, configured measurement data, etc., to the SMO / NRT-RIC framework periodically or on an event basis.

[0165] In operation 5, the NRT-RIC obtains optimization data (i.e., configuration data, configured measurement data, etc.) for processing (e.g., to consume and / or generate R1 services related to EE / ES) and provides the optimization data to the rApp (e.g., via the R1 interface).

[0166] 12 illustrates an AI / ML model training flow in an NRT-RIC according to one embodiment. Referring to FIG. 12, in operation 6, if the NRT-RIC framework is hosting (re)training of at least one AI / ML model among multiple AI / ML models, the rApp selects one AI / ML model from the multiple AI / ML models and initiates retraining of the selected AI / ML model on the non-RT-RIC framework. In an exemplary embodiment, the AI / ML model (re)training and selection may be performed by a flexible AI / ML workflow within the SMO (i.e., the NRT-RIC framework and the rApp may collaborate in the AI / ML workflow to achieve optimal results).

[0167] In operation 7, upon receiving a (re)training request from the rApp, the NRT-RIC framework initiates AI / ML model retraining.

[0168] In operation 8, the rApp monitors the performance of the retrained AI / ML model (i.e., the rApp analyzes the performance of the retrained AI / ML model).

[0169] In operation 9, when the rApp determines that the retraining of the AI / ML models is complete (i.e., based on monitoring the AI / ML model parameters), the rApp requests the NRT-RIC (e.g., through the R1 interface via the SMO / NRT-RIC framework according to FIG. 4) to deploy at least one AI / ML model (including the (re)trained AI / ML model) to the nRT-RIC.

[0170] Figure 13 shows an AI / ML model training flow in an rApp, according to one embodiment. Referring to Figure 13, in operation 10, the retraining of the AI / ML model is hosted in the rApp, and the AI / ML model is retrained by the rApp itself.

[0171] In operation 11, when the rApp determines that the retraining of the AI / ML model is complete, the rApp transfers at least one AI / ML model (including the (re)trained AI / ML model) to the SMO framework / NRT-RIC framework for deployment to the nRT-RIC (i.e., the rApp requests the NRT-RIC to deploy the AI / ML model to the nRT-RIC).

[0172] Referring to Figures 12 and 13, in operations 9 and 11, respectively, the rApp constantly monitors the performance and energy consumption of E2 node(s), energy consumption of O-RU(s), etc.

[0173] In an example embodiment, the input data (i.e., optimization data) used in AI / ML model training may include the following measurement data for monitoring the energy consumption and energy efficiency EC / EE of one or more E2 nodes and one or more O-RUs: Downlink Packet Data Convergence Protocol Service Data Unit (DL PDCP) SDU data volume per interface (DL data volume delivered from O-CU-UP to O-DU per public land mobile network (PLMN), per quality of service (QoS) level, per slice, per F1-U interface, Xn-U interface, and X2-U interface); Uplink Packet Data Convergence Protocol Service Data Unit (UP PDCP) per interface SDU data volume (UL data volume delivered from O-CU-UP to O-DU per public land mobile network (PLMN), per quality of service QoS level, per slice, per F1-U interface, Xn-U interface, X2-U interface); reference signal received quality RSRQ measurement value per synchronization signal block (SSB) per cell; reference signal received power RSRP measurement value per SSB per cell; signal to interference and noise ratio SINR measurement value per SSB per cell; energy consumption; power consumed by hardware components; transmit power, etc.

[0174] FIG. 14 illustrates the generation and implementation of E2 message(s) for preparing and performing cell and / or carrier switch off / on based on A1 policy, according to one embodiment.

[0175] 14, in operation 13, the rApp provides the nRT-RIC with an A1 policy for preparing and executing cell and / or carrier switch-off / on via the R1 interface through the NRT-RIC framework and via the A1 interface through A1-related functions in the NRT-RIC framework. For example, the rApp triggers EE / ES optimization through the A1 policy for preparing and executing cell(s) and carrier(s) switch-off / on.

[0176] In operation 14, the nRT-RIC interprets the A1 policy for switching off / on cells and / or carriers.

[0177] In operation 15, based on the interpretation of the A1 policy, the nRT-RIC sends a data collection request to the E2 node via the E2 interface.

[0178] In operation 16, upon receiving a data collection request from the nRT-RIC function, the E2 node collects the data necessary to perform cell and / or carrier switch off / on from the O-RU (e.g., via the open FH M-plane interface).

[0179] In operation 17, the E2 node transmits the collected data to the nRT-RIC via the E2 interface.

[0180] In operation 18, upon receiving the collected data required to perform cell and / or carrier switch off / on from the E2 node via the E2 interface, the nRT-RIC applies AI / ML model inference based on the received E2-related data to evaluate at least one E2 message (e.g., E2 control command and / or E2 policy command required to apply the implementation of cell and / or carrier switch off / on in the O-RU).

[0181] In operation 19, based on the AI / ML model inference, the nRT-RIC generates at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU, and sends an E2 message to the E2 node via the E2 interface. For example, the E2 message(s) may include E2 configuration data for preparing and performing cell and / or carrier switch-off / on that meets the energy saving target(s) formulated in the A1 policy and corresponds to the capabilities of the O-RU (e.g., meets the requirements of the O-RU's internal system architecture).

[0182] In operation 20, based on the E2 message (e.g., E2 configuration data for preparing and performing cell and / or carrier switch-off / on), the E2 node and the O-RU implement the cell and / or carrier switch-off / on in the O-RAN. According to an example embodiment, while implementing the E2 message, the E2 node may convert at least one E2 control command and / or at least one E2 policy command for preparing and performing cell and / or carrier switch-off / on into an implementation instruction command, where the implementation instruction command instructs the O-RU to perform the cell and / or carrier switch-off / on. For example, the E2 node instructs the O-RU(s) to update their configurations to perform the cell or carrier switch-off / on.

[0183] In operation 21, based on the completion of the implementation by operation 20, the rApp receives A1 policy feedback from the E2 node (e.g., via the R1 interface through the NRT-RIC framework and via the A1 interface through A1-related functions within the NRT-RIC framework) (i.e., the nRT-RIC feeds back E2 control / policy to the rApp).

[0184] In an exemplary embodiment, the O-RU may notify the E2 node of completion of the implementation of cell and / or carrier switch off / on via the FH M plane interface between the E2 node and the O-RU. In response, the E2 may notify the nRT-RIC via the E2 interface of feedback regarding the E2 message(s) (e.g., at least one E2 control command and / or at least one E2 policy command) based on the completion of the implementation of the cell and / or carrier switch off / on (i.e., based on the O-RU's notification). Upon receiving the feedback regarding the E2 message(s), the nRT-RIC may notify the rApp (e.g., through the SMO framework function and via the R1 interface through the NRT-RIC framework within the SMO framework) of A1 policy feedback based on the feedback regarding the E2 message(s).

[0185] In operation 22, the rApp monitors at least one performance goal based on the A1 policy feedback, e.g., whether the A1 policy feedback indicates that the A1 policy (e.g., related to an energy conservation goal) was successfully interpreted, enforced, etc.

[0186] In act 23, the rApp may determine that a predetermined performance goal is not being achieved (i.e., based on the E2 control policy feedback) based on the monitoring (i.e., A1 policy feedback) in act 22. In this case, the rApp may initiate at least one fallback mechanism associated with the predetermined performance goal.

[0187] In operation 24, based on the initiation, the rApp may modify the A1 policy to prepare and perform cell and / or carrier switch off / on optimization based on predetermined performance targets and send the modified A1 policy to the NRT-RIC. For example, the rApp may update or delete the A1 policy for carrier and / or cell switch off / on optimization and send the modified A1 policy to the NRT-RIC.

[0188] In operation 25, based on the initiation, the rApp may initiate an AI / ML model update and / or AI / ML model retraining based on predetermined performance goals (e.g., based on an evaluation of an energy saving goal).

[0189] In operation 26, once the AI / ML model update begins, the NRT-RIC framework may send the update (i.e., the updated AI / ML model) or deploy the retrained AI / ML model to the nRT-RIC.

[0190] The method for performing carrier and / or cell switch off / on optimization based on the A1 policy may terminate when the E2 node(s) becomes inoperable or when the operator disables the optimization rApp or AI / ML model(s) for the energy saving (ES) function(s). However, as long as the optimization rApp is enabled, the rApp continues to monitor the ES function in the E2 node and O-RU, where the E2 node and O-RU operate using updated parameters / models and states (off / on) (i.e., implement the latest E2 message from the nRT-RIC containing the latest E2 control command and / or latest E2 policy command to prepare and perform cell and / or carrier switch off / on).

[0191] As a result, the system and method implement an NRT-RIC framework that allows network operators to flexibly configure carrier and / or cell switch off / on parameters within a cell or cluster of cells to optimize energy efficiency management in O-RAN.

[0192] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit 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.

[0193] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, one or more of the 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(s) having computer-readable program instructions for causing a processor to perform operations.

[0194] A computer-readable storage medium may be any tangible device capable of retaining and storing instructions for use by an instruction-execution device. A 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 computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0195] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0196] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions to personalize the electronic circuitry by utilizing state information of the computer-readable program instructions to perform aspects or operations.

[0197] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, form means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular way, such that the computer-readable storage medium on which the instructions are stored constitutes an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0198] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions, executing on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0199] The flowcharts 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 flowcharts or block diagrams may represent a portion of a microservice, module, segment, or instruction set, comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those shown 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 actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or a combination of dedicated hardware and computer instructions.

[0200] It will be apparent that the 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 intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0201] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following clauses. Item [1]: A system for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, the system may include: a memory that stores instructions; and at least one processor configured to implement a service management and orchestration (SMO) framework, a near real-time radio intelligent controller (nRT-RIC), a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, and an rApp, wherein the at least one processor executes the instructions to: collect, by the rApp, data necessary to perform cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via the nRT-RIC through the NRT-RIC framework and / or the SMO framework; retrain, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; Among the retrained AI / ML models, deploy one retrained AI / ML model to the nRT-RIC via the NRT-RIC framework; provide, via the rApp, an A1 policy to the nRT-RIC through the NRT-RIC framework for preparing and executing the cell and / or carrier switch off / on optimization; collect, via the nRT-RIC via an E2 node, data for performing the cell and / or carrier switch off / on from the O-RU based on the provided A1 policy; evaluate, via the nRT-RIC, the collected data for performing the cell and / or carrier switch off / on based on the deployed AI / ML model and the provided A1 policy; generate, via the nRT-RIC, at least one E2 message for preparing and executing the cell and / or carrier switch off / on optimization based on the evaluation; and transmit, via the nRT-RIC via the E2 node, the at least one E2 message to the O-RU;Implementing, by the E2 node and the O-RU, switch off / on optimization of the cell and / or carrier within the O-RAN based on the at least one E2 message; and receiving, by the rApp, A1 policy feedback from the O-RU through the E2 node and the nRT-RIC framework based on the implementing. Item [2]: While collecting the data for performing switch-off / on of the cell and / or carrier by the nRT-RIC, the at least one processor: The system described in item [1] may be configured to: interpret, by the nRT-RIC, the provided A1 policy for switching off / on the cell and / or carrier; send, by the nRT-RIC, a data collection request to the E2 node via an E2 interface based on the interpretation of the provided A1 policy; receive, by the E2 node, the data collection request from the nRT-RIC; collect, by the E2 node, the data for performing switching off / on of the cell and / or carrier from the O-RU via an open FH M plane interface; and send, by the E2 node, the collected data for performing switching off / on of the cell and / or carrier to the nRT-RIC via the E2 interface. Item [3]: During evaluation of the collected data for performing switch-off / on of the cell and / or carrier, the at least one processor may be configured to: receive, by the nRT-RIC, the collected data for performing switch-off / on of the cell and / or carrier from the E2 node via the E2 interface; and, based on the collected data for performing switch-off / on of the cell and / or carrier, apply AI / ML model inference by the nRT-RIC to evaluate the at least one E2 message. The system described in Item [2] may be configured to: Item [4]: ​​The system described in Item [3] may be configured to: while generating the at least one E2 message for preparing and performing the cell and / or carrier switch off / on optimization, the at least one processor: generate, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and transmit, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface. Item [5]: The system described in any of items [1] to [4], wherein while receiving the A1 policy feedback from the O-RU, the at least one processor may be further configured to: notify the rApp, via the nRT-RIC, through the NRT-RIC framework and / or the SMO framework, of the A1 policy feedback based on feedback on the at least one E2 message from the O-RU; monitor at least one performance goal by the rApp based on the notified A1 policy feedback; determine that at least one predetermined performance goal is not achieved based on the notified A1 policy feedback; and initiate a fallback mechanism associated with the at least one predetermined performance goal. Item [6]: The system described in Item [5] may be further configured such that, while initiating the fallback mechanism, the at least one processor: based on the initiation, the rApp modifies the provided A1 policy for preparing and performing switch off / on optimization of the cell and / or carrier based on the at least one predetermined performance goal; and, based on the rApp, requests the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC. Item [7]: The system described in Item [6] may be further configured to update the AI / ML model while initiating the fallback mechanism, by the at least one processor: based on the initiation, by the rApp, initiate updating and / or retraining of the AI / ML model based on the at least one predetermined performance goal; by the rApp: sending an initiation request to the NRT-RIC framework to retrain the AI / ML model; by the NRT-RIC, retraining the AI / ML model through the NRT-RIC framework; monitoring the retrained AI / ML model through the rApp; and, based on the retrained AI / ML model parameters, determining, by the rApp, to request the NRT-RIC to deploy the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC, thereby updating the AI / ML model. Item [8]: A method for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, comprising: collecting data for performing cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via an E2 node through the nRT-RIC framework and / or the SMO framework via an rApp; retraining at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; deploying one retrained AI / ML model to the nRT-RIC via the NRT-RIC framework among the at least one retrained AI / ML; providing an A1 policy to the nRT-RIC via the NRT-RIC framework via an rApp for preparing and performing the cell and / or carrier switch off / on optimization; and deploying the cell and / or carrier switch off / on optimization by the nRT-RIC via the E2 node based on the provided A1 policy. collecting data required to perform switch off / on of the cell and / or carrier from the O-RU via a nRT-RIC node; evaluating the collected data for performing switch off / on of the cell and / or carrier by the nRT-RIC based on the deployed AI / ML model and the provided A1 policy; generating at least one E2 message for preparing and performing switch off / on optimization of the cell and / or carrier by the nRT-RIC based on the evaluation; transmitting the at least one E2 message to the O-RU via the E2 node by the nRT-RIC; implementing the switch off / on optimization of the cell and / or carrier within the O-RAN by the E2 node and the O-RU based on the at least one E2 message; and receiving A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework based on the implementing, by the rApp. Item [9]: The method of item [8], wherein collecting the data for switching off / on the cell and / or carrier by the nRT-RIC may include: interpreting a provided A1 policy for switching off / on the cell and / or carrier by the nRT-RIC; sending a data collection request to the E2 node via an E2 interface by the nRT-RIC based on the interpretation of the provided A1 policy; receiving the data collection request from the nRT-RIC by the E2 node; collecting the data for switching off / on the cell and / or carrier from the O-RU via an open FH M plane interface by the E2 node; and transmitting the collected data for switching off / on the cell and / or carrier to the nRT-RIC via the E2 interface by the E2 node. Item

[10] : The method described in Item [9], wherein evaluating the collected data for performing switch-off / on of the cell and / or carrier may include: receiving, by the nRT-RIC, the collected data for performing switch-off / on of the cell and / or carrier from the E2 node via the E2 interface; and applying AI / ML model inference, by the nRT-RIC, to evaluate the at least one E2 message based on the collected data for performing switch-off / on of the cell and / or carrier. Item

[11] : The method described in Item

[10] , wherein generating the at least one E2 message for preparing and performing switch off / on optimization of the cell and / or carrier may include: generating, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and transmitting, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface. Item

[12] : A method according to any of items [8] to

[13] , wherein receiving the A1 policy feedback from the O-RU through the NRT-RIC framework via the E2 node and the nRT-RIC may include: notifying the rApp of the A1 policy feedback through the NRT-RIC framework and / or the SMO framework based on feedback for the at least one E2 message from the O-RU; monitoring at least one performance goal by the rApp based on the notified A1 policy feedback; determining that at least one predetermined performance goal is not achieved based on the notified A1 policy feedback; and initiating a fallback mechanism associated with the at least one predetermined performance goal. Item

[13] : The method described in Item

[12] , wherein initiating the fallback mechanism may include: based on the initiation, modifying, by the rApp, the provided A1 policy for preparing and performing switch off / on optimization of the cell and / or carrier based on the at least one predetermined performance target; and, by the rApp, requesting the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC. Item

[14] : The method described in Item

[12] , wherein initiating the fallback mechanism may include: based on the initiation, by the rApp, initiating an update and / or retraining of the AI / ML model based on the at least one predetermined performance goal; updating the AI / ML model by the rApp, and wherein the updating may include: by the rApp, sending an initiation request to the NRT-RIC framework to retrain the AI / ML model; by the NRT-RIC, retraining the AI / ML model by the NRT-RIC framework; and based on the retrained AI / ML model parameters, by the rApp, determining to request the NRT-RIC to deploy the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC. Item

[15] : A non-transitory computer-readable recording medium storing instructions executable by at least one processor, wherein the at least one processor is further configured to execute a method for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy, the method including: collecting, by an rApp, data for performing cell and / or carrier switch off / on optimization from an open radio unit (O-RU) via an E2 node through the nRT-RIC framework and / or the SMO framework via the nRT-RIC; retraining, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; deploying, by the NRT-RIC framework, one retrained AI / ML model to the nRT-RIC among the at least one retrained AI / ML; deploying, by an rApp, one retrained AI / ML model to the nRT-RIC framework; and providing the nRT-RIC with an A1 policy for preparing and performing cell and / or carrier switch off / on optimization; collecting, by the nRT-RIC, via an E2 node, data necessary for performing cell and / or carrier switch off / on from the O-RU based on the provided A1 policy; evaluating, by the nRT-RIC, the collected data for performing cell and / or carrier switch off / on based on the deployed AI / ML model and the provided A1 policy; generating, by the nRT-RIC, at least one E2 message for preparing and performing cell and / or carrier switch off / on optimization based on the evaluation; transmitting, by the nRT-RIC, the at least one E2 message to the O-RU via the E2 node; implementing, by the E2 node and the O-RU, the cell and / or carrier switch off / on optimization within the O-RAN based on the at least one E2 message;The non-transitory computer-readable storage medium may include, based on the implementation, receiving, by the rApp, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework; Item

[16] : The non-transitory computer-readable storage medium described in Item

[15] , wherein collecting the data for switching off / on the cell and / or carrier by the nRT-RIC may include: interpreting, by the nRT-RIC, a provided A1 policy for switching off / on the cell and / or carrier; sending, by the nRT-RIC, a data collection request to the E2 node via an E2 interface based on the interpretation of the provided A1 policy; receiving, by the E2 node, the data collection request from the nRT-RIC; collecting, by the E2 node, the data for switching off / on the cell and / or carrier from the O-RU via an open FH M plane interface; and transmitting, by the E2 node, the collected data for switching off / on the cell and / or carrier to the nRT-RIC via the E2 interface. Item

[17] : The non-transitory computer-readable recording medium described in Item

[16] , wherein evaluating the collected data for performing switch-off / on of the cell and / or carrier may include: receiving, by the nRT-RIC, the collected data for performing switch-off / on of the cell and / or carrier from the E2 node via the E2 interface; and applying AI / ML model inference, by the nRT-RIC, to evaluate the at least one E2 message based on the collected data for performing switch-off / on of the cell and / or carrier. Item

[18] : The non-transitory computer-readable storage medium described in Item

[17] , wherein generating the at least one E2 message for preparing and performing switch off / on optimization of the cell and / or carrier may include: generating, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and sending, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface. Item

[19] : A non-transitory computer-readable storage medium described in any of items

[15] to

[18] , wherein receiving the A1 policy feedback from the O-RU through the NRT-RIC framework via the E2 node and the nRT-RIC may include: notifying the rApp of the A1 policy feedback through the NRT-RIC framework and / or the SMO framework based on feedback for the at least one E2 message from the O-RU, by the nRT-RIC; monitoring at least one performance goal by the rApp based on the notified A1 policy feedback; determining that at least one predetermined performance goal is not being achieved based on the notified A1 policy feedback; and initiating a fallback mechanism associated with the at least one predetermined performance goal. Item

[20] : The non-transitory computer-readable recording medium described in Item

[19] , wherein initiating the fallback mechanism may include: based on the initiation, modifying, by the rApp, the provided A1 policy for preparing and performing switch off / on optimization of the cell and / or carrier based on the at least one predetermined performance goal; and, by the rApp, requesting the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC.

Claims

1. 1. A system for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on A1 policy, the system comprising: a memory for storing instructions; and at least one processor configured to implement a Service Management and Orchestration (SMO) framework, a near real-time radio intelligent controller (nRT-RIC), a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, and an rApp; The at least one processor executes the instructions to: collecting, by the rApp, from an Open Radio Unit (O-RU) via the nRT-RIC, data necessary to perform cell and / or carrier switch off / on optimization through the NRT-RIC framework and / or the SMO framework; retraining, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; Among the at least one retrained AI / ML, deploying one retrained AI / ML model to the nRT-RIC through the nRT-RIC framework; providing, via the rApp, to the nRT-RIC an A1 policy for preparing and executing switch-off / on optimization of the cell and / or carrier through the nRT-RIC framework; Collecting data from the O-RU via the E2 node by the nRT-RIC based on the provided A1 policy to perform switching off / on of the cell and / or carrier; Evaluating, by an nRT-RIC, the collected data to perform switch-off / on of the cell and / or carrier based on the deployed AI / ML model and the provided A1 policy; generating, by the nRT-RIC, based on the evaluation, at least one E2 message for preparing and performing switch-off / on optimization of the cell and / or carrier; transmitting, by the nRT-RIC, the at least one E2 message to the O-RU via the E2 node; implementing, by the E2 node and the O-RU, switch off / on optimization of the cell and / or carrier in the O-RAN based on the at least one E2 message; Based on the implementation, the rApp is configured to receive A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework. system.

2. While collecting the data for performing switch-off / on of the cell and / or carrier by the nRT-RIC, the at least one processor: interpreting, by the nRT-RIC, the provided A1 policy for switching off / on the cell and / or carrier; sending, by the nRT-RIC, a data collection request to the E2 node via an E2 interface based on the interpretation of the provided A1 policy; receiving, by the E2 node, the data collection request from the nRT-RIC; collecting, by the E2 node, the data for performing switch-off / on of the cell and / or carrier from the O-RU via an open FH M-plane interface; and configured to transmit collected data for performing switching off / on of the cell and / or carrier by the E2 node to the nRT-RIC via the E2 interface; The system of claim 1 .

3. While evaluating the collected data for performing the cell and / or carrier switch off / on, the at least one processor: receiving, by the nRT-RIC, the collected data for performing switching off / on of the cell and / or carrier from the E2 node via the E2 interface; and applying AI / ML model inference by the nRT-RIC to evaluate the at least one E2 message based on the collected data for performing switch-off / on of the cell and / or carrier. The system of claim 2 .

4. While generating the at least one E2 message for preparing and performing the cell and / or carrier switch off / on optimization, the at least one processor: generating, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and configured to transmit, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface; The system of claim 3.

5. While receiving the A1 policy feedback from the O-RU, the at least one processor: notifying the rApp, by the nRT-RIC through the NRT-RIC framework and / or the SMO framework, of the A1 policy feedback based on feedback for the at least one E2 message from the O-RU; monitoring, by the rApp, at least one performance goal based on the notified A1 policy feedback; determining, based on the communicated A1 policy feedback, that at least one predetermined performance goal is not being achieved; and and initiating a fallback mechanism associated with the at least one predetermined performance goal. The system of claim 1 .

6. While initiating the fallback mechanism, the at least one processor: Based on the initiation, modifying, by the rApp, the provided A1 policy for preparing and performing switch-off / on optimization of the cell and / or carrier based on the at least one predetermined performance target; and and requesting, by the rApp, the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC. The system of claim 5.

7. While initiating the fallback mechanism, the at least one processor: Based on the initiation, initiating, by the rApp, updating and / or retraining an AI / ML model based on the at least one predetermined performance goal; By the rApp: sending, by the rApp, an initiation request to retrain the AI / ML model to the NRT-RIC framework; retraining the AI / ML model with the NRT-RIC framework using the NRT-RIC; Monitoring the retrained AI / ML model by the rApp; and and determining, based on the retrained AI / ML model parameters, to request NRT-RIC to deploy, by the rApp, the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC, thereby updating the AI / ML model. The system of claim 6.

8. 1. A method for implementing carrier and / or cell switch off / on optimization in an Open Radio Access Network (O-RAN) based on A1 policy, comprising: collecting data from an open radio unit (O-RU) via an E2 node via the nRT-RIC, by the rApp, for performing cell and / or carrier switch off / on optimization through the nRT-RIC framework and / or the SMO framework; retraining, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; Deploying one retrained AI / ML model to the nRT-RIC through the nRT-RIC framework among the at least one retrained AI / ML; providing, by the rApp, to the nRT-RIC an A1 policy for preparing and performing switch-off / on optimization of the cell and / or carrier through the nRT-RIC framework; collecting, by the nRT-RIC via an E2 node from the O-RU, data required to perform switch-off / on of the cell and / or carrier based on the provided A1 policy; evaluating the collected data to perform switching off / on of the cell and / or carrier by the nRT-RIC based on the deployed AI / ML model and the provided A1 policy; generating, by the nRT-RIC based on the evaluation, at least one E2 message for preparing and performing switch-off / on optimization of the cell and / or carrier; transmitting, by the nRT-RIC, the at least one E2 message to the O-RU via the E2 node; implementing, by the E2 node and the O-RU, switch off / on optimization of the cell and / or carrier in the O-RAN based on the at least one E2 message; receiving, by the rApp based on the implementation, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework; method.

9. The collecting of the data for performing switch off / on of the cell and / or carrier by the nRT-RIC includes: interpreting, by the nRT-RIC, a provided A1 policy for switching off / on the cell and / or carrier; sending, by the nRT-RIC, a data collection request to the E2 node via an E2 interface based on the interpretation of the provided A1 policy; receiving, by the E2 node, the data collection request from the nRT-RIC; collecting, by the E2 node, the data for performing switch-off / on of the cell and / or carrier from the O-RU via an open FH M-plane interface; and transmitting, by the E2 node, the collected data for performing switching off / on of the cell and / or carrier to the nRT-RIC via the E2 interface; The method of claim 8.

10. The evaluating the collected data for performing a switch off / on of the cell and / or carrier comprises: receiving, by the nRT-RIC, the collected data for performing switching off / on of the cell and / or carrier from the E2 node via the E2 interface; and applying AI / ML model inference by the nRT-RIC to evaluate the at least one E2 message based on the collected data for performing switch-off / on of the cell and / or carrier; 10. The method of claim 9.

11. The generating of the at least one E2 message for preparing and performing switch off / on optimization of the cell and / or carrier comprises: generating, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and transmitting, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface; The method of claim 10.

12. receiving the A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework; notifying the rApp, by the nRT-RIC through the NRT-RIC framework and / or the SMO framework, of the A1 policy feedback based on feedback from the O-RU to the at least one E2 message; monitoring, by the rApp, at least one performance goal based on the notified A1 policy feedback; determining, based on the communicated A1 policy feedback, that at least one predetermined performance goal is not being achieved; and initiating a fallback mechanism associated with the at least one predetermined performance goal. The method of claim 8.

13. Initiating the fallback mechanism comprises: Based on the initiation, modifying, by the rApp, the provided A1 policy for preparing and performing switch-off / on optimization of the cell and / or carrier based on the at least one predetermined performance target; and requesting, by the rApp, the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC; The method of claim 12.

14. Initiating the fallback mechanism comprises: based on said initiation, initiating, by said rApp, updating and / or retraining an AI / ML model based on said at least one predetermined performance goal; updating an AI / ML model with said rApp; To update: sending, by the rApp, an initiation request to retrain the AI / ML model to the NRT-RIC framework; retraining, by the NRT-RIC, the AI / ML model by the NRT-RIC framework; and determining, based on the retrained AI / ML model parameters, to request the NRT-RIC to deploy the retrained AI / ML model from the NRT-RIC framework to the nRT-RIC by the rApp; The method of claim 12.

15. 1. A non-transitory computer-readable storage medium storing instructions executable by at least one processor, the at least one processor being further configured to perform a method for implementing carrier and / or cell switch off / on optimization in an open radio access network (O-RAN) based on an A1 policy; The method comprises: collecting data from an open radio unit (O-RU) via an E2 node via the nRT-RIC, by the rApp, for performing cell and / or carrier switch off / on optimization through the nRT-RIC framework and / or the SMO framework; retraining, by the SMO, at least one artificial intelligence / machine learning (AI / ML) model based on the collected optimization data; Deploying one retrained AI / ML model to the nRT-RIC through the nRT-RIC framework among the at least one retrained AI / ML; providing, by the rApp, to the nRT-RIC an A1 policy for preparing and performing switch-off / on optimization of the cell and / or carrier through the nRT-RIC framework; collecting, by the nRT-RIC via an E2 node from the O-RU, data required to perform switch-off / on of the cell and / or carrier based on the provided A1 policy; evaluating the collected data to perform switching off / on of the cell and / or carrier by the nRT-RIC based on the deployed AI / ML model and the provided A1 policy; generating, by the nRT-RIC based on the evaluation, at least one E2 message for preparing and performing switch-off / on optimization of the cell and / or carrier; transmitting, by the nRT-RIC, the at least one E2 message to the O-RU via the E2 node; implementing, by the E2 node and the O-RU, switch off / on optimization of the cell and / or carrier in the O-RAN based on the at least one E2 message; receiving, by the rApp based on the implementation, A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework; A non-transitory computer-readable recording medium.

16. The collecting of the data for performing switch off / on of the cell and / or carrier by the nRT-RIC includes: interpreting, by the nRT-RIC, a provided A1 policy for switching off / on the cell and / or carrier; sending, by the nRT-RIC, a data collection request to the E2 node via an E2 interface based on the interpretation of the provided A1 policy; receiving, by the E2 node, the data collection request from the nRT-RIC; collecting, by the E2 node, the data for performing switch-off / on of the cell and / or carrier from the O-RU via an open FH M-plane interface; and transmitting, by the E2 node, the collected data for performing switching off / on of the cell and / or carrier to the nRT-RIC via the E2 interface; 16. The non-transitory computer-readable storage medium of claim 15.

17. The evaluating the collected data for performing a switch off / on of the cell and / or carrier comprises: receiving, by the nRT-RIC, the collected data for performing switching off / on of the cell and / or carrier from the E2 node via the E2 interface; and applying AI / ML model inference by the nRT-RIC to evaluate the at least one E2 message based on the collected data for performing switch-off / on of the cell and / or carrier; 17. The non-transitory computer-readable storage medium of claim 16.

18. The generating of the at least one E2 message for preparing and performing switch off / on optimization of the cell and / or carrier comprises: generating, by the nRT-RIC, at least one E2 control command and / or at least one E2 policy command for the E2 node corresponding to the capabilities of the O-RU based on the AI / ML model inference; and sending, by the nRT-RIC, the at least one E2 control command and / or the at least one E2 policy command to the E2 node via the E2 interface; 20. The non-transitory computer-readable storage medium of claim 17.

19. receiving the A1 policy feedback from the O-RU via the E2 node and the nRT-RIC through an NRT-RIC framework; notifying the rApp, by the nRT-RIC through the NRT-RIC framework and / or the SMO framework, of the A1 policy feedback based on feedback from the O-RU to the at least one E2 message; monitoring, by the rApp, at least one performance goal based on the notified A1 policy feedback; determining, based on the communicated A1 policy feedback, that at least one predetermined performance goal is not being achieved; and initiating a fallback mechanism associated with the at least one predetermined performance goal.

16. The non-transitory computer-readable storage medium of claim 15.

20. Initiating the fallback mechanism comprises: Based on the initiation, modifying, by the rApp, the provided A1 policy for preparing and performing switch-off / on optimization of the cell and / or carrier based on the at least one predetermined performance target; and requesting, by the rApp, the NRT-RIC to deploy the modified A1 policy from the NRT-RIC framework to the nRT-RIC; 20. The non-transitory computer-readable storage medium of claim 19.

Images