WO2025250158A1 - End-to-end (e2e) carrier activation procedure for a split architecture - Google Patents

Abstract

Embodiments of the disclosure describe a method for managing the synchronization between a plurality of logical entities. The method includes receiving, at a first entity associated with a DU 200, a cell activation command from a CU 100. The method includes transmitting, upon receiving the cell activation command, one or more carrier activation commands towards at least one of a second entity associated with the DU 200 and a RU 300 in a predefined carrier activation sequence order to initiate a carrier activation. The method includes receiving a response message from one or more of the second entity and the RU in response to the one or more transmitted carrier activation commands. The response message comprises one of the Ack message or the NAck message. The method includes synchronizing the carrier state among the DU 200, the CU 100 and the RU 300 based on the received response message.

Description

END-TO-END (E2E) CARRIER ACTIVATION PROCEDURE FOR A SPLIT ARCHITECTURE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Indian Patent Application No. 202411042166, filed on May 30, 2024, the full disclosure of which is incorporated herein by reference in its entirety for all purposes.

FIELD

[0002] The present disclosure relates to an End-to-End (E2E) carrier activation procedure for a split architecture.

BACKGROUND

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

[0004] In the existing telecommunication systems (e.g., 5G New Radio (NR) architecture 10), a gNodeB (gNB) functionality is split across three logical entities such as a Central Unit (CU) 11, a Distributed Unit (DU) 12, and an Open Radio Unit (O-RU) 13, as illustrated in FIG. 1. The CU 11 is configured to perform a higher-layer protocol processing of the gNB and communicate with a core network 14. For instance, the CU 11 handles the Radio Resource Control (RRC) protocol, which is responsible for the configuration and management of the radio interface. The CU 11 also manages the Packet Data Convergence Protocol (PDCP), which performs header compression, ciphering, and integrity protection of user data and control plane packets. The CU 11 is a crucial component in the management and control of the radio interface and user data and control plane packets transmission. The CU 11 provides centralized control and optimization of radio resources, ensuring efficient utilization and dynamic allocation to support diverse 5G services and use cases. [0005] Further, the DU 12 is configured to perform a lower-layer protocol processing of the gNB. For instance, the DU 12 encompasses a Radio Link Control (RLC) layer that performs segmentation, reassembly, and retransmission of data packets. The DU 12 also encompasses a Medium Access Control (MAC) layer that handles scheduling and multiplexing of physical resources. Moreover, the DU 12 encompasses a Physical (PHY) layer that performs modulation, coding, and radio frequency processing. Furthermore, the 0-RU 13 represents a physical radio unit in the 5G NR architecture. The 0-RU 13 is configured to perform an analog-to-digital and digital - to-analog conversion, as well as an amplification and transmission/reception of radio signals over an air interface, to communicate with User Equipment (UE) 15.

SUMMARY

[0006] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure nor is it intended for determining the scope of the disclosure.

[0007] According to one embodiment of the present disclosure, a method for managing synchronization between a plurality of logical entities. The method includes receiving, at a first entity associated with a Distributed Unit (DU), a cell activation command from a Central Unit (CU). The method further includes transmitting one or more carrier activation commands upon receiving the cell activation command. The one or more carrier activation commands are transmitted towards at least one of a second entity associated with the DU and a Radio Unit (RU) in a predefined carrier activation sequence order to initiate a carrier activation. The method further includes receiving a response message from one or more of the second entity and the RU in response to the one or more transmitted carrier activation commands. The response message comprises one of an Acknowledgement (Ack) message or a Negative Acknowledgement (NAck) message. The method further includes synchronizing a carrier state among the DU, the CU, and the RU based on the received response message.

[0008] According to one embodiment of the present disclosure, an apparatus is implemented at the DU for managing synchronization between a plurality of logical entities. The apparatus is configured to receive, at the first entity associated with the DU, the cell activation command from the CU. The apparatus is further configured to transmit the one or more carrier activation commands upon receiving the cell activation command. The one or more carrier activation commands are transmitted towards at least one of a second entity associated with the DU and the RU in the predefined carrier activation sequence order to initiate the carrier activation. The apparatus is further configured to receive the response message from one or more of the second entity and the RU in response to the one or more transmitted carrier activation commands. The response message comprises one of the Ack message or the NAck message. The apparatus is further configured to synchronize the carrier state among the DU, the CU, and the RU based on the received response message.

[0009] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail in the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 illustrates an existing split architecture, according to the prior art;

FIG. 2 illustrates one or more operations associated with a plurality of logical entities, according to the prior art;

FIG. 3A illustrates a block diagram of a system for managing a synchronization, according to an embodiment as disclosed herein;

FIG. 3B illustrates a block diagram of a Distributed Unit (DU) for managing the synchronization between the plurality of logical entities, according to an embodiment as disclosed herein; FIGS. 4A-4C are exemplary sequence flow diagrams that illustrate one or more operations involved in executing a cell initialization method to manage the synchronization, according to an embodiment as disclosed herein;

FIG. 5 is an exemplary sequence flow diagram that illustrates one or more operations involved in executing a cell auto-recovery method to manage the synchronization, according to an embodiment as disclosed herein;

FIG. 6 is a flow diagram illustrating a method for managing the synchronization between the plurality of logical entities, according to an embodiment as disclosed herein; and

FIG. 7 illustrates a diagram of example components of a system, according to an embodiment as disclosed herein.

DETAILED DESCRIPTION

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

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

[0013] Even though particular combinations of features are recited in the claims and/or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

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

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

[0016] In the existing telecommunication systems, as illustrated in FIG. 1, the splitting of the gNB functionality into the CU 11, DU 12, and O-RU 13 enables a more modular and distributed architecture, which enhances scalability, flexibility, and the ability to independently optimize one or more different functional layers of the existing telecommunication systems. However, several problems are encountered in the existing telecommunication systems, which are mentioned below. [0017] To bring a cell to an active state, one or more DU applications interact with the CU 11 and O-RU 13 in a specific sequence, as illustrated in FIG. 2. This interaction ensures that the various logical entities (e.g., CU 11, DU 12, and O-RU 13) are synchronized and in a consistent state, which is crucial for maintaining End-to-End (E2E) service availability and reliability. Any mismatch in the cell state or carrier state across the different logical entities could lead to service disruptions and must be avoided. Due to the split architecture of the gNB functionality, there is a lack of synchronization between the various logical entities or O-RAN components (e.g., CU 11, DU 12, and O-RU 13) involved in a carrier activation procedure. This makes it difficult to analyze the root cause of failures that lead to carrier deactivation and subsequent service interruption. The situation may require the re-deployment of network functions (NFs). Additionally, the cell-level Key Performance Indicators (KPIs) might display inaccurate data due to a mismatch in the reported carrier state.

[0018] FIG. 2 illustrates one or more operations associated with a plurality of logical entities, according to the prior art. The plurality of logical entities may include the CU 11, the DU 12, and the O-RU 13.

[0019] The DU 12 is a modular architecture that comprises one or more functional application modules. These one or more functional application modules may include a System Manager (sysmgr) module 12a (also referred to as “SYSMGR”), a Radio Unit Manager (RUmgr) module 12b (also referred to as “RUMGR”), a Fronthaul Interface Manager (FICmgr) module 12c (also referred to as “FICMGR”), a baseband processing module 12d, an extended distributed key-value store (etcd) module 12e (also referred to as “ETCD”), a Functional Capabilities (FCAPS) module 12f, and a timing module 12g. The functionality of each module is described below.

[0020] The sysmgr module 12a is a central management and coordination component that oversees the operation of the other applications within the DU 12. The sysmgr module 12a is configured to handle one or more tasks such as configuration management, fault management, performance management, and security management. The sysmgr module 12a ensures a smooth operation of the DU 12 by monitoring its status, handling alarms and events, and providing a centralized interface for administrators to manage the system. The RUmgr module 12b is configured to manage one or more radio units within the DU 12. The RUmgr module 12b is further configured to handle one or more tasks such as radio resource management, radio configuration, and radio link control. The RUmgr module 12b ensures efficient utilization of radio resources and optimal performance of the O-RU 13.

[0021] The FICmgr module 12c is configured to manage a fronthaul interface, which connects the DU 12 to the O-RU 13. The FICmgr module 12c is further configured to handle one or more tasks such as fronthaul configuration, synchronization, and performance monitoring. The FICmgr module 12c ensures reliable and efficient communication between the DU 12 and the O-RU 13. The baseband processing module 12d is configured to process one or more baseband signals in the radio access network. It performs functions such as modulation/demodulation, encoding/decoding, and digital signal processing. The baseband processing module 12d plays a crucial role in converting digital data into radio signals for transmission and vice versa.

[0022] The ETCD module 12e is a distributed configuration and coordination service used within the DU 12. The FCAPS module 12f is configured to perform specific functionalities and capabilities of the DU 12. Each module has its own set of functional capabilities that contribute to the overall operation and performance of the DU 12. The FCAPs module 12f defines a behavior and characteristic of each module within the DU 12.

[0023] The timing module 12g is configured to provide synchronization and coordination between different modules. Within the DU 12, timing functionality includes synchronization of radio units, baseband processing, and fronthaul interfaces. Accurate timing is essential for efficient operation and seamless handover between cells. These functionalities collectively contribute to the efficient operation, management, and performance of the DU 12 within an Open Radio Access Network (ORAN) architecture, enabling flexible and interoperable radio access networks.

[0024] In addition, the sysmgr module 12a serves as a central coordination and integration point for the one or more functional application modules. The sysmgr module 12a leverages well- established communication protocols to facilitate connectivity and information exchange between the DU applications. In other words, this modular architecture with well-defined communication interfaces and protocols allows for a high degree of flexibility, scalability, and maintainability within the DU 12. It enables the independent development, deployment, and upgradability of individual modules without disrupting the overall system functionality.

[0025] In one example, the sysmgr module 12a communicates with the baseband processing module 12d using a remote procedure call such as the gRPC Remote Procedure Call (gRPC) protocol. The gRPC is a modem open-source RPC framework that enables efficient and type-safe communication between the sysmgr module 12a and the baseband processing module 12d.

[0026] In one example, the sysmgr module 12a communicates with the timing module 12g using a Hypertext Transfer Protocol (HTTP). The HTTP is a widely adopted application-layer protocol that provides a standardized mechanism for the sysmgr module 12a to exchange information and coordinate timing-related aspects.

[0027] In one example, the FICmgr module 12c communicates with the CU 11 using a standardized Fl interface, which utilizes a Stream Control Transmission Protocol (SCTP) for reliable data transfer. The SCTP is a transport-layer protocol designed for signaling and other realtime applications, ensuring the robust exchange of information between the DU 12 and the CU 11. [0028] In one example, the RUmgr module 12b communicates with the O-RU 13 using a M-plane interface. This interface facilitates the management and control of the O-RU 13 by the RUmgr module 12b.

[0029] In one example, the timing module 12g communicates with a Grand Master (GM) Precision Time Protocol (PTP) clock 17 over a Splane interface. The PTP is a widely used time synchronization protocol that ensures accurate and reliable time synchronization within the DU 12. [0030] In one example, the FCAPS module 12f communicates with a northbound 16 over an 01 interface to enable management and control functions between the DU 12 and the CU 11.

[0031] In one example, the baseband processing module 12d communicates with the O-RU 13 using a CU-plane interface. This interface enables the exchange of radio data and signaling between the baseband processing module 12d and the O-RU 13, enabling the DU 12 to perform its core radio processing functions.

[0032] Throughout this disclosure, the terms “entity”, “application” and “module” are used interchangeably and mean the same.

[0033] Referring now to the drawings, and more particularly to FIGS. 3A to 7, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

[0034] FIG. 3A illustrates a block diagram of a system 1000, according to an embodiment as disclosed herein. The system 1000 includes a Central Unit (CU) 100, a Distributed Unit (DU) 200, and a Radio Unit (RU) 300. The system 1000 may execute multiple operations to manage the synchronization between the CU 100, the DU 200, and the RU 300, which are given below.

[0035] In one or more embodiments, the DU 200 is configured to receive a cell activation command from the CU 100. The cell activation command may be received at a first entity (i.e., system manager application (sysmgr)) associated with the DU 200. Upon reception of the cell activation command, the DU 200 is further configured to transmit one or more carrier activation commands towards at least one of a second entity associated with the DU 200 and the RU 300 in a predefined carrier activation sequence order to initiate a carrier activation. Examples of the second entity may include, but are not limited to, a baseband application, a Radio Unit Manager (RUmgr) application, a Fronthaul Interface Manager (FICmgr) application, a Functional Capabilities (FCAPs) application, atiming application, and an extended distributed key-value store (etcd). The baseband application may include a Layer- 1 (LI) application and a Layer-2 (L2) application. The predefined carrier activation sequence order, for example, is first as the L2 application, second as the LI application, and third as the RU 300. In response to the one or more transmitted carrier activation commands, the DU 200 is configured to receive a response message from one or more of the second entity and the RU 300. The response message comprises one of an Acknowledgement (Ack) message or a Negative Acknowledgement (NAck) message. Based on the received response message, the DU 200 is further configured to synchronize a carrier state among the DU, the CU, and the RU, as described in conjunction with FIG. 3B, FIGS. 4A-4C, and FIG. 5. Here, the carrier state refers to one or more operational statuses of a Radio Frequency (RF) carrier within at least one communication device comprising at least an active state, an inactive state, a standby state, or undergoing maintenance state.

[0036] FIG. 3B illustrates a block diagram of the DU 200 for managing the synchronization between the plurality of logical entities, according to an embodiment as disclosed herein.

[0037] In an embodiment, the DU 200 may include a memory 210, a processor 220, and a communicator 230.

[0038] In an embodiment, the memory 210 stores instructions to be executed by the processor 220 for managing the synchronization between the CU 100, the DU 200, and the RU 300, as discussed throughout the disclosure. The memory 210 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 210 may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted as the memory 210 is non-movable. In some examples, the memory 210 can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 210 can be an internal storage unit, or it can be an external storage unit of the DU 200, a cloud storage, or any other type of external storage.

[0039] The processor 220 communicates with the memory 210, and the communicator 230. The processor 220 is configured to execute instructions stored in the memory 210 and to perform various processes for managing the synchronization between the CU 100, the DU 200, and the RU 300, as discussed throughout the disclosure. The processor 220 may include one or a plurality of processors, maybe a general-purpose processor, such as a Central Processing Unit (CPU), an Application Processor (AP), or the like, a graphics-only processing unit such as a Graphics Processing Unit (GPU), a Visual Processing Unit (VPU), and/or an Artificial intelligence (Al) dedicated processor such as a Neural Processing Unit (NPU).

[0040] In one or more embodiments, the processor 220 may include an E2E carrier activation module 221. The E2E carrier activation module 221 is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The E2E carrier activation module 221 may execute multiple operations to manage the synchronization between the CU 100, the DU 200, and the RU 300, which are given below.

[0041] In one or more embodiments, the E2E carrier activation module 221 may receive the cell activation command from the CU 100. The E2E carrier activation module 221 may then transmit the one or more carrier activation commands towards at least one of the second entity associated with the DU 200 and the RU 300 in the predefined carrier activation sequence order to initiate the carrier activation. The E2E carrier activation module 221 may then receive the response message from one or more of the second entity and the RU in response to the one or more transmitted carrier activation commands. The response message comprises one of the Ack message or the NAck message. The E2E carrier activation module 221 may then synchronize the carrier state among the DU 200, the CU 100, and the RU 300 based on the received response message, as described in conjunction with FIGS. 4A-4C, and FIG. 5.

[0042] In one or more embodiments, to synchronize the carrier state, the E2E carrier activation module 221 may execute multiple operations, which are given below.

[0043] In one embodiment, the E2E carrier activation module 221 may identify the reception of the NAck message from one or more of the second entity or the RU 300. The NAck message indicates an unsuccessful activation of a carrier at one or more of the second entity or the RU. The E2E carrier activation module 221 may then retransmit the one or more carrier activation commands to the identified second entity or the identified RU 300 in order to achieve synchronization of the carrier state.

[0044] In one embodiment, the E2E carrier activation module 221 may identify the reception of the Ack message from one or more of the second entity or the RU 300. The Ack message indicates a successful activation of the carrier at one or more of the second entity or the RU 300. The E2E carrier activation module 221 may then activate, upon identification of the Ack message, a cell at the DU 200. The E2E carrier activation module 221 may then receive a CU-response message from the CU 100 in response to transmitting the cell-in-service command. The response message comprises one of a CU Ack message or a CU NAck message. The E2E carrier activation module 221 may then synchronize the carrier state among the DU 200, the CU 100, and the RU 300 based on the received response message.

[0045] In one embodiment, the E2E carrier activation module 221 may identify the reception of the CU-Ack message from the CU 100, wherein the Ack message indicates a successful activation of the carrier at the DU 200, the CU 100, and the RU 300. The E2E carrier activation module 221 may then identify, upon reception of the identified CU-Ack message, synchronization of the carrier state among the DU 200, the CU 100, and the RU 300, as illustrated in conjunction with FIG. 4C. [0046] In one embodiment, the E2E carrier activation module 221 may identify the reception of the CU-NAck message from the CU 100. The CU-NAck message indicates an unsuccessful activation of the carrier at the CU 100. The E2E carrier activation module 221 may then initiate, upon identification of the CU-NAck message, a carrier deactivation at the second entity and the RU 300 in a predefined carrier deactivation sequence order in order to achieve synchronization of the carrier state, as illustrated in conjunction with FIG. 5. The predefined carrier deactivation sequence order is first as the RU 300, second as the LI application, and third as the L2 application. [0047] In one embodiment, the E2E carrier activation module 221 may receive the response message from one or more of the second entity and the RU 300 in response to the one or more transmitted carrier activation commands. The response message comprises the NAck message. The E2E carrier activation module 221 may then identify, upon reception of the NAck message, an entity (e.g., FICmgr) that shares the NAck message among the one or more of the second entity and the RU 300. The E2E carrier activation module 221 may then retransmit a carrier activation command towards the identified entity. Then, the E2E carrier activation module 221 may continue to retransmit the one or more carrier activation commands towards other second entity associated with the DU 200 or the RU 300 based on the predefined carrier activation sequence order to reinitiate the carrier activation. The E2E carrier activation module 221 may then synchronize, after reinitiating the carrier activation, the carrier state among the DU 200, the CU 100, and the RU 300, as illustrated in conjunction with FIG. 5.

[0048] The communicator 230 is configured for communicating internally between internal hardware components and with external devices (e.g., the CU 100, the RU 300, etc.) via one or more networks (e.g., radio technology). The communicator 230 includes an electronic circuit specific to a standard that enables wired or wireless communication.

[0049] Although FIG. 3B shows various hardware components of the DU 200, but it is to be understood that other embodiments are not limited thereon. In other embodiments, the DU 200 may include less or more number of components. Further, the labels or names of the components are used only for illustrative purposes and do not limit the scope of the present disclosure. One or more components can be combined to perform the same or substantially similar functions to manage the synchronization between the CU 100, the DU 200, and the RU 300.

[0050] FIGS. 4A-4C are exemplary sequence flow diagrams that illustrate one or more operations involved in executing a cell initialization method 400 to manage the synchronization, according to an embodiment as disclosed herein.

[0051] Referring to FIG. 4A: in the cell initialization process, the various entities involved, such as the CU 100, the DU 200 (including the System Manager (sysmgr) 200a, the Radio Unit Manager (RUmgr) 200b, the F1C Manager (FICmgr) 200c, the Layer 1 (LI) application 200dl, the Layer 2 (L2) application 200d2, and the Configuration (conf.) module 400a), and the RU 300, execute a series of operations to manage the synchronization.

[0052] At operation 401, the conf, module 400a sends a configuration pushed message to the System Manager (sysmgr 200a) to configure the NR cell with a specific cell ID (n). At operation 402, the conf, module 400a sends a separate configuration pushed message to the L2 application 200d2 to configure the same NR cell with the same cell ID (n).

[0053] During this initial stage, the administrative state is set to “locked”, the operational state is set to “disabled”, and the cell state is set to “idle” for both the sysmgr 200a and the RUmgr 200b. If the administrative state is locked in the NR cell Distributed Unit (DU) configuration, the flow will wait until the northbound entity (e.g., network management system) changes the state to “unlocked”.

[0054] At operation 403, the conf, module 400a sends a dynamic configuration update to the sysmgr 200a, changing the administrative state of the NR cell to “unlocked”. Upon receiving the dynamic configuration update, the administrative state is changed to “unlocked”, the operational state is set to “disabled”, and the cell state is set to “idle” for both the sysmgr 200a and the RUmgr 200b. At operation 404, the sysmgr 200a adds a carrier configuration for the NR cell, identified by the cell ID (n) and the Network Slice Subnet ID (NSC ID: m). The sysmgr 200a initiates the carrier configuration procedure at the baseband, including the initialization of the Baseband Unit (BBU) Pool. At operation 405, the L2 application 200d2 sends a carrier configuration status message to the sysmgr 200a. Then, the RU 300 serial number is configured to accept the call home connection. At operation 406, the RU 300 establishes a call home connection with the RUmgr 200b. At operation 407, the RUmgr 200b sends a radio registration request to the sysmgr 200a, including the RU’s serial number and the list of supported carrier IDs. At operation 408, the sysmgr 200a sends the baseband carrier configuration status to the RUmgr 200b, including the BBU Pool ID and the Distributed Unit (DU) MAC address. At operation 409, the RUmgr 200b then establishes the M-plane (Management plane) carrier configuration with the RU 300.

[0055] Referring to FIGS. 4B-4C: at operation 410, the RUmgr 200b sends a RU-specific configuration to the LI application 200dl. This configuration contains parameters and settings specific to the RU 300 that the LI application 200dl needs to configure and operate the RU hardware and software. At operation 411, the RUmgr 200b sends a radio carrier configuration to the sysmgr 200a. This configuration includes the specific carrier parameters, such as the frequency, bandwidth, and other relevant settings, that the sysmgr 200a needs to configure the baseband processing resources for the RU 300. At operation 412, the RUmgr 200b sends timing lock information to the sysmgr 200a. This information ensures that the DU 200 and the RU 300 are synchronized in terms of timing, which is critical for the proper operation of the radio interface. During this stage, the administrative state is set to “unlocked”, the operational state is set to “enabled”, and the cell state is set to “idle” for both the sysmgr 200a and the RUmgr 200b.

[0056] At operation 413, the sysmgr 200a sends a command to add the cell to the FICmgr 200c. This command initiates the process of establishing the Fl interface connection between the DU 200 and the CU 100. At operation 414, upon reception of the command, the FICmgr 200c sends an Fl setup request to the CU 100. This request initiates the Fl interface setup procedure between the DU 200 and the CU 100. At operation 415, upon reception of the Fl setup request, the CU 100 sends an Fl setup response to the FICmgr 200c. This response completes the Fl interface setup process and establishes the necessary signaling and data connections between the DU 200 and the CU 100. The NG set up with the core network and the CU-UP (Centralized Unit User Plane) supports the Public Land Mobile Network (PLMN) configuration. At operation 416, the CU 100 sends a CU configuration update message to the FICmgr 200c. This message contains the updated configuration parameters for the CU 100, which the FICmgr 200c needs to apply to the DU 200 side to ensure a consistent and synchronized operation between the CU 100 and the DU 200.

[0057] At operation 417, upon receiving the CU configuration update message, the FICmgr 200c sends an active cell command (i.e., cell activation command) to the sysmgr 200a. Now, the disclosed method and operations in this cell initialization method 400 differ from the existing telecommunication systems, as highlighted by the notations “A”, “B”, and “C”. These notations indicate the specific areas or operations where the disclosed method deviates from the traditional approaches used in existing telecommunication systems. The differences may be in terms of the sequence of operations, the interactions between the entities, the configuration parameters, or the overall cell activation workflow, as described below.

[0058] At operations 418, 420, 422, and 423 the sysmgr 200a transmits the one or more carrier activation commands (e.g., carrier start, RU activate carrier, etc.) towards at least one of the second entity (e.g., L2 application 200d2, LI application 200dl, etc.) and the RU 300 in the predefined carrier activation sequence order to initiate the carrier activation. At operations 419, 421, 424, and 425, the sysmgr 200a receives the response message (e.g., carrier operational status, carrier active response, radio carrier operational status, etc.), as the Ack message or Nack message, from one or more of the second entity and the RU 300 in response to the one or more transmitted carrier activation commands. During this stage, the administrative state is set to “unlocked”, the operational state is set to “enabled”, and the cell state is set to “active” for both the sysmgr 200a and the RUmgr 200b.

[0059] At operations 426-427, upon receiving the Ack message from either the second entity (e.g., LI application 200dl, L2 application 200d2) or the RU 300, the sysmgr 200a activates the cell at the DU 200. The sysmgr 200a then transmits the “cell-in-service” command or a “DU config update” message to the CU 100 via the FICmgr 200c. This operation ensures that the DU is ready to provide service and notifies the CU about the cell activation status.

[0060] At operations 428-429, the FICmgr 200c receives a CU-response message (e.g., “DU config update Ack”) from the CU 100 in response to the “cell-in-service” command or “DU config update” message transmitted in the previous step. Upon receiving the CU-response message, the FICmgr 200c transmits a “DU config update status” message to the sysmgr 200a. This exchange of messages between the DU 200, the FICmgr 200c, and the CU 100 confirms the successful configuration update and synchronization of the cell state. As a result of these operations, the sysmgr 200a establishes and manages the synchronization of the carrier state among the DU 200, the CU 100, and the RU 300. This ensures that the cell is properly activated and all the involved entities (the DU 200, the CU 100, and the RU 300) are in a synchronized state, ready to provide service.

[0061] FIG. 5 is an exemplary sequence flow diagram that illustrates one or more operations involved in executing a cell auto-recovery method 500 to manage the synchronization, according to an embodiment as disclosed herein.

[0062] In the cell auto-recovery method 500, consider a scenario where the administrative state is set to “unlocked”, the operational state is set to “enabled”, and the cell state is set to “active” for both the sysmgr 200a and the RUmgr 200b.

[0063] At operations 501-502, the sysmgr 200a transmits the “cell-in-service” command or a “DU config update” message to the CU 100 via the FICmgr 200c. This operation ensures that the DU is ready to provide service and notifies the CU about the cell activation status. At operation 503, the FICmgr 200c receives a CU-response message (e.g., “DU config update NAck”) from the CU 100 in response to the “cell-in-service” command or “DU config update Nack” message.

[0064] Now, the disclosed method and operations in this cell auto-recovery method 500 differ from the existing telecommunication systems, as highlighted by the notations “D” and “E”. These notations indicate the specific areas or operations where the disclosed method deviates from the traditional approaches used in existing telecommunication systems. The differences may be in terms of the sequence of operations, the interactions between the entities, the configuration parameters, or the overall cell auto-recovery workflow, as described below.

[0065] At operation 504, upon receiving the CU-response message, the FICmgr 200c transmits a “DU config update Nack” message to the sysmgr 200a. This exchange of messages between the DU 200, the FICmgr 200c, and the CU 100 confirms the unsuccessful configuration update and synchronization of the cell state.

[0066] At operations 505 to 512, upon identifying the reception of the CU-NAck message from the CU 100, the sysmgr 200a initiates the carrier deactivation at the second entity (e.g., L2 application 200d2, LI application 200dl, etc.) and the RU 300 in the predefined carrier deactivation sequence order in order to achieve synchronization of the carrier state. In other words, the sysmgr 200a transmits one or more carrier deactivation commands (e.g., deactivate carrier, carrier deactivate, etc.) towards at least one of the second entity associated with the DU and the RU. The sysmgr 200a then receives a response message (e.g., deactivation success, carrier operational state down, etc.) from one or more of the second entity and the RU in response to the one or more transmitted carrier deactivation commands. During this stage, the administrative state is set to “unlocked”, the operational state is set to “disabled”, and the cell state is set to “inactive” for both the sysmgr 200a and the RUmgr 200b.

[0067] At operations 513-514, the sysmgr 200a sends a get cell activate list message to the F ICmgr 200c when all operation statuses are in ok-state. The FICmgr 200c sends the cell active command and initiates the carrier activation flow as described in FIGS. 4A-4C. Further, the sysmgr 200a determines whether any operational status is down or not, and waits until all operational status are up. [0068] In other words, the sysmgr 200a identifies, upon receiving the NAck message, an entity that shares the NAck message among the one or more of the second entity and the RU 300. The sysmgr 200a retransmits a carrier activation command towards the identified entity, then continues to retransmit the one or more carrier activation commands towards other second entity associated with the DU 200, or the RU 300 based on the predefined carrier activation sequence order to reinitiate the carrier activation. As a result, the sysmgr 200a achieves synchronization, after reinitiating the carrier activation, the carrier state among the DU 200, the CU 100, and the RU 300. [0069] In one or more embodiments, if the CU 100 generates a failure response during the IN_SERVICE state, the CU 100 may trigger the deactivation of the carrier at the DU 200 and the RU 300. Once the carrier is deactivated at the RU 300 and the DU 200, this ensures that there is no mismatch in the state between the ORAN components (plurality of logical entities). If the activation failure is due to the activation procedure, the sysmgr 200a may query the CU 100 for the cell activation list again. As a response to the activate cell command, the sysmgr 200a may reinitiate the carrier activation flow. By doing this, the sysmgr 200a avoids any mismatch in the cell state across the ORAN components and re-triggers the carrier activation process in case of a failure at any component during the carrier activation. This ensures the synchronization and consistency of the cell state across the ORAN components, and the ability to recover from activation failures by re-triggering the activation process.

[0070] In one or more embodiments, the sysmgr 200a may perform carrier auto recovery if all the interfaces (e g., fronthaul, midhaul, timing sync, etc.) are fine.

[0071] FIG. 6 is a flow diagram illustrating a method 600 for managing the synchronization between the plurality of logical entities, according to an embodiment as disclosed herein. The E2E carrier activation module 221 may execute multiple operations to manage the synchronization between the plurality of logical entities (e.g., the CU 100, the DU 200, and the RU 300), which are given below.

[0072] At operation 601, the method 600 includes receiving, at the first entity associated with the DU 200, the cell activation command from the CU 100. At operation 602, the method 600 includes transmitting, upon receiving the cell activation command, the one or more carrier activation commands towards at least one of the second entity associated with the DU and the RU in the predefined carrier activation sequence order to initiate the carrier activation. At operation 603, the method 600 includes receiving the response message from one or more of the second entity and the RU in response to the one or more transmitted carrier activation commands. The response message comprises one of the Ack message or the NAck message. At operation 604, the method 600 includes synchronizing the carrier state among the DU 200, the CU 100 and the RU 300 based on the received response message.

[0073] The method described in para [0071], the method includes identifying reception of the NAck message from one or more of the second entity or the RU 300. The NAck message indicates an unsuccessful activation of a carrier at one or more of the second entity or the RU 300. The method further includes retransmitting the one or more carrier activation commands to the identified second entity or the identified RU 300 in order to achieve synchronization of the carrier state.

[0074] The method described in any one of paragraphs [0071]-[0072], the method includes identifying reception of the Ack message from one or more of the second entity or the RU 300. The Ack message indicates a successful activation of the carrier at one or more of the second entity or the RU 300. The method further includes activating, upon identification of the Ack message, the cell at the DU 200. The method further includes transmitting, after activation of the cell, a cellin-service command to the CU 100. The method further includes receiving the CU-response message from the CU 100 in response to transmitting the cell in service command. The response message comprises one of the CU Ack message or the CU NAck message. The method further includes synchronizing the carrier state among the DU (200), the CU (100), and the RU (300) based on the received response message.

[0075] The method described in any one of paragraphs [0071]-[0073], the method includes identifying reception of the CU-Ack message from the CU 100. The Ack message indicates the successful activation of the carrier at the DU 200, the CU 100, and the RU 300. The method further includes identifying, upon reception of the identified CU-Ack message, synchronization of the carrier state among the DU 200, the CU 100, and the RU 300.

[0076] The method described in any one of paragraphs [0071]-[0074], the method includes identifying reception of the CU-NAck message from the CU 100. The CU-NAck message indicates the unsuccessful activation of the carrier at the CU 100. The method further includes initiating, upon identification of the CU-NAck message, the carrier deactivation at the second entity and the RU (300) in the predefined carrier deactivation sequence order in order to achieve synchronization of the carrier state.

[0077] The method described in any one of paragraphs [007 l]-[0075], the method includes receiving the response message from one or more of the second entity and the RU 300 in response to the one or more transmitted carrier activation commands. The response message comprises the NAck message. The method further includes identifying, upon receiving the NAck message, the entity that share the NAck message among the one or more of the second entity and the RU 300. The method further includes retransmitting the carrier activation command towards the identified entity. Then, continue to retransmit the one or more carrier activation commands towards other second entity associated with the DU (200), or the RU (300) based on the predefined carrier activation sequence order to reinitiate the carrier activation. The method further includes synchronizing, after reinitiating the carrier activation, the carrier state among the DU 200, the CU 100, and the RU 300.

[0078] The method described in any one of paragraphs [0071]-[0076], the predefined carrier activation sequence order is first as the L2 application, second as the LI application, and third as the RU 300.

[0079] The method described in any one of paragraphs [0071 ]-[0077], the predefined carrier deactivation sequence order is first as the RU 300, second as the LI application, and third as the L2 application.

[0080] The method described in any one of paragraphs [0071 ]-[0078], the first entity comprises the sysmgr. The second entity comprises at least one of the baseband application, the RUMGR application, the F1CMGR application, the FCAPs application, the timing application, and the etcd. The baseband application comprises the LI application and the L2 application.

[0081] The method described in any one of paragraphs [0071 ]-[0079], the carrier state refers to one or more operational status of the RF carrier within at least one communication device comprising at least one of the active state, the inactive state, the standby state or the undergoing maintenance state.

[0082] According to another aspect, the apparatus implemented at the DU 200. The apparatus is configured to receive, at the first entity associated with the DU 200, the cell activation command from the CU 100. The apparatus is configured to transmit, upon reception of the cell activation command, the one or more carrier activation commands towards at least one of the second entity associated with the DU 200 and the RU 300 in the predefined carrier activation sequence order to initiate the carrier activation. The apparatus is configured to receive the response message from one or more of the second entity and the RU 300 in response to the one or more transmitted carrier activation commands. The response message comprises one of the Ack message or the NAck message. The apparatus is configured to synchronize the carrier state among the DU 200, the CU 100, and the RU 300 based on the received response message.

[0083] FIG. 7 illustrates a diagram of example components of a system 700, according to an embodiment as disclosed herein. As shown in FIG. 7, the system 700 comprises a processor 710, a memory 720, a storage component 730, an input component 740, an output component 750, a communication interface 760, and a bus 770. In one embodiment, the system 700 may relate to at least one of the CU 100, the DU 200, the RU 300, or any other network device.

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

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

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

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

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

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

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

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

[0092] The various actions, acts, blocks, steps, or the like in the flow diagrams or sequence flow diagrams may be performed in the order presented, in a different order, or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the present disclosure.

[0093] The disclosed method 600 has several advantages over the existing telecommunication systems, for example, which are stated below, a. Avoid mismatch in cell state across the plurality of logical entities: The synchronization of carrier state among the DU 200, CU 100, and RU 300 ensures that the cell state is consistent across the different logical entities, preventing any mismatch. b. Ensures synchronization between the plurality of logical entities: The method establishes a predefined carrier activation sequence and utilizes Ack or NAck messages to synchronize the carrier state among the plurality of logical entities. c. Minimal service interruption in case of failures: The synchronization mechanism and the ability to handle both Ack and NAck responses help minimize the impact of failures during the carrier activation process, ensuring minimal service disruption. d. Quick and silent recovery of the application: The automated synchronization and self-healing capabilities of the method enable the application to recover quickly and silently from unexpected failures, without the need for human intervention. e. Automatic healing from unexpected failures during carrier activation: The method’s self-healing mechanisms can automatically address and recover from unexpected failures that may occur during the carrier activation process, reducing the need for manual intervention. f. No human intervention during self-healing: The automated nature of the synchronization and self-healing process eliminates the need for human intervention, resulting in cost savings and efficient system management.

[0094] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device or a combination of hardware devices and software modules. [0095] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0096] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0097] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0098] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

[0099] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

1. A method (600) comprising: receiving (601), at a first entity associated with a Distributed Unit (DU) (200), a cell activation command from a Central Unit (CU) (100); transmitting (602), upon receiving the cell activation command, one or more carrier activation commands towards at least one of a second entity associated with the DU (200) and a Radio Unit (RU) (300) in a predefined carrier activation sequence order to initiate a carrier activation; receiving (603) a response message from any combination of the second entity and the RU (300) in response to the one or more transmitted carrier activation commands, wherein the response message comprises one of an Acknowledgement (Ack) message or a Negative Acknowledgement (NAck) message; and synchronizing (604) a carrier state among the DU (200), the CU (100), and the RU (300) based on the received response message.

2. The method (600) as claimed in claim 1, wherein synchronizing the carrier state comprises: identifying reception of the NAck message from one or more of the second entity or the RU (300), wherein the NAck message indicates an unsuccessful activation of a carrier at any combination of the second entity or the RU (300); and retransmitting the one or more carrier activation commands to the identified second entity or the identified RU in order to achieve synchronization of the carrier state.

3. The method (600) as claimed in claim 1, wherein synchronizing the carrier state comprises: identifying reception of the Ack message from any combination of the second entity or the RU (300), wherein the Ack message indicates a successful activation of a carrier at one or more of the second entity or the RU (300); activating, upon identification of the Ack message, a cell at the DU (200); transmitting, after activation of the cell, a cell-in-service command to the CU (100); receiving a CU-response message from the CU (100) in response to transmitting the cell in service command, wherein the response message comprises one of an CU Acknowledgement (Ack) message or a CU Negative Acknowledgement (NAck) message; and synchronizing the carrier state among the DU (200), the CU (100), and the RU (300) based on the received response message.

4. The method (600) as claimed in claim 3, wherein synchronizing the carrier state comprises: identifying reception of the CU-Ack message from the CU (100), wherein the Ack message indicates a successful activation of a carrier at the DU (200), the CU (100), and the RU (300); and identifying, upon reception of the identified CU-Ack message, synchronization of the carrier state among the DU (200), the CU (100), and the RU (300).

5. The method (600) as claimed in claim 3, wherein synchronizing the carrier state comprises: identifying reception of the CU-NAck message from the CU (100), wherein the CU-NAck message indicates an unsuccessful activation of a carrier at the CU (100); and initiating, upon identification of the CU-NAck message, a carrier deactivation at the second entity and the RU (300) in a predefined carrier deactivation sequence order in order to achieve synchronization of the carrier state.

6. The method (600) as claimed in claim 1, further comprising: receiving the response message from any combination of the second entity and the RU (300) in response to the one or more transmitted carrier activation commands, wherein the response message comprises the NAck message; identifying, upon receiving the NAck message, an entity that shares the NAck message among the one or more of the second entity and the RU (300); retransmitting a carrier activation command towards the identified entity, then continuing to retransmit the one or more carrier activation commands towards other second entity associated with the DU (200), or the RU (300) based on the predefined carrier activation sequence order to reinitiate the carrier activation; and synchronizing, after reinitiating the carrier activation, the carrier state among the DU (200), the CU (100), and the RU (300).

7. The method (600) as claimed in claim 1 , wherein the predefined carrier activation sequence order is first as a Layer-2 (L2) application, second as a Layer-1 (LI) application, and third as the RU (300).

8. The method (600) as claimed in claim 5, wherein the predefined carrier deactivation sequence order is first as the RU (300), second as a Layer- 1 (LI) application, and third as a Layer-2 (L2) application.

9. The method (600) as claimed in claim 1 , comprising: wherein the first entity comprises a system manager application (SYSMGR); wherein the second entity comprises at least one of a baseband application, a Radio Unit Manager (RUMGR) application, a Fronthaul Interface Manager (F1CMGR) application, a Functional Capabilities (FCAPs) application, a timing application, and an extended distributed key -value store (etcd); and wherein the baseband application comprises a Layer-1 (LI) application and a Layer-2 (L2) application.

10. The method (600) as claimed in claim 1, wherein the carrier state refers to one or more operational status of a Radio Frequency (RF) carrier within at least one communication device comprising at least an active state, an inactive state, a standby state or undergoing a maintenance state.

11. An apparatus implemented at a Distributed Unit (DU) (200), wherein the apparatus is configured to: receive, at a first entity associated with the DU (200), a cell activation command from a Central Unit (CU) (100); transmit, upon receiving the cell activation command, one or more carrier activation commands towards at least one of a second entity associated with the DU (200) and a Radio Unit (RU) (300) in a predefined carrier activation sequence order to initiate a carrier activation; receive a response message from any combination of the second entity and the RU (300) in response to the one or more transmitted carrier activation commands, wherein the response message comprises one of an Acknowledgement (Ack) message or a Negative Acknowledgement (NAck) message; and synchronize a carrier state among the DU (200), the CU (100), and the RU (300) based on the received response message.

12. The apparatus as claimed in claim 11, wherein to synchronize the carrier state, the apparatus is configured to: identify reception of the NAck message from any combination of the second entity or the RU (300), wherein the NAck message indicates an unsuccessful activation of a carrier at one or more of the second entity or the RU (300); and retransmit the one or more carrier activation commands to the identified second entity or the identified RU (300) in order to achieve synchronization of the carrier state.

13. The apparatus as claimed in claim 11, wherein to synchronize the carrier state, the apparatus is configured to: identify reception of the Ack message from any combination of the second entity or the RU (300), wherein the Ack message indicates a successful activation of a carrier at one or more of the second entity or the RU (300); activate, upon identification of the Ack message, a cell at the DU (200); transmit, after activation of the cell, a cell-in-service command to the CU (100); receive a CU-response message from the CU (100) in response to transmitting the cell in service command, wherein the response message comprises one of an CU Acknowledgement (Ack) message or a CU Negative Acknowledgement (NAck) message; and synchronize the carrier state among the DU (200), the CU (100), and the RU (300) based on the received response message.

14. The apparatus as claimed in claim 13, wherein to synchronize the carrier state, the apparatus is configured to: identify reception of the CU-Ack message from the CU (100), wherein the Ack message indicates a successful activation of a carrier at the DU (200), the CU (100), and the RU (300); and identify, upon reception of the identified CU-Ack message, synchronization of the carrier state among the DU (200), the CU (100), and the RU (300).

15. The apparatus as claimed in claim 13, wherein to synchronize the carrier state, the apparatus is configured to: identify reception of the CU-NAck message from the CU (100), wherein the CU- NAck message indicates an unsuccessful activation of a carrier at the CU (100); and initiate, upon identification of the CU-NAck message, a carrier deactivation at the second entity and the RU (300) in a predefined carrier deactivation sequence order in order to achieve synchronization of the carrier state.

16. The apparatus as claimed in claim 11, further comprising: receive the response message from any combination of the second entity and the RU (300) in response to the one or more transmitted carrier activation commands, wherein the response message comprises the NAck message; identify, upon receiving the NAck message, an entity that shares the NAck message among the one or more of the second entity and the RU (300); retransmit a carrier activation command towards the identified entity, then continue to retransmit the one or more carrier activation commands towards other second entity associated with the DU (200), or the RU (300) based on the predefined carrier activation sequence order to reinitiate the carrier activation; and synchronize, after reinitiating the carrier activation, the carrier state among the DU (200), the CU (100), and the RU (300).

17. The apparatus as claimed in claim 11, wherein the predefined carrier activation sequence order is first as a Layer-2 (L2) application, second as a Layer-1 (LI) application, and third as the RU (300).

18. The apparatus as claimed in claim 15, wherein the predefined carrier deactivation sequence order is first as the RU, second as a Layer-1 (LI) application, and third as a Layer-2 (L2) application.

19. The apparatus as claimed in claim 11, comprising: wherein the first entity comprises a system manager application (SYSMGR); wherein the second entity comprises at least one of a baseband application, a Radio Unit Manager (RUMGR) application, a Fronthaul Interface Manager (F1CMGR) application, a Functional Capabilities (FCAPs) application, a timing application, and an extended distributed key -value store (etcd); and wherein the baseband application comprises a Layer-1 (LI) application and a Layer-2 (L2) application.

20. The apparatus as claimed in claim 11, wherein the carrier state refers to one or more operational status of a Radio Frequency (RF) carrier within at least one communication device comprising at least an active state, an inactive state, a standby state or undergoing a maintenance state.