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

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR ROUTING EVENT REQUESTS IN NETWORK

2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[0002] The present disclosure generally relates to the field of event routing in wireless communication systems. More particularly, the present disclosure relates to a system and a method for routing event requests in a network. A communication interface for management and orchestration (MANO).
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘Virtualization’ used hereinafter in the specification refers to a technology that allows an operator to create and manage virtual versions of physical resources, such as servers, storage devices, and networks.
[0005] The expression ‘Virtualized infrastructure’ used hereinafter in the specification refers to an abstraction of physical computing resources into virtual instances that can be managed and utilized more flexibly. This abstraction allows for efficiently allocating, managing, and scaling resources across multiple applications and services.
[0006] The expression ‘Management and Orchestration (MANO)’ framework used hereinafter in the specification refers to a framework that manages and orchestrates virtualized network functions (VNFs) and resources in a Network Functions Virtualization (NFV) environment.
[0007] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to an intermediary component that facilitates communication between the external systems and the MANO framework, routing service requests and responses of network slice allocations and resources allocation and management.
[0008] The expression ‘Network Management System (NMS)’ used hereinafter in the specification refers to a system responsible for the centralized management, monitoring, and control of the infrastructure of a network (e.g., the 5G network). The NMS provides comprehensive tools and features for network operators (or network administrators) to manage and optimize network resources, including routers, switches, servers, and other network devices.
[0009] The expression ‘Network Functions Virtualization (NFV)’ used hereinafter in the specification refers to a network architecture concept that uses virtualization technologies to manage core networking functions via software rather than hardware.
[0010] The expression ‘Virtualized Network Function (VNF)’ used hereinafter in the specification refers to an implementation of a network function that can be deployed on a Network Functions Virtualization Infrastructure (NFVI).
[0011] The expression ‘Orchestrator’ used hereinafter in the specification refers to a component of the MANO framework responsible for the orchestration and lifecycle management of physical and software resources. The orchestrator is a component in charge of the management of the NFV infrastructure and software resources.
[0012] The expression ‘Containerized network function (CNF) manager (CNFM)’ used hereinafter in the specification to a component that orchestrates and optimizes network functions deployed within containerized environments.
[0013] The expression ‘Virtualized Infrastructure Manager (VIM)’ used hereinafter in the specification refers to a component of the MANO framework responsible for controlling and managing the NFV infrastructure computation, storage, and resources (i.e., network resources).
[0014] The expression ‘NFV Infrastructure (NFVI)’ used hereinafter in the specification refers to a collection of hardware and software components that build an environment in which VNFs are deployed, managed, and executed.
[0015] The expression ‘NFV orchestrator (NFVO)’ used hereinafter in the specification refers to a component within the NFV architecture responsible for the end-to-end orchestration and management of the VNFs and their associated resources.
[0016] The expression ‘Container’ used hereinafter in the specification refers to an executable unit of software in which application code is packaged along with its libraries and dependencies.
[0017] The expression ‘Containerized Applications’ used hereinafter in the specification refers to applications that run in isolated packages of code (containers).
[0018] The expression ‘Orchestration Management’ used hereinafter in the specification refers to a process of managing and coordinating the deployment and operation of multiple services or applications in a distributed environment.
[0019] The expression ‘Event’ used hereinafter in the specification refers to a specific action that can trigger a network element or network entity or a system to take a particular action or reaction. In an example, the event may include network traffic, system configuration changes, or security incidents.
[0020] The expression “Network services” refer to the architectural and deployment paradigm where applications are composed of small, independent services that are deployed and managed within the virtualized environment. Each network service is designed to perform a specific business function and communicates with other network services over well-defined application programming interfaces (APIs).
[0021] The expression “Communication path” refers to a route through which information is exchanged between entities. For the network services, the communication path describes the way network services interact with each other. This includes the protocols, interfaces, and data formats used for communication.
[0022] The expression “Interconnectivity between network services” refers to a way in which different network services within the system interact and communicate with each other.
[0023] The expression “Network entity” refers to any device, component, or element that is part of the network and participates in its operation. The network entities are involved in various functions, such as communication, management, and data processing.
[0024] The expression “Orchestration request” refers to a command or set of instructions sent to or from the orchestration system to manage, coordinate, or automate the deployment, scaling, and operation of various resources or services within the network.
[0025] The expression “Healthy network service” refers to a network service that is functioning correctly and meeting its operational and performance expectations.
[0026] These definitions are in addition to those expressed in the art.
BACKGROUND
[0027] 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.
[0028] With the rapid development of cloud computing, business systems are gradually migrating to a cloud platform and starting to provide business services for users through virtual hosts. With a gradually increasing demand from users regarding cost reduction and business configuration flexibility improvement, the use of containers on physical hosts for providing various applications is becoming more and more extensive. With the help of current container technology, one host may support dozens or even hundreds of containers, but once that number exceeds hundreds, one host is insufficient. High availability is also impacted by the fact that there is only one host system utilized to run the container; as a result, all user containers become inoperable in the event of a host machine failure. Therefore, it is necessary that containers be operated concurrently by several hosts and that the connectivity between various host containers should be maintained in a cloud computing environment in order to achieve high scalability and high availability.
[0029] Management and orchestration (MANO) is a framework for the management and orchestration of all network resources in the cloud. The MANO includes computing, networking, storage, containers, and virtual machine (VM) resources. The MANO includes three essential components: virtualized infrastructure manager (VIM), containerized network function (CNF) manager (CNFM), and 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 components can communicate with each other in a flexible manner.
[0030] Presently, to connect these components (providing various network services), multiple interfaces are designed that are hardcore and are limited to specific network services only. Therefore, a number of interfaces are required to provide connectivity according to the requirements of the network, therefore yielding a complex and costly solution.
[0031] Furthermore, there is one-way communication between the NFVO and the CNFM (i.e., from the NFVO to the CNFM). The NFVO communicates with the CNFM via an interface (i.e., the Or_Cnfm interface). When the CNFM needs to communicate with the NFVO, the CNFM employs a polling method. This polling approach can lead to increased overhead in the network. Therefore, there is a need for bidirectional communication between the NFVO and the CNFM to reduce the overload caused by the polling method.
[0032] Hence, there is a need for an interface configured to facilitate enhanced, dynamic, and efficient communication between the CNFM and the MANO, as well as between various network services within the MANO.
OBJECTIVES
[0033] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0034] An objective of the present disclosure is to provide an EM_CNFM interface that connects an event routing manager and a containerized network function manager (CNFM) of a management and orchestration (MANO).
[0035] Another objective of the present disclosure is to provide an EM_CNFM interface that provides a guaranteed message delivery with acknowledgement and delivery report.
[0036] Yet another objective of the present disclosure is to provide an EM_CNFM interface that automatically detects failed services and facilitates rerouting requests to alternative healthy instances or services.
[0037] Still, another objective of the present disclosure is to provide an EM_Cnfm interface that enables asynchronous communication between various components of the MANO.
[0038] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
SUMMARY
[0039] In an exemplary embodiment, a system for routing a plurality of service requests in a management and orchestration (MANO) framework is described. The system includes an event routing manager (ERM), the ERM includes a communicating unit configured to: receive at least one service request from at least one network entity, send the received at least one service request to a network functions virtualization orchestrator (NFVO) of the MANO framework, where the NFVO is configured to generate at least one orchestration request on receiving the at least one service request, and receive the at least one orchestration request from the NFVO. The system also includes an analyzing unit coupled with the communication unit is configured to: analyze the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework. The system also includes forward the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework via an interface.
[0040] In some embodiments, the at least one component of the MANO is one of a containerized network function manager (CNFM) and a virtualized infrastructure manager (VIM). The interface is an event routing manager_containerized network function manager (EM_Cnfm) interface.
[0041] In some embodiments, the orchestration request comprises at least one operation associated with the resources, wherein the at least operation is one of allocation of the resources and deallocation of the resources.
[0042] In some embodiments, upon receiving the at least one orchestration request via the interface, the CNFM is configured to process the at least one received orchestration request to generate at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization.
[0043] In some embodiments, the VIM is configured to receive the at least one information from the CNFM via the ERM and is further configured to analyze the received at least one information to manage at least one underlying infrastructure resource for virtualization.
[0044] In another exemplary embodiment, a method for routing a plurality of service requests in a management and orchestration (MANO) framework by an event routing manager (ERM), the method includes receiving at least one service request from at least one network entity, sending the received at least one service request to a network functions virtualization orchestrator (NFVO) of the MANO framework, where the NFVO is configured to generate at least one orchestration request on receiving the at least one service request, receiving the at least one orchestration request from the NFVO, analyzing the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework, and forwarding the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework via an interface.
[0045] In some embodiments, the method further includes upon receiving the at least one orchestration request via the interface, processing, by the CNFM, the at least one received orchestration request to generate at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization.
[0046] In some embodiments, the method further includes receiving, by the VIM, the at least one information from the CNFM via the ERM and analyzing, by the VIM, the received at least one information to manage at least one underlying infrastructure resource for virtualization.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0047] 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.
[0048] FIG. 1A illustrates an exemplary network architecture for implementing a system for routing a plurality of service requests in a management and orchestration (MANO) framework, in accordance with an embodiment of the present disclosure.
[0049] FIG. 1B illustrates another exemplary network architecture for implementing an event routing manager (ERM)_ containerized network function manager (CNFM) (EM_Cnfm) interface for the MANO framework, in accordance with an embodiment of the present disclosure.
[0050] FIG. 1C illustrates an exemplary block diagram of the system for routing the plurality of service requests in the MANO framework, in accordance with an embodiment of the present disclosure.
[0051] FIG. 2 illustrates an exemplary flow diagram of processing a service request between the components of the MANO via the EM_Cnfm interface, in accordance with an embodiment of the present disclosure.
[0052] FIG. 3 illustrates another exemplary flow diagram describing “service request” processing, in accordance with an embodiment of the present disclosure.
[0053] FIG. 4 illustrates an exemplary representation of the MANO framework architecture, in accordance with an embodiment of the present disclosure.
[0054] FIG. 5 illustrates an exemplary flow diagram of a method for routing the plurality of service requests in the MANO framework by the ERM, in accordance with an embodiment of the present disclosure.
[0055] FIG. 6 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented.
[0056] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100A - 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
130 – Event Routing Manager
100B – Block Diagram
111 – Processor(s)
112 - Memory
114 – Plurality of Interfaces
116 – Communication Unit
118 – Analyzing Unit
122 – Database
100C - Network Architecture
105 - Management and Orchestration (MANO) Framework
110 - Network Functions Virtualization Orchestrator (NFVO)
115 - Containerized Network Function Manager (CNFM)
120 - Virtualized Infrastructure Manager (VIM)
125 - Operations, Administration, and Maintenance Module (OAM)
200 - Flow Diagram
300 - Flow Diagram
400 - Management and Orchestration (MANO) framework architecture
500 - Flow Diagram
600 - Computer system
610 - External Storage Device
620 - Bus
630 - Main Memory
640 - Read Only Memory
650 - Mass Storage Device
660 - Communication Port
670 - Processor
DETAILED DESCRIPTION
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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 internet protocol (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.
[0065] Further, the user device may also comprise a "processor" or "processing unit" includes processing unit, wherein the 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 (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0066] 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 is also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), and now sixth generation (6G), and more such generations are expected to continue in the forthcoming time.
[0067] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0068] 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.
[0069] As the wireless technologies are advancing, there is a need to cope up with the 5G requirements and deliver a high level of service to the customers. Thus, faster communication between elements of a 5G communication network is becoming crucial day by day. Business systems are gradually migrating to a cloud platform and starting to provide business services for users through virtual hosts. With a gradually increasing demand from users regarding cost reduction and business configuration flexibility improvement, network functions virtualization (NFV) is extensively employed. NFV is a replacement of network appliance hardware with virtual machines (VM), or containers on physical hosts for providing various applications is becoming more and more extensive.
[0070] NFV architecture relies on server virtualization technologies to provide the VMs necessary to host the network functions. Virtualization makes it possible to spin up resources as needed to meet the demands of fluctuating and evolving workloads, while also taking advantage of the cost savings that come with commercial off-the-shelf (COTS) hardware. NFV also includes containers to host networking operations. NFV architecture is built on three components: virtualized network functions (VNFs), the NFV infrastructure (NFVI) and an administrative framework that handles management and orchestration architecture (MANO).
[0071] VNFs are software applications that run in virtual machines (VMs) and carry out specific networking tasks, such as routing or load balancing. An individual VNF can span multiple VMs, and the network administrators may couple multiple VNFs to deliver broader network services. The NFVI component provides an underlying structure to host the VMs and run the VNF applications. The infrastructure includes the physical computing, storage, and network resources, as well as a hypervisor-based virtualization layer that abstracts the resources and makes them available to the VNFs. The MANO handles all VNF-related tasks, such as chaining, connectivity and lifecycle management. The MANO is also responsible for managing, monitoring and optimizing NFVI hardware and virtual resources. The MANO is focused on specifying operations at each interface. The MANO includes three essential components a virtualized infrastructure manager (VIM), a CNF manager (CNFM), and a NFV orchestrator (NFVO). It is required that an event (demand for a specific service) raised by the user (or network entity) should be handled by the MANO effectively. It is required that these components are able to communicate with each other in a flexible manner.
[0072] The various components of the MANO have limited connectivity to transfer data or requests with each other. Further, specific interfaces are required to connect the different components (network services), which are hardcore designed and limited to certain network services only. This results in the need for multiple interfaces to provide connectivity as per network requirements, leading to a complex and expensive solution.
[0073] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by promoting interoperability between various components of the MANO, such that it is easier for them to work seamlessly together. In an aspect, the present disclosure may be configured to provide an event routing manager (ERM) that is configured to provide seamless data communication between the NFVO and the CNFM, and the CNFM and the VIM.
[0074] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs. 1A-6.
[0075] FIG. 1A illustrates an exemplary network architecture (100A) for implementing a system (108) for routing a plurality of service requests in a management and orchestration (MANO) framework, in accordance with an embodiment of the present disclosure.
[0076] As illustrated in FIG. 1A, the network architecture (100A) 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 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). Although only three UE (104) are depicted in FIG. 1A, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.
[0077] 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 is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, 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 is not limited to, intelligent, multi-sensing, network-connected devices, which 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.
[0078] 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 is 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, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein 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 the entity such as touchpad, touch-enabled screen, 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.
[0079] Referring to FIG. 1A, the UE (104) may communicate with the system (108) through the network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100A) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0080] 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 a radio access network (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.
[0081] In an embodiment, an event routing manager (ERM) (130) provides the interconnectivity between components of the MANO to allocate one or more network services. The ERM (130) receives at least one service request received from at least one network entity. The ERM (130) sends the at least one service received request to a network functions virtualization orchestrator (NFVO). The ERM (130) receives at least one orchestration request generated by the NFVO on receiving the at least one service request. The ERM (130) analyzes the received at least one orchestration request to determine at least one network service associated with one of components of the MANO. The ERM (130) forwards the analyzed at least one orchestration request towards the allocated network service associated with one of components of the MANO.
[0082] The at least one allocated network service is associated with one of a containerized network function manager (CNFM) and a virtualized infrastructure manager (VIM). In an aspect, the network services corresponding to the NFVO include, but are not limited to, service orchestration network services, resources management network services, monitoring and analytics network services, and policy management network services. The network services corresponding to the CNFM include, but are not limited to, virtualized network function (VNF) management network services, network service management network services, fault management network services, and configuration management network services. The network services corresponding to the VIM include, but are not limited to, compute resource management network services, storage management network services, network management network services, and resource monitoring network services.
[0083] In an embodiment, the user equipment (104) is communicatively coupled with the system (108). The system (108) receives a connection request from the UE (104). The system (108) sends an acknowledgment of the connection request to the UE (104). The UE (104) transmits a plurality of signals in response to the connection request.
[0084] Although FIG. 1A shows exemplary components of the network architecture (100A), in other embodiments, the network architecture (100A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1A. Additionally, or alternatively, one or more components of the network architecture (100A) may perform functions described as being performed by one or more other components of the network architecture (100A).
[0085] Referring to FIG. 1B, illustrates another exemplary network architecture (100B) for implementing an event routing manager (ERM)_ containerized network function manager (CNFM) (EM_Cnfm) interface for the MANO framework (105), in accordance with an embodiment of the present disclosure.
[0086] In an aspect, the ERM (130) may be integrated with the MANO framework (105) or may be connected as an external device with the MANO framework (105). In an example, the exemplary network architecture (100B) may include multiple MANO frameworks and multiple ERMs. However, for the sake of brevity, single MANO framework (105) and single ERM (130) have been shown. In an aspect, the multiple ERMs (130) may be configured to communicate with each other. The multiple ERMs (130) may be able to disperse the service requests such that multiple service requests can be processed simultaneously without any delay.
[0087] The MANO framework (105) may be commutatively coupled with several network entities (not shown in figures). For example, the plurality of network entities may be a logical entity or a physical entity within the network that is being managed or controlled. The network entity (may be referred to as an actor) is preferably designed with built-in instrumentation, which allows for the collection of relevant information that may be subsequently used to determine control actions to be applied to the network entity. In the network architecture (100B) of FIG. 1B, the plurality of network entities may be any hardware or software component that has a measurable parameter that can be reported. Examples of network entities (may also be referred to as network elements) include virtual routers, virtual switches, hosts, virtual modems, terminals, dial access servers, virtual gateways, ports, channels, interfaces, circuits, processes, drivers, protocols, services, applications, etc. In an aspect, the actor is any entity or component involved in interacting with the network services.
[0001] The ERM (130) may be adapted as a software and may be added as a network service within the MANO framework (105). In an example, the ERM (130) is a publisher subscriber-based network service. In an embodiment, the ERM (130) is a combination of an event-based architecture and a publish/subscribe architecture and takes advantage of both architectures.
[0088] As shown in FIG. 1B, the MANO framework (105) includes a NFV orchestrator (NFVO) (110), a containerized network function manager (CNFM) (115), and a virtualized infrastructure manager (VIM) (120). For example, the CNFM (115) may be replaced with a virtualized network functions manager (VNFM). The NFVO (110) may be configured to cooperate with a CNF catalog management, a network service catalog, and a policy execution engine. The NFVO (110) may be configured to perform resource orchestration and service orchestration. In the resource orchestration, the NFVO (110) may be configured to coordinate, authorize, release, and engage the network functions virtualization infrastructure (NFVI) resources. In the service orchestration, the NFVO (110) may be configured to manage lifecycle network service (NS) instances (instantiation, scaling, termination, update, etc. of NS instances). The NFVO (110) may be configured to create end-to-end service among different VNFs (different VNFMs may manage that).
[0089] The CNFM (115) may be configured to determine the lifecycle of the CNF instances (for example, instantiation, update, query, scaling, termination, etc.).
[0090] The VIM (120) may be configured as an orchestration adapter. The VIM (120) may be configured to manage computing, storage, and network resources of the NFVI, monitor a failure of the NFVI, and monitor resources of the NFVI. In an example, the NFVI is the NFV Infrastructure that includes physical (server, storage, etc.), virtual resources (Virtual Machines), and software resources (hypervisor) in an NFV environment). In an example, the MANO framework (105) may include multiple VIMs, each managing its respective NFVI domain. The VIM (120) may be configured to manage the life cycle of virtual resources in the NFVI domain. The VIM (120) creates and maintains virtual machines (VMs) from physical resources in the NFVI domain. The VIM (120) is configured to maintain an inventory of virtual machines (VMs) associated with physical resources. In an example, the VIM (120) is configured to handle performance and fault management of hardware, software, and virtual resources.
[0091] In an aspect, the MANO framework (105) may be configured to incorporate the ERM (130). It may be configured to augment its capabilities with additional functionalities that provide enhanced container infrastructure monitoring, management, and analytics.
[0092] In an example, the MANO framework (105) may include a telecom operation support system (i.e., Operations Support System and Business Support System, OSS/BSS), a containerized service management module (i.e., container infrastructure service manager, CISM), and a network element management system.
[0093] In an operative aspect, the network entity is configured to send a request (for example, a containment request) to the NFVO (110). In an example, the containment request refers to a request for isolating containerized network functions (CNFs) to manage issues (e.g., performance degradation, security risks, or resource conflicts. The NFVO (110) is further configured to forward the containment request to the VNFM or the CNFM (115) according to the type of network entity corresponding to the containment request (i.e., VNF or CNF), so that the VNFM or CNFM (115) may perform a resource containment processing of the related VNF or CNF respectively.
[0094] In an aspect, the ERM (130) may include a plurality of interfaces. In an example, the plurality of interfaces includes a first interface (OR_EM), a second interface (EM_Cnfm), and a third interface (EM_Vi). The ERM (130) may be configured to implement an async event-based approach to utilize the plurality of interfaces efficiently. The first interface (OR_EM) may be coupled to the NFVO (110) and may be configured to receive the plurality of service requests from the NFVO (110). The first interface (OR_EM) may also be configured to transfer an acknowledgment message and a delivery report to the NFVO (110) (e.g., publisher). The first interface (OR_EM) may be configured to operate in a high availability mode, ensuring continuity of service processing. The first interface (OR_EM) of the ERM (130) may be configured to communicate an update signal to the NFVO (110) indicating the status of the processed request.
[0095] The second interface (EM_Cnfm) may be coupled with the CNFM (115) and receives service requests from the NFVO (110). The second interface (EM_Cnfm) may be configured to translate the received service requests into specific resource and VNF configurations and manage the lifecycle of VNF instances. The second interface (EM_Cnfm) may be configured to forward the translated service request to the specific network service for the request processing, which includes resource provisioning and initiating via the CNFM (115). After the request processing, the specified network service associated with the CNFM (115) may be configured to generate an event acknowledgment. The second interface (EM_Cnfm) of the ERM (130) may be configured to receive the event acknowledgment from the CNFM (115). In an aspect, the ERM (130) may be configured to route the request to a specified network service using the second interface (EM_Cnfm) to allocate the necessary resources by spawning the resources. In an example, the second interface (EM_Cnfm) may be used to send the different types of service requests from the network service of NFVO (110) to another network service or group of network services in the CNFM (115) using the event name or the NFVO (110) to another network service or group of network service in the VIM (120). The second interface (EM_Cnfm) may be configured to operate in a high availability mode, ensuring continuity of service processing.
[0096] In an example, the second interface (EM_Cnfm) may configured to provide communication from the CNFM (115) to the NFVO (110) for container life cycle management, resource allocation and management, fault management and recovery, resource optimization and scaling decisions.
[0097] The CNFM (115) may interact with the VIM (120) to request and allocate resources for operation. In an example, the second interface (EM_Cnfm) may be configured to provide communication from the CNFM (115) to the VIM (120) to get information regarding the state and health of the underlying virtualized infrastructure optimizing their resource allocation to ensure efficient use of infrastructure resources.
[0098] In an example, the third interface (EM_Vi) may be coupled with the VIM (120). The EM_Vi interface is configured to provide communication between the ERM (130) and the VIM (120).
[0099] In an embodiment, the ERM (130) may be coupled with an operations, administration, and maintenance module (OAM) (125) via an EM_Oa interface. The OAM (125) may be configured to perform operations, administration, and maintenance of a plurality of activities involved in managing and maintaining a system or process.
[00100] In an embodiment, the ERM (130) may be configured to provide a deferred delivery in case a specific subscriber network service fails. In such a scenario, the ERM (130) may be configured to store the event and may communicate the event to the specific subscriber network service after a predefined time.
[00101] In an aspect, the ERM (130) plays an essential role in event-driven systems where events need to be delivered from event sources (publishers) to appropriate event consumers or downstream services (subscribers). The ERM (130) may be configured to provide event distribution by efficiently distributing events to multiple consumers or services based on the event name. Further, the ERM (130) helps in adding multiple event producers and consumers in the event-driven systems without affecting the overall system's functionality or performance. The ERM (130) supports dynamic routing in event-driven systems by enabling the system to adapt to changing requirements. The ERM (130) provides various mechanisms (e.g., retry mechanism) to handle errors or failures during event routing and ensure reliable delivery of the events, even in transient failures or network issues.
[00102] In an aspect, the ERM (130) may automatically detect failed service requests and facilitate the rerouting of service requests to alternative healthy instances or services, thereby improving overall resilience and minimizing network downtime. In an aspect, the ERM (130) may be configured to provide advanced automation features and enhanced scalability.
[00103] In an embodiment, the ERM (130) may perform asynchronous communication between the NFVO (110) and the CNFM (115), as well as between the NFVO (110) and the VIM (120). For instance, the ERM (130) facilitates sending selective service requests to a group of NFVOs that have subscribed to the relevant event.
[00104] In an embodiment, the service requests are routed based on the event publishers and subscribers configured along with hypertext transfer protocol (HTTP) headers. Events corresponding to the service requests need to be delivered from event sources (publishers) to appropriate event consumers (subscribers). The ERM (130) is configured to provide event distribution by efficiently distributing events to multiple consumers or services based on the HTTP headers. In an aspect, the HTTP headers are key-value pairs sent in HTTP requests and responses. The HTTP headers provide metadata about the request or response and can include information such as content type, authorization tokens, and custom headers for routing or filtering purposes. The HTTP headers can be used to include metadata or routing information in event requests. This metadata can be utilized to direct the event to specific consumers or services based on its content or characteristics.
[00105] In an aspect, the MANO framework (105) includes the VIM (120), the CNFM (115) and the NFVO (110). The VIM (120) is responsible for managing the underlying infrastructure resources required for virtualization. The CNFM (115) oversees and controls Containerized Network Functions (CNFs), ensuring their proper functioning. The NFVO (110) plays a crucial role in orchestrating services, overseeing the deployment, and managing resources efficiently. The three managers (i.e., the VIM (120), the CNFM (115) and the NFVO (110)) collaborate closely to facilitate the flexible and efficient deployment and management of virtualized services. Multiple network services operate within each of the manager components. Three managers communicate with one another using specific event names. The ERM (130) directs incoming requests based on the event name to the appropriate network service, employing designated interfaces. This enhances the overall functionality and effectiveness of the MANO framework (105). Further, the EM_Cnfm interface plays a crucial role in facilitating communication between the NFVO (110) and the CNFM (115), the CNFM (115) and the VIM (120). The NFVO (110) and the CNFM interface are responsible for taking the high-level service requests from the NFVO (110), translating them into specific resources and the VNF configurations, and managing the lifecycle of VNF instances. The CNFM and the VIM interface is responsible for taking the service requests from the CNFM (115) and managing the underlying infrastructure resources required for virtualization. The CNFM (115) interacts with the VIM (120) to request and allocate resources for the operation of the VIM (120). The EM_Cnfm interface receives the request generated from the orchestration and sends the request to the CNFM (115) and/or VIM (120).
[00106] In an aspect, the EM_Cnfm interface executes mutually exclusive events in parallel within the virtualized infrastructure. The EM_Cnfm interface involves handling events that do not occur simultaneously but are processed independently in parallel environments.
[00107] Although FIG. 1B shows exemplary components of the network architecture (100B), in other embodiments, the network architecture (100B) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1B. Additionally, or alternatively, one or more components of the network architecture (100B) may perform functions described as being performed by one or more other components of the network architecture (100B).
[00108] FIG. 1C illustrates an exemplary block diagram (100C) of the system (108) for routing the plurality of service requests in the MANO framework (105), in accordance with an embodiment of the present disclosure.
[00109] Referring to FIG. 1C, in an embodiment, the system (108) may include one or more processor(s) (111), a memory (112), a plurality of interface(s) (114), and a database (122). The one or more processor(s) (111) 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) (111) may be configured to fetch and execute computer-readable instructions stored in the memory (112) of the system (108). The memory (112) 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 (112) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[00110] In an embodiment, the interface(s) (114) 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) (114) may facilitate communication through the system (108). The interface(s) (114) 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 database (122).
[00111] The system (108) includes the event routing manager (ERM) (130) and the database (122). The ERM (130) includes a communication unit (116) and an analyzing unit (118).
[00112] The communication unit (116) is configured to receive at least one service request received from the at least one network entity.
[00113] In an aspect, the at least one network entity includes, but is not limited to, virtual switches, virtual routers, virtual firewall, virtual load balancer, virtual private network (VPN) gateways, virtualized network interface cards, virtualized network functions, etc. In an aspect, the virtual switches are used by virtual machines (VMs) or containers to communicate with each other and with the external network. In an aspect, the virtual routers perform routing functions within the virtualized network, directing traffic between different subnets or virtual networks. In an aspect, the virtual network interface cards are virtualized network interfaces that allow VMs or containers to connect to the virtual switches or networks. In an aspect, the virtual firewalls are software-based firewalls that provide network security by monitoring and controlling incoming and outgoing network traffic based on predefined security rules. In an aspect, the virtual load balancers distribute incoming network traffic across multiple servers or services to ensure high availability and reliability. In an aspect, the VPN gateways provide secure connectivity between virtual networks or between a virtual network and an on-premises network. In an aspect, virtualized network functions (VNFs) are network functions that are virtualized and run on virtualized infrastructure instead of dedicated hardware. Furthermore, in an aspect, the network entity includes at least one of external systems. The external systems include, but are not limited to, a network slicing management platform, a support ticket system, a subscriber support system, a performance management system, a network management system, a container network infrastructure monitoring system. In an aspect, the network slicing management platform is designed to create, manage, and optimize network slices in the network. Network slicing allows multiple virtual networks to be created on the shared physical infrastructure. In an aspect, the support ticket system supports requests related to network services and virtual functions. In an aspect, the subscriber support system manages interactions and support requests from subscribers. In an aspect, the performance management system is used to monitor, evaluate, and optimize the performance of virtualized resources, such as virtual machines (VMs), containers, and network services. In an aspect, the network management system is used to monitor, control, and optimize network resources and network services. In an aspect, the container infrastructure monitoring system is used to monitor and manage the performance, availability, and health of containerized applications and the underlying infrastructure. In an example, the at least one network service is a container lifecycle manage network service, a resource allocation network service, a fault management and recovery service network service, and a resource optimization and scaling network service. In a modern cloud-native application, several network services work together to manage containerized workloads efficiently. The container lifecycle manager network service oversees the entire lifecycle of containers. It handles tasks such as provisioning new containers, deploying them across the infrastructure, scaling them up during peak usage, and terminating them when no longer needed. This network service ensures that containers are managed efficiently, allowing for smooth updates and version control, which is essential for maintaining application reliability. The resource allocation manager network service is responsible for dynamically allocating resources and optimizing the use of both physical and virtual resources based on current demand. It continuously monitors resource usage and adjusts allocations in real-time to ensure optimal performance and availability. For example, if a particular container experiences increased traffic, the resource allocation manager network service automatically allocates additional CPU and memory resources to handle the load. Additionally, the fault management and recovery service network service plays a crucial role in maintaining system reliability. It focuses on detecting and diagnosing faults within the system and implementing monitoring tools to identify issues quickly. When a failure occurs, this service triggers automated recovery processes, such as restarting failed containers or reallocating resources to ensure service continuity. The resource optimization and scaling network service analyzes resource usage patterns to optimize performance further. By utilizing predictive analytics, it can anticipate demand spikes and proactively allocate additional resources, or scale back during periods of low demand, ensuring both cost efficiency and performance optimization.
[00114] 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. In an example, the container life cycle management request includes, but is not limited to, container creation request, container scaling request, container update request, container restart request, container stop request, container removal request, container health request, container configuration request, etc. In an aspect, the resource allocation and management request include, but is not limited to, request to allocate central processing unit (CPU) or memory to virtual machines (VMs), request to resize the VMs, request to allocate storage to VMs, request to modify storage allocation, request to deallocate resources from VMs, request to monitor resource utilization, request to update resource allocation policies, etc. The fault management and recovery request includes, but is not limited to, request to detect a fault, request to restart a faulty VM, request to reboot a host, request to restore VM from backup, request to update fault tolerance settings, etc. The resource optimization and scaling request includes, but is not limited to, request to scale up or scale down the VM, request to auto scale container service, request to optimize storage allocation, request to adjust network bandwidth allocation, request to provision additional VMs, request to monitor and adjust performance metrics, request to optimize load balancer configuration, etc.
[00115] The communication unit (116) is configured to send the received at least one service request to the NFVO (110) associated with the MANO framework (105). The NFVO (110) is configured to process the received at least one service request and generates at least one orchestration request. The orchestration request comprises at least one operation associated with the resources, wherein the at least operation is one of allocation of the resources and deallocation of the resources. In an aspect, the orchestration request may refer to a command or series of commands issued to manage and automate the deployment, scaling, operation, and decommissioning of resources. The orchestration request includes, but is not limited to, request to provision a new virtual machine, request to configure load balancers, request to backup and restore resources, request to monitor and adjust performance, request to schedule maintenance, request to optimize resource utilization, etc.
[00116] The communication unit (116) is configured to receive the at least one orchestration request from the NFVO (110). In an aspect, the ERM (130) receives the at least orchestration request from the NFVO (110).
[00117] The communication unit (116) is configured to receive the at least one orchestration request. The analyzing unit (118) is configured to analyze the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework (105). In an aspect, the at least one component of the MANO framework includes the CNFM (115) and the VIM (120).
[00118] In an aspect, the analyzing unit (118) is configured to identify/allocate the at least one network service by extracting one or more parameters from the at least one received service request. In an embodiment, the one or more extracted parameters include at least one of the network entity identifier (ID) and a request type. The extraction allows the analyzing unit (118) to identify and transmit the at least one received request to the least one network service capable of handling the specified at least one network entity and requested operation.
[00119] The analyzing unit (118) is configured to forward the analyzed at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework (105) via the interface (i.e., EM_Cnfm interface). The determined network service is associated with the CNFM (115) and the VIM (120). In an aspect, upon receiving the at least one orchestration request via the interface, the CNFM (115) is configured to process the at least one received orchestration request to generate at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization. In an aspect, the CNFM (115) processes the orchestration request to determine the current state of resources (e.g., computing resource, storage resource, network resource, etc.) and check whether the existing infrastructure supports the requirement for processing of the received service request. The CNFM (115) further provides information corresponding to resource allocation, deployment, configurations (e.g., network policies, security settings, scaling parameters, etc.). In this way, the CNFM (115) provides information corresponding to resource assessment, deployment planning, and monitoring.
[00120] In an aspect, the VIM (120) is configured to receive the at least one information from the CNFM (115) via the ERM (130) and is further configured to analyze the received at least one information to manage at least one underlying infrastructure resource for virtualization. In an aspect, the VIM (120) analyzes the information received from the CNFM to perform the allocation of computing resources, storage resources, and network resources. Further, the VIM (120) performs virtualization management (i.e., create, manage, and terminate virtual machines that host VNFs), network management (i.e., configuration and management of virtual networks, including virtual switches and routers, enabling communication between VNFs and other components, load balancing, fault management, security, etc.
[00121] In an aspect, states of the virtualized infrastructure associated with the network service include operational state, pending state, scaling state, decommissioning state, failure state, recovery state, maintenance state, standby state, healthy state, unhealthy state, deployment complete state, configuration changing state, resource allocation state, etc. In an aspect, the communication path refers to an interface used for communication between components.
[00122] Allocation of resources associated with the network service includes assigning and managing computing resources such as CPU, memory, storage, and network bandwidth to the network services. The resource allocation includes, but is not limited to, CPU allocation, memory allocation, storage allocation, network bandwidth allocation, auto-scaling resources, resource balancing, resource monitoring and adjustment, etc.
[00123] The communication unit (116) is configured to send an acknowledgement of the processing of the at least one service request to the at least one network entity. In an aspect, the acknowledgment is sent to provide the status of at least one service request. The acknowledgment is sent to confirm that the service request has been received and processed. The status of the at least one service request includes success or failure. In this way, the system (108) provides the guaranteed message delivery with acknowledgement and delivery report.
[00124] In an aspect, responsive to detection failure of the network service allocation during processing of the at least one service request, the communication unit (116) is configured to reroute the at least one service request to another network service (healthy network service) based on a plurality of routing configurations. The ERM (130) ensures automatic detection of failed services and facilitates rerouting requests to alternative healthy instances or network services. This improves overall system resilience and minimizes downtime.
[00125] In an aspect, a plurality of routing configuration is stored based on a plurality of service (network service) names and fully qualified domain name (FQDN) addresses in the database (122). In an example, the plurality of network service names includes, but is not limited to, infrastructure services, container orchestration services, application services, monitoring and management services, security services, networking services, storage services, deployment services, backup and recovery services, access management services, resource allocation services, configuration services, etc. In an aspect, the fully qualified domain names (FQDNs) are used to uniquely identify and locate resources within a domain. The FQDNs are essential for ensuring that network resources can be correctly addressed and accessed.
[00126] The analyzing unit (118) is configured to map the at least one service request to the routing configurations based on the service name and the FQDN address of the service request. The at least one service request is routed to the allocated network service based on the mapped routing configuration. The at least one received service request includes a defined service name and a defined FQDN address. In an example, the service request is a load balancing service request. The service name is load balancing, the FQDN address is lb-web.example.com. (e.g., the load balancer for web traffic with the hostname lb-web in the example.com domain).
[00127] The analyzing unit (118) may be configured to fetch and execute computer-readable instructions stored in the memory. The analyzing unit (118) may be configured to execute a sequence of instructions of the method to route the received service requests, which may be embodied in a program or software. The instructions can be directed to the analyzing unit (118), which may subsequently program or otherwise be configured to implement the methods of the present disclosure. In some examples, the analyzing unit (118) is configured to control and/or communicate with large databases, perform high-volume transaction processing, and generate reports from large databases. The analyzing unit (118) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
[00128] In an aspect, the ERM (130) is configured to operate in a deferred event configuration in which the ERM (130) is configured to retry or reschedule a processing of the at least one service request having initially failed delivery. The deferred event configuration in a virtualized infrastructure refers to the management of events and their handling in a way that delays or schedules the processing of certain events to optimize performance, resource utilization, or system responsiveness. In an example, in case of fault management and recovery, handling fault events or triggering recovery actions might be deferred to prevent immediate system strain. The event includes fault detection, recovery action request. The deferred handling includes queue fault recovery actions and prioritize based on severity. The fault management system schedules recovery actions (e.g., queuing and prioritizing recovery actions).
[00129] In an embodiment, the system (108) includes the database (122) that includes data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (111). The database (122) stores the plurality of routing configurations based on the plurality of service names and FQDN addresses. The database (122) may include any computer-readable medium known in the art including, for example, volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM), and/or nonvolatile memory, such as Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an aspect, the database (122) may be implemented in the ERM (130).
[00130] In an aspect, the database (122) is configured to store program instructions and data corresponding to a plurality of service requests. The database (122) is configured to store the data received from the NFVO (110), a list of events registered service requests, a list of having status of the received service requests, and a list of network services corresponding to registered service requests. The program instructions include a program that implements a method for providing enhanced interconnectivity for communicating data between various components of the MANO framework (105) in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification.
[00131] Although FIG. 1C shows exemplary components of the block diagram (100C) of the system (108), in other embodiments, the block diagram (100C) of the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1C. Additionally, or alternatively, one or more components of the block diagram (100C) of the system (108) may perform functions described as being performed by one or more other components of the block diagram (100C) of the system (108).
[00132] FIG. 2 illustrates an exemplary flow diagram (200) of processing the service request between the components of the MANO framework (105) via the EM_Cnfm interface, in accordance with an embodiment of the present disclosure.
[00133] At step 202, one of the network entities (201) generates a service request. In an example, the service request includes a provision resource request, a create resource request, a termination request, and an initialize resource request. The generated service request is communicated to the ERM (130). The ERM (130) determines whether the received plurality of service requests (events) is valid or not. In an example, if the received service request (event) exists within the memory of the ERM (130), then it is valid.
[00134] At step 204, the ERM (130) forwards the service request to the MANO framework (105). In an example, the ERM (130) is configured to analyze the received service request to allocate the specific network service associated with the MANO framework (105) accordingly. For example, if the ERM (130) analyzes that the received service request is the provision resource request, then the ERM (130) forwards the received request to the NFVO (110). In an example, the MANO framework (105) includes the VIM (120), the CNF manager (CNFM) (115), the NFVO (110), the OAM (125), and the ERM (130). The NFVO (110) is configured to perform the resource orchestration and network service orchestration.
[00135] At step 206, the NFVO (110) is configured to receive the service request from the network entity (201) via the ERM (130) and generate an orchestration request accordingly. In an aspect, the orchestration request may include a set of instructions to be followed by the CNFM. In an aspect, the NFVO (110) is responsible for the onboarding of CNFs and network services that are managed by the same or different CNFMs. The NFVO (110) communicates with the CNFM and coordinates, authorizes, releases, and engages the virtual storage and networking resources. The NFVO (110) is also configured to manage the life cycles of network services of the CNFM.
[00136] At step 208, the ERM (130) receives the orchestration request from the NFVO (110). In an example, the orchestration request includes various service requests including a life 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 example, the ERM (130) analyzes the received service requests to determine a specific network service associated with one of components of the MANO framework (105) accordingly.
[00137] In an example, the ERM (130) forwards the received orchestration request either to the CNFM (115) or the VIM (120), or both. The analyzed service request (for example, the orchestration request) is forwarded to the CNFM (115).
[00138] At step 212, the CNFM (115) processes the received request and generates an orchestration request. Upon detecting an increase in traffic, the CNFM (115) identifies the need to scale out a network function to handle the load. The orchestration request includes a scale up request. For instance, the CNFM (115) generates an orchestration request to increase the number of replicas for the containerized network function.
[00139] At step 214, the ERM (130) receives the orchestration request from the CNFM (115). In an example, the ERM (130) receives the orchestration request (e.g., scale up request) from the CNFM (115).
[00140] In an aspect, after step 208, the flow diagram may go to step 216. At step 216, the ERM (130) forwards the received orchestration request (e.g., scale up request) to the VIM (120).
[00141] At step 218, the VIM (120) processes the received request and generates a service request acknowledgment. The VIM (120) processes the received request (e.g., scale up request) and generates a service request acknowledgment (e.g., acknowledgment for scale up request). In an example, step 218 may include a step of generating at least one information. In an example, the at least one information includes a state of the virtualized infrastructure associated with the specific network services.
[00142] In an aspect, the state of the virtualized infrastructure associated with the specific network services include, but is not limited to, static allocation (e.g., resources are allocated based on fixed parameters), dynamic allocation (e.g., resources are allocated based on number of requests, resource availability, predefined limits), automated scaling (e.g., automatically adjusting number of instances based on metrics (e.g., usage or request load).
[00143] At step 220, the ERM (130) receives the service request acknowledgment (e.g., acknowledgment of scale up request) from the VIM (120).
[00144] At step 222, the ERM (130) communicates an update signal towards the network entity (201) indicating a status of the processed request. In an example, the update signal may represent a status of the received service request. In an example, the status may be a success or a failure.
[00145] FIG. 3 illustrates another exemplary flow diagram (300) describing “service request” processing, in accordance with an embodiment of the present disclosure.
[00146] At step 302, the plurality of service requests is generated by the network entities (201). The generated plurality of service requests is sent to the ERM (130).
[00147] At step 304, the ERM (130) forwards the plurality of service requests towards the NFVO (110).
[00148] At step 306, the NFVO (110) analyzes the received service request. the NFVO (110) generates an orchestration request. In an aspect, the orchestration request may include a set of instructions to be followed by the CNFM (115).
[00149] At step 308, the ERM (130) receives the orchestration request from the NFVO (110). In an example, the ERM (130) analyzes the received orchestration request to allocate a specific network service associated with the MANO framework (105) accordingly.
[00150] At step 310, the ERM (130) forwards the received orchestration request to the CNFM (115).
[00151] At step 312, the CNFM (115) processes the received orchestration request by the CNFM (115) and generates an orchestration request. In an aspect, the orchestration request may include a set of instructions to be followed by the VIM (120).
[00152] At step 314, the ERM (130) receives the orchestration request from the CNFM (115).
[00153] At step 316, the ERM (130) forwards the received orchestration request to the VIM (120).
[00154] At step 318, the VIM (120) processes the received orchestration request and generates an orchestration request. In an aspect, the orchestration request may include at least one information. In an example, at least one information includes the state of the virtualized infrastructure associated with the VIM (120).
[00155] At step 320, the ERM (130) may include receiving the orchestration request from the VIM (120).
[00156] At step 322, the ERM (130) forwards the received orchestration request having at least one information to the CNFM (115).
[00157] At step 324, the CNFM (115) analyzes the received at least one information and allocates resources associated with the VIM (120) accordingly. The CNFM (115) processes the received request and generates a service request acknowledgment.
[00158] At Step 326. the ERM (130) receives the service request acknowledgment from the CNFM (115).
[00159] At step 328, the ERM (130) forwards the service request acknowledgment towards the network entity (201) indicating the status of the processed request. The status of the processed request includes success or failure.
[00160] In an example, the CNFM (115) may be configured to automate the development, deployment, maintenance, and operation of the network to effectively handle escalating demand, accelerate deployments, and reduce complexity.
[00161] FIG. 4 illustrates an exemplary representation of a MANO framework architecture (400), in accordance with an embodiment of the present disclosure.
[00162] 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. The interconnected 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).
[00163] The user interface layer (402) may serve as a primary point of interaction for the network operators and the network administrators. Through the user interface layer (402), various parameters associated with the ERM (130) may be configured and adjusted based on specific requirements. These parameters may include a number of network services associated with ERMs, a number of ERMs that may be deployed simultaneously, and other relevant settings.
[00164] 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 (130). The modules may be responsible for determining the target network service within the MANO framework based on a type of resource allocation required. The modules may utilize a mapping of service request types to target network services maintained by the ERM (130) to ensure accurate routing. The NFV and SDN design functions (404) may include a virtualized network function (VNF) lifecycle manager (compute) that is a specialized component focused on managing the compute resources associated with 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 VNF, facilitating their deployment and lifecycle management. The NFV and SDN design functions (404) may include network services catalog, network slicing and service chaining manager, physical and virtual resource manager and 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 & service chaining manager is responsible for orchestrating network slices and service chains, ensuring efficient allocation and utilization of network resources tailored to various services. The physical and virtual resource manager oversees both physical and 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 the CNF, including onboarding, instantiation, scaling, monitoring, and termination, thereby facilitating the efficient deployment and operation of network functions in a cloud-native environment.
[00165] The platform foundation services (406) may support an asynchronous event-based processing model implemented by the ERM (130), enabling concurrent handling of multiple service requests. They may also facilitate bi-directional communication interfaces (NMS_EM and EM_MS) used by the ERM (130) to interact with the external systems (e.g., the NMS) and the MANO framework network services. The platform foundation services (406) may include network services elastic load balancer, identity & access manager, command line interface (CLI), central logging manager, and the ERM. The network services elastic load balancer ensures that incoming traffic is evenly distributed across multiple network services, 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 platform, 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.
[00166] The platform core services (408) are central to the processing and fulfillment of the service requests (i.e., 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 infrastructure resources based on each of the at least one service request routed by the ERM (130). The platform core services (408) may include NFV infrastructure monitoring manager, assurance manager, performance manager, policy execution engine, capacity monitoring manager, release management repository, configuration manager & Golden Configuration Template (GCT), NFV platform decision analytics platform, Not Only SQL database (NoSQL DB), platform schedulers & jobs, VNF backup & upgrade manager, and network service auditor. The NFV infrastructure monitoring manager tracks and oversees the health and performance of NFV infrastructure. The assurance manager ensures service quality and compliance with operational standards. The performance manager monitors system performance metrics to optimize efficiency. The policy execution engine enforces and executes policies across the platform. The capacity monitoring manager tracks resource usage and forecasts future needs. The release management repository manages software releases and version control. The configuration manager handles system configurations, ensuring consistency and automation. The GCT provides centralized oversight and management of platform 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 network service auditor ensures the integrity and compliance of network services across the platform.
[00167] The platform operation, administration, and maintenance manager (410) 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 (130) to distribute the service requests across multiple instances of the MANO framework network services.
[00168] 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 resource allocation. The platform resource adapters and utilities (412) may include platform external API adapter and gateway, generic decoder, and indexer, orchestration adapter, API adapter, and NFV gateway. The platform external API adapter and gateway facilitates seamless integration with external APIs and manages data flow between external systems and the platform. The generic decoder and indexer processes and organizes data from various formats such as XML, comma-separated values (CSV), and JSON, ensuring compatibility and efficient indexing. The orchestration adapter manages interactions with clusters, enabling container orchestration and scaling. The API adapter interfaces with services, allowing integration and management of cloud resources. The NFV gateway acts as a bridge for NFV communications, coordinating between NFV components and other platform elements.
[00169] The ERM (130) may interact with all these modules to facilitate an end-to-end process of a service request handling. The ERM (130) 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 resource 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 resource allocation and management, potentially providing a flexible and responsive system capable of meeting diverse service requirements in a dynamic network environment.
[00170] FIG. 5 illustrates an exemplary flow diagram of a method (500) for routing the plurality of service requests in the MANO framework (105) by the ERM (130), in accordance with an embodiment of the present disclosure.
[00171] At step 502, the method (500) includes receiving at least one service request from at least one network entity (201). In an aspect, the at least one service request comprise a request of instantiating a VNF. The request (instantiating the VNF) is received from the network entity (e.g., network management system).
[00172] At step 504, the method (500) includes sending the received at least one service request to a network functions virtualization orchestrator (NFVO) (110) of the MANO framework (105). The NFVO (110) is configured to generate at least one orchestration request on receiving the at least one service request. In an aspect, the received request (e.g., instantiating the VNF) is sent to the NFVO (110). The NFVO (110) generates the orchestration request corresponding to the received request (e.g., instantiating the VNF). The orchestration request for instantiating the VNF includes information necessary to ensure that the VNF is deployed correctly.
[00173] At step 506, the method (500) includes receiving the at least one orchestration request from the NFVO (110). In an aspect, the orchestration request comprises at least one operation associated with the resources. The at least operation is one of allocation of the resources and deallocation of the resources. In an aspect, the ERM (130) receives the orchestration request corresponding to the received request (e.g., instantiating the VNF) from the NFVO. The orchestration request corresponding to the received request (e.g., instantiating the VNF) includes allocation of computing resources (e.g., CPU, memory), network requirements, location constraints, scaling policies (e.g., minimum number of instances to run, maximum number of instances to be allowed, scaling thresholds (e.g., CPU or memory thresholds)).
[00174] At step 508, the method (500) includes analyzing the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework (105). The at least one component of the MANO framework (105) is one of the CNFM (115) and the VIM (120). In an aspect, the received orchestration request from the NFVO (110) is analyzed to determine one component of the MANO (i.e., the CNFM (115) or the VIM (120))
[00175] At step 510, the method (500) includes forwarding the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework (105) via an interface (i.e., EM_Cnfm interface). In an aspect, the ERM (130) forwards the received orchestration request to the CNFM (115) via the interface (e.g., the EM_Cnfm interface). Upon receiving the orchestration request via the EM_Cnfm interface, the CNFM (115) processes the at least one received orchestration request to generate at least one information. The generated information corresponds to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization. In an example, the generated information includes the computing resources (e.g., CPUs = 4, Memory = 4GB RAM, storage = 100 GB), the network resources (e.g., IP address for public network and private network), location constraints (e.g., data center (DC1) and availability zone (AZ2), security and network policies (e.g., access control, firewall, routing policies).
[00176] In an aspect, the VIM (120) receives the at least one information from the CNFM (115) via the ERM (130). The VIM (120) analyzes the received at least one information to manage at least one underlying infrastructure resource for virtualization. In an aspect, the VIM (120) receives the generated information (i.e., includes the computing resources (e.g., CPUs = 4, Memory = 4GB RAM, storage = 100 GB), the network resources (e.g., IP address for public network and private network), location constraints (e.g., data center (DC1) and availability zone (AZ2)) from the CNFM (115) via the ERM (130). The VIM (120) performs the instantiation of the VNF in the network by efficiently allocating and managing the underlying infrastructure resources required for the instantiation of the VNF based on the received information from the CNFM. Further, the VIM (120) ensures that resources are provisioned correctly, monitored continuously, and managed in compliance with the service and network policies, thus enabling effective orchestration of network services.
[00177] In an aspect, the plurality of routing configurations is stored based on a plurality of service names and fully qualified domain name (FQDN) addresses in the database (122). The at least one orchestration request is mapped to the routing configurations based on the service name and the FQDN address of the service request. The at least one orchestration request is routed to the allocated network service based on the mapped routing configuration. In an example, for a load balancing request, the routing configuration includes the service name (e.g., load balancing) and FQDN address (e.g., IP address 192.0.2.1). The load balancing request is routed to the network service of the CNFM (115) based on the service name (e.g., load balancing) and FQDN address (e.g., IP address 192.0.2.1).
[00178] In an example, the state of the virtualized infrastructure associated with the defined network service include, but is not limited to, deployment state (e.g., provisioning or pending), operational state (e.g., active/running, idle), scaling state (e.g., scaling up, scaling down), maintenance state (e.g., upgrading, patching), monitoring (e.g., health monitoring, alerting), fault management state (e.g., fault detected, recovery/resilience), configuration state (e.g., initial setup/configuration change), resource management state (e.g., resource allocation/resource deallocation), security state (e.g., security assessment, compliance checking).
[00179] The at least one resource includes computing resources (e.g., CPU, memory allocation to VMs/containers), storage resources (e.g., disk space), network resources (e.g., bandwidth, IP addresses, network configuration), management resources (e.g., resources for monitoring, logging, orchestration, etc.)
[00180] Furthermore, in an aspect, the ERM (130) is configured to operate in a deferred event configuration in which the ERM (130) is configured to retry or reschedule the processing of the at least one service request having initially failed delivery. In an aspect, if deferred event configuration is enabled for any event, the ERM (130) may automatically retry the processing of such events even if the initial delivery failed. In an embodiment, the ERM (130) may be configured to provide a deferred delivery in case the specific subscriber network service fails. In such a scenario, the ERM (130) may be configured to store the event and may communicate the event to the specific subscriber network service after a predefined time.
[00181] FIG. 6 illustrates an exemplary computer system (600) in which or with which embodiments of the present disclosure may be implemented.
[00182] As shown in FIG. 6, the computer system may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (670) may include various modules associated with embodiments of the present disclosure. The communication port(s) (660) 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) (660) 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 connects.
[00183] The main memory (630) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) 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 (670). The mass storage device (650) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage device (650) 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, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks.
[00184] The bus (620) communicatively couples the processor (670) with the other memory, storage, and communication blocks. The bus (620) 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 670 to the computer system.
[00185] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (620) to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[00186] The exemplary computer system (600) is configured to execute a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for routing a plurality of service requests in a management and orchestration (MANO) framework by an event routing manager (ERM), the method includes receiving at least one service request from at least one network entity, sending the received at least one service request to a network functions virtualization orchestrator (NFVO) of the MANO framework, where the NFVO is configured to generate at least one orchestration request on receiving the at least one service request, receiving the at least one orchestration request from the NFVO, analyzing the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework, and forwarding the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework via an interface.
[00187] 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 skill in the art.
[00188] The present disclosure provides technical advancement related to an interface between the components of the MANO framework. This advancement addresses the limitations of existing solutions by using an Event Routing Manager (ERM) responsible for directing incoming requests based on the event name to an appropriate network service or manager component. The interface between CNFM and ERM (EM_Cnfm) is responsible for communication from CNFM to NFVO for life container life cycle management, resource allocation and management, fault management and recovery and resource optimization and scaling decisions. The interface between CNFM and ERM (EM_Cnfm) is responsible for communication from CNFM to VIM to get information regarding the state and health of the underlying virtualized infrastructure, optimizing the resource allocation to ensure efficient use of infrastructure resources. A high availability mode in which, if one ERM instance goes down during a request processing then next available instance will take care of the request. Asynchronized event-based implementation is provided to utilize interface efficiently. A deferred event configuration is enabled for an event in which the ERM automatically retries or reschedule the processing of the event even if the initial delivery failed.
TECHNICAL ADVANTAGES OF THE INVENTION
[00189] The present disclosure described herein above has several technical advantages including, but not limited to, the realization of an EM_Cnfm interface for connecting a containerized network function manager (CNFM) and a management and orchestration (MANO) framework that:
- provides the guaranteed message delivery with acknowledgement and delivery report, thereby enhancing the reliability of a communication system.
- enables automatic detection of failed services and facilitates the rerouting of requests to alternative healthy instances or services, thereby improving overall system resilience and minimizing downtime.
- sends the same request to a group of NFVO which subscribed for the event, thereby providing a flexible system.

,CLAIMS:CLAIMS
We claim:

1. A system (108) for routing a plurality of service requests in a management and orchestration (MANO) framework (105), the system (108) comprising an event routing manager (ERM) (130), the ERM (130) comprising:
a communicating unit (118) configured to:
receive at least one service request from at least one network entity (201);
send the received at least one service request to a network functions virtualization orchestrator (NFVO) (110) of the MANO framework (105), wherein the NFVO (110) is configured to generate at least one orchestration request on receiving the at least one service request; and
receive the at least one orchestration request from the NFVO (110); and
an analyzing unit (118) coupled with the communication unit (116) is configured to:
analyze the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework (105); and
forward the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework (105) via an interface.

2. The system as claimed in claim 1, wherein the at least one component of the MANO framework (105) is one of a containerized network function manager (CNFM) (115) and a virtualized infrastructure manager (VIM) (120) and wherein the interface is an event routing manager_containerized network function manager (EM_Cnfm) interface.

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

4. The system as claimed in claim 2, wherein upon receiving the at least one orchestration request via the interface, the CNFM (115) is configured to process the at least one received orchestration request to generate at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization.

5. The system as claimed in claim 4, wherein the VIM (120) is configured to receive the at least one information from the CNFM (115) via the ERM (130) and is further configured to analyze the received at least one information to manage at least one underlying infrastructure resource for virtualization.

6. A method for routing a plurality of service requests in a management and orchestration (MANO) framework (105) by an event routing manager (ERM) (130), the method comprising:
receiving at least one service request from at least one network entity (201);
sending the received at least one service request to a network functions virtualization orchestrator (NFVO) (110) of the MANO framework (105), wherein the NFVO (110) is configured to generate at least one orchestration request on receiving the at least one service request;
receiving the at least one orchestration request from the NFVO (110);
analyzing the received at least one orchestration request to determine at least one network service corresponding to at least one component of the MANO framework (105); and
forwarding the at least one orchestration request towards the determined network service corresponding to the at least one component of the MANO framework (105) via an interface.

7. The method as claimed in claim 6, wherein the at least one component of the MANO framework (105) is one of a containerized network function manager (CNFM) (115) and a virtualized infrastructure manager (VIM) (120) and wherein the interface is an event routing manager_containerized network function manager (EM_Cnfm) interface.

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

9. The method as claimed in claim 7, wherein upon receiving the at least one orchestration request via the interface, processing, by the CNFM (115), the at least one received orchestration request to generate at least one information corresponding to allocation of resources for virtualization or managing underlying infrastructure resources required for virtualization.

10. The method as claimed in claim 9, wherein receiving, by the VIM (120), the at least one information from the CNFM (115) via the ERM (130); and
analyzing, by the VIM (120), the received at least one information to manage at least one underlying infrastructure resource for virtualization.