Decoupled service management and orchestration service architecture in an open radio access network

Abstract

Embodiments of the disclosure describe a method for decoupling Service Management and Orchestration (SMO) in an Open Radio Access Network (O-RAN). The method includes configuring one or more interfaces and services for a plurality of modules associated with the SMO and an Open Radio Access Network Cloud (O-Cloud). The plurality of modules comprises an operator User Interface (UI) module, one or more SMO Services (SMOS) modules, a Service Orchestration (SO) SMOS module, a higher layer SMOS module, an Application Software Package Onboarding SMOS module, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module, and a Network Function Orchestrator (NFO) SMOS module. The method further includes establishing, based on the one or more configured interfaces and services, an End-to-End (E2E) service flow between the plurality of modules and the O-Cloud in an Open Radio Access Network (O-RAN) architecture.

Description

DECOUPLED SERVICE MANAGEMENT AND ORCHESTRATION SERVICE ARCHITECTURE IN AN OPEN RADIO ACCESS NETWORKCROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority to India Provisional Patent Application No. 202511004774, filed on January 21, 2025, and to India Non-Provisional Patent Application No. 202511004774, filed on July 30, 2025 the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to a decoupled Service Management and Orchestration (SMO) service architecture in an Open Radio Access Network (O-RAN).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] Radio Access Networks (RAN) serve as a crucial component in mobile telecommunications infrastructure, establishing connectivity between user devices and core networks through radio connections. Traditional RAN architectures operate on proprietary solutions, where network components from multiple vendors experience interoperability limitations.

[0005] As the demand for higher data rates and more efficient network management continues to increase, an Open RAN (O-RAN) has been introduced, emphasizing openness, interoperability,and intelligence. An O-RAN architecture enables mobile network operators to deploy multivendor network components, thereby promoting interoperability, innovation, and minimizing single-vendor dependencies.

[0006] Moreover, a Service Management and Orchestration (SMO) framework is a pivotal component of the O-RAN architecture, designed to enhance the efficiency and automation of network operations. The SMO facilitates the management of RAN functions and resources, ensuring seamless orchestration of various network elements, regardless of the vendor.SUMMARY

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

[0008] According to one embodiment of the present disclosure, a method is disclosed. The method includes configuring one or more interfaces and services for a plurality of modules associated with a Service Management and Orchestration (SMO) and an Open Radio Access Network Cloud (O-Cloud). The plurality of modules comprises an operator User Interface (UI) module, one or more SMO Services (SMOS) modules, a Service Orchestration (SO) SMOS module, a higher layer SMOS module, an Application Software Package Onboarding SMOS module, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module, and a Network Function Orchestrator (NFO) SMOS module. The method further includes establishing, based on the one or more configured interfaces and services, an End-to-End (E2E) service flow between the plurality of modules and the O-Cloud in an Open Radio Access Network (O-RAN) architecture.

[0009] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, at a Federated O-Cloud Orchestration and Management (FOCOM) Service Management and Orchestration service (SMOS) module, a provisioning request to create, modify, or terminate a cluster. The provisioning request is received from at least one of an operator User Interface (UI) module, one or more other SMOS modules, and a Service Orchestration (SO) SMOS module. The cluster characteristics are defined by one of a standardized template, an abstracted cluster template, or a vendor-specific cluster template. The method further includes implementing either the standardized, the abstracted cluster template, or the vendor-specific cluster template at a Northbound Interface (NBI) of the FOCOM SMOS module. The method further includes transmitting an 02 interface Infrastructure Management Services (02-IMS) cluster provisioning request, by utilizing one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template, via the 02 interface to the O-Cloud.

[0010] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, at an application software package onboarding Service Management and Orchestration service (SMOS) module, a request for onboarding one or more applications. The request is received from at least one of, an operator User Interface (UI) module, one or more other SMOS modules. The request comprises at least one of, one or more Application Specific Descriptors (ASDs), software images, helm charts, and Cloud Resource Descriptor (CRDs). The method further includes executing, in response to the receiving request, one or more application onboarding operations from the application software package onboarding SMOS module to the SO SMOS or NFO SMOS module. The one or more application onboarding operations comprise transferring the one or more ASDs, software images, helm charts, and CRDs received in the requestfrom the application software package onboarding SMOS module to the SO SMOS or NFO SMOS module.

[0011] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, at a Service Orchestration (SO) SMOS module, a request. The request is received for creating, modifying, or terminating at least one of, one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), one or more Network Services (NSs) through a Northbound Interface (NBI) based on at least one of a first pre-defined standard and a second pre-defined standard. The method further includes retrieving, at the SO SMOS module, one or more application package artifacts. The one or more application package artifacts are retrieved from a blueprint or catalogue database associated with an application software package onboarding SMOS module, based on the reference mentioned in the received request. The method further includes requesting, by the SO SMOS module, a Network Function Orchestrator (NFO) SMOS module, for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts.

[0012] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, at a Network Function Orchestrator (NFO) SMOS module, a request. The request is received for creating, modifying, or terminating one or more Network Function (NF) Deployments, from a Service Orchestration (SO) SMOS module. The method further includes handling, by the NFO SMOS module, one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs) in response to receiving the request. The NFO SMOS module handles the one or more 02-DMS APIs to instantiate or update, or deleteone or more applications to fulfil an NF Deployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

[0013] According to one embodiment of the present disclosure, a system is disclosed. The system includes a Service Orchestration (SO) SMOS module and a Network Function Orchestrator (NFO) SMOS module. The SO SMOS module is configured to receive a request for creating, modifying, or terminating at least one of one or more Radio Access Network (RAN) services, one or more Network Services (NSs), and one or more Network Functions (NFs) through a Northbound Interface (NBI) based on at least one a first pre-defined standard and a second pre-defined standard. The SO SMOS module is further configured to retrieve one or more application package artifacts, from a blueprint or catalogue database associated with an application software package Onboarding SMOS module, based on the reference mentioned in the received request. The SO SMOS module is further configured to request the NFO SMOS module for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts. The NFO SMOS module is configured to handle one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interfaces (APIs) in response to receiving the request. The NFO SMOS module handles the one or more 02-DMS APIs to instantiate or update, or delete one or more applications to fulfil an NF Deployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

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

[0015] 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 a schematic diagram for a decoupled Service Management and Orchestration (SMO) architecture and SMO services, according to the prior art;FIG. 2 illustrates an end-to-end service flow diagram depicting various interfaces between the SMO and an Open Radio Access Network Cloud (O-Cloud) in an Open Radio Access Network (0-RAN) architecture, according to an embodiment as disclosed herein;FIG. 3 illustrates a Network Function Orchestration (NFO) SMOS module northbound interface for Network Function (NF) deployment Life Cycle Management (LCM), according to an embodiment as disclosed herein;FIG. 4 illustrates a mapping between the O-RAN architecture and a Third Generation Partnership Project (3 GPP) architecture, according to an embodiment as disclosed herein;FIG. 5 illustrates a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module northbound interface diagram for cluster provisioning, according to an embodiment as disclosed herein;FIG. 6 illustrates a SMO service and one or more API requirements for an application software package onboarding SMOS module in the SMO framework, according to an embodiment as disclosed herein;FIG. 7 illustrates a SMO service and one or more API requirements for a Service Orchestration (SO) SMOS module in the SMO framework, according to an embodiment as disclosed herein;FIG. 8 illustrates a SMO service and one or more API requirements for a Network Function Orchestrator (NFO) SMOS module in the SMO framework, according to an embodiment as disclosed herein;FIG. 9 is a flow diagram illustrating a method for establishing an End-to-End (E2E) service flow in the O-RAN architecture, according to an embodiment as disclosed herein; and FIG. 10 illustrates a diagram of example components of an apparatus, according to an embodiment as disclosed herein.DETAILED DESCRIPTION

[0016] 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 toat 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).

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

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

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

[0020] The foregoing disclosure provides an 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.

[0021] In the present disclosure, specific tasks may be performed using Artificial Intelligence / Machine Learning (AT / 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.

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

[0023] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised 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.

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

[0025] In the context of an Open Radio Access Network (O-RAN) architecture, a decoupled Service Management and Orchestration (SMO) architecture refers to a system where one or more SMO functions are separated into modular components, allowing for greater flexibility, interoperability, and easier integration with diverse vendor solutions, as illustrated in FIG. 1. For instance, existing standardization initiative, O-RAN-WGl.Decoupled-SMO-Architecture-R004-v3.00 specification defines various SMO services.

[0026] FIG. 1 illustrates a schematic diagram 1000 for the decoupled SMO architecture and SMO services, according to the prior art. At a high level, the schematic diagram consists of an SMO 100, an O-Cloud 200, an O-RU 300, and a Near-RT-RIC along with Ol-Nodes 400.

[0027] In a service provider’s network, there can be many management domains, such as Radio Access Node (RAN) management, core management, transport management, End-to-End slice management, and the like. In the O-RAN architecture, the SMO 100 is responsible for RAN domain management. The key capabilities of the SMO 100 that provide RAN support in the O-RAN, for example:a. Fault, Configuration, Accounting, Performance, Security (FCAPS) interface to O- RAN network functions.b. Non-Real-Time RAN Intelligent Controller (Non-RT RIC) for RAN optimization. c. O-Cloud management, orchestration, and workflow management.

[0028] In addition, the SMO 100 is responsible for managing and orchestrating various network functions and services, which include a plurality of sub-modules.

[0029] Examples of the plurality of sub-modules associated with the SMO 100 may include a software package onboarding, a Service Orchestration (SO), a service assurance, a Topology & Inventory (TE&IV), a AI / ML workflow, a data management and exposure, a Service Management and Exposure (SME), a rApp, a Network Function Orchestrator (NFO), a federated O-Cloud orchestration and management, a RAN NF Fault Management (FM), a RAN NF Configuration Management (CM), a RAN NF Performance Management (PM), a RAN analytics, and a Non-RT RIC (rApp management and Al -related services). Functionality of each of the plurality of submodules is described below.

[0030] The software package onboarding of SMO 100 is configured to handle one or more onboarding and deployment of software packages within the O-RAN. The SO of SMO 100 is configured to orchestrate the various services and their interactions within the O-RAN. The serviceassurance of SMO 100 is configured to ensure the quality and reliability of one or more services provided by the 0-RAN. The TE&IV of SMO 100 is configured to manage a network topology and inventory information. The Al / ML workflow of SMO 100 is configured to handle the automation and optimization of network workflows using artificial intelligence and machine learning techniques.

[0031] The data management and exposure of SMO 100 is configured to manage the data generated by the O-RAN and expose it to other systems. The SME of SMO 100 is configured to manage an overall service lifecycle and exposes one or more network services to external systems. The rApp of SMO 100 represents one or more applications that run on top of the O-RAN architecture. These applications leverage one or more capabilities and services provided by the O-RAN network to deliver advanced functionality and optimization. The rApps can utilize the AI-related services and a Near-RT RIC to implement intelligent decision-making and control mechanisms for the O-RAN.

[0032] The NFO of SMO 100 is configured to orchestrate one or more network functions within the O-RAN architecture. The federated O-Cloud orchestration and management of SMO 100 is configured to handle the orchestration and management of the federated cloud infrastructure supporting the O-RAN network. The RAN NF FM of SMO 100 is configured to detect, diagnose, and resolve network faults or failures, monitor network elements, identify issues, and trigger appropriate actions to restore normal operation. The RAN NF CM of SMO 100 is configured to manage a configuration of RAN network elements. This includes tasks like provisioning, updating, and maintaining the settings of various network components to ensure they are operating correctly and according to defined policies. The RAN NF PM of SMO 100 is configured to monitor andoptimize the performance of the O-RAN. This involves collecting performance data, analyzing it to identify bottlenecks or areas for improvement, and taking actions to enhance network efficiency and user experience. The RAN analytics of SMO 100 is configured to provide advanced analytics and insights for the O-RAN network.

[0033] The Non-RT RIC of SMO 100 in the O-RAN is a crucial component for long-term network optimization and policy management. The Non-RT RIC is configured to operate within the SMO 100 and handle tasks that don’t require immediate, real-time responses. The Non-RT RIC leverages specialized applications called rApps and the Al interface to communicate with the Near-RT-RIC along with Ol-Nodes 400 and other RAN elements, ultimately guiding network performance and resource allocation. Herein, the Ol-Nodes represent the management and control nodes within the O-RAN architecture. The Ol-Nodes are configured to provide overall management and control of the O-RAN, including functions like configuration, fault management, and performance monitoring.

[0034] The SMO 100 performs one or more services through a plurality of key interfaces, for example:a. Al Interface between the Non-RT RIC in the SMO 100 and the Near-RT RIC for the RAN optimization.b. 01 Interface used by the SMO 100 for the FCAPS support of the O-RAN network functions (excluding Open Radio Access Network Radio Unit (O-RU 300)). c. In a hybrid model, an Open Fronthaul M-plane (FH-M) interface is used between the SMO 100 and the O-RU 300 for FCAPS support.d. 02 interface between the SMO 100 and the O-Cloud 200 to provide platform resources and workload management.e. SMOS communication: This interface enables communication between the O-RU 300 and the SMO 100, allowing for the exchange of control and management information.f. 3GPP MDA Mngt (3GPP TS 28.104) interface: This interface follows the 3GPP standards for managing the multi-domain aspects of the O-RU 300. g. R1 interface: This interface plays a crucial role here as it serves as a communication pathway between the rApps and the underlying Non-RT RIC framework. This interface enables rApps to access necessary data, interact with other components, and ultimately contribute to the overall service management and orchestration of the network.

[0035] Further, an SMO external interface is the interface between the SMO 100 and an SMO external system. The SMO external system is a data source outside the O-RAN domain that provides data to the SMO 100. The SMO functions (SMOFs) include internal SMO entities that provide one or more SMO services. The SMO services (SMOSs) are the standardized cohesive set of management, orchestration, and automation capabilities offered by an SMO Function.

[0036] As illustrated in FIG. 1, the SMO functions (e.g., SO, NFO, etc.) are organized into modular components, which enhances flexibility, interoperability, and integration with various vendor solutions. This separation allows for a multi-vendor environment, enabling different SMO functions to be sourced from various providers, thus improving network management andautomation. However, there are several challenges / issues encountered in the existing methods / sy stems, which are mentioned below.

[0037] One major issue is the technical difficulties in ensuring service interoperability among decoupled SMO services. This architecture necessitates the standardization of North Bound Interface (NBI) Application Programming Interfaces (APIs) to facilitate consistent communication between services from different vendors.

[0038] Currently, existing O-RAN specifications do not provide clear definitions of the functional responsibilities for each SMO service / function, nor do they outline comprehensive interface requirements for service interactions. This lack of detailed specifications leads to challenges in implementing network function deployment, cloud resource management, and service orchestration.

[0039] Additionally, the existing O-RAN specifications fail to address the workflow requirements needed for coordination among multiple SMO services. To effectively manage end-to-end service operations, there is an essential requirement to define interaction patterns and data exchange requirements among the various SMO services.

[0040] To address the above-mentioned challenges / issues, a disclosed method / system provides a unique strategy to a decoupled SMO service architecture in the O-RAN, as described in conjunction with FIG. 2 to FIG. 10.

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

[0042] FIG. 2 illustrates an end-to-end service flow diagram depicting various interfaces between the SMO 201 and an Open Radio Access Network Cloud (O-Cloud) 203 in an Open Radio Access Network (O-RAN) architecture 2000, according to an embodiment as disclosed herein.

[0043] In some example embodiments, the SMO 201 may configure one or more interfaces and services for a plurality of modules associated with the SMO 201 and the O-Cloud 203. The plurality of modules comprises an operator User Interface (UI) module 205, one or more SMO Services (SMOS) modules 207 (i.e., other SMOs module), a Service Orchestration (SO) SMOS module 209, a higher layer SMOS module 211, an application software package onboarding SMOS module 213, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module 215, and a Network Function Orchestrator (NFO) SMOS module 217. The SMO 201 may establish, based on the one or more configured interfaces and services, an End-to-End (E2E) service flow between the plurality of modules and the O-Cloud 203 in the O-RAN architecture 2000, as described in conjunction with FIG. 3, FIG. 5, FIG. 6, FIG. 7, and FIG. 8.

[0044] In some example embodiments, the disclosed method / system associated with the O-RAN architecture 2000 facilitates coordination among key decoupled SMO services (e.g., SO, NFO, TE&IV, etc.) in a layered manner, enabling effective end-to-end cloud and network function orchestration and management, from cluster provisioning to the deployment of network function applications. Each SMO layer, or SMO service (SMOS), has specific responsibilities and interacts with others through defined service APIs. The roles of each SMOS are clearly outlined, along with the requirements and functionalities of the northbound. APIs, as described in conjunction with FIG. 3, FIG. 5, FIG. 6, FIG. 7, and FIG. 8

[0045] The disclosed method / system associated with the 0-RAN architecture 2000 provides several advantages, for example, the disclosed method / system allows for the disaggregation of SMO functions into independent services that meet operators’ urgent needs. Different SMOS (e.g., 205, 207, 209, 211, 213, 215, 217, etc.) can be sourced from various vendors, with interoperability assured through standardized APIs. This significantly enhances 0-RAN adoption in existing environments and reduces costs and time for future maintenance and upgrades of SMO services. Additionally, the disclosed method / system facilitates seamless integration with 0-RAN rApps, giving operators access to more customized and adaptive solutions. The disclosed method / system also leverages Al and machine learning technologies to optimize network and cloud performance and efficiency.

[0046] FIG. 3 illustrates the NFO SMOS module 217 northbound interface for Network Function (NF) deployment Life Cycle Management (LCM), according to an embodiment as disclosed herein. The NFO SMOS module 217 may execute multiple operations 3000 in the O-RAN architecture 2000, which are given below.

[0047] In some example embodiments, the NFO SMOS module 217 may receive a request for creating, modifying, or terminating one or more NF deployments, from the SO SMOS module 209. The request may include, for example, but not limited to, at least one of one or more helm charts, Custom Resource Definitions (CRDs), Application Package Descriptors (ASDs), and a Virtual Network Function Descriptor (VNFD).

[0048] In some example embodiments, in response to receiving the request, the NFO SMOS module 217 may handle one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs) to instantiate or update, or delete one or moreapplications to fulfil an NF Deployment lifecycle management request from a NBI of the SO SMOS module 209. Examples of the 02-DMS interface APIs may include, but are not limited to, at least one of a Kubemetes (K8S) native Application Programming Interface (API), or a European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) Management and Orchestration (MANO) API.

[0049] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may adapt the NBI to the Southbound Interface (SB I), to abstracting various SBI API solutions to a common NBI API solution.

[0050] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may continuously monitor and reconcile a current desired declarative state for one or more NF deployment instances within the O-Cloud 203.

[0051] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may transparently pass the current desired declarative state to the O-Cloud 203 for a K8S Custom Resource Definition (CRD) API, allowing the O-Cloud 203 to autonomously execute one or more necessary actions to achieve the current desired declarative state.

[0052] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may manage a life cycle of the one or more NF deployments based on at least one of a predefined standard and / or an O-RAN-specific APIs at the NBI to ensure compliance with industry standards. Examples of the pre-defined standard may include European Telecommunications Standards Institute (ETSI) standards SOL 002, SOL 003, and SOL 005.

[0053] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may collaborate with the SO SMOS module 209 to ensure that all required inputs for anexecution of one or more orchestration tasks are provided through the SO SMOS module 209, to enable the NFO SMOS module 217 to operate as a decoupled service.

[0054] In some example embodiments, the SO SMOS module 209 may process requests for creating or modifying one or more network services (NSs) from the NBI using the ETSI standard. The request may be received from a higher layer (e.g., NSSMF) 211. This request may include Network Service Descriptions (NSD) and Virtual Network Function Descriptions (VNFD) that point to a location of application package artifacts in the blueprint or catalog database 301.

[0055] In some example embodiments, for requests related to NF, the SO SMOS module 209 may follow the 3GPP standard (TS 28.532), for NF instance creation, modification, and deletion.

[0056] In some example embodiments, when a new NF needs to be created, the SO SMOS module 209 may retrieve the necessary application package artifacts from the application software package onboarding SMOS module 213 and instructs the NFO SMOS module 217 to create the NF deployment by providing the required deployment artifacts, such as the one or more helm charts or the CRDs.

[0057] In some example embodiments, the SO SMOS module 209 may serve as a central control point / single plane of control, managing the lifecycle of NSs, NFs, and the associated NF deployments or software instances. The NFO SMOS module 217 may handle the 02-DMS interface APIs, including the Kubernetes native APIs, CRDs, and ETSINFV MANO, to instantiate or update applications in response to lifecycle management requests from the SO SMOS module 209

[0058] FIG. 4 illustrates a mapping 4000 between the O-RAN architecture and a 3 GPP architecture, according to an embodiment as disclosed herein.

[0059] In some example embodiments, the O-RAN architecture may include various modules, such as the higher layer (e.g., NSSMF) 211, the SO SMOS module 209, the NFO SMOS module 217, and the O-Cloud 203. The 3 GPP architecture may include various modules, such as a Management and Network Service (MnS) consumer 401, a MnS producer 403, a XYZ reference point 405 for cloud-native NF LCM, and an Orchestration and Management component 406. The higher layer component 211 may perform one or more operations / functionalities similar to the MnS consumer 401. The SO SMOS module 209 and the NFO SMOS module 217 may implement the functionality of the 3GPP MnS producer 403. The O-Cloud 203 may implement the functionality of the XYZ reference point 405 for the cloud-native NF creation LCM, which may interface with the orchestration and management component 406.

[0060] FIG. 5 illustrates a FOCOM SMOS module 215 northbound interface diagram for cluster provisioning, according to an embodiment as disclosed herein. The FOCOM SMOS module 215 may execute multiple operations 5000 in the O-RAN architecture 2000, which are given below.

[0061] In some example embodiments, the FOCOM SMOS module 215 may receive a provisioning request to create, modify, or terminate a cluster. The provisioning request is received from at least one of the UI module 205, the one or more other SMOS modules 207, and the SO SMOS module 209. The cluster is defined by one of a standardized template, an abstracted cluster template, or a vendor-specific cluster template.

[0062] In some example embodiments, in response to receiving the provisioning request, the FOCOM SMOS module 215 may implement either the standardized, the abstracted cluster template, or the vendor-specific cluster template at the NBI of the FOCOM SMOS module 215.

[0063] In some example embodiments, to establish the E2E service flow, the FOCOM SMOS module 215 may transmit an 02 interface Infrastructure Management Services (02-IMS) provisioning request, utilizing one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template, via the 02 interface to the O-Cloud 203.

[0064] In some example embodiments, the FOCOM SMOS module 215 may operate as a service exposure function that exposes the SBI, an 02-IMS interface, one or more cluster provisioning capabilities via one of the standardized template, the abstracted cluster template, or the vendorspecific cluster template to the NBI. In addition, the FOCOM SMOS module 215 may operate as an adapter that translates the vendor-specific cluster template at the SBI into an abstracted standardized template at the NBI.

[0065] In some example embodiments, the FOCOM SMOS module 215 may support multiple use cases for cluster management. A first use case may enable the creation of a cluster from a template to establish clusters with the necessary capabilities for NF deployments. A second use case may support updating a cluster from a template to establish clusters with the required capabilities for NF deployments. A third use case may enable the deletion of a cluster to recover resources for future deployments.

[0066] In some example embodiments, the communication between the potential consumer (e.g., at least one of the UI module 205, the one or more other SMOS modules 207, and the SO SMOS module 209) and the FOCOM SMOS module 215 may utilize standardized API interface options. The FOCOM SMOS module 215 may adapt these standardized northbound interface requests to the SBI.

[0067] In some example embodiments, the FOCOM SMOS module 215 may communicate with the O-Cloud 203 through the O2-IMS interface. The southbound communication may employ 02-1MS ProvisioningRequest with vendor-specific cluster templates, or alternatively may utilize Kubemetes cluster API with vendor-specific CRD.

[0068] FIG. 6 illustrates an SMO service and one or more API requirements for an application software package onboarding SMOS module 213 in the SMO framework, according to an embodiment as disclosed herein. The application software package onboarding SMOS module 213 may execute multiple operations 6000 in the O-RAN architecture 2000, which are given below.

[0069] In some example embodiments, the application software package onboarding SMOS module 213 may receive a request for onboarding one or more applications. The request i s received from at least one of, an Operator / vendor 601, the operator UI module 205 (not shown in FIG. 6), the one or more other SMOS modules 207 (not shown in FIG. 6). The request comprises at least one of, the one or more ASDs, software images, helm charts, or / and CRDs.

[0070] In some example embodiments, in response to the receive request, the application software package onboarding SMOS module 213 may execute one or more application onboarding operations from the application software package onboarding SMOS module 213 to the SO SMOS 209 or the NFO SMOS module 217 (not shown in FIG. 6). The one or more application onboarding operations comprise transferring the one or more ASDs, software images, helm charts, and / or the CRDs received in the request from the application software package onboarding SMOS module 213 to the SO SMOS 209 or the NFO SMOS module 217 (not shown in FIG. 6).

[0071] In some example embodiments, the application software package onboarding SMOS module 213 may engage one or more onboarding software packages for one or more applicationsbased on a third pre-defined standard at the NBI (e.g., ETSI SOL 001, ETSI SOL 004, ETSI SOL 007, ETSI SOL 005, and ORAN ASD R003, etc.).

[0072] In some example embodiments, the application software package onboarding SMOS module 213 may validate the one or more onboarding software packages for the one or more applications during an onboarding process.

[0073] In some example embodiments, the application software package onboarding SMOS module 213 may ensure the onboarding process includes verification of application packages to meet pre-defined security requirements (e.g., as outlined in ISO / QSM).

[0074] In some example embodiments, the application software package onboarding SMOS module 213 may store the one or more onboarding software packages for the one or more applications in an internal blueprint or catalog database 301 for efficient management and retrieval.

[0075] FIG. 7 illustrates an SMO service and one or more API requirements for the SO SMOS module 209 in the SMO framework, according to an embodiment as disclosed herein. The SO SMOS module 209 may execute multiple operations 7000 in the O-RAN architecture 2000, which are given below.

[0076] In some example embodiments, the SO SMOS module 209 may receive a request for creating, modifying, or terminating at least one of, one or more Radio Access Network (RAN) services, one or more network slice subnet instances, one or more Network Functions (NFs), one or more Network Services (NSs) through a Northbound Interface (NBI). The request comprises at least one of a Network Service Descriptor (NSD), the VNFD, and one or more NF-related parameters. The SO SMOS module 209 may utilize at least one of a first pre-defined standard (e.g.,ETSI) and a second pre-defined standard (e.g., 3 GPP) for the creation or modification, or termination.

[0077] In some example embodiments, the SO SMOS module 209 may retrieve one or more application package artifacts, from the blueprint or catalogue database associated with the application software package onboarding SMOS module 213, based on the reference mentioned in the received request.

[0078] In some example embodiments, the SO SMOS module 209 may request the NFO SMOS module 217, for the creation, modification, or termination of the one or more NF deployments based on the one or more retrieved application package artifacts.

[0079] In some example embodiments, the SO SMOS module 209 may coordinate a lifecycle management of at least one of the one or more RAN services, an NS, and associated NFs.

[0080] In some example embodiments, to establish the E2E service flow, the SO SMOS module 209 may manage a life cycle of each of one or more RAN services, network slice subnet instances, NSs, constituent one or more NFs, and one or more NF deployments that realize one or more NFs.

[0081] In some example embodiments, to establish the E2E service flow, the SO SMOS module 209 may utilize a fourth predefined standard (e.g., ETSI SOL 005) for network service Life Cycle Management (LCM). The network service LCM may include various operations, for example, one or more operations to create, instantiate, modify, and terminate the at least one of, the one or more RAN services, the one or more network slice subnet instances, the one or more NSs, or the one or more constituting NFs of the one or more NSs are created directly by the NBI using APIs defined in a fifth pre-defined standard (e.g., 3GPP TS 28.532). The one or more NSs are initially planned by an operator, and planned NS topologies modelling the one or more NSs, NFs, and NFdeployments to be created are stored in either the NSD or in a Test Environment and Validation (TE&IV) database or in another descriptor format.

[0082] In some example embodiments, the SO SMOS module 209 may receive service planning information from the NBI, by utilizing either the NSD or the TE&IV database, or in another descriptor format, to identify one or more NS, one or more NF s, and one or more NF deployments required and the relationship among them to realize a planned topology.

[0083] In some example embodiments, the SO SMOS module 209 may execute the one or more identified NS, the one or more identified NFs, and the identified NF deployment LCM operations. The SO SMOS module 209 may, for execution, at least one of a pre-defined workflow as specified in a sixth pre-defined standard, one or more triggering operations via external service consumer interactions through the NBI as specified in a fourth pre-defined standard, and one or more autonomously executing operations. The sixth pre-defined standard may relate to Section 6.2.9 of ETSI IFA 014, while the fourth pre-defined standard may relate to Section 6.2.9 of ETSI IFA 014.

[0084] In some example embodiments, to establish the E2E service flow, the SO SMOS module 209 may determine one or more NS-NF application-level requirements to make one or more placement decisions and instruct the NFO SMOS module 217 regarding one or more homing requirements for the one or more NF deployments.

[0085] In some example embodiments, to establish the E2E service flow, the SO SMOS module 209 may evaluate the one or more determined NS-NF application-level requirements and instruct the NFO SMOS module 217 concerning one or more performance requirements or one or more resource allocation requirements for the one or more NF deployments.

[0086] In some example embodiments, the one or more NS-NF application-level requirements comprise a capacity requirement and a latency requirement. The one or more homing requirements, the one or more performance requirements, and the one or more resource allocation requirements are communicated to the NFO SMOS module 217 in a form of at least one of the one or more helm charts, the CRDs, Virtual Network Function Descriptors (VNFDs), and Virtual Network Function Component Descriptors (VNFCDs).

[0087] In some example embodiments, the one or more homing and resource allocation may also be determined at design time (by human operators) and stored in the TE&IV or NSD / VNFD. So, directly take the service plan input and apply it instead of deriving it.

[0088] FIG. 8 illustrates an SMO service and one or more API requirements for the NFO SMOS module 217 in the SMO framework, according to an embodiment as disclosed herein. The NFO SMOS module 217 may execute multiple operations 8000 in the O-RAN architecture 2000, which are given below. In addition, one or more functionalities related to the modules (e g., 213, 211, 701) are covered in the description related to FIG. 2 to FIG. 7, and are omitted herein for the sake of brevity.

[0089] In some example embodiments, the NFO SMOS module 217 may receive a request, for creating, modifying, or terminating one or more NF deployments, from the SO SMOS module 209.The request comprises at least one of the one or more helm charts, the ASDs, the CRDs, and the VNFDs. In response to receiving the request, the NFO SMOS module 217 may handle the one or more 02-DMS interface APIs to instantiate or update, or delete one or more applications to fulfil the NF deployment lifecycle management request from the NBI of the SO SMOS module 209.Examples of the 02-DMS interface APIs may include, but are not limited to, the K8S native API, or the ETSI NFV MANO API.

[0090] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may adapt the NBI to SBI by abstraction various SBI API solutions to a common NBI API solution.

[0091] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may continuously monitor and reconcile the current desired declarative state for the one or more NF deployment instances within the O-Cloud 203.

[0092] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may transparently pass the current desired declarative state to the O-Cloud 203 for the K8S CRD API, allowing the O-Cloud 203 to autonomously execute one or more necessary actions to achieve the current desired declarative state.

[0093] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may manage a life cycle of the one or more NF deployments based on at least one of a seventh pre-defined standard and an Open Radio Access Network (O-RAN) specific Application Programming Interfaces (APIs) to ensure compliance with industry standards. An example of the seventh pre-defined standard may include ETSI standards SOL 002 and SOL 003.

[0094] In some example embodiments, to establish the E2E service flow, the NFO SMOS module 217 may collaborate with the SO SMOS module 209 to ensure that all required inputs for an execution of one or more orchestration tasks are provided through the SO SMOS module 209, to enable the NFO SMOS module 217 to operate as the decoupled service.

[0095] FIG. 9 is a flow diagram illustrating a method 9000 for establishing the E2E service flow in the O-RAN architecture 2000, according to an embodiment as disclosed herein. The method 9000 may execute multiple operations to establish the E2E service flow, which are given below.

[0096] At operation 901, the method 9000 includes configuring the one or more interfaces and the services (SMO service) for the plurality of modules associated with the SMO 201 and the O-cloud 203. At operation 902, the method 9000 includes establishing, based on the one or more configured interfaces and services, the E2E service flow between the plurality of modules and the O-Cloud 203 in the O-RAN architecture 2000. Further, a detailed description related to the various operations of FIG.9 is covered in the description related to FIG. 2 to FIG. 8, and is omitted herein for the sake of brevity.

[0097] FIG. 10 illustrates a diagram of example components of an apparatus 10000 (e.g., SMO 201), according to an embodiment as disclosed herein. As shown in FIG. 10, the apparatus 10000 comprises a processor 1010, a memory 1020, a storage component 1030, an input component 1040, an output component 1050, a communication interface 1060, and a bus 1070. In one embodiment, the apparatus 10000 may relate to at least one of the electronic device 201, or any other network device.

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

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

[0100] The storage component 1030 stores information and / or software related to the operation and use of the apparatus 10000. For example, the storage component 1030 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.

[0101] The input component 1040 is configured to receive information, such as user input. For example, the input component 1040 may include, but not be limited to, a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 1040 may include a sensor for sensing information (e.g., a Global Positioning System (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0102] The output component 1050 is configured to provide output information from the apparatus 10000. For example, the output component 1050 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).

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

[0104] The bus 1070 acts as an interconnect between the processor 1010, the memory 1020, the storage component 1030, the input component 1040, the output component 1050, and the communication interface 1060 of the apparatus 10000. The bus 1070 may include a wired interconnection or a wireless interconnection.

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

[0106] Examples of the techniques and apparatus described herein include, but are not limited to, the following enumerated embodiments:[1] A method comprising:configuring one or more interfaces and services for a plurality of modules associated with a Service Management and Orchestration (SMO) and an Open Radio Access Network Cloud (O-Cloud),wherein the plurality of modules comprises an operator User Interface (UI) module, one or more SMO Services (SMOS) modules, a Service Orchestration (SO) SMOS module, a higher layer SMOS module, an Application Software Package Onboarding SMOS module, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module, and a Network Function Orchestrator (NFO) SMOS module; andestablishing, based on the one or more configured interfaces and services, an End- to-End (E2E) service flow between the plurality of modules and the O-Cloud in an Open Radio Access Network (O-RAN) architecture.[2] A method comprising:receiving, at a Federated O-Cloud Orchestration and Management (FOCOM) Service Management and Orchestration service (SMOS) module from at least one of an operator User Interface (UI) module, one or more other SMOS modules, and a Service Orchestration (SO) SMOS module, a provisioning request to create, modify, or terminate a cluster,wherein the cluster characteristics is defined by one of a standardized template, an abstracted cluster template, or a vendor-specific cluster template;implementing either the standardized, the abstracted cluster template, or the vendor-specific cluster template at a Northbound Interface (NBI) of the FOCOM SMOS module; andtransmitting an 02 interface Infrastructure Management Services (02-IMS) cluster provisioning request, utilizing one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template, via the 02 interface to the O-Cloud.[3] The method as described in [2], wherein the FOCOM SMOS module operates as a service exposure function that exposes a Southbound Interface (SB I), an 02-IMS interface, one or more cluster provisioning capabilities via one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template to the NBI, and operates as an adapter that translates the vendor-specific cluster template at a Southbound Interface (SBI) into an abstracted standardized template at the NBI.[4] A method comprising:receiving, at an application software package onboarding Service Management and Orchestration service (SMOS) module from at least one of, an operator User Interface (UI) module, one or more other SMOS modules, a request for onboarding one or more application.wherein the request comprises at least one of, one or more Application Specific Descriptors (ASDs), software images, helm charts, and Cloud Resource Descriptors (CRDs);executing, in response to the receiving request, one or more application onboarding operations from the application software package onboarding SMOS module to the SO SMOS orNFO SMOS module,wherein the one or more application onboarding operations comprise transferring the one or more ASDs, software images, helm charts, and CRDs received in the request from the application software package onboarding SMOS module to the SO SMOS orNFO SMOS module.[5] The method as described in [4],wherein the application software package onboarding SMOS module engages one or more onboarding software packages for one or more NF applications based on a third pre-defined standard at the NBI;wherein the application software package onboarding SMOS module validates the one or more onboarding software packages for the one or more NF applications during an onboarding process;wherein the application software package onboarding SMOS module ensures the onboarding process includes verification of NF application packages to meet pre-defined security requirements; andwherein the Application Software Package Onboarding SMOS module stores the one or more onboarding software packages for the one or more NF applications in an internal blueprint or catalog database for efficient management and retrieval.[6] The method as described in any of [l]-[5], wherein configuring the one or more interfaces and services for the plurality of modules associated with the SMO comprises:establishing, in response to a completion of one or more application onboarding operations, a Network Service (NS) that incorporates a Network Function (NF) instance to facilitate communication among the operator UI module, the one or more SMOS modules, the higher layer SMOS module, and the SO SMOS module.[7] The method as described in any of [l]-[6], wherein configuring the one or more interfaces and services for the plurality of modules associated with the SMO and the O-Cloud comprises:performing one of:creating one or more NF deployment operations at the NFO SMOS module based on at least one of one or more helm charts, CRDs, VNFDs, NSDs, ASDs within the NFO SMOS module; orcreating an NF Deployment instance based on one or more NF Deployment requirements; andinitializing, in response to performing one of, by the NFO SMOS module, at least one of a Kubemetes (K8S) Application Programming Interface (API), a K8S CustomResource Definition (CRD) API, or European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) Management and Orchestration (MANO) interfaces with the O-Cloud, to ensure that the plurality of modules is properly integrated and operational within the O-RAN architecture.[8] A method comprising:receiving, at a Service Orchestration (SO) SMOS module, a request for creating, modifying, or terminating at least one of, one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), one or more Network Services (NSs) through a Northbound Interface (NBI) based on at least one of a first pre-defined standard and a second pre-defined standard,retrieving, at the SO SMOS module, one or more application package artifacts, from a blueprint or catalogue database associated with an application software package onboarding SMOS module, based on the referenced mentioned in the received request; requesting, by the SO SMOS module, to a Network Function Orchestrator (NFO) SMOS module, for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts.[9] The method as described in [8],wherein the request comprises at least one of a Network Service Descriptor (NSD), a Virtual Network Function Descriptor (VNFD), and one or more NF related parameters; andwherein the SO SMOS module is configured to coordinate a lifecycle management of at least one of the one or more RAN services, an NS, and associated NFs

[0010] The method as described in any of [8] - [9] , comprising:performing, at the SO SMOS module, at least one of, to establish an End-to-End (E2E) service flow:managing a life cycle of each of one or more RAN services, network slice subnet instances, NSs, constituent one or more Network Functions (NFs), and one or more NF deployments that realize one or more NFs;utilizing a fourth predefined standard for network service Life Cycle Management (LCM), including one or more operations to create, instantiate, modify, and terminate the at least one of, one or more RAN services, one or more network slice subnet instances, one or more NSs, or the one or more constituting NFs of the one or more NSs are created directly by the NBI using APIs defined in a fifth pre-defined standard;wherein the one or more NSs are initially planned by an operator, and planned NS topologies modelling the one or more NSs, NFs, and NF deployments to be created are stored in either a Network Service Descriptor(NSD) or in a Test Environment and validation (TE&IV) database or in another descriptor format.receiving service planning information from the NB1, by utilizing either the NSD or the TE&IV database, or in another descriptor format, to identify one or more NS, one or more NFs, and one or more NF deployments required and relationship information to realize a planned topology;executing the one or more identified NS, the identified one or more NFs, and the identified NF deployment LCM operations by employing at least one of a pre-defined workflow as specified in a sixth pre-defined standard, one or more triggering operations via external service consumer interactions through the NBT as specified in a fourth pre-defined standard, and one or more autonomously executing operations;determining one or more NS-NF application-level requirements to make one or more placement decisions and instructing the NFO SMOS module regarding one or more homing requirements for the one or more NF deployments; and evaluating the one or more determined NS-NF application-level requirements and instructing the NFO SMOS module concerning one or more performance requirements or one or more resource allocation requirements the one or more NF deployments,wherein the one or more NS-NF application-level requirements comprise a capacity requirement and a latency requirement,wherein the one or more homing requirements, the one or more performance requirements, and the one or more resource allocation requirements are communicated to the NFO SMOS module in a form of at least one of one or more helm charts, Custom Resource Definitions (CRDs), Virtual Network Function Descriptors (VNFDs), and Virtual Network Function Component Descriptors (VNFCDs).

[0011] A method comprising:receiving, at Network Function Orchestrator (NFO) SMOS module, a request, for creating, modifying, or terminating one or more Network Function (NF) Deployments, from a Service Orchestration (SO) SMOS module; andin response to receiving the request, handling, by the NFO SMOS module, one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs), to instantiate or update or delete one or more applications to fulfil an NF Deployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

[0012] The method as described in

[0011] ,wherein the request comprises at least one of one or more helm charts, Custom Resource Definitions (CRDs), Application Package Descriptors (ASDs), and Virtual Network Function Descriptor (VNFDs); andwherein the 02-DMS interface APIs comprise at least one of a Kubernetes (K8S) native Application Programming Interface (API), or a European Telecommunications Standards Institute (ETS1) Network Functions Virtualization (NFV) Management and Orchestration (MANO) API.

[0013] The method as described in any of

[0011] -

[0012] , comprising:performing, at the NFO SMOS module, at least one of, to establish an End-to-End (E2E) service flow:adapting the NBI to the Southbound Interface (SBI), to abstracting various SBI API solutions to a common NBI API solution;continuously monitoring and reconciling a current desired declarative state for one or more NF deployment instances within the O-cloud;transparently passing the current desired declarative state to the O-cloud for a K8S Custom Resource Definition (CRD) API, allowing the O-Cloud to autonomously execute one or more necessary actions to achieve the current desired declarative state;managing a life cycle of the one or more NF deployments based on at least one of a seventh pre-defined standard and an Open Radio Access Network (O-RAN) specific Application Programming Interfaces (APIs) to ensure compliance with industry standards; andcollaborating with the SO SMOS module to ensure that all required inputs for an execution of one or more orchestration tasks are provided through the SO SMOS module, to enable the NFO SMOS module to operate as a decoupled service.

[0014] A system comprising:a Service Orchestration (SO) SMOS module is configured to:receive a request for creating, modifying, or terminating at least one of one or more Radio Access Network (RAN) services, one or more Network Services (NSs) and one or more Network Functions (NFs) through a Northbound Interface (NBT) based on at least one a first pre-defined standard and a second pre-defined standard,retrieve one or more application package artifacts, from a blueprint or catalogue database associated with an application software package Onboarding SMOS module, based on the reference mentioned in the received request; and request to a Network Function Orchestrator (NFO) SMOS module, for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts; and the NFO SMOS module is configured to:in response to receiving the request, handle one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs), to instantiate or update, or delete one or more applications to fulfil an NFdeployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

[0015] An apparatus configured to:configure one or more interfaces and services for a plurality of modules associated with a Service Management and Orchestration (SMO) and an Open Radio Access Network Cloud (O-Cloud),wherein the plurality of modules comprises an operator User Interface (UI) module, one or more SMO Services (SMOS) modules, a Service Orchestration (SO) SMOS module, a higher layer SMOS module, an Application Software Package Onboarding SMOS module, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module, and a Network Function Orchestrator (NFO) SMOS module; andestablish, based on the one or more configured interfaces and services, an End-to- End (E2E) service flow between the plurality of modules and the O-Cloud in an Open Radio Access Network (O-RAN) architecture

[0016] An apparatus configured to:receive, at a Federated O-Cloud Orchestration and Management (FOCOM) Service Management and Orchestration service (SMOS) module from at least one of an operator User Interface (UI) module, one or more other SMOS modules, anda Service Orchestration (SO) SMOS module, a provisioning request to create, modify, or terminate a cluster,wherein the cluster characteristics is defined by one of a standardized template, an abstracted cluster template, or a vendor-specific cluster template;implement either the standardized, the abstracted cluster template, or the vendor-specific cluster template at a Northbound Interface (NBI) of the FOCOM SMOS module; andtransmit an 02 interface Infrastructure Management Services (02-IMS) cluster provisioning request, utilizing one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template, via the 02 interface to the O-Cloud.

[0017] An apparatus configured to:receive, at an application software package onboarding Service Management and Orchestration service (SMOS) module from at least one of, an operator User Interface (UI) module, one or more other SMOS modules, a request for onboarding one or more application,wherein the request comprises at least one of, one or more Application Specific Descriptors (ASDs), software images, helm charts, and Cloud Resource Descriptor (CRDs);execute, in response to the receiving request, one or more application onboarding operations from the application software package onboarding SMOS module to the SO SMOS or NFO SMOS module,wherein the one or more application onboarding operations comprise transferring the one or more ASDs, software images, helm charts, and CRDs received in the request from the application software package onboarding SMOS module to the SO SMOS or NFO SMOS module.

[0018] An apparatus configured to:receive, at a Service Orchestration (SO) SMOS module, a request for creating, modifying, or terminating at least one of, one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NF s), one or more Network Services (NSs) through a Northbound Interface (NBI) based on at least one of a first pre-defined standard and a second pre-defined standard,retrieve, at the SO SMOS module, one or more application package artifacts, from a blueprint or catalogue database associated with an application software package onboarding SMOS module, based on the reference mentioned in the received request; request, by the SO SMOS module, to a Network Function Orchestrator (NFO) SMOS module, for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts.

[0019] An apparatus configured to:receive, at Network Function Orchestrator (NFO) SMOS module, a request, for creating, modifying, or terminating one or more Network Function (NF) Deployments, from a Service Orchestration (SO) SMOS module; andin response to receive the request, handle, by the NFO SMOS module, one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs), to instantiate or update, or delete one or more applications to fulfil an NF Deployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

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

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

[0109] 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. Forexample, orders of processes described herein may be changed and are not limited to the manner described herein.

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

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

[0112] 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 embodimentsherein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

CLAIMSWe claim:

1. A method comprising:configuring one or more interfaces and services for a plurality of modules associated with a Service Management and Orchestration (SMO) and an Open Radio Access Network Cloud (O-Cloud),wherein the plurality of modules comprises an operator User Interface (UI) module, one or more SMO Services (SMOS) modules, a Service Orchestration (SO) SMOS module, a higher layer SMOS module, an Application Software Package Onboarding SMOS module, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS module, and a Network Function Orchestrator (NFO) SMOS module; andestablishing, based on the one or more configured interfaces and services, an End- to-End (E2E) service flow between the plurality of modules and the O-Cloud in an Open Radio Access Network (O-RAN) architecture.

2. A method comprising:receiving, at a Federated O-Cloud Orchestration and Management (FOCOM) Service Management and Orchestration service (SMOS) module from at least one of an operator User Interface (UI) module, one or more other SMOS modules, and a Service Orchestration (SO) SMOS module, a provisioning request to create, modify, or terminate a cluster,wherein the cluster characteristics is defined by one of a standardized template, an abstracted cluster template, or a vendor-specific cluster template;implementing either the standardized, the abstracted cluster template, or the vendor-specific cluster template at a Northbound Interface (NBI) of the FOCOM SMOS module; andtransmitting an 02 interface Infrastructure Management Services (02-IMS) provisioning request, utilizing one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template, via the 02 interface to the O-Cloud.

3. The method as claimed in claim 2, wherein the FOCOM SMOS module operates as a service exposure function that exposes a Southbound Interface (SBI), an 02-IMS interface, one or more cluster provisioning capabilities via one of the standardized template, the abstracted cluster template, or the vendor-specific cluster template to the NBI and operates as an adapter that translates the vendor-specific cluster template at a Southbound Interface (SBI) into an abstracted standardized template at the NBI.

4. A method comprising:receiving, at an application software package onboarding Service Management and Orchestration service (SMOS) module from at least one of, an operator User Interface (UI)module, one or more other SMOS modules, a request for onboarding one or more application.wherein the request comprises at least one of, one or more Application Specific Descriptors (ASDs) , software images, helm charts, and Cloud Resource Descriptor (CRDs);executing, in response to the receiving request, one or more application onboarding operations from the application software package onboarding SMOS module to the SO SMOS orNFO SMOS module,wherein the one or more application onboarding operations comprise transferring the one or more ASDs, software images, helm charts, and CRDs received in the request from the application software package onboarding SMOS module to the SO SMOS orNFO SMOS module.

5. The method as claimed in claim 4,wherein the application software package onboarding SMOS module engages one or more onboarding software packages for one or more applications based on a third predefined standard at the NBI;wherein the application software package onboarding SMOS module validates the one or more onboarding software packages for the one or more applications during an onboarding process;wherein the application software package onboarding SMOS module ensures the onboarding process includes verification of application packages to meet pre-defined security requirements; andwherein the Application Software Package Onboarding SMOS module stores the one or more onboarding software packages for the one or more applications in an internal blueprint or catalog database for efficient management and retrieval.

6. The method as claimed in claim 1, wherein configuring the one or more interfaces and services for the plurality of modules associated with the SMO comprises:establishing, in response to a completion of one or more application onboarding operations, a Network Service (NS) that incorporates a Network Function (NF) instance to facilitate communication among the operator UI module, the one or more SMOS modules, the higher layer SMOS module, and the SO SMOS module.

7. The method as claimed in claim 1, wherein configuring the one or more interfaces and services for the plurality of modules associated with the SMO and the O-Cloud comprises:performing one of:creating one or more NF Deployment operations at the NFO SMOS module based on at least one of one or more helm charts, CRDs, VNFDs, NSDs, ASDs within the NFO SMOS module; orcreating an NF Deployment instance based on one or more NF Deployment requirements; andinitializing, in response to performing one of, by the NFO SMOS module, at least one of a Kubemetes (K8S) Application Programming Interface (API), a K8S Custom Resource Definition (CRD) API, or European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) Management and Orchestration (MANO) interfaces with the O-Cloud, to ensure that the plurality of modules is properly integrated and operational within the O-RAN architecture.

8. A method comprising:receiving, at a Service Orchestration (SO) Service Management and Orchestration service (SMOS) module, a request for creating, modifying, or terminating at least one of, one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), one or more Network Services (NSs) through a Northbound Interface (NBI) based on at least one of a first pre-defined standard and a second pre-defined standard,retrieving, at the SO SMOS module, one or more application package artifacts, from a blueprint or catalogue database associated with an application software package onboarding SMOS module, based on the referenced mentioned in the received request; requesting, by the SO SMOS module, to a Network Function Orchestrator (NFO) SMOS module, the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts.

9. The method as claimed in claim 8,wherein the request comprises at least one of a Network Service Descriptor (NSD), a Virtual Network Function Descriptor (VNFD), and one or more NF related parameters; andwherein the SO SMOS module is configured to coordinate a lifecycle management of at least one of the one or more RAN services, an NS, and associated NFs10. The method as claimed in claim 8, further comprising:performing, at the SO SMOS module, at least one of, to establish an End-to-End (E2E) service flow:managing a life cycle of each of one or more RAN services, network slice subnet instances, NSs, constituent one or more Network Functions (NFs), and one or more NF deployments that realize one or more NFs;utilizing a fourth predefined standard for network service Life Cycle Management (LCM), including one or more operations to create, instantiate, modify, and terminate the at least one of, one or more RAN services, one or more network slice subnet instances, one or more NSs, or the one or more constituting NFs of the one or more NSs are created directly by the NBI using APIs defined in a fifth pre-defined standard;wherein the one or more NSs are initially planned by an operator, and planned NS topologies modelling the one or more NSs, NFs, and NF deployments to be created are stored in either a Network Service Descriptor(NSD) or in a Test Environment and validation (TE&IV) database or in another descriptor format.receiving service planning information from the NB1, by utilizing either the NSD or the TE&IV database, or in another descriptor format, to identify one or more NS, one or more NF s, and one or more NF deployments required relationship information to realize a planned topology;executing the one or more identified NS, the identified one or more NFs, and the identified NF deployment LCM operations by employing at least one of a pre-defined workflow as specified in a sixth pre-defined standard, one or more triggering operations via external service consumer interactions through the NBT as specified in a fourth pre-defined standard, and one or more autonomously executing operations;determining one or more NS-NF application-level requirements to make one or more placement decisions and instructing the NFO SMOS module regarding one or more homing requirements for the one or more NF deployments; and evaluating the one or more determined NS-NF application-level requirements and instructing the NFO SMOS module concerning one or more performance requirements or one or more resource allocation requirements the one or more NF deployments,wherein the one or more NS-NF application-level requirements comprise a capacity requirement and a latency requirement,wherein the one or more homing requirements, the one or more performance requirements, and the one or more resource allocation requirements are communicated to the NFO SMOS module in a form of at least one of one or more helm charts, Custom Resource Definitions (CRDs), Virtual Network Function Descriptors (VNFDs), and Virtual Network Function Component Descriptors (VNFCDs).

11. A method comprising:receiving, at Network Function Orchestrator (NFO) Service Management and Orchestration service (SMOS) module, a request, for creating, modifying, or terminating one or more Network Function (NF) Deployments, from a Service Orchestration (SO) SMOS module; andin response to receiving the request, handling, by the NFO SMOS module, one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs), to instantiate or update or delete one or more applications to fulfil an NF Deployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

12. The method as claimed in claim 11,wherein the request comprises at least one of one or more helm charts, Custom Resource Definitions (CRDs), Application Package Descriptors (ASDs), and Virtual Network Function Descriptors (VNFDs); andwherein the 02-DMS interface APIs comprise at least one of a Kubernetes (K8S) native Application Programming Interface (API), or a European Telecommunications Standards Institute (ETS1) Network Functions Virtualization (NFV) Management and Orchestration (MANO) API.

13. The method as claimed in claim 11, further comprising:performing, at the NFO SMOS module, at least one of, to establish an End-to-End (E2E) service flow:adapting the NBI to the Southbound Interface (SBI), to abstracting various SBI API solutions to a common NBI API solution ;continuously monitoring and reconciling a current desired declarative state for one or more NF deployment instances within the O-cloud;transparently passing the current desired declarative state to the O-cloud for a K8S Custom Resource Definition (CRD) API, allowing the O-Cloud to autonomously execute one or more necessary actions to achieve the current desired declarative state;managing a life cycle of the one or more NF deployments based on at least one of a seventh pre-defined standard and an Open Radio Access Network (O-RAN) specific Application Programming Interfaces (APIs) to ensure compliance with industry standards; andcollaborating with the SO SMOS module to ensure that all required inputs for an execution of one or more orchestration tasks are provided through the SO SMOS module, to enable the NFO SMOS module to operate as a decoupled service.

14. A system comprising:a Service Orchestration (SO) Service Management and Orchestration service (SMOS) module configured to:receive a request for creating, modifying, or terminating at least one of one or more Radio Access Network (RAN) services, one or more Network Services (NSs), and one or more Network Functions (NFs) through a Northbound Interface (NBI) based on at least one a first pre-defined standard and a second pre-defined standard,retrieve one or more application package artifacts, from a blueprint or catalogue database associated with an application software package Onboarding SMOS module, based on the reference mentioned in the received request; and request to a Network Function Orchestrator (NFO) SMOS module, for the creation, modification, or termination of one or more Network Function (NF) Deployments based on the one or more retrieved application package artifacts; and the NFO module is configured to:in response to receiving the request, handle one or more 02 Deployment Management Service (02-DMS) interface Application Programming Interface (APIs), to instantiate or update, or delete one or more applications to fulfil an NFdeployment lifecycle management request from a Northbound Interface (NBI) of the SO SMOS module.

Images