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

METHOD AND SYSTEM FOR MANAGING COMMUNICATION BETWEEN NETWORK SERVICES ASSOCIATED WITH 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 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 relates generally to a field of wireless communication systems. More particularly, the present disclosure relates to a method and a system for managing communication between network services associated with 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 ‘Management and Orchestration (MANO) framework’ used hereinafter in the specification refers to a framework that manages and orchestrates virtualized network functions and resources in a Network Functions Virtualization (NFV) environment.
[0005] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to an intermediary component that facilitates communication between network services associated with the MANO framework, routing service requests and responses to network slice allocations, and resource allocation and management.
[0006] 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.
[0007] The expression ‘Container Network Function (CNF) manager’ used hereinafter in the specification refers to a network function designed and implemented for a cloud-native environment, packaged as a container, and configured to determine the lifecycle of CNF instances.
[0008] 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).
[0009] 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 Virtual Network Functions (VNFs) and their associated resources.
[0010] The expression ‘Virtualized Network Function (VNF)’ used hereinafter in the specification refers to a software implementation of a network function that runs on the NFV infrastructure and can be deployed on a virtual machine.
[0011] The expression ‘event’ used hereinafter in the specification refers to a specific action that can trigger a system to take a particular action. In an example, the event may include service requests, network traffic, system configuration changes, security incidents, and the like.
[0012] The expression ‘network services’ used hereinafter in the specification refers to a software architectural style where an application is structured as a collection of small, independent services that communicate over a network. In the context of the MANO framework, the network services are used to manage and automate various network functions and services, enabling flexibility, scalability, and efficient resource utilization.
[0013] The expression ‘at least one configuration’ used hereinafter in the specification refers to specific settings and parameters used to direct the service requests to an appropriate network service associated with the MANO framework within the network.
[0014] The expression ‘service discovery mechanism’ used hereinafter in the specification refers to a process or a technique used to locate and route the service requests to the appropriate network service associated with the MANO framework. The service discovery mechanism dynamically identifies available network services and their instances, using a method like a round robin technique to distribute the service requests efficiently across these network services.
BACKGROUND
[0015] 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.
[0016] In the realm of Network Functions Virtualization (NFV), a Management and Orchestration (MANO) architecture is pivotal for the effective deployment and management of virtualized network services. The MANO architecture 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, these three essential components must interact with each other smoothly and flexibly. Each element of these three components relies on communication with each other to perform its functions efficiently for deploying and managing the virtualized network services.
[0017] When any of these three components (or associated network services) fail to communicate with each other, several significant issues may arise, such as network service deployment delays or failures, resource misallocation and inefficiency, 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 these 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 these three components and the associated network services to maintain the overall functionality and effectiveness of the MANO architecture.
[0018] Therefore, there is a need to provide a method and a system that provides effective communication management between the network services associated with the MANO framework.
OBJECTIVES
[0019] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0020] An objective of the present disclosure is to provide a method and a system for managing communication between network services associated with a Management and Orchestration (MANO) framework via an Event Routing Manager (ERM). The ERM serves as a crucial intermediary, connecting the network services associated with the MANO framework
[0021] An objective of the present disclosure is to provide a method and a system that implements intelligent service request routing to specific MANO framework network services, ensuring optimal resource allocation and improving overall network performance.
[0022] Another objective of the present disclosure is to provide an interface that provides a guaranteed message delivery with an acknowledgement and a delivery report.
[0023] 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 network services associated with the MANO framework.
[0024] 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 Container network function’ (CNF) manager, a Virtualized Infrastructure Manager (VIM)) of the MANO framework via an associated interface.
[0025] Another objective of the present disclosure is to provide an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface that connects the ERM and the VIM of the MANO framework. The VIM facilitates efficient resource management by processing the service requests received from the NFVO and the CNFM. The VIM translates high-level service requests into specific resource configurations, manages the lifecycle of Virtual Network Function (VNF) instances, and ensures optimal resource allocation to meet network service requirements.
[0026] Other objects 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
[0027] In an exemplary embodiment, a method for managing communication between network services associated with a Management and Orchestration (MANO) framework is disclosed. The method includes receiving, by an Event Routing Manager (ERM), at least one orchestration request based on at least one service request, from at least one network service associated with one of a Network Function Virtualization Orchestrator (NFVO) and a Containerized Network Function (CNF) Manager (CNFM) of the MANO framework. The at least one service request is received from a network element. The method includes processing, by the ERM, the at least one orchestration request to identify one or more network services associated with a Virtualized Infrastructure Manager (VIM) of the MANO framework. The method includes upon identifying the one or more network services, routing, by the ERM, the at least one orchestration request to the one or more network services associated with the VIM using an associated interface for processing of the at least one orchestration request.
[0028] In an embodiment, the at least one service request includes 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.
[0029] In an embodiment, the method further includes identifying, by the ERM, at least one configuration corresponding to the at least one orchestration request based on a service discovery mechanism for routing the at least one orchestration request to the one or more network services using the associated interface, upon identifying the one or more network services for processing the at least one orchestration request.
[0030] In an embodiment, the method includes receiving, by the ERM, an acknowledgement based on processing of the at least one orchestration request from a network service of the one or more network services using the associated interface, in response to routing the at least one orchestration request.
[0031] In an embodiment, the associated interface of the VIM is an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.
[0032] In an embodiment, the acknowledgement includes at least one of a positive acknowledgement indicating a successful fulfillment of the at least one service request, and a negative acknowledgement indicating a failure to fulfill the at least one service request.
[0033] In an embodiment, when the acknowledgement is the negative acknowledgement, the ERM is configured to reschedule processing of the at least one service request after a pre-defined time period.
[0034] In another exemplary embodiment, a system for managing communication between network services associated with a Management and Orchestration (MANO) framework is disclosed. The system including an Event Routing Manager (ERM) that is configured to receive at least one orchestration request based on at least one service request, from at least one network service associated with one of a Network Function Virtualization Orchestrator (NFVO) and a Containerized Network Function (CNF) Manager (CNFM) of the MANO framework. The at least one service request is received from a network element. The ERM is configured to process the at least one orchestration request to identify one or more network services associated with a Virtualized Infrastructure Manager (VIM) of the MANO framework. The ERM is configured to route the at least one orchestration request to the one or more network services associated with the VIM using an associated interface for processing of the at least one orchestration request, upon identifying the one or more network services.
[0035] In an embodiment, the at least one service request includes 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.
[0036] In an embodiment, the ERM is further configured to identify at least one configuration corresponding to the at least one orchestration request based on a service discovery mechanism for routing the at least one orchestration request to the one or more network services using the associated interface, upon identifying the one or more network services for processing the at least one orchestration request.
[0037] In an embodiment, the ERM is configured to receive an acknowledgement based on processing of the at least one orchestration request from a network service of the one or more network services using the associated interface, in response to routing the at least one orchestration request.
[0038] In an embodiment, the associated interface of the VIM is an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.
[0039] In an embodiment, the acknowledgement includes at least one of a positive acknowledgement indicating a successful fulfillment of the at least one service request, and a negative acknowledgement indicating a failure to fulfill the at least one service request.
[0040] In an embodiment, when the acknowledgement is the negative acknowledgement, the ERM is configured to reschedule processing of the at least one service request after a pre-defined time period.
[0041] 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
[0042] 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.
[0043] FIG. 1 illustrates an exemplary network architecture for implementing a system for managing communication between network services associated with a Management and Orchestration (MANO) framework, in accordance with an embodiment of the present disclosure.
[0044] FIG. 2 illustrates an exemplary block diagram of the system configured for managing communication between the network services associated with the MANO framework, in accordance with an embodiment of the present disclosure.
[0045] FIG. 3 illustrates an exemplary block diagram depicting communication between the network services associated with the MANO framework via interfaces associated with an Event Routing Manager (ERM), in accordance with an embodiment of the present disclosure.
[0046] FIG. 4 illustrates a MANO framework architecture, in accordance with embodiments of the present disclosure.
[0047] FIG. 5 illustrates an exemplary process flow depicting management of communication between the network services associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0048] FIG. 6 illustrates another exemplary process flow depicting management of communication between the network services associated with the MANO framework via the ERM, in accordance with an embodiment of the present disclosure.
[0049] FIG. 7 illustrates an exemplary flow diagram of a method for managing communication between the network services associated with the MANO framework, in accordance with embodiments of the present disclosure.
[0050] FIG. 8 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0051] 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 – Processing Engine
210 – Database
212 - Event Routing Manager (ERM)
300 – Exemplary Block Diagram
302 – ERM
304 - Network Functions Virtualization Orchestrator (NFVO)
306 - Container Network Function (CNF) manager
308 - Virtual 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
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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 Digital Signal Processor (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.
[0061] 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), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
[0062] 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 a Global System for Mobile Communications (GSM), a Code Division Multiple Access (CDMA), a Universal Mobile Telecommunications System (UMTS), a Long-Term Evolution (LTE), and a 5G network. 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.
[0063] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when a 2G technology was introduced. A 3G technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. A 4G technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, a 5G technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. A Sixth Generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way we connect and interact with technology.
[0064] 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.
[0065] A Management and orchestration (MANO) framework manage and orchestrates all network resources in the cloud. The MANO framework includes computing, networking, storage, containers, and Virtual Machine (VM) resources. The MANO framework includes three essential components, namely a Virtualized Infrastructure Manager (VIM), a Container Network Function (CNF) manager, and a Network Functions Virtualization Orchestrator (NFVO). Within each of these components, multiple network services operate. These multiple network services communicate with one another using specific event names. It is required that these three components flexibly communicate with each other. An Event Routing Manager (ERM) is a component or a system responsible for directing incoming service requests based on an event name to an appropriate network service, employing designated interfaces.
[0066] Various interfaces have been designed to connect these three components and multiple network services, but they are rigid and limited to specific network services. As a result, particular interfaces are necessary to meet the requirements of the network, thereby leading to a complex and expensive solution.
[0067] The present disclosure aims to overcome the above-mentioned and other existing problems in this technology field by promoting interoperability between various components of the MANO framework, making it easier for them to work seamlessly together. In an aspect, the present disclosure may be directed to the ERM configured to provide seamless data communication between the CNF manager (also referred to as CNFM) and the VIM, as well as the VIM and the NFVO via an associated interface. In particular, the present disclosure may be directed to the ERM configured to provide seamless data communication between various network services associated with the CNF manager, the VIM, and the NFVO, via an associated interface.
[0068] Embodiments herein relate to a method for managing communication between the network services associated with the MANO framework. The ERM may manage the communication between the network services associated with the MANO framework. In particular, the method includes receiving at least one orchestration request based on at least one service request associated with one of a Network Function Virtualization Orchestrator (NFVO) and a Containerized Network Function (CNF) Manager (CNFM) of the MANO framework. The at least one service request is received from a network element. The method further includes processing the at least one orchestration request to identify one or more network services associated with a Virtualized Infrastructure Manager (VIM) of the MANO framework. Upon identifying the one or more network services, the method further includes routing the at least one orchestration request to the one or more network services associated with the VIM using an associated interface for processing of the at least one orchestration request.
[0069] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0070] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1- FIG. 8.
[0071] FIG. 1 illustrates an exemplary network architecture 100 of a system 108 for managing communication between the network services associated with the MANO framework, in accordance with an embodiment of the present disclosure. The system 108 may include an ERM. The ERM may be configured to manage communication between the network services. In an embodiment, the network services associated with the MANO framework may be implemented as microservices. 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, any number of the UE 104 may be included without departing from the scope of the ongoing description.
[0072] 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.
[0073] 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.
[0074] In FIG. 1, the UE 104 may communicate with the ERM within the system 108 through the network 106. In particular, the UE 104 may be communicatively coupled with the network 106. The coupling including steps of sending the at least one service request to the ERM via the network 106. The coupling including steps of receiving the acknowledgment corresponding to the at least one service request from the ERM via the network 106.
[0075] 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.
[0076] 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.
[0077] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for managing the communication between the network services associated with the MANO framework, in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1.
[0078] 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.
[0079] 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, a processing engine 208 and a database 210. In one embodiment, the processing engine 208 may include an ERM 212. The ERM 212 may be configured to manage the communication between the network services associated with the MANO framework. In some embodiments, the processing engine 208 may include the MANO framework.
[0080] In an embodiment, the ERM 212 within the processing engine 208 is configured to receive at least one service request (also referred to 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 an actor. The actor may correspond to a network element or an external system (e.g., the UE 104) that communicate with the MANO framework. The network element may be any hardware or software component that has a measurable parameter that can be reported. Examples of the network element 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. 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). Upon receiving the at least one service request, the ERM 212 is configured to route the at least one service request to at least one network service (also referred to as a target network service) associated with the MANO framework. In an embodiment, the target network service may correspond to a network service associated with the NFVO. The ERM 212 may route the target service request to the at least one network service of the NFVO via an associated interface, i.e., an Event routing Manager Orchestrator (EM_Or) interface.
[0081] Further, the target network service is configured to process the at least one service request to generate one of an acknowledgement corresponding to the at least one service request. In an embodiment, the target network service is configured to generate at least one orchestration request in response to receiving the at least one service request. Further, the ERM 212 is configured to receive the acknowledgement corresponding to the at least one service request, or the at least one orchestration request, from the target network service. Upon receiving the at least one orchestration request, the ERM 212 is configured to process the at least one orchestration request to identify one or more network services associated with the MANO framework. In an embodiment, the at least one orchestration request may include a set of instructions (i.e., data identifying the one or more network services) that needs to be followed by the one or more network services. Upon identifying the one or more network service, the ERM 212 is configured to route the at least one orchestration request to the one or more network services for processing of the at least one orchestration request. The one or more network services may correspond to network services associated with the CNF manager (i.e., the CNFM) or the VIM, or both of the CNFM and the VIM. Further, the at least one orchestration request may be routed by the ERM 212 to the one or more network services associated with the CNF manager or the VIM via an associated interface, i.e., an Event routing Manager Container Network Function Manager (EM_Cnfm) interface and an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface, respectively. Further, the ERM 212 is configured to receive the acknowledgement based on the processing of the at least one orchestration request from a network service of the one or more network services. The acknowledgement is at least one of a positive acknowledgement indicating a successful fulfillment of the at least one service request and a negative acknowledgement indicating a failure to fulfill the at least one service request. This complete method performed by the ERM 212 in conjunction with the processing engine 208 for managing the communication between the network services associated with the MANO framework is further explained in detail in FIGS. 3 – 7.
[0082] In an embodiment, the system 108 may include the processing engine 208 that may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine 208. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine 208 may be processor-executable instructions stored on a non-transitory machine-readable storage medium. The hardware for the processing engine 208 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 processing engine 208. 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 processing engine 208 may be implemented by electronic circuitry.
[0083] In an embodiment, the system 108 may include a database 210 that includes data (e.g., the at least one service request, the at least one orchestration request, the acknowledgment, the one or more network services, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor 202 or the processing engine 208.
[0084] FIG. 3 illustrates an exemplary block diagram 300 depicting communication between the network services 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 212. FIG. 3 is explained in conjunction with FIGS. 1 and 2.
[0085] The MANO framework is commutatively coupled with several network elements (not shown in figures) or external systems. Each network element or the external system may also be referred to as the actor. For example, the network element may be a logical 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 collecting relevant information that may be subsequently used to determine control actions to be applied to the network element. In particular, the network element may be any hardware or software component with a measurable parameter that can be reported. Examples of the network element include the router, the switch, the host, the modem, the terminal, the dial access server, the gateway, the port, the channel, the interface, the circuit, the process, the driver, the protocol, the service, the application, etc. Examples of the external system may include but are not limited to, the NSMP, the STS, the SSS, the PM system, the NMS, and the CNIS.
[0086] The ERM 302 may be adapted as software and added as a network service within the MANO framework. In some embodiments, the ERM 302 may communicate with the MANO framework. For example, the ERM 302 may be a publisher-subscriber based network service. The ERM 302 may be responsible for directing incoming service requests (i.e., the at least one service request) based on an event name to an appropriate network service, employing designated interfaces (i.e., the EM_Or interface, the EM_Cnfm interface, and the EM_Vi interface) for this purpose. The ERM 302 is an event-driven communication framework that enhances the overall functionality and effectiveness of the MANO framework.
[0087] As shown in FIG. 3, the MANO framework includes an NFVO 304, a CNF manager (CNFM) 306, and a VIM 308. The NFVO 304 is configured to cooperate with a CNF catalog management, a network service catalog, and a policy execution engine. The NFVO 304 is responsible for orchestrating services, overseeing 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 306 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.
[0088] 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.
[0089] 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 (i.e., the target network service) is further configured to process the at least one service request internally or is configured to identify the one or more network services (i.e., 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 network service (i.e., the target network service), 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 by the NFVO 304, the NFVO 304 is configured to generate the at least one orchestration request and is configured to forwards the at least one orchestration request to the one or more network services associated with the CNFM 306 or the VIM 308 via one of the one or more second interfaces, i.e., the EM_Cnfm interface or the EM_Vi interface, respectively. The NFVO is configured to generate the at least one orchestration request 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.
[0090] The ERM 302 may make use of service discovery mechanisms such as a service registry for event 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, the 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).
[0091] In an aspect, to route the at least one service request or the at least one orchestration request to the target network service or the one or more network service, respectively, the ERM 302 may include a plurality of interfaces. For example, the plurality of interfaces may include the first interface (i.e., the EM_Or interface), and the one or more second interfaces (i.e., the EM_Cnfm interface and the EM_Vi interface). Each of the plurality of interfaces may be associated with a corresponding network service, 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. A first interface (i.e., the EM_Or interface) is coupled to the NFVO 304 and is configured to establish communication between the NFVO 304 and the ERM 302. Using the EM_Or interface, the NFVO 304 is configured to receive service requests from the ERM 302. Further, using the EM_Or interface, the NFVO 304 may be configured to transfer the acknowledgment and a delivery report, or the at least one orchestration request 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.
[0092] A second 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 a service request (e.g., the at least one orchestration request) from the ERM 302 via the EM_Cnfm interface. The ERM 302 receives the at least one orchestration request in response to the at least one service request from the NFVO 304 via the EM_Or 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 network service 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 network service 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 forward 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 network service 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. This process of the spawning involves initializing and configuring the resources, so that the resources 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 network service of the NFVO 304 via the EM_Or interface to another network service or a group of network services in the CNFM 306 using the event name, or to another network service or a group of network service 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.
[0093] In an example, the EM_Or 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.
[0094] In an example, the CNFM 306 may interact with the VIM 308 to request and allocate resources for performing operations to process the service request. The CNFM 306 may interact with the VIM 308 via the EM_Cnfm and 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.
[0095] In an example, 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 network service associated with the VIM 308 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 network service (i.e., the target network service) of the NFVO 304 via the EM_Or interface associated with the ERM 302 to another network service or a group of network services in the VIM 308 using the event name, or to another network service or a group of network service in the NFVO 304 via the EM_Or interface of the ERM 302.
[0096] In an embodiment, the EM_Cnfm interface and the EM_Vi interface plays a crucial role in facilitating communication between the CNFM 306 and the VIM 308. The EM_Vi interface is responsible to take the service requests received by the ERM 302 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 EM_Or 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 EM_Or 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 EM_Or interface, the VIM 308 communicates with the NFVO 304 to ensure the resource allocation aligns with network service requirements.
[0097] The EM_Vi interface supports an asynchronous event-based implementation to establish the communication between the NFVO 304 and the VIM 308 via the EM_Or interface, and the VIM 308 and the CNFM 306 via the EM_Cnfm interface. Furthermore, the EM_Vi interface supports guaranteed message delivery for the acknowledgement and the delivery reports incorporated and gives flexibility to execute mutually exclusive events (i.e., the service requests) in parallel. The EM_Vi interface supports for the subscriber and publisher model.
[0098] In an embodiment, the ERM 302 is coupled with an Operations, Administration, and Maintenance (OAM) module depicted as an OAM 310 via an Event routing Manager Operations, Administration, and Maintenance (EM_OAM) ineterface (depicted as an EM_OA interface). 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.
[0099] 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 network services 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 network services 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 a Static Random Access Memory (SRAM) and a Dynamic Random Access Memory (DRAM), and/or nonvolatile memory, such as a Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[00100] 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 network services (i.e., the target network service or the one or more network services) associated with the MANO framework. Each of the plurality of service request is subscribed to by a specific network service (i.e., a subscriber network service). For example, the ERM 302 may enable dynamic and efficient communication between the network services of the NFVO 304 associated with the MANO framework via the EM_Or interface.
[00101] If deferred event configuration is enabled for any event (i.e., a service request), the ERM 302 may automatically retry the processing of such event even if an initial delivery failed. In an embodiment, the ERM 302 is configured to provide a deferred delivery in case the specific network service 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 network service after a predefined time interval (e.g., 15 minutes).
[00102] In an aspect, the ERM 302 may play an essential role in event-driven systems where an event (i.e., the service request) needs to be delivered from an event source, i.e., a publisher (e.g., the actor) to appropriate event consumers or downstream services, i.e., subscribers, such as the NFVO 304, 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 (i.e., the publisher) and event consumers (i.e., the subscribers) 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.
[00103] In an embodiment, the EM_Vi interface provides a guaranteed message delivery of the acknowledgement and the delivery report. Further, the EM_Vi interface enables automatic detection of failed service requests and facilitate rerouting of the service requests to alternative healthy instances or network services, thereby improving overall resilience and minimizing downtime of the network. In an aspect, the ERM 302 is 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.
[00104] 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.
[00105] 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.

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

[00107] 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 network service within the MANO framework based on a type of the resource allocation required. In an embodiment, the network services (i.e., the target network service and the one or more network services) may be implemented as microservices. These modules may utilize a mapping of service request types to target network services 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.

[00108] 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 Network service interface used by the ERM 302 to interact with the external systems and the MANO framework network services. 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.

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

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

[00111] 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 docker 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 docker swarm adaptor manages interactions with docker swarm clusters, enabling container orchestration and scaling. The OpenStack API adapter interfaces with OpenStack 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.

[00112] 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.
[00113] FIG. 5 illustrates an exemplary process flow 500 depicting management of the communication between the network services 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.
[00114] Initially, at step 504, at least one service request (also referred to as the event) may be generated and sent by a network element 502 (also referred to as the actor) to the ERM 302. In some embodiment, the network element 502 may correspond to an external system. Examples of the network element include the router, the switch, the host, the modem, the terminal, the dial access server, the gateway, the port, the channel, the interface, the circuit, the process, the driver, the protocol, the service, the application, etc. Examples of the external system may include, but are not limited to, the NSMP, the STS, the SSS, the PM system, the NMS, and the CNIS. 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.
[00115] 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.
[00116] 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 EM_Or interface. In an example, the ERM 302 is configured to analyze the received at least one service request to allocate a specific network service, i.e., at least one network service (also referred to as the target network service) 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 network service (i.e., the target network service) 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.
[00117] 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 network services internally or requires transmission of the at least one service request to the one or more network services associated with the CNFM 306, or the VIM 308, or both.
[00118] 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 network service 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 EM_Or interface. The ERM 302 may further transmit the acknowledgement generated corresponding to the at least one service request to the network element 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 network service of the NFVO 304 is configured to generate an orchestration request (i.e., the at least one orchestration request) and send the orchestration request to the ERM 302. Further, the ERM 302 is configured to process the orchestration request to identify the one or more network services.
[00119] In an embodiment, the orchestration request may include a set of instructions (i.e., the data identifying one or more network services 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 EM_Or interface.
[00120] 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 life 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 network service or a group of network services (i.e., the one or more services of the CNFM 306) associated with the MANO framework accordingly. In an example, the ERM 302 may allocate a group of network services associated with the CNFM 306, the VIM 308, or both, for the received orchestration request. Further, the ERM 302 may forward 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 network services of the CNFM 306 and generate an orchestration request. The orchestration request may include a set of instructions (the data identifying the one or more network services 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 at least one network service of the one or more network services associated with the CNFM 306 to the VIM 308 via the EM_Vi interface.
[00121] At step 520, the VIM 308 is configured to process the orchestration request (i.e., the at least one orchestration request) 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 network services 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. In particular, upon receiving the orchestration request from the ERM 302 via the EM_Vi interface, the VIM 308 first validates the orchestration request to ensure the orchestration request aligns with the current capabilities of the underlying virtualized infrastructure associated with the one or more network services of the VIM 308. The underlying virtualized infrastructure associated with the one or more network services of the VIM 308 includes physical and virtual resources, such as physical servers, switches, routers, VNFs (such as firewalls, load balancers, etc.). Further, to validate the orchestration request, the VIM 308 checks a format and a structure of the orchestration request based on a format (e.g., the HTTP format) and a structure (e.g., a request header structure, a request body structure, and the like) supported by the underlying virtualized infrastructure. After validating the orchestration request, the VIM 308 assesses a state of available resources, such as a Central Processing Unit (CPU), a memory, a storage, and a network capacity, by querying resource management systems, such as an OpenStack, an apache mesos, a Microsoft Azure Resource Manager (ARM), and the like. Further, based on requirements specified in the orchestration request, the VIM 308 allocates necessary resources from the available resources, which may involve provisioning new virtual machines or scaling existing resources. Subsequently, the VIM 308 configures these necessary resources according to the orchestration request, updating networking configurations and installing required software or the VNFs. After configuring the necessary resources, the VIM 308 updates an associated internal state to accurately reflect the current resource allocations and configurations. Thereafter, the VIM 308 generates the service request acknowledgment and sends the service request acknowledgment to the ERM 302. At step 524, the ERM 302 may send the service request acknowledgment to the network element 502. The service request acknowledgment may correspond to an update signal that is transmitted to the network element 502 indicating a status of the orchestration request processed by the VIM 308. 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. In some embodiments, the service request acknowledgement may also include details about the state of the underlying virtualized infrastructure.
[00122] FIG. 6 illustrates another exemplary process flow 600 depicting management of the communication between the network services 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.
[00123] Initially, at step 602, the at least one service request (also referred to as the event) may be generated and send by the network element 502 to the ERM 302. In some embodiments, the network element 502 may correspond to the external system. 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 EM_Or 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.
[00124] 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 network service 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 EM_Or interface. The ERM 302 may further transmit the acknowledgement generated corresponding to the at least one service request to the network element 502. Further, in some embodiments, the acknowledgement may be rendered to the network operator (e.g., the user 102).
[00125] 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 network services for processing the at least one service request. Further, upon determining the one or more network services 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 network services 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 EM_Or interface.
[00126] 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 network services of the VIM 308. At step 612, the VIM 308 is configured to process the orchestration request. In particular, the one or more network services 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.
[00127] 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 network services of the CNFM 306) to be followed by the CNFM 306 for processing the orchestration request. In particular, upon receiving the orchestration request from the ERM 302 via the EM_Vi interface, the VIM 308 first validates the orchestration request to ensure the orchestration request aligns with the current capabilities of the underlying virtualized infrastructure associated with the one or more network services of the VIM 308. The underlying virtualized infrastructure associated with the one or more network services of the VIM 308 includes the physical and virtual resources, such as the physical servers, the switches, the routers, the VNFs (such as the firewalls, the load balancers, etc.). Further, to validate the orchestration request, the VIM 308 checks the format and the structure of the orchestration request based on the format (e.g., the HTTP format) and the structure (e.g., the request header structure, the request body structure, and the like) supported by the underlying virtualized infrastructure. After validating the orchestration request, the VIM 308 assesses the state of available resources, such as the CPU, the memory, the storage, and the network capacity, by querying resource management systems. Examples of the resource management systems may include the OpenStack, the apache mesos, the Microsoft Azure Resource Manager (ARM), and the like. Further, based on requirements specified in the orchestration request, the VIM 308 allocates necessary resources from the available resources, which may involve provisioning new virtual machines or scaling existing resources. Subsequently, the VIM 308 configures these necessary resources according to the orchestration request, updating networking configurations and installing the required software’s or the VNFs. After configuring the necessary resources, the VIM 308 updates the associated internal state to accurately reflect the current resource allocations and configurations. Thereafter, the VIM 308 generates another orchestration request and sends the another orchestration request service request to the ERM 302. At step 616, the ERM 302 is configured to route the orchestration request received from the VIM 308 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 network services 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. 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 element 502. The service request acknowledgment may correspond to an update signal that is transmitted to the network element 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.
[00128] FIG. 7 illustrates an exemplary flow diagram of a method 700 for managing the communication between the network services associated with the MANO framework, in accordance with embodiments of the present disclosure. Each step of the method 700 may be performed by 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. 7 is explained in conjunction with FIGS. 1, 2, 3, 4, 5, and 6.
[00129] In order to manage the communication between the network services associated with the MANO framework, initially the at least one service request may be received. The at least one service request may be received by the ERM 302 from the network element 502. In some embodiments, the network element 502 may correspond to the external system. Examples of the network element 502 include the router, the switch, the host, the modem, the terminal, the dial access server, the gateway, the port, the channel, the interface, the circuit, the process, the driver, the protocol, the service, the application, etc. Examples of the external system may include, but are not limited to, the NSMP, the STS, the SSS, the PM system, the NMS, and the CNIS. 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.
[00130] In an embodiment, 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. The memory associated with the ERM 302 may contain the repository of valid service request templates (i.e., the list of valid service request templates) or identifiers, serving as the 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. In another embodiment, if the at least one service request does not exist within the memory associated with the ERM 302, then the at least one service request is the invalid service request. If the at least one service request is the invalid service request, the ERM 302 may discard the invalid service request.
[00131] Further the at least one service request may be routed by the ERM 302 to the target network service associated with the MANO framework. In other words, the ERM 302 may route the at least one service request to the at least one network service (i.e., the target network service) of the NFVO 304 associated with the MANO framework. The ERM 302 may route the at least one service request to the NFVO 304 via the associated interface, i.e., the EM_Or interface. In an embodiment, examples of network services (i.e., the target network service) associated with the NFVO 304 may include, a service orchestration network service, a resource management network service, a service catalog network service, a lifecycle management network service and the like.
[00132] Upon receiving the at least one service request, the target network service 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 other words, the NFVO 304 is configured to process the at least one service request to determine whether the target network service of the NFVO 304 may be able to cater the at least one service request internally or requires transmission of the at least one service request to the one or more network services associated with one of the CNFM 306 or the VIM 308, or both of the CNFM 306 and the VIM 308. Examples of network services associated with the CNFM 306 may include a deployment management network service, a scaling management network service, a configuration management network service, etc. Examples of network services associated with the VIM 308 may include a compute resource management network service, a storage resource management network service, a network resource management network service, and the like.
[00133] 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 network service 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. The acknowledgement generated corresponding to the at least one service request includes at least one of the positive acknowledgement indicating the successful fulfillment of the at least one service request and the negative acknowledgement indicating a failure to fulfill the at least one service request. 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 network service of the NFVO 304 is configured to generate the at least one orchestration request. Further, the target network service is configured to send the at least one orchestration request to the ERM 302 via the EM_Or interface.
[00134] In one embodiment, at step 702, the ERM 302 is configured to receive the at least one orchestration request from the at least one network service (i.e., the target network service) associated with the NFVO 304. The at least one orchestration request may include the data (i.e., the set of instructions) identifying the one or more network services. Upon receiving the at least one orchestration request, at step 704, the ERM 302 is configured to process the at least one orchestration request. In particular, the ERM 702 is configured to process the data, i.e., the set of instructions within the at least one orchestration request to identify the one or more network services associated with the VIM 308. Upon identifying the one or more network services associated with the VIM 308 based on the data, i.e., the set of instructions (e.g., a number of the CPUs required, a number of the VNFs required, etc.) within the at least one orchestration request, at step 706, the ERM 302 is configured to send the at least one orchestration request to the VIM 308 using the EM_Vi interface for processing the at least one orchestration request.
[00135] In another embodiment, the ERM 302 is configured to receive the at least one orchestration request from the CNFM 306 using the EM_Cnfm interface. In other words, based on processing of the at least one orchestration request received from the NFVO 304, the ERM 302 identifies that the at least one orchestration request is associated with the one or more network services of the CNFM 306. Upon identifying the at least one orchestration request to be associated with the one or more network services of the CNFM 306, the ERM 302 is configured to route the at least one orchestration request to the one or more network services associated with the CNFM 306 using the EM_Cnfm interface. The CNFM 306 is configured to generate at least one orchestration request (i.e., another orchestration request) based on processing of the at least one orchestration request received from the NFVO 302 via the ERM 302. Further, the CNFM 306 is configured to route the at least one orchestration request to the ERM 302 using the EM_Cnfm interface. In particular, the at least one network service of the one or more network services of the CNFM 306 is configured to route the at least one orchestration request to the ERM 302. Upon receiving the at least one orchestration request from CNFM 306 by the ERM 302 via the EM_Cnfm interface as mentioned via the step 702, the ERM 302 is configured to perform the step 704 and the step 706. In an embodiment, upon identifying the one or more network services, the ERM 302 is configured to identify the at least one configuration corresponding to the at least one orchestration request based on the service discovery mechanism (e.g., the round robin technique) for routing the at least one orchestration request to the one or more network services. The at least one configuration may include a service router configuration, an API gateway configuration, a VNF manager configuration, and the like.
[00136] In particular, the ERM 302 may route the at least one orchestration request to the one or more network services of one of the CNFM 306, or the VIM 308, or both, via an associated interface, i.e., the EM_Cnfm interface or the EM_Vi interface. Further, the acknowledgement may be received by the ERM 302 based on processing of the at least one orchestration request from a network service of the one or more network services via the associated interface. The ERM 302 then transmits the acknowledgement to the network element 502. The acknowledgement generated corresponding to the at least one service request includes at least one of the positive acknowledgement indicating the successful fulfillment of the at least one service request and the negative acknowledgement indicating the failure to fulfill the at least one service request. In an embodiment, when the acknowledgement is the negative acknowledgement, the ERM 302 is configured to reschedule the processing of the at least one service request after a pre-defined time period (e.g., 15 minutes).
[00137] FIG. 8 illustrates an exemplary computer system 800 in which or with which embodiments of the present disclosure may be implemented. 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.
[00138] 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.
[00139] 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.
[00140] 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.
[00141] 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.
[00142] 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.
[00143] 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.
[00144] The present disclosure provides technical advancement related to management of communication between network services associated with a MANO framework. This advancement addresses the limitations of existing solutions by introducing an ERM that acts as an intelligent intermediary between the network services associated with the MANO framework. By introducing the ERM, the present disclosure promotes interoperability between the network services associated with the MANO framework to cater service requests received from an actor (i.e., network elements or external systems). The present disclosure provides asynchronous communication between various components (i.e., an NFVO, a CNF manager, a VIM) of the MANO framework via an associated interface.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00145] The present disclosure provides a method and a system for managing communication between network services and a Management and Orchestration (MANO) framework via an Event Routing Manager (ERM). The ERM serves as a crucial intermediary, connecting the network services associated with the MANO framework.
[00146] The present disclosure implements intelligent service request routing to specific MANO framework network services, ensuring optimal resource allocation and improving overall network performance.
[00147] The present disclosure provides an interface that provides guaranteed message delivery with an acknowledgement and a delivery report.
[00148] The present disclosure enables automatic detection of failed services (i.e., service requests) and facilitates rerouting of the service requests to alternative healthy instances or the network services associated with the MANO framework.
[00149] The present disclosure enables asynchronous communication between various components (i.e., a Network Functions Virtualization Orchestrator (NFVO), a Container network function’ (CNF) manager, a Virtualized Infrastructure Manager (VIM)) of the MANO framework via an associated interface.
[00150] The present disclosure provides an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface that connects the ERM and the VIM of the MANO framework. The VIM facilitates efficient resource management by processing the service requests received from the NFVO and the CNFM. The VIM translates high-level service requests into specific resource configurations, manages the lifecycle of Virtual Network Function (VNF) instances, and ensures optimal resource allocation to meet network service requirements.
,CLAIMS:CLAIMS
We Claim:
1. A method (700) for managing communication between network services associated with a Management and Orchestration (MANO) framework, the method (700) comprises:
receiving (702), by an Event Routing Manager (ERM) (212), at least one orchestration request based on at least one service request, from at least one network service associated with one of a Network Function Virtualization Orchestrator (NFVO) (304) and a Containerized Network Function (CNF) Manager (CNFM) (306) of the MANO framework, wherein the at least one service request is received from a network element;
processing (704), by the ERM (212), the at least one orchestration request to identify one or more network services associated with a Virtualized Infrastructure Manager (VIM) (308) of the MANO framework; and
upon identifying the one or more microservices, routing (706), by the ERM (212), the at least one orchestration request to the one or more network services associated with the VIM (308) using an associated interface, for processing of the at least one orchestration request.

2. 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.

3. The method (700) as claimed in claim 1, further comprising:
upon identifying the one or more network services for processing the at least one orchestration request, identifying, by the ERM (212), at least one configuration corresponding to the at least one orchestration request based on a service discovery mechanism for routing the at least one orchestration request to the one or more network services using the associated interface.

4. The method 700) as claimed in claim 4, further comprising:
in response to routing the at least one orchestration request, receiving, by the ERM (212), an acknowledgement based on processing of the at least one orchestration request from a network service of the one or more network services using the associated interface.

5. The method (700) as claimed in claim 1, wherein the associated interface of the VIM (308) is an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.

6. The method (700) as claimed in claim 4, wherein the acknowledgement comprises at least one of:
a positive acknowledgement indicating a successful fulfillment of the at least one service request, and
a negative acknowledgement indicating a failure to fulfill the at least one service request.

7. The method (700) as claimed in claim 6, wherein when the acknowledgement is the negative acknowledgement, the ERM (212) is configured to reschedule processing of the at least one service request after a pre-defined time period.

8. A system (108) for managing communication between network services associated with a Management and Orchestration (MANO) framework, the system (108) comprising:
an Event Routing Manager (ERM) (212) configured to:
receive (702) at least one orchestration request based on at least one service request, from at least one network service associated with one of a Network Function Virtualization Orchestrator (NFVO) (304) and a Containerized Network Function (CNF) Manager (CNFM) (306) of the MANO framework, wherein the at least one service request is received from a network element;
process (704) the at least one orchestration request to identify one or more network services associated with a Virtualized Infrastructure Manager (VIM) (308) of the MANO framework; and
upon identifying the one or more microservices, route (706) the at least one orchestration request to the one or more network services associated with the VIM (308) using an associated interface for processing of the at least one orchestration request.

9. The system (108) as claimed in claim 8, 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.

10. The system (108) as claimed in claim 8, wherein the ERM (212) is further configured to:
upon identifying the one or more network services for processing the at least one orchestration request, identify at least one configuration corresponding to the at least one orchestration request based on a service discovery mechanism for routing the at least one orchestration request to the one or more network services using the associated interface.

11. The system (108) as claimed in claim 8, wherein the ERM (212) is further configured to:
in response to routing the at least one orchestration request, receive an acknowledgement based on processing of the at least one orchestration request from a network service of the one or more network services using the associated interface.

12. The system (108) as claimed in claim 8, wherein the associated interface of the VIM (308) is an Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface.

13. The system (108) as claimed in claim 11, wherein the acknowledgement comprises at least one of:
a positive acknowledgement indicating a successful fulfillment of the at least one service request, and
a negative acknowledgement indicating a failure to fulfill the at least one service request.

14. The system (108) as claimed in claim 13, wherein when the acknowledgement is the negative acknowledgement, the ERM (212) is configured to reschedule processing of the at least one service request after a pre-defined time period.