Shared open-ran radio unit resiliency

Abstract

A method, apparatus, and system for resiliency in multiple O-DU systems may be provided and may include, receiving, by a shared O-RAN radio unit (O-RU) from Service Management and Orchestration (SMO), details of a first O-RAN distributed unit (O-DU); calling home the first O-DU based on the received details of the first O-DU to establish a network configuration protocol session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving details of a second O-DU from the SMO; and upon the SMO detecting failure / scheduled maintenance of the first O-RU, calling home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU.

Description

SHARED OPEN-RAN RADIO UNIT RESILIENCYFIELD

[0001] The present disclosure relates to shared Open-RAN (0-RAN) Radio Unit (RU) resiliency.BACKGROUND

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

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

[0004] 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, different types 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), or could be in physical hardware form (e.g., non-VM based).

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

[0006] FIG. 1 illustrates an 0-RAN architecture in the related art. RAN functions in the 0-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the O-RAN system, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types: a non-real-time RIC (Non- RT RIC) 120 and a near-real-time RIC (Near-RT RIC) 130.

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

[0008] The Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-DU 170, the O-CU (disaggregated into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and an open evolved NodeB (O- eNB) 160 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop. The Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes (O-CU 140,150, O-DU 170, and O-eNB 160) via policies. For example, the Near-RT RIC 130 may set policy parameters on activated functions of the E2 nodes. Further, the Near-RT RIC 130 may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc.

[0009] Here, the O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via the El interface, and may be coupled to the O-DU 170 via the Fl-c interface and Fl-u interface, respectively. Further, the 0-RU 180 may be coupled to the O-DU 170 via the Open Fronthaul (OF) Control (C), User (U), Synchronization (S), and Management (M) Planes, and may be coupled to the SMO 110 via the OF M-Plane.

[0010] The two types of RICs work together to optimize the O-RAN. For example, the Non-RT RIC 120 may provide the policies, data, and AVML models enforced and used by the Near-RT RIC 130 for RAN optimization, and the Near-RT RIC 130 may return policy feedback (i.e., how the policy set by the Non-RT RIC 120 works).

[0011] As mentioned above, the Non-RT RIC 120 may be located within the SMO framework 110, which manages and orchestrates RAN elements. Specifically, the SMO 110 may manage and orchestrate what is referred to as the O-Ran Cloud (O-Cloud) 190. The O-Cloud 190may be a collection of physical RAN nodes that host the RICs, O-CUs, and O-DUs, the supporting software components (e.g., the operating systems and runtime environments), and the SMO 110 itself. In other words, the SMO 110 may manage the O-Cloud 190 from within. The 02 interface may be the interface between the SMO 110 and the O-Cloud 190 it resides in. Through the 02 interface, the SMO 110 may provide infrastructure management services (IMS) and deployment management services (DMS).

[0012] In the related art, a plurality of O-DU’s (which may have a similar configuration to 0-DU 170) may be implemented in order to implement a multiple 0-DU system for resiliency (for example, if one of the O-DU’s fails, then there is a backup 0-DU). To this end, a shared 0-RU (which may have a similar configuration to 0-RU 180) may be configured in order to operate between multiple O-DU’s.SUMMARY

[0013] Related art use-cases using a shared 0-RU for resiliency may not clearly define (in current specifications) how to share details (such as carrier configurations) between entities in a multiple 0-DU system (e.g., the multiple O-DU’s, the SMO, the shared 0-RU). It particularly may not be clearly defined how to implement pre-configured carrier configurations for multiple O- DU’s in related art systems.

[0014] According to embodiments, methods, apparatuses and systems for resiliency in shared 0-RU systems may be provided. The method may include, receiving, by a shared Open Radio Access Network (0-RAN) radio unit (0-RU) from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); calling home, by the shared O- RU, the first O-DU based on the received access details of the first 0-DU to establish a networkconfiguration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

[0015] Based on the above embodiments, resiliency for shared O-RU / multiple O-DU systems can be improved in various aspects including, but not limited to, improving scenario detection / handling from the SMO, improving efficiency of carrier configuration data, and improving carrier transfer between active / stand-by O-DU’s for a given shared O-RU.

[0016] According to embodiments, a shared Open Radio Access Network (O-RAN) radio unit (O-RU) may be provided. The shared O-RU may be configured to: receive from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); call home the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receive, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, call home the secondO-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

[0017] According to embodiments, at least one non-transitory computer-readable recording medium having recorded thereon instructions executable may be provided to implement a method including: receiving, by a shared Open Radio Access Network (O-RAN) radio unit ORU) from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); calling home, by the shared O-RU, the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O- RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

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

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

[0001] FIG. 1 illustrates an 0-RAN architecture according to the related art;

[0020] FIG. 2 illustrates a system architecture diagram for a shared O-RU system for resiliency according to an embodiment;

[0021] FIG. 3 illustrates an example data structure for carrier configurations according to an embodiment;

[0022] FIG. 4 illustrates a method for implementing a shared O-RU system for resiliency according to an embodiment;

[0023] FIG. 5 is a diagram of an example environment in which systems and / or methods, described herein, may be implemented; and

[0024] FIG. 6 is a diagram of example components of a device according to an embodiment.DETAILED DESCRIPTION

[0025] 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 form 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, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be switched.

[0026] 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 limiting of 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.

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

[0028] 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.” Where only one item is intended, the term “one” or similar language is used. 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]” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B.

[0029] According to embodiments, methods, apparatuses and systems for resiliency in shared O-RU systems may be provided. The method may include, receiving, by a shared Open Radio Access Network (0-RAN) radio unit (O-RU) from Service Management and Orchestration (SMO), access details of a first 0-RAN distributed unit (O-DU); calling home, by the shared O- RU, the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenantO-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

[0030] Based on the above embodiments, resiliency for shared O-RU / multiple O-DU systems can be improved in various aspects including, but not limited to, improving scenario detection / handling from the SMO, improving efficiency of carrier configuration data, and improving carrier transfer between active / stand-by O-DU’s for a given shared O-RU.

[0031] FIG. 2 illustrates a system architecture diagram for a shared O-RU system for resiliency according to an embodiment. Service Management and Orchestration (SMO) 200, O- CU #1 210, O-DU #1 211, O-DU #2 212, Shared O-RU 220, and DHCP Server 230 may be provided. Although only one O-CU (O-CU #1 210) and two O-DU’s (“active / host / primary” O- DU #1 211 and “standby / tenant / secondary” O-DU #2212) are illustrated, it should be appreciated that more than one O-CU and more than two O-DU’s may be included, depending on the specification implementation (e.g., a single primary O-DU may be paired with multiple standby O-DU’s such as primary active and primary standby O-DU’s, or multiple operators may be provided, in cases with multiple O-DU’s, sro-id (for the multiple operator deployment case) and / or odu-id (for the single operator deployment case) may be implemented in order to identify the individual O-DU, described in further detail hereinbelow). It should also be appreciated that shared O-RU 220 may also interchangeably be referred to as a “shared resource operator” (SRO).

[0032] It should also be appreciated that while the term “active / host / primary” may be used to refer to O-DU #1 211 and “standby / tenant / secondary / backup” may be used to refer to O-DU #2 212, these terms are based on the operational state of O-DU #1 211 and ODU #2212. Accordingly,if O-DU #1 211 fails, O-DU #1 211 may be referred to as the “secondary / standby / backup” O-DU and O-DU #2 212 may be referred to as being in the “active” state, etc.

[0033] SMO 200 may be in communication with O-CU #1 210, O-DU #1 211, O-DU #2 212, and Shared O-RU 220 via DHCP Server 230.

[0034] O-DU #1 211 may be referred to as an active / host / master O-DU, and O-DU #2212 may be referred to as a standby / tenant / slave O-DU. In other words, shared O-RU 220 may be intended to initially connect to O-DU #1 211 as the main O-DU, whereas O-DU #2212 acts as the backup for resiliency (e.g. in case of failure / scheduled maintenance of O-DU #1 211). O-DU #1 211 and O-DU #2 212 may have optionally have an inter O-DU management interface and / or a traffic interface in order to provided communication between the two O-DU’s.

[0035] In the scenario illustrated in FIG. 2, the following pre-conditions may be assumed. Firstly, Shared O-RU 220 should support a SHARED-ORU-MULTI-ODU feature. Secondly, O- DU #1 211 and O-DU #2212 should be connected to the same O-CU (e.g., O-CU #1 210 illustrated in FIG. 2).

[0036] At SI, SMO 200 may identify O-DU #1 211 and O-DU #2212. This may be based on an “odu-id” string, and / or an O-DU unique name. The odu-id may be defined with a variety of naming schemas including, but not necessarily limited to:

[0037] (a) “host” for active O-DU (e.g., O-DU #1 211) and as “tenant” for standby O-DU(e.g., O-DU #2212);

[0038] (b) “master” for active O-DU (e.g., O-DU #1 211) and as “slave” for standby O-DU (e.g., O-DU #2 212); and / or

[0039] (c) String(s) in Two / Three octet format to distinguish or identify the active and standby O-DUs, (for example, refer to PLMN ID defined in Sec. 9.3.3.5 of 3GPP TS 38.413 specification).

[0040] It should be appreciated that “odu-id” string as defined above may be used also in single operator cases, and the shared 0-RU 220 may support “SHARED-ORU-MULTI-ODU feature to assign net configuration protocol (NETCONF) access control privileges (for example, odu-id string may be included in o-ran usermgmt. yang module for multi-ODU feature, such that the NETCONF client of a ODU #2 212 may be identified using a user list field in o-ran- usermgmt.yang module); (yang refers to Yet Another Generation, which is a data modelling language typically used for NETCONF, however it should be appreciated that yang may be interchangeably used with other data modelling languages as appropriate). Additionally or alternatively, SMO 200 may use the “odu-id” string and / or some other unique 0-DU name to identify 0-DU #1 211 and 0-DU #2 212, as this may be particularly useful in the case where both 0-DU #1 211 and 0-DU #2 212 are assigned as primary by mistake (i.e., incorrect assignment case).

[0041] At S2, Shared O-RU 220 may make a call to SMO 200 (via DHCP Server 230) in order to obtain details regarding 0-DU #1 211, which may include the IP address of O-DU #1 211 as well as the ODU-ID details.

[0042] At S3, Shared 0-RU 220 may call home to 0-DU #1 211 in order to establish a persistent NETCONF session, activate a carrier configuration with 0-DU #1 211, and subscribe to alarms and notification with 0-DU #1 211. The NETCONF session with O-DU #1 211 may have supervision activated and “sudo” privilege related configurations for 0-DU #1 211 (e.g.,admin / super user privileges to allow O-DU #1 211 to modify configurations freely) according to embodiments.

[0043] At S4, Shared 0-RU 220 may firstly receive details regarding O-DU #2212 (which may include the IP address of O-DU #2 212 as well as ODU-ID details) from SMO 200. Methods for obtaining O-DU #2 212 details may include, but may not necessarily be limited to:

[0044] (a) O-DU #1 211 may write odu-id of O-DU #2 212 in an o-ran-supervision.yang module in the hierarchical deployment; and / or

[0045] (b) In a scenario of hybrid deployment, SMO 200 may write odu-ids of both O-DU#1 211 and O-DU #2 212 in o-ran-supervision.yang module, based on which shared O-RU 220 may have a NETCONF session with supervision activated.

[0046] Subsequently, Shared O-RU 220 may make a call home to O-DU #2 (which may establish a persistent NETCONF session, and subscribe to configuration related change notifications in Shared O-RU 220). In S4, O-DU#1 211 (which is acting as the primary O-DU) could use an o-ran-mplane-int yang model to configure the configured-client-info container in shared O-RU 220 with IP address(es) of the NETCONF client(s) used by back-up O-DU(s) (such as O-DU #2 212, which is acting as the back-up O-DU in the illustrated embodiment). According to some embodiments, O-DU #2 212 may include only carrier privilege (e.g., NETCONF access control privilege), and not perform actual carrier configuration. It should be appreciated that according to embodiments, a NETCONF client with carrier privileges (whose user account may be configured with an odu-id string) may only be permitted to update list entries, after the list entry has been created and configured with an odu-id string associated with O-DU #2 212)

[0047] According to embodiments, when 0-DU 2 212 subscribes to configuration related change notifications in Shared 0-RU 220 (which currently has an active configuration with O- DU#1 211), O-DU#2 may already be fully aware of any configuration changes after reading the configuration changes during start up. According to embodiments, 0-DU #1 211 may configure an odu-id string of 0-DU #2 212 to create an account for 0-DU #2 212 NETCONF client(s) on the shared 0-RU NETCONF server which includes the odu-id string. 0-DU #1 211 may accordingly communicate account information to 0-DU #2212. Optionally, 0-DU #1 211 may be subscribed to be notified of updates to the O-RU’s configuration datastore. According to embodiments, in the single operator (SHARED-ORU-MULTI-ODU) use-case, odu-id string may be used by ODU #2 212 to subscribe to the O-DU #1 related configuration change notifications.

[0048] At S5, 0-DU #1 211 may fail, or there may be some interface failure, or scheduled maintenance (for instance, caused by an operator’s decision). Shared 0-RU 220 may no longer have a stable connection with 0-DU #1 211. According to embodiments, SMO 200 may detect or determine that this failure has occurred.

[0049] At S6, SMO 200 may make a decision for 0-DU #2 212 to take over control of shared O-RU 220 (i.e., O-DU #2 212 may become the primary O-DU over O-DU #1 211) based on failure in S5 being determined / detected. It should be appreciated that SMO 200 may need to differentiate between 0-DU failure and scheduled maintenance (e.g., basic resiliency case) and network component or function related failures (e.g., advanced resiliency case). SMO 200 may also need to be able to determine when failures are caused by the network, interface, or a scenario of the 0-DU #1 211 being reset but coming back to service after waiting some time. Failures may also further be caused by an O-DU fault, a FH interface failure, Fl interface failure, O-DU portfailure, environmental issues, power failures, supervision failures, security threats, scheduled maintenance, software upgrades, carrier upgrades, and etc. At least some of the above factors may be considered when determining failure which occurred in S5.

[0050] There may be additional various factors for a decision to transition 0-DU #2 212 to take control over shared 0-RU 220, as well as how to perform said transition, which may also include, but may not necessarily be limited to:

[0051] (a) SMO 200 may have some pre-defined reference points for carrier states according to embodiments, said reference points may be based on operational / availability statuses of the appropriate carrier (for example, defined in specification 3GPP TS 28.625 / ITU-T X.731). Since these carrier states may be more clearly defined using such pre-defined reference points, SMO 200 may be able to make more well-informed decisions, rather than relying on only failure alarms;

[0052] (b) SMO 200 may also need to consider when to perform carrier / NR cell switching / transitions between either a soft transition or a hard transition, according to embodiments. A soft transition may be when the carrier configuration (which was active between O-DU #1 211 and shared O-RU 220) is with O-DU #2212, and is ready to be pushed to shared O- RU 212, whereas a hard transition is when the carrier configuration is not readily available with O-DU #2212;

[0053] (c) Alarms from O-DU #1 211 and associated O-CU (e.g., O-CU #1 210) or other alarms received from higher layers in the layer stack are received;

[0054] (d) The threshold of maximum call home attempts from shared O-RU 220 are completed (it should be noted that the SMO 200 may not be explicitly aware that shared O-RU 220 is still making call home attempts, or that the threshold is reached); and / or

[0055] (e) A first supervision alarm (#35) and / or O-DU #1 211 being faulty are detected.First supervision alarm #35 may commonly be defined in the related art for supervision failure for shared O-RU 220, however, it may not necessarily provide enough details / relevancy regarding the specific failure. Accordingly, more specific alarms for shared O-RU resiliency (such as indicating NR cell transition failure, back-up O-DU non-availability / fault, interface with back-up O-DU failure, etc.) may be implemented, according to embodiments. According to some embodiments, an alarm generated after a first supervision failure for other factors / flags may be provided, for instance to indicate max-call-home attempt completion and re-activation of call home with a failing O-DU is a success. In any case, history of all alarm data used may be able to improve future decision-making by SMO 200 (for example, using AI / Machine learning approaches to train a model based on alarm data history).

[0056] In any of these cases, SMO 200 may modify the access privilege of O-DU 212 #2 to be “sudo” (e.g., admin / super user privileges to allow O-DU #2 212 to modify configurations freely). Particularly, it should be noted that O-DU 211 #1 may previously have “sudo” privilege. It should be appreciated that according to embodiments where O-RU 220 may also have NETCONF sessions with any N number of O-DU’ s with different privileges (whereas two O-DU’ s are described in the example embodiment), SMO 200 may identify the correct back-up O-DU and set only the necessary privileges to the identified back-up O-DU for resiliency decision making.

[0057] At S7, either SMO 200 or O-DU #2 212 may configure (for example, using o-ran- processing-elements.yang module) one of the MAC address / MAC Address + VLAN-ID / UDP IP and / or the ODU-ID, and subsequently activate the carrier configuration for the appropriate carrier for O-DU #2 212 (for example, by changing the tx / rx array-carrier-active as “ACTIVE” in o-ran- uplane.yang module for the appropriate carrier for O-DU #2 212). It should be appreciated that O- DU #2 212 may retrieve its carrier configuration with a variety of methods including, but not limited to:

[0058] (a) SMO 200 pushes the configuration to O-DU #2 212 with an edit-config remote protocol call (RPC). Subsequently, O-DU #2 212 may apply transport related changes (such as MAC addresses / MAC Address+VLAN ID / UDP IP and / or the ODU-ID) and subsequently activate a carrier configuration by setting tx / rx array-carrier-active as “ACTIVE in o-ran-uplane.yang module, similar to as mentioned above;

[0059] (b) O-DU #2 212 may already have a snapshot of the carrier configuration pertaining to previously active O-DU #1 211 and shared O-RU 211, and accordingly that carrier configuration may be modified and applied / activated during the carrier transition from O-DU #1 21 I to O-DU #2 212;

[0060] (c) O-DU #2212 could perform a fresh configuration (e.g., via a start-up procedure) with shared O-RU 220 by sending a remote protocol call (RPC) to shared O-RU 220 to delete the existing configuration. This may be similar to how a new O-RU is connected to / configured. In this case, O-DU #2212 may, for example, send an RPC delete to shared O-RU 220 by mentioning the appropriate container name or yang file to delete the corresponding carrier configuration which was previously active between O-DU #1 211 and shared O-RU 220. Otherwise, SMO 200 mayalso initiate a carrier transition from O-DU #1 211 to O-DU #2 212 such that O-DU #2 212 may request the shared O-RU 220 to delete the carrier configuration. In such a scenario, a common configuration may already be known to O-DU #2 212, and / or O-DU #2 212 may be able to configure the same common configuration via an active NETCONF session via carrier privilege; and / or

[0061] (d) Duplicate carrier configurations with dummy endpoints (dedicated resources) for O-DU #2212 and shared O-RU 220 could be preconfigured in shared O-RU 220, and updated periodically or based on O-DU #2 212 getting updates on configuration changes. In this scenario, carrier configurations pertaining to O-DU #2 212 could initially be pre-configured to have tx / rx array-carriers:: active to “INACTIVE”, and the state of the array-carrier to “DISABLED”. Accordingly, when SMO 200 triggers carrier transition between O-DU #1 211 and O-DU #2 212, O-DU #2 may simply change tx / rx array-carriers:: active to “ACTIVE”, and the state of the arraycarrier to “ENABLED”. It should be appreciated that the variable names used in the above scenarios may be arbitrary, and that the purpose of the example may be to illustrate how carrier configurations may be pre-configured prior to transitioning between O-DU’s.

[0062] According to embodiments, shared O-RU 220 may implement pre-configuration of O-DU #2 212, by reporting the support of pre-configuration as a capability, (e g., via o-ran- module-cap.yang under SHARED-ORU-MULTI-ODU feature. module: o-ran-module-cap). For example, a boolean flag may be set in the appropriate file.

[0063] In any of the above scenarios, it may be possible for an entity (such as a SMO 200 or O-DU #2 212) to use a get-config RPC to get a snapshot and / or retrieve configurations which are presently active between O-DU #1 211 and shared O-RU 220.

[0064] According to embodiments, carrier switching from O-DU #1 211 to 0-DU #2 212 may need to be quick. According to an embodiment, in the case where there are duplicate carriers, duplicated cells (NRCellDU parameter) and carriers (NRSectorCarrier parameter) may be configured in 0-DU #2 212. Duplicate cells (NRCellDU(s)) and NRSectorCarrier(s) associated with O-DU#1 211 could be pre-configured in standby 0-DU i.e., 0-DU #2 212 and their Administrative-State set as “Locked”. However, NRCellDU(s) may be different for the same NRSectorCarrier(s) configured in both O-DU#1 211 and 0-DU#2 212 as it is a function of gNB ID / O-DU ID. Also, O-CU 210 could differentiate them with the unique gNB-DU name. The duplicate cells could be created in 0-DU#2212 with the unique / corresponding gNB-DU Name / ID and with Administrate State as locked, so that the Fl AP interface will not reject the duplicate cells configured in 0-DU#2212. When O-DU#1 211 fails, the NR Cells that were configured and active are either removed, or SMO 200 / 0-CU 210 could set the respective Administrative- State as locked. Subsequently, NR cells configured in 0-DU#2 212 are unlocked.

[0065] Since O-CU 210 may know that cells (NRCellDU(s)) configured with a unique gNB-DU name and ID (gNB ID / O-DU ID) of O-DU#2 212 is a back-up for O-DU#1 211 cells, when O-DU #1 211 fails, SMO 200 may trigger a resiliency use-case and request O-DU#2 212 to take over and then transition the carrier(s). Subsequently, O-DU#2 212 could setup F1AP configuration request to O-CU 210, as it has preconfigured cell(s) (NRCellDU(s)) / carrier(s) (NRSectorCarrier(s)). Once the NRSectorCarriers of 0-DU#2212 become active and ready, SMO 200 / 0-CU 210 could unlock the preconfigured NRCellDU(s) in O-DU#2 212 by setting“administrative State” as “Unlocked”. Now, the UE may see different Cell IDs for the same carriers,which is unavoidable as the carriers could not be configured with same Cell IDs in both O-DU#1 211 and O-DU#2 212.

[0066] At S8, shared O-RU 220 may continue to make a call-home (e.g., to 0-DU #1 211) until it re-establishes a NETCONF session with 0-DU #1 211. After recovery of the session, O- DU #1 211 may continue to have a NETCONF session with supervision activated to shared O-RU 220 (e.g., after failure and NR cell / carrier transition). In this scenario, a RPC for “re-call-home- activation” could come from SMO 200 via O-DU #2 212 as soon as SMO 200 knows about the availability of O-DU #1 211.

[0067] According to embodiments, the reconnect strategy which may occur in S8 may be implemented by SMO 200 / DHCP server 230 / the NETCONF clients of the currently active O-DU #2 212 to send a RPC restart-call-home to simply tell shared O-RU 220 that it may now renew the outdated / failed / closed NETCONF session with now O-DU #1 211, from which shared O-RU 220 was associated with prior to the failure. According to some embodiments, SMO 200 may send RPC restart-call-home via O-DU #2212 as soon as it is aware that O-DU #1 211 recovered / became operational / became active. According to embodiments, O-DU #2 212 may configure settings via an edit-config RPC for the shared O-RU 220 as to how frequent re-call-home attempt should be made. Once a NETCONF session with O-DU #1 211 is re-established for Shared O-RU 220, Shared O-RU 220 may cancel alarm #35 (the supervision failure alarm as described above) which is associated with the respective NETCONF session, and send a notification (e.g., via o-ran operations. yang to SMO 200 via the O-DU #1 211 or O-DU #2 212, or to SMO 200 directly.

[0068] It should be appreciated that S8 may not necessarily occur subsequent or synchronous to S7, and rather S8 may be performed any time after failure occurs in S5.

[0069] According to embodiments, fault / exception handling may be implemented for the method described in S1-S8 above. This may include, but may not necessarily be limited to:

[0070] (a) A shared O-RU 220 may restart / switch during a switch-over / transition between0-DU #1 211 and 0-DU #2 212;

[0071] (b) 0-DU #2212 may become unavailable during the transition;

[0072] (c) Common / management and carrier specification configurations may not have been performed properly during transition or after transition;

[0073] (d) O-DU #2 212 may lose the configuration data from a configuration replica or receive incomplete configuration data from SMO 200 or retrieval of configuration from shared O- RU 220 may fail;

[0074] (e) O-DU #1 211 (as the active O-DU) may return to operation while O-DU #2212(as the standby O-DU) is attempting to become the active O-DU; and / or

[0075] (f) if the connectivity or functionality of the management system (e.g., SMO 200) becomes unavailable.

[0076] Nevertheless, it should be appreciated that other fault management may be implemented as appropriate by a person skilled in the art, depending on the specific implementation(s).

[0077] According to embodiments, it may be possible for O-DU #1 211 and O-DU #2212 to be connected to the same router / clock source, and hence synchronization of shared O-RU 220 and O-DU #1 211 and 0-DU #2 212 may be aligned without issue (LLS-C3 (Clock in Router). In this scenario, the sync / clock source will be common for both O-DU #1 211 and O-DU #2 212 as well as shared O-RU 220.

[0078] According to embodiments, LLS-C1 (Lower Layer Split Control -plane) deployment may be implemented, and shared 0-RU 220 may manage and align the carriers of the respective O-DU with their associated synchronization plane clocks.

[0079] According to embodiments, performance management may need to be considered when transitioning between O-DU #1 211 and O-DU #2 212. O-DU #1 211 may be responsible for configuring performance measurement for Shared 0-RU 220 while it is the active O-DU. In this case, O-DU #2 212 as the standby O-DU could use a get RPC to read performance management configuration which is performed by O-DU #1 211 in shared O-RU 220. According to embodiments, an “ru-elements” list (for example, in o-ran-processing-elements.yang module) may be defined for both O-DU #1 211 and O-DU #2 212. “ru-elements” list may be used for retrieving the respective performance management configurations.

[0080] Back-up O-DU’s (e.g., at least O-DU #2 212) may subscribe to the shared 0-RU 220’s performance management counter related notifications (e.g., O-DU #2 212 subscribes to performance counter notifications). As an example, packet delay for shared 0-RU 220 could be poor during its association with O-DU #1 211. After transition from O-DU #1 211 to O-DU #2 212, O-DU #2 212 could rectify packet delay based on history / current performance counters received from either shared O-RU 220 or SMO 200. A management entity (such as SMO 200) may still have the shared O-RU 220’s performance counter measurement reports associated to O- DU #1 211. Hence, shared O-RU 220’s performance counters associated with O-DU #1 211 may need to be flashed / removed when O-DU #2 takes over shared O-RU 220. To this end, O-DU #2 212 could flash / delete the entire performance counter / KPI associated with O-DU #1 211 stored in shared O-RU 220, by sending an RPC delete / delete-config. O-DU #2212 may also get and analysethe shared O-RU 220’s performance counters associated with O-DU #1 211 during / after the transition. If there are no issues, O-DU #2212 could activate TX / RX array carriers 330 (described with reference to FIG. 3 below), or after mitigating any existing issues O-DU #2212 may perform a reset, etc.

[0081] According to embodiments, shared O-RU 220 may have a capability to flash the performance counters associated with O-DU #1 211 after sharing. / reporting the same to SMO 200 and / or O-DU #2 212. Once O-DU #2 212 takes over the shared O-RU 220, O-DU #2 212 may become responsible for reporting associated performance counters.

[0082] It should be appreciated that timer / performance counters could be divided between O-DU #1 211 and O-DU #2 212 based on severity and availability. For instance, in some embodiments, performance counters associated with active carriers of O-DU #1 211 and inactive carriers of O-DU #2 212 could be reported accordingly.

[0083] FIG. 3 illustrates an example data structure for carrier configurations according to an embodiment. Low level TX / RX links 300, which may comprise processing element 310, low level TX / RX endpoint 320, static low level TX / RX endpoint 321, and TX / RX array carriers 330 may be provided. The configuration illustrated in FIG. 3 may be a rw user-plane configuration, according to embodiments.

[0084] According to embodiments, a list of low-level TX / RX links 300 may be created so that the same carriers between an active O-DU (e.g., O-DU #1 211) and a shared O-RU (e.g., shared O-RU 220) may be associated with O-DU #2 212. Accordingly, odu-id string may be included in low-level TX / RX links.

[0085] Processing element 310 may be a data structure used to distinguish the specific processing elements associated with an active / standby 0-DU (i.e., 0-DU #1 211 and 0-DU #2 212 described with reference to FIG. 2 above), nevertheless it should be appreciated that there may be an N number of standby O-DU’s according to embodiments. Processing element 310 may be in the format of a list, and each entry in the list may refer to a corresponding processing element associated with a shared O-RU / multiple O-DU’s, wherein an odu-id string may be used to identify a specific 0-DU.

[0086] According to embodiments, carrier pre-configuration (e.g., pre- configuring a list of carriers associated with both the active / standby 0-DU) may be performed using a list of processing element 310, which are specific to each of the active / standby 0-DU. This may be achieved since the respective odu-id string and / or the 0-DU unique name may be listed in a list of processing element 310. For example, an active 0-DU (e.g., 0-DU #1 211) may configure a list of RU- elements for one of the standby O-DU’s (e.g., 0-DU #2 212) based on an agreed upon 0-DU transport identifier value. Each of the elements may have a corresponding odu-id parameter, which is set to the value allocated to the standby 0-DU. In this scenario, the odu-id may be included (for example, in the o-ran-processing-elements.yang module).

[0087] According to embodiments, processing element 310 may include MAC addresses of the active / standby 0-DU as well as the shared 0-RU, such that processing element 310 may be mapped to appropriate Shared 0-RU. Similarly, the active / standby O-DU’s may have the IP addresses defined.

[0088] Low level TX / RX endpoints 320 may map endpoints with the active / standby O-DU’s, and said mapping may be performed by Low level TX / RX links 300 associating theirrespective odu-id strings with the appropriate TX / RX array carriers 330. The odu-id may particularly be included in order to support SHARED-ORU-MULTLODU feature. According to embodiments, low-level TX / RX endpoints 320 may include an o-du-port-bitmask parameter for an extended antenna-carrier identifier (eAXC-ID), so as map endpoints with both the active / standby O-DU’s. Static low level TX / RX endpoint 321 may be specific to a given 0-RU vendor / manufacturer, and may have a one-to-one mapping with low level TX / RX endpoints 320. Static low level TX / RX endpoint 321 may be configured by a given 0-RU (such as shared 0-RU) as a read-only parameter, which a given O-DU may not be able to configure / write to. In addition, a low level TX / RX endpoint 320 may be created by a given O-DU based on Static low level TX / RX Endpoint 321 of O-RU, and the given O-DU can configure or modify the Low-Level TX / RX endpoints 320.

[0089] According to embodiments, an eAXC ID bitwidth may be configured by the respective NETCONF client. The same carriers may not have a similar eAXC ID mapped to both the active / standby O-DU and then activated. Since the odu-port-mask for the standby (e.g., O-DU #2 212) O-DU, there may be a change in the eAXC ID bitwidth. In this scenario, the carriers may be pre-configured with an eAXC ID of different bitwidth, and carriers pertaining to the standby (e g., O-DU #2 212) O-DU may be inactive.

[0090] TX / RX array carriers 330 may be a data structure used to represent carriers which are configured between an active O-DU (e g., O-DU #1 211) and a shared O-RU (e.g., O-RU 220) and could have a duplicated instance, or be preconfigured for the standby O-DU (e.g., O-DU #2212) using an odu-id string.

[0091] According to embodiments, TX / RX array carriers 330 list entries may be created by an active O-DU (e.g., 0-DU #1 211) in relation to the TX / RX array carriers 330 list entries used by a standby 0-DU (e.g., 0-DU #2 212) in the case of active O-DU’s failure. Each of the list entries may have a corresponding odu-id of the standby 0-DU configured in a list of odu-ids associated with TX / RX array carriers 330. Accordingly, odu-id string in TX / RX array carriers 330 may be employed to map the same carriers between the active 0-DU and the standby 0-DU.

[0092] According to embodiments, prior to the active 0-DU (e.g., 0-DU #1 211) failing, carriers associated with the active 0-DU may be configured, and active in the shared 0-DU, and carriers associated with the standby 0-DU (e.g., 0-DU #2 212) may be preconfigured but not active. When active 0-DU fails, the associated carriers may either be deactivated by the shared O- RU itself, or the standby 0-DU may send an RPC setting the appropriate TX / RX array carriers 330 entry (active setting) to “inactive”. When deactivating or deleting active 0-DU associated carriers, the odu-id string may be utilized in order to differentiate between carriers associated with the active / standby 0-DU. The standby 0-DU may already know, and identify the TX / RX array carriers 330 entry associated with the active 0-DU with odu-id string reference in carrier parameters, and hence the standby 0-DU (to-be transitioned to) may delete / deactivate TX / RX array carriers 330 entries associated with odu-id of the active 0-DU (to be transitioned away from).

[0093] According to embodiments, a first 0-DU (e.g., 0-DU #1 211) may create a list of entries for Low level TX / RX links 300, which may comprise processing element 310, low level TX / RX endpoint 320, and TX / RX array carriers 330 as described above. A uniquely configured name and / or one or more configured odu-id strings may be provided therewith. The odu-id stringsmay be used to generate the links and array carriers between a second O-DU (e.g., O-DU #2 212) and a shared O-RU (e.g., shared O-RU 220), according to embodiments.

[0094] According to embodiments, an O-DU may push the u-plane configuration file (e.g., Low level TX / RX links 300, which may comprise processing element 310, low level TX / RX endpoint 320, and TX / RX array carriers 330 as described above) as associated with their respective odu-ids of the active / stand-by O-DU, to the shared O-RU. According to embodiments, a NETCONF.yang may be responsible for merging configurations into a single file, since there may exist a common EARFCN (E-UTRA Absolute Radio Frequency Channel Number) and some other parameters between configurations. The configuration file in the shared O-RU may accordingly have the carrier configuration associated with both the active / stand-by O-DU’s. During transition from the active to the standby O-DU, the standby O-DU could activate the carriers associated with its “odu-id” string by setting the associated array carrier 330 to “active”. Subsequently, the shared O-RU may set the appropriate array-carrier 330 state as “enabled”, and notify the O-DU about the state change (i.e., the carrier state is ready). This change may be taken care of by the low level TX / RX links 300, as the processing elements 310 list of entries may be defined for both the active / standby O-DU’s based on MAC Address / IP Address. Accordingly, there may be no new hardware requirements for storing separate carrier configuration files associated with the standby O-DU (i.e., O-DU #2 212).

[0095] FIG. 4 illustrates a method 400 for implementing a shared O-RU system for resiliency according to an embodiment.

[0096] At operation 401, a shared O-RU (e.g., shared O-RU 220) may receive access details of a first O-DU (e.g., O-DU #1 211) from an SMO (e.g., SMO 200). According toembodiments, the SMO may have been configured to identify the first O-DU and the second O- DU based on an O-DU identifier (odu-id as referred to with reference to FIG. 2, 3 above) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the received access details of the first O-DU ( and the second O-DU in operation 403) may include the IP address and odu-id / sro-id of the respective O-DU. The carrier configuration of each of the first O-DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.

[0097] In this implementation, the first O-DU may be an active / primary / host O-DU, and the second O-DU may be a standby / secondary / tenant O-DU. In addition, it should be emphasized that the second O-DU may have either the same or different performance capability as the first O- DU. For an example with the O-DU’s having different performance capabilities, the first O-DU may be able to configure 4 tx / rx array-carriers but the second O-DU may only be able to configure 2 tx / rx-array-carriers in the Shared 0-RU just to restore the service. In that case, the second O-DU may recover the Shared 0-RU and perform carrier configurations (to the extent it can).

[0098] At operation 402, the O-RU may call the first O-DU based on the details received in operation 401, in order to establish a NETCONF session, activate a carrier configuration with the first O-DU, and subscribe to alarms and notification with the first O-DU.

[0099] At operation 403, the shared 0-RU may receive access details of a second O-DU (e g., O-DU #2212). As mentioned with reference to operation 401, the details may include the IP address and odu-id / sro-id of the second O-DU.

[0100] At operation 404, failure / schedule maintenance may be detected of the first 0-DU (for example, by the SMO), such that the shared 0-RU may call the second 0-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O- RU, and instruct the second 0-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first 0-DU. According to embodiments, the carrier configuration of the second 0-DU may be pre-configured in the shared 0-RU, or the SMO may be configured to push the carrier configuration of the second 0-DU to the second 0-DU to configure in the shared 0-RU. The carrier configurations of the first / second 0-DU may include a list of processing elements; a list of low-level tx / rx (transmit / receive) links; a list of low-level tx / rx endpoints; and a list of tx / rx array-carriers (see FIG. 3 above).

[0101] In other embodiments, carrier configuration of the second 0-DU may instead be actively configured by a start-up procedure with the shared 0-RU.

[0102] In operation 404, calling home the second 0-DU may include retrieving the carrier configuration of the first 0-DU; modifying the carrier configuration of the first O-DU according to the second 0-DU (to obtain a carrier configuration for the second 0-DU), and deactivating carriers associated with the carrier configuration of the first O-DU.

[0103] At operation 405, the shared 0-DU may re-call home the first 0-DU based on a RPC received from the SMO in order to re-establish a NETCONF session with the first 0-DU. This may occur after operation 404 according to some embodiments.

[0104] Based on the above embodiments, resiliency for shared O-RU / multiple 0-DU systems can be improved in various aspects including, but not limited to, improving scenariodetection / handling from the SMO, improving efficiency of carrier configuration data, and improving carrier transfer between active / stand-by O-DU’s for a given shared O-RU.

[0105] FIG. 5 is a diagram of an example environment 500 in which systems and / or methods, described herein, may be implemented. As shown in FIG. 5, environment 500 may include a user device 510, a platform 520, and a network 530. Devices of environment 500 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described with reference to FIGS. 1-4 above may be performed by any combination of elements illustrated in FIG. 5.

[0106] User device 510 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 520. For example, user device 510 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. In some implementations, user device 510 may receive information from and / or transmit information to platform 520.

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

[0108] In some implementations, as shown, platform 520 may be hosted in cloud computing environment 522. Notably, while implementations described herein describe platform520 as being hosted in cloud computing environment 522, in some implementations, platform 520 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

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

[0110] Computing resource 524 includes one or more personal computers, a cluster of computing devices, workstation computers, server devices, or other types of computation and / or communication devices. In some implementations, computing resource 524 may host platform 520. The cloud resources may include compute instances executing in computing resource 524, storage devices provided in computing resource 524, data transfer devices provided by computing resource 524, etc. In some implementations, computing resource 524 may communicate with other computing resources 524 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0111] As further shown in FIG. 5, computing resource 524 includes a group of cloud resources, such as one or more applications (“APPs”) 524-1, one or more virtual machines (“VMs”) 524-2, virtualized storage (“VSs”) 524-3, one or more hypervisors (“HYPs”) 524-4, or the like.

[0112] Application 524-1 includes one or more software applications that may be provided to or accessed by user device 510. Application 524-1 may eliminate the need to install and executethe software applications on user device 510. For example, application 524-1 may include software associated with platform 520 and / or any other software capable of being provided via cloud computing environment 522. In some implementations, one application 524-1 may send / receive information to / from one or more other applications 524-1, via virtual machine 524-2.

[0113] Virtual machine 524-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 524-2 may be either a system virtual machine or a process virtual machine, depending upon use and degree of correspondence to any real machine by virtual machine 524-2. A system virtual machine may provide a complete system platform that supports execution of a complete operating system (“OS”). A process virtual machine may execute a single program, and may support a single process. In some implementations, virtual machine 524-2 may execute on behalf of a user (e.g., user device 510), and may manage infrastructure of cloud computing environment 522, such as data management, synchronization, or long-duration data transfers.

[0114] Virtualized storage 524-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of computing resource 524. In some implementations, within the context of a storage system, types of virtualizations may include block virtualization and file virtualization. Block virtualization may refer to abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed without regard to physical storage or heterogeneous structure. The separation may permit administrators of the storage system flexibility in how the administrators manage storage for end users. File virtualization may eliminate dependencies between data accessed at a file level and a location where files are physically stored. This may enableoptimization of storage use, server consolidation, and / or performance of non-disruptive file migrations.

[0115] Hypervisor 524-4 may provide hardware virtualization techniques that allow multiple operating systems (e.g., “guest operating systems”) to execute concurrently on a host computer, such as computing resource 524. Hypervisor 524-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of a variety of operating systems may share virtualized hardware resources.

[0116] Network 530 includes one or more wired and / or wireless networks. For example, network 530 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., 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, and / or a combination of these or other types of networks.

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

[0118] FIG. 6 illustrates an embodiment of a device 600. As shown in FIG. 6, the device 600 processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670.

[0119] The processor 610, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 610 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 610 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.

[0120] Memory 620 includes a non-transitory computer readable medium. Memory 620 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 610. The memory 620 comprises machine-readable instructions which are executable by the processor 610. These machine-readable instructions when executed by the processor 610 cause the processor 610 to perform one or more method steps of an embodiment described above.

[0121] Storage component 630 stores information and / or software related to the operation and use of the device 600. For example, storage component 630 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.

[0122] Input component 640 is configured to receive information, such as user input. For example, the input component 640 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 640 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0124] Communication interface 660 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 660 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 600 and other devices. In other words, the standard of the communication interface 660 is not limited.

[0125] The bus 670 acts as an interconnect between the processor 610, the memory 620, the storage component 630, the input component 640, the output component 650, and the communication interface 660 of the device 600. The bus 670 may include a wired interconnection or a wireless interconnection.

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

[0127] In embodiments, any one of the operations or processes of FIGS. 1-4 may be implemented by or using any one of the elements illustrated in FIGS. 5 and 6. It is understood that other embodiments are not limited thereto, and may be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture such as Kubernetes, Docker, OpenStack, etc ).

[0128] 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.

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

[0130] The computer readable storage medium can be a tangible device that can retain andstore 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), 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.

[0131] 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 readablestorage medium within the respective computing / processing device.

[0132] 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. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a standalone 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.

[0133] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing thefunctions / 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.

[0134] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device 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.

[0135] 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 microservice(s), module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed inthe 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.

[0136] 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 limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0137] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item

[0001] A method including: receiving, by a shared Open Radio Access Network (0-RAN) radio unit (O-RU) from Service Management and Orchestration (SMO), access details of a first 0-RAN distributed unit (0-DU); calling home, by the shared O-RU, the first 0-DU based on the received access details of the first 0-DU to establish a network configuration protocol (NETCONF) session with the first 0-DU, activate a carrier configuration with the first 0-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (0-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on aninstruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.Item [2]: The method according to Item [1], wherein the SMO is configured to identify the first O-DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O-DU may include the IP address and odu-id / sro-id of the respective O-DU .Item [3]: The method according to any one of Items [l]-[2], wherein the carrier configuration of the second O-DU is pre-configured in the shared O-RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.Item [4]: The method according to Item [2], wherein the carrier configuration of each of the first O-DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.Item [5]: The method according to any one of Items [l]-[4], wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RUItem [6]: The method according to any one of Items [l]-[5], wherein calling home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU may include: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O-DU to obtain a carrier configuration for the second O-DU; and deactivating carriers associated with the carrier configuration of the first O-DU.Item [7]: The method according to any one of Items [ l]-[6], further including; re-call home the first O-DU by the shared O-RU, based on a remote procedure call (RPC) received from the SMO, to re-establish the NETCONF session with the first O-DU.Item [8]: A shared Open Radio Access Network (O-RAN) radio unit (O-RU), configured to: receive from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); call home the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receive, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenantO-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.Item [9]: The shared O-RU according to Item [8], wherein the SMO is configured to identify the first O-DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O-DU may include the IP address and odu-id / sro-id of the respective O-DU .Item

[0010] : The shared O-RU according to any one of Items [8]-[9], wherein the carrier configuration of the second O-DU is pre-configured in the shared O-RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.Item

[0011] : The shared O-RU according to Item [9], wherein the carrier configuration of each of the first O-DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.Item

[0012] : The shared O-RU according to any one of Items [8]-[l 1], wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RUItem

[0013] : The shared O-RU according to any one of Items [8]-

[0012] , wherein the shared O- RU is further configured to call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU and instruct the second O- DU to activate a carrier configuration of the second O-DU over the carrier configuration from thefirst O-DU by: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O-DU to obtain a carrier configuration for the second O-DU; and deactivating carriers associated with the carrier configuration of the first O- DU.Item

[0014] : The shared O-RU according to any one of Items [8]-[l 3], further configured to; re-call home the first O-DU based on a remote procedure call (RPC) received from the SMO, to re-establish the NETCONF session with the first O-DU.Item

[0015] : At least one non-transitory computer-readable recording medium having recorded thereon instructions executable to implement a method including: receiving, by a shared Open Radio Access Network (O-RAN) radio unit (O-RU) from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); calling home, by the shared O-RU, the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.Item

[0016] : The at least one non-transitory computer-readable recording medium according to Item

[0015] , wherein the SMO is configured to identify the first O-DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O-DU may include the IP address and odu- id / sro-id of the respective O-DU .Item

[0017] : The at least one non-transitory computer-readable recording medium according to any one of Items

[0015] -

[0016] , wherein the carrier configuration of the second O-DU is preconfigured in the shared O-RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.Item

[0018] : The at least one non-transitory computer-readable recording medium according to Item

[0016] , wherein the carrier configuration of each of the first O-DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.Item

[0019] : The at least one non-transitory computer-readable recording medium according to any one of Items

[0015] -

[0018] , wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RU.Item

[0020] : The at least one non-transitory computer-readable recording medium according to any one of Items

[0015] -

[0019] , wherein call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU may include: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O-DU to obtain a carrier configuration for the second O-DU; and deactivating carriers associated with the carrier configuration of the first O-DU.

[0138] 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 IS1. A method comprising: receiving, by a shared Open Radio Access Network (O-RAN) radio unit (O-RU) from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); call home, by the shared O-RU, the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU, based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

2. The method as claimed in claim 1, wherein the SMO is configured to identify the first O- DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resourceoperator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O-DU comprises the IP address and odu-id / sro-id of the respective O-DU .

3. The method as claimed in claim 1, wherein the carrier configuration of the second O-DU is pre-configured in the shared O-RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.

4. The method as claimed in claim 2, wherein the carrier configuration of each of the first O- DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.

5. The method as claimed in claim 1, wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RU.

6. The method as claimed in claim 1, wherein call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O- RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU comprises: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O-DU to obtain a carrier configuration for the second O-DU; anddeactivating carriers associated with the carrier configuration of the first O-DU.

7. The method of claim 1, further comprising; re-call home the first O-DU by the shared O-RU, based on a remote procedure call (RPC) received from the SMO, to re-establish the NETCONF session with the first O-DU.

8. A shared Open Radio Access Network (O-RAN) radio unit (O-RU), configured to: receive from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); call home the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receive, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; and upon the SMO detecting failure or scheduled maintenance of the first O-RU, call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

9. The shared O-RU as claimed in claim 8, wherein the SMO is configured to identify the first O-DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O- DU comprises the IP address and odu-id / sro-id of the respective O-DU .

10. The shared O-RU as claimed in claim 8, wherein the carrier configuration of the second O-DU is pre-configured in the shared O-RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.

11. The shared O-RU as claimed in claim 9, wherein the carrier configuration of each of the first O-DU and the second O-DU may be differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.

12. The shared O-RU as claimed in claim 8, wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RU.

13. The shared O-RU as claimed in claim 8, wherein the shared O-RU is further configured to call home the second O-DU based on an instruction sent from the SMO to instructthe second O-DU to take over control of the shared O-RU and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU by: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O- DU to obtain a carrier configuration for the second O-DU; and deactivating carriers associated with the carrier configuration of the first O-DU.

14. The shared O-RU of claim 1, further configured to; re-call home the first O-DU based on a remote procedure call (RPC) received from the SMO, to re-establish the NETCONF session with the first O-DU.

15. At least one non-transitory computer-readable recording medium having recorded thereon instructions executable to implement a method comprising: receiving, by a shared Open Radio Access Network (O-RAN) radio unit (O-RU) from Service Management and Orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); calling home, by the shared O-RU, the first O-DU based on the received access details of the first O-DU to establish a network configuration protocol (NETCONF) session with the first O-DU, activate a carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; andupon the SMO detecting failure or scheduled maintenance of the first O-RU, calling home, by the shared O-RU, the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU, wherein the first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU, and the second O-DU may have either the same or different performance capability as the first O-DU.

16. The at least one non-transitory computer-readable recording medium as claimed in claim 15, wherein the SMO is configured to identify the first O-DU and the second O-DU based on at least one of an O-DU identifier (odu-id) or a shared resource operator identifier (sro-id), wherein the odu-id or sro-id represents a string and / or a unique name of the respective O-DU, wherein the details of the first O-DU and the second O-DU comprises the IP address and odu- id / sro-id of the respective O-DU .

17. The at least one non-transitory computer-readable recording medium as claimed in claim 15, wherein the carrier configuration of the second O-DU is pre-configured in the shared O- RU, or the SMO is configured to push the carrier configuration of the second O-DU to the second O-DU to configure in the shared O-RU.

18. The at least one non-transitory computer-readable recording medium as claimed in claim 16, wherein the carrier configuration of each of the first O-DU and the second O-DU maybe differentiated using the respective odu-id in a single operator deployment, or differentiated using the respective sro-id in a multiple operator deployment.

19. The at least one non-transitory computer-readable recording medium as claimed in claim 15, wherein the carrier configuration of the second O-DU is actively configured by a startup procedure with the shared O-RU.

20. The at least one non-transitory computer-readable recording medium as claimed in claim 15, wherein call home the second O-DU based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU, and instruct the second O-DU to activate a carrier configuration of the second O-DU over the carrier configuration from the first O-DU comprises: retrieving the carrier configuration of the first O-DU; modifying the carrier configuration of the first O-DU according to the second O- DU to obtain a carrier configuration for the second O-DU; and deactivating carriers associated with the carrier configuration of the first O-DU.

Images