Network function orchestration with northbound interface for network function deployment lifecycle management

Abstract

Disclosed herein is a method for network function orchestration with a northbound interface for network function deployment lifecycle management. The method includes receiving, at a Service Orchestration (SO) Service Management and Orchestration System (SMOS) module, a service creation request; retrieving, by the SO SMOS module, a service descriptor corresponding to the received service creation request from a service and application catalog; decomposing, by the SO SMOS module, the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; and transmitting, by the SO SMOS module to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.

Description

NETWORK FUNCTION ORCHESTRATION WITH NORTHBOUND INTERFACE FOR NETWORK FUNCTION DEPLOYMENT LIFECYCLE MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to Indian Provisional Application No. 202511014228, filed on February 19, 2025, and Indian Non-Provisional Application No. 202511014228, filed on December 26, 2025, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to network function orchestration with a northbound interface for network function deployment lifecycle management.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] A Network Function Orchestration (NFO) with a Northbound Interface (NBI) for Network Function (NF) Deployment Lifecycle Management (LCM) is a key architectural component in 5G networks or cloud-based environments. The orchestration and lifecycle management of NFs is essential for delivering and maintaining the desired network services throughout an end-to-end service flow.

[0005] The End-to-End (E2E) service flow involves multiple stages, each interacting through various interface options such as Northbound Interface (NBI), Southbound Interface (SBI), and Service Orchestration (SO). These interfaces facilitate communication between different orchestration layers, resource management systems, and network functions, ensuring that network services are efficiently delivered, managed, and decommissioned. The choice of interface depends on the level of interaction, the type of service being provided, and the underlying infrastructure used. These interfaces allow for a highly flexible, scalable, and dynamic service delivery, enabling the network to meet customer demands, business policies, and performance expectations.SUMMARY

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

[0007] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, at a Service Orchestration (SO) Service Management and Orchestration System (SMOS) module, a service creation request. The method further includes retrieving, by the SO SMOS module, a service descriptor corresponding to the received service creation request from a service and application catalog. The method also includes decomposing, by the SO SMOS module, the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor. Moreover, the method includes transmitting, by the SO SMOS module to a Network Function Orchestrator (NFO) SMOSmodule, the decomposed at least one of the one or more service components and the one or more sub-service components. The decomposed at least one of the one or more service components and the one or more sub-service components is required for the creation of one or more Network Function (NF) deployments based on the received service creation request.

[0008] According to another embodiment of the present disclosure, an apparatus is disclosed. The apparatus comprises a Service Orchestration (SO) SMOS module. The SMOS module is configured to to receive a service creation request. Further, the SMOS module is configured to retrieve a service descriptor corresponding to the received service creation request from a service and application catalog. The SMOS module is also configured to decompose the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor. Thereafter, the SMOS module is configured to transmit, to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.

[0009] According to another embodiment of the present disclosure, a non-transitoiy computer-readable medium is disclosed. The non-transitory computer-readable medium stores instructions comprising one or more instructions that are executed by an apparatus. The apparatus includes one or more processors. The instructions cause the one or more processors to receive a service creation request. The instructions also cause the one or more processors to retrieve, from a service and application catalog, a service descriptor corresponding to the received service creation request. Moreover, the instructions cause the one or more processors to decompose the received servicecreation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor. Further, the instructions cause the one or more processors to transmit, to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.

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

[0011] 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 example Service Management and Orchestration (SMO) framework and its interaction with an O-Cloud for orchestrating, deploying, and managing Network Functions (NFs), in accordance with an embodiment of the present disclosure;FIG. 2 illustrates an implementation environment for providing support to network energysaving mode stages, according to an embodiment as disclosed herein;FIG.3 illustrates an example method of network function orchestration with a northbound interface (NBI) for Network Function (NF) deployment lifecycle management, in accordance with an embodiment of the present disclosure;FIG.4 illustrates an example architecture depicting a correspondence between Open-Radio Access Network (O-RAN) SMO components and 3rdGeneration Partnership Project (3 GPP) Management Services (MnS) framework, in accordance with the present disclosure;FIG. 5 illustrates an example architecture of a Federated O-Cloud Orchestration and Management (FOCOM) for cluster provisioning through a Northbound Interface (NBI), in accordance with an embodiment of the present disclosure;FIG. 6 illustrates an example architecture of a software package onboarding module, in accordance with an embodiment of the present disclosure;FIG. 7 illustrates an example architecture of a Service Orchestrator (SO) module and its interaction with a Network Function Orchestrator (NFO) module, in accordance with an embodiment of the present disclosure.FIG. 8 illustrates Service Management and Orchestration (SMO) service and API requirements for the NFO module and its interaction with a SO module, in accordance with an embodiment of the present disclosure;FIG. 9 illustrates an architecture for implementing network function orchestration with a Northbound Interface (NBI) for network function deployment lifecycle management, in accordance with an embodiment of the present disclosure;FIG. 10 illustrates a flowchart depicting a method for onboarding application packages, software packages, and service packages, in accordance with an embodiment of the present disclosure;FIG. 11 illustrates a flowchart depicting a method for processing a service creation request, in accordance with an embodiment of the present disclosure;FIG. 12 illustrates a flowchart depicting a method for processing homing information in a service creation workflow, in accordance with an embodiment of the present disclosure; and FIG. 13 illustrates a diagram of example components of the apparatus, according to an embodiment as disclosed herein.DETAILED DESCRIPTION

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

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

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

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

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

[0017] In the present disclosure, specific tasks may be performed using Artificial Intelligence / Machine Learning (AI / ML) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm 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.

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

[0019] Machine learning includes various types of learning method 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 method 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 structureof ML models may vary depending on the embodiments and learning method, and is not limited to the method 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.

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

[0021] The primary objective of the present disclosure is to provide an apparatus and a method for network function orchestration with a northbound interface for network function deployment lifecycle management. The apparatus and method of the present disclosure are able to manage the cases: when the consumer needs Network Function Orchestration (NFO) Service Management and Orchestration System (SMOS) to create a Network Function (NF) Deployment instance based on a new Helm chart, Custom Resource Definition (CRD), or Virtual Network Function Descriptor (VNFD) or Virtual Network Function Component Descriptor (VNFCD), when the consumer needs NFO SMOS to modify a Network Function (NF) instance based on an updated Helm chart, CRD, or VNFD or VNFCD, when the consumer need NFO SMOS to terminate a NF Deployment instance and when the consumer need NFO SMOS to provide NF Deployment instance creation or modification or termination status so that the consumer may understand the status of the process.

[0022] FIG. 1 illustrates an example Service Management and Orchestration (SMO) framework 102 and its interaction with an O-Cloud 104 for orchestrating, deploying, and managing Network Functions (NFs) throughout an end-to-end (E2E) service flow in accordance with an embodimentof the present disclosure. The SMO framework 102, also referred to as SMO 102, encompasses multiple functional modules that collectively enable service orchestration and lifecycle management of network services and functions. The O-Cloud 104 represents the underlying cloud infrastructure that provides computing, storage, and networking resources for hosting network functions.

[0023] As shown, the SMO 102 includes an Operator User Interface (UI) module, one or more Service Management and Orchestration Service (SMOS) modules, a Service Orchestration (SO) module, a higher-layer SMOS module (e.g., NSMF), and an Application Software Package Onboarding module. These modules interact with each other to process service creation requests, onboard applications, and manage network function deployments. The SMO 102 communicates with the O-Cloud 104 through orchestration components such as the Federated O-Cloud Orchestration and Cloud Management (FOCOM) and the Network Function Orchestrator (NFO) with physical / virtual adapters.

[0024] The E2E service flow illustrated in FIG. 1 includes multiple phases and actions. In a first phase, represented by option ‘la’, the SMO 102 initiates provisioning of a cluster using a vendorspecific cluster template. This provisioning operation involves allocating resources such as compute, storage, and networking within the O-Cloud 104 according to predefined templates. The provisioning may utilize Kubernetes (K8s) Application Programing Interfaces (APIs), Kubernetes Custom Resource Definitions (CRDs), or European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) standards for resource instantiation

[0025] In a subsequent phase, represented by option ‘ lb’, the SMO 102 may perform application onboarding. Sub-option ‘a’ of option ‘lb’ indicates onboarding of application artifacts such asApplication Specific Descriptors (ASDs), images, Helm charts, and CRDs to the SO module. This step defines application lifecycle parameters, dependencies, and configurations. Sub-option ‘b’ of option ‘ lb’ indicates onboarding of the application to the NFO, which is responsible for managing the lifecycle of network services and functions, including instantiation, scaling, and termination.

[0026] In another phase, represented by option ‘2’, the SMO 102 supports creation of network slices and network function instances. Sub-option ‘la’ of option ‘2’ illustrates creating a Network Slice (NS) comprising multiple NF instances. In one or more embodiments, each NF instance represents a specific network function such as a firewall, load balancer, or gateway. Sub-option ‘lb’ of option ‘2’ illustrates creating an individual NF instance based on service requirements, including performance, capacity, and scaling characteristics.

[0027] In a further phase, represented by option ‘3’, the SMO 102 enables NF deployment operations. Sub-option ‘la’ of option ‘3’ illustrates creating NF deployment artifacts such as Helm charts, CRDs, and Virtual Network Function Descriptors (VNFDs). Sub-option ‘lb’ of option ‘3’ illustrates creating NF deployment using Helm chart references within the NFO. Sub-option ‘ 1c’ of option ‘3’ illustrates creating NF instances based on network function requirements and service descriptors.

[0028] The O-Cloud 104 provides the execution environment for the instantiated network functions. It hosts clusters provisioned by the SMO 102 and supports containerized workloads through Kubernetes or other orchestration frameworks. The interaction between SMO 102 and O-Cloud 104 ensures that NF deployments are aligned with service-level objectives and resource availability.

[0029] The number and arrangement of modules and components shown in FIG. 1 are provided as an example. Variations such as additional SMOS modules, different orchestration layers, or alternative onboarding mechanisms may be implemented without departing from the scope of the present disclosure.

[0030] FIG. 2 is a diagram of an example of implementation environment 200 in which the apparatus and / or method, described herein, may be implemented. The implementation environment 200 includes a user equipment (UE) 210, a service environment 220, and a network 230. The service environment 220 includes one or more sub-environments 221. To illustrate the one or more sub-environment 221, FIG. 2 shows, for convenience, examples of a 1st subenvironment 221-1, a 2nd sub-environment 221-2, and an N- sub-environment 221-N (where N is any natural number).

[0031] The UE 210 is connected to the network 230, and the network 230 is connected to the service environment 220. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 210 and the service environment 220 are connected via the network 230.

[0032] The UE 210 is a device that communicates with the service environment 220. The UE 210 receives information from the service environment 220 and / or sends information to the service environment 220. Also, the UE 210 may generate and / or store information to be transmitted, as necessary. Also, the UE 210 may store and / or process information that is received, as necessary.

[0033] The example FIG. 2 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device”, “terminal”, “terminal device”, “communication device”, and “communication terminal” may be used interchangeably with the term “UE.”

[0034] For example, the UE 210 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0035] The service environment 220 is an environment that communicates with the UE 210 to provide one or more services. The service environment 220 receives information from the UE 210 and / or sends information to the UE 210. Also, the service environment 220 may generate and / or store information to be transmitted, as necessary. Also, the service environment 220 may store and / or process information that is received, as necessary. For example, the service environment 220 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE 210; it may also be provided to devices other than the UE 210. For example, based on communication from the UE 210, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0036] The example FIG. 2 refers to the “service environment”. The term “service environment” is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing apparatus, network apparatus, and cloud apparatus generally represent the environments in which services are conducted, and these are included within the “service environment”. However, the “service environment” is not limited to these examples. Additionally, the specific types of environments within the “service environment” are not restricted. For instance, cloud environments and cloud apparatus can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the “service environment”.

[0037] The one or more services provided by the service environment 220 are not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 210, a service that stores information from the UE 210, or a service that performs processing based on information from the UE 210 and returns the results of the processing.

[0038] In an embodiment, the service environment 220 may also provide computing resources as the service. The computing resources may be hardware resources and / or software resources. For example, applications, processors, memory, and storage may be included in the provided computing resources. Each computing resource may communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0039] The provided computing resources may be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources may be selected as appropriate. That is, in this disclosure, the use of adjectives such as “Virtual” or “Virtualized” to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0040] The service environment 220 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 220 may be determined as appropriate. Additionally, if the service environment 220 includes one or more sub -environments 221, the placement of devices may be determined based on predetermined policies for each sub-environment 221. For example, devices related to the first service may be placed in the 1st sub-environment 221-1, and devices related to the second service may be placed in the 2nd sub-environment 221-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 221-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 221-2. In this way, specific devices may be placed in specific sub-environments 221. Conversely, each sub-environment 221 may be specialized for a particular purpose.

[0041] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0042] The network 230 is a network that exchanges information between the UE 210 and the service environment 220. The network 230 includes one or more wired and / or wireless networks.

[0043] For example, the network 230 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hocnetwork, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0044] The network 230 may be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 230 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 220 could be in the core network, in which case the network 230 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0045] The number and arrangement of devices and networks shown in FIG. 2 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.

[0046] FIG. 3 illustrates an example method 300 of network function orchestration with a northbound interface (NBI) for Network Function (NF) deployment lifecycle management, in accordance with an embodiment of the present disclosure. FIG. 3 depicts a sequence of operations across the Software Package Onboarding function (block 302), a Service Orchestration (SO) function (block 304), a Network Function Orchestrator (NFO) (block 306), and an O-Cloud execution environment (block 308). In one embodiment, the Software Package Onboarding function, the SO, and the NFO are modules of the SMO framework 102 shown in FIG. 1, while the runtime infrastructure corresponds to the O-Cloud 104. The SMO framework 102 (also referred to as SMO 102) operates as the orchestration and management plane, and the O-Cloud 104 provides compute, storage, and networking resources for instantiating and operating NFs.

[0047] At block 302, application packages are onboarded into a software package blueprint and catalog database 302-a. The software package blueprint and catalog database 302-a stores artifacts and descriptors used later by orchestration flows, such as Application-level descriptors (e.g., ASDs in 0-RAN terminology), Virtual Network Function Descriptors (VNFDs), images, Helm charts, and Kubernetes Custom Resource Definitions (CRDs). In standards practice, descriptor-based onboarding and cataloging underpin NFV MANO-aligned orchestration and lifecycle management. The NSDs and VNF packages are managed so that downstream lifecycle operations can reference a consistent source of truth.

[0048] At block 304, the SO receives a request over the NBI to create / modify a Network Slice (NS) using an ETST NFV-SOL 005 APT carrying NSD / VNFD references. In an alternative embodiment, the SO may receive a request to create / modify an NF using 3GPP TS 28.532 generic management services with NF parameters that refer to artifacts stored in the software package blueprint and catalog database 302-a.

[0049] If the request requires a new NF to be instantiated, the SO retrieves the corresponding application package artifacts (e.g., VNFD, ASD, images, Helm chart, CRD) from the software package blueprint and catalog database 302-a. Thereafter, the SO may decompose the requested service / NF into deployable components according to the descriptor semantics, prior to instructing the NFO.

[0050] At block 306, the NFO may receive a deployment request to the NFO with the deployment artifacts (e.g., Helm chart or CRD) and / or VNFD references for realizing the NF on the O-Cloud. In cloud-native realizations, Helm charts package a set of Kubernetes manifests for reproducible deployment and upgrade / rollback, and CRDs extend the Kubernetes API with custom resourcetypes to express declarative desired state. In NFV realizations, ETSI NFV-SOL 003 specifies the RESTful protocols and data models for VNF Lifecycle Management between NFVO and VNFM. The NFO may adapt these inputs to the appropriate southbound mechanisms.

[0051] The NFO handles a southbound 02 Deployment Management Service (02-DMS) interface toward the O-Cloud. The NFO utilizes standardized Kubernetes (K8s) Native APIs, K8s CRDs, or ETSI NFV MANO procedures to instantiate, scale, update, heal, or terminate NF deployments in order to fulfill the LCM intent received from the SO. Open-Radio Access Network (0-RAN) Work Group 6 (WG6) specifies the 02 interface between SMO and O-Cloud, and the 02-DMS Kubernetes Profile normatively describes how containerized NFs are managed via Kubernetes resources (Deployments, StatefulSets, Services, Ingress, HP A, etc.) under the 02-DMS service, including instantiate, terminate, heal, scale, and software upgrade procedures.

[0052] At block 308, the O-Cloud (for example, the o-cloud 104) provides an execution environment for the NF deployments, hosting clusters, applying declarative desired state, and supplying compute, storage, and networking resources. Under the 02-IMS / DMS framework, SMO 102 supervises infrastructure management and NF deployment LCM over the O-Cloud, enabling multi-vendor interoperability and cloud-native operations.

[0053] The number, naming, and arrangement of blocks and modules shown in FIG. 3 are provided as examples. In other embodiments, the flow may incorporate additional SMO services (e.g., NSMF in slice management), alternate onboarding pipelines, or different southbound profiles (e.g., ETSI NFV VIM / VNFM integrations) while remaining within the scope of descriptor-driven orchestration and standards-based LCM over NBI and 02.

[0054] FIG.4 illustrates an example architecture 400 that depicts the correspondence between O-RAN Service Management and Orchestration (SMO) components and the 3rdGeneration Partnership Project (3GPP) Management Services (MnS) framework for network function orchestration and lifecycle management, in accordance with an embodiment of the present disclosure. The example architecture 400 demonstrates how SMO modules in the O-RAN domain corresponds / map with 3 GPP-defined MnS producers and consumers to enable standards-based orchestration and management of Network Functions (NFs) and Network Services (NSs) over a cloud-native infrastructure. In one embodiment, the SMO framework operates as the orchestration and management plane, while the O-Cloud provides compute, storage, and networking resources for hosting NFs.

[0055] At the top of the O-RAN domain, a higher-layer Operations Support System (OSS), such as a Network Slice Subnet Management Function (NSSMF) 402, issues requests to create, modify, or terminate NSs or NFs using standardized APIs. These requests may use ETSI SOL005 for NS lifecycle management or 3GPP TS 28.531 for NF lifecycle operations. The requests are processed by a Service Orchestration (SO) module 404 and a Network Function Orchestrator (NFO) module 406. The SO module 404 may perform service decomposition and lifecycle coordination. The NFO module 406 may manage NF deployment and lifecycle actions on the O-Cloud 104. Together, the SO module 404 and the NFO module 406 may implement the role of a 3GPP MnS producer 412, exposing northbound management services to a MnS consumers 410 through APIs defined in 3GPP TS 28.532. The MnS consumer 410 may represent higher-level management entities or OSS systems that consume these services for NS and NF lifecycle operations.

[0056] The MnS consumer 410 may communicate with the MnS producer 412 through standardized MnS APIs, exchanging messages such as CreateManagedObj ect, ModifyManagedObject, and QueryManagedObject. These messages enable the MnS consumer 410 to request creation, modification, or termination of NSs and NFs, and to retrieve operational status or configuration details. The MnS producer 412 may respond with confirmation messages, status updates, and error codes as defined in 3GPP TS 28.532. This interaction ensures that higher-level orchestration systems can manage network slices and functions without direct dependency on vendor-specific implementations, thereby promoting interoperability.

[0057] The example architecture 400 also includes an interaction layer represented by block 414, which provides a reference point for cloud-native NF creation and management. The block 414 acts as an abstraction layer that maps MnS-level requests to specific orchestration workflows within the SMO, ensuring that descriptor-driven operations such as Helm chart deployment or CRD instantiation are aligned with the lifecycle intent received from the MnS consumer 410. This layer is critical for translating high-level service models into actionable deployment steps across heterogeneous environments.

[0058] Block 416 represents the orchestration and management functions within the 3GPP domain, which may include NFVO and VNFM components as defined in ETSI NFV MANO architecture. These functions coordinate with the MnS producer 412 to maintain end-to-end service integrity, handle resource allocation, and enforce policies across multiple domains.

[0059] The NFO module 406 may interact with an 02 Deployment Management Service (02-DMS) interface toward the O-Cloud 104 using one of several southbound options. The southbound options may include, but not limited to, Kubemetes native APIs, Kubemetes Custom ResourceDefinitions (CRDs), or ETSI NFV MANO VIM APIs. These interfaces enable NF deployment through artifacts such as Helm charts, CRDs, and Virtual Network Function Descriptors (VNFDs). The O-Cloud 104 provides the execution environment for NF instances, hosting clusters and supplying compute, storage, and networking resources. Under the O-RAN 02 specifications, the 02-DMS Kubemetes profile defines how containerized NFs are instantiated, scaled, healed, and terminated using declarative resource models.

[0060] The example architecture 400 aligns with ETSI NFV and O-RAN standards, where SOL005 governs NS lifecycle management, SOL003 governs VNF lifecycle management, and 02-DMS specifies cloud-native NF deployment procedures. In one embodiment, the SO module and NFO modules shown in FIG. 4 correspond to the SMO framework 102 described in FIG. 1, while the O-Cloud 104 remains the underlying infrastructure layer. The role of MnS producer as implemented by the SO module 404 and the NFO module 406 ensures compliance with 3GPP TS 28.532, enabling northbound exposure of management services to MnS consumers for orchestration and lifecycle control.

[0061] The number and arrangement of components shown in FIG. 4 are provided as an example. Variations such as additional MnS producers, alternate onboarding flows, or different orchestration layers may be implemented without departing from the scope of the present disclosure. The example architecture 400 provides a unified approach for integrating O-RAN SMO functions with 3 GPP MnS-based management, ensuring interoperability across multi-vendor environments and supporting both descriptor-driven and cloud-native orchestration models.

[0062] FIG. 5 illustrates an example architecture 500 of a Federated O-Cloud Orchestration and Management (FOCOM) module 508 for cluster provisioning through a Northbound Interface(NBI), in accordance with an embodiment of the present disclosure. The FOCOM module 508 acts as an adaptor that translates standardized and abstracted cluster provisioning requests received at the NBI into vendor-specific templates or Kubemetes Custom Resource Definitions (CRDs) at the Southbound Interface (SBI). This approach enables interoperability across multi-vendor O-Cloud environments by abstracting implementation-specific details behind a standardized interface.

[0063] FIG. 5 illustrates potential consumers of FOCOM services, including an Operator User Interface (UI) 502, other SMOS modules 506, and a SO module 504. These consumers interact with the FOCOM module 508 through standardized APIs to create, modify, or terminate clusters. The requests may include either standardized and abstracted cluster templates or vendor-specific templates, depending on the selected option. For example, different modes of cluster provisioning may include a fully standardized template, or a allow partial vendor-specific customization.

[0064] The FOCOM module 508 processes these requests and adapts them for execution at the SBI. At the southbound layer, the FOCOM module 508 may interact with the 02 Infrastructure Management Service (02-IMS) to issue implementation-specific commands such as clusterProvisioningRequest using vendor-specific cluster templates or Kubemetes cluster APIs. These APIs may include vendor-specific CRDs that define cluster configuration parameters, resource allocation policies, and lifecycle hooks. By serving as an adaptor, the FOCOM module 508 may ensure that higher-level orchestration systems can manage clusters without being tied to proprietary vendor interfaces.

[0065] The O-Cloud 104 provides the underlying infrastructure for hosting the provisioned clusters. The O-Cloud 104 may supply compute, storage, and networking resources required for cluster instantiation and operation. An 02-IMS layer acts as the control point for infrastructuremanagement, exposing APIs that allow FOCOM to trigger cluster creation, scaling, or termination. This interaction aligns with O-RAN 02 specifications, which define the interface between SMO and O-Cloud for infrastructure and workload management.

[0066] The steps illustrated in FIG. 5 represent a flow for cluster provisioning. First, a consumer such as the SO module 504 sends a request to create or modify a cluster using a standardized template at the NBI. The FOCOM module 508 receives this request and translates it into an implementation-specific format suitable for the target O-Cloud environment. Next, the FOCOM module 508 may invoke the 02-IMS interface using vendor-specific APIs or Kubemetes CRDs to instantiate the cluster. Finally, the O-Cloud 104 provisions the cluster resources and makes them available for hosting network functions or services.

[0067] In one or more embodiments, the operator UI 502, the SMOS modules 506, the SO module 504, and the FOCOM module 508 may corresponds to the SMO framework 102, as shown in FIG.1.

[0068] The example architecture 500 provides a unified mechanism for cluster lifecycle management across heterogeneous environments. By abstracting vendor-specific details at the SBI and exposing standardized APIs at the NBI, the FOCOM module 508 enables seamless integration with higher-level orchestration systems such as SMO and SO. The number and arrangement of components shown in FIG. 5 are provided as an example, and variations such as additional SMOS modules, alternate API profiles, or different cluster templates may be implemented without departing from the scope of the present disclosure.

[0069] FIG. 6 illustrates an example architecture of a software package onboarding module 602, in accordance with an embodiment of the present disclosure. The software package onboardingmodule 602 is responsible for onboarding Network Function (NF) application packages into the SMO framework to enable descriptor-driven orchestration and lifecycle management of network services and functions. In one embodiment, the software package onboarding module 602 may correspond to a component within the SMO framework 102 as shown in FIG. 1.

[0070] The software package onboarding module 602 may support NF application package onboarding aligned with industry standards, including ETSI SOL001, SOL004, and SOL007, as well as O-RAN ASD R003 specifications. These standards define the structure and semantics of descriptors such as Application Software Descriptors (ASDs), Virtual Network Function Descriptors (VNFDs), and associated artifacts required for NFV MANO-compliant orchestration. By adhering to these standards, the onboarding process ensures interoperability across multivendor environments and consistency in lifecycle operations.

[0071] In addition to standards compliance, the software package onboarding module 602 may perform NF application package validations to verify the integrity and correctness of onboarded artifacts. This validation process may include checking descriptor syntax, verifying image references, and ensuring that lifecycle scripts conform to expected behaviors. Furthermore, the onboarding module supports NF application package verification aligned with security requirements such as ISO and Quality Security Management (QSM) guidelines. These security checks help prevent vulnerabilities by validating cryptographic signatures, enforcing secure packaging practices, and ensuring compliance with regulatory requirements.

[0072] Once validated and verified, the onboarded NF application packages are stored in an internal blueprint and catalog database. The internal blueprint and catalog database serves as a centralized repository for descriptors and artifacts, enabling downstream orchestration componentssuch as the Service Orchestration (SO) and Network Function Orchestrator (NFO) to retrieve consistent and authoritative information during service decomposition and NF deployment. The internal blueprint and catalog database may include metadata such as versioning, compatibility information, and resource requirements, which are essential for automated lifecycle management.

[0073] The software package onboarding module 602 thus plays a critical role in enabling descriptor-driven orchestration workflows within the SMO framework. By ensuring standards compliance, performing rigorous validation and security checks, and maintaining a structured catalog of onboarded packages, this module provides the foundation for reliable and secure NF deployment across cloud-native and NFV-based environments. The number and arrangement of components shown in FIG. 6 are provided as an example, and variations such as additional validation steps, alternate catalog structures, or extended security policies may be implemented without departing from the scope of the present disclosure.

[0074] FIG. 7 illustrates an example architecture 700 of a Service Orchestrator (SO) module 704 and its interaction with a Network Function Orchestrator (NFO) module 706, in accordance with an embodiment of the present disclosure. The SO module 704 is responsible for managing the lifecycle of Network Services (NSs), their constituent Network Functions (NFs), and the NF deployments that realize these NFs. In one embodiment, the SO module 704 and NFO module 706 may correspond to components within the SMO framework 102 as shown in FIG. 1.

[0075] The SO module 704 exposes a Northbound Interface (NBI) that can use ETSI SOL005 standards for Network Service lifecycle management, including operations such as create, instantiate, modify, and terminate NS instances. Alternatively, the constituent NFs of an NS can be created directly through the NBI using APIs defined in 3GPP TS 28.532. These standardizedinterfaces ensure interoperability and compliance with industry specifications for service orchestration and management.

[0076] A network service is initially planned by an operator, and the planned NS topologies, representing the modelling of the NS, its constituent NFs, and the NF deployments to be created, are stored either in a Network Service Descriptor (NSD) or in a Topology Exposure & Inventory (TE&IV) database 702-b. The SO module 704 reads these service planning inputs from the northbound interface, either from the NSD or from the TE&IV database 702-b, to determine the new NS, NFs, and NF deployments required to realize the planned topology. In one embodiment, the SO module 704 may interact with a software package onboarding module 702-a to retrieve onboarded application packages and artifacts to perform NF deployment lifecycle management operations.

[0077] Once the planning inputs are retrieved, the SO module 704 executes NS, NF, and NF deployment lifecycle management operations using one of several approaches: (a) a predefined workflow as specified in Section 6.2.9 of ETSI IFA 014, (b) workflows triggered by external service consumers via the NBI, or (c) automated execution initiated by the SO itself. These workflows ensure that service orchestration is flexible and can adapt to operator-driven or automated processes.

[0078] The SO module 704 may also consider NS and NF application-level requirements, such as capacity, latency, and performance constraints, to make placement decisions. Thereafter, the SO module 704 may instruct the NFO module 706 with homing requirements for NF deployments. In addition, the SO module 704 may provide the NFO module 706 with performance and resource allocation requirements for NF deployments. These requirements are communicated in the formof deployment artifacts such as Helm charts, Kubernetes Custom Resource Definitions (CRDs), and Virtual Network Function Descriptors (VNFDs) or Virtual Network Function Component Descriptors (VNFCDs).

[0079] It may be noted that homing and resource allocation requirements can also be determined at design time by human operators and stored in the TE&IV database 702-b or within NSD / VNFD artifacts. In such cases, the SO module 704 may directly apply the service plan inputs without deriving them dynamically. This capability ensures flexibility in orchestration, allowing both automated and operator-driven approaches to coexist within the SMO framework.

[0080] The number and arrangement of components shown in FIG. 7 are provided as an example. Variations such as additional orchestration layers, alternate API profiles, or different planning mechanisms may be implemented without departing from the scope of the present disclosure.

[0081] FIG. 8 illustrates Service Management and Orchestration (SMO) service and API requirements for a NFO module 806 and its interaction with a SO module 804, in accordance with an embodiment of the present disclosure. In one embodiment, the SO module 804 and the NFO module 806 may correspond to components within the SMO framework 102 as shown in FIG. 1. The SO module 804 initiates NF deployment lifecycle operations by sending create, modify, or terminate NF deployment requests to the NFO module 806. These requests are transmitted over the Northbound Interface (NBI) and adapted by the NFO module 806 for execution at the SBI.

[0082] The NFO module 806 is responsible for adapting NBI requests, such as instantiate deployment requests, to the appropriate SBI mechanisms. The NFO module 806 may enable continuous reconciliation of the current declarative wanted state for all NF deployment instances in the O-Cloud 104. In one embodiment, when Kubernetes Custom Resource Definitions (CRDs)are used, the NFO module 806 may transparently pass the declarative wanted state to the O-Cloud 104. This may enable the O-Cloud 104 to perform the necessary actions to achieve the desired state. This approach ensures alignment with cloud-native principles and minimizes orchestration complexity.

[0083] In one or more embodiments, the NFO module 806 may perform NF deployment lifecycle management operation using ETSI-defined SOL002 and SOL003 standards or O-RAN-specific APIs. SOL002 may govern the VE-VNFM interface for VNF lifecycle management, while SOL003 may specify the OR-VNFM interface for VNF lifecycle operations between orchestrators and VNF managers. These standards ensure interoperability and compliance with NFV MANO architecture while supporting cloud-native deployment models.

[0084] The NFO module 806 may work in close collaboration with the SO module 804 and expects all necessary inputs for execution to be provided through the SO module 804. Despite this collaboration, the NFO module 806 may operate as a decoupled service, allowing independent scaling and lifecycle management. The SO module 804 provides deployment artifacts such as Helm charts, Kubernetes CRDs, and Virtual Network Function Descriptors (VNFDs) or Virtual Network Function Component Descriptors (VNFCDs), which the NFO module 806 uses to instantiate and manage NF deployments.

[0085] At the southbound layer, the NFO module 806 interacts with the O2-Deployment Management Service (02-DMS) interface toward the O-Cloud 104 using one of several options: (A) Kubernetes native APIs, (B) Kubernetes CRDs, or (C) ETSI NFV MANO VIM APIs. These interfaces enable NF deployment and lifecycle operations such as instantiation, scaling, healing,and termination. The O-Cloud 104 provides the execution environment for NF deployments, hosting clusters and supplying compute, storage, and networking resources.

[0086] The number and arrangement of components shown in FIG. 8 are provided as an example. Variations such as additional orchestration layers, alternate API profiles, or different deployment mechanisms may be implemented without departing from the scope of the present disclosure.

[0087] FIG. 9 illustrates an architecture 900 for implementing Network Function (NF) orchestration with a NBI for network function deployment lifecycle management, in accordance with an embodiment of the present disclosure. The architecture 900 includes a Software Packaging and Onboarding SMOS module 902, a Service Orchestrator (SO) SMOS module 904, and a Network Function Orchestrator (NFO) SMOS module 906. These modules interact with a repository 910, a catalog 912, and a Network Service Descriptor (NSD) 908. The architecture 900 also illustrates a decomposition module 916, an SO module 918, an NFO 922, and a Homing Algorithms module 920.

[0088] The software packaging and onboarding SMOS module 902 includes an onboarding module 905 and a designer module 907. In one or more embodiments, the onboarding module 905 may receive requests for onboarding application packages, software packages, or service packages. The onboarding module 905 may perform onboarding operations such as, but not limited to, creating the repository 910 and generating the catalog 912. The repository 910 may be configured to store binary artifacts like Helm charts, CSAR packages, and configuration files. The catalog 912 may store service descriptors 914 such as NSD, VNFD, and ASD. The service descriptors 914 define service topologies, workflows, policies, and group rules.

[0089] The designer module 907 may support service design and planning. In some embodiments, the designer module 907 may create deployment topologies, service workflows, application designs, input variables, and configuration templates. The designer module 907 may also be configured to provide libraries for configuration files, observability files, and scripts. After design, the designer module 907 generates service planning artifacts such as NSD, VNFD, and ASD. These artifacts are stored in the catalog 912 for use by the SO SMOS 904.

[0090] In one or more embodiments, upon receiving a service creation request at the NBI, the SO SMOS module 904 retrieves the corresponding NSD from the catalog 912. The NSD contains workflows for service orchestration. The NSD may include linked VNFDs with their respective flavours and may include nested services. The NSD may also define affinity and anti -affinity rules required for service instantiation.

[0091] In some embodiments, the SO SMOS module 904 may use the decomposition module 916 to break down the service creation request into service components and sub-service components. The decomposition module 916 may process these components sequentially based on the retrieved NSD. Thereafter, the SO module 918 may send individual service requests to the NFO SMOS module 906. Before sending requests, the SO module 918 may retrieve homing information from the homing algorithms module 920. The homing information may define application-level requirements such as capacity and latency, as well as infrastructure and transport network constraints, required to take homing decisions.

[0092] In one or more embodiments, the SO SMOS 904 module may retrieve homing information corresponding to a received service creation request. The homing information may define placement decisions, resource allocation constraints, and connectivity requirements for NetworkFunction (NF) deployments. The homing decisions may be computed using one or more algorithms, as described below.

[0093] In an embodiment, the homing algorithm may implement a latency-aware graph optimization technique. The network topology may be modeled as a weighted graph where nodes represent compute clusters and edges represent transport links. Each edge weight may correspond to estimated latency. The algorithm may select a cluster that minimizes end-to-end latency for NF deployments by applying shortest-path computations such as Dijkstra’s algorithm or constraintbased optimization. As described above, according to this embodiment, latency-aware placement minimizes end-to-end delay, improving service quality.

[0094] In another embodiment, homing decisions may be determined using resource-constrained optimization. For example, Mixed Integer Linear Programming (MILP) may be applied to optimize placement under constraints such as CPU, memory, and storage availability per cluster. The objective function may minimize cost or maximize resource utilization while satisfying affinity and anti-affinity rules defined in the service descriptor.

[0095] In yet another embodiment, homing decisions may be predicted using AI / ML-based models. A supervised learning model may be trained on historical NF deployment data, including features such as latency, bandwidth, cluster load, and NF performance metrics. The trained model may output the most suitable cluster for deployment, enabling proactive placement under dynamic network conditions.

[0096] The SO module 918 may then decompose the service components into individual functions. These functions may include Virtual Network Functions (VNFs), Cloud-native Network Functions(CNFs), and Physical Network Functions (PNFs). The SO module 918 may transmit these function-level requests to the NFO SMOS module 906 for NF deployment.

[0097] The NFO SMOS module 906 may adapt NB1 requests to the SB1. The NFO SMOS module 906 may forward deployment instructions to the 02-DMS toward the O-Cloud 104. The NFO SMOS module 906 may use one of several southbound options: Kubemetes native APIs, Kubernetes Custom Resource Definitions (CRDs), or ETSI NFV MANO interfaces. The NFO SMOS module 906 may enable continuous reconciliation of the declarative wanted state for all NF deployments in the O-Cloud 104. When CRDs are used, the NFO SMOS module 906 may pass the declarative state directly to the O-Cloud 104. This may enable the O-Cloud 104 to perform actions to meet the desired state.

[0098] The NF deployment lifecycle management is performed using ETSI-defined SOL002 and SOL003 standards or O-RAN-specific APIs. The NFO SMOS module 906 works closely with the SO module 918 and expects all necessary inputs to be provided through the Service Orchestrator. Despite this collaboration, in some embodiments, the NFO SMOS module 906 may operate as a decoupled service, allowing independent scaling and lifecycle control.

[0099] The number and arrangement of components shown in FIG. 9 are provided as examples. Variations such as additional SMOS modules, alternate workflows, or different descriptor structures may be implemented without departing from the scope of the present disclosure. In one embodiment, the modules shown (902, 904, 906) are all part of the SMO framework 102 described in FIG. 1, with the O Cloud and 02 DMS providing the execution substrate and management interfaces for the resulting NF deployments.

[0100] FIG. 10 illustrates a flowchart depicting a method 1000 for onboarding application packages, software packages, and service packages, in accordance with an embodiment of the present disclosure. The method 1000 may be performed by the software package onboarding SMOS module 902 as shown in FIG. 9.

[0101] At step 1002, the software package onboarding SMOS module 902 receives a request for onboarding. The request may corresponds to onboarding at least one of one or more application packages, one or more software packages, and one or more service packages. The request may originate from an operator UI module or from one or more other SMOS modules.

[0102] At step 1004, software package onboarding SMOS module 902 creates the repository 910. The repository 910 may store the onboarded application packages, software packages, and service packages. The repository 910 may include binary artifacts such as Helm charts, CSAR packages, and configuration files.

[0103] At step 1006, the software package onboarding SMOS module 902 may generate a service and application catalog (for example, the catalog 912) based on the received onboarding request. The catalog 912 may include one or more service descriptors. The service descriptors may include at least one of a service planning artifact, one or more Application Specific Descriptors (ASDs), a Network Service Descriptor (NSD), and a Network Function Descriptor (NFD). These descriptors define service topologies, workflows, policies, and group rules required for service orchestration.

[0104] The onboarding process ensures that all application packages and descriptors are validated and stored for use by downstream modules such as the Service Orchestrator and Network Function Orchestrator. The catalog 912 may provide a consistent source of truth for service lifecycle management operations.

[0105] The number and arrangement of steps shown in FIG. 10 are provided as an example. Variations such as additional validation steps, alternate catalog structures, or extended security checks may be implemented without departing from the scope of the present disclosure.

[0106] FIG. 11 illustrates a flowchart depicting a method 1100 for processing a service creation request, in accordance with an embodiment of the present disclosure. The method 1100 may be performed by the SO SMOS module 904.

[0107] At step 1102, the SO SMOS module 904 may receive a service creation request. The request may correspond to creation of one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), or one or more Network Services (NSs) through a Northbound Interface (NBI). The request may be based on at least one of a first pre-defined standard or a second pre-defined standard, such as ETSI SOL005 or 3 GPP TS 28.532

[0108] At step 1104, the SO SMOS module 904 may retrieve a service descriptor corresponding to the received service creation request from a service and application catalog. The service descriptor defines at least one service topology, one or more application designs, one or more workflow designs, one or more service policies, and one or more group rules associated with one or more services. The service descriptor may also include one or more linked Network Function Descriptors (NFDs) and corresponding NFD Flavours.

[0109] At step 1106, the SO SMOS module 904 decomposes the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor. The decomposition ensures that each component aligns with the workflows and policies defined in the descriptor.

[0110] At step 1108, the SO SMOS module 904 transmits the decomposed components to the NFO SMOS module 906. The transmission includes at least one of the one or more service components and the one or more sub-service components for the creation of one or more NF deployments based on the received service creation request.[OHl] The number and arrangement of steps shown in FIG. 11 are provided as an example. Variations such as additional validation steps, alternate decomposition logic, or extended descriptor structures may be implemented without departing from the scope of the present disclosure.

[0112] FIG. 12 illustrates a flowchart depicting a method 1200 for processing homing information in a service creation workflow, in accordance with an embodiment of the present disclosure. The method 1200 may be performed by the SO SMOS module 904.

[0113] At step 1202, the SO SMOS module 904 may retrieve homing information corresponding to the received service creation request. The homing information may include placement decisions, resource allocation constraints, and connectivity requirements. These decisions consider application-level requirements such as capacity and latency, as well as infrastructure capabilities and transport network constraints.

[0114] At step 1204, the SO SMOS module 904 sequentially processes the received service creation request based on the retrieved homing information and the retrieved service descriptor. The service descriptor defines workflows, policies, and group rules for service instantiation. Sequential processing ensures that each service component and sub-service component is instantiated in the correct order and aligned with the homing requirements.

[0115] The number and arrangement of steps shown in FIG. 12 are provided as an example. Variations such as additional validation steps, order of steps, or alternate homing algorithms, may be implemented without departing from the scope of the present disclosure.

[0116] FIG. 13 illustrates a diagram of example components of the apparatus 1300, according to an embodiment as disclosed herein. As shown in FIG. 13, the apparatus 1300 comprises a processor 1310, a memory 1320, a storage component 1330, an input component 1340, an output component 1350, a communication interface 1360, and a bus 1370. The apparatus 1300 is configured to perform the steps to be taken to perform network function orchestration with the northbound interface for network function deployment lifecycle management. The apparatus 1300 may corresponds to the SMO 102 and / or one or more associated component (such as SO SMOS module 904, the software packaging and onboarding SMOS module 902).

[0117] The processor 1310, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1310 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 apparatus, or the like. The processor 1310 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.

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

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

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

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

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

[0123] The bus 1370 acts as an interconnect between the processor 1310, the memory 1320, the storage component 1330, the input component 1340, the output component 1350, and the communication interface 1360 of the apparatus 1300. The bus 1370 may include a wired interconnection or a wireless interconnection.

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

[0125] Examples of the techniques and apparatus described herein include, but are not limited to, the following enumerated embodiments:[1] A method comprising:receiving, at a Service Orchestration (SO) Service Management and Orchestration System (SMOS) module, a service creation request;retrieving, by the SO SMOS module, a service descriptor corresponding to the received service creation request from a service and application catalog;decomposing, by the SO SMOS module, the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmitting, by the SO SMOS module to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.[2] The method as described in [1], wherein prior to receiving the service creation request, the method comprises:receiving, at a software package onboarding SMOS module from at least one of an operator User Interface (UI) module or one or more other SMOS modules, a request for onboarding of at least one of one or more application packages, one or more software packages, and one or more service packages;performing, by the software package onboarding SMOS module, one or more onboarding operations in response to the receiving request, wherein the one or more onboarding operations comprise at least one of:creating a repository of the at least one of the one or more application packages, the one or more software packages, and the one or more service packages; andgenerating the service and application catalog based on the received request for onboarding, wherein the service and application catalog comprises one or more service descriptors, wherein the one or more service descriptors comprise at least one of a service planning artifact, one or more Application Specific Descriptors (ASDs), a Network Service Descriptor (NSD), and a Network Function Descriptor (NFD).[3] The method as described in any of [1] to [2], wherein prior to transmitting the decomposed at least one of the one or more service components and the one or more sub-service components, the method comprises:retrieving homing information corresponding to the received service creation request; and sequentially processing the received service creation request based on the retrieved homing information and retrieved service descriptor.[4] The method as described in any of [1] to [3], wherein the one or more service descriptors define at least one service topology, one or more application designs, one or more workflow designs, one or more service policies, and one or more group rules associated with one or more services.[5] The method as described in any of [1] to [4], wherein the one or more service descriptors comprise one or more linked NFDs and corresponding NFD Flavours.[6] The method as described in any of [1] to [5], wherein the service creation request corresponds to creation of at least one of one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), or 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.[7] An apparatus comprising:a Service Orchestration (SO) SMOS module configured to:receive a service creation request;retrieve a service descriptor corresponding to the received service creation request from a service and application catalog;decompose the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmit, to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.[8] The apparatus as described in [7], wherein prior to transmitting the decomposed at least one of the one or more service components and the one or more sub-service components, the SO SMOS module is configured to:retrieve homing information corresponding to the received service creation request; and sequentially process the received service creation request based on the retrieved homing information and retrieved service descriptor.[9] The apparatus as described in any of [7] to [8], wherein the one or more service descriptors define at least one service topology, one or more application designs, one or more workflow designs, one or more service policies, and one or more group rules associated with one or more services.

[0010] The apparatus as described in any of [7] to [9], wherein the one or more service descriptors comprise one or more linked NFDs and corresponding NFD Flavours.

[0011] The apparatus as described in any of [7] to

[0010] , wherein the service creation request corresponds to creation of at least one of one or more Radio Access Network services, one or more network slice subnet instances, one or more Network Functions (NFs), or one or more NetworkServices (NSs) through a Northbound Interface (NBI) based on at least one of a first pre-defined standard and a second pre-defined standard.

[0012] A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by an apparatus comprising one or more processors, cause the one or more processors to:receive a service creation request;retrieve, from a service and application catalog, a service descriptor corresponding to the received service creation request;decompose the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmit, to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components for the creation of one or more Network Function (NF) deployments based on the received service creation request.

[0126] The embodiments disclosed herein may 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 may be at least one of a hardware device or a combination of hardware devices and software modules.

[0127] 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, variousworking modifications may be made to the method in order to implement the inventive concept as taught herein.

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

[0129] Moreover, the actions of any flow diagram need not be implemented in the order shown, nor are all of the acts necessarily 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.

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

[0131] 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 thegeneric concept, and, therefore, such adaptations and / or modifications may be 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. A method comprising:receiving, at a Service Orchestration (SO) Service Management and Orchestration service (SMOS) module, a service creation request;retrieving, by the SO SMOS module, a service descriptor corresponding to the received service creation request from a service and application catalog;decomposing, by the SO SMOS module, the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmitting, by the SO SMOS module to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components, for the creation of one or more Network Function (NF) deployments based on the received service creation request.

2. The method of claim 1, wherein prior to receiving the service creation request, the method comprises:receiving, at a software package onboarding SMOS module from at least one of, an operator User Interface (UI) module, one or more other SMOS modules, a request for onboarding of at least one of one or more application packages, one or more software packages, and one or more service packages;performing, by the software package onboarding SMOS module, one or more onboarding operations in response to the receiving request, wherein the one or more onboarding operations comprises at least one of:creating a repository of the at least one of the one or more application packages, the one or more software packages, and the one or more service packages; and generating the service and application catalog based on the receive request for onboarding, wherein the service and application catalog comprises one or more service descriptors, wherein the one or more service descriptors comprises at least one of a service planning artifact, one or more Application Specific Descriptors (ASDs), a Network Service Descriptor (NSD), and a Network Function Descriptor (NFD).

3. The method of claim 1, wherein prior to transmitting the decomposed at least one of the one or more service components and the one or more sub-service components, the method comprises:retrieving homing information corresponding to the received service creation request; and sequentially processing the received service creation request based on the retrieved homing information and retrieved service descriptor.

4. The method of claim 1, wherein the one or more service descriptors define at least one service topology, one or more application designs, one or more workflow designs, one or more service polices, and one or more group rules, associated with one or more services.

5. The method of claim 1, wherein the one or more service descriptors comprises one or more linked NFDs and corresponding NFD Flavours.

6. The method of claim 1, wherein the service creation request corresponds to creation of 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 predefined standard.

7. An apparatus comprising:a Service Orchestration (SO) Service Management and Orchestration service (SMOS) module configured to:receive a service creation request;retrieve a service descriptor corresponding to the received service creation request from a service and application catalog;decompose the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmit, to a Network Function Orchestrator (NFO) SMOS module, the decomposed at least one of the one or more service components and the one or more sub-service components, for the creation of one or more Network Function (NF) deployments based on the received service creation request.

8. The apparatus of claim 7, wherein prior to transmitting the decomposed at least one of the one or more service components and the one or more sub-service components, the SO SMOS module is configured to:retrieve homing information corresponding to the received service creation request; and sequentially process the received service creation request based on the retrieved homing information and retrieved service descriptor.

9. The apparatus of claim 7, wherein the one or more service descriptors define at least one service topology, one or more application designs, one or more workflow designs, one or more service polices, and one or more group rules, associated with one or more services.

10. The apparatus of claim 7, wherein the one or more service descriptors comprises one or more linked NFDs and corresponding NFD Flavours.

11. The apparatus of claim 7, wherein the service creation request corresponds to creation of 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 predefined standard.

12. A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by an apparatus comprising one or more processors, cause the one or more processors to:receive a service creation request;retrieve, from a service and application catalog, a service descriptor corresponding to the received service creation request;decompose the received service creation request into at least one of one or more service components and one or more sub-service components based on the retrieved service descriptor; andtransmit, to a Network Function Orchestrator (NFO) Service Management and Orchestration service (SMOS) module, the decomposed at least one of the one or more service components and the one or more sub-service components, for the creation of one or more Network Function (NF) deployments based on the received service creation request.

Images