O-ran distributed unit (o-du) power saving

Abstract

Example embodiments of the present disclosure relate to enhanced Open Radio Access Network (O-RAN) Distributed Unit (O-DU) power saving. According to example embodiments, a system may include a Service Management and Orchestration (SMO) framework, and the SMO framework may be configured to: determine whether an O-RAN Radio Unit (O-RU) can be rehomed from a first O-DU to a second O-DU. Based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, the SMO framework may be configured to configure a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.

Description

O-RAN DISTRIBUTED UNIT (O-DU) POWER SAVINGCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to Indian Provisional Patent Application No.202541014921, filed with the Indian Patent Office on February 21, 2025, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to Open Radio Access Network (O-RAN) Distributed Unit (O-DU) power saving.BACKGROUND

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

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

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, differenttypes of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based, etc.), or could be in physical hardware form (e.g., non-VM based, etc.). Accordingly, O-RAN disaggregates the RAN functions into different entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). Since these entities have open protocols and interfaces between them, they can be developed by different vendors.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently implement O-RAN DU (O-DU) power saving.

[0007] According to example embodiments, a system may include a Service Management and Orchestration (SMO) framework, and the SMO framework may be configured to determine whether an O-RAN Radio Unit (O-RU) can be rehomed from a first O-DU to a second O-DU. Based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, the SMO framework may be configured to configure a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.

[0008] According to example embodiments, a method may include determining, by an SMO framework, whether an O-RU can be rehomed from a first O-DU to a second O-DU. The method may further include configuring, by the SMO framework, a TN Manager to rehome the O-RU from the first O-DU to the second O-DU, based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU.

[0009] According to example embodiments, a non-transitory computer-readable recording medium having recorded thereon instructions executable by a device (e.g., a device thatimplements the SMO framework, etc.) to cause the device to perform a method including determining, by an SMO framework, whether an O-RU can be rehomed from a first O-DU to a second O-DU. The method may further include configuring, by the SMO framework, a TN Manager to rehome the O-RU from the first O-DU to the second O-DU, based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU.

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

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

[0012] FIG. 1 illustrates a generic system configuration, according to one or more example embodiments;

[0013] FIG. 2 and FIG. 3 illustrate various example methods and operations, according to one or more example embodiments;

[0014] FIG. 4A to FIG. 6C illustrate various example use cases, according to one or more example embodiments;

[0015] FIG. 7 illustrates an example device / apparatus that may implement one or more example embodiments; and

[0016] FIG. 8 illustrates an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

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

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

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

[0020] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B. Further, the descriptions such as “Component A may communicatively couple to Component B” may refer to any suitable configuration that enables Component A to communicate with Component B, including (but not limited to) arrangements or configurations in which Component A interfaces with or connects to Component B, whether directly or indirectly, via wireless connection, wired connection, or a combination thereof.

[0021] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

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

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

[0024] Furthermore, terms like “0-RAN entities,” “O-RAN components,” “O-RAN network functions,” “RAN entities,” “RAN functions,” “Network Functions,” or the like, may be used interchangeably throughout this specification and may refer to similar components, unless described otherwise. In addition, for illustrative purposes, an “Nthcomponent” may be labelled as “component #N” in the Figures (e.g., a “first O-DU” may be illustrated as “O-DU#1”, a “second O-RU” may be illustrated as “O-RU#2”, etc.).

[0025] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, Internet Engineering Task Force (IETF) standard organization, Institute of Electrical and Electronics Engineers (IEEE) standard organization, and the like. For instance, the terms “O-DU,” “O-RU,” “O-CU,” “O-CU-CP,” “SMO,” “Non-RT RIC,” “Near RT RIC,” “Transport Network,” “01 interface,” “02 interface,” “Fl interface,” “M-Plane,” “PM,” “FM,” “CM,” “Rehoming,” and the like, as well as the associated features, operations, interfaces, and messagesinvolved therein, may be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0026] As described above, an Open Radio Access Network (0-RAN) disaggregates RAN functions / components into various entities, such as an 0-RAN Radio Unit (0-RU), an 0-RAN Distributed Unit (O-DU), and an 0-RAN Central Unit (O-CU), that allow multi-vendor interoperability. Nevertheless, the disaggregation of the RAN functions / components also introduces the complexities and challenges in optimizing power consumption and energy efficiency of the disaggregated RAN functions / components. Amongst others, the power saving of the O-DU remains challenging and complex, due to the following reasons.

[0027] To begin with, an O-DU is typically allocated with the capacity, capability, and resources to handle high network traffic (e.g., during peak hours). Nevertheless, since the O-DU remains fully powered at all times once configured and activated, the underutilization of the O-DU during low network traffic conditions (e.g., during non-peak hours) may cause wastage of the allocated resources and eventually cause the wastage of energy and suboptimal power consumption. In this regard, the static connections or communications between an O-RU and an O-DU may further exaggerate the complexities and difficulties in optimizing the power consumption of the O-DU. Specifically, since each O-RU is coupled to a respective O-DU via a static transport path(s) or connection(s), the underlying transport nodes or components (e.g., switches, routers, optical interfaces, etc.) may always remain in an active state to serve the communications between the O-RU and O-DU. Since there are no mechanisms in the related art to dynamically establish and / or tear down the transport path(s) or connection(s) among the O-RU and the O-DU, it remains a challenging task to dynamically shift the O-RU from one O-DU to another O-DU according to the network condition(s) and / or resource utilization status of the O-DU. Rather, the O-RU typically remains connected to the same O-DU, even when the O-RU carries little or no traffic. Thus, an O-DU may not be turned off or configured to enter the idle mode, without risking service disruption at the associated O-RU.

[0028] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently enhance O-DU power saving. Specifically, example embodiments implement a Service Management and Orchestration (SMO) framework to dynamically determine (via leveraging data obtained or collected via various O-RAN-related features of services, such as policies, Performance Measurement (PM) data, Fault Management (FM) data, Configuration Management (CM) data, etc.) whether an O-RU can be rehomed from a first O-DU to a second O-DU, and configure or communicate with a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU. The SMO framework may interoperate with the TN Manager to migrate a transport path (e.g., terminating an existing transport path between the O-RU and the first O-DU and establishing a new transport path between the O-RU and the second O-DU), and then rehome the O-RU to the second O-DU thereafter. In this way, the first O-RU can be shut down (e.g., shut down for a short period, permanently shut down, etc.) for energy-saving purposes, eventually enhancing the O-DU power saving.

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

[0030] FIG. 1 illustrates a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1, the system configuration 100 includes a Service and Management Orchestration (SMO) framework 110, a Transport Network (TN) Manager 120, an Open Radio Access Network (O-RAN) Radio Unit (O-RU) 130, a Transport Network 140 (that may include one or more network nodes in the fronthaul, midhaul, and backhaul), a first O-RAN Distributed Unit (O-DU) 150-1 (illustrated as “O-DU#1” in FIG. 1), a second O-DU 150-2 (illustrated as “O-DU#2” in FIG. 1), an O-RAN Central Unit (O-CU) 160, and a Core Network 170. It is contemplated that the configuration in FIG. 1 is merely an example provided for descriptive purposes, and the scope of the present disclosure is not limited thereto. For instance, in some example implementations, more than two O-DUs may be involved, multiple O-RUs may be involved, the transport network 140 may be omitted and the communication between the O-DU(s) and the O-RU may be presented as being performed via an Open Front Haul (OFH) interface, and the like, without departing from the scope of the present disclosure.

[0031] The SMO framework 110 (may also be referred to as the “SMO 110” herein) may refer to a logical entity responsible for service management, end-to-end orchestration, and automation across the disaggregated RAN components (e.g., O-RU 130, O-DUs 150-1 to 150-2, O-CU 160, etc ). According to example embodiments, the SMO 110 may be implemented in the software form in one or more hardware components (e.g., servers, computing devices, etc.). In some example implementations, the SMO 110 may be constituted of various software components, such as a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) that manages or implements one or more modular applications (rApps), one or more SMO Services (SMOs) that handle or manage different SMO Functions (SMOFs) (e.g., power saving orchestration, inventory or policymanagement, etc.), and the like. Descriptions of various example SMOSs are provided below with reference to FIG. 5. In this regard, descriptions such as “the SMO framework may be configured to perform an operation” can be interpreted as “the SMO framework may be configured to implement at least one associated RIC / rApp / SMOS to perform the operation” and the like.

[0032] According to example embodiments, the SMO 110 may be configured to orchestrate the 0-DU power-saving process by consuming various data (e.g., operator-defined policies, Performance Measurement (PM) data, Fault Management (FM) data, Configuration Management (CM) data, network Key Performance Indicators (KPIs), network topology that indicates how the transport network is organized and connected, inventory information that indicates how many network components are interconnected, etc.), managing transport paths between the O-RU(s) and the O-DU(s), and coordinating with other RAN entities / network functions (e.g., O-CU, etc.).

[0033] As further described below, according to example embodiments, the SMO 110 may be configured to determine the status of an O-DU(s) and trigger the rehoming process to rehome the associated O-RU(s). In this regard, “rehoming” may refer to a procedure by which an O-RU(s) transport connectivity is reconfigured, reconnected, or reassociated from one 0-DU to another O-DU. For instance, the SMO 110 may determine a source O-DU(s) of which the status satisfies a first predefined condition (e.g., O-DU(s) that is underutilized, overloaded, having a software / hardware failure, having a maintenance planned, having an unexpected event, etc.) and a target O-DU(s) of which the status satisfies a second predefined condition (e.g., O-DU(s) that has sufficient resources to accommodate the O-RU(s) associated with the source O-DU(s), etc.). Accordingly, the SMO 110 may prepare and provide (to the TN Manager 120) an instruction, a trigger, a policy associated with power saving (“power-saving policy” herein), a configurationinformation associated with the power saving, an API call, or a command, each of which may include information or parameters associated with the rehoming process, (e.g., identifier of the O-RU(s) to be rehomed, identifier of the source O-DU(s), identifier of the target O-DU(s), bandwidth requirements, latency requirements, thresholds, activation / deactivation periods, etc.), thereby triggering a transport path migration process before rehoming the O-RU(s) to the target O-DU(s). As further described below, the transport path migration process may be managed by the TN Manager 120 to migrate the transport path(s) of the O-RU(s) from the source O-DU(s) to the target O-DU(s), and may include alternate transport path generation depending on one or more of the above-mentioned requirements, transport path cost, transport path characteristics, and the like. Upon completion of the transport path migration process, the SMO 110 may perform one or more operations (e.g., communicating and instructing the source O-DU(s), the O-CU(s), and / or the associated nodes) to shut down or decommission the source O-DU(s), thereby enhancing power saving for the source O-DU(s).

[0034] As illustrated in FIG. 1, the SMO 110 may communicatively couple to the TN Manager 120 via an 01 interface, an 02 interface, and / or any other suitable interfaces (e.g., interfaces that comply with the requirements from 3GPP, 0-RAN Alliance, IETF, ETSI, IEEE, etc.). Further, the SMO 110 may communicatively couple to each of the O-DUs 150-1 to 150-2, the O-CU 160, and the Core Network 170, via the 01 interface. In addition, the SMO 110 may communicatively couple to the 0-RU 130 via one or more OFH interfaces, such as the Management Plane (M-Plane) interface. These interfaces (e.g., 01, 02, OFH, etc.) may be consistent with those defined in one or more technical specifications of one or more standard organizations (e.g., the 0-RAN Alliance), which provide open protocols and interfaces between the SMO 110 and the underlying components (e.g., TN Manager 120, O-DUs 150-1 to 150-2, O-CU 160, etc.) and enable the SMO 110 and the underlying components to be developed or provided by different parties (e.g., different network operators, vendors, service providers, etc.). The TN Manager 120 may refer to a logical entity responsible for managing the Transport Network 140 (or one or more nodes associated therewith). For instance, the TN Manager 120 may receive (from the SMO 110) an instructions associated with configuration changes or a policy associated with 0-DU power saving (“power-saving policy” herein), and then communicate with the Transport Network 140 (or one or more nodes associated therewith) to perform or manage a transport path mitigation process based thereon. It is contemplated that the “TN Manager” is merely an example terminology and may be replaced with any other suitable terminology. For instance, in example implementations where the Transport Network 140 is an All Photonic Network (APN), the TN Manager may also be referred to as the “APN Manager,” “APN Orchestrator,” “APN Controller,” and the like.

[0035] The TN Manager 120 may be implemented externally from the SMO 110 (e.g., implemented as a separate management entity, a managed function, a proxy network, or a subnetwork, etc.), may be implemented within the SMO 110 (e.g., in the form of rApp, SMOF, SMOS, etc.), or a combination thereof. As illustrated in FIG. 1, the TN Manager 120 may communicate with the SMO 110 via the 01 interface, the 02 interface, and / or any other suitable interface (e.g., interfaces that comply with the requirements from 3GPP, 0-RAN Alliance, IETF, ETSI, IEEE, etc.). In some example embodiments, the communications between the SMO 110 and the TN Manager 120 may be performed in the form of an Application Programming Interface (API) call (via standardized API such as the REST API, etc ), a Remote Procedure Call (RPC) command, a Network Configuration Protocol (NETCONF) Yet Another Generation (YANG) model / operation, and the like. In this case, in addition to the 01 interface and 02 interface, the TNManager 120 may also communicate with the SMO 110 via an API (e.g., a Representational State Transfer (REST) API, etc ).

[0036] According to example embodiments, the TN Manager 120 may be configured to assist the SMO 110 in orchestrating the transport path changes, thereby ensuring the seamless execution of the 0-DU power-saving process. As further described below, the TN Manager 120 may be configured to communicate with the SMO 110 (or at least one rApp / SMOF / SMOS associated therewith) and manage the Transport Network 140 (e.g., terminate / tear down a transport path, establish a transport path, determine a potential or alternative transport path, etc.) based on the communications. In some example implementations, the TN Manager 120 may receive an instruction or a power-saving policy from the SMO 110, and then perform or manage a transport path migration process based thereon. For instance, the TN Manager 120 may determine an alternative transport path(s) for connecting the O-RU(s) with the target O-DU(s), and may communicate with the Transport Network 140 (or one or more nodes associated therewith) to migrate or shift the O-RU(s) from the existing transport path(s) between the O-RU(s) and the source O-DU(s) to the alternative transport path(s). In this regard, the alternative transport path(s) may be an existing transport path(s) between the O-RU(s) and another O-DU(s), between another O-RU(s) and another O-DU(s), or a combination thereof. Alternatively or additionally, the alternative transport path(s) may be a new transport path(s) established between the O-RU(s) and the target O-DU(s). As further described below, the Transport Network 140 may include various types of networks, such as an All Photonic Network (APN), an Ethernet Network, an Internet Protocol (IP) Network, a Multi -Protocol Label Switching (MPLS) network, and the like. In this regard, it is contemplated that the TN Manager 120 may be able to manage any suitable type of the Transport Network 140, irrespective of underlying Physical transport networks.

[0037] The O-RU 130 may include one or more network components (e.g., Power Amplifiers (PAs), Radio Frequency (RF) transceivers, processing units, etc.) that handle or manage Physical (PHY) layer operations, such as transmitting and receiving Radio Frequency (RF) signals over the air interface, converting RF signals to digital signals, performing power amplifications, and the like. According to example embodiments, the O-RU 120 may house or manage one or more transceiver (TRX) arrays, each of which may include a set of RF chains associated with antenna elements and responsible for communicating with the end user’s device (e g., user equipment (UE), etc.) over the air on one or more carriers. Further, the O-RU 120 may include one or more physical nodes or network components that convert radio signals (from antennas) to digital signals that can be transmitted over the OFH interface(s) to the O-DUs via the Transport Network 140.

[0038] The Transport Network 140 may refer to the physical and logical transport frameworks constituted by various Transport Network Elements (TNEs), such as server nodes, switches, routers, wirings, and the like, that constitutes one or more transport paths (may also be referred to as “transport tunnels” or “connections”) that transport traffic or signals between the O-RU 130 and the plurality of O-DUs 150-1 and 150-2. According to example embodiments, the Transport Network 140 may include an All Photonic Network (APN) that implements optical transport fabric and utilizes optical or photonic technologies, such as wavelength divisional multiplexing (WDM), optical switches, optical multiplexers, and the like, to transport traffic or signals without electrical conversion. Further, the Transport Network 140 may include any other suitable type of networks, such as an Ethernet Network, an Internet Protocol (IP) Network, a Multiprotocol Label Switching (MPLS) network, and the like. Additionally or alternatively, the Transport Network 140 may include a Software Defined Transport Network (SDTN) that enablesunderlying physical components (e.g., server nodes, etc.) to communicate with the northbound components (e.g., SMO 110, TN Manager 120, etc.) via one or more APIs and perform one or more operations to manage the transport paths (e.g., establish a new transport path, tear down an existing transport path, etc.) based on the communications. As further described below, in some example embodiments, the TN Network 140 may include at least one edge node that is located nearby the O-RU 130, at least one edge node that is located nearby the O-DUs 150-1 and / or 150-2, and at least one core node that is located between two edge nodes.

[0039] The O-DUs 150-1 to 150-2 may refer to the logical nodes that may be configured to host Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The O-DUs 150-1 to 150-2 may communicatively couple to the O-CU 160 via the Fl interface, and to the SMO 110 via the 01 interface. For descriptive purposes, it may be assumed that in the example configuration of FIG. 1, the first O-DU 150-1 is a source O-DU to which the O-RU 130 is originally connected, while the second O-DU 150-2 is a target O-DU to which the O-RU 130 may be rehomed.

[0040] The O-CU 160 may refer to the logical node configured to host Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. In some example implementations, the O-CU 160 may include an O-CU Control Plane (O-CU-CP) that handles control plane-related operations (e.g., RRC and PDCP control plane signaling, etc.) and an O-CU User Plane (O-CU-UP) that handles user plane-related operations (e.g., PDCP user plane and SDAP signaling, etc.).

[0041] According to example embodiments, the O-DUs and / or the O-CU may be implemented in the software form (e.g., Virtualized Network Function (VNF), Cloud-Native / Containerized Network Function (CNF), etc.), and the like. In this regard, it may beunderstood that the “O-DU’ and “O-CU” described herein may refer to the respective component in the software form, the hardware component or apparatus (e.g., computing device, server, etc.) that implements the software form of the respective component, or a combination thereof. According to example embodiments, one or more of the O-DUs and / or the O-CU may be implemented in one or more Regional Data Centers (RDCs), one or more Centralized Data Centers (CDCs), or a combination thereof.

[0042] The Core Network 170 may refer to the centralized node that manages and provides various control-plane and user-plane functions, such as access and mobility management, session management, user plane management, and the like. The Core Network 170 may include, for example, a 5G Core (5GC), a 4G Evolved Packet Core (EPC), and any other suitable types of core networks. In some example embodiments, the Core Network 170 may connect to a variety of external networks or services, and then obtain and provide data associated therewith to the underlying components.

[0043] According to example embodiments, a first transport path may be established between the first O-DU 150-1 and the O-RU 130, thereby enabling the O-RU 130 to communicate with the O-CU 160 and the Core Network 170 via the first transport path. The SMO 110 may continuously (or periodically) collect or receive data (e.g., operator-defined policies, PM data, CM data, FM data, network KPIs, etc.) from the RAN entities / network functions (e.g., O-RU 130, O-DUs 150-1 to 150-2, O-CU 160, etc.) via the respective interface (e.g., 01 interface, OFH interface, etc.), and then analyze the collected / received data to assess the status (e.g., resource utilization, overloading, failure, etc.) of the underlying components.

[0044] Accordingly, assuming that the SMO 110 determines that a first predefined condition associated with the first O-DU 150-1 is satisfied (e.g., utilization of resources like CPU,memory, and / or input / output (I / O) falls below a predefined threshold, an overloading / risk of overloading is detected, a failure / risk of failure is detected, a planned maintenance like software update is detected, etc.), the SMO 110 may determine whether a second predefined condition associated with the second O-DU 150-2 is satisfied (e.g., whether the second 0-DU 150-2 have sufficient resources to accommodate or serve the O-RU 130, etc.). If the SMO 110 determines that the second predefined condition is satisfied, the SMO 110 may determine that the O-RU 130 can be rehomed from the first O-DU 150-1 to the second O-DU 150-2. Thus, the SMO 110 may trigger the rehoming process and configure the TN Manager 120 to rehome the O-RU 130 from the first O-DU 150-1 to the second O-DU 150-2.

[0045] For instance, the SMO 110 may interact with the TN Manager 120 (e.g., via one or more APIs) to migrate the transport paths (e.g., terminate the first transport path, establish a second transport path between the O-RU 130 and the second O-DU 150-2, etc.). Further, the SMO 110 may interact with the first O-DU 150-1 and the O-CU 160 to deactivate a first cell associated with the first O-DU 150-1 and / or remove network resources (e g., carrier resources, etc.) associated with the first cell, and interact with the second O-DU 150-2 and the O-CU 160 to activate a second cell associated with the second O-DU 150-2 and / or activate network resources (e.g., carrier resources, etc.) associated with the second cell. In this way, the O-RU 130 (which is initially communicating with the first O-DU 150-1) can be efficiently and effectively rehomed to the second O-DU 150-2, and the SMO 110 may then shut down (e.g., power down) or decommission the first O-DU 150-1 (e.g., the underutilized O-DU, the O-DU that has failed or having a risk of failure, etc.), thereby optimizing the power consumption of the first O-DU 150-1 and enhancing power saving thereof.

[0046] Upon completion of the rehoming process, the SMO 110 may be configured to monitor the status of the O-DUs (e.g., by monitoring the associated data such as the FM data, PM data, CM data, etc.) for at least a predefined period of time, and may orchestrate the TN Manager 120 and the RAN entities / network functions (e.g., O-RU 130, O-DUs 150-1 and 150-2, O-CU 160, etc.) to coordinately implement another rehoming process to restore the O-RU 130 to the first O-DU 150-1 (e.g., power up the first 0-DU 150-1, establishing a transport path between the O-RU 130 and the first 0-DU 150-1, activate the cell(s) and associated network resources for the first O-DU 150-1, etc.) when applicable (e.g., during high traffic / peak hour, when the failure / risk of failure of the first O-RU 150-1 is mitigated, when the planned maintenance on the first O-RU 150-1 is completed, etc.).

[0047] In view of the above, example embodiments provide systems, configurations, devices, and the like, that effectively and efficiently enhance the power saving of an 0-DU, and ultimately optimize the O-RAN power consumption. Specifically, example embodiments implement an SMO framework that interoperate with a TN Manager and various RAN entities / network functions to effectively and efficiently rehome an O-RU(s) from a source O-DU(s) to a target O-DU(s), thereby allowing the source O-DU(s) to be shut down or decommissioned and optimizing the power consumption of the source O-DU(s).

[0048] For instance, the SMO framework may continuously (or periodically) monitor the status of the O-DUs in real-time or near-real-time, thereby enabling timely detection of O-DU(s) that can be shut down / decommissioned by rehoming the associated O-RU(s) to another O-DU(s). Accordingly, the SMO framework may interoperate with the TN Manager to appropriately manage the transport paths involved in the rehoming process, and then interoperate with the associated RAN entities / network functions (e.g., source O-DU(s), target O-DU(s), O-CU(s), etc.) to managethe cells and network resources involved in the rehoming process, thereby effectively migrating the traffic or signals of the O-RU(s) from the source O-DU(s) to the target O-DU(s). Advantageously, by implementing the example embodiments, the rehoming of O-RU(s) may be performed effectively and efficiently to aggregate the traffic or signals of the source O-DU(s) to the target O-DU(s), thereby enabling the source O-DU(s) to be shut down / decommissioned and optimizing the power-saving opportunities of the O-DU(s)

[0049] Further descriptions of example methods and operations of example embodiments are provided below with reference to FIG. 2 to FIG. 3, descriptions of several example use cases are provided below with reference to FIG. 4A to FIG. 6C, and descriptions of an example device and an example environment for implementing one or more example embodiments are provided below with reference to FIG. 7 to FIG. 8, respectively.Example Methods and Operations

[0050] As described above with reference to FIG. 1, the SMO framework may interoperate with the underlying components (e g., TN Manager, O-RU, O-DUs, O-CU, etc.) and perform one or more methods and operations to enhance O-DU power saving. Several example methods and operations are described below with reference to FIG. 2 to FIG. 3. One or more features, parameters, and operations associated with FIG. 2 to FIG. 3 may be similar to those described above with reference to FIG. 1 and may involve one or more components in FIG. 1, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0051] For descriptive purposes, the methods and operations may be mainly described herein as being performed by one or more specific network components, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure. For instance,an operation of the SMO framework providing a data / message to the TN Manager may suggest or indicate an operation of the TN Manager receiving the data / message from the SMO framework, and the like.

[0052] According to example embodiments, one or more operations of an SMO framework (or a RIC / rApp / SMOF / SMOS associated therewith) may be implemented in one or more apparatuses or hardware components. For instance, the SMO framework (or one or more associated operations) may be implemented in an apparatus / device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations of the SMO framework.

[0053] FIG. 2 illustrates a first example method 200, according to one or more example embodiments. One or more operations in method 200 may be performed by an SMO framework (e.g., SMO framework 110) or at least one RIC, rApp, SMOF, or SMOS associated therewith.

[0054] As illustrated in FIG. 2, at operation S210, the SMO framework may be configured to determine whether an O-RU (e.g., O-RU 130) can be rehomed from a first O-DU (e.g., O-DU 150-1) to a second O-DU (e.g., O-DU 150-2). Descriptions of example operations for determining whether the O-RU can be rehomed are provided below with reference to FIG. 3.

[0055] If the SMO framework determines that the O-RU can be rehomed from the first O-DU to the second O-DU, method 200 may proceed to operation S220. Otherwise, method 200 may be terminated, or alternatively, method 200 may be restarted such that the SMO framework may be configured to repeat operations S210 for at least a predefined period of time.

[0056] At operation S220, the SMO framework may be configured to communicate with or configure a TN Manager (e.g., TN Manager 120) to rehome the O-RU from the first O-DU tothe second O-DU. For instance, the SMO framework may perform a API call to the TN Manager to terminate a first transport path between the O-RU and the first DU, and then perform a second API call to the TN Manager to establish a second transport path between the O-RU and the second O-DU. The TN Manager may be implemented externally from the SMO framework, or may be implemented as an SMO Service (SMOS) or an SMO Function (SMOF) within the SMO framework. Thus, the SMO framework may communicate with the TN Manager via the 01 interface, 02 interface, an interface that may be based on one or more technical requirements from one or more standard organizations (e.g., 3GPP, 0-RAN Alliance, IETF, ETSI, IEEE, etc.) that may be utilized to manage the transport networks in various stages, an API (e.g., standardized API such as the REST API, etc.), an RPC command, a NETCONF YANG model / operation, or any other suitable interfaces. In some example implementations, the SMO framework may prepare a power-saving policy (e g., create a new policy, update an existing policy, etc.) that includes information associated with the rehoming process, such as information on the associated RAN entities / network functions (e.g., information of the target O-RU, the target O-DU, the source O-DU, etc.), information on the rehoming requirements (e.g., conditions / thresholds defined by the network operator, etc.), and any other suitable information that may be consumed or utilized by the TN Manager to manage the transport path(s) during the rehoming process.

[0057] According to some example embodiments, prior to performing the first API call, the SMO framework may perform at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell. For instance, the SMO framework may instruct an O-CU (e.g., O-CU 160) via the 01 interface to deactivate the first cell and / or instruct the first O-DU via the 01 interface to remove network resources (e.g., carrier resources, etc.) associated with the first cell. Alternatively or additionally, prior to performing thesecond API call, the SMO framework may perform at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell. For instance, the SMO framework may instruct the O-CU via the 01 interface to activate the second cell and / or instruct the second O-DU via the 01 interface to activate network resources (e g., carrier resources, etc.) associated with the second cell.

[0058] Referring next to FIG. 3, which illustrates a second example method 300, according to one or more example embodiments. Similar to method 200, one or more operations in method 300 may be performed by an SMO framework (e g., SMO framework 110) or at least one RIC, rApp, SMOF, or SMOS associated therewith. For instance, one or more operations in method 300 may be similar to or a part of operation S210 in method 200, and may be performed by the SMO framework to determine whether an 0-RU (e.g., 0-RU 130) can be rehomed from a first O-DU (e g., O-DU 150-1) to a second O-DU (e g., O-DU 150-2). Method 300 may be initiated while assuming that the SMO framework has received or collected data (e.g., PM data, FM data, CM data, network KPIs, a policy defined or provided by a network operator to trigger the rehoming process, etc.) from the underlying components (e.g., O-RU 130, O-DUs 150-1 to 150-2, O-CU 160, etc.) via the respective interface (e.g., 01 interface, OFH interface, etc.).

[0059] As illustrated in FIG. 3, at operation S310, the SMO framework may be configured to determine whether a first predefined condition associated with the first O-DU is satisfied. For instance, the SMO framework may be configured to analyze one or more collected / received data (e.g., PM data, FM data, CM data, network KPIs, etc.) to assess the status (e.g., resource utilization, overloading, failure, etc.) of the first O-DU. In this regard, the first predefined condition may include one or more of: an underutilization (or a risk of underutilization) of the first O-DU is detected (e.g., utilization of resources like CPU and memory of the first O-DU falls below a firstpredefined threshold, etc.), an overloading (or a risk of overloading) of the first O-DU is detected (e.g., utilization of resources like CPU and memory of the first O-DU falls exceeds a second predefined threshold, etc.), a failure (or a risk of failure) of the first O-DU is detected (e.g., abnormal performance and / or network KPI is detected, etc.), and a planned maintenance on the first O-DU is detected (e.g., scheduled configuration changes is detected, etc ).

[0060] If the SMO framework determines that the first predefined condition is not satisfied, method 300 may proceed to operation S340, at which the SMO framework may determine that the O-RU cannot (or does not need to) be rehomed. On the other hand, if the SMO framework determines that the first predefined condition is satisfied, method 300 may proceed to operation S320, at which the SMO framework may be configured to determine whether a second predefined condition associated with the second O-DU is satisfied. For instance, the SMO framework may be configured to analyze the one or more collected / received data (e.g., PM data, FM data, CM data, network KPIs, etc.) to assess the status (e.g., resource utilization, overloading, failure, etc.) of the second O-DU. In this regard, the second predefined condition may include a condition at which the second O-DU has sufficient resources to accommodate the O-RU (e.g., the second O-DU has sufficient resources like CPU and memory to handle the traffic of the O-RU without service degradation, etc.).

[0061] If the SMO framework determines that the first predefined condition is not satisfied, method 300 may proceed to operation S340, at which the SMO framework may determine that the O-RU cannot be rehomed to the second O-DU. In some example embodiments, the SMO framework may repeat operations S320 to determine whether the O-RU can be rehomed to a third O-DU (e.g., whether a third predefined condition is satisfied), a fourth O-DU (e.g., whether a fourth predefined condition is satisfied), and the like, in a similar manner, thereby determining anO-DU to which the O-RU can be rehomed. On the other hand, if the SMO framework determines that the second predefined condition is satisfied, method 300 may proceed to operation S330, at which the SMO framework may determine that the O-RU can be rehomed from the first O-DU to the second O-DU.

[0062] In view of the above, example embodiments provide methods and operations that effectively and efficiently enhance O-DU power saving. Advantageously, method and operations in FIG. 2 may be automatically implemented by an SMO framework to trigger a rehoming process to rehome an O-RU from a first O-DU (e.g., a source O-DU) to a second O-DU (e.g., a target O-DU), thereby aggregating the traffic or signals of the O-RU at the second O-DU and enabling the shutdown / decommissioning of the first O-DU to optimize the power saving opportunities. Further, method and operations in FIG. 3 may be automatically implemented by the SMO framework to accurately determine whether an O-RU can be rehomed, thereby ensuring seamless implementation of the rehoming process of the O-RU (e.g., situations where the target O-DU(s) do not have sufficient resources to accommodate the O-RU can be avoided).

[0063] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 2 to FIG. 3 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 2 to FIG. 3 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it can be understood that the example embodiments of FIG. 2 to FIG. 3 may achieve similar technical advantages and significance described above with reference to FIG. 1, since the methodsand operations in FIG. 2 and FIG. 3 may be implemented in the system configuration and devices in FIG. 1.Example Use Cases

[0064] Various example use cases, in which the system configurations, apparatuses, methods, and operations in FIG. 1 to FIG. 3 may be involved, are described below with reference to FIG. 4A to FIG. 6C.

[0065] Referring first to FIG. 4A and FIG. 4B, which illustrate a system configuration of a first example use case 400, according to one or more example embodiments. In example use case 400, the disaggregated RAN components illustrated in FIG. 1 may be implemented in different sites.

[0066] For instance, three O-RUs 430-1 to 430-3 (each of which may be similar to the O-RU 130 in FIG. 1) may each be implemented at Sites A-C, respectively. In this regard, each of the Sites A-C may refer to the physical cell sites where the O-RUs’ physical components (e.g., antenna, PA, etc.) are implemented, such as macro cell towers, small cell cabinets, distributed antenna system (DAS), and the like.

[0067] On the other hand, Site D may include a centralized management facility (e.g., a Network Operation Center (NOC), central data center, etc.) that implements the SMO 410 (which may be similar to the SMO 110 in FIG. 1), the Transport Network (TN) Manager 420 (which may be similar to the TN Manager 120 in FIG. 1), and the Core Network 470 (which may be similar to the Core Network 170 in FIG. 1). The SMO 410 may include a RIC 411 and a plurality of SMO services. In some example implementations, a group of SMO services may be collectively referred to as an SMO Function (SMOF) and may be collectively configured to perform one or more operations described herein.

[0068] Further, the O-DUs 450-1 to 450-3 (which may be similar to the O-DUs 150-1 to 150-2 in FIG. 1) may each be implemented at Sites E-G, respectively. In this regard, each of the Sites E-G may refer to an edge computing facility (e.g., a regional office / data center, an edge data center, an edge cloud facility, etc.). Furthermore, Site H may include a central computing facility (e g., a central office / data center, etc.) that implements the O-CUs 460-1 to 460-3 (each of which may be similar to the O-CU 160 in FIG. 1).

[0069] The Transport Network 440 (which may be similar to the Transport Network 140 in FIG. 1) may be logically and / or physically located between Sites A-C and Sites E-G, thereby providing or forming various transport paths for connecting one or more of the O-RUs 430-1 to 430-3 to one or more of the O-DUs 450-1 to 450-3. The Transport Network 440 may include a first Edge Node 441, a Core Node 442, and a second Edge Node 443. The first Edge Node 441 may be a fronthaul node that is located close to Sites A-C and may be configured to aggregate the traffic or signals from the O-RUs 430-1 to 430-3. In some example embodiments, the first Edge Node 441 may include multiple edge nodes, each of which may be located at (or close to) each of the Sites A-C and may be configured to collect the traffic or signals from the respective O-RU. The Core Node 442 may be the midhaul node that is located between the first Edge Node 441 and the second Edge Node 443, and may be configured to route the traffic or signals from the first Edge node 441 to the second Edge Node 443. The second Edge Node 443 may be the backhaul node that is located close to Sites E-G and may be configured to receive the traffic or signals from the Core Node 442 and distribute the same to one or more of the O-DUs 450-1 to 450-3. In some example embodiments, the second Edge Node 443 may include multiple edge nodes, each of which may be located at (or close to) each of the Sites F-G and may be configured to route the traffic or signals to the respective 0-DU. One or more of the nodes 441-443 of the Transport Network 440may include components such as routers, switches, servers, wiring, and the like, that may be selectively activated or powered on (according to instructions from the Transport Network Manager 420) to thereby establish a transport path between an 0-RU and an O-DU, and may be selectively deactivated or powered down to thereby tear down a transport path between an O-RU and an O-DU.

[0070] In the example of FIG. 4A, it may be assumed that all of the O-DUs 450-1 to 450-3 in Sites E-G and all of the O-CUs 460-1 to 460-3 in Site H are activated and utilized for carrying the traffic or signals from the O-RUs 430-1 to 430-3 in Sites A-C. As illustrated in FIG. 4A, three transport paths X-Z are established to handle the traffic or signals from O-DUs 430-1 to 430-3, respectively. Each of the O-RUs, O-DUs, and O-CUs may continuously (or periodically) report the associated data (e.g., PM data, FM data, CM data, network KPIs, etc.) to the SMO 410 (or the RIC 411 and / or SMO Services 412 associated therewith). The SMO 410 may be configured to implement (or may configure the RIC 411 and / or SMO Services 412 to implement) the operations in methods 200 and 300 (in FIG. 2 and FIG. 3, respectively) to trigger a rehoming process when applicable.

[0071] FIG. 4B illustrates an example scenario of example use case 400, according to one or more example embodiments. Specifically, FIG. 4B illustrates an example scenario where the SMO 410 (or the associated RIC 411 and / or SMO Services 412) determines that O-RUs 430-2 and 430-3 can be rehomed to O-DU 450-1 (e.g., the source O-DUs 450-2 and 450-3 associated therewith are underutilized / overloaded / experiencing a failure, the O-DU 450-1 is capable to accommodate both O-RUs 430-2 and 430-3, etc.) and configures the Transport Network Manager 420 to rehome the O-RUs 430-2 and 430-3 accordingly.

[0072] According to example embodiments, the SMO 410 (or the associated RIC 411 and / or SMO Services 412) may provide (to the Transport Network Manager 420) a power-saving policy that may include information of the target O-DU (e.g., O-DU 450-1), the source O-DUs (e.g., O-DUs 450-2 and 450-3), and the associated O-RU (e.g., O-RUs 430-2 and 430-3). Accordingly, the Transport Network Manager 420 may determine, based on the policy (and real-time / near-real-time conditions of the transport network 440, if applicable), an appropriate transport path for rehoming the O-RUs. For instance, the Transport Network Manager 420 may determine that transport path X (i.e., the transport path established between the O-RU 430-1 and the O-DU 450-1) is suitable to be utilized as the new transport path for the O-RUs 430-2 and 430-3, may determine that an establishment of a new transport path W is required (e.g., the transport path X is not capable of accommodating both O-RUs 430-2 and 430-3, etc.), and the like. Accordingly, upon receiving (from the SMO 410 and / or the associated RIC 411 / SMO Services 412) the instructions for rehoming the O-RUs 430-2 and 430-3, the Transport Network Manager 420 may configure or instruct the Transport Network 440 (or the nodes 441-443 associated therewith) to tear down the transport paths Y and Z (in FIG. 4A) and then shift the traffic or signals of O-RUs 430-2 and 430-3 to transport path X (and / or establish the new transport path W, if applicable). In this way, the traffic or signals of all O-RUs may be aggregated to Site E (and the associated O-DU), and Sites F-G (or the associated O-DUs) may be shut down or decommissioned, thereby enhancing the power saving on the O-DUs 450-2 and 450-3 without affecting the operations of O-RUs 430-2 and 430-3. In addition, the associated O-CUs (e.g., O-CUs 460-2 and 460-3) may also be shut down or enter idle mode, thereby further enhancing the overall power saving of the network.

[0073] It is contemplated that the configuration in FIG. 4A and FIG. 4B is merely an example and the scope of the present disclosure should not be limited thereto. Specifically,more / less components than as illustrated may be involved, and / or the illustrated components may be arranged in any other suitable manner, without departing from the scope of the present disclosure. For instance, in some example implementations, one or more of the Sites A-H may include a Telecom Time Slave Clock (T-TSC), a Layer-2 Switch (L2SW) Telecom Grandmaster (T-GM), a Global Positioning System (GPS) device, and the like, which may be utilized by the respective components (e.g., O-RU, O-DU, O-CU, etc.) to synchronize the clocks and timings.

[0074] Referring next to FIG. 5, which illustrates a second example use case 500, according to one or more example embodiments. Specifically, example use case 500 illustrates an example configuration of a cloud-native deployment that involves a Decoupled SMO Architecture and various O-RAN entities / network functions.

[0075] As illustrated in FIG. 5, example use case 500 may include an SMO 510, a TN Manager 520, an O-RU 530, a Transport Network 540, an O-DU 551, and an O-CU 552, each of which may be similar to the respective component described above with reference to FIG. 1 to FIG. 4B. Thus, it is contemplated that similar features, mechanisms, operations, configurations, data, and the like, described above with reference to FIG. 1 to FIG. 4B may be similarly applicable to example use case 500, and redundant descriptions associated therewith may be omitted below for conciseness. In addition to the described components, example use case 500 also involves an O-Cloud 550 and a Network Operator Equipment 560.

[0076] The O-Cloud 550 may be a collection of physical nodes 555 that may be configured to host the O-DU 551, O-DU 552, an Infrastructure Management Service (IMS) 553, a Deployment Management Service (DMS) 554, the supporting software components (e g., the operating systems and runtime environments), and in some example implementations, the SMO 510. In such a configuration, the SMO 510 may manage the O-Cloud 550 from within.

[0077] The SMO 510 may include various types of SMO Service (SMOS), such as a Power Saving (or Energy Saving) Orchestration SMOS 511, a RAN Network Function (NF) Operations, Administrations, and Maintenance (0AM) SMOS 512, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS 513, an NF Orchestration (NFO) SMOS 514, and an SMOS 515 for policy-related information management.

[0078] Generally, the SMOS 515 may communicate with the Network Operator Equipment 560 (e.g., mobile device, static device, etc.) via, for example, one or more APIs, and receive configuration or information associated with power-saving policy configuration (e.g., threshold, activation / deactivation period, conditions, contextual data, etc.) therefrom. The SMOS 515 may also be configured to manage (e.g., add, update, delete, etc.) the policy and the associated information, and provide the same to the SMOS 511 when applicable. The SMOS 515 may serve as the centralized repository or management entity for the operator-defined policies and the associated information, thereby providing the SMOS 511 with accurate and updated policy information for optimized, policy-driven power-saving (e g., rehoming, etc.) decisions.

[0079] The SMOS 512 may communicate with the RAN components / functions (e.g., O-RU 530, 0-DU 551, O-CU 552, etc.) via the respective interface (e.g., OFH, 01, etc.) and periodically (or continuously) collect / receive data associated therewith (e.g., PM data, FM data, CM data, network KPIs, etc.). The SMOS 512 may also be configured to manage the collected / received data and provide the same to the SMOS 511 when applicable, thereby providing the SMOS 511 with the latest information associated with the status of the RAN components / functions, in real-time, near-real-time, and / or non-real-time.

[0080] The SMOS 513 may communicate with the IMS 553 via the 02 interface. When the SMOS 511 decides to activate / deactivate a cell(s) or the associated resources for a specific O-DU via modifying or orchestrating the infrastructure or resources (e.g., 0-DU 551, O-CU 552, node 555, etc.) of the O-Cloud 550, the SMOS 513 may be configured to provide the associated instruction(s) to the IMS 553, thereby enabling the IMS 553 to modify or orchestrate the associated infrastructure or resources of the O-Cloud 550. Namely, SMOS 513 may interoperate with the IMS 553 to activate / deactivate a cell(s) or the associated resources for a specific 0-DU via modifying or orchestrating the infrastructure or resources of the O-Cloud 550.

[0081] The SMOS 514 may communicate with the DMS 554 via the 02 interface. When the SMOS 511 decides to activate / deactivate a cell(s) or the associated resources for a specific O-DU, the SMOS 514 may be configured to provide the associated instruction(s) to the DMS 554, thereby enabling the DMS 554 to control the node 555 to deploy / decommission the cell(s) or the associated resources (e.g., scaling out / in, deploying new 0-DU worker processes or instances, decommissioning existing 0-DU worker processes or instances, temporarily stopping the 0-DU worker processes or containers, etc.). Namely, SMOS 514 may interoperate with the IMS 554 to provide lifecycle management (e.g., deployment, decommission, temporary shutdown, etc.) on a specific 0-DU (and the associated resources and cells).

[0082] The SMOS 511 may serve as the central entity that communicates with the SMOSs 512-515, collect / receive data from the SMOS 512-515, and make decisions for enhancing 0-DU power saving. For instance, the SMOS 511 may continuously (or periodically) collect or receive data from the SMOS 512 and SMOS 515 (e.g., at step 1), and then determine whether the 0-RU 530 can be rehomed and an associated O-DU 551 can be shut down / enter to idle mode (e.g., at step 2). Accordingly, based on determining that the O-RU 530 can be rehomed, the SMOS 511 may communicate with the TN Manager 520 (e.g., via one or more API calls, RPC commands, NETCONF YANG operations, etc.) to perform automated rehoming procedure (at step 3).Alternatively or additionally, the rehoming procedure at step 3 may also be triggered by an associated user (e.g., a network operator, etc.). In this regard, the TN Manager 520 may communicate with the Transport Network 540 (or one or more nodes associated therewith) and manage one or more transport paths (if required) to fulfill the rehoming requirements. Accordingly, once the TN Manager 520 receives a transport path migration request from the SMOS 511, the TN Manager 520 may tear down the old transport path(s) and establish the new transport path(s) for rehoming the O-RU 530. On the other hand, the SMOS 511 may issue a node control command to the IMS 553 (via the SMOS 513) to modify / orchestrate the O-Cloud infrastructure / resources of the associated O-DUs, and / or may issue a lifecycle management (LCM) control command to the DMS 554 (via the SMOS 514) to perform lifecycle management operations on the associated O-DUs.

[0083] Referring next to FIG. 6A to FIG. 6C, which illustrate a third example use case 600, according to one or more example embodiments. Example use case 600 may involve one or more RAN entities / network functions, as well as the associated mechanisms, operations, data, and the like, described above with reference to FIG. 1 to FIG. 5. For instance, as illustrated in FIG. 6A to FIG. 6C, example use case 600 may involve an SMO 610, a TN Manager 620, an O-CU 660, at least one O-RU 630, a first 0-DU 650-1, and a second 0-DU 650-2, each of which may be similar to the respective components described above with reference to FIG. 1 to FIG. 5, and thus the detailed descriptions associated therewith may be omitted below for conciseness.

[0084] Generally, FIG. 6A illustrates a flow diagram associated with the SMO decisionmaking for triggering a rehoming process. FIG. 6B illustrates a flow diagram associated with the cell(s) deactivation and corresponding resources removal, during the rehoming process. FIG. 6C illustrates a flow diagram associated with the cell(s) activation and corresponding resourcesactivation, during the rehoming process. The first operation / initial step in FIG. 6B may be performed or triggered subsequent to the last operation / final step in FIG. 6A, while the first operation / initial step in FIG. 6C may be performed or triggered subsequent to the last operation / final step in FIG. 6B.

[0085] Referring first to FIG. 6A, example use case 600 may be triggered while assuming that the precondition (e.g., the SMO has subscribed to FM, PM, and CM data from the O-DUs and O-CU (or the associated O-CU-CP) via the 01 interface, and from the 0-RU via the OFH (e.g., M-Plane), etc.) is satisfied. In some example implementations, the SMO 610 may also be configured to collect / receive the FM, PM, and CM data from the transport network via the TN Manager 620. Namely, it may be assumed that the SMO 610 has collected / received the FM, PM, and CM data from the O-DUs, O-CU, 0-RU, and / or the transport network, prior to the first operation / initial step of example use case 600.

[0086] As illustrated in FIG. 6 A, as step 1, the SMO 610 may consume the collected / received data (e g., FM data, PM data, CM data, etc.) to analyze the resource utilization of the first O-DU 650-1. Similarly, at step 2, the SMO 610 may consume the collected / received data (e.g., FM data, PM data, CM data, etc.) to analyze the resource utilization of the second O-DU 650-2. Assuming that the first O-DU 650-1 is underutilized (e.g., the resource usage falls below a specific threshold, such as 20% of CPU, memory, or I / O capacity, etc.) and the second O-DU 650-2 can accommodate the O-RU(s) 630, at step 3, the SMO 610 may decide to rehome the O-RU(s) 630 from the first O-DU 650-1 to the second O-DU 650-2. Accordingly, at step 4, the SMO 610 may trigger the rehoming process and prepare a power-saving policy that includes information or parameters associated with the rehoming process, (e.g., identifier of the O-RU(s) to be rehomed, identifier of the source O-DU(s), identifier of the target O-DU(s) to which the O-RU(s) will be rehomed, operator-defined conditions such as the bandwidth requirements, latency requirements, thresholds, and activation / deactivation periods, etc.). Accordingly, at step 5, the SMO 610 may trigger one or more API calls (via the 01 interface, 02 interface, and / or any other suitable interfaces) to provide the policy (prepared at step 4) to the TN Manager 620. Subsequently, the TN Manager 620 may utilize the policy (or the information / parameters included therein) to determine one or more transport paths for provisioning the rehoming process.

[0087] Referring next to FIG. 6B, at step 6, the SMO 610 may communicate (via the 01 interface) with the O-CU 660 (or an O-CU-CP associated therewith) to deactivate and remove the cell(s) associated with the first 0-DU 650-1. Similarly, at step 7, the SMO 610 may communicate (via the 01 interface) with the first 0-DU 650-1 to remove the cell(s) associated with the first O-DU 650-1 and the corresponding carrier(s) resources. Accordingly, at step 8, the first 0-DU 650-1 may apply or update the associated cell(s) configuration, and then provide an update message / notification to the O-CU 660 (or the associated O-CU-CP) via the Fl interface. Further, at step 9, the SMO 610 may trigger one or more API calls (via the 01 interface, 02 interface, and / or any other suitable interfaces) to instruct or notify the TN Manager 620 to perform path termination (e.g., terminating the transport path(s) or connection(s) between the O-RU(s) 630 and the first 0-DU 650-1).

[0088] Furthermore, at step 10, the first 0-DU 650-1 may communicate (via the OFH interface, such as the M-Plane, etc.) with the O-RU(s) 630 to deactivate and remove the associated carrier resources (e.g., TRX array carrier(s), etc.). Accordingly, at step 11, the first 0-DU 650-1 may communicate with the SMO 610 (via the 01 interface) to provide an update notification regarding the status of the associated cell(s) and the corresponding carrier(s) resources. Similarly, at step 12, the O-CU 660 may communicate with the SMO 610 (via the 01 interface) to providean update notification regarding the status of the cell(s) associated with the first 0-DU 650-1. At this stage, the SMO 610 may determine that the cell(s) and corresponding resources associated with the first 0-DU 650-1 have been deactivated and removed. Thus, at step 13, the SMO 610 may trigger one or more API calls (via the 01 interface, 02 interface, and / or any other suitable interfaces) to instruct or notify the TN Manager 620 to tear down the transport path(s) or connection(s) between the O-RU(s) 630 and the first 0-DU 650-1. Accordingly, the TN Manager 620 may perform one or more operations (e.g., communicating and instructing one or more nodes of the associated transport network, etc.) to tear down the transport path(s) or connection(s) between the O-RU(s) 630 and the first 0-DU 650-1.

[0089] Referring next to FIG. 6C, at step 14, the SMO 610 may trigger one or more API calls (via the 01 interface, 02 interface, and / or any other suitable interfaces) to instruct or notify the TN Manager 620 to establish a transport path(s) or connection(s) between the O-RU(s) 630 and the second 0-DU 650-2. Accordingly, the TN Manager 620 may perform one or more operations (e.g., communicating and instructing one or more nodes of the associated transport network, etc.) to establish the transport path(s) or connection(s) between the O-RU(s) 630 and the second 0-DU 650-2. At this stage, the O-RU(s) 630 is ready to be rehomed to the second 0-DU 650-2.

[0090] At step 15, the SMO 610 may communicate (via the 01 interface) with the O-CU 660 (or an O-CU-CP associated therewith) to configure or activate the cell(s) associated with the second O-DU 650-2. Similarly, at step 16, the SMO 610 may communicate (via the 01 interface) with the second 0-DU 650-2 to configure or activate the cell(s) associated with the second 0-DU 650-2 and the corresponding carrier(s) resources. Accordingly, at step 17, the second 0-DU 650-2 may apply or update the cell(s) configuration, and then provide an update message / notificationto the O-CU 660 (or the associated O-CU-CP) via the Fl interface. Further, at step 18, the SMO 610 may instruct or notify the TN Manager 620 to perform path establishment (e.g., establishing the transport path(s) or connection(s) between the O-RU(s) 630 and the second 0-DU 650-2). For instance, at step 18, the SMO 610 may provide or trigger one or more API calls (e.g., via any suitable API interface such as REST API, etc.) to the TN Manager 620, may provide an RPC command to the TN Manager 620 (e.g., via NETCONF YANG operation / model, etc.), may provide an instruction or a trigger from a user (e.g., a network operator) to the TN Manager 620, and the like.

[0091] Furthermore, at step 19, the second 0-DU 650-2 may communicate (via the OFH interface, such as the M-Plane, etc.) with the O-RU(s) 630 to activate or configure the associated carrier resources (e.g., TRX array carrier(s), etc ). Accordingly, at step 20, the second O-DU 650-2 may communicate with the SMO 610 (via the 01 interface) to provide an update notification regarding the status of the associated cell(s) and the corresponding carrier(s) resources. Similarly, at step 21, the O-CU 660 (or the associated O-CU-CP) may communicate with the SMO 610 (via the 01 interface) to provide an update notification regarding the status of the cell(s) associated with the second 0-DU 650-2.

[0092] At this stage, it can be considered that the O-RU(s) 630 has been successfully rehomed from the first 0-DU 650-1 to the second 0-DU 650-2. Accordingly, the SMO 610 may perform one or more operations (e.g., communicating with the IMS and / or DMS associated with the first O-DU 650-1, etc.) to shut down the first O-DU 650-1, thereby achieving the power-saving purposes. Accordingly, the SMO 610 may continue to monitor the data (e.g., FM data, PM data, CM data, etc.) for at least a predefined period of time, and then orchestrate the TN Manager 620 and the RAN entities / functions (e.g., O-RU(s) 630, O-DUs 650-1 and 650-2, O-CU 660, etc.) tocoordinately implement the example use case 600 (e.g., reactivating the first O-DU 650-1 and rehome at least part of the O-RU(s) 630 back to the first O-DU 650-1 during high traffic / peak hour, etc.), according to the resource utilizations in real-time, near-real-time, and / or non-real-time. In some example implementations, in addition to the SMO 610, an APN Orchestrator may be utilized as the secondary management entity to assist the SMO 610 in orchestrating the TN manager 620 and the RAN entities / functions.

[0093] It is contemplated that the configurations in FIG. 6A to FIG. 6C are merely example, and the scope of the present disclosure is not limited thereto. Specifically, the more / less components (e.g., TN Network, Core Network, etc.) may be involved, some of the steps may be performed in any suitable sequential manner (e.g., some steps may be performed simultaneously, etc.), and the like, without departing from the scope of the present disclosure. Further, it is contemplated that the configurations, mechanisms, and operations in example use case 600 may also be implemented in difference scenarios (e.g., O-DU failure, overloading / load-balancing or capacity optimization, planned maintenance like a scheduled software update, unexpected events like disasters, etc.), in addition to or in alternative to the described resource underutilization scenario.

[0094] In view of the above, example embodiments provide several example use cases that illustrate and exemplify the implementations of the enhanced O-DU power saving. Specifically, the example use cases show that example embodiments of the present disclosure may be implemented in an O-RAN-based network. For instance, FIG. 4A and FIG. 4B exemplify how different 0-RAN entities / network functions (e g., SMO, O-RU, O-DU, O-CU, etc ), that may be implemented at different sites, may interoperate with each other to rehome the O-RU(s) from a source O-DU(s) to a target O-DU(s), thereby enabling the source O-DU(s) to be shutdown / decommissioned for power-saving purposes without affecting the operations of the O-RU(s). Further, FIG. 5 exemplifies how the rehoming process may be implemented in a cloud-native environment and how the decoupled SMO architecture may involve therein. Furthermore, FIG. 6A to FIG. 6C exemplifies the call flows and interactions between the O-RAN entities / network functions in implementing the rehoming process.

[0095] Advantageously, the example use cases in FIG. 4A to FIG. 6C exemplify that example embodiments can be efficiently and effectively implemented in the existing O-RAN network architecture while utilizing the existing O-RAN components and interfaces without substantive modification thereto, thereby reducing the roll-out period and implementation difficulty. It is also contemplated that the technical advantages described above with reference to FIG. 1 to FIG. 3 may be similarly applied to the example use cases in FIG. 4A to FIG. 6C, without departing from the scope of the present disclosure.Examples of Device

[0096] One or more components of the example embodiments (e.g., SMO, TN Manager, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

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

[0098] FIG. 7 illustrates an embodiment of a device 700. As shown in FIG. 7, the device 700 may include a processor 710, a memory 720, a storage component 730, an input component 740, an output component 750, a communication interface 760, and a bus 770.

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

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

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

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

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

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

[0105] The bus 770 acts as an interconnect between the processor 710, the memory 720, the storage component 730, the input component 740, the output component 750, and the communication interface 760 of the device 700. The bus 770 may include a wired interconnection or a wireless interconnection.

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

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

[0108] FIG. 8 illustrates a diagram of an example environment 800 in which systems and / or methods, described herein, may be implemented. The implementation environment 800 includes a UE (User equipment) 810, a service environment 820, and a network 830. The service environment 820 includes one or more sub-environments 821. To illustrate this, FIG. 8 shows, for convenience, examples of a 1st sub -environment 821-1, a 2nd sub-environment 821-2, and an N-th sub-environment 821-N (where N is any natural number).

[0109] The UE 810 is connected to the network 830, and the network 830 is connected to the service environment 820. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 810 and the service environment 820 are connected via the network 830.

[0110] The UE 810 is a device that communicates with the service environment 820. The UE 810 receives information from the service environment 820 and / or sends information to the service environment 820. Also, the UE 810 may generate and / or store information to be transmitted, as necessary. Also, the UE 810 may store and / or process information that is received, as necessary.[OHl] The example FIG. 8 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,”“communication device,” and “communication terminal” can be used interchangeably with the term “UE ”

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

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

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

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

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

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

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

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

[0120] The network 830 is a network that exchanges information between the UE 810 and the service environment 820. The network 830 includes one or more wired and / or wireless networks.

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

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

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

[0124] Example embodiments introduces new parameters, attributes, mechanisms, and features that supplement and enhance the disclosures of one or more standard specifications. As a non-limiting example, example embodiments supplement and enhance at least one technical specification associated with the 0-RAN Alliance), as detailed blow (the supplementations and enhancements provided by example embodiments are presented in table and / or bold format).

[0125] To begin with, the following is added: :& &&

[0126] Further, the call flows consistent with FIG. 6A to FIG. 6C, as well as the following, are added:

[0127] In view of the above, example embodiments introduce specified and standardized approaches for implementing the enhanced 0-DU power saving in O-RAN-based architecture. Specifically, example embodiments clarify how specifically the components in the O-RAN architecture (e.g., SMO, O-RU, O-DU, O-CU, etc.) and the existing O-RAN interfaces (e.g., 01 interface, 02 interface, Fl interface, OFH interface, etc.) can be utilized to implement the enhanced 0-DU power saving. Accordingly, example embodiments may be implemented in the O-RAN-based networks in a clear and standardized manner to enhance the power saving of the O-DU, and eventually enhancing the power saving of the O-RAN-based networks.

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

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

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

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

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

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

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

[0135] These computer-readable program instructions may be provided to a processor of ageneral -purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

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

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

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

[0139] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprising: a Service Management and Orchestration (SMO) framework configured to: determine whether an Open Radio Access Network (0-RAN) Radio Unit (O-RU) can be rehomed from a first 0-RAN Distributed Unit (O-DU) to a second O-DU; and based on determining that the O-RU can be rehomed from the first O- DU to the second O-DU, configure a Transport Network (TN) Manager to rehome the O- RU from the first O-DU to the second O-DU.Item [2]: The system according to item [1], wherein the SMO framework is configured to determine that the O-RU can be rehomed by: determining whether a first predefined condition associated with the first O-DU is satisfied; based on determining that the first predefined condition is satisfied, determining whether a second predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.Item [3]: The system according to one or more of items

[0001] -[2], wherein the SMO framework is configured to configure the TN Manager to rehome the O-RU by: performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; and performing a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.Item [4]: The system according to item [3], wherein the SMO framework is further configured to: prior to performing the first API call, perform at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; and prior to performing the second API call, perform at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell.Item [5]: The system according to item [4], wherein the SMO framework is configured to deactivate the first cell by: instructing, via an 01 interface, an 0-RAN Central Unit (0-CU) to deactivate the first cell; wherein the SMO framework is configured to remove the network resources associated with the first cell by: instructing, via the 01 interface, the first O-DU to remove a carrier resource associated with the first cell; whereinthe SMO framework is configured to activate the second cell by: instructing, via the 01 interface, the O-CU to activate the second cell; and wherein the SMO framework is configured to activate the network resources associated with the second cell by: instructing, via the 01 interface, the second 0-DU to activate a carrier resource associated with the second cell.Item [6]: The system according to item [2], wherein the first predefined condition comprises at least one of: an underutilization of the first 0-DU is detected, an overloading of the first 0-DU is detected, a failure of the first 0-DU is detected, or a planned maintenance on the first 0-DU is detected; and wherein the second predefined condition comprises: the second 0-DU has sufficient resources to accommodate the 0-RU.Item [7]: The system according to one or more of items [I]-[6], wherein the TN manager is implemented externally from the SMO framework.Item [8]: The system according to one or more of items [l]-[6], wherein the TN manager is implemented as at least one of: an SMO Service (SMOS) within the SMO framework or an SMO Function (SMOF) within the SMO framework.Item [9]: A method comprising: determining, by a Service Management and Orchestration (SMO) framework, whether an Open Radio Access Network (0-RAN) Radio Unit (0-RU) can be rehomed from a first 0-RAN Distributed Unit (0-DU) to a second 0-DU; and based on determining that the 0-RU can be rehomed from the first O-DU to the second 0-DU, configuring, by the SMO framework, a Transport Network (TN) Manager to rehome the 0-RU from the first 0-DU to the second 0-DU.Item

[0010] : The method according to item [9], wherein the determining whether the 0-RU can be rehomed comprises: determining whether a first predefined conditionassociated with the first O-DU is satisfied; based on determining that the first predefined condition is satisfied, determining whether a second predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.Item

[0011] : The method according to one or more of items [9]-

[0010] , wherein the configuring the TN Manager to rehome the O-RU comprises: performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; and performing a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.Item

[0012] : The method according to item

[0011] , further comprising: prior to performing the first API call, performing at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; and prior to performing the second API call, performing at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell.Item

[0013] : The method according to item

[0012] , wherein the deactivating the first cell comprises: instructing, via an 01 interface, an 0-RAN Central Unit (0-CU) to deactivate the first cell; wherein the removing the network resources associated with the first cell comprises: instructing, via the 01 interface, the first O-DU to remove a carrier resource associated with the first cell; wherein the activating the second cell comprises: instructing, via the 01 interface, the 0-CU to activate the second cell; and wherein the activating the network resources associated with the second cell comprises: instructing, viathe 01 interface, the second 0-DU to activate a carrier resource associated with the second cell.Item

[0014] : The method according to item

[0010] , wherein the first predefined condition comprises at least one of: an underutilization of the first 0-DU is detected, an overloading of the first 0-DU is detected, a failure of the first 0-DU is detected, or a planned maintenance on the first O-DU is detected; and wherein the second predefined condition comprises: the second O-DU has sufficient resources to accommodate the O-RU.Item

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

[0014] , wherein the TN manager is implemented externally from the SMO framework.Item

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

[0014] , wherein the TN manager is implemented as at least one of: an SMO Service (SMOS) within the SMO framework or an SMO Function (SMOF) within the SMO framework.Item

[0017] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a device to cause the device to perform a method comprising: determining whether an Open Radio Access Network (O-RAN) Radio Unit (O-RU) can be rehomed from a first O-RAN Distributed Unit (O-DU) to a second O-DU; and based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, configuring a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.Item

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

[0017] , wherein the determining whether the O-RU can be rehomed comprises: determining whether a first predefined condition associated with the first O-DU is satisfied; based on determining that the first predefined condition is satisfied, determining whether asecond predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.Item

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

[0017] -

[0018] , wherein the configuring the TN Manager to rehome the O- RU comprises: performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; and performing a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.Item

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

[0019] , further comprising: prior to performing the first API call, performing at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; and prior to performing the second API call, performing at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell.

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

Claims

What is claimed is:

1. A system comprising:a Service Management and Orchestration (SMO) framework configured to:determine whether an Open Radio Access Network (O-RAN) Radio Unit (O-RU) can be rehomed from a first O-RAN Distributed Unit (O-DU) to a second O-DU; andbased on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, configure a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.

2. The system according to claim 1, wherein the SMO framework is configured to determine whether the O-RU can be rehomed by:determining whether a first predefined condition associated with the first O-DU is satisfied;based on determining that the first predefined condition is satisfied, determining whether a second predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.

3. The system according to claim 1, wherein the SMO framework is configured to configure the TN Manager to rehome the O-RU by:performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; andperforming a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.

4. The system according to claim 3, wherein the SMO framework is further configured to:prior to performing the first API call, perform at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; andprior to performing the second API call, perform at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell.

5. The system according to claim 4,wherein the SMO framework is configured to deactivate the first cell by: instructing, via an 01 interface, an 0-RAN Central Unit (0-CU) to deactivate the first cell;wherein the SMO framework is configured to remove the network resources associated with the first cell by: instructing, via the 01 interface, the first O-DU to remove a carrier resource associated with the first cell;wherein the SMO framework is configured to activate the second cell by: instructing, via the 01 interface, the 0-CU to activate the second cell; andwherein the SMO framework is configured to activate the network resources associated with the second cell by: instructing, via the 01 interface, the second O-DU to activate a carrier resource associated with the second cell.

6. The system according to claim 2,wherein the first predefined condition comprises at least one of: an underutilization of the first 0-DU is detected, an overloading of the first 0-DU is detected, a failure of the first 0-DU is detected, or a planned maintenance on the first 0-DU is detected; and wherein the second predefined condition comprises: the second 0-DU has sufficient resources to accommodate the 0-RU.

7. The system according to claim 1, wherein the TN manager is implemented externally from the SMO framework.

8. The system according to claim 1, wherein the TN manager is implemented as at least one of: an SMO Service (SMOS) within the SMO framework or an SMO Function (SMOF) within the SMO framework.

9. A method comprising:determining, by a Service Management and Orchestration (SMO) framework, whether an Open Radio Access Network (O-RAN) Radio Unit (O-RU) can be rehomed from a first O-RAN Distributed Unit (O-DU) to a second O-DU; andbased on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, configuring, by the SMO framework, a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.

10. The method according to claim 9, wherein the determining whether the 0-RU can be rehomed comprises:determining whether a first predefined condition associated with the first O-DU is satisfied;based on determining that the first predefined condition is satisfied, determining whether a second predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.

11. The method according to claim 9, wherein the configuring the TN Manager to rehome the O-RU comprises:performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; and performing a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.

12. The method according to claim 11, further comprising:prior to performing the first API call, performing at least one of: deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; andprior to performing the second API call, performing at least one of: activating a second cell associated with the second O-DU or activating network resources associated with the second cell.

13. The method according to claim 12,wherein the deactivating the first cell comprises: instructing, via an 01 interface, an 0-RAN Central Unit (O-CU) to deactivate the first cell;wherein the removing the network resources associated with the first cell comprises: instructing, via the 01 interface, the first 0-DU to remove a carrier resource associated with the first cell;wherein the activating the second cell comprises: instructing, via the 01 interface, the O-CU to activate the second cell; andwherein the activating the network resources associated with the second cell comprises: instructing, via the 01 interface, the second 0-DU to activate a carrier resource associated with the second cell.

14. The method according to claim 10,wherein the first predefined condition comprises at least one of: an underutilization of the first 0-DU is detected, an overloading of the first 0-DU is detected, a failure of the first 0-DU is detected, or a planned maintenance on the first 0-DU is detected; and wherein the second predefined condition comprises: the second 0-DU has sufficient resources to accommodate the 0-RU.

15. The method according to claim 9, wherein the TN manager is implemented externally from the SM0 framework.

16. The method according to claim 9, wherein the TN manager is implemented as at least one of: an SMO Service (SMOS) within the SMO framework or an SMO Function (SMOF) within the SMO framework.

17. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a device to cause the device to perform a method comprising:determining whether an Open Radio Access Network (O-RAN) Radio Unit (O-RU) can be rehomed from a first O-RAN Distributed Unit (O-DU) to a second O-DU; and based on determining that the O-RU can be rehomed from the first O-DU to the second O-DU, configuring a Transport Network (TN) Manager to rehome the O-RU from the first O-DU to the second O-DU.

18. The non-transitory computer-readable recording medium according to claim 17, wherein the determining whether the O-RU can be rehomed comprises:determining whether a first predefined condition associated with the first O-DU is satisfied;based on determining that the first predefined condition is satisfied, determining whether a second predefined condition associated with the second O-DU is satisfied; and based on determining that the second predefined condition is satisfied, determining that the O-RU can be rehomed from the first O-DU to the second O-DU.

19. The non-transitory computer-readable recording medium according to claim 17, wherein the configuring the TN Manager to rehome the O-RU comprises:performing a first Application Programming Interface (API) call to the TN manager to terminate a first transport path between the O-RU and the first DU; and performing a second API call to the TN manager to establish a second transport path between the O-RU and the second O-DU.

20. The non-transitory computer-readable recording medium according to claim 19, wherein the method further comprises:prior to performing the first API call, performing at least one of deactivating a first cell associated with the first O-DU or removing network resources associated with the first cell; andprior to performing the second API call, performing at least one of activating a second cell associated with the second O-DU or activating network resources associated with the second cell.

Images