System and method for orchestrating cloud-native network functions in a container infrastructure

Abstract

A system (400) and a method (800, 900) for orchestrating a Cloud-native Network Function (CNF) in a container infrastructure is disclosed. The system (400) includes a Universal Cloud Service Executor (UCSE) (169) and a CNF Lifecycle Manager (CNFLM) (121). The CNFLM (121) receives a CNF orchestration request and fetches a resource availability status of the container infrastructure (203) from a database (149), based on the CNF orchestration request. Moreover, the CNFLM (121) transmit a CNF orchestration trigger to the UCSE (169) using an interface between the CNFLM (121) and the UCSE (169) based on a determination that the resource is available for the orchestration of the CNF and update the resource availability status of the container infrastructure (203) in the database (149) based on a CNF orchestration response for the orchestration request, received from the UCSE (169) corresponding to the orchestration of the CNF in the container infrastructure (203).

Description

SYSTEM AND METHOD FOR ORCHESTRATING CLOUD-NATIVE NETWORK FUNCTIONS IN A CONTAINER INFRASTRUCTURETECHNICAL FIELD

[0001] The embodiments of the present disclosure generally relate to the field of communication networks. More particularly, the present disclosure relates to a system and a method for orchestrating cloud-native network functions in a container infrastructure.BACKGROUND OF THE INVENTION

[0002] In today’s world, Network Functions Virtualization (NFV) has become an important aspect of application development. The NFV involves virtualizing network services that traditionally ran on dedicated hardware (like routers, firewalls, load balancers) and running them as software-based functions on standard servers. The NFV provides an approach to design, deploy, and manage network services. Network function virtualization management and orchestration (NFV MANO) is an architectural framework used to perform management and coordination on a virtualized network function (VNF). The VNFs are software applications that deliver network functions such as directory services, routers, firewalls, load balancers, and more. The VNFs are deployed on Virtual Machines (VMs). However, the VMs impose limitations to achieve scalability in cloud environments.

[0003] To overcome above mentioned limitations, a cloud-native approach is used which uses containers rather than VMs. The containers allow users to package software with all of files necessary to run it while sharing access to the operating system and other server resources. In the cloud-native approach, Container Network Function (CNF) refers to the network functions that are implemented and executed within the container. The CNF allows for the creation of virtual networks within containers, enabling communication between containers and with the externalnetwork. This allows for the implementation of network functions like firewalls, load balancers, and VPNs within a container environment.

[0004] To perform management and coordination on the container, provisioning of CNF operations is required. The provisioning of the CNF operations involves various operations, such as instantiation, termination, scaling, and change management, across major container orchestration platforms. Typically, a CNF Lifecycle Manager (CNFLM) is responsible for preparing the necessary data for these operations and sending it to a Cloud Service Executor responsible for managing deployment and orchestration of the CNF operations on deployment sites. To ensure smooth execution of the CNF, the CNF provisioning is required to be carried out seamlessly, as any failure of which (e.g., incomplete or inconsistent CNF data) can disrupt proper deployment and configuration.

[0005] Therefore, there is a need for an improved architectural framework for orchestrating the CNF operations.SUMMARY

[0006] The following embodiments present a simplified summary in order to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key / critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0007] According to an embodiment of the present disclosure, a method for orchestrating Container Network Function (CNF) operations in a container infrastructure is presented. The method includes receiving, by a transceiver module at a CNF Lifecycle Manager (CNFLM), a CNF orchestration request. The CNF orchestration request corresponds to a CNF operation for orchestrating the CNF inthe container infrastructure. The method further includes fetching, by the transceiver module at the CNFLM, a resource availability status of the container infrastructure from a database. The resource availability status indicates a resource in the container infrastructure being available or unavailable for orchestration of the CNF. Furthermore, the method includes transmitting, by the transceiver module at the CNFLM, a CNF orchestration trigger to a Universal Cloud Service Executor (UCSE) using an interface between the CNFLM and the UCSE based on a determination that the resource is available for the orchestration of the CNF. Furthermore, the method includes updating, by an update module at the CNFLM, the resource availability status of the container infrastructure in the database based on a CNF orchestration response for the CNF orchestration request, received from the UCSE corresponding to the orchestration of the CNF in the container infrastructure.

[0008] In some aspects of the present disclosure, the CNF orchestration trigger initiates the orchestration of the CNF in the container infrastructure corresponding to the CNF orchestration request.

[0009] In some aspects of the present disclosure, the CNF orchestration request corresponds to a CNF operation from a plurality of CNF operations for orchestrating the CNF in the container infrastructure.

[0010] In some aspects of the present disclosure, the interface between the CNFLM and the UCSE provides monitoring of an execution lifecycle of the CNF operation corresponding to the CNF orchestration request in the container infrastructure.

[0011] In some aspects of the present disclosure, the CNF orchestration response is an CNF orchestration acknowledgement corresponding to a successful orchestration of the CNF in the container infrastructure or a CNF orchestration error corresponding to a failed orchestration of the CNF in the container infrastructure.

[0012] In some aspects of the present disclosure, prior to fetching the resource availability status of the container infrastructure from the database, the method includes determining, by a validation module at the CNFLM, a validity of CNF data in the CNF orchestration request for the orchestration of the CNF in the container infrastructure. The resource availability status of the container infrastructure is fetched from the database when the CNF data is determined valid for the orchestration of the CNF in the container infrastructure.

[0013] In some aspects of the present disclosure, the method further includes rendering, by a notification module at the CNFLM, a first error notification based on a determination that the resource is available for the orchestration of the CNF, a second error notification indicating the CNF orchestration error corresponding to the failed orchestration of the CNF in the container infrastructure, and a third error notification when the CNF data is found invalid for the orchestration of the CNF in the container infrastructure.

[0014] In some aspects of the present disclosure, upon updating the resource availability status of the container infrastructure in the database, the method includes generating, by the notification module at the CNFLM, a notification trigger for the user interface rendering the update of the database for the for orchestration of the CNF in the container infrastructure.

[0015] According to another embodiment of the present disclosure, a system for orchestrating a Cloud-Native Network Function (CNF) in a container infrastructure is provided. The system includes a Universal Cloud Service Executor (UCSE) and a CNF Lifecycle Manager (CNFLM) communicatively coupled to each other, The CNFLM comprises a transceiver module and an update module. The transceiver module is configured to receive a CNF orchestration request and fetch a resource availability status of the container infrastructure from a database. The resource availability status indicates a resource in the container infrastructure being available or unavailable for orchestration of the CNF. Moreover, the transceiver module is further configured to transmit a CNF orchestration trigger to the UCSE using aninterface between the CNFLM and the UCSE based on a determination that the resource is available for the orchestration of the CNF. The update module is configured to update the resource availability status of the container infrastructure in the database based on a CNF orchestration response for the orchestration request, received from the UCSE corresponding to the orchestration of the CNF in the container infrastructure.

[0016] According to yet another embodiment of the present disclosure, a computerprogram product for orchestrating a Container Network Function (CNF) in a container infrastructure is provided. The computer-program product comprising computer-executable instructions that are stored on a non-transitory computer- readable medium and that, when executed by at least one processor performs operations. The operations include receiving a CNF orchestration request and fetching a resource availability status of the container infrastructure from a database. The resource availability status indicates a resource in the container infrastructure being available or unavailable for orchestration of the CNF. The operations further include transmitting a CNF orchestration trigger to a Universal Cloud Service Executor (UCSE) using an interface between a CNF Eifecycle Manager (CNFEM) and the UCSE based on a determination that the resource is available for the orchestration of the CNF. Furthermore, the operations include updating the resource availability status of the container infrastructure in the database based on a CNF orchestration response for the CNF orchestration request, received from the UCSE corresponding to the orchestration of the CNF in the container infrastructure.BRIEF DESCRIPTION OF DRAWINGS

[0017] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts disclosed herein. Further, components and elements shown in the drawings are not necessarily to scale,emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For the purpose of consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings.

[0018] FIG. 1 illustrates a block diagram depicting an architecture framework for orchestrating Container Network Function (CNF) operations, in accordance with an embodiment of the present invention.

[0019] FIG. 2 illustrates a block diagram depicting an operational environment including an interface between a CNF Lifecycle Manager (CNFLM) and a Universal Cloud Service Executor (UCSE), in accordance with an embodiment of the present disclosure.

[0020] FIG.3 illustrates a block diagram depicting exemplary components of the CNFLM, in accordance with an embodiment of the present disclosure.

[0021] FIG. 4 illustrates a block diagram depicting exemplary components of a system for orchestrating the CNF operations in a container infrastructure, in accordance with an embodiment of the present disclosure.

[0022] FIG. 5 illustrates a process flow diagram depicting a process for orchestrating CNF instantiation operation, in accordance with an embodiment of the present invention.

[0023] FIG. 6 illustrates a process flow diagram depicting a process for orchestrating CNF termination operation, in accordance with an embodiment of the present invention.

[0024] FIG. 7 illustrates a process flow diagram depicting a process for orchestrating CNF scaling operation, in accordance with an embodiment of the present invention.

[0025] FIG. 8 is a flow chart depicting a method for orchestrating the CNF operations, in accordance with an embodiment of the present disclosure.

[0026] FIG. 9 is a flow chart depicting another method for orchestrating the CNF operations in the container infrastructure, in accordance with an embodiment of the present disclosure.

[0027] FIG. 10 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented.LIST OF REFERENCE NUMERALS

[0028] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is as follows:100 - Architecture Framework101 - User interface Layer (UI / UX)103 - NVF & SDN Design Functions105 - Platform Foundation Services107 - Platform Core Services109 - Platform Resource Adapters and Utilities111 - VNF Lifecycle Manager113 - VNF Catalog115 - Network Services Catalog117 - Network Slicing & Service Charging Manager119 - Physical and Virtual Resource Manager121 - CNF Lifecycle Manager (CNFLM)123 - Microservices Elastic Load125 - Identity and Access Manager127 - Command Line Interface129 - Central Logging Manager131 - Event Routing Manager133 - NFV Infrastructure Monitoring Manager135 - Assurance Manager137 - Performance Manager139 - Policy Execution Engine141 - Capability Monitoring Manager143 - Release Management Repository145 - Configuration Manager & GCT147 - NFV Platform Decision Analytics149 - Database151 - Platform Schedulers & Cron Jobs153 - VNF Backup & Upgrade Manager155 - Micro Service Auditor157 - Platform Operations, Administration, and Maintenance Manager159 - Platform External API Adapter and Gateway161 - Generic Decoder and Indexer163 - Docker Swarm Adapter165 - Open Stack API Adapter167 - NFV Gateway169 - Universal Cloud Service Executor (UCSE)200 - Operational Environment201 - Network Management System (NMS)203 - Container Infrastructure300 - Communication Interface301 - Input Output (I / O) Interface302 - Console Host304 - Processing Circuitry306 - Memory Unit307 - First Communication Bus308 - Transceiver Module310 - Processing Module312 - Update Module314 - Validation Module316 - Notification Module319 - Second Communication Bus320 - Instructions Repository322 - Instructions Objects324 - Data Repository326 - Data Objects400 - System for orchestrating the CNF operations405 - Container Platform Managers500 - Process for orchestrating CNF instantiation operation502-511 - Steps of the Process 500600 - Process for orchestrating CNF termination operation602-611 - Steps of the Process 600700 - Process for orchestrating CNF scaling operation702-711 - Steps of the process 700800 - Method for orchestrating the CNF operations802-824 - Operational blocks of the method 800900 - Method for orchestrating the CNF operations at container infrastructure902-908 - Operational blocks of the method 8001000 - Computer System1010 - Bus1020 - Processing Unit1030 - Main Memory1040 - ROM1050 - Storage Device1060 - Input Device1070 - Output Device1080 - Communication InterfaceDETAILED DESCRIPTION OF THE INVENTION

[0029] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

[0030] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

[0031] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” or “some implementations” which may each refer to one or more or all of the same or different embodiments or implementations. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly,the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” or “in an implementation” refers to one embodiment or one implementation and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments ”. Further, the term, for example, “in one or more implementations” refers to “at least one implementation, or more than one implementation, or all implementations.

[0032] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

[0033] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features.

[0034] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.

[0036] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0037] The term “Container Network Function (CNF)” in the entire disclosure may refer to a network function that is packaged, deployed, and executed within one or more containerized environments (containers) in a communication network.

[0038] The term “Container” in the entire disclosure may refer to an executable software package including an application and its required dependencies. Each network function may run inside one or more containers.

[0039] The term “CNF instantiation” in the entire disclosure may refer to an operation of creating a CNF within a containerized execution environment. The CNF instantiation involves retrieving CNF parameters from a CNF deployment plan, allocating necessary compute, storage, and networking resources, and initializing CNF instance using an orchestration platform.

[0040] The term “CNF scaling” in the entire disclosure may refer to an operation of adjusting resource or a number of CNF instances to meet service requirement.

[0041] The term “CNF termination” in the entire disclosure may refer to an operation of removing a CNF instance from the communication network.

[0042] The term “Container platform” in the entire disclosure may refer to a software environment that provides orchestration, scheduling, networking, and lifecycle management for the one or more containers.

[0043] The term “host node” in the entire disclosure may refer to a physical or virtual machine within a container platform that provide computing, storage, and networking resources for running the one or more containers.

[0044] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 to FIG. 10, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0045] FIG. 1 illustrates a block diagram depicting an architecture framework 100 for orchestrating Container Network Function (CNF) operations, in accordance with an embodiment of the present invention. The embodiment of the architecture framework 100 shown in FIG. 1 is for illustration only. Other embodiments of the architecture framework 100 may be used without departing from the scope of this disclosure.

[0046] The architecture framework 100 includes a user interface 101 (hereinafter interchangeably referred to as UI 101 or user interface 101), Network Functions Virtualization (NFV) & Software-defined Networking (SDN) design functions 103, platform foundation services 105, platform core services 107, and platform resource adapters and utilities 109.

[0047] The NFV and SDN design functions 103 may include specific roles, responsibilities, and capabilities that are deployed through hardware, software, or a combination thereof, providing complementary technology to reshape or managenetwork transactions (specifically for orchestrating the CNF operations). Preferably, the NFV and SDN design functions 103 may include design function(s) specific to role(s) of the NFV (i.e., for visualizing network services) and design function(s) specific to the role(s) of the SDN (i.e., providing programmable and / or centralized control of the network to connect the network services efficiently).

[0048] The platform foundation services 105 may include circuitry, codes, or a combination thereof, to provide an operational platform (e.g., through operational functions) for a cloud or application platform. The platform foundation services 105 may enable higher-level applications and workloads to run reliably, securely, and efficiently. Preferably, the platform foundation services 105 may correspond to network services such as, but not limited to, compute services, storage services, network services, identity and access management services, security and compliance services, monitoring and logging services, and resource management and orchestration services.

[0049] The platform core services 107 may be essential, higher-level services built on top of foundation services that enable application development, integration, and management on a cloud or enterprise platform, deployed through hardware-software combination. Specifically, the platform services 107 may be associated with application runtime management, database / storage and its management, messaging and technology integration, analytics and data processing, developer tools and their management, and policy enforcement, compliance, and its governance, etc.

[0050] The platform resource adapters and utilities 109 may be operational components within the cloud or enterprise platform, deployed through hardware circuitry, software, or a combination thereof, supporting integration, management, and optimization of resources and network services. Specifically, the platform resource adapters and utilities 109 may be software components that act as connectors or interfaces to enable communication in heterogeneous environments. More specifically, the platform resource adapters and utilities 109 may translate Application Programming Interface (API) calls into resource- specific commands,handle differences in protocols associated with different network services, and provide resource abstraction (i.e., abstract details of the resources).

[0051] Particularly, the architecture framework 100 includes new management blocks including a Container Network Function Lifecycle Manager (CNFLM) 121 and a Universal Cloud Service Executor (UCSE) 169 on the top of existing Network function virtualization management and orchestration (NFV MANO) architectural framework. Further, the architecture framework 100 proposes an interface (CM_UCS interface) that serves as a critical link between the CNFLM 121 and the UCSE 169. The description of those components of architecture framework 100 which are common in the existing NFV MANO architectural framework is not provided for the sake of brevity of the disclosure.

[0052] The CNFLM 121 may be a specialized orchestrator for container-based network functions, translating CNF lifecycle operations into native actions for container orchestration platform (e.g., Kubernetes) designed to automate the deployment, scaling, and management of containerized applications. The CNFLM 121 may include circuitry, software, or a combination thereof, to support deployment, management, scaling, healing, upgrading, and decommissioning of CNFs in accordance with telecommunication standards.

[0053] The UCSE 169 may be a network component in cloud-native environment as presented through the architectural framework 100 configured to abstract and manage execution of tasks or workflows on cloud infrastructure for managing the operations of the CNF orchestration. The USCE 169 may further be configured to manage resource allocation at deployment site(s) for operations corresponding to the CNF orchestration. In some aspects of the present disclosure, the UCSE 169 may act as an interface between the CNFLM 121 and the deployment sites for CNF orchestration.

[0054] The user interface 101 provides a User Interface (UI) to a user to initiate request for the CNF operations. The CNFLM 121 receives the request for the CNFoperations from the user interface 101. It is to be noted that the user interface 101 may also be referred to as the UI 101 interchangeably throughout this disclosure without departing from the scope of the disclosure.

[0055] The NVF & SDN design functions 103 are configured to manage and orchestrate Virtualized Network Functions (VNFs) and other software components. The NVF & SDN design functions 103 includes a Virtualized Network Functions Lifecycle Manager (VNFLM) 111, VNF catalog 113, network services catalog 115, a network slicing & service changing manager 117, physical & virtual resource manager 119, and the CNFLM 121.

[0056] The VNFLM 111 may manage complete lifecycle of the VNFs, including instantiation, scaling, and termination. The VNF catalog 113 is a repository containing standardized descriptions, metadata, and deployment templates of available VNFs for orchestration and reuse. The network services catalog 115 a repository that may contain service descriptors and deployment rules. The network slicing & service changing manager 117 may create and manage logical network slices and orchestrates service chains by linking the VNFs to deliver end-to-end services. The physical & virtual resource manager 119 may allocate, monitor, and optimize physical resources across physical infrastructure and virtualized environments.

[0057] The CNFLM 121 may be a microservice that may capture details of vendors, CNFs, and CNFCs via create, read, and update APIs. The captured details are stored in a database 149 and may be further used by the UCSE 169. The CNFLM 121 is responsible for creating or terminating the CNF. Also, the CNFLM 121 is responsible for scaling of CNFs. In a non-limiting example, the database 149 may include Not only SQL Database (NoSQL DB).

[0058] The platform foundation services 105 provides essential services and infrastructure for the architecture framework 100. The platform foundation services 105 includes microservices elastic load balancer 123, an identity & access manager125, Command Line Interface (CLI) 127, a central logging manager 129, an event routing manager 131.

[0059] The microservices elastic load balancer 123 may dynamically distributes incoming traffic across multiple microservice instances to ensure scalability, fault tolerance, and high availability. The identity & access manager 125 may control authentication, authorization, and user access policies across the architecture framework 100. The CLI 127 may be a text-based tool that allows network operator to interact with the platform, execute commands, and manage resources. The central logging manager 129 may collect, store, and manage logs from different components of the of the communication network for monitoring, troubleshooting, and compliance. The event routing manager 131 may direct and deliver events between services, enabling asynchronous communication and real-time responsiveness.

[0060] The platform core services 107 are the foundation services responsible for orchestrating and managing the CNF. The platform core services 107 includes NFV infrastructure monitoring manager 133, assurance manager 135, performance manager 137, policy execution engine 139, capability monitoring manager 141, release management repository 143, configuration manager & GCT 145, NFV platform decision analytics 147, the database 149, platform schedulers & cron jobs 151, a VNF backup & upgrade manager 153, micro service auditor 155, and a Platform Operations, Administration, and Maintenance Manager (hereinafter interchangeably referred to as ‘POAM’) 157.

[0061] The NFV infrastructure monitoring manager 133 may monitor resources in NFV infrastructure to ensure availability and performance. The assurance manager 135 may validate service quality and compliance with SLAs. The performance manager 137 may track and analyze CNF performance metrics such as throughput, latency, and resource utilization. The policy execution engine 139 may enforce predefined policies across CNFs and infrastructure components. The capabilitymonitoring manager 141 may observe functional capabilities of CNFs to detect degradation, anomalies, or compliance gaps. The release management repository 143 may store and manage CNF software versions, updates, and release artifacts for controlled deployment. The configuration manager & GCT 145 may store and manage CNF configuration applies standardized templates to ensure consistency. The NFV platform decision analytics 147 may provide data-driven insights and recommendations for the resource allocation, scaling, and optimization. The platform schedulers & cron jobs 151 may automates recurring tasks such as backups, monitoring checks, and resource updates within the CNF platform. The VNF backup & upgrade manager 153 may manage backup, restoration, and controlled upgrades of VNFs. The micro service auditor 155 may audit microservices within CNF deployments.

[0062] The POAM 157 may provide a centralized tools for day-to-day operations, administration, and maintenance of the CNF platform. The POAM 157 connects with CNFLM 121 and UCSE 169. The POAM 157 provides available CNFLM instance and load balancer details to the CNFLM 121. Also, the POAM 157 provides available UCSE instance and the load balancer details to the UCSE 169. The POAM 157 receives the load balancer details from the microservices elastic load balancer 123.

[0063] The platform resource adapters and utilities 109 comprises one or more platform adapters as a software component to allow the architecture framework 100 to interface with external resource providers, cloud environment, and infrastructure platforms. Further, the platform resource adapters and utilities 109 comprises one or more supporting tools and services for the function of the components of the architecture framework 100. The platform resource adapters and utilities 109 includes platform external API adapter and gateway 159, generic decoder and indexer 161, docker swarm adapter 163, open stack API adapter 165, NFV gateway 167, and the UCSE 169.

[0064] The platform external API adapter and gateway 159 may be an interface that enables the architecture framework 100 to communicate securely with external APIs and resource providers. The generic decoder and indexer 161 may parse, decode, and index heterogeneous data formats for standardized processing. The docker swarm adapter 163 may integrate the architecture framework 100 with docker swarm clusters, enabling container orchestration and workload management. The open stack API adapter 165 is a connector that may allow the architecture framework 100 to interact with cloud environments for provisioning and managing virtualized resources. The NFV gateway 167 corresponds to a gateway component that bridges the platform with NFV infrastructure, enabling interoperability and service delivery across the virtualized network functions.

[0065] The UCSE 169 may connect with container platform managers of container infrastructure setup to deploy all CNFCs on eligible host nodes. Further, the UCSE 169 connect with the POAM 157 to receive available UCSE instance and the load balancer details. The UCSE 169 interacts with the CNFLM 121 via the CM_UCS interface that serves as the link between the CNFLM 121 and the UCSE 169. The UCSE 169 spawn the available UCSE instances in a container infrastructure 203 (as shown later in FIG 2).

[0066] FIG. 2 illustrates a block diagram depicting an operational environment 200 including an interface between the CNFLM 121 and the UCSE 169, in accordance with an embodiment of the present disclosure. The operational environment 200 includes the User Interface 101, the CNFLM 121 and the UCSE 169 coupled through the interface (CM_UCS Interface), the database 149, a Network Management System (NMS) 201, and a container infrastructure 203. The CNFLM 121 and the UCSE 169 may be communicatively coupled to the various other components of the operational environment 200.

[0067] As shown in the FIG. 2, the CNFLM 121 connects with the UCSE 169 using the interface (CM_UCS interface). The CM_UCS interface serves as a critical link between the CNFLM 121 and the UCSE 169 for orchestrating CNF operationseffectively. The CM_UCS interface facilitates CNF and site monitoring, ensuring that lifecycle operations are executed efficiently, thus supporting stable operation of cloud-native functions.

[0068] The NMS 201 may include operational components that may be realized through hardware, software, or a combination of hardware and software components to provides a foundation to implement Operations Support Systems (OSS) architectures. The NMS 201 enables service providers to rapidly deploy new services and meet stringent Quality of Service requirements.

[0069] The container infrastructure 203 may include resource site(s) at various deployment region(s) for orchestration of the CNFs. In some aspects of the present disclosure, the container infrastructure 203 may be considered as a pool of data centers, at one or more regions (or deployment sites), having data storage resources, data management resources and / or data processing resources, that may be utilized for orchestration of the CNFs (i.e., instantiation of the CNFs, termination of the CNFs, and / or scaling of the CNFs).

[0070] FIG. 3 illustrates a block diagram depicting exemplary components of the CNFLM 121, in accordance with an embodiment of the present disclosure. The CNFLM 121 may include a communication interface 300, an Input-Output (I / O) interface 301, a console host 302, processing circuitry 304, and a memory unit 306. Various components of the CNFLM 121 may be communicatively coupled to each other via a first communication bus 307.

[0071] The communication interface 300 may be configured to enable the CNFLM 121 to communicate with various entities of the system 400 via the network 106. Examples of the communication interface 300 may include, but are not limited to, a modem, a network interface such as an Ethernet card, a communication port, and / or a Personal Computer Memory Card International Association (PCMCIA) slot and card, an antenna, a radio frequency (RF) transceiver, amplifier(s), a tuner, oscillator(s), a digital signal processor, a coder-decoder (CODEC) chipset, asubscriber identity module (SIM) card, and a local buffer circuit. It will be apparent to a person of ordinary skill in the art that the communication interface 300 may include any device and / or apparatus capable of providing wireless or wired communications between the CNFLM 121 and various other entities of the system 400.

[0072] The I / O interface 301 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on the CNFLM 121. For example, the I / O interface may have an input interface and an output interface. The input interface may be configured to enable a user to provide input(s) to trigger (or configure) the CNFLM 121 to perform various operations for orchestrating CNF operation by providing user inputs, managing notifications, and giving instructions to initiate, terminate or scale the CNF instances. Preferably, the CNF operations may include CNF instantiation operation(s), CNF termination operation(s), CNF scaling operation(s), and CNF management operation(s). Examples of the input interface may include, but are not limited to, a touch interface, a mouse, a keyboard, a motion recognition unit, a gesture recognition unit, a voice recognition unit, or the like. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface including known, related art, and / or later developed technologies without deviating from the scope of the present disclosure. The output interface may be configured to display (or present) output(s) by the CNFLM 121 such as, but not limited to details of the CNF instance may it be a successful instance or a failed instance. In some aspects of the present disclosure, the output interface may provide the output(s) based on an instruction provided via the input interface. Examples of the output interface of the I / O interface 301 may include, but are not limited to, a digital display, an analog display, a touch screen display, an appearance of a desktop, and / or illuminated characters.

[0073] The console host 302 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to enable the I / O interface 301 to receive input(s)and / or present output(s). In some aspects of the present disclosure, the console host 302 may include suitable logic, instructions, and / or codes for executing various operations of one or more computer executable applications to host a console on an external user device (not shown) coupled to the UI 101, by way of which a user can trigger the CNFLM 121 for operation(s) associated with orchestration of the CNF. In some other aspects of the present disclosure, the console host 302 may provide a Graphical User Interface 101 for the CNFLM 121 for user interaction.

[0074] The processing circuitry 304 may include data processor(s) (e.g., data processing modules) as presented in FIG. 3. According to an exemplary embodiment, the processing circuitry 304 may include a transceiver module 308, a processing module 310, an update module 312, a validation module 314, and a notification module 316, coupled to each other by way of a second communication bus 319.

[0075] The transceiver module 308 may be configured to enable transfer of data from the memory unit 306 to various modules of the processing circuitry 304. The transceiver module 308 may further be configured to enable a transfer of the input data from the UI 101 to the CNFLM 121. Furthermore, the transceiver module 308 may be configured to enable transfer of the data and / or instructions between various other modules of the processing circuitry 304.

[0076] Particularly, the transceiver module 308 may be configured to receive a CNF orchestration request (specifically from the UI 101). The CNF orchestration request corresponds to a CNF operation for orchestrating the CNF. In some aspects of the present disclosure, the CNF operations may correspond to a CNF instantiation operation, a CNF termination operation, or a CNF scaling operation. Furthermore, the transceiver module 308 may be configured to transmit the CNF orchestration request to the validation module 314. Preferably, the CNF orchestration request comprises CNF data including CNF descriptor(s) (indicating properties of the CNF for orchestration such as network function name, version, vendor information, deployment artifacts, resource requirement details, and connectivity requirementdetails, etc.), lifecycle operation details (indicating a type of operation such as instantiation, termination, scaling, or management), and details of resource and placement constraints (indicating characteristics of deployment sites in the container infrastructure 203 suitable for orchestration of CNFs in accordance with the orchestration request), etc. The validation module 314 may be configured to receive the CNF orchestration request from the transceiver module 308 and check a validity of the CNF orchestration request. Particularly, the validation module 314 may be configured to determine the validity of CNF data in the CNF orchestration request for the orchestration of the CNF in the container infrastructure. Preferably, the CNF data includes data objects corresponding to the CNF to be orchestrated at a deployment site (as shown later in FIG. 4) of the container infrastructure. For example, the validation module 314 may determine whether the CNF data includes data objects required for the orchestration of the CNF in the container infrastructure (e.g., the CNF descriptor(s), the lifecycle operation details, and the details of the resource and placement constraints, etc.). Moreover, the validation module 314 may also be configured to assess whether the CNF descriptor(s) includes data essential to identify the network function (such as name, version, vendor information, deployment artifacts, resource requirement details, and connectivity requirement details, etc.), sufficient details of the lifecycle operations (such as type of orchestration operation for the CNF), and data associated with the resource and placement constraints. In an aspect of the present disclosure, the validation module 314 may compare the CNF data with a predefined set of identifiers associated with the orchestration of the CNFs in the container infrastructure 203 to identify whether the CNF orchestration request is valid or invalid. Based on the determination that the CNF orchestration is valid, the validation module 314 may trigger the transceiver module 308 for further operations.

[0077] The transceiver module 308 may also be configured to fetch a resource availability status of the container infrastructure from the database 149. The resource availability status indicates the resource in the container infrastructure 203 being available or unavailable for orchestration of the CNF. For example, anavailability of the resource at the container infrastructure 203 (at a desired deployment site) for instantiation of the CNF (through the orchestration request i.e., instantiation request) indicates that the resources of the deployment site at the container infrastructure 203 are unoccupied / idle and can be utilized for instantiation of the CNF based on the orchestration request. Similarly, an unavailability of the resource at the container infrastructure 203 (at the desired deployment site) for instantiation of the CNF (through the orchestration request i.e., the instantiation request) indicates that the resources of the deployment site at the container infrastructure 203 are occupied by another CNFs / unavailable for instantiation of the CNF and cannot be utilized for instantiation of the CNF based on the orchestration request. In a similar manner, the resource availability status also indicates whether operations associated with a termination request or scaling request can be performed by the container infrastructure 203. In some aspects of the present disclosure, to fetch the resource availability status of the container infrastructure 203, the transceiver module 308 may be configured to transmit a status request to the database 149 corresponding to the CNF orchestration received from the user interface 101. Moreover, the transceiver module 308 may also be configured to receive a response to the status request from the database 149. The response received from the database 149 may correspond to a positive or a negative response. In an exemplary scenario, when the CNF orchestration request corresponds to CNF instantiation or CNF scaling, the positive response received from the database 149 may correspond to the hosting servers being idle, and the negative response received from the database 149 may correspond to the hosting servers being occupied. In another exemplary scenario, when the CNF orchestration request corresponds to CNF termination, the positive response received from the database 149 may correspond to the hosting servers being occupied, and the negative response received from the database 149 may correspond to the hosting servers (i.e., resources at the deployment sites in the container infrastructure 203) being idle.

[0078] The transceiver module 308, based on the determination that the resource is available for the orchestration of the CNF (i.e., the response received from thedatabase 149 is positive) may be configured to transmit a CNF orchestration trigger to the UCSE 169 using an interface between the CNFLM 121 and the UCSE 169. Preferably, the CNF orchestration trigger initiates the orchestration of the CNF in the container infrastructure corresponding to the CNF orchestration request. The interface between the CNFLM 121 and UCSE 169 may provide monitoring of an execution lifecycle of the CNF operation in the container infrastructure 203 corresponding to the CNF orchestration request. The execution lifecycle may indicate a status of execution of operations corresponding to the CNF orchestration request at the container infrastructure 203 for orchestration of the CNF. Preferably, the monitoring of execution lifecycle results in determining whether the orchestration succeeded or failed. In an exemplary scenario, the execution lifecycle may indicate a percentage of completion of the CNF orchestration at the container infrastructure 203.

[0079] The processing module 310 may be configured to receive a CNF orchestration response from the UCSE 169 indicating the status of execution of the CNF orchestration at the container infrastructure 203. The processing module 310 may also be configured to identify whether the CNF orchestration response corresponds to an acknowledgement for CNF orchestration at the container infrastructure 203 or error(s) in execution of the CNF orchestration request at the container infrastructure. Errors in the execution of CNF orchestration request may occur during the lifecycle management of CNFs such as onboarding, instantiation, scaling, healing, upgrading, or termination. These error(s) may be associated with infrastructure issues, configuration mismatches, orchestration logic flaws, and / or Kubemetes-level failures. Specifically, for instantiation of the CNF, the errors may be associated with resource failure, network failure, or CNF registration failure, etc.). For CNF update, the errors may be associated with configuration changes (e.g., incompatible old configuration) or roll-back issues (e.g., missing of all or part of previous CNF data required for continued operation). For termination of the CNF, the errors may be associated with resource clean-up failure (i.e., issues with network pods, services, or interfaces) and / or detangling persistent volumes (i.e., resourcesnot released for termination of the CNF due to storage issues). For scaling operations, the errors may be associated with horizontal pod auto-scaler misconfiguration (i.e., unavailability of metrics server for scaling) and / or exceed in cluster limit of resources at the deployment site in the container infrastructure. As will be apparent to a person ordinarily skilled in the art, the abovementioned are mere examples of the errors that can appear and does not limit the scope of the present disclosure. Any errors that may occur during any operation included in the orchestration of the CNF(s) in the container infrastructure 203 must therefore be included as the error(s) in execution of the CNF orchestration request, without deviating from the scope of the present disclosure. In some aspects of the present disclosure, the CNF orchestration response may be CNF orchestration acknowledgement corresponding to a successful orchestration of the CNF in the container infrastructure or a CNF orchestration error corresponding to a failed orchestration of the CNF in the container infrastructure 203. The update module 312 may be configured to update the database 149 for the CNF orchestration request, based on a CNF orchestration response for the CNF orchestration request, received from the UCSE 169 corresponding to the orchestration of the CNF in the container infrastructure 203.

[0080] The notification module 316 may be configured to render the update of the database 149 for the CNF orchestration. The notification module 316 may further be configured to first error notification based on a determination that the resource is available for the orchestration of the CNF. Furthermore, the notification module 316 may be configured to render a second error notification indicating the CNF orchestration error corresponding to the failed orchestration of the CNF in the container infrastructure. Furthermore, the notification module 316 may be configured to render a third error notification when the CNF data is found invalid for the orchestration of the CNF in the container infrastructure. In a preferred embodiment, the notifications (i.e., cumulatively referring to the update, the first error notification, the second error notification, and the third error notification) are rendered through the UI 101.

[0081] Various modules of the processing circuitry 304 are presented to illustrate the functionality driven by the CNFLM 121. It will be apparent to a person having ordinary skill in the art that various modules in the processing circuitry 304 are for illustrative purposes and not limited to any specific combination of hardware circuitry and / or software.

[0082] The memory unit 306 may be configured to store data corresponding to the system 400. In some aspects of the present disclosure, the memory unit 306 may be segregated into multiple repositories that may be configured to store a specific type of data. In the exemplary embodiment as presented through FIG. 3, the memory unit 306 includes instructions repository 320, and a data repository 324.

[0083] The instructions repository 320 is configured to store instructions and / or codes for operation(s) of various components of the CNFLM 121, particularly as instruction objects 322. The data repository 324 is configured to store data generated and / or acquired by the various components of the CNFLM 121, particularly as data objects 326. The data objects 326 may further store data required by the modules to generate triggers or requests.

[0084] In some embodiments of the present disclosure, the instructions repository 320 is configured to store computer program instructions and / or codes for operation(s) of various components of the processing circuitry 304. For example, the instructions repository 320 may be configured to store computer program instructions corresponding to the operation(s) performed by the processing circuitry 304 for orchestrating the CNF in the container infrastructure, as presented through the various engines in the processing circuitry 304. In an embodiment of the present disclosure, the instructions repository 320 may be configured as a non-transitory storage medium. Examples of the instructions repository 320 configured as the non- transitory storage medium includes hard drives, solid-state drives, flash drives, Compact Disk (CD), Digital Video Disk (DVD), and the like. Aspects of the present disclosure are intended to include or otherwise cover any type of non-transitorystorage medium as the instructions repository 320, without deviating from the scope of the present disclosure. As will be appreciated, any such computer program instructions stored in the instructions repository 320 may be executed by one or more computer processors, including without limitation a general-purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for implementing the function(s) specified.

[0085] It will be apparent to a person of ordinary skill in the art that the repositories in the memory unit 306 are presented based on the functionality of the CNFLM 121 and are not limited to those disclosed. The memory unit 306 may have any configuration, combination and / or count of repositories without deviating from the scope of the present disclosure. Although FIG. 3 illustrates one example of the CNFLM 121, various changes may be made to FIG. 3. Further, the CNFLM 121 may include any number of components in addition to those shown in FIG. 3, without deviating from the scope of the present disclosure. Further, various components in FIG. 3 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.

[0086] FIG. 4 illustrates a block diagram depicting exemplary components of a system 400 for orchestrating the CNF operations performed by the components of the CNFLM 121 as presented in FIG. 3, in accordance with an embodiment of the present disclosure.

[0087] The system 400 includes the user interface 101, the CNFLM 121, and the UCSE 169. The the CNFLM 121 is connected with the database 149 to receive the details of vendors, CNFs, and CNFCs via create, read, and update APIs. The UCSE 169 is connect with the container platform managers 405-1, 405-2, 405-n(hereafter may be referred to as “container platform managers 405”) of the container infrastructure 203 (as shown in FIG. 2) to deploy all the CNFCs on the eligible host nodes.

[0088] The CNFLM 121 may include processor(s) to perform one or more operations associated with orchestration of the CNFs at the container infrastructure 203. The processor(s) may include one or more general purpose processors and / or one or more special purpose processors, a microprocessor, a digital signal processor, an application specific integrated circuit, a microcontroller, a state machine, or ay any type of programmable logic array.

[0089] The CNFLM 121 may receive a request to orchestrate a CNF operation among the CNF operations. The CNF operations include a CNF instantiation operation, a CNF termination operation, and a CNF scaling operation. The CNFLM 121 receives the request from the user interface 101.

[0090] Further, upon receiving the request, the CNFLM 121 may send a request to the database 149 to one of reserve resources in the database 149 or fetch resource data from the database 149. The CNFLM 121 may send the request for reserving the resources in the database 149 if the CNF operation is the CNF instantiation operation or the CNF scaling operation. Further, the CNFLM 121 may send the request for fetching resource data from the database 149 if the CNF operation is the CNF termination operation.

[0091] Thereafter, the CNFLM 121 may forward the request for the CNF operation to UCSE 169 using the CM_UCS interface. For instance, the CNFLM 121 prepares data for the operations and sends the data to the UCSE 169 for execution.

[0092] Further, the CNFLM 121 receives a response on the request from the UCSE 169. The UCSE 169 performs the CNF operation and sends the response of the CNF operation to the CNFLM 121. The UCSE 169 directly connect to the container platform managers 405 of the container infrastructure 203 to deploy all CNFCs on eligible host nodes. The UCSE 169 also verifies that if a particular host node is part of a site at the time of site creation. If verification fails, that node becomes ineligible for the CNF operations related to that site.

[0093] Further, the CNFLM 121 may update inventory in the database 149 based on the received response from the UCSE 169. The CNFLM 121 may also display the response to the user via the user interface 101.

[0094] FIG. 5 illustrates a process flow diagram depicting a process 500 for orchestrating the CNF instantiation operation, in accordance with an embodiment of the present invention. The process 500 is presented through process steps 501 through 511, i.e., performed by the components of the system 400 as presented in FIG. 4.

[0095] At step 501, the user inputs a request for the CNF instantiation operation on the UI 101. At step 502, the CNFLM 121 may receive the request for the CNF instantiation operation (i.e., CNF instantiation request) from the UI 101. The CNFLM 121 may validate the CNF data included in the CNF instantiation request and send a request to the database 149 to reserve the resources in the database 149 upon successful validation of the CNF data, at step 503. At step 504, the CNFLM 121 may receive a response from the database 149.

[0096] At step 505, the CNFLM 121 may forward the CNF instantiation request for the CNF instantiation operation to the UCSE 169 using the CM_UCS interface. At step 506, the UCSE 169 may connect to the container platform managers 405 of the container infrastructure 203 to deploy the CNF on the deployment site(s) in the container infrastructure. At step 507, the UCSE 169 may receive a status of the CNF instantiation operation from the container infrastructure 203.

[0097] At step 508, the UCSE 169 may send the response on the CNF instantiation operation to the CNFLM 121. The UCSE 169 may send an instantiation acknowledgement to the CNFLM 121 through the CM_UCS interface indicating completion of the CNF instantiation request for the CNF instantiation operation.

[0098] At step 509, the CNFLM 121 may trigger the database 509 to update the inventory based on the received response from the UCSE 169 (i.e., related to thestatus of instantiation of the CNF at the container infrastructure 203. At step 510, the CNFLM 121 may receive a response from the database 149 indicating the update in the database 149. At step 511, the CNFLM 121 may send the instantiation acknowledgment to the user. For instance, the CNFLM 121 may display an acknowledgement to the user via the UI 101.

[0099] FIG. 6 illustrates a process flow diagram depicting a process 600 for orchestrating the CNF termination operation, in accordance with an embodiment of the present invention. The process 600 is presented through process steps 601 through 611 i.e., performed by the components of the system 400 as presented in FIG. 4.

[0100] At step 601, the user inputs a request for the CNF termination operation on the UI 101. At step 602, the CNFLM 121 may receive the request for the CNF termination operation (i.e., CNF termination request) from the UI 101. The CNFLM 121 may validate the CNF data included in the CNF termination request and send a request to the database 149 to fetch the resource data in the database 149 upon successful validation of the CNF data, at step 603. At step 604, the CNFLM 121 may receive a response from the database 149.

[0101] At step 605, the CNFLM 121 may forward the CNF termination request for the CNF termination operation to the UCSE 169 using the CM_UCS interface. At step 606, the UCSE 169 may connect to the container platform managers 405 of the container infrastructure 203 to termination the CNF. At step 607, the UCSE 169 may receive a status of the CNF termination operation from the host node(s) (i.e., the deployment site(s)) container infrastructure 203.

[0102] At step 608, the UCSE 169 may send the response on the CNF termination operation to the CNFLM 121. The UCSE 169 may send a termination acknowledgement to the CNFLM 121 through the CM_UCS interface indicating completion of the CNF termination request for the CNF termination operation.

[0103] At step 609, the CNFLM 121 may trigger the database 149 to update records of the CNF in the inventory to indicate the resource availability status for the host node(s) in the container infrastructure 203 based on the received response from the UCSE 169. At step 610, the CNFLM 121 may receive a response from the database 149 indicating the update in the database 149. At step 611, the CNFLM 121 may send the termination acknowledgment to the user. For instance, the CNFLM 121 may display an acknowledgement to the user via the UI 101.

[0104] FIG. 7 illustrates a process flow diagram depicting a process 700 for orchestrating the CNF scaling operation, in accordance with an embodiment of the present invention. The process 700 is presented through process steps 701 through 711, i.e., performed by the components of the system 400 as presented in FIG. 4.

[0105] At step 701, the user input a request for the CNF scaling operation on the UI 101. At step 702, the CNFLM 121 may receive the request for the CNF scaling operation (i.e., CNF scaling request) from the UI 101. The CNFLM 121 may validate the CNF data included in the CNF scaling request (corresponding to adjustment of number of container instances (pods) for the CNF already deployed at the container infrastructure 203, i.e., re-instantiation with different configuration) and send a request to the database 149 to reserve the resources in the database 149 upon successful validation of the data, at step 703. At step 704, the CNFLM 121 may receive a response from the database 149.

[0106] At step 705, the CNFLM 121 may forward an instantiation request corresponding to the CNF scaling request to instantiate the CNFs to the UCSE 169 using the CM_UCS interface. At step 706, the UCSE 169 may connect to the container platform managers 405 of the container infrastructure 203 to deploy the CNF on the deployment site in the container infrastructure 203. At step 707, the UCSE 169 may receive a status of the CNF scaling operation from the container infrastructure 203.

[0107] At step 708, the UCSE 169 may send the response on the CNF scaling operation to the CNFLM 121 through the CM_UCS interface. The UCSE169 may send the instantiation acknowledgement to the CNFLM 121 indicating completion of the instantiation request for the CNF scaling operation.

[0108] At step 709, the CNFLM 121 may trigger the database 149 to update the inventory based on the received response from the UCSE 169 (i.e., related to the status of instantiation of the CNF at the container infrastructure 203). At step 710, the CNFLM 121 may receive a response from the database 149 indicating the update in the database 149. At step 711, the CNFLM 121 may send a scaling acknowledgment to the user. For instance, the CNFLM 121 may display an acknowledgement to the user via the UI 101.

[0109] FIG. 8 is a flow chart depicting a method 800 for orchestrating the CNF operations, in accordance with an embodiment of the present disclosure. The method 800 is presented through operational blocks depicting operational steps performed by the components of the system 400 (specifically by the CNFLM 121 and the UCSE 169), as discussed in the description of FIG. 3 through FIG. 7, for orchestrating the CNF operations in the container infrastructure 203. As will be apparent to a person of ordinary skill in the art, the operations are present in brief for the sake of brevity through the blocks 802 through 824, however, the scope of the operations is defined through the specification of the CNFLM 121, as discussed in FIG. 3 through FIG. 7, as presented herein.

[0110] At block 802, the CNFLM 121, preferably by way of the transceiver module 308, may receive the CNF orchestration request (preferably from the UI 101). The CNF orchestration request may correspond to the CNF operation for orchestrating the CNF. In some aspects of the present disclosure, the CNF operation may be one of, the CNF instantiation operation, the CNF termination operation, the CNF scaling operation, or the CNF management operation.

[0111] At block 804, the CNFLM 121, preferably by way of the validation module 314, may determine the validity of the CNF orchestration request (specifically the CNF data) for the orchestration of the CNF in the containerinfrastructure 203, as discussed in FIG. 3. When the CNFLM 121 determines that the CNF data in the CNF orchestration request is valid for the orchestration of the corresponding CNF in the container infrastructure 203, the method 800 proceeds to block 808. Else, when the CNFLM 121 determines that the CNF data in the CNF orchestration request is invalid for the orchestration of the corresponding CNF in the container infrastructure 203, the method 800 proceeds to block 806.

[0112] At block 806, the CNFLM 121, preferably by way of the transceiver module 308, may transmit the third error notification rendering that the CNF data in the CNF orchestration request is found invalid for the orchestration of the CNF in the container infrastructure 203. Thereafter, the method 800 halts.

[0113] At block 808, in response to the determination that the CNF data in the CNF orchestration request is found valid for the orchestration of the corresponding CNF in the container infrastructure, the CNFLM 121, preferably by way of the transceiver module 308, may fetch the resource availability status of the container infrastructure from the database 149. The resource availability status indicates the resource in the container infrastructure203 being available or unavailable for orchestration of the CNF.

[0114] At block 810, based on the resource availability status, the CNFLM 121, preferably by way of the processing module 310, may determine whether the resource at the container infrastructure 203 is available or unavailable for the orchestration of the CNF. When the CNFLM 121 determines that the resource is available (e.g., response to the status request is positive), the method 800 proceeds to block 814. Else, when the CNFLM 121 determines that the resource is unavailable (e.g., the response to the status request is negative), the method 800 proceeds to block 812.

[0115] At block 812, the CNFLM 121, preferably by way of the notification module 316, may generate and render the first error notification through the UI 101 indicating that the resource at the container infrastructure 203 (i.e., the requesteddeployment site) is unavailable for orchestration of the CNF of the CNF orchestration request. In some aspects of the present disclosure, the first error notification may indicate an error either at the database 149 or in the CNF orchestration request corresponding to an engagement of a resource requested in the CNF orchestration request. Thereafter, the method 800 halts.

[0116] At block 814, the CNFLM 121, preferably by way of the transceiver module 308, may transmit the CNF orchestration trigger to the UCSE 169 using the interface between the CNFLM and the UCSE (i.e., the CM_UCS Interface, as shown in FIG. 3). In some aspects of the present disclosure, the CNF orchestration trigger initiates the orchestration of the CNF in the container infrastructure corresponding to the CNF orchestration request. The CM_UCS Interface provides monitoring of the execution lifecycle of the CNF operation corresponding to the CNF orchestration request in the container infrastructure 203.

[0117] At block 816, the CNFLM 121, preferably by way of the transceiver module 308, may receive the CNF orchestration response for the orchestration request from the UCSE 169 corresponding to the orchestration of the CNF in the container infrastructure 203.

[0118] At block 818, based on the CNF orchestration response, the CNFLM 121, preferably by way of the processing module 310, may determine whether the operations corresponding to CNF orchestration associated with the CNF orchestration request executed successfully or failed. When the CNFLM 121 determines that the CNF orchestration failed, the method 800 proceeds to block 820. Else, when the CNFLM 121 determines that the CNF orchestration succeeded, the method 800 proceeds to block 822.

[0119] At block 820, the CNFLM 121, preferably by way of the transceiver module 308, may render the second error notification (preferably through the UI 101) indicating that the CNF orchestration error corresponding to the failedorchestration of the CNF in the container infrastructure 203. Thereafter, the method 800 halts.

[0120] At block 822, the CNFLM 121, preferably by way of the update module 312, may update the database 149 for the CNF orchestration.

[0121] At block 822, the CNFLM 121, preferably by way of the notification module 316, may generate the notification trigger for the UI 101 rendering the update of the database 149 for the CNF orchestration.

[0122] FIG. 9 is a flow chart depicting another method 900 for orchestrating the CNF operations in the container infrastructure 203, in accordance with an embodiment of the present disclosure. The method 900 is presented through operational blocks depicting operational steps performed by the components of the system 400 (specifically by the CNFLM 121 and the UCSE 169), as discussed in the description of FIG. 3 through FIG. 7, for orchestrating the CNF operations in the container infrastructure 203. As will be apparent to a person of ordinary skill in the art, the operations are present in brief for the sake of brevity through the blocks 902 through 908, however, the scope of the operations is defined through the specification of the CNFLM 121, as discussed in FIG. 3 through FIG. 7, as presented herein.

[0123] At block 902, the CNFLM 121, preferably by way of the transceiver module 308, may receive the CNF orchestration request (preferably from the UI 101). The CNF orchestration request may correspond to the CNF operation for orchestrating the CNF. In some aspects of the present disclosure, the CNF operation may be one of, the CNF instantiation operation, the CNF termination operation, the CNF scaling operation, or the CNF management operation.

[0124] At block 904, the CNFLM 121, preferably by way of the transceiver module 308, may fetch the resource availability status of the container infrastructure 203 from the database 149. The resource availability status indicates a resource inthe container infrastructure 203 being available or unavailable for orchestration of the CNF.

[0125] At block 906, the CNFLM 121, preferably by way of the transceiver module 308, may transmit the CNF orchestration trigger to the UCSE 169 using the interface between the CNFLM 121 and the UCSE 169 based on the determination that the resource is available for the orchestration of the CNF.

[0126] At block 908, the CNFLM 121, preferably by way of the update module 312, may update the resource availability status of the container infrastructure 203 in the database 149 based on the CNF orchestration response for the CNF orchestration request received from the UCSE 169 corresponding to the orchestration of the CNF in the container infrastructure 203.

[0127] FIG. 10 illustrates an exemplary computer system 1000 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 10, the computer system 1000 may include a bus 1010, a processing unit 1020, a main memory 1030, a Read Only Memory (ROM) 1040, a storage device 1050, an input device 1060, an output device 1070, and a communication interface 1080. The bus 1010 may include a path that permits communication among the other components of the computer system 1000.

[0128] The processing unit 1020 may include one or more processors or microprocessors which may interpret and execute stored instructions associated with one or more processes, or processing logic that implements the one or more processes. For example, the processing unit 1020 may include, but is not limited to, programmable logic such as Field Programmable Gate Arrays (FPGAs) or accelerators. The processing unit 1020 may include software, hardware, or a combination of software and hardware for executing the processes described herein.

[0129] The main memory 1030 may include a random-access memory (RAM) or another type of dynamic storage device that may store information and,in some implementations, instructions for execution by the processing unit 1020. The ROM 1040 may include a ROM device or another type of static storage device (e.g., Electrically Erasable Programmable ROM (EEPROM)) that may store static information and, in some implementations, instructions for use by the processing unit 1020.

[0130] The storage device 1050 may include a magnetic, an optical, and / or a solid state (e.g., flash drive) recording medium and its corresponding drive. The main memory 1030, the ROM 140 and the storage device 1050 may each be referred to herein as a “non-transitory computer-readable medium” or a “non-transitory storage medium.” The process / methods set forth herein can be implemented as instructions that are stored in the main memory 1030, the ROM 1040 and / or the storage device 1050 for execution by the processing unit 1020.

[0131] The input device 1060 may include one or more devices that permit an operator to input information to the computer system 1000, such as, for example, a keypad or a keyboard, a display with a touch sensitive panel, voice recognition and / or biometric mechanisms etc. The output device 1070 may include one or more devices that output information to the operator, including a display, a speaker, etc. The input device 1060 and the output device 1070 may, in some implementations, be implemented as a user interface (UI) that displays UI information and which receives user input via the UI 101. The communication interface 1080 may include one or more transceivers that enable the computer system 1000 to communicate with other devices and / or systems. For example, the communication interface 1080 may include one or more wired or wireless transceivers for communicating.

[0132] The computer system 1000 may perform certain operations or processes, as may be described herein. The computer system 1000 may perform these operations in response to the processing unit 1020 executing software instructions contained in a computer-readable medium, such as the memory 1030. The “computer-readable medium” may be defined as a physical or logical memory device. The logical memory device may include memory space within a singlephysical memory device or spread across multiple physical memory devices. The software instructions may be read into the main memory 1030 from another computer-readable medium, such as the storage device 1050, or from another device via the communication interface 1080. The software instructions contained in the main memory 1030 may cause the processing unit 1020 to perform the operations or processes, as described herein. Alternatively, hardwired circuitry (e.g., logic hardware) may be used in place of, or in combination with, software instructions to implement the operations or processes, as described herein. Thus, exemplary implementations are not limited to any specific combination of hardware circuitry and software.

[0133] The configuration of components of the computer system 1000 illustrated in FIG. 10 is for illustrative purposes only. Other configurations may be implemented. Therefore, the computer system 1000 may include additional, fewer and / or different components, arranged in a different configuration, than depicted in FIG. 10.

[0134] In one or more embodiments, the disclosed system, methods, and processes may provide proper resource inventory update during partial CNF instantiation based on the response from the UCSE 169. For example, when a CNF includes 3 CNFC and while instantiation 2 CNFC are get instantiated successfully and 1 CNFC instantiation failed then CNFLM moved reserved resources for failed CNFC to free pool.

[0135] Referring to the technical abilities and advantageous effect of the present disclosure, the disclosed system and method may provide an architecture framework for end-to-end execution of CNF and CNFC instantiation, termination, and scaling call flow across major container orchestration platforms. Further, the disclosed system and method supports cache less operation. Due to non-data replication requirements, the architecture framework is available for all events. More particularly, the present disclosure provides end to end execution of CNF andCNFC instantiation call flow across major container orchestration platforms. Moreover, the present disclosure provides end to end execution of CNF and CNFC termination call flow across major container orchestration platforms. Furthermore, the present disclosure provides end to end execution of change management process across major container orchestration platforms. Furthermore, the present disclosure provides end to end execution of scaling process across major container orchestration platforms. Furthermore, the present disclosure provides resource inventory update during partial CNF instantiation based on UCSE response. Furthermore, the present disclosure provides means to collect monitoring data of available deployment sites in the container infrastructure and operational CNFCs, that can be utilized for a real-time status track of the resources at the container infrastructure, based on which the CNF orchestration requests may be managed (or timed).

[0136] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The abovedescribed embodiments are therefore to be construed in all aspects as illustrative and not restrictive.

[0137] 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. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

[0138] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary fromembodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, 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 are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.

Claims

We Claim:

1. A method (800, 900) for orchestrating a Cloud-native Network Function (CNF) in a container infrastructure (203), the method (800) comprising: receiving a CNF orchestration request by a transceiver module (308) at a CNF Lifecycle Manager (CNFLM) (121); fetching, by the transceiver module (308) at the CNFLM (121), a resource availability status of the container infrastructure (203) from a database (149), wherein the resource availability status indicates a resource in the container infrastructure (203) being available or unavailable for orchestration of the CNF; transmitting, by the transceiver module (308) at the CNFLM (121), a CNF orchestration trigger to a Universal Cloud Service Executor (UCSE) (169) using an interface between the CNFLM (121) and the UCSE (169) based on a determination that the resource is available for the orchestration of the CNF; and updating, by an update module (312) at the CNFLM (121), the resource availability status of the container infrastructure (203) in the database (149) based on a CNF orchestration response for the CNF orchestration request, received from the UCSE (169) corresponding to the orchestration of the CNF in the container infrastructure (203).

2. The method (800) as claimed in claim 1, wherein the CNF orchestration trigger initiates the orchestration of the CNF in the container infrastructure (203) corresponding to the CNF orchestration request.

3. The method (800) as claimed in claim 1, wherein the CNF orchestration request corresponds to a CNF operation from a plurality of CNF operations for orchestrating the CNF in the container infrastructure (203).

4. The method (800) as claimed in claim 3, wherein the interface between the CNFLM (121) and the UCSE (169) provides monitoring of an execution lifecycleof the CNF operation corresponding to the CNF orchestration request in the container infrastructure (203).

5. The method (800) as claimed in claim 1, wherein the CNF orchestration response is an CNF orchestration acknowledgement corresponding to a successful orchestration of the CNF in the container infrastructure (203) or a CNF orchestration error corresponding to a failed orchestration of the CNF in the container infrastructure (203).

6. The method (800) as claimed in claim 5, wherein, prior to fetching the resource availability status of the container infrastructure (203) from the database (149), the method (800) comprises determining, by a validation module (314) at the CNFLM (121), a validity of CNF data in the CNF orchestration request for the orchestration of the CNF in the container infrastructure (203), wherein the resource availability status of the container infrastructure (203) is fetched from the database (149) when the CNF data is determined valid for the orchestration of the CNF in the container infrastructure (203).

7. The method (800) as claimed in claim 6, further comprising rendering, by a notification module (316) at the CNFLM (121), a first error notification based on a determination that the resource is unavailable for the orchestration of the CNF, a second error notification indicating the CNF orchestration error corresponding to the failed orchestration of the CNF in the container infrastructure (203), and a third error notification when the CNF data is found invalid for the orchestration of the CNF in the container infrastructure (203).

8. The method (800) as claimed in claim 7, wherein, upon updating the resource availability status of the container infrastructure (203) in the database (149), the method (800) comprising generating, by the notification module (316) atthe CNFLM (121), a notification trigger for the user interface rendering the update of the database (149) for the for orchestration of the CNF in the container infrastructure (203).

9. A system (400) for orchestrating a Cloud-Native Network Function (CNF) in a container infrastructure (203), the system (400) comprising: a Universal Cloud Service Executor (UCSE) (169); and a CNF Lifecycle Manager (CNFLM) (121) communicatively coupled to the UCSE (169), wherein the CNFLM (121) comprising: a transceiver module (308) configured to: receive a CNF orchestration request; fetch a resource availability status of the container infrastructure (203) from a database (149), wherein the resource availability status indicates a resource in the container infrastructure (203) being available or unavailable for orchestration of the CNF; and transmit a CNF orchestration trigger to the UCSE (169) using an interface between the CNFLM (121) and the UCSE (169) based on a determination that the resource is available for the orchestration of the CNF; and an update module (312) configured to update the resource availability status of the container infrastructure (203) in the database (149) based on a CNF orchestration response for the orchestration request, received from the UCSE (169) corresponding to the orchestration of the CNF in the container infrastructure (203).

10. The system (400) as claimed in claim 9, wherein the CNF orchestration trigger initiates the orchestration of the CNF in the container infrastructure (203) corresponding to the CNF orchestration request.

11. The system (400) as claimed in claim 9, wherein the CNF orchestration request corresponds to a CNF operation from a plurality of CNF operations for orchestrating the CNF in the container infrastructure (203).

12. The system (400) as claimed in claim 11, wherein, the interface between the CNFLM (121) and the UCSE (169) provides monitoring of an execution lifecycle of the CNF operation corresponding to the CNF orchestration request in the container infrastructure (203).

13. The system (400) as claimed in claim 9, wherein the CNF orchestration response is an CNF orchestration acknowledgement corresponding to a successful orchestration of the CNF in the container infrastructure (203) or a CNF orchestration error corresponding to a failed orchestration of the CNF in the container infrastructure (203).

14. The system (400) as claimed in claim 13, wherein the CNFLM (121) comprises a validation module (314) configured to determine a validity of CNF data in the CNF orchestration request for the orchestration of the CNF in the container infrastructure (203), wherein the resource availability status of the container infrastructure (203) is fetched from the database (149) when the CNF data is determined valid for the orchestration of the CNF in the container infrastructure (203).

15. The system (400) as claimed in claim 14, wherein the CNFLM (121) comprises a notification module (316) configured to render: a first error notification based on a determination that the resource is unavailable for the orchestration of the CNF; a second error notification indicating the CNF orchestration error corresponding to the failed orchestration of the CNF in the container infrastructure (203); and third error notification when the CNF data is found invalid for the orchestration of the CNF in the container infrastructure (203).

16. The system (400) as claimed in claim 15, wherein, upon updating the resource availability status of the container infrastructure (203) in the database (149), the notification module (316) is configured to generate a notification trigger for the user interface rendering the update of the database (149) for the for orchestration of the CNF in the container infrastructure (203).

17. A computer-program product for orchestrating a Container Network Function (CNF) in a container infrastructure (203), the computer-program product comprising computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations comprising: receiving a CNF orchestration request; fetching a resource availability status of the container infrastructure (203) from a database (149), wherein the resource availability status indicates a resource in the container infrastructure (203) being available or unavailable for orchestration of the CNF; transmitting a CNF orchestration trigger to a Universal Cloud Service Executor (UCSE) (169) using an interface between a CNF Lifecycle Manager (CNFLM) (121) and the UCSE (169) based on a determination that the resource is available for the orchestration of the CNF; and updating the resource availability status of the container infrastructure (203) in the database (149) based on a CNF orchestration response for the CNF orchestration request, received from the UCSE (169) corresponding to the orchestration of the CNF in the container infrastructure (203).

Images