Digital twin service in open-radio access network

Abstract

Disclosed herein is an apparatus. The apparatus is configured to generate one or more Digital Twin (DT) services. The DT services provide access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN. The apparatus is also configured to enable one or more DT service consumers to access the generated one or more DT services. The generated one or more DT services are accessed via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

Description

DIGITAL TWIN SERVICE IN OPEN-RADIO ACCESS NETWORKCROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority to Indian Provisional Application No. 202411059093, filed on August 5, 2024, and Indian Non-Provisional Application No. 202411059093, filed on May 8, 2025, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to a Digital Twin (DT) service in an Open-Radio Access Netw ork (O-RAN).BACKGROUND

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

[0004] Open Radio Access Network (O-RAN) is a non-proprietary version of a Radio Access Network (RAN) that supports interoperability’ between cellular network equipment from different vendors. Significant research and development efforts are underway to implement O- RAN architectures. Additionally, a Digital Twin (DT) is a real-time representation of physical components in a digital w orld. Incorporating one or more DT services in O-RAN systems offers numerous advantages across various scenarios and use cases. For example, the one or more DT services are widely utilized in smart manufacturing and industry applications, includingaerospace engineering, electrical grids, automotive production, and petroleum sector.Moreover, the one or more DT sendees are anticipated to be used extensively in emerging fields like smart cities, human activity monitoring, and scientific research.SUMMARY

[0005] 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 present disclosure nor is it intended to determine the scope of the disclosure.

[0006] According to one embodiment of the present disclosure, an apparatus is disclosed. The apparatus is configured to generate one or more Digital Twin (DT) services. The DT services provide access to a digital replica of at least one of one or more Open-Radio Access Netw ork (0-RAN) services, one or more O-RAN architecture elements, one or more 0-RAN netw ork functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an 0-RAN. The apparatus is also configured to enable one or more DT service consumers to access the generated one or more DT services. The generated one or more DT services are accessed via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

[0007] According to another embodiment of the present disclosure, a method is disclosed. The method includes generating one or more Digital Twin (DT) services. The one or more DT sendees provide access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions, one or more User Equipment (UEs), and one or more connectivity betweenone or more entities in an O-RAN. The one or more DT services are generated by a DT service producer. The method also includes enabling, by the DT service producer, one or more DT service consumers to access the generated one or more DT services. The generated one or more DT services are accessed via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

[0008] According to another embodiment of the present disclosure, a non-transilory computer- readable medium is disclosed. The non-transitory computer-readable medium stores instructions that, when executed by one or more processors at a Digital Twin (DT) service producer, cause the one or more processors to generate one or more Digital Twin (DT) services. The DT services provide access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs). and one or more connectivity between one or more entities in an O-RAN. The one or more processors also enable one or more DT service consumers to access the generated one or more DT services. The generated one or more DT services are accessed via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).BRIEF DESCRIPTION OF DRAWINGS

[0009] 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 Open Radio Access Network (O-RAN) architecture, according to the state of art;FIG. 2 illustrates a functional view of an O-RAN standard compliant Non-Real TimeRAN Intelligent Controller (Non-RT RIC) architecture, according to the state of art;FIG. 3 illustrates a sendee-based view of the O-RAN standard compliant Non-RT RIC architecture, according to the state of art;FIG. 4 illustrates an O-RAN standard compliant Near-Real Time RIC (Near-RT RIC) architecture, according to the state of art;FIG. 5 illustrates a service-based Service Management and Orchestration (SMO) architecture including one or more SMO sendees (SMOS), according to the state of art; FIG. 6 illustrates an example environment for implementation of a Digital Twin (DT) as a sen ice in the O-RAN, in accordance with an embodiment of the present disclosure; FIG. 7 illustrates an example environment depicting one or more implementation or deployment options for generated one or more DT services within the SMO, the Non- RT RIC, and across one or more O-RAN interfaces associated with the one or more DT services, in accordance with an embodiment of the present disclosure;FIG. 8 illustrates an example environment depicting one or more implementation or deployment options for the generated one or more DT services in the Near-RT RIC and across the one or more O-RAN interfaces associated with the one or more DT services, in accordance w ith an embodiment of the present disclosure;FIG. 9 illustrates an example environment depicting one or more implementation or deployment options for the one or more DT services within O-RAN Network Functions (NFs) and across the one or more O-RAN interfaces associated with the one or more DT services, in accordance w ith an embodiment of the present disclosure;FIG. 10 illustrates a flowchart depicting a method for implementing the DT as a service in the O-RAN, in accordance with an embodiment of the present disclosure;FIG. 11 illustrates a flowchart depicting a method for providing access to one or more DT service consumers to the generated one or more DT services, in accordance with an embodiment of the present disclosure; andFIG. 12 illustrates an embodiment of a device, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

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

[0011] 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 hardw are or softw are code used to implement these systems and / or methodsis not limiting of the 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.

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

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

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

[0015] In the present disclosure, specific tasks may be performed using ArtificialIntelligence / Machine Learning (AI / ML) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithms, or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc.

[0016] Although Al and ML are explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve their performance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0017] Machine learning includes various ty pes of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, selfsupervised learning, transudative learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, and is not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0018] It should be noted that the AI / ML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0019] A digital twin (DT) may refer to a digital representation of a physical network. The DT may be used for functions such as analyzing, diagnosing, emulating, and controlling the physical network. The functions may be performed based on data, model, and interface to achieve a real-time interactive mapping between the physical network and the DT. Incorporating DT services into Open Radio Access Network (O-RAN) systems offers numerous advantages across various scenarios and use cases. For example, DT services are widely utilized in smart manufacturing and industry applications, including aerospace engineering, electrical grids, automotive production, and petroleum sector. Moreover, DT services are anticipated to be used extensively in emerging fields like smart cities, human activity monitoring, and scientific research.

[0020] However, existing techniques provide only a limited understanding of the types of DT services that may be integrated into the O-RAN systems. Furthermore, there is limited understanding regarding the effective implementation and integration of various DT services within an O-RAN framework.

[0021] FIG. 1 illustrates an O-RAN architecture 100, according to the state of art. The present disclosure is applicable to other configurations of a Non Real-Time RAN Intelligent Controller (Non-RT RIC) architecture as well, and the description provided for FIG. 1 is non-limiting to the scope of the present disclosure. The components illustrated in FIG. 1 are described in detail in the following paragraphs. The O-RAN architecture 100 includes a Non-RT RIC 104.

[0022] The Non-RT RIC 104 is a logical function that enables non-real-time control and optimization of RAN elements and resources. The Non-RT RIC 104 supports AI / ML workflows, including model training and updates, as well as policy-based guidance of applications and features. The Non-RT RIC 104 operates within a Service Management and Orchestration (SMO) framework 102 (hereinafter referred to as '“the SMO 1O2’?).

[0023] The O-RAN architecture 100 includes a Near-RT RIC 108. The Near-RT RIC 108 is a logical function that enables near-real-time control and optimization of the RAN elements and resources. The Near-RT RIC 108 operates by performing fine-grained data collection and actions (such as on a per-User Equipment (UE) basis or a per-cell basis) over an E2 interface.

[0024] An O-RAN Central Unit (O-CU) is a logical node hosting Radio Resource Control (RRC) protocols. Service Data Adaptation Protocols (SDAPs), and Packet Data Convergence Protocols (PDCPs). An O-RAN Central Unit-Control Plane (O-CU-CP) 114 is a logical node hosting the RRC and a control plane part of the PDCP. An O-RAN Central Unit-User Plane (O- CU-UP) 116 is a logical node hosting a user plane part of the PDCP along with the SDAP.

[0025] An O-RAN Distributed Unit (O-DU) 118 is a logical node hosting Radio Link Control (RLC), Medium Access Control (MAC), and High-Physical (High-PHY) layer functions, based on a lower-layer functional split, as defined in the O-RAN architecture.

[0026] An O-RAN Radio Unit (O-RU) 120 is a logical node hosting Low-Physical (PHY) layer and Radio Frequency (RF) processing, based on a lower-layer functional split. Further, an O- RAN evolved Node B (O-eNB) 112 is either an eNB or a Next Generation-eNB supporting the E2 interface.

[0027] An 01 interface is an interface between orchestration and management entities (such as Orchestration or Network Management Systems (NMS)) and O-RAN managed elements. The01 interface supports operations and management functions, enabling Faults, Configuration,Accounting, Performance, and Security (FCAPS) management, as well as software management, file management, and other similar functions.

[0028] Further, an Open Fronthaul Management (M)-Plane is a management interface controlling the O-RU 120. generally driven by the O-DU 118. In a hybrid topology, the Open Fronthaul M-Plane may be managed by the SMO 102. An Open Fronthaul Centralized User Plane (CUS)-Plane is a logical plane responsible for managing the user plane data between different network elements. For example, the Open Fronthaul CUS-Plane facilitates the transmission and processing of user data across various RAN elements.

[0029] Additionally, the O-RAN architecture 100 supports one or more Non-RT RIC control loops 106, one or more Near-RT RIC control loops 110, and one or more RT control loops (not shown), involving various O-RAN functionalities. The one or more Non-RT RIC control loops 106 are part of the Non-RT RIC 104 and operate, for example, with a time frame of 1 second or longer. The one or more Near-RT RIC control loops 110 are part of the Near-RT RIC 108 and operate within a time frame of, for example, 10 milliseconds to just under 1 second. FIG. 1 also illustrates one or more O-DU control loops 124 responsible for managing and optimizing functions and resources within the O-DU 118. The one or more O-DU control loops 124 operate with extremely low latency, for example, typically less than 10 milliseconds.

[0030] An Al interface is an interface connecting the Non-RT RIC 104 and the Near-RT RIC 108, enabling policy-driven guidance for Near-RT RIC applications and functions, as well as supporting the AI / ML workflows. An E2 interface links the Near-RT RIC 108 to one or more O-CU-CPs 114, one or more O-CU-UPs 116, and one or more O-DUs 118. For the sake of clarity, external interfaces from the O-CU-CP 114 and O-CU-UP 116 are not illustrated in FIG.1. Further, interfaces from the O-CU-CP 114 may include X2-c, Xn-c, and NG-c interfaces.Furthermore, interfaces from the O-CU-UP 116 may include X2-u, Xn-u, and NG-u interfaces.

[0031] An O-Cloud 122 is a cloud computing platform including a collection of physical infrastructure nodes that meet O-RAN requirements. The O-Cloud 122 hosts relevant O-RAN functions such as the Near-RT RIC 108. the O-CU-CP 114. the O-CU-UP 116, and the O-DU 118. The O-Cloud 122 also hosts supporting software components (e.g.. Operating System (OS). Virtual Machine Monitor (VMA), container runtime, etc.) and necessary management and orchestration functions.

[0032] FIG. 2 illustrates a functional view of an O-RAN standard compliant Non-RT RIC architecture 200, according to the state of art. FIG. 3 illustrates a service-based view of the O- RAN standard compliant Non-RT RIC architecture 300, according to the state of art. FIGS. 2 and 3 have been explained together in detail in the forthcoming paragraphs for the sake of clarity.

[0033] In FIGS. 2 and 3, the Non-RT RIC 204. 304 includes one or more RAN Applications (rApps) 206-1, 206-2, ... 206-n, 306 (collectively referred to as the “rApps 206, 306”). The rApps 206, 306 are modular applications that leverage the functionality exposed by the Non- RT RIC 204, 304. The rApps 206, 306 operate within the SMO framework 202, 302, respectively to deliver value-added services for intelligent RAN optimization and operation. Examples of the value-added services may include, but are not limited to, policy-based guidance and enrichment information provided across the Al interface. Further, the value- added services include performing data analytics, AI / ML training, and inference to support RAN optimization or to assist other rApps 206, 306. Additionally, the value-added services may include recommending configuration management actions over the 01 interface.

[0034] An R1 interface (Open Application Programming Interfaces (APIs) for the rApps 206,306) is an internal interface within the Non-RT RIC 204, 304, connecting the rApps 206, 306 and a Non-RT RIC framework 205, 305. Further, the Non-RT RIC framework 205, 305 comprises one or more inherent Non-RT RIC framework functionalities. The one or more inherent Non-RT RIC framework functionalities include R1 service exposure functions 223. rApp management functions 230, one or more Al functions, AI / ML monitoring functions 238. other Non-RT RIC framework functions 228, and an Al termination 212, 308, as explained in the forthcoming paragraphs. Additionally, one or more E2 nodes 210, and 312 refer to logical nodes terminating the E2 interface.

[0035] As shown in FIG. 2. the R1 interface enables a set of R1 service exposure functions 223, which include a service registration and discovery function 226. an authentication and authorization function 224, AI / ML workflow services, and Al-related services. The rApp management functions 230 may govern deployment, orchestration, monitoring, and management of the rApps 206, 306 throughout the rApps’ lifecycle. The one or more Al functions may include Al Policy (P) functions 232, Al Enrichment Information (El) functions 234, Al Machine Learning (ML) functions 236, and the like.

[0036] Further, the AI / ML monitoring functions 238 are responsible for providing online monitoring functions to the AI / ML models in the Non-RT RIC 204, 304. For example, the AI / ML monitoring functions 238 may implement a contract-based strategy7for run-time monitoring of the AI / ML models, enabling support for various types of the AI / ML algorithms across multi-vendor scenarios.

[0037] Additionally, the SMO framework 202, 302 includes one or more implementation variability7functions such as one or more AI / ML workflow functions 248. The one or moreAI / ML workflow functions 248 include AI / ML model management functions, AI / ML data preparation functions, AI / ML modeling or training functions, and ML model repository. The AI / ML workflow functions 248 may be flexibly deployed either within the Non-RT RIC 204, 304, or outside the Non-RT RIC 204. 304 but within the SMO 202. 302, or even outside the SMO 202. 302. The SMO framework 202 may also include additional implementation variability functions such as Function 1 246-1, ... . Function n 246-n.

[0038] Further, the one or more implementation variability functions also include various logical terminations for external capabilities supported within the SMO framework, including such as an external El termination 242, an external AI / ML termination 244. and a humanmachine termination 250 (i.e., external capabilities termination 320 of FIG. 3). The external El termination 242 is connected to one or more external El sources 258 via an external El interface. Further, the external AI / ML tennination 244 is connected to one or more external AI / ML servers 256 via an external AI / ML interface. Furthermore, the human-machine tennination 250 is connected to a local craft tenninal 254 via an external human-machine interface. The one or more external El sources 258, the one or more external AI / ML servers 256, and the local craft terminal 254 correspond to external capabilities 322, as shown in FIG. 3. The external capabilities 322 may be connected to the external capabilities tennination 320 via one or more external (or, out of scope) interfaces. FIGS. 2 and 3 further illustrate the Near-RT RIC 208, 310 and the O-Cloud 218, 318, which correspond to the Near-RT RIC 108 and the O-Cloud 122 respectively of FIG. 1 and, therefore, have not been explained again for the sake of brevity7. Further, in FIG. 3, the rApps 306 and the Non-RT RIC framework 305 may interact via one or more R1 services. The one or more R1 sendees may include one or more services produced by the Non-RT RIC 304 and consumed by the rApps 306. The one or more R1 services may alsoinclude one or more sendees produced by the rApps 306 and consumed by the Non-RT RIC 304.

[0039] The services that facilitate interoperability between the rApps 206, 306 and the Non-RT RIC 204. 304, or the SMO 202, 302 are known as integration services. The integration services may include capabilities to authenticate and authorize service producers and service consumers.

[0040] As illustrated in FIG. 3, Data Management and Exposure (DME) functionalities enable the collection and production of data, as well as fetching data from a database. The DME functionalities are designed to handle various sources of heterogeneous data, which may be delivered either directly to data consumers or via a distribution system. The DME functionalities are implementation variability functionalities and may be flexibly deployed either within the Non-RT RIC 204, 304, or outside the Non-RT RIC 204, 304 but within the SMO 202, 302. Further, an Al interface support services of FIG. 3 may include services such as Al-P, Al -El, Al -ML, and the like.

[0041] Additionally, an Al termination 212, and 308 refers to a logical endpoint of the Al interface within the Near-RT RIC 208, and 310 respectively. An 01 termination 216, 316 is a logical endpoint of the 01 interface within an 0-RAN managed element (such as O-CU, O- DU, or O-RU). An 02 termination 214, 314 is a logical endpoint of the 02 interface within, for example, the O-Cloud 218, 318 respectively. The 01 and 02 terminations 216, 316, 214, 314 may be considered inherent SMO framework functionality. The inherent SMO framework functionality may also include other SMO framework functions 220. Further, FIGS. 2 and 3 illustrate various O-RAN defined interfaces such as the 01 interface, the 02 interface, the Al interface, and the R1 interface. FIG. 2 also illustrates an SMO internal interface that connects multiple functional components within the SMO framew ork 202.

[0042] FIG. 4 illustrates an O-RAN standard-compliant Near-RT RIC architecture 400, according to the state of art. The O-RAN standard-compliant Near-RT RIC architecture 400 includes an SMO 402, a Non-RT RIC 404, and a Near-RT RIC 405 that correspond to the SMO 102, the Non-RT RIC 104, and the Near-RT RIC 108, respectively of FIG. 1, and therefore, the description thereof has been omitted with reference to FIG. 4 for the sake of brevity. Similarly, an 01 termination 406, an Al termination 408. and E2 nodes 412 correspond to the 01 termination 216, the Al termination 212. and the E2 nodes 210, respectively, of FIG. 2, and therefore, the description thereof has been omitted with reference to FIG. 4 for the sake of brevity.

[0043] Further, the O-RAN standard-compliant Near-RT RIC architecture 400 includes one or more extensible Applications (xApps) 410-1, 410-2, ... , 410-n (collectively referred to as the “xApp 410” or “xApps 410”). A xApp 410 is an application designed to run on the Near-RT RIC 405 and typically includes one or more microservices. During an onboarding process, the xApp 410 identifies data intended to be consumed by the xApp 410 and data the xApp 410 is required to provide. The xApps 410 are independent of the Near-RT RIC 405 and may be developed by third parties. The E2 interface enables a direct association betw een the xApps 410 and one or more underlying RAN functionalities.

[0044] FIG. 4 further illustrates one or more services provided by the Near-RT RIC 405 and the xApps 410. The services may include, but are not limited to, conflict mitigation 418, subscription management 420, management services 422, security 424, AI / ML support 426, and an xApp repository' function 428. Additionally, the Non-RT RIC 405 may include a messaging infrastructure 414, an API enablement layer 416, a shared data layer 432, and a database 434. The messaging infrastructure 414 may facilitate internal and externalcommunication between multiple RIC components. The API enablement layer 416 may provide standardized and secure APIs to expose Non-RT RIC services and capabilities to the rApps, external systems, and other SMO components. The shared data layer 432 may act as a centralized data access and exchange layer. Further, the database 434 may store persistent data such as configuration, historical metrics, the AI / ML models, and policies for use by the Non- RT RIC 405 and its applications. The O-RAN standard-compliant Near-RT RIC architecture 400 may also include an E2 termination 430.

[0045] FIG. 5 illustrates a service-based SMO architecture 500 including one or more SMO services (SMOS), according to the state of art. The service-based SMO architecture 500 includes an SMO 502, a Non-RT RIC 504, one or more rApps 506, a Near-RT RIC 507, an O- RU 510, and an O-Cloud 512 that corresponds to the SMO 102, the Non-RT RIC 104, the Near- RT RIC 108, the O-RU 120, and the O-Cloud 122 of FIG. 1, and therefore, description thereof has been omitted with reference to FIG. 5 for the sake of brevity. Similarly, the service-based SMO architecture 500 includes the rApps 506 that correspond to the rApps 206 of FIG. 2, and therefore, the description thereof has been omitted with reference to FIG. 5 for the sake of brevity. The service-based SMO architecture 500 also includes one or more 01 nodes 508.

[0046] In a service provider’s network, there are multiple management domains, including RAN management, core management, transport management, and End-to-End slice management. In the O-RAN architecture, the SMO is responsible for the RAN management. The key capabilities of the SMO 502 that support the RAN management in the O-RAN may include:• FCAPS interface to O-RAN Network Functions (NFs);• The Non-RT RIC 504 for RAN optimization; and• O-Cloud Management, Orchestration, and Workflow Management.

[0047] The SMO 502 may perform the above-mentioned services through four key interfaces towards other O-RAN architecture elements.• The Al Interface between the Non-RT RIC 504 in the SMO 502 and the Near-RT RIC 507 for RAN Optimization;• The 01 Interface used by the SMO 502 for FCAPS support of the O-RAN NFs (excluding the O-RU 510);• In a hybrid model, the Open Fronthaul M-plane interface betw een the SMO 502 and the O-RU 510 for the FCAPS support; and• The 02 Interface between the SMO 502 and the O-Cloud 512 to provide platform resources and workload management.

[0048] Further, an SMO external interface is the interface between the SMO 502 and an SMO external system. The SMO external system is a data source outside O-RAN domain that provides data to the SMO 502.

[0049] Additionally, one or more SMO functions (SMOFs) include one or more internal SMO entities which provide the one or more SMO sendees (SMOSs). The one or more SMOSs represent a standardized, cohesive set of management, orchestration, and automation capabilities offered by an SMO Function. As shown in FIG. 5, the one or more SMOSs include, but are not limited to, a software package onboarding SMOS, a service orchestration SMOS, a service assurance SMOS, and a Topology Exposure and Inventory Management (TE&IV) SMOS. The one or more SMOSs also include an AI / ML workflow SMOS, a Data Management and Exposure (DME) SMOS, and a Service Management and Exposure (SME) SMOS. The one or more SMOSs further include a Network Functions Orchestration (NFO) SMOS, a FederatedO-Cloud Orchestration and Management (FOCOM) SMOS, and a RAN Analytics SMOS. Furthermore, the one or more SMOSs include one or more RAN NF Operations, Administration, and Maintenance (OAM) SMOSs such as RAN NF Performance Assurance Management (NF PM), RAN NF Fault Supervision Management (NF FM). and RAN NF Provisioning Management (NF CM).

[0050] The present disclosure provides various types of digital twin (DT) services to support various use cases prioritized in DT use case research conducted by an 0-RAN Alliance. The present disclosure also provides options for integrating or supporting the various types of DT services within the 0-RAN. The present disclosure enables different types of DT services to coexist within the 0-RAN, catering to different use cases. The present disclosure also allows the DT services to be discovered on-demand by the service consumers when a DT service is needed. The present disclosure allows the DT services to be flexibly implemented and located at different locations within the 0-RAN system. Specifically, the present disclosure discloses that the DT service is decoupled from the 0-RAN interface exposing service access, allowing the DT serv ice to be implemented anywhere within the 0-RAN system and accessed through any 0-RAN interface. According to the present disclosure, an exact location of the DT implementation may depend on various factors such as the type of the DT service, a supported use case, performance and cost requirements, multi-vendor interoperability requirements, and any other vendor-specific criteria. The present disclosure corresponds to a standard for Third Generation Partnership Project (3GPP) and 0-RAN.

[0051] Embodiments of the present disclosure are explained in detail in the forthcoming paragraphs.

[0052] FIG. 6 illustrates an example environment 600 for the implementation of a DT as a service in an O-RAN 602, in accordance with an embodiment of the present disclosure.

[0053] In an embodiment, a DT function may be provided as a service in the O-RAN decoupled from one or more O-RAN interfaces (such as. but not limited to, the 01 interface, the 02 interface, the E2 interface, and one or more predefined internal interfaces). For example, the DT sendee may be logically independent of an O-RAN interface layer. The DT service may be flexibly located anywhere in the O-RAN architecture and may be accessed via any interface depending on deployment. Examples of the one or more DT services may include, but are not limited to, a network planning DT senice. a Quality of Service (QoS) or a Quality’ of Experience (QoE) optimization DT sendee, a handover and traffic steering optimization DT service, a network energy’ saving optimization DT service, a cloud resource and power optimization DT service, an AI / ML model training DT service, an AI / ML performance assurance DT service, an AI / ML testing service, an intent fulfillment DT service, a network slicing provisioning DT service, a slice Service Level Agreement (SLA) assurance DT service, and a conflict mitigation sendee.

[0054] In an embodiment, one or more DT services may be provided by one or more DT sendee producers 604. The one or more DT service producers 604 may include, but are not limited to, the SMO, the Non-RT RIC framework, the Near-RT RIC framework, one or more O-RAN NFs, the one or more SMOFs, the one or more rApps, and the one or more xApps. In an embodiment, the one or more DT service producers 604 may be configured to generate the one or more DT services providing access to a digital replica of at least one of one or more O-RAN services, one or more O-RAN architecture elements, the one or more O-RAN NFs, one or more UEs, and one or more connectivity’ between one or more entities in an O-RAN. The digital replicamay be created using, for example, advanced simulation, emulation, or AI / ML techniques driven by data collected from the O-RAN 602. The digital replica may produce an accurate and synchronous simulation of a physical network. In an embodiment, the one or more DT service producers 604 may be configured to implement the generated one or more DT services within at least one of the NF, an external network entity, the xApp, the Near-RT RIC framework, the E2 node, the Non-RT RIC framework, an external SMO southbound entity, and an external SMO northbound entity.

[0055] In an embodiment, one or more DT service consumers 606 may consume or access the one or more DT services via one or more DT service APIs. A DT service API may refer to an API that exposes one or more DT functionalities as one or more services to one or more components (such as the rApps, the xApps, the SMO, and the Non-RT RIC) within the O-RAN 602. The one or more DT service consumers 606 may include, but are not limited to, the SMO, the Non-RT RIC framework, the Near-RT RIC framework, one or more O-RAN NFs, the one or more SMOFs, the one or more rApps, and the one or more xApps. In an embodiment, the one or more DT service producers 604 may be configured to enable the one or more DT service consumers 606 to access the generated one or more DT services via one or more DT sendee APIs. For example, the one or more DT service producers 604 may expose the one or more DT service APIs from the one or more O-RAN interfaces based on a location of an implementation of the one or more DT services within the O-RAN 602, as explained in detail in the forthcoming paragraphs. Examples of the one or more O-RAN interfaces may include, but are not limited to, a SMOS API interface, the R1 interface, one or more SMO external interfaces, the 01 interface, the 02 interface, the Al interface, the Open Fronthaul (FH) M-plane interface, the E2 interface, a Near-RT RIC API interface, an X2 interface, an Fl interface, an El interface,and one or more pre-defined internal interfaces. In an embodiment, the one or more DT service producers 604 may expose the one or more DT service APIs via one or more API commands. Examples of the one or more API commands may include, but are not limited to. Representational State Transfer API commands and Hypertext Transfer Protocol-based API commands.

[0056] In an embodiment, the one or more DT service producers 604 may be configured to register the one or more DT services with one or more SME service providers or systems 608. Further, the one or more DT service consumers 606 may discover and request access to the one or more DT services access from the one or more SME service providers 608. For example, the one or more DT service producers 604 may be configured to enable, via the one or more SME service providers 608, discovery’ of the generated one or more DT services. In response to enabling the discovery of the generated one or more DT services, the one or more DT service producers 604 may be configured to receive a request to access the generated one or more DT services via the one or more DT service APIs. The request to access the generated one or more DT sendees may be received from the one or more DT service consumers 606. Thereafter, the one or more DT service producers 604 may be configured to provide, to the one or more DT service consumers, the access to the one or more generated DT services. The access may be provided based on the received request to access.

[0057] FIG. 7 illustrates an example environment 700 depicting one or more implementation or deployment options for the generated one or more DT services within an SMO 702, a Non- RT RIC 704, and across one or more O-RAN interfaces, in accordance with an embodiment of the present disclosure. The one or more O-RAN interfaces may be associated with the one or more DT services. The example environment 700 may include one or more rApps 706, a Near-RT RIC 714, an O-RU 712, and an O-Cloud 710. The SMO 702, the Non-RT RIC 704, the Near-RT RIC 714, the O-RU 712, and the O-Cloud 710 may correspond to the SMO 102, the Non-RT RIC 104, the Near-RT RIC 108, the O-RU 120, and the O-Cloud 122, respectively, of FIG. 1, and therefore, description thereof has been omitted with reference to FIG. 7 for the sake of brevity. Similarly, the rApps 706 may correspond to the rApps 206 of FIG. 2, and therefore, the description thereof has been omitted with reference to FIG. 7 for the sake of brevity. The example environment 700 may include one or more RAN nodes 716 connected to the Near-RT RIC 714 via the E2 interface. Further, as shown in FIG. 7, the SMO 702 may include one or more SMOSs. The one or more SMOSs may include a NFO 720, a FOCOM 722, a RAN NF FM 724. a RAN NF CM 726. and a RAN NF PM 728. Furthermore, the rApp 706 and the Non-RT RIC 704 may interact with each other via one or more R1 services 718 (explained in conjunction with FIG. 3). The Non-RT RIC 704 may also include one or more rApp management services 730 and one or more Al-related services 732.

[0058] FIG. 7 illustrates five options for implementing the DT as a service in the SMO 702 and the Non-RT RIC 704. In Option 1, the DT may be implemented as an SMO service (SMOS) (i.e., a DT service 708-1) internal to the SMO 702. In an embodiment, the DT service 708-1 may be provided or exposed via the SMOS API interface. In Option 2, the DT may be implemented in the Non-RT RIC framework 704 as a DT service 708-2. In an embodiment, the DT sendee 708-2 may be exposed via one of the Non-RT RIC API interface, the R1 interface, or the SMOS API interface. In Option 3, the DT may be implemented in the rApp 706 as a DT service 708-3. In an embodiment, the DT-service 708-3 may be exposed via the R1 interface.In Option 4, the DT may be implemented externally to the SMO northbound entity as a DT service 708-4. In an embodiment, the DT sendee 708-4 may be exposed via the one or moreSMO external interfaces. The one or more SMO external interfaces may be non-standardized interfaces. In Option 5, the DT may be implemented externally to the SMO southbound entity as a DT service 708-5. In an embodiment the DT service 708-5 may be exposed via one of the 01 interface, the 02 interface, the Open FH M-plane interface or the Al interface.

[0059] In an embodiment, the above-mentioned five options (Option 1 to Option 5) may correspond to at least one of the one or more DT services described in conjunction with FIG.6. Further, the one or more DT services may be provided or exposed via one or more standardized APIs, as explained above. The implementation of the one or more DT services may be flexible in terms of the 0-RAN interfaces.

[0060] FIG. 8 illustrates an example environment 800 depicting one or more implementation or deployment options for the generated one or more DT services in the Near-RT RIC 802 and across the one or more O-RAN interfaces associated with the one or more DT services, in accordance with an embodiment of the present disclosure. The example environment 800 may include the Near-RT RIC 802 that corresponds to the Near-RT RIC 108 of FIG. 1, and therefore, the description thereof has been omitted with reference to FIG. 8 for the sake of brevity. Similarly, the example environment 800 may include the xApps 804-1, 804-2, ... , 804- N+l (collectively referred to as the “xApp 804” or “xApps 804”) and the E2 nodes 806 that correspond to the xApps 410 and the E2 nodes 412 of FIG. 4, and therefore, description thereof has been omitted with reference to FIG. 8 for the sake of brevity'. The example environment 800 may also include an E2 termination 810.

[0061] FIG. 8 illustrates three options for implementing the DT as a service in a Near-RT RIC 802 of the 0-RAN system. In Option 1, the DT may be implemented in an xApp (for example, xApp 804N+1) as a DT 808-1. In an embodiment, the DT 808-1 may be provided via the Near-RT RIC API interface. In Option 2, the DT may be implemented in aNear-RT RIC framework 803 as a DT 808-2. In an embodiment, the DT 808-2 may be provided by one of the Near-RT framework internal interface and the Near-RT RIC API interface. In Option 3, the DT may be implemented in one or more E2 nodes 806 external to the Near-RT RIC 802 as a DT 808-3. In an embodiment, the DT 808-3 may be provided by the E2 interface.

[0062] In an embodiment, the above-mentioned three options (Option 1 to Option 3) may correspond to at least one of the one or more DT services described in conjunction with FIG. 6. Further, the one or more DT services may be provided via the one or more standardized APIs, as explained above. The implementation of the one or more DT services is flexible in terms of the O-RAN interfaces.

[0063] FIG. 9 illustrates an example environment 900 depicting one or more implementation or deployment options for the one or more DT services within the O-RAN NFs and across the one or more O-RAN interfaces associated with the one or more DT services, in accordance with an embodiment of the present disclosure. The environment 900 may include an NF (i.e., an O- RAN NF) 902. Examples of the O-RAN NFs may include the O-CU-CP, the O-CU-UP, the O- RU, the O-DU, etc.

[0064] FIG. 9 illustrates two options for implementing the DT as a sendee within the O-RAN NFs. In Option 1, the DT may be implemented inside the NF 902 as a DT 904-1. In an embodiment, the DT 904-1 may be provided via the NF internal interface. In Option 2, the DT may be implemented externally to the NF 902 as a DT 904-2. In an embodiment, the DT 904- 2 may be provided via the NF external interfaces (such as the X2 interface, the Fl interface, and the El interface) or one or more non-standardized interfaces.

[0065] In an embodiment, the above-mentioned two options (Option 1 and Option 2) may correspond to at least one of the one or more DT services described in conjunction with FIG. 6. Further, the one or more DT services may be provided via the one or more standardized APIs. The implementation of the one or more DT services may be flexible in terms of the O-RAN interfaces.

[0066] The present disclosure enables the co-existence of various types of DT sendees within the O-RAN, supporting a wide range of use cases. The DT services may be flexibly implemented across different parts of the O-RAN architecture. The exact location of a DT implementation may be determined by the use case, as well as vendor-specific and operatorspecific requirements. The present disclosure provides implementation flexibility that significantly expands the applicability of DT technology in the O-RAN, allowing for the deployment of diverse DT service types tailored to specific needs. Further, the present disclosure addresses the challenges of integrating DT functions into the O-RAN architecture, for example, challenges arising from varying use case requirements, enabling technologies, and vendor or operator-specific implementation requirements while ensuring multi-vendor interoperability via the standardized service APIs.

[0067] FIG. 10 illustrates a flowchart depicting a method 1000 for implementing the DT as a service in the O-RAN 602, in accordance with an embodiment of the present disclosure. The method may be performed by the one or more DT service producers 604. In an embodiment, the one or more DT service producers 604 may include, but are not limited to, the SMO, the Non-RT RIC framework, the Near-RT RIC framework, the one or more O-RAN NFs, the one or more SMOFs, the one or more rApps, and the one or more xApps.

[0068] At step 1002, the method 1000 may include generating the one or more DT services providing access to the digital replica of at least one of the one or more O-RAN services, the one or more O-RAN architecture elements, the one or more O-RAN NFs, the one or more UEs, and the one or more connectivity between the one or more entities in the O-RAN 602. In an embodiment, the one or more DT services may include at least one of the network Planning DT service, the QoS or QoE optimization DT service, the handover and traffic steering optimization DT service, the network energy saving optimization DT service, the cloud resource and power optimization DT service, the AI / ML model training DT service, the AI / ML performance assurance DT service, the AI / ML testing service, the intent fulfillment DT service, the network slicing provisioning DT service, the slice SLA assurance DT service, and the conflict mitigation service.

[0069] At step 1004, the method 1000 may include enabling the one or more DT service consumers 606 to access the generated one or more DT services via the one or more DT service producers 604 through the one or more DT service APIs. The one or more DT service consumers 606 may include, but are not limited to, the SMO, the Non-RT RIC framework, the Near-RT RIC framework, one or more O-RAN NFs, the one or more SMOFs, the one or more rApps, and the one or more xApps. In an embodiment, for enabling the one or more DT sen-ice consumers 606 to access the one or more DT services, the method 1000 may include exposing the one or more DT service APIs from the one or more O-RAN interfaces. The one or more DT service APIs may be exposed based on the location of the implementation of the one or more DT services within the O-RAN 602. The one or more O-RAN interfaces may include the SMOS API interface, the R1 interface, the one or more SMO external interfaces, the 01 interface, the 02 interface, the Al interface, the Open FH M-plane interface, the E2 interface, the Near-RTRIC API interface, the X2 interface, the Fl interface, the El interface, and the one or more predefined internal interfaces.

[0070] In an embodiment, the method 1000 may include implementing the generated one or more DT sendees within at least one of the NF, the external network entity, the xApp. the Near- RT RIC framework, the E2 node, the Non-RT RIC framework, the external SMO southbound entity, and the external SMO northbound entity.

[0071] FIG. 11 illustrates a flowchart depicting a method 1100 for providing access to the one or more DT service consumers 606 to the generated one or more DT services, in accordance with an embodiment of the present disclosure. The method may be performed by the one or more DT service producers 604. The method 1100 may be a part of the method 1000.

[0072] At step 1102, the method 1100 may include registering the generated one or more DT services with the one or more SME service providers 608.

[0073] At step 1104, the method 1100 may include enabling, via the one or more SME service providers 608, discovery of the generated one or more DT services.

[0074] At step 1106, in response to enabling the discovery of the generated one or more DT services, the method 1100 may include receiving, from the one or more DT service consumers 606, the request to access the generated one or more DT services via the one or more DT service APIs.

[0075] At step 1108, the method 1100 may include providing, to the one or more DT sendee consumers 606, the access to the generated one or more DT services based on the received request to access.

[0076] FIG. 12 illustrates an embodiment of a device 1200, in accordance with an embodiment of the present disclosure. As shown in FIG. 12, the device 1200 includes a processor 1210, amemory 1220, a storage component 1230, an input component 1240, an output component1250, a communication interface 1260, and a bus 1270. The device 1200 may correspond to the one or more DT service producers 604. The device 1200 may also correspond to the one or more DT service consumers 606 or the one or more SME sendee providers 608. The one or more components of the device 1200 may be configured to implement one or more operations / functionalities of the present disclosure as discussed above.

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

[0078] The memory 1220 includes a non-transitory computer readable medium. The memory 1220 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 memoiy ) that stores information and / or instructions for use by the processor 1210. The memory' 1220 comprises machine-readable instructions which are executable by the processor 1210. These machine-readable instructions when executed by the processor 1210 cause the processor 1210 to perform one or more method steps of an embodiment described above.

[0079] The storage component 1230 stores information and / or software related to the operation and use of the device 1200. For example, the storage component 1230 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compactdisc (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.

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

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

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

[0083] The bus 1270 acts as an interconnect betw een the processor 1210, the memory 1220, the storage component 1230, the input component 1240, the output component 1250, and the communication interface 1260 of the device 1200. The bus 1270 may include a wired interconnection or a wireless interconnection.

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

[0085] Examples of the techniques and apparatus described herein include, but are not limited to, the following enumerated embodiments:[1] An apparatus configured to: generate one or more Digital Twin (DT) services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O- RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN; and enable one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).[2] The apparatus as described in [1], wherein to enable the one or more DT service consumers to access the one or more DT services, the apparatus is configured to: expose the one or more DT service APIs from one or more O-RAN interfaces based on a location of an implementation of the one or more DT services within the O-RAN, wherein the one or more O-RAN interfaces comprise at least one of a Service Management and Orchestration Service (SMOS) API interface, an R1 interface, one or more SMO external interfaces, an 01 interface, an 02 interface, an Al interface, an Open Fronthaul (FH)Management-Plane (M-plane) interface, an E2 interface, a Near-Real-Time RAN Intelligent Controller (Near-RT RIC) API interface, an X2 interface, an Fl interface, an El interface, and one or more pre-defined internal interfaces.[3] The apparatus as described in any one of [1] to [2], further configured to: register the generated one or more DT services with one or more Service Management and Exposure (SME) service providers; enable, via the one or more SME service providers, discovery of the one or more generated DT services; in response to enabling the discovery of the one or more generated DT sendees, receive, from the one or more DT service consumers, a request to access the one or more generated DT services via the one or more DT service APIs; and provide, to the one or more DT service consumers, the access to the one or more generated DT services based on the received request to access.[4] The apparatus as described in any one of [1] to [3], further configured to: implement the one or more generated DT services within at least one of a network function, an external network entity, an extensible Application (xApp), a Near-RT RIC framework, an E2 node, a Non-Real time (Non-RT) RIC framework, an external SMO southbound entity', and an external SMO northbound entity.[5] The apparatus as described in any one of [1] to [4], wherein the one or more DT services comprises at least one of: a network Planning DT sen ice; a Quality of service (QoS) or a quality7of experience (QoE) optimisation DT service; a handover and traffic steering optimisation DT service;a network energy saving optimisation DT service; a cloud resource and power optimisation DT service; an artificial intelligence / machine learning (AI / ML) model training DT service; an AI / ML performance assurance DT service; an AI / ML testing service; an intent fulfilment DT service; a network slicing provisioning DT service: a slice Service Level Agreement (SLA) assurance DT service: and a conflict mitigation service.[6] The apparatus as described in any one of [1] to [5], wherein the one or more DT service consumers include a SMO. the Non-RT RIC framework, the Near-RT RIC framework, the one or more O-RAN NFs, one or more SMO functions, one or more RAN Applications (rApps), and one or more xApps.[7] The apparatus as described in any one of [1] to [6], wherein the apparatus corresponds to a DT service producer, and wherein the DT service producer corresponds to at least one of: the SMO; the one or more O-RAN NFs; the one or more SMO functions; the Non-RT RIC framework; the Near-RT RIC framework; the one or more rApps; and the one or more xApps.[8] A method comprising:generating, by a Digital Twin (DT) service producer, one or more DT services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN; and enabling, by the DT service producer, one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).[9] The method as described in [8], wherein enabling the one or more DT service consumers to access the one or more DT services comprises: exposing, by the DT service producer, the one or more DT service APIs from one or more O-RAN interfaces based on a location of an implementation of the one or more DT services within the O-RAN, wherein the one or more O-RAN interfaces comprise at least one of a Service Management and Orchestration Service (SMOS) API interface, an R1 interface, one or more SMO external interfaces, an 01 interface, an 02 interface, an Al interface, an Open Fronthaul (FH) Management-Plane (M-plane) interface, an E2 interface, a Near-Real- Time RAN Intelligent Controller (Near-RT RIC) API interface, an X2 interface, an Fl interface, an El interface, and one or more pre-defined internal interfaces.

[0010] The method as described in any one of [8] to [9], further comprising: registering, by the DT service producer, the generated one or more DT services with one or more Service Management and Exposure (SME) service providers; enabling, by the DT sendee producer via the one or more SME service providers, discovery' of the one or more generated DT services;in response to enabling the discovery of the one or more generated DT services, receiving, by the DT service producer from the one or more DT service consumers, a request to access the one or more generated DT services via the one or more DT service APIs; and providing, by the DT service producer to the one or more DT service consumers, the access to the one or more generated DT services based on the received request to access.

[0011] The method as described in any one of [8] to

[0010] , further comprising: implementing, by the DT service producer, the one or more generated DT services within at least one of a network function, an external network entity, an extensible Application (xApp), a Near-RT RIC framework, an E2 node, a Non-Real time (Non-RT) RIC framework, an external SMO southbound entity, and an external SMO northbound entity.

[0012] The method as described in any one of [8] to

[0011] . wherein the one or more DT services comprises at least one of: a network Planning DT service; a Quality of service (QoS) or a quality of experience (QoE) optimisation DT service; a handover and traffic steering optimisation DT service; a netw ork energy saving optimisation DT service; a cloud resource and power optimisation DT service; an artificial intelligence / machine learning (AI / ML) model training DT service; an AI / ML perfonnance assurance DT service; an AI / ML testing service; an intent fulfilment DT service; a netw ork slicing provisioning DT service; a slice Service Level Agreement (SLA) assurance DT service; anda conflict mitigation service.

[0013] The method as described in any one of [8] to

[0012] , wherein the one or more DT service consumers include a SMO, the Non-RT R1C framework, the Near-RT R1C framework, the one or more O-RAN NFs, one or more SMO functions, one or more RAN Applications (rApps). and one or more xApps.

[0014] The method as described in any one of [8] to

[0013] , wherein the DT service producer corresponds to at least one of: the SMO; the one or more O-RAN NFs; the one or more SMO functions; the Non-RT RIC framework; the Near-RT RIC framework; the one or more rApps; and the one or more xApps.

[0015] A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors at a Digital Twin (DT) service producer, cause the one or more processors to: generate one or more DT services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN; andenable one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

[0086] 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. The DT service producer may include respective processors, communication units, and storage units (e.g., memory). The communication units may perform functions for transmitting and receiving signals. The storage units may include executable instructions that, when executed by the corresponding processors, cause the corresponding DT service producer to perform the functions as described above with reference to FIGS. 10-11.

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

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

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

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

[0091] 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

We Claim:

1. An apparatus configured to: generate one or more Digital Twin (DT) services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O- RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN; and enable one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

2. The apparatus as claimed in claim 1, wherein to enable the one or more DT service consumers to access the one or more DT services, the apparatus is configured to: expose the one or more DT service APIs from one or more O-RAN interfaces based on a location of an implementation of the one or more DT services within the O-RAN, wherein the one or more O-RAN interfaces comprise at least one of a Service Management and Orchestration Service (SMOS) API interface, an R1 interface, one or more SMO external interfaces, an 01 interface, an 02 interface, an Al interface, an Open Fronthaul (FH) Management-Plane (M-plane) interface, an E2 interface, a Near-Real-Time RAN Intelligent Controller (Near-RT RIC) API interface, an X2 interface, an Fl interface, an El interface, and one or more pre-defined internal interfaces.

3. The apparatus as claimed in claim 1, further configured to:register the generated one or more DT services with one or more Service Management and Exposure (SME) service providers; enable, via the one or more SME service providers, discovery of the one or more generated DT services; in response to enabling the discovery of the one or more generated DT sen-ices, receive, from the one or more DT service consumers, a request to access the one or more generated DT services via the one or more DT service APIs; and provide, to the one or more DT service consumers, the access to the one or more generated DT services based on the received request to access.

4. The apparatus as claimed in claim 1, further configured to: implement the one or more generated DT services within at least one of a network function, an external network entity, an extensible Application (xApp), a Near-RT RIC framework, an E2 node, a Non-Real time (Non-RT) RIC framework, an external SMO southbound entity, and an external SMO northbound entity.

5. The apparatus as claimed in claim 1, wherein the one or more DT services comprises at least one of: a network Planning DT sendee; a Quality of service (QoS) or a quality of experience (QoE) optimisation DT service; a handover and traffic steering optimisation DT service; a network energy' saving optimisation DT service; a cloud resource and power optimisation DT sendee;an artificial intelligence / machine learning (AI / ML) model training DT service; an AI / ML performance assurance DT service; an AI / ML testing service; an intent fulfilment DT service; a network slicing provisioning DT service: a slice Service Level Agreement (SLA) assurance DT service: and a conflict mitigation service.

6. The apparatus as claimed in claim 1, wherein the one or more DT service consumers include a SMO, the Non-RT RIC framework, the Near-RT RIC framework, the one or more O- RAN NFs, one or more SMO functions, one or more RAN Applications (rApps), and one or more xApps.

7. The apparatus as claimed in claim 1, wherein the apparatus corresponds to a DT service producer, and wherein the DT service producer corresponds to at least one of: the SMO; the one or more O-RAN NFs; the one or more SMO functions; the Non-RT RIC framework; the Near-RT RIC framework; the one or more rApps; and the one or more xApps.

8. A method comprising: generating, by a Digital Twin (DT) service producer, one or more DT services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs), and one or more connectivity between one or more entities in an O-RAN; and enabling, by the DT service producer, one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

9. The method as claimed in claim 8, wherein enabling the one or more DT service consumers to access the one or more DT services comprises: exposing, by the DT service producer, the one or more DT service APIs from one or more O-RAN interfaces based on a location of an implementation of the one or more DT services within the O-RAN, wherein the one or more O-RAN interfaces comprise at least one of a Service Management and Orchestration Service (SMOS) API interface, an R1 interface, one or more SMO external interfaces, an 01 interface, an 02 interface, an Al interface, an Open Fronthaul (FH) Management-Plane (M-plane) interface, an E2 interface, a Near-Real- Time RAN Intelligent Controller (Near-RT RIC) API interface, an X2 interface, an Fl interface, an El interface, and one or more pre-defined internal interfaces.

10. The method as claimed in claim 8, further comprising:registering, by the DT service producer, the generated one or more DT senices with one or more Service Management and Exposure (SME) service providers; enabling, by the DT service producer via the one or more SME service providers, discovery of the one or more generated DT services; in response to enabling the discovery of the one or more generated DT services, receiving, by the DT service producer from the one or more DT service consumers, a request to access the one or more generated DT services via the one or more DT service APIs; and providing, by the DT service producer to the one or more DT service consumers, the access to the one or more generated DT services based on the received request to access.

11. The method as claimed in claim 8, further comprising: implementing, by the DT service producer, the one or more generated DT services within at least one of a network function, an external network entity, an extensible Application (xApp), a Near-RT RIC framework, an E2 node, a Non-Real time (Non-RT) RIC framework, an external SMO southbound entity, and an external SMO northbound entity.

12. The method as claimed in claim 8, wherein the one or more DT services comprises at least one of: a network Planning DT sendee; a Quality of service (QoS) or a quality of experience (QoE) optimisation DT service; a handover and traffic steering optimisation DT service; a network energy' saving optimisation DT service; a cloud resource and power optimisation DT sendee;an artificial intelligence / machine learning (AI / ML) model training DT service; an AI / ML performance assurance DT service; an AI / ML testing service; an intent fulfilment DT service; a network slicing provisioning DT service: a slice Service Level Agreement (SLA) assurance DT service: and a conflict mitigation service.

13. The method as claimed in claim 8, wherein the one or more DT service consumers include a SMO, the Non-RT RIC framework, the Near-RT RIC framework, the one or more O- RAN NFs, one or more SMO functions, one or more RAN Applications (rApps), and one or more xApps.

14. The method as claimed in claim 8. wherein the DT service producer corresponds to at least one of: the SMO; the one or more O-RAN NFs; the one or more SMO functions; the Non-RT RIC framework; the Near-RT RIC framework; the one or more rApps; and the one or more xApps.

15. A non-transitory computer-readable medium storing instructions, the instructions compnsing: one or more instructions that, when executed by one or more processors at a Digital Twin (DT) service producer, cause the one or more processors to: generate one or more DT services providing access to a digital replica of at least one of one or more Open-Radio Access Network (O-RAN) services, one or more O-RAN architecture elements, one or more O-RAN network functions (NFs), one or more User Equipment (UEs). and one or more connectivity’ between one or more entities in an O-RAN: and enable one or more DT service consumers to access the generated one or more DT services via one or more DT service producers through one or more DT service Application Programming Interfaces (APIs).

Images