Shared Open RAN Radio Unit Resiliency

Abstract

A method, apparatus, and system may be disclosed for resiliency in a multiple O-DU system that may include receiving, by a shared O-RAN radio unit, details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); calling home to 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 carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; receiving details of a second O-RAN DU (O-DU) from the SMO; and, upon the SMO detecting a failure or scheduled maintenance of the first O-RU, calling home to the second O-DU based on instructions from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate carrier configuration for the second O-DU via the carrier configuration from the first O-DU.

Description

[Technical Field]

[0001] The present disclosure relates to resiliency of a shared Open-RAN (O-RAN) Radio Unit (RU). [Background technology]

[0002] The information disclosed in this Background section of the present disclosure is intended only to enhance understanding of the general background of the present disclosure and should not be construed as an admission or any form of suggestion that this information forms prior art already known to those skilled in the art.

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

[0004] Open RAN (O-RAN) technology is emerging to allow multiple vendors to provide hardware and / or software for telecommunication systems. Because different vendors are involved, the types of hardware and / or software provided may also vary. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NEs may be virtualized in software form (e.g., virtual machine (VM)-based) or may be physical hardware form (e.g., non-VM-based).

[0005] To this end, O-RAN divides 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 the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) lower layers of the RAN. The DU may be a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) lower layers of the RAN. The RU may be a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul. These entities can be developed by different vendors due to the open protocols and interfaces between them.

[0006] Figure 1 shows an O-RAN architecture in the related art. RAN functions in the O-RAN architecture can be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC can be a software-defined component that implements modular applications to facilitate multivendor operability required in an O-RAN system and to automate and optimize RAN operations. As shown in Figure 1, the RIC can 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 a control point for non-real-time control loops and may operate on greater than one second timescales within the Service Management and Orchestration (SMO) framework 110. Its functionality may be implemented via modular applications called rApps and may include providing policies based on guidance and enrichment over the A1 interface, which is an interface that enables communication between non-RT RICs and quasi-RT RICs, performing data analytics, artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization, and / or recommending configuration management actions over the O1 interface, which may be an interface that connects the SMO to RAN managed elements (e.g., quasi-RT RIC 130, O-RAN Centralized Units (O-CUs) 140, 150, O-RAN Distributed Units (O-DUs) 170, etc.).

[0008] The quasi-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled to the O-DU 170, the O-CU (split into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and the open evolved NodeB (O-eNB) 160 via an E2 interface. The quasi-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) via near-real-time control loops. The quasi-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 quasi-RT RIC 130 may set policy parameters regarding activated functions of the E2 nodes. Additionally, the semi-RT RIC 130 may host xApps that implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security.

[0009] Here, the O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via an E1 interface, and may be coupled to the O-DU 170 via an F1-c interface and an F1-u interface, respectively. Furthermore, the O-RU 180 may be coupled to the O-DU 170 via an open fronthaul (OF) control (C) plane, user (U) plane, synchronization (S) plane, and management (M) plane, and may be coupled to the SMO 110 via the OF M plane.

[0010] The two types of RICs work together to optimize O-RAN. For example, the non-RT RIC 120 may provide policies, data, and AI / ML models that are implemented and used by the quasi-RT RIC 130 for RAN optimization, and the quasi-RT RIC 130 may return policy feedback (i.e., how the policies set by the non-RT RIC 120 are performing).

[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 190 may be a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO 110 itself. In other words, the SMO 110 may manage the O-Cloud 190 from within. The O2 interface may be an interface between the SMO 110 and the O-Cloud 190 on which it resides. Through the O2 interface, the SMO 110 may provide infrastructure management services (IMS) and deployment management services (DMS).

[0012] In the related art, multiple O-DUs (which may have a configuration similar to that of the O-DU 170) may be implemented to implement a multiple O-DU system for resilience (e.g., if one of the O-DUs fails, there is a backup O-DU). For this purpose, a shared O-RU (which may have a configuration similar to that of the O-RU 180) may be configured to operate between multiple O-DUs. Summary of the Invention [Problem to be solved by the invention]

[0013] Related art use cases that use a shared O-RU for resiliency may not clearly define (in the current specification) how details (such as carrier configuration) are shared between entities in a multiple O-DU system (e.g., multiple O-DUs, SMOs, shared O-RUs). In particular, it may not be clearly defined how to implement pre-configured carrier configurations for multiple O-DUs in related art systems. [Means for solving the problem]

[0014] According to embodiments of the present disclosure, a method, apparatus, and system for resiliency in a shared O-RU system may be provided. The method may include receiving, by a shared open radio access network (O-RAN) radio unit (O-RU), access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO), calling home, by the shared O-RU, to 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 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 calling home, by the shared O-RU, to the second O-DU based on the command sent from the SMO when the SMO detects a failure or scheduled maintenance of the first O-RU. The instructions instruct the second O-DU to take over control of the shared O-RU and instruct the second O-DU to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. The first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU. The second O-DU may have the same or different performance capabilities as the first O-DU.

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

[0016] According to an embodiment of the present disclosure, a shared open radio access network (O-RAN) radio unit (O-RU) may be provided. The shared O-RU may be configured to receive access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO), establish a network configuration protocol (NETCONF) session with the first O-DU, activate carrier configuration with the first O-DU, and call home to the first O-DU based on the received access details of the first O-DU to subscribe to alarms and notifications with the first O-DU, receive access details of a second O-RAN DU (O-DU) from the SMO, and call home to the second O-DU based on instructions sent from the SMO when the SMO detects a failure or scheduled maintenance of the first O-RU. The instructions instruct the second O-DU to take over control of the shared O-RU and instruct the second O-DU to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. The first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU. The second O-DU may have the same or different performance capabilities as the first O-DU.

[0017] According to an embodiment of the present disclosure, at least one non-transitory computer-readable storage medium having executable instructions stored thereon for performing a method may be provided, the method including receiving, by a shared open radio access network (O-RAN) radio unit (O-RU), access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO), calling home, by the shared O-RU, to 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 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 calling home, by the shared O-RU, to the second O-DU based on the instructions sent from the SMO when the SMO detects a failure or scheduled maintenance of the first O-RU. The instructions instruct the second O-DU to take over control of the shared O-RU and instruct the second O-DU to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. The first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU. The second O-DU may have the same or different performance capabilities 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 learned by practice of the presented embodiments of the present disclosure.

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

[0020] [Figure 1] FIG. 1 illustrates an O-RAN architecture according to the related art. [Figure 2] 1 illustrates a system architecture diagram of a shared O-RU system for resiliency, according to one embodiment.

[0021] [Figure 3] FIG. 2 illustrates an exemplary data structure for a carrier configuration, according to one embodiment.

[0022] [Figure 4] FIG. 1 illustrates a method for implementing a shared O-RU system for resiliency, according to one embodiment.

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

[0024] [Figure 6] FIG. 2 is a diagram of exemplary components of a device, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0026] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

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

[0028] No element, act, or instruction used herein should be construed as critical or required unless expressly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise. Furthermore, phrases such as "at least one of A and B" and "at least one of A or B" should be understood to include A only, B only, or both A and B.

[0029] According to embodiments, a method, apparatus, and system for resiliency in a shared O-RU system may be provided, the method including receiving, by a shared Open Radio Access Network (O-RAN) radio unit (O-RU) from a service management and orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); establishing, by the shared O-RU, a network configuration protocol (NETCONF) session with the first O-DU, activating carrier configuration with the first O-DU, and calling home to the first O-DU based on the received access details of the first O-DU to subscribe to alarms and notifications with the first O-DU; and receiving, by the shared O-RU from the SMO, access details of a second O-RAN distributed unit (O-DU). and receiving access details of an O-DU (O-RU) and, when the SMO detects a failure or scheduled maintenance of the first O-RU, calling home by the shared O-RU to the second O-DU based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. The first O-DU is an active / primary / host O-DU, and the second O-DU is a standby / secondary / tenant O-DU. The second O-DU may have the same or different performance capabilities as the first O-DU.

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

[0031] 2 shows a system architecture diagram of a shared O-RU system for resiliency according to one embodiment. A service management and orchestration (SMO) 200, an O-CU#1 210, an O-DU#1 211, an O-DU#2 212, a shared O-RU 220, and a DHCP server 230 may be provided. While only one O-CU (O-CU#1 210) and two O-DUs ("active / host / primary" O-DU#1 211 and "standby / tenant / secondary" O-DU#2 212) are shown, it should be understood that two or more O-CUs and three or more O-DUs may be included depending on the specification implementation (e.g., a single primary O-DU may be paired with multiple standby O-DUs, such as a primary active O-DU and a primary standby O-DU, or multiple operators may be provided, and in the case of multiple O-DUs, sro-id (in the case of a multiple operator deployment) and / or odu-id (in the case of a single operator deployment) may be implemented to identify individual O-DUs, as described in further detail below). It should also be understood that the shared O-RU 220 may be referred to interchangeably as a "shared resource operator" (SRO).

[0032] It should also be understood that the terms “active / host / primary” may be used to refer to the O-DU#1 211, and “standby / tenant / secondary / backup” may be used to refer to the O-DU#2 212, but these terms are based on the operational states of the O-DU#1 211 and the ODU#2 212. Accordingly, if the O-DU#1 211 fails, the O-DU#1 211 may be called a “secondary / standby / backup” O-DU, and the O-DU#2 212 may be called in an “active” state, etc.

[0033] The SMO 200 may communicate with the O-CU#1 210, the O-DU#1 211, the O-DU#2 212, and the shared O-RU 220 via the DHCP server 230.

[0034] The O-DU#1 211 may be referred to as the active / host / master O-DU, and the O-DU#2 212 may be referred to as the standby / tenant / slave O-DU. In other words, the shared O-RU 220 may be intended to initially connect to the O-DU#1 211 as the main O-DU, while the O-DU#2 212 serves as a backup for resilience (e.g., in case of failure / planned maintenance of the O-DU#1 211). The O-DU#1 211 and the O-DU#2 212 may optionally have an inter-O-DU management interface and / or a traffic interface to provide communication between the two O-DUs.

[0035] In the scenario shown in Fig. 2, the following prerequisites may be assumed: First, the shared O-RU 220 should support the SHARED-ORU-MULTI-ODU function. Second, the O-DU#1 211 and the O-DU#2 212 should be connected to the same O-CU (e.g., the O-CU#1 210 illustrated in Fig. 2).

[0036] In S1, the SMO 200 may identify the O-DU#1 211 and the O-DU#2 212. This may be done based on an "odu-id" string and / or a unique name in the O-DU. The odu-id may be defined in various naming schemes, including but not necessarily limited to the following:

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

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

[0039] (c) A string or strings in 2 / 3 octet format to distinguish or identify active and standby O-DUs (see, for example, the PLMN ID defined in section 9.3.3.5 of the 3GPP TS 38.413 specification).

[0040] It should be understood that the "odu-id" string defined above may also be used in the case of a single operator, where the shared O-RU 220 may support a "SHARED-ORU-MULTI-ODU function" that assigns Net Configuration Protocol (NETCONF) access control privileges (e.g., the odu-id string may be included in the o-ran usermgmt.yang module for the multi-ODU function, such that the NETCONF client of O-DU#2 212 may be identified using the user list field in the o-ran-usermgmt.yang module). (Yang refers to Yet Another Generation, a data modeling language typically used for NETCONF, but it should be understood that yang may be used interchangeably with other data modeling languages ​​as needed). Additionally or alternatively, the SMO 200 may identify the O-DU#1 211 and the O-DU#2 212 using an “odu-id” string and / or some other unique O-DU name, which may be particularly useful when both the O-DU#1 211 and the O-DU#2 212 are mistakenly assigned as primary (i.e., in the case of a misassignment).

[0041] At S2, the shared O-RU 220 may call the SMO 200 (via the DHCP server 230) to obtain details about the O-DU#1 211, including the IP address of the O-DU#1 211 as well as the ODU-ID details.

[0042] In S3, the shared O-RU 220 may establish a persistent NETCONF session, activate carrier configuration with the O-DU#1 211, and call home to the O-DU#1 211 to subscribe to alarms and notifications with the O-DU#1 211. The NETCONF session with the O-DU#1 211 may have monitoring activation and "sudo" privilege-related configuration for the O-DU#1 211 (e.g., administrative / superuser privileges that allow the O-DU#1 211 to freely modify the configuration), according to an embodiment.

[0043] At S4, the shared O-RU 220 may first receive details about the O-DU#2 212 (which may include the IP address as well as the ODU-ID details of the O-DU#2 212) from the SMO 200. Methods for obtaining the details of the O-DU#2 212 may include, but are not necessarily limited to, the following:

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

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

[0046] The shared O-RU 220 may then call home to O-DU#2, which may establish a persistent NETCONF session and subscribe to configuration-related change notifications in the shared O-RU 220. At S4, O-DU#1 211 (acting as the primary O-DU) may use the o-ran-mplane-int yang model to configure the configured-clients-information container in the shared O-RU 220 with the IP address(es) of the NETCONF client(s) used by the backup O-DU(s) (such as, for example, O-DU#2 212, acting as the backup O-DU in the illustrated embodiment). According to some embodiments, O-DU#2 212 may only include carrier authority (e.g., NETCONF access control authority) and may not perform the actual carrier configuration. According to an embodiment, it should be understood that a NETCONF client with carrier privileges (whose user account may be configured with an odu-id string) may only be allowed to update a list entry after the list entry has been created and configured with the odu-id string associated with O-DU#2 212.

[0047] According to an embodiment, when O-DU#2 212 subscribes to configuration-related change notifications in the shared O-RU 220 (which currently has an active configuration with O-DU#1 211), O-DU#2 may already be fully aware of the configuration change after reading it during startup. According to an embodiment, O-DU#1 211 may configure an odu-id string for O-DU#2 212 and create an account including the odu-id string for the O-DU#2 212 NETCONF client(s) on the shared O-RU NETCONF server. In response, O-DU#1 211 may communicate the account information to O-DU#2 212. Optionally, O-DU#1 211 may be subscribed to be notified of updates to the O-RU's configuration data store. According to an embodiment, in a single operator (SHARED-ORU-MULTI-ODU) use case, the odu-id string may be used by O-DU#2 212 to subscribe to O-DU#1 related configuration change notifications.

[0048] In S5, the O-DU#1 211 may fail, or there may be some interface failure or scheduled maintenance (e.g., caused by an operator's decision). The shared O-RU 220 may no longer have a stable connection with the O-DU#1 211. According to an embodiment, the SMO 200 may detect or determine that this failure has occurred.

[0049] In S6, the SMO 200 may make a decision that the O-DU#2 212 takes over control of the shared O-RU 220 based on the determined / detected failure in S5 (i.e., the O-DU#2 212 may become the primary O-DU for the O-DU#1 211). It should be understood that the SMO 200 may need to distinguish between an O-DU failure and scheduled maintenance (e.g., a basic recovery case) and a network component or function-related failure (e.g., an advanced recovery case). The SMO 200 may also need to be able to determine when the failure is caused by the network, the interface, or a scenario in which the O-DU#1 211 is reset but returns to service after waiting for a while. The failure may also be further caused by an O-DU failure, an FH interface failure, an F1 interface failure, an O-DU port failure, an environmental issue, a power failure, a monitoring failure, a security threat, a scheduled maintenance, a software upgrade, a carrier upgrade, etc. At least some of the above factors may be taken into consideration when determining the failure that occurred in S5.

[0050] There may be a variety of additional factors that may influence the decision to transition O-DU#2 212 to take over control of the shared O-RU 220, as well as how to perform this transition, including, but not necessarily limited to, the following:

[0051] (a) According to an embodiment, SMO 200 may have several predefined reference points for carrier states, which may be based on the operation / availability status of the appropriate carriers (e.g., as defined in specifications 3GPP TS 28.625 / ITU-T X.731). Because these carrier states may be more clearly defined using such predefined reference points, SMO 200 may be able to make more informed decisions rather than relying solely on fault alarms.

[0052] (b) The SMO 200 may also need to consider when to perform a carrier / NR cell switch / transition between either a soft transition or a hard transition, depending on the embodiment. A soft transition may be when the carrier configuration (that was active between the O-DU#1 211 and the shared O-RU 220) is with the O-DU#2 212 and is ready to be pushed to the shared O-RU 212. On the other hand, a hard transition is when the carrier configuration is not readily available with the O-DU#2 212.

[0053] (c) An alarm from the O-DU#1 211 and the associated O-CU (eg, O-CU#1 210) or other alarm received from a higher layer in the layer stack is received.

[0054] (d) A threshold of maximum call-home attempts from the shared O-RU 220 has been reached (note that the SMO 200 may not be explicitly aware that the shared O-RU 220 is still making call-home attempts or that the threshold has been reached); and / or

[0055] (e) A first monitoring alarm (#35) and / or O-DU#1 211 is detected to have failed. While the first monitoring alarm #35 may be generally defined in the related art for a monitoring failure of the shared O-RU 220, it may not necessarily provide sufficient detail / relevance regarding the specific failure. Accordingly, according to embodiments, more specific alarms for shared O-RU resiliency (e.g., indicating NR cell transition failure, backup O-DU unavailability / failure, backup O-DU failed interface, etc.) may be implemented. According to some embodiments, an alarm generated after the first monitoring failure for other factors / flags may be provided to indicate, for example, completion of maximum call home attempts and successful reactivation of call home by the failed O-DU. In either case, the history of all used alarm data may improve future decision-making by the SMO 200 (e.g., using AI / machine learning techniques to train a model based on historical alarm data).

[0056] In either of these cases, the SMO 200 may modify the access privileges of the O-DU#2 212 to “sudo” (e.g., administrative / superuser privileges that allow the O-DU#2 212 to freely modify the configuration). In particular, note that the O-DU 211#1 may have previously had “sudo” privileges. It should be understood that according to an embodiment in which the O-RU 220 may also have NETCONF sessions with any N O-DUs (whereas, in the exemplary embodiment, two O-DUs are described) with different privileges, the SMO 200 may identify the correct backup O-DU and set only the necessary privileges for the identified backup O-DU for resiliency decision-making.

[0057] At S7, either the SMO 200 or the O-DU#2 212 may configure one of the MAC address / MAC address+VLAN-ID / UDP IP and / or ODU-ID (e.g., using the o-ran-processing-elements.yang module), and then activate the carrier configuration for the appropriate carrier for the O-DU#2 212 (e.g., by changing tx / rx array-carrier-active to “active” in the o-ran-uplane.yang module of the carrier appropriate for the O-DU#2 212). It should be understood that the O-DU#2 212 may regain its carrier configuration in various ways, including, but not limited to, the following:

[0058] (a) The SMO 200 pushes the configuration to the O-DU#2 212 using an edit-config remote protocol call (RPC). The O-DU#2 212 may then apply transport-related changes (such as MAC address / MAC address+VLAN ID / UDP IP and / or ODU-ID) and then activate the carrier configuration by setting tx / rx array-carrier-active to “active” in the o-ran-uplane.yang module, similar to what was described above.

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

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

[0061] (d) A duplicate carrier configuration using dummy endpoints (dedicated resources) for the O-DU#2 212 and the shared O-RU 220 may be preconfigured in the shared O-RU 220 and updated periodically or based on the O-DU#2 212 obtaining updates regarding configuration changes. In this scenario, the carrier configuration related to the O-DU#2 212 may initially be preconfigured with tx / rx array-carriers::active set to “INACTIVE” and the state of array-carrier set to “disabled.” Accordingly, when the SMO 200 triggers a carrier transition between the O-DU#1 211 and the O-DU#2 212, the O-DU#2 may simply change tx / rx array-carriers::active to “active” and the state of array-carrier set to “enabled.” It should be understood that the variable names used in the above scenarios may be arbitrary and the purpose of the example may be to show how the carrier configuration may be pre-configured before transitioning between O-DUs.

[0062] According to an embodiment, the shared O-RU 220 may implement pre-configuration of the O-DU#2 212 by reporting support for 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 an appropriate file.

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

[0064] According to an embodiment, a carrier switch from O-DU#1 211 to O-DU#2 212 may need to be performed quickly. According to an embodiment, if there is an overlapping carrier, the overlapping cell (NRCellDU parameter) and carrier (NRSectorCarrier parameter) may be configured in O-DU#2 212. The overlapping cell (NRCellDU(s)) and NRSectorCarrier(s) associated with O-DU#1 211 may be pre-configured in the standby O-DU, i.e., O-DU#2 212, and their administrative state may be set to "locked". However, the NRCellDU(s) may be different for the same NRSectorCarrier(s) configured in both O-DU#1 211 and O-DU#2 212, since they are a function of the gNB ID / O-DU ID. Also, the O-CU 210 can distinguish them using unique gNB-DU names. A duplicate cell can be created in O-DU#2 212 with an administrative state of "locked" using a unique / corresponding gNB-DU name / ID, so that the F1AP interface does not reject the duplicate cell configured in O-DU#2 212. When O-DU#1 211 fails, the configured and active NR cells are removed, or the SMO 200 / O-CU 210 can set their respective administrative states to "locked". After that, the NR cells configured in O-DU#2 212 are unlocked.

[0065] Since the O-CU 210 may know that the cell (NRCellDU(s)) configured with the unique gNB-DU name and ID (gNB ID / O-DU ID) of the O-DU#2 212 is a backup for the O-DU#1 211 cell, when the O-DU#1 211 fails, the SMO 200 may trigger a resiliency use-case and request the O-DU#2 212 to take over the carrier(s), and then transfer the carrier(s). After that, the O-DU#2 212 can set up an F1AP configuration request to the O-CU 210 because it has pre-configured cell(s) (NRCellDU(s)) / carrier(s) (NRSectorCarrier(s)). When the NRSectorCarrier of O-DU#2 212 becomes active and ready, the SMO200 / O-CU210 can unlock the pre-configured NRCellDU in O-DU#2 212 by setting "administrativeState" to "unlocked". Here, the UE may see different cell IDs for the same carrier, which is unavoidable because a carrier cannot be configured with the same cell ID in both O-DU#1 211 and O-DU#2 212.

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

[0067] According to embodiments, a reconnect strategy that may occur in S8 may be implemented by the SMO 200 / DHCP server 230 / NETCONF client of the currently active O-DU#2 212 by sending an RPC restart-call-home to simply inform the shared O-RU 220 that it can now resume a stale / failed / closed NETCONF session with the current O-DU#1 211 with which the shared O-RU 220 was associated before the failure. According to some embodiments, the SMO 200 may send the RPC restart-call-home via the O-DU#2 212 as soon as it recognizes that the O-DU#1 211 has recovered / become operational / become active. According to embodiments, the O-DU#2 212 may configure a setting regarding how often re-call-home attempts should be made for the shared O-RU 220 via an edit-config RPC. When the NETCONF session with O-DU#1 211 is re-established for the shared O-RU 220, the shared O-RU 220 may cancel alarm #35 (a monitoring failure alarm as described above) associated with the individual NETCONF session and send a notification (e.g., via o-ran operations.yang) to the SMO 200 via O-DU#1 211 or O-DU#2 212, or directly to the SMO 200.

[0068] It should be understood that S8 does not necessarily have to follow or occur simultaneously with S7, but rather S8 may be performed any time after a failure occurs in S5.

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

[0070] (a) The shared O-RU 220 may be reactivated (restarted) / switched during the switch / transition between the O-DU#1 211 and the O-DU#2 212.

[0071] (b) O-DU#2 212 may become unavailable during the transition.

[0072] (c) Common / management configurations and carrier-specific configurations may not be properly implemented during or after the transition.

[0073] (d) O-DU#2 212 may lose configuration data from the configuration replica, or may receive incomplete configuration data from the SMO 200, or may fail to retrieve the configuration from the shared O-RU 220.

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

[0075] (f) The connectivity or functionality of the management system (e.g., SMO200) becomes unavailable.

[0076] Nevertheless, it should be understood that other fault management may be suitably performed by one skilled in the art depending on the particular implementation.

[0077] According to an embodiment, it may be possible for the O-DU#1 211 and the O-DU#2 212 to be connected to the same router / clock source, and therefore the synchronization between the shared O-RU 220 and the O-DU#1 211 and the O-DU#2 212 can be aligned without any problems (LLS-C3 (clock in the router)). In this scenario, the synchronization / clock source is common to both the O-DU#1 211 and the O-DU#2 212, and the shared O-RU 220.

[0078] According to an embodiment, a Lower Layer Split Control-plane (LLS-C1) deployment may be implemented, in which a shared O-RU 220 may manage the carriers of each O-DU and align the carriers with their associated synchronous plane clocks.

[0079] According to an embodiment, performance management may need to be considered when transitioning between O-DU#1 211 and O-DU#2 212. The O-DU#1 211 may be responsible for configuring the performance measurements of the shared O-RU 220 while it is the active O-DU. In this case, the O-DU#2 212, as the standby O-DU, can use a get RPC to read the performance management configuration executed by the O-DU#1 211 in the shared O-RU 220. According to an embodiment, a "ru-elements" list (e.g., in the o-ran-processing-elements.yang module) may be defined for both the O-DU#1 211 and the O-DU#2 212. The "ru-elements" list may be used to retrieve the respective performance management configurations.

[0080] The backup O-DU (e.g., at least the O-DU#2 212) may subscribe to performance management counter-related notifications of the shared O-RU 220 (e.g., the O-DU#2 212 subscribes to performance counter notifications). As an example, the packet delay of the shared O-RU 220 may worsen during its association with the O-DU#1 211. After the transition from the O-DU#1 211 to the O-DU#2 212, the O-DU#2 212 can correct the packet delay based on historical / current performance counters received from either the shared O-RU 220 or the SMO 200. The management entity (e.g., the SMO 200) may still have performance counter measurement reports for the shared O-RU 220 associated with the O-DU#1 211. Therefore, the performance counters of the shared O-RU 220 associated with the O-DU#1 211 may need to be flushed / removed when the O-DU#2 takes over the shared O-RU 220. For this purpose, the O-DU#2 212 may flush / delete the entire performance counters / KPIs associated with the O-DU#1 211 that are stored in the shared O-RU 220 by sending an RPC delete / delete-config. The O-DU#2 212 may also obtain and analyze the performance counters of the shared O-RU 220 associated with the O-DU#1 211 during / after the migration. If there are no problems, the O-DU#2 212 may activate the TX / RX array carrier 330 (described below with reference to FIG. 3 ), or after mitigating the existing problem, the O-DU#2 212 may perform a reset, etc.

[0081] According to an embodiment, the shared O-RU 220 may have the ability to flush the performance counters associated with the O-DU#1 211 after sharing / reporting them to the SMO 200 and / or the O-DU#2 212. When the O-DU#2 212 takes over the shared O-RU 220, the O-DU#2 212 may be responsible for reporting the associated performance counters.

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

[0083] 3 illustrates an exemplary data structure for a carrier configuration, according to one embodiment. A low-level TX / RX link 300 may be provided, which may include a processing element 310, a low-level TX / RX endpoint 320, a static low-level TX / RX endpoint 321, and a TX / RX array carrier 330. The configuration illustrated in FIG. 3 may be a rw user plane configuration, according to an embodiment.

[0084] According to an embodiment, a list of low-level TX / RX links 300 may be created such that the same carrier 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. Therefore, an odu-id string may be included in the low-level TX / RX links.

[0085] The processing element 310 may be a data structure used to distinguish a particular processing element associated with an active / standby O-DU (i.e., O-DU#1 211 and O-DU#2 212 described with reference to FIG. 2 above), although it should be understood that there may be N standby O-DUs according to an embodiment. The processing element 310 may be in the form of a list, where each entry in the list may point to a corresponding processing element associated with a shared O-RU / multiple O-DUs, and an odu-id string may be used to identify a particular O-DU.

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

[0087] According to an embodiment, the processing element 310 may include the MAC addresses of the active / standby O-DUs as well as the shared O-RUs so that the processing element 310 can be mapped to the appropriate shared O-RU. Similarly, the active / standby O-DUs may have defined IP addresses.

[0088] The low-level TX / RX endpoints 320 may map active / standby O-DUs and endpoints; this mapping is performed by the low-level TX / RX link 300 and may associate each odu-id string with the appropriate TX / RX array carrier 330. The odu-id may be specifically included to support the SHARED-ORU-MULTI-ODU feature. According to an embodiment, the low-level TX / RX endpoints 320 may include an o-du-port-bitmask parameter for the extended antenna-carrier identifier (eAXC-ID) to map both active and standby O-DUs and endpoints. The static low-level TX / RX endpoints 321 may be specific to a given O-RU vendor / manufacturer and may have a one-to-one mapping with the low-level TX / RX endpoints 320. The static low-level TX / RX endpoint 321 may be configured by a given O-RU (such as a shared O-RU) as a read-only parameter that a given O-DU cannot configure / write. Furthermore, the low-level TX / RX endpoint 320 may be created by a given O-DU based on the static low-level TX / RX endpoint 321 of the O-RU, and the given O-DU can configure or modify the low-level TX / RX endpoint 320.

[0089] According to an embodiment, the eAXCID bit width can be configured by an individual (respective) NETCONF client. The same carrier cannot have similar eAXCIDs mapped to both the active and standby O-DUs and then activated. There can be variations in the eAXCID bit width because of the odu-port-mask for the standby (e.g., O-DU#2 212) O-DU. In this scenario, carriers can be pre-configured with eAXCIDs of different bit widths, and the carrier associated with the standby (e.g., O-DU#2 212) O-DU can be inactive.

[0090] The TX / RX array carrier 330 may be a data structure used to represent a carrier that is configured between an active O-DU (e.g., O-DU#1 211) and a shared O-RU (e.g., O-RU 220) and may have a duplicated instance or may be pre-configured for a standby O-DU (e.g., O-DU#2 212) using an odu-id string.

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

[0092] According to an embodiment, before an active O-DU (e.g., O-DU#1 211) fails, the carriers associated with the active O-DU may be configured and active in the shared O-DU, and the carriers associated with the standby O-DU (e.g., O-DU#2 212) may be pre-configured but not active. When the active O-DU fails, the associated carriers may be deactivated by the shared O-RU itself, or the standby O-DU may send an RPC to set the appropriate TX / RX array carrier 330 entry (active setting) to "inactive." When deactivating or deleting carriers associated with an active O-DU, the odu-id string may be utilized to distinguish between carriers associated with the active / standby O-DUs. The standby O-DU already knows the TX / RX array carrier 330 entry associated with the active O-DU and can identify it using the odu-id string reference in the carrier parameter, so the standby O-DU (to be migrated) can delete / deactivate the TX / RX array carrier 330 entry associated with the odu-id of the active O-DU (from which it is migrated).

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

[0094] According to an embodiment, the O-DU may push u-plane configuration files associated with the odu-ids of the respective active / standby O-DUs (e.g., the low-level TX / RX link 300, which may comprise the processing element 310, the low-level TX / RX endpoint 320, and the TX / RX array carrier 330, as described above) to the shared O-RU. According to an embodiment, NETCONF.yang may be responsible for merging the configurations into a single file because there may be a common E-UTRA Absolute Radio Frequency Channel Number (EARFCN) and several other parameters between the configurations. Accordingly, the configuration file in the shared O-RU may have carrier configurations associated with both the active and standby O-DUs. During the transition from the active O-DU to the standby O-DU, the standby O-DU may 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 state of the appropriate array carrier 330 to "enabled" and notify the O-DU of the state change (i.e., the carrier state is ready). This change may be handled by the low-level TX / RX link 300 because a list of processing element 310 entries may be defined for both the active / standby O-DU based on MAC address / IP address. Accordingly, there may be no new hardware requirement to store a separate carrier configuration file 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 one embodiment.

[0096] In 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 to an embodiment, the SMO may be configured to identify the first and second O-DUs based on an O-DU identifier (odu-id as mentioned with reference to FIGS. 2 and 3 above) or a shared resource operator identifier (sro-id), where odu-id or sro-id represents a string and / or unique name of the individual O-DU, and 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 individual O-DU. The carrier configurations of the first O-DU and the second O-DU may be distinguished using a separate odu-id in a single operator deployment, or may be distinguished using a separate 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. It should be emphasized that the second O-DU may have the same or different performance capabilities as the first O-DU. For example, in the case of O-DUs with different performance capabilities, the first O-DU may be able to configure four tx / rx array carriers, while the second O-DU may only be able to configure two tx / rx array carriers in the shared O-RU to restore the service state. In this case, the second O-DU may recover the shared O-RU and perform carrier configuration (to the extent possible).

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

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

[0100] In operation 404, a failure / scheduled maintenance of the first O-DU may be detected (e.g., by the SMO), which may cause the shared O-RU to call the second O-DU based on an instruction sent from the SMO. The instruction instructs the second O-DU to take over control of the shared O-RU and to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. According to an embodiment, the carrier configuration of the second O-DU may be pre-configured in the shared O-RU, or the SMO may be configured to push the carrier configuration of the second O-DU to the second O-DU for configuration in the shared O-RU. The carrier configuration of the first / second O-DU may include a list of processing elements, a list of low-level transmit / receive (tx / rx) 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, the carrier configuration of the second O-DU may instead be actively configured by a start-up procedure with the shared O-RU.

[0102] In operation 404, calling home to the second 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 the carrier configuration for the second O-DU), and deactivating a carrier associated with the carrier configuration of the first O-DU.

[0103] In operation 405, the shared O-DU may call home again to the first O-DU based on the RPC received from the SMO to re-establish a NETCONF session with the first O-DU, which may occur after operation 404, according to some embodiments.

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

[0105] 5 is a diagram of an example environment 500 in which the 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. The devices in environment 500 may be interconnected 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 the elements shown in FIG. 5.

[0106] User device 510 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to 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 smartphone, a wireless telephone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, user device 510 may receive information from platform 520 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 can be swapped in or out depending on particular needs. 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 within a cloud computing environment 522. In particular, although the implementations described herein describe platform 520 as being hosted within 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 services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 510) knowledge of the physical location and configuration of the system(s) and / or device(s) that host platform 520. As shown, cloud computing environment 522 may include a group of computing resources 524 (collectively referred to as “computing resources 524” and individually referred to as “computing resource 524”).

[0110] The computing resource(s) 524 may include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resource(s) 524 may host the platform 520. Cloud resources may include compute instances running within the computing resource(s) 524, storage devices provided within the computing resource(s) 524, data transfer devices provided by the computing resource(s) 524, etc. In some implementations, the computing resource(s) 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, the computing resource(s) 524 include a group of cloud resources such as one or more applications (APP) 524-1, one or more virtual machines (VMs) 524-2, virtualized storage (VSs) 524-3, and one or more hypervisors (HYPs) 524-4.

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

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

[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(s) 524. In some implementations, types of virtualization in the context of storage systems may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed regardless of the physical storage or heterogeneous structure. The separation allows storage system administrators flexibility in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable performance optimization of storage usage, server consolidation, and / or non-disruptive file migration.

[0115] Hypervisor 524-4 may provide hardware virtualization techniques that allow multiple operating systems (e.g., guest operating systems) to run simultaneously on a host computer, such as computing resource(s) 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 different operating systems may share virtualized hardware resources.

[0116] Network 530 may include 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., a Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical-based fiber network, etc., and / or combinations of these or other types of networks.

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

[0118] Figure 6 illustrates an embodiment of a device 600. As shown in Figure 6, the device 600 includes a 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] Processor 610, as used herein, refers to any type of computing circuitry that may comprise hardware and software elements. 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, etc. 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 random-access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 610. Memory 620 comprises machine-readable instructions executable by processor 610. These machine-readable instructions, when executed by processor 610, cause processor 610 to perform one or more method steps of the above-described embodiments.

[0121] Storage component 630 stores information and / or software related to the operation and use of device 600. For example, storage component 630 may include a hard disk (e.g., a magnetic disk, an optical disk, an optical-magnetic 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] The input component 640 is configured to receive information such as user input. For example, the input component 640 may include, but is not limited to, a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally or alternatively, the input component 640 may include sensors (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator) for sensing information.

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

[0124] The communication interface 660 is an interface for providing a communication connection with other devices such as external devices and internal devices. The connection via the communication interface 660 may be a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection, and may be a direct connection or an indirect connection via a communication network existing between the device 600 and the other device. In other words, the standard of the communication interface 660 is not limited.

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

[0126] The number and arrangement of components shown in Figure 6 are provided as an example. In practice, device 600 may include more, fewer, different, or differently arranged components than those shown in Figure 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. Furthermore, one or more method steps described in any of the embodiments may be performed using multiple devices 600 in communication with each other.

[0127] In embodiments, any one of the operations or processes of Figures 1-4 may be implemented by or using any one of the elements shown in Figures 5 and 6. It is understood that other embodiments may be implemented in a variety of different architectures (e.g., without being limited thereto, a bare metal architecture, any cloud-based 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 implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations.

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

[0130] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

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

[0132] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer may be made (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions and personalize the electronic circuits by utilizing state information of the computer-readable program instructions 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, executed by the processor of the computer or other programmable data processing apparatus, form means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular way, such that the computer-readable storage medium on which the instructions are stored constitutes an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

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

[0135] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a portion of a microservice, module, segment, or instruction set, comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those shown in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or a combination of dedicated hardware and computer instructions.

[0136] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0137] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following clauses. Item 1: Receiving, by a shared open radio access network (O-RAN) radio unit (O-RU), access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); and, by the shared O-RU, establishing a network configuration protocol (NETCONF) session with the first O-DU, activating carrier configuration with the first O-DU, and calling home to the first O-DU based on the received access details of the first O-DU to subscribe to alarms and notifications with the first O-DU; and, from the SMO, receiving, by the shared O-RU, access details of a second O-RAN distributed unit (O-DU). receiving access details of an O-DU (Operating-Unit-Database Unit); and, when a Service Management Organization (SMO) detects a failure or scheduled maintenance of a first O-RU, calling home, by the shared O-RU, to a second O-DU based on an instruction sent from the SMO to command the second O-DU to take over control of the shared O-RU and to command the second O-DU to activate a carrier configuration of the second O-DU via 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 the same or different performance capabilities as the first O-DU. Item 2: The method of 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), where the odu-id or sro-id represents a string and / or a unique name of each O-DU, and the details of the first O-DU and the second O-DU may include the IP address and odu-id / sro-id of each O-DU. Item 3: The method according to any one of Items 1 to 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 for configuration in the shared O-RU. Item 4: The method according to item 2, wherein the carrier configurations of the first O-DU and the second O-DU are distinguished using respective odu-ids in a single operator deployment, or can be distinguished using respective sro-ids in a multi-operator deployment. Item 5: The method according to any one of items 1 to 4, wherein the carrier configuration of the second O-DU is actively configured by a startup procedure with the shared O-RU. Item 6: The method of any one of items 1 to 5, wherein calling home to the second O-DU based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via 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 the carrier configuration for the second O-DU, and deactivating a carrier associated with the carrier configuration of the first O-DU. Item 7: A method according to any one of items 1 to 6, further comprising calling home again to the first O-DU by the shared O-RU based on a remote procedure call (RPC) received from the SMO to re-establish a NETCONF session with the first O-DU. Item 8: A shared open radio access network (O-RAN) radio unit (O-RU) configured to receive access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); establish a network configuration protocol (NETCONF) session with the first O-DU, activate carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU. Call home to the first O-DU based on the received access details of the first O-DU; and receive access details of a second O-RAN distributed unit (O-DU) from the SMO. and configured to receive access details of a shared O-RU (O-DU), and when the SMO detects a failure or scheduled maintenance of a first O-RU, to call home to a second O-DU based on an instruction sent from the SMO, the instruction instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via 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 the same or different performance capabilities as the first O-DU. Item 9: A shared O-RU as described in 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 each O-DU, and the details of the first O-DU and the second O-DU may include an IP address and odu-id / sro-id of each O-DU. Item 10: A shared O-RU according to any one of Items 8 to 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 for configuration in the shared O-RU. Item 11: The shared O-RU according to Item 9, wherein the carrier configurations of the first O-DU and the second O-DU can be distinguished using respective (individual) odu-ids in a single operator deployment, or can be distinguished using respective (individual) sro-ids in a multiple operator deployment. Item 12: A shared O-RU according to any one of items 8 to 11, wherein the carrier configuration of the second O-DU is actively configured by a startup procedure with the shared O-RU. Item 13: The shared O-RU according to any one of Items 8 to 12, wherein the shared O-RU is further configured to call home to the second O-DU by, based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via the carrier configuration from the first O-DU, recovering 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 a carrier associated with the carrier configuration of the first O-DU. Item 14: A shared O-RU according to any one of items 8 to 13, further configured to call home again to the first O-DU based on a remote procedure call (RPC) received from the SMO to re-establish a NETCONF session with the first O-DU. Item 15: At least one non-transitory computer-readable storage medium having executable instructions stored thereon for performing a method, the method including receiving, by a shared open radio access network (O-RAN) radio unit (O-RU) from a service management and orchestration (SMO), access details of a first O-RAN distributed unit (O-DU); establishing, by the shared O-RU, a Network Configuration Protocol (NETCONF) session with the first O-DU, activating carrier configuration with the first O-DU, and calling home to the first O-DU based on the received access details of the first O-DU to subscribe to alarms and notifications with the first O-DU; and receiving, by the shared O-RU from the SMO, access details of a second O-RAN distributed unit (O-DU). and, when the SMO detects a failure or scheduled maintenance of a first O-RU, calling home, by the shared O-RU, to a second O-DU based on an instruction sent from the SMO, the instruction instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via 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 the same or different performance capabilities as the first O-DU. Item 16: At least one non-transitory computer-readable storage medium described in Item 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 each O-DU, and the details of the first O-DU and the second O-DU may include an IP address and odu-id / sro-id of each O-DU. Item 17: At least one non-transitory computer-readable storage medium described in any one of Items 15 to 16, 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 for configuration in the shared O-RU. Item 18: At least one non-transitory computer-readable storage medium described in Item 16, wherein the carrier configurations of the first O-DU and the second O-DU can be distinguished using respective odu-ids in a single operator deployment, or can be distinguished using respective sro-ids in a multi-operator deployment. Item 19: At least one non-transitory computer-readable storage medium described in any one of items 15 to 18, wherein the carrier configuration of the second O-DU is actively configured by a startup procedure with the shared O-RU. Item 20: At least one non-transitory computer-readable storage medium described in any one of Items 15 to 19, wherein calling home to the second O-DU based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via 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 a carrier associated with the carrier configuration of the first O-DU.

[0138] It can be appreciated that many 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 disclosure may be practiced otherwise than as specifically described herein.

Claims

1. receiving, by a shared open radio access network (O-RAN) radio unit (O-RU), access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); calling home, by the shared O-RU, to the first O-DU based on the access details of the received first O-DU to establish a Network Configuration Protocol (NETCONF) session with the first O-DU, activate 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; When the SMO detects a failure or scheduled maintenance of the first O-RU, the shared O-RU calls home to the second O-DU based on an instruction sent from the SMO; the instructions 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 via the carrier configuration from the first O-DU; The method, 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 the same or different performance capabilities as the first O-DU.

2. 2. The method of 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 resource operator identifier (sro-id), the odu-id or the sro-id representing a string and / or a unique name of each of the O-DUs, and the details of the first O-DU and the second O-DU include an IP address and odu-id / sro-id of each of the O-DUs.

3. 2. The method of 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 for configuration in the shared O-RU.

4. 3. The method of claim 2, wherein the carrier configurations of the first O-DU and the second O-DU can be distinguished using the respective odu-ids in a single operator deployment or can be distinguished using the respective sro-ids in a multi-operator deployment.

5. The method of 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. calling home to the second O-DU based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via the carrier configuration from the first O-DU; 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 a carrier associated with the carrier configuration of the first O-DU.

7. 2. The method of claim 1, further comprising: calling home again to 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), comprising: configured to receive access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); configured to call home to the first O-DU based on the access details of the received first O-DU to establish a Network Configuration Protocol (NETCONF) session with the first O-DU, activate carrier configuration with the first O-DU, and subscribe to alarms and notifications with the first O-DU; configured to receive, by the shared O-RU, access details of a second O-RAN DU (O-DU) from the SMO; The SMO is configured to call home to the second O-DU based on an instruction sent from the SMO when the SMO detects a failure or scheduled maintenance of the first O-RU, the instruction instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU, the first O-DU being an active / primary / host O-DU and the second O-DU being a standby / secondary / tenant O-DU, and the second O-DU may have the same or different performance capabilities as the first O-DU; Shared O-RU.

9. The shared O-RU of 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), the odu-id or the sro-id representing a string and / or a unique name of each of the O-DUs, and the details of the first O-DU and the second O-DU include an IP address and odu-id / sro-id of each of the O-DUs.

10. The shared O-RU of 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 for configuration in the shared O-RU.

11. The shared O-RU of claim 9, wherein the carrier configurations of the first O-DU and the second O-DU can be distinguished using the respective odu-ids in a single operator deployment or can be distinguished using the respective sro-ids in a multi-operator deployment.

12. The shared O-RU of 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 is based on an instruction sent from the SMO to instruct the second O-DU to take over control of the shared O-RU and to activate the carrier configuration of the second O-DU via the carrier configuration from the first O-DU. 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; deactivating a carrier associated with the carrier configuration of the first O-DU; The shared O-RU of claim 8 , further configured to call home to the second O-DU.

14. and further configured to call home again to 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. The shared O-RU of claim 1.

15. At least one non-transitory computer-readable storage medium having executable instructions recorded thereon for performing a method, the method comprising: receiving, by a shared open radio access network (O-RAN) radio unit (O-RU), access details of a first O-RAN distributed unit (O-DU) from a service management and orchestration (SMO); calling home, by the shared O-RU, to the first O-DU based on the access details of the received first O-DU to establish a Network Configuration Protocol (NETCONF) session with the first O-DU, activate 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 when the SMO detects a failure or scheduled maintenance of the first O-RU, calling home by the shared O-RU to the second O-DU based on instructions sent from the SMO, the instructions instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via the carrier configuration from the first O-DU; At least one non-transitory computer-readable storage medium, 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 the same or different performance capabilities as the first O-DU.

16. 16. At least one non-transitory computer-readable storage medium according to 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), the odu-id or the sro-id representing a string and / or a unique name of each of the O-DUs, and the details of the first O-DU and the second O-DU include an IP address and odu-id / sro-id of each of the O-DUs.

17. 16. The at least one non-transitory computer-readable storage medium of 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 for configuration in the shared O-RU.

18. 17. The at least one non-transitory computer-readable storage medium of claim 16, wherein the carrier configuration of each of the first O-DU and the second O-DU can be distinguished using the respective odu-id in a single operator deployment or the respective sro-id in a multi-operator deployment.

19. 16. The at least one non-transitory computer-readable storage medium of claim 15, wherein the carrier configuration of the second O-DU is actively configured by a start-up procedure with the shared O-RU.

20. calling home to the second O-DU based on an instruction sent from the SMO instructing the second O-DU to take over control of the shared O-RU and instructing the second O-DU to activate a carrier configuration of the second O-DU via the carrier configuration from the first O-DU; 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 a carrier associated with the carrier configuration of the first O-DU.

Images