DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR PROVIDING INTERCONNECTIVITY BETWEEN COMPONENTS OF A MANO FRAMEWORK
2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[0002] The present disclosure generally relates to the field of event routing in wireless communication systems. More particularly, the present disclosure relates to a system and a method for providing interconnectivity between one or more components of a management and orchestration (MANO) framework.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘Virtualization’ used hereinafter in the specification refers to a technology that allows to create and manage virtual versions of physical resources, such as servers, storage devices, and networks.
[0005] The expression ‘Virtualized infrastructure' used hereinafter in the specification refers to the abstraction of physical computing resources into virtual instances that can be managed and utilized flexibly. This abstraction allows for efficiently allocating, managing, and scaling resources across multiple applications and services.
[0006] The expression ‘Management and Orchestration (MANO)’ framework used hereinafter in the specification refers to a framework that manages and orchestrates virtualized network functions (VNFs) and resources in a Network Functions Virtualization (NFV) environment.
[0007] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to an intermediary component that facilitates communication between external systems and the MANO framework, routing service requests and responses for network slice allocations and resource allocation and management.
[0008] The expression ‘Network Management System (NMS)’ used hereinafter in the specification refers to a system responsible for the centralized management, monitoring, and control of the infrastructure of a network (e.g., the 5G network and the 6G network). The NMS provides comprehensive tools and features for network operators (or network administrators) to manage and optimize network resources, including routers, switches, servers, and other network devices.
[0009] The expression ‘Network Functions Virtualization (NFV)’ used hereinafter in the specification refers to a network architecture concept that uses virtualization technologies to manage core networking functions via software rather than hardware.
[0010] The expression ‘Virtualized Network Function (VNF)’ used hereinafter in the specification refers to a software implementation of a network function that can be deployed on a Network Functions Virtualization Infrastructure (NFVI).
[0011] The expression ‘Orchestrator’ used hereinafter in the specification refers to a component of the MANO framework responsible for the orchestration and lifecycle management of physical and software resources. The orchestrator is a component in charge of the management of the NFV infrastructure and software resources.
[0012] The expression ‘Containerized network function manager (CNFM)’ used hereinafter in the specification orchestrates and optimizes network functions deployed within containerized environments.
[0013] The expression ‘Virtualized Infrastructure Manager (VIM)’ used hereinafter in the specification refers to a component of the MANO framework responsible for controlling and managing the NFV infrastructure computation, storage, and resources (i.e., network resources).
[0014] The expression ‘NFV Infrastructure (NFVI)’ used hereinafter in the specification refers to a collection of hardware and software components that build an environment in which VNFs are deployed, managed, and executed.
[0015] The expression ‘NFV orchestrator (NFVO)’ used hereinafter in the specification refers to a component within the NFV architecture responsible for the end-to-end orchestration and management of the VNFs and their associated resources.
[0016] The expression ‘Container’ used hereinafter in the specification refers to an executable unit of software in which application code is packaged along with its libraries and dependencies.
[0017] The expression ‘Containerized Applications’ used hereinafter in the specification refers to applications that run in isolated packages of code (containers).
[0018] The expression ‘Orchestration Management’ used hereinafter in the specification refers to a process of managing and coordinating the deployment and operation of multiple services or applications in a distributed environment.
[0019] The expression ‘Event’ used hereinafter in the specification refers to a specific action that can trigger a network element, network entity, or system to take a particular action or reaction. In an example, the event may include network traffic, system configuration changes, security incidents, and the like.
[0020] The expression ‘Microservices’ used hereinafter in the specification refer to the architectural and deployment paradigm where applications are composed of small, independent services that are deployed and managed within the virtualized environment. Each microservice is designed to perform a specific function and communicates with other microservices over well-defined APIs.
[0021] The expression ‘communication path’ used hereinafter in the specification refers to a route through which entities exchange information. For the microservices, the communication path describes the way microservices interact with each other. This includes the protocols, interfaces, and data formats used for communication.
[0022] The expression ‘interconnectivity between microservices’ used hereinafter in the specification refers to a way in which different microservices within the system interact and communicate with each other.
[0023] The expression ‘Network entity’ used hereinafter in the specification refers to any device, component, or element that is part of the network and participates in its operation. The network entities involve in various functions, such as communication, management, and data processing.
[0024] The expression ‘Orchestration request’ used hereinafter in the specification refers to a command or set of instructions sent to or from the orchestration system to manage, coordinate, or automate the deployment, scaling, and operation of various resources or services within the network.
[0025] The expression ‘alternate microservice’ used hereinafter in the specification refers to a microservice that is functioning correctly and meeting its operational and performance expectations.
[0026] The expression ‘Orchestrator_Event Routing Manager (Or_EM) interface’ used hereinafter in the specification refers to a communication interface within the Management and Orchestration (MANO) framework. The Or_EM interface is responsible for facilitating the communication and routing of orchestration requests between the NFVO and various microservices associated with the CNFM and the VIM. More particularly, the Or_EM interface effectively provides interconnectivity between a microservice of the NFVO and one of a microservice associated with the CNFM or the Virtualized VIM to fulfill the service request and orchestration request.
[0027] These definitions are in addition to those expressed in the art.
BACKGROUND
[0028] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0029] In the realm of Network Functions Virtualization (NFV), a Management and Orchestration (MANO) framework is critical for the effective deployment and management of virtualized network services. The MANO framework is primarily comprised of three essential components including a Virtualized Infrastructure Manager (VIM), a Containerized Network Function (CNF) manager, and a Network Functions Virtualization Orchestrator (NFVO). To effectively deploy and manage the virtualized network services, the three essential components must interact with each other in a smooth and flexible manner. Each component relies on communication with the other to perform its functions efficiently in deploying and managing the virtualized network services.
[0030] When any of the three components (or microservices associated with these three components) fail to communicate with each other, several significant issues may arise, such as network service deployment delays or failures, resource misallocation and inefficiency, a network service degradation and outages, an inability to handle failures and recovery, an operational inefficiency, and the like. In particular, maintaining proper communication between these three components of the MANO framework is essential for ensuring a reliable and efficient deployment and management of the virtualized network services. This is because any disruptions in the communication of the three components impact service performance and availability and increase operational complexities and manual interventions. Hence, it is essential to ensure robust and reliable communication between the three components to maintain the overall functionality and effectiveness of the MANO framework.
[0031] Therefore, there is a need to provide a method and a system that provides effective interconnectivity between microservices associated with the MANO framework.
OBJECTIVE OF THE PRESENT DISCLOSURE
[0032] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0033] An objective of the present disclosure is to provide a method and a system for providing interconnectivity between one or more components of a management and orchestration (MANO) framework via a network interface (e.g., an Orchestrator_ Event routing Manager (Or_EM) interface).
[0034] Another objective of the present disclosure is to provide the Or_EM interface that connects a network function virtualization orchestrator (NFVO) of the MANO framework and an event routing manager (ERM).
[0035] Another objective of the present disclosure is to provide the Or_EM interface that provides a guaranteed message delivery with an acknowledgement and a delivery report.
[0036] Another objective of the present disclosure is to provide a method and a system that enables automatic detection of failed services (i.e., service requests) and facilitates rerouting of the service requests to alternative healthy instances or microservices associated with the MANO framework.
[0037] Another objective of the present disclosure is to provide a method and a system that enables asynchronous communication between various components (i.e., a Network Functions Virtualization Orchestrator (NFVO), a Containerized network function’ (CNF) manager, a Virtualized Infrastructure Manager (VIM)) of the MANO via the Or_EM interface.
[0038] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
SUMMARY
[0039] In an exemplary embodiment, a method for providing interconnectivity between one or more components of a management and orchestration (MANO) framework is disclosed. The method includes receiving, by a network function virtualization orchestrator (NFVO), at least one service request from an event routing manager (ERM) via an associated network interface. The method includes extracting, by the NFVO, one or more parameters from the at least one received service request. The method includes processing, by the NFVO, the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request. The method includes determining, by the NFVO, at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request.
[0040] In some embodiments, the method further comprises receiving, by the ERM, the least one generated orchestration request from the NFVO, and routing, by the ERM, the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface.
[0041] In some embodiments, the network interface is an Orchestrator_ Event routing Manager (Or_EM) interface.
[0042] In some embodiments, the at least one service request comprises a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request.
[0043] In some embodiments, the one or more extracted parameters comprise at least one of a network entity identifier (ID) and a service request type, and wherein the service request type comprises one or more key performance indicators (KPIs) and one or more issues associated with the network entity.
[0044] In some embodiments, processing the at least one received service request comprising analyzing, by the NFVO, the one or more KPIs associated with the network entity, comparing, by the NFVO, the analyzed one or more KPIs with one or more threshold values, and generating, by the NFVO, the at least one orchestration request when the one or more KPIs exceed or fall below the one or more threshold values.
[0045] In some embodiments, processing the at least one received service request comprising analyzing, by the NFVO, the one or more issues associated with the network entity, and generating, by the NFVO, the at least one orchestration request based on analyzing the one or more issues.
[0046] In some embodiments, the at least orchestration request comprises at least one operation request associated with resources, and the at least one operation request is one of a creation of the resources, allocation of the resources, and deallocation of the resources.
[0047] In an exemplary embodiment, a system for providing interconnectivity between one or more components of a management and orchestration (MANO) framework is disclosed. The system comprises an Event Routing Manager (ERM). The ERM is communicatively coupled with a network function virtualization orchestrator (NFVO) of the MANO framework. The NFVO is configured to receive at least one service request from the ERM via an associated network interface. The NFVO is further configured to extract one or more parameters from the at least one received service request. The NFVO is further configured to process the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request. The NFVO is further configured to determine at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request.
[0048] In some embodiments, the ERM is configured to receive the least one generated orchestration request from the NFVO, and route the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface.
[0049] In some embodiments, the network interface is an Orchestrator_ Event routing Manager (Or_EM) interface.
[0050] In some embodiments, the at least one service request comprises a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request.
[0051] In some embodiments, the one or more extracted parameters comprise at least one of a network entity identifier (ID) and a service request type, and wherein the service request type comprises one or more key performance indicators (KPIs) and one or more issues associated with the network entity.
[0052] In some embodiments, to process the at least one received service request, the NFVO is configured to analyze the one or more KPIs associated with the network entity, compare the analyzed one or more KPIs with one or more threshold values, and generate the at least one orchestration request when the one or more KPIs exceed or fall below the one or more threshold values.
[0053] In some embodiments, to process the at least one received service request, the NFVO is configured to analyze the one or more issues associated with the network entity and generate the at least one orchestration request based on analyzing the one or more issues.
[0054] In some embodiments, the at least orchestration request comprises at least one operation request associated with resources, and the at least one operation request is one of a creation of the resources, allocation of the resources, and deallocation of the resources.
[0055] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0056] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0057] FIG. 1 illustrates an exemplary network architecture for implementing a system for providing interconnectivity between one or more components of a management and orchestration (MANO) framework, in accordance with an embodiment of the present disclosure.
[0058] FIG. 2 illustrates an exemplary block diagram of the system configured for providing interconnectivity between the one or more components associated with the MANO framework, in accordance with an embodiment of the present disclosure.
[0059] FIG. 3 illustrates an exemplary block diagram depicting interconnectivity between the one or more components associated with the MANO framework, in accordance with an embodiment of the present disclosure.
[0060] FIG. 4 illustrates an exemplary MANO framework architecture, in accordance with embodiments of the present disclosure.
[0061] FIG. 5 illustrates an exemplary process flow depicting interconnectivity between the one or more components associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0062] FIG. 6 illustrates another exemplary process flow depicting interconnectivity between the one or more components associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0063] FIG. 7 illustrates an exemplary flow diagram of a method for providing interconnectivity between the one or more components associated with the MANO framework, in accordance with embodiments of the present disclosure.
[0064] FIG. 8 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0065] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 – Network architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
200 – Block Diagram
202 – Processor(s)
204 - Memory
206 – Plurality of Interfaces
208 – Event Routing Manager (ERM)
210 – Database
212 - Receiving unit
214 – Communication unit
300 – Exemplary Block Diagram
302 – ERM
304 - Network Functions Virtualization Orchestrator (NFVO)
306 - Containerized Network Function (CNF) manager
308 - Virtualized Infrastructure Manager (VIM)
310 - Operations, Administration, and Maintenance (OAM) module
400 – MANO framework architecture
402 - User interface layer
404 - Network Functions Virtualization (NFV) and Software-Defined Networking SDN design function
406 - Platform foundation service
408 – Platform core service
410 – Platform operation, administration, and maintenance manager
412 – Platform resource adapters and utilities
500 – Process Flow Diagram
600 – Process Flow Diagram
700 – Flow Diagram
800 – Computer System
810 – External Storage Device
820 – Bus
830 – Main Memory
840 – Read Only Memory
850 – Mass Storage Device
860 – Communication Port
870 – Processor
DETAILED DESCRIPTION
[0066] 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. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0067] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0068] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0069] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0070] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0071] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0072] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0073] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[0074] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0075] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), sixth generation (6G), and more such generations are expected to continue in the forthcoming time.
[0076] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0077] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0078] Management and orchestration (MANO) is a framework for managing and orchestrating all network resources in the cloud. The MANO framework includes three essential components namely a Virtualized Infrastructure Manager (VIM), a Containerized Network Function (CNF) manager, and a Network Functions Virtualization Orchestrator (NFVO). Within each of these components, multiple microservices operate. The multiple microservices communicate with one another using specific event names. It is required that these three components communicate with each other in a flexible manner. An Event Routing Manager (ERM) is responsible for routing incoming service requests to a defined microservice based on an event name employing designated interfaces.
[0079] At present, various interfaces have been designed to connect these three components and multiple microservices, but these interfaces are rigid and limited to specific microservices. As a result, specific interfaces are necessary to meet the requirements of the network, thereby leading to a complex and expensive solution.
[0080] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by promoting interoperability between various MANO components, making it easier for each element to work seamlessly together. In an aspect, the present disclosure may be directed to the ERM that is configured to provide seamless data communication between the NFVO and CNF manager (also referred to as CNFM) and the NFVO and VIM via an Orchestrator_ Event routing Manager (Or_EM) interface.
[0081] Embodiments herein relate to a method and a system for providing interconnectivity between one or more components of the MANO framework. The interconnectivity between the one or more components (e.g., NFVO, CNFM, and VIM) associated with the MANO framework may be provided by the ERM via the Or_EM interface. Initially, an Event Routing Manager (ERM) may receive at least one service request from a network entity. Further, the ERM may transmit the at least one service request to a network function virtualization orchestrator (NFVO) of the MANO framework. The NFVO may receive the at least one service request from the ERM via the Or_EM interface. Further, the NFVO may extract one or more parameters from the at least one received service request. Further, the NFVO may process the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request. Further, the NFVO may determine the at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request. Further, the ERM may receive the at least one orchestration request generated by the NFVO in response to the at least one service request. Further, the ERM may route the least one generated orchestration request to the determined at least one network service associated with the at least one component (e.g., CNFM, and VIM) of the MANO framework via the Or_EM interface. In an aspect, the Or_EM interface is configured to provide interconnectivity between the NFVO and the at least one determined network service associated with one of the CNFM and the VIM of the MANO framework.
[0082] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0083] FIG. 1 illustrates an exemplary network architecture 100 of a system 108 for providing interconnectivity between one or more components of the MANO framework, in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2…104-N associated with one or more users 102-1, 102-2…102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2…102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2…104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.
[0084] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users 102 and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0085] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.
[0086] In FIG. 1, the UE 104 may communicate with the system 108 through the network 106. In particular, the UE 104 may be communicatively coupled with the network 106. On coupling, the system 108 receives a connection request from the UE 104. The system 108 sends an acknowledgment of the connection request to the UE 104. The UE 104 transmits a plurality of signals in response to the connection request. The system 108 may be configured for providing interconnectivity between the one or more components associated with the MANO framework.
[0087] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, one or more of the RAN, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0088] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.
[0089] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for providing interconnectivity between the one or more components associated with the MANO framework, in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1.
[0090] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.
[0091] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, an Event Routing Manager (ERM) 208 and a database 210. In one embodiment, the ERM 208 may be configured to provide interconnectivity between one or more components associated with the MANO framework.
[0092] In an embodiment, the one or more processor(s) 202 may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the one or more processor(s) 202. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the one or more processor(s) 202 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the one or more processor(s) 202 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the one or more processor(s) 202. In such examples, the system 108 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system 108 and the processing resource. In other examples, the one or more processor(s) 202 may be implemented by electronic circuitry.
[0093] In an embodiment, the ERM 208 may include a receiving unit 212, and a communication unit 214. The receiving unit 212 is configured to receive at least one service request (also referred as an event). Examples of the at least one service request may include, but are not limited to, a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request. In an embodiment, the at least one service request may be received from a network entity (also referred to as an actor). The network entity may be associated with external systems (e.g., the UE 104) that are in communication with the MANO framework. Examples of network entity include, but are not limited to, routers, switches, hosts, modems, terminals, dial access servers, gateways, ports, channels, interfaces, circuits, processes, drivers, protocols, services, and applications. Further, examples of the external system may include, but are not limited to, a Network Slicing Management Platform (NSMP), a Support Ticket System (STS), a Subscriber Support System (SSS), a Performance Monitoring (PM) System, a Network Management System (NMS), and a Container Network Infrastructure Monitoring System (CNIS).
[0094] In an aspect, the virtual switches are used in virtual machines (VMs) or containers to communicate with each other and with the external network. In an aspect, the virtual routers perform routing functions within the virtualized network, directing traffic between different subnets or virtual networks. In an aspect, the virtual network interface cards are virtualized network interfaces that allows VMs or containers to connect to the virtual switches or networks. In an aspect, the virtual firewalls are software-based firewalls that provides network security by monitoring and controlling incoming and outgoing network traffic based on predefined security rules. In an aspect, the virtual load balancers distribute incoming network traffic across multiple servers or services to ensure high availability and reliability. In an aspect, the VPN gateways provide secure connectivity between virtual networks or between a virtual network and an on-premises network. In an aspect, virtualized network functions (VNFs) are network functions that are virtualized and run on virtualized infrastructure instead of dedicated hardware.
[0095] In an aspect, the resource allocation and management request include, but is not limited to, request to allocate central processing unit (CPU) or memory to virtual machines (VMs), request to resize the VMs, request to allocate storage to VMs, request to modify storage allocation, request to deallocate resources from VMs, request to monitor resource utilization, and request to update resource allocation policies. The fault management and recovery request includes, but is not limited to, request to detect a fault, request to restart a faulty VM, request to reboot a host, request to restore VM from backup, and request to update fault tolerance settings. The resource optimization and scaling request includes, but is not limited to, request to scale up or scale down the VM, request to auto scale container service, request to optimize storage allocation, request to adjust network bandwidth allocation, request to provision additional VMs, request to monitor and adjust performance metrics, and request to optimize load balancer configuration.
[0096] Upon receiving the at least one service request, the communication unit 214 is configured to transmit the at least one received service request to a network function virtualization orchestrator (NFVO) associated with the MANO framework. In an embodiment, the ERM 208 may be communicatively coupled with the NFVO to exchange data that is required to provide interconnectivity between one or more components of the MANO framework. In particular, the NFVO may be configured to receive the at least one service request from the ERM 208 via an associated network interface (e.g., Or_EM interface). The NFVO may further extract one or more parameters from the at least one received service request.
[0097] The NFVO may further configured to process the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request. In an aspect, the one or more extracted parameters may include at least one of a network entity identifier (ID) and a service request type. The service request type may include one or more key performance indicators (KPIs), and one or more issues associated with the network entity. In particular, the extraction allows the NFVO to process the at least one service request and generate the corresponding orchestration request. Based on the generated orchestration request, the ERM may determine at least one network service (interchangeably referred to as at least one microservice) associated with at least one component of the MANO framework. The at least one microservice may be capable of handling the specified network entity and requested operation.
[0098] In an embodiment, the NFVO may process the at least one received service request based on one or more KPIs. In such embodiment, the NFVO may initially analyze the one or more KPIs associated with the network entity to track the performance of the network or application continuously. The one or more KPIs may include metrics such as bandwidth usage, response time, latency, the number of active connections, Central Processing Unit (CPU), Random Access Memory (RAM), Disk Input/Output (Disk I/O) or Network Input/Output (Network I/O) usage. The NFVO then compares the monitored one or more KPIs with one or more threshold values. If the comparison reveals that the analyzed one or more KPIs exceed or fall below one or more threshold values, indicating a performance issue or inefficiency, the NFVO automatically generates at least one orchestration request.
[0099] The orchestration request may include at least one operation associated with the resources. The at least one operation is one of a creation of the resources, allocation of the resources and deallocation of the resources. In an aspect, the orchestration request refers to a command or series of commands issued to manage and automate the deployment, scaling, operation, and decommissioning of resources. Examples of orchestration request may include, but is not limited to, request to provision a new virtual machine, request to configure load balancers, request to backup and restore resources, request to monitor and adjust performance, request to schedule maintenance, request to optimize resource utilization. Additionally, the at least one operation may further include allocating additional resources, scaling up the service by spawning more containers, or initiating corrective actions to restore optimal performance without manual intervention. This ensures that the system (108) maintains the desired level of service quality by dynamically responding to changes in network conditions or service demands. The value of monitoring a KPI parameter, such as CPU usage, is critical for maintaining system performance and preventing resource bottlenecks. For example, if the one or more KPI being monitored is CPU usage, a predefined threshold can be set. In this case, if the CPU usage exceeds 80%, it triggers an automatic action, such as spawning a new resource or scaling up system capacity to handle the increased load. This approach ensures that the system (108) remains responsive and efficient, preventing potential slowdowns or outages caused by resource exhaustion. Monitoring thresholds like this helps to maintain optimal performance and resource allocation in real-time. Suppose the system can handle up to 1,000 requests per second, but the KPIs indicate that the system is receiving more than 1,000 requests per second. In this case, based on the KPI data, the NFVO automatically provisions additional resources to handle the increased load. The resource scaling may involve spawning more containers and distributing incoming requests across them, ensuring optimal throughput.
[00100] In an alternative embodiment, the NFVO may process the at least one received service request based on one or more issues (e.g., user complaint) associated with the network entity. In such embodiment, rather than traditional KPIs, the NFVO may initially analyze the content of the complaint to determine the underlying issue. These issues can be performance-related complaints, such as slow internet speeds, connection drops, or poor voice quality, reported directly by the user (102) or detected through automated trouble ticketing systems.
[00101] For instance, when the user (102) submits a complaint regarding slow download speeds, the NFVO retrieves the associated network entity identifier (e.g., cell tower ID, router ID, etc.) and the nature of the complaint (e.g., download speed, latency, connection instability). Based on this information, the NFVO analyzes the service degradation or resource bottlenecks without necessarily referring to predefined KPI thresholds. Further, the NFVO automatically generates the orchestration request to resolve the complaint based on the nature of the issue. In such cases, the orchestration request may include allocating additional bandwidth to the affected user, re-routing traffic to a less congested network path, or initiating corrective actions to address the underlying issue (e.g., resetting a faulty network element or redistributing workloads).
[00102] This scenario focuses on resolving the complaint by dynamically provisioning resources or adjusting configurations to meet the user’s service expectations. The orchestration request may involve operations such as scaling up resources (e.g., adding more capacity to a congested network segment), allocating additional network slices to the user, reallocating existing resources to prioritize the affected service, and repairing or restarting faulty components that may have caused the issue. For example, if the user (102) experiences frequent disconnections in a specific area, the NFVO may initiate the creation of additional virtualized resources or increase priority for the user's traffic to mitigate the issue, ensuring that the service level is restored without manual intervention.
[00103] In another case, suppose the complaint is related to voice call quality, where the user reports dropped calls. The NFVO may analyze the complaint to identify the network entities involved (e.g., base stations, routers) and automatically generate a request to adjust network parameters (e.g., re-routing calls through alternative paths or adjusting codec configurations) to resolve the issue. This complaint-based approach ensures that customer satisfaction is maintained by addressing issues promptly to fix problems without waiting for the KPIs to reach critical thresholds.
[00104] In an aspect, to transmit the at least one generated orchestration request to the at least one determined microservice, the receiving unit 212 may receive the at least one orchestration request generated by the NFVO. Further, the communication unit 214 may be configured to route the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface. In an embodiment, the at least one component may correspond to one of the CNFM and the VIM. In an aspect, the network interface is the Orchestrator_ Event routing Manager (Or_EM) interface.
[00105] In an embodiment, the Or_EM interface is configured to provide interconnectivity between the NFVO and the at least one determined microservice associated with one of the CNFM and the VIM based on the generated orchestration request. In such embodiment, the determined microservice may correspond to a microservice associated with one of the CNFM and the VIM.
[00106] In one aspect, based on the generated orchestration request, the ERM 208 may be configured to establish a first communication path between the NFVO and the CNFM via the Or_EM interface to manage the lifecycle of VNF instances. In an aspect, the CNFM processes the orchestration request to determine the current state of resources (e.g., computing resource, storage resource, network resource, etc.) and check whether the existing infrastructure supports the requirement for processing of the received service request. The CNFM further provides information corresponding to resource allocation, deployment, configurations (e.g., network policies, security settings, scaling parameters, etc.). In this way, the CNFM provides information corresponding to resource assessment, deployment planning, and monitoring.
[00107] In another aspect, based on the generated orchestration request, the ERM 208 may be configured to establish a second communication path between the NFVO and the VIM via the Or_EM interface. In an aspect, the VIM is configured to receive the at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization from the CNFM via the ERM 208. The VIM is configured to analyze the received at least one information to manage at least one underlying infrastructure resource for virtualization. In an aspect, the VIM may analyze the information received from the CNFM to perform the allocation of computing resources, storage resources, and network resources. Further, the VIM may perform virtualization management (i.e., create, manage, and terminate virtual machines that host VNFs), network management (i.e., configuration and management of virtual networks, including virtual switches and routers, enabling communication between VNFs and other components, load balancing, fault management, security, etc.
[00108] In an aspect, states of the virtualized infrastructure associated with the at least one microservice include, but are not limited to, deployment state (e.g., provisioning or pending), operational state (e.g., active/running, idle), scaling state (e.g., scaling up, scaling down), maintenance state (e.g., upgrading, patching), monitoring (e.g., health monitoring, alerting), fault management state (e.g., fault detected, recovery/resilience), configuration state (e.g., initial setup/configuration change), resource management state (e.g., resource allocation/resource deallocation), security state (e.g., security assessment, compliance checking). In an aspect, the communication path refers to an interface used for communication between the components.
[00109] In an aspect, allocation of resources associated with the microservice includes assigning and managing computing resources such as CPU, memory, storage, and network bandwidth to the microservices. The resource allocation includes, but is not limited to, CPU allocation, memory allocation, storage allocation, network bandwidth allocation, auto-scaling resources, resource balancing, resource monitoring and adjustment.
[00110] In an aspect, the NFVO is configured to process the at least one service request and sends the processed at least one service request to the ERM 208. In an aspect, the ERM 208 sends an acknowledgement of processing of the at least one service request to the at least one network entity. In an aspect, the acknowledgment is sent to provide the status of at least one service request. The acknowledgment confirms that the service request has been received and processed. The status of the at least one service request includes success or failure. In this way, the system (108) provides the guaranteed message delivery with acknowledgement and delivery report.
[00111] In an aspect, responsive to detection failure of the microservice allocation during processing of the at least one service request, the communication unit 214 may reroute the at least one service request to an alternate healthy microservice based on a plurality of routing configurations. The communication unit 214 ensures the automatic detection of failed services and facilitates the rerouting of requests to alternative healthy instances or microservices. This improves overall system resilience and minimizes downtime.
[00112] In an aspect, a plurality of routing configuration is stored based on a plurality of service names and fully qualified domain name (FQDN) addresses in the database (210). In an example, the plurality of service names includes, but is not limited to, infrastructure services, container orchestration services, application services, monitoring and management services, security services, networking services, storage services, deployment services, backup and recovery services, access management services, resource allocation services, configuration services, etc. In an aspect, the fully qualified domain names (FQDNs) are used to uniquely identify and locate resources within a domain. The FQDNs are essential for ensuring that network resources can be correctly addressed and accessed.
[00113] In an aspect, the communication unit 214 is configured to map the at least one service request to the routing configurations based on the service name and the FQDN address of the service request. The at least one service request is routed to the determined microservice based on the mapped routing configuration. The at least one received service request includes a defined service name and a defined FQDN address. In an example, if the service request is the load balancing service request. In such example, the service name is load balancing, and the FQDN address is lb-web.example.com. (e.g., the load balancer for web traffic with the hostname web in the example.com domain).
[00114] In an embodiment, the system 108 may include a database 210 that includes data (e.g., the at least one service request, the acknowledgment or data identifying the one or more microservices, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor 202.
[00115] Although FIG. 2 shows exemplary components of the block diagram 200 of the system 108, in other embodiments, the block diagram 300 of the system 108 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the block diagram 200 of the system 108 may perform functions described as being performed by one or more other components of the block diagram 200 of the system 108.
[00116] FIG. 3 illustrates an exemplary block diagram 300 depicting interconnectivity between the one or more components associated with the MANO framework via interfaces associated with an ERM 302, in accordance with an embodiment of the present disclosure. The ERM 302 may correspond to the ERM 208. FIG. 3 is explained in conjunction with FIGS. 1 and 2.
[00117] The MANO is commutatively coupled with several network elements (not shown in figures) or the external systems. Each network element or the external system may be also referred to as the actor. For example, the network elements may be a logical entity or a physical entity within a network (e.g., the network 106) that is being managed or controlled. The network element is preferably designed with built-in instrumentation, which allows for the collection of relevant information which may be subsequently used to determine control actions to be applied to the network element. In particular, the network elements may be any hardware or software component that has the measurable parameter that can be reported. Examples of network elements include the routers, the switches, the hosts, the modems, the terminals, the dial access servers, the gateways, the ports, the channels, the interfaces, the circuits, the processes, the drivers, the protocols, the services, the applications, etc.
[00118] The ERM 302 may be adapted as software and added as a microservice within the MANO framework. In some embodiments, the ERM 302 may communicate with the MANO framework. In an example, the ERM 302 may be a publisher subscriber based microservice. The ERM 302 may direct incoming service requests (i.e., at least one service request) based on an event name to an appropriate microservice, employing designated interfaces. The ERM 302 is an event-driven communication framework that enhances the overall functionality and effectiveness of the MANO framework.
[00119] As shown in FIG. 3, the MANO framework includes a NFVO 304, a CNF manager (CNFM) 306, and a VIM 308. The NFVO 304 is configured to co-operate with a CNF catalogue management, a network service catalogue, and a policy execution engine. The NFVO 304 is responsible for orchestrating services, overseeing a deployment, and managing resources (also referred to as network resources) efficiently. In an aspect, the NFVO 304 is configured to perform a resource orchestration and a service orchestration. In the resource orchestration, the NFVO 304 is configured to coordinate, authorize, release, and engage Network Functions Virtualization Infrastructure (NFVI) resources. In the service orchestration, the NFVO 304 is configured to manage lifecycle Network Service (NS) instances (instantiation, scaling, termination, update, etc. of the NS instances). The CNFM 396 is configured to determine a lifecycle of the CNF instances (for example, instantiation, update, query, scaling, termination, etc.). In examples, the CNFM 306 is responsible for overseeing and controlling Containerized Network Functions (CNFs), ensuring proper functioning of the CNFs.
[00120] The VIM 308 is configured as an orchestration adapter. The VIM 308 is configured to manage underlying infrastructure resources required for virtualization. In an aspect, the VIM 308 is configured to manage computation, storage, and resources (also referred to as network resources) of the NFVI, monitor a failure of the NFVI, and monitor the resources of the NFVI. In an example, the NFVI is an NFV Infrastructure that includes physical (server, storage, etc.) resources, virtual resources (virtual machines), and software resources (hypervisor) in an NFV environment. The VIM 308 is configured to manage a lifecycle of the virtual resources in the NFVI. The VIM 308 creates and maintains virtual machines from the physical resources in the NFVI. The VIM 308 is configured to maintain an inventory of the virtual machines associated with the physical resources. In an example, the VIM 308 is configured to handle performance and fault management of the physical resources (also referred to as hardware resources), the software resources, and the virtual resources.
[00121] In an operative aspect, a network element (e.g., the actor) is configured to send the at least one service request to the ERM 302. The ERM 302 is configured to route the at least one service request to the NFVO 304. Further, the NFVO 304 is further configured to process the at least one service request internally or is configured to identify one or more microservices associated with the CNFM 306 or the VIM 308 for processing the at least one service request if the at least one service request cannot be processed internally. In other words, the NFVO 304 is configured to process the at least one service request internally using an associated microservice (i.e., the determined microservice), if the at least one service request can be catered by the NFVO 304. However, if the at least one service request cannot be catered internally, the NFVO 304 generates at least one orchestration request corresponding to the at least one service request. Further, the NFVO 304 forwards the at least one orchestration request to the one or more microservices associated with the CNFM 306 or the VIM 308 according to a type of the network element from which the at least one service request is received, so that the CNFM 306 or the VIM 308 may perform resource processing of a related CNF or a related VIM.
[00122] The ERM 302 may make use of service discovery mechanisms such as a service registry for routing configurations to map service names with Fully Qualified Domain Name (FQDN) addresses. In an example, incoming service requests (i.e., the at least one service request) is routed based on events publisher and subscribers configured along with Hypertext Transfer Protocol (HTTP) headers. Further, event routing configurations is used for distributing the incoming service requests across multiple instances of services using load balancing techniques such as a round robin technique. The round robin technique helps in optimizing the resource utilization and improving overall performance of a system (i.e., the system 108).
[00123] In an aspect, to forward the at least one orchestration request to the one or more microservices associated with the CNFM 306 or the VIM 308, the ERM 302 may include a plurality of interfaces. For example, the plurality of interfaces may include a network interface (i.e., the Or_EM interface), a second network interface (i.e., the EM_Cnfm interface), and a third network interface (i.e., the EM_Vi interface). Each of the plurality of interfaces may be associated with a corresponding microservice, i.e., the NFVO 304, the CNFM, 306, the VIM 308. The ERM 302 is configured to implement an asynchronous event-based approach to efficiently utilize the plurality of interfaces. The network interface (i.e., the Or_EM interface) is coupled to the NFVO 304 and is configured to establish communication between the NFVO 304 and the ERM 302. Using the Or_EM interface, the NFVO 304 is configured to receive service requests from the ERM 302. Further, using the Or_EM interface, the NFVO 304 may be configured to transfer the acknowledgment and a delivery report, or the data identifying the one or more microservices to the ERM 302. The NFVO 304 may act as a publisher here. The EM_Or interface is configured to operate in a high availability mode, ensuring continuity of a service processing based on a service request received from the ERM 302. In some embodiment, the EM_Or interface of the ERM 302 is configured to communicate an update signal to the NFVO 304 indicating a status of the processed service request.
[00124] In some embodiments, the Or_EM interface is responsible for providing interconnectivity between the one or more components associated with the MANO framework. For example, in one embodiment, the Or_EM interface may provide interconnectivity between the NFVO 304 and CNFM 306. In another embodiment, the Or_EM interface may provide interconnectivity between the NFVO 304 and VIM 308. The Or_EM interface provides fault tolerance for any event failure. In an example, the Or_EM interface may send different type of service requests from the microservice of the NFVO 304 to another microservice or group of microservice in the CNFM 306 using the event name or the NFVO 304 to another microservice or group of microservice in the VIM 308. The Or_EM interface operates in a high availability mode and if one ERM instance goes down during service request processing then next available instance may take care of the service request.
[00125] To further elaborate, the Or_EM interface is crucial for facilitating communication between the NFVO 304 and the CNFM 306. The Or_EM interface is responsible for managing the overall orchestration of the CNF. The Or_EM interface takes high-level service requests, translates these service requests into specific resource and VNF configurations, and manages the lifecycle of VNF instances. The Or_EM interface is also crucial for facilitating communication between the NFVO 304 and the VIM 308. The Or_EM interface is responsible for managing the overall orchestration of the CNF and virtualized infrastructure resources. The Or_EM interface takes high-level service requests and manages the underlying infrastructure resources required for virtualization.
[00126] The Or_EM interface serves the orchestration request generated from the NFVO 304 and sends the request to the CNFM 306 and/or the VIM 308. The Or_EM interface supports asynchronous event-based implementation to utilize the interface efficiently between the NFVO 304 and the CNFM 306, and the NFVO 304 and VIM 308. Furthermore, the Or_EM interface supports guaranteed message delivery for acknowledgement and delivery reports incorporated and gives the flexibility to execute mutually exclusive events in parallel. The Or_EM interface supports the subscriber and publisher model.
[00127] The second network interface (i.e., the EM_Cnfm interface) is coupled with the CNFM 306 and is configured to establish the communication between the ERM 302 and the CNFM 306. In an embodiment, the CNFM 306 is configured to receive the service request from the ERM 302 via the EM_Cnfm interface. Further, the CNFM 306 is configured to transfer the acknowledgement (along with the delivery report) to the ERM 302 based on processing the service request. The EM_Cnfm interface is configured to translate the received service requests into specific resource and VNF configurations and manage the lifecycle of the VNF instances. The EM_Cnfm interface is configured to forward the translated service request to a specific microservice associated with the CNFM 306 for processing the translated service request. The processing of the translated service request includes resource provisioning and initiating via the CNFM 306. After the service request processing, the specified microservice associated with the CNFM 306 is configured to generate the acknowledgement (also referred to as an event acknowledgment). The EM_Cnfm interface of the ERM 302 is configured to receive the acknowledgment from the CNFM 306 and for the acknowledgement to the network element for which the service request was received. In other words, the ERM 302 is configured to route the service request to a specified microservice using the EM_Cnfm interface to allocate the necessary resources by spawning the resources. The spawning of the resources on the MANO framework corresponds to a process of creating or provisioning new resources, such as virtual machines, containers, or network functions, based on incoming service requests, i.e., the at least one service request. The process of the spawning involves initializing and configuring the resources, so they are ready for use within the MANO framework. In an example, the EM_Cnfm interface is used to route different types of service requests received from the target microservice of the NFVO 304 via the EM_Or interface to another microservice or a group of microservices in the CNFM 306 using the event name, or to another microservice or a group of microservice in the VIM 308 via the ERM 302. The EM_Cnfm interface is configured to operate in a high availability mode, ensuring continuity of the service processing.
[00128] In an example, the Or_EM interface and the EM_Cnfm interface may configured to provide communication between the CNFM 306 and the NFVO 304 via the ERM 302 for the at least one service request, for example, the container life cycle management, the resource allocation and management, the fault management and recovery, the resource optimization and scaling decisions.
[00129] In an example, the CNFM 306 may interact with the VIM 308 to request and allocate resources for performing operations to process the service. The CNFM 306 may interact with the VIM 308 via the EM_Cnfm and the third interface, i.e., the EM_Vi interface associated with the ERM 302. The CNFM 306 may interact with the VIM 308 to get information regarding a state and a health of the underlying virtualized infrastructure optimizing the resource allocation to ensure efficient use of the underlying virtualized infrastructure resources.
[00130] In an example, the third network interface (i.e., the EM_Vi interface) is coupled with the VIM 308 and is configured to establish communication between the VIM 308 and the ERM 302. The EM_Vi interface enables dynamic and efficient communication between the microservice associated with the VIM in the MANO framework. The EM_Vi interface works in a high availability mode and if one ERM instance goes down during the service request processing then next available instance will take care of the service request. The EM_Vi interface may send different types of the service requests received from the microservice (i.e., the target microservice) of the NFVO 304 via the Or_EM interface associated with the ERM 302 to another microservice or a group of microservices in the VIM 308 using the event name, or to another microservice or a group of microservice in the NFVO 304 via the Or_EM interface of the ERM 302.
[00131] In an embodiment, the EM_Cnfm interface and the EM_Vi interface is crucial in facilitating communication between the CNFM 306 and the VIM 308. The EM_Vi interface is responsible to take the service requests received from the CNFM 306 via the EM_Cnfm interface and manage the underlying virtualized infrastructure resources required for virtualization. The EM_Vi interface and the Or_EM interface also plays a crucial role in facilitating communication between the VIM 308 and the NFVO 304. The EM_Vi interface is responsible to take a high-level service requests received from the NFVO 304 via the Or_EM interface, translate the high-level service requests into a specific resource and VNF configurations, and manage the lifecycle of VNF instances. Using the EM_Vi interface and the Or_EM interface, the VIM 308 communicates with the NFVO 304 to ensure the resource allocation aligns with network service requirements.
[00132] In an embodiment, the ERM 302 is coupled with an Operations, Administration, and Maintenance (OAM) module (also referred to as an OAM 310). The OAM 310 is configured to perform operations, administration, and maintenance of a plurality of activities involved in managing and maintaining a system or a process. The ERM 302 may be configured to process the received service requests to generate at least one specific resource configuration.
[00133] In an embodiment, a memory (e.g., the memory 204) may be associated with the ERM 302. The memory is configured to store program instructions and data corresponding to a plurality of service requests. The memory is configured to store a list of registered service requests, a list of status associated with the received service requests, and a list of microservices corresponding to each of the list of registered service requests. The program instructions include a program that implements a method for providing enhanced interconnectivity for communicating data between the microservices associated various components (i.e., the NFVO 304, the CNFM 306, and the VIM 308) of the MANO framework in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification. The memory may include any computer-readable medium known in the art including, for example, volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM), and/or nonvolatile memory, such as Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[00134] In an aspect, the ERM 302 is configured to receive the plurality of service requests (also referred to as the events). The ERM 302 may further be configured to publish (or route) each of the plurality of service request to the microservices (i.e., the target microservice or the one or more microservices) associated with the MANO framework. Each of the plurality of service request is subscribed to by a specific microservice (subscriber microservice). For example, the ERM 302 may enable dynamic and efficient communication between the microservices of the NFVO 304 associated with the MANO framework via the Or_EM interface.
[00135] In an aspect, the ERM 302 is configured to operate in a deferred event configuration. If deferred event configuration is enabled for any event (i.e., a service request), the ERM 302 may automatically retry such event processing even if an initial delivery failed. The deferred event configuration in a virtualized infrastructure refers to managing events and their handling in a way that delays or schedules the processing of certain events to optimize performance, resource utilization, or system responsiveness. In an example, in case of fault management and recovery, handling fault events or triggering recovery actions might be deferred to prevent immediate system strain. The event includes fault detection, recovery action request. The deferred handling includes queue fault recovery actions and prioritize based on severity. The fault management system schedules recovery actions (e.g., queuing and prioritizing recovery actions).
[00136] In an embodiment, the ERM 302 is configured to provide a deferred delivery in case the specific microservice of a subscriber (e.g. the NFVO 304, the CNFM 306, or the VIM 308) fails. In such a scenario, the ERM 302 is configured to store the event and may communicate the event to the specific microservice after a predefined time interval (e.g., 15 minutes).
[00137] In an aspect, the ERM 302 may play an essential role in event-driven systems where an event (i.e., the service request) need to be delivered from an event source, i.e., a publisher (e.g., the actor or the NFVO 304) to appropriate event consumers or downstream services, i.e., subscribers, such as the CNFM 306 or the VIM 308. The ERM 302 is configured to provide the event distribution by efficiently distributing the event to multiple event consumers or the downstream services based on the event name. Further, the ERM 302 helps in adding multiple event producers and event consumers in the event-driven systems without affecting the overall functionality or performance of the system (e.g., the system 108). The ERM 302 supports dynamic routing in the event-driven systems by enabling the system to adapt to changing requirements. The ERM 302 provides various mechanisms (e.g., a retry mechanism) to handle errors or failures during the event routing and ensure reliable delivery of each event even in transient failures or network issues.
[00138] In an aspect, the Or_EM interface provides the guaranteed message delivery with acknowledgement and delivery report. Further, the Or_EM interface enables automatic detection of failed service requests and facilitates the rerouting of service requests to alternative healthy instances or services, thereby improving overall resilience and minimizing downtime of the network. In an aspect, the ERM (130) may be configured to provide advanced automation features and enhanced scalability. In an embodiment, the ERM 302 facilitates sending a selective service request to a group of NFVOs that have subscribed to that specific service request
[00139] FIG. 4 illustrates a MANO framework architecture 400, in accordance with embodiments of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3.
[00140] As depicted in FIG. 4, the MANO framework architecture 400 may comprise several interconnected modules that work together to enable efficient resource allocation and management. These modules may include a user interface layer 402, NFV and Software-Defined Networking (SDN) design functions 404, platform foundation services 406, platform core services 408, a platform operation, administration, and maintenance manager 410, and platform resource adapters and utilities 412. The user interface layer 402 may serve as a primary point of interaction for network operators and network administrators. Through the user interface layer 402, various parameters associated with the ERM 302 may be configured and adjusted based on specific requirements. These parameters may include a number of microservices associated with ERMs, a number of ERMs that can be deployed simultaneously, and other relevant settings.
[00141] The NFV and SDN design functions 404 may work in conjunction with the platform core services 408 to analyze and route the service requests received by the ERM 302. These modules may be responsible for determining the target microservice within the MANO framework based on a type of the resource allocation required. These modules may utilize a mapping of service request types to target microservices maintained by the ERM 302 to ensure accurate routing of each service request. The NFV and SDN design functions 404 may include a Virtual Network Function (VNF) lifecycle manager (compute) that is a specialized component focused on managing compute resources associated with a VNF throughout their lifecycle. The NFV and SDN design functions 404 may include a VNF catalog that is a repository that stores and manages metadata, configurations, and templates for the VNF, facilitating their deployment and lifecycle management. The NFV and SDN design functions 404 may include a network services catalog, a network slicing and service chaining manager, a physical and virtual resource manager, and a CNF lifecycle manager. The network services catalog serves as a repository for managing and storing detailed information about network services, including their specifications and deployment requirements. The network slicing and service chaining manager is responsible for orchestrating network slices and service chains, ensuring efficient allocation and utilization of the network resources tailored to various services. The physical and virtual resource manager oversees both the physical resources and the virtual resources, handling their allocation, monitoring, and optimization to ensure seamless operation across the network infrastructure. The CNF lifecycle manager manages the complete lifecycle of a CNF, including onboarding, instantiation, scaling, monitoring, and termination, thereby facilitating the efficient deployment and operation of network functions in a cloud-native environment.
[00142] The platform foundation services 406 may support an asynchronous event-based processing model implemented by the ERM 302, enabling concurrent handling of the multiple service requests. They may also facilitate bi-directional communication interfaces (a Network Management System Event Routing Manager (NMS_EM) interface and an Event routing Manager Microservice (EM_MS)) used by the ERM 302 to interact with the external systems and the MANO framework microservices. The platform foundation services 406 may include a microservices elastic load balancer, an identity & access manager, a Command Line Interface (CLI), a central logging manager, and a ERM (e.g., the ERM 302). The microservices elastic load balancer ensures that incoming traffic (i.e., the service requests) is evenly distributed across multiple microservices, enhancing performance and availability. The identity & access manager handles user identity management and access control, enforcing permissions and roles to secure resources and services. The CLI offers a text-based method for users to interact with the MANO framework, enabling command execution and configuration management. The central logging manager consolidates log data from various system components, providing a unified view for effective monitoring, troubleshooting, and data analysis.
[00143] The platform core services 408 are central to the processing and fulfillment of the service requests (i.e., the at least one service request). The platform core services 408 may work together to allocate network slices, manage virtualized network functions, and orchestrate the underlying virtualized infrastructure resources based on each of the at least one service request routed by the ERM 302. The platform core services 408 may include an NFV infrastructure monitoring manager, an assurance manager, a performance manager, a policy execution engine, a capacity monitoring manager, a release management repository, a configuration manager and Golden Configuration Template (GCT), a NFV platform decision analytics platform, a Not Only Structured Query Language (SQL) database (NoSQL DB), platform schedulers & jobs, a VNF backup & upgrade manager, and a microservice auditor. The NFV infrastructure monitoring manager tracks and oversees the health and performance of the NFV infrastructure. The assurance manager ensures service quality and compliance with operational standards. The performance manager monitors the system performance metrics to optimize efficiency. The policy execution engine enforces and executes policies across the MANO framework. The capacity monitoring manager tracks the resources usage and forecasts future needs. The release management repository manages software releases and version control. The configuration manager handles the system configurations, ensuring consistency and automation. The GCT provides a centralized oversight and a management of the MANO framework operations. The NFV platform decision analytics platform utilizes data analytics to support decision-making. The NoSQL DB stores unstructured data to support flexible and scalable data management. The platform schedulers and jobs automate and schedule routine tasks and workflows. The VNF backup and upgrade manager oversees the backup and upgrading of VNFs. The microservice auditor ensures the integrity and compliance of the microservices across the MANO framework.
[00144] The platform operation, administration, and maintenance manager 410 (i.e., the OAM 310) may oversee operational aspects of the MANO framework architecture (400). The platform operation, administration, and maintenance manager 410 may be responsible for implementing a load-balancing mechanism used by the ERM 302 to distribute the service requests across multiple instances of the MANO framework microservices.
[00145] The platform resource adapters and utilities 412 may provide necessary tools and interfaces for interacting with an underlying network infrastructure, i.e., the NFV architecture. These components may be crucial in translating the service requests into actionable commands for the resources (also referred to as the network resources) allocation and management. The platform resource adapters and utilities 412 may work closely with the platform core services 408 to ensure that allocated resources meet specified requirements. Together, these modules create a cohesive and efficient system for managing the resources allocation. The platform resource adapters and utilities 412 may include a platform external Application Programming Interface (API) adapter and gateway, a generic decoder and indexer, a swarm adaptor, an open stack API adapter, and a NFV gateway. The platform external API adapter and gateway facilitates seamless integration with external APIs and manages data flow between the external systems and the MANO framework. The generic decoder and indexer processes and organizes data from various formats such as an eXtensible Markup Language (XML), a Comma Separated Values (CSV), and a JavaScript Object Notation (JSON), ensuring compatibility and efficient indexing. The swarm adaptor manages interactions with swarm clusters, enabling container orchestration and scaling. The API adapter interfaces with services, allowing integration and management of cloud resources. Finally, the NFV gateway acts as a bridge for NFV communications, coordinating between NFV components and other platform elements.
[00146] The ERM 302 may interact with all these modules to facilitate an end-to-end process of a service request handling. The ERM 302 may receive the service requests through the user interface layer 402, utilize the NFV and SDN design functions 404 for the service requests analysis, leverage the platform core services 408 for the service requests fulfillment and use the platform resource adapters and utilities 412 for actual resources allocation for each of the service requests. The platform operations, administration and maintenance manager 410 may oversee this entire process, ensuring efficient operation and fault tolerance. This integrated approach may enable the MANO framework to efficiently manage a complex process of the resources allocation and management, potentially providing a flexible and responsive system capable of meeting diverse service requirements in a dynamic network environment.
[00147] FIG. 5 illustrates an exemplary process flow 500 depicting interconnectivity between the one or more components associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure, The ERM may correspond to the ERM 302. Further, the MANO framework may include the NFVO 304, the CNFM 306, and the VIM 308. In an embodiment, the MANO framework may also include the OAM 310. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3, and 4.
[00148] At step 504, at least one service request (also referred to as the event) may be generated and sent by a network entity 502 (actor 502) to the ERM 302. Examples of the network entity 502 include a router, a switch, a host, a modem, a terminal, a dial access server, a gateway, a port, a channel, an interface, a circuit, a process, a driver, a protocol, a service, an application, etc. Examples of the at least one service request may include, but are not limited to, the container life cycle management request, the resource allocation and management request, the fault management and recovery request, and the resource optimization and scaling request. In some embodiments, the at least one service request includes a provision resource request, a create resource request, and an initialize resource request. Upon receiving the at least one service request, the ERM 302 is configured to determine whether the at least one service request is a valid service request or an invalid service request. In an example, if the at least one service request exists within a memory (e.g., the memory 204) associated with the ERM 302, then the at least one service request is the valid service request. The memory associated with the ERM 302 may contain a repository of valid service request templates (i.e., a list of valid service request templates) or identifiers, serving as a reference for this validation process. In some embodiments, the memory including the repository of valid service request templates, or the identifiers may be present within the ERM 302. If the at least one service request is the invalid service request, the ERM 302 may discard the invalid service request.
[00149] Upon determining the at least one service request to be the valid service request, at step 506, the ERM 302 may be configured to route the at least one service request to the NFVO 304. The ERM 302 may route the at least one service request to the NFVO 304 via the Or_EM interface. In an example, the ERM 302 is configured to analyze the received at least one service request to allocate a specific microservice (i.e., the determined microservice) associated with the MANO framework. For example, if based on the analysis the ERM 302 determines that the at least one service request is the provision resource request, then the ERM 302 forwards the received at least one service request to the NFVO 304. In other words, the ERM 302 forwards the received at least one service request to a microservice (i.e., the determined microservice) of the NFVO 304. The NFVO 304 is configured to perform resource orchestration and network service orchestration based on the at least one service request received from the ERM 302.
[00150] Further, at step 508, the NFVO 304 is configured to process the at least one service request to determine whether the at least one service request is an internal service request or an external service request. In other words, the NFVO 304 is configured to process the at least one service request to determine whether the NFVO 304 may be able to cater the at least one service request using associated microservices internally or requires transmission of the at least one service request to the one or more microservices associated with the CNFM 306, or the VIM 308, or both.
[00151] In one embodiment, based on processing the at least one service request, upon determining the at least one service request to be the internal service request, the target microservice of the NFVO 304 is configured to process the at least one service request to generate the acknowledgement corresponding to the at least one service request. Further, the generated acknowledgement may be transmitted by the NFVO 304 to the ERM 302 via the Or_EM interface. The ERM 302 may further transmit the acknowledgement generated corresponding to the at least one service request to the network entity 502. Further, in some embodiments, the acknowledgement may be rendered to the network operator (e.g., the user 102). In another embodiment, based on processing the at least one service request, upon determining the at least one service request to be the external service request, the target microservice of the NFVO 304 is configured to determine the one or more microservices for processing the at least one service request.
[00152] Further, upon determining the one or more microservices required for processing the at least one service request, the NFVO 304 is configured to generate an orchestration request. In an embodiment, the orchestration request may include a set of instructions (i.e., the data identifying the one or more microservices of the CNFM 306) to be followed by the CNFM 306. In an aspect, the NFVO 304 is responsible for onboarding of the VNFs and the network services that are managed by the same or different VNF managers. Once the orchestration request is generated, at step 510, the NFVO 304 is configured to transfer the orchestration request to the ERM 302 via the Or_EM interface.
[00153] At step 512, the ERM 302 is configured to route the orchestration request to the CNFM 306. In an example, the orchestration request may correspond to the container life cycle management request, the resource allocation and management request, the fault management and recovery request, and the resource optimization and scaling request. Further, the ERM 302 may analyze the received orchestration request to allocate a specific microservice or a group of microservices (i.e., the one or more services of the CNFM 306) associated with the MANO framework accordingly. In an example, the ERM 302 may allocated a group of microservices associated with the CNFM 306, the VIM 308, or both, for the received orchestration request. Further, the ERM 302 may forwarding the orchestration request to the CNFM 306 via the EM_Cnfm interface. At step 514, the CNFM 306 is configured to process the received orchestration request via the one or more microservices of the CNFM 306 and generating an orchestration request. The orchestration request may include a set of instructions (the data identifying the one or more microservices of the VIM 308) to be followed by the VIM 308 to process the orchestration request. At step 516, the CNFM 306 may forward the orchestration request to the ERM 302 via the EM_Cnfm interface for further processing. At step 518, the ERM 302 is configured to forward the orchestration request received from the CNFM 306 to the VIM 308 via the EM_Vi interface.
[00154] At step 520, the VIM 308 is configured to process the orchestration received from the ERM 302 to generate the acknowledgement (depicted as a service request acknowledgment). In an example, the step 520 may include a step of generating at least one information by the VIM 308. In an example, the at least one information includes a state of the underlying virtualized infrastructure associated with the one or more microservices of the VIM 308. At step 522, the VIM 308 is configured to send the service request acknowledgment to the ERM 302 via the EM_Vi interface. At step 524, the ERM 302 may send the service request acknowledgment to the network entity 502 The service request acknowledgment may correspond to an update signal that is transmitted to the network entity 502 indicating a status of the orchestration request processed by the CNFM 306. In an example, the status may be a success (i.e., the positive acknowledgment) or a failure (i.e., the negative acknowledgment) in fulfilling of the orchestration request.
[00155] FIG. 6 illustrates another exemplary process flow 600 depicting interconnectivity between the one or more components associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure. The ERM may correspond to the ERM 302. Further, the MANO framework may include the NFVO 304, the CNFM 306, and the VIM 308. In an embodiment, the MANO framework may also include the OAM 310. FIG. 6 is explained in conjunction with FIGS. 1, 2, 3, 4, and 5.
[00156] Initially, at step 602, the at least one service request (also referred to as the event) may be generated and send by the network entity 502. Upon receiving the at least one service request, the ERM 302 is configured to determine whether the at least one service request is the valid service request or the invalid service request. In an example, if the at least one service request exists within the memory (e.g., the memory 204) associated with the ERM 302, then the at least one service request is the valid service request. In one embodiment, upon determining the at least one service request to be the valid service request, the ERM 302 is configured to route the at least one service request to the NFVO 304 as mentioned via step 604. The ERM 302 may route the at least one service request to the NFVO 304 via the Or_EM interface. In another embodiment, upon determining the at least one service request to be the invalid service request, the ERM 302 may discard the invalid service request.
[00157] At step 606, the NFVO 304 is configured to process the at least one service request to determine whether the at least one service request is the internal service request or the external service request. In one embodiment, based on processing the at least one service request, upon determining the at least one service request to be the internal service request, the target microservice of the NFVO 304 is configured to process the at least one service request to generate the acknowledgement corresponding to the at least one service request. Further, the generated acknowledgement may be transmitted by the NFVO 304 to the ERM 302 via the Or_EM interface. The ERM 302 may further transmit the acknowledgement generated corresponding to the at least one service request to the network entity 502. Further, in some embodiments, the acknowledgement may be rendered to the network operator (e.g., the user 102).
[00158] In another embodiment, based on processing the at least one service request, upon determining the at least one service request to be the external service request, the NFVO 304 is configured to determine the one or more microservices for processing the at least one service request. Further, upon determining the one or more microservices required for processing the at least one service request, the NFVO 304 is configured to generate an orchestration request. In an embodiment, the orchestration request may include a set of instructions (i.e., the data identifying the one or more microservices of the VIM 308) to be followed by the VIM 308. Once the orchestration request is generated, at step 608, the NFVO 304 is configured to transfer the orchestration request to the ERM 302 via the Or_EM interface.
[00159] At step 610, the ERM 302 is configured to route the orchestration request to the VIM 308 via the EM_Vi interface. In order to route the orchestration request to the VIM 308, the ERM 302 is configured to identify at least one configuration corresponding to the orchestration request based on the service discovery mechanism for routing the at least one service request to the one or more microservices of the VIM 308. At step 612, the VIM 308 is configured to process the orchestration request. In particular, the one or more microservices associated with the VIM 308 is configured to process the orchestration request and generate an orchestration request. In an example, the VIM 308 is configured to automate the development, deployment, maintenance, and operation of the network to effectively handle escalating demand, accelerate deployments, and reduce complexity.
[00160] Further, at step 614, the VIM 308 is configured to send the orchestration request to the ERM 302. The orchestration request sent by the VIM 308 may include the set of instructions (i.e., the data identifying the one or more microservices of the CNFM 306) to be followed by the CNFM 306 for processing the orchestration request. At step 616, the ERM 302 is configured to route the orchestration request to the CNFM 306 via the EM_Cnfm interface. In order to route the orchestration request to the CNFM 306, the ERM 302 is configured to identify at least one configuration corresponding to the orchestration request based on the service discovery mechanism for routing the at least one service request to the one or more microservices of the CNFM 306. The CNFM 306 is configured process the orchestration request to generate an acknowledgement (depicted as a service request acknowledgment) as mentioned via step 618.
[00161] Further, at step 620, the CNFM 306 is configured to send the service request acknowledgment to the ERM 302 via the EM_Cnfm interface. At step 622, the ERM 302 further transmits the service request acknowledgment to the network entity 502. The service request acknowledgment may correspond to an update signal that is transmitted to the network entity 502 indicating a status of the orchestration request processed by the CNFM 306. In an example, the status may be a success (i.e., the positive acknowledgment) or a failure (i.e., the negative acknowledgment) in fulfilling of the orchestration request.
[00162] FIG. 7 illustrates an exemplary flow diagram of a method 700 for providing interconnectivity between the one or more components associated with the MANO framework, in accordance with embodiments of the present disclosure. The MANO framework may include the NFVO 304, the CNFM 306, and the VIM 308. In an embodiment, the MANO framework may also include the OAM 310. FIG. 7 is explained in conjunction with FIGS. 1, 2, 3, 4, 5, and 6.
[00163] At step 702, the method 700 includes receiving, by the NFVO 304, at least one service request from the ERM 208, 302 via an associated network interface. The at least one service request comprises a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request. The associated network interface is an Orchestrator_ Event routing Manager (Or_EM) interface.
[00164] At step 704, the method 700 includes extracting, by the NFVO 304, one or more parameters from the at least one received service request. In an aspect, the one or more extracted parameters comprise at least one of a network entity identifier (ID) and a service request type, and wherein the service request type comprises one or more key performance indicators (KPIs) and one or more issues associated with the network entity.
[00165] At step 706, the method 700 includes processing, by the NFVO 304, the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request. In an embodiment, the at least orchestration request includes at least one operation request associated with resources, and the at least one operation request is one of a creation of the resources, allocation of the resources, and deallocation of the resources.
[00166] In an embodiment, the processing of the at least one received service request may include analyzing, by the NFVO 304, the one or more KPIs associated with the network entity, comparing, by the NFVO 304, the analyzed one or more KPIs with one or more threshold values, and generating, by the NFVO 304, the at least one orchestration request when the one or more KPIs exceed or fall below the one or more threshold values.
[00167] In an alternative embodiment, the processing of the at least one received service request may include analyzing, by the NFVO 304, the one or more issues associated with the network entity, and generating, by the NFVO 304, the at least one orchestration request based on analyzing the one or more issues.
[00168] At step 708, the method 700 includes determining, by the NFVO 304, at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request. The at least one component may include the CNFM 306 and the VIM 308.
[00169] Once the orchestration request is generated and the least one network service associated with the at least one component of the MANO framework is determined, the method 700 further includes receiving, by the ERM 208, 302, the least one generated orchestration request from the NFVO 304. The method 700 further includes routing, by the ERM 208, 302, the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface.
[00170] FIG. 8 illustrates an exemplary computer system 800 in which or with which embodiments of the present disclosure may be implemented.
[00171] As shown in FIG. 8, the computer system 800 may include an external storage device 810, a bus 820, a main memory 830, a read-only memory 840, a mass storage device 850, communication port(s) 860, and a processor 870. A person skilled in the art will appreciate that the computer system 800 may include more than one processor and communication ports. The processor 870 may include various modules associated with embodiments of the present disclosure. The communication port(s) 860 may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 860 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 800 connects.
[00172] The main memory 830 may be Random-Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 840 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor 870. The mass storage device 850 may be any current or future mass storage solution, which can be used to store information and/or instructions. The mass storage device 850 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, a Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.
[00173] The bus 820 communicatively couples the processor 870 with the other memory, storage, and communication blocks. The bus 820 may be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 870 to the computer system 800.
[00174] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 820 to support direct operator interaction with the computer system 800. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 860. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 800 limit the scope of the present disclosure.
[00175] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skills in the art.
[00176] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.\While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.
[00177] The present disclosure provides technical advancement related to providing interconnectivity between the one or more components associated with a management and orchestration (MANO) framework. This advancement addresses the limitations of existing solutions by enabling dynamic interconnectivity and efficient routing of orchestration and service requests between microservices within the MANO framework. The disclosure involves the Or_EM interface, which significantly improves communication efficiency and resource management. By implementing the Or_EM interface, the disclosed invention enhances the communication between the NFVO and other network functions such as, the CNFM and the VIM, resulting in optimized resource allocation, reduced processing delays, and improved fault management in virtualized network environments.
TECHNICAL ADVANTAGES OF THE PRESENT DISCLOSURE
[00178] The present disclosure provides a method and a system for providing interconnectivity between one or more components of a management and orchestration (MANO) framework via a network interface (e.g., an Orchestrator_ Event routing Manager (Or_EM) interface).
[00179] The present disclosure provides the Or_EM interface that connects a network function virtualization orchestrator (NFVO) of the MANO framework and an event routing manager (ERM).
[00180] The present disclosure provides the Or_EM interface that guarantees message delivery with an acknowledgment and a delivery report.
[00181] The present disclosure provides a method and a system that enables the automatic detection of failed services (i.e., service requests) and facilitates rerouting of the service requests to alternative healthy instances or the microservices associated with the MANO framework.
[00182] The present disclosure enables asynchronous communication between various components (i.e., a Network Functions Virtualization Orchestrator (NFVO), a Containerized network function’ (CNF) manager, a Virtualized Infrastructure Manager (VIM)) of the MANO framework via the Or_EM interface.
,CLAIMS:CLAIMS
We Claim:
1. A method (700) for providing interconnectivity between one or more components of a management and orchestration (MANO) framework, the method (700) comprising:
receiving (702), by a network function virtualization orchestrator (NFVO) (304), at least one service request from an event routing manager (ERM) (208, 302) via an associated network interface;
extracting (704), by the NFVO (304), one or more parameters from the at least one received service request;
processing (706), by the NFVO (304), the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request; and
determining (708), by the NFVO (304), at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request.

2. The method (700) as claimed in claim 1, further comprising:
receiving, by the ERM (208, 302), the least one generated orchestration request from the NFVO (304); and
routing, by the ERM (208, 302), the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface.

3. The method (700) as claimed in claim 1, wherein the associated network interface is an Orchestrator_ Event routing Manager (Or_EM) interface.

4. The method (700) as claimed in claim 1, wherein the at least one service request comprises a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request.

5. The method (700) as claimed in claim 1, wherein the one or more extracted parameters comprise at least one of a network entity identifier (ID) and a service request type, and wherein the service request type comprises one or more key performance indicators (KPIs) and one or more issues associated with the network entity.

6. The method (700) as claimed in claim 5, wherein processing the at least one received service request comprising:
analyzing, by the NFVO (304), the one or more KPIs associated with the network entity;
comparing, by the NFVO (304), the analyzed one or more KPIs with one or more threshold values; and
generating, by the NFVO (304), the at least one orchestration request when the one or more KPIs exceed or fall below the one or more threshold values.

7. The method (700) as claimed in claim 5, wherein processing the at least one received service request comprising:
analyzing, by the NFVO (304), the one or more issues associated with the network entity; and
generating, by the NFVO (304), the at least one orchestration request based on analyzing the one or more issues.

8. The method as claimed in claim 1, wherein the at least orchestration request comprises at least one operation request associated with resources, and wherein the at least one operation request is one of a creation of the resources, allocation of the resources, and deallocation of the resources.

9. A system (108) for providing interconnectivity between one or more components of a management and orchestration (MANO) framework, the system (108) comprising:
an Event Routing Manager (ERM) (208, 302) communicatively coupled with a network function virtualization orchestrator (NFVO) (304) of the MANO framework, wherein the NFVO (304) is configured to:
receive at least one service request from the ERM (208, 302) via an associated network interface;
extract one or more parameters from the at least one received service request;
process the at least one received service request based on the extracted one or more parameters to generate at least one orchestration request; and
determine at least one network service associated with at least one component of the MANO framework based on the at least one generated orchestration request.

10. The system (108) as claimed in claim 9, wherein the ERM (208, 302) is configured to:
receive the least one generated orchestration request from the NFVO (304); and
route the least one generated orchestration request to the determined at least one network service associated with the at least one component of the MANO framework via the associated network interface.

11. The system (108) as claimed in claim 9, wherein the associated network interface is an Orchestrator_ Event routing Manager (Or_EM) interface.

12. The system (108) as claimed in claim 9, wherein the at least one service request comprises a container life cycle management request, a resource allocation and management request, a fault management and recovery request, and a resource optimization and scaling request.

13. The system (108) as claimed in claim 9, wherein the one or more extracted parameters comprise at least one of a network entity identifier (ID) and a service request type, and wherein the service request type comprises one or more key performance indicators (KPIs) and one or more issues associated with the network entity.

14. The system (108) as claimed in claim 13, wherein to process the at least one received service request, the NFVO (304) is configured to:
analyze the one or more KPIs associated with the network entity;
compare the analyzed one or more KPIs with one or more threshold values; and
generate the at least one orchestration request when the one or more KPIs exceed or fall below the one or more threshold values.

15. The system (108) as claimed in claim 13, wherein to process the at least one received service request, the NFVO (304) is configured to:
analyze the one or more issues associated with the network entity; and
generate the at least one orchestration request based on the analyzed one or more issues.

16. The system (108) as claimed in claim 9, wherein the at least orchestration request comprises at least one operation request associated with resources, and wherein the at least one operation request is one of a creation of the resources, allocation of the resources, and deallocation of the resources.