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 relates generally to the field of telecommunication systems. More particularly, the present disclosure relates to a system and a method for routing event requests in a network. An event routing manager_operations, administration and maintenance (EM_OA) interface for management and orchestration (MANO) framework.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression “Virtualization” used hereinafter in the specification refers to a technology that allows to create and manage virtual versions of physical resources, such as servers, storage devices, and networks.
[0005] The expression “Virtualized infrastructure” used hereinafter in the specification refers to the abstraction of physical computing resources into virtual instances that can be managed and utilized more flexibly. This abstraction allows for the efficient allocation, management, and scaling of 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., 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 a software implementation of a network function that runs on an NFV environment and can be deployed on a virtual machine.
[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.
[0012] The expression ‘Container network function’ (CNF) manager’ used hereinafter in the specification orchestrates and optimizes network functions deployed within containerized environments.
[0013] The expression ‘Virtualized Infrastructure Manager (VIM)’ used hereinafter in the specification refers to a component of the MANO framework responsible for controlling and managing the NFV infrastructure computation, storage, and resources (i.e., network resources).
[0014] The expression ‘NFV Infrastructure (NFVI)’ used hereinafter in the specification refers to a collection of hardware and software components that build an environment in which VNFs are deployed, managed, and executed.
[0015] The expression ‘NFV orchestrator (NFVO)’ used hereinafter in the specification refers to a component within the NFV architecture responsible for the end-to-end orchestration and management of the VNFs and their associated resources.
[0016] The expression ‘Container’ used hereinafter in the specification refers to an executable unit of software in which application code is packaged along with its libraries and dependencies.
[0017] The expression ‘Containerized Applications’ used hereinafter in the specification refers to applications that run in isolated packages of code (containers).
[0018] The expression ‘Orchestration Management’ used hereinafter in the specification refers to a process of managing and coordinating the deployment and operation of multiple services or applications in a distributed environment.
[0019] The expression ‘Event’ used hereinafter in the specification refers to a specific action that can trigger a network element 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 “Operations, Administration, and Maintenance (OAM)” refer to the processes and activities required to manage and sustain Information Technology (IT) systems and services effectively.
[0022] The expression “Fault, Configuration, Accounting, Performance, and Security (FCAPS)” a framework used in network management to address the comprehensive needs of managing and maintaining network systems.
[0023] The expression “Software-Defined Networking (SDN)” refers to a network architecture approach that separates the network control plane from the data plane to enable more flexible, programmable, and centralized network management.
[0024] These definitions are in addition to those expressed in the art.
BACKGROUND
[0025] 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.
[0026] In a distributed system, different services need to be manually configured and updated whenever changes occur, such as the addition or removal of services. This leads to inefficiencies and increases administrative overhead due to the lack of automation. Further, managing service endpoints manually becomes challenging. During the scaling of services horizontally or the addition of new services in the system, the configuration of every client that interacts with these services is required to be modified. The lack of scalability can hamper the growth and flexibility of the system. Currently, clients are required to have prior knowledge of the service’s location or internet protocol (IP) address. When the services change their location or IP, clients are unable to find or connect to the services, resulting in service availability problems. Services need to use custom and ad hoc methods for discovering and communicating with each other. This reduces the potential for the reuse and integration of services.
[0027] There is, therefore, a need in the art to provide a method and a system that can overcome the shortcomings of the existing prior arts.
SUMMARY
[0028] In an exemplary embodiment, a method for routing a plurality of event requests between a plurality of components of a management and orchestration (MANO) by an event routing manager (ERM), the method includes receiving at least one event request from at least one component of the MANO via an interface, analyzing the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request, upon determining the at least one received event request is the routing request, extracting an event name corresponding to the at least one determined routing request, and based on the determined event name, routing the at least one received event request to at least one network service of at least one corresponding component of the MANO, where upon determining the at least one received event request is the broadcast request, transmitting the at least one determined broadcast request to the plurality of components of the MANO.
[0029] In some embodiments, the plurality of components of the MANO comprises of an operation, administration and maintenance (OAM), a network functions virtualization orchestrator (NFVO), a container network function (CNF) manager (CNFM) and a virtualized infrastructure manager (VIM). The interface is an event routing manager_ operation, administration and maintenance (EM_OA) interface.
[0030] In some embodiments, the method further comprises extracting a set of information from the at least one received event request. The set of information includes service details, instance details, context details. In some embodiments, the method further comprises determining whether the set of extracted information is available in a database and upon determining the set of extracted information is not available in the database, adding the extracted information in the database. Upon determining the set of extracted information is available in the database, updating the extracted information in the database.
[0031] In some embodiments, the broadcast request comprises at least one of a registration request, a deregistration request, a high availability request, wherein the routing request comprises a fault, configuration, accounting, performance, and security (FCAPS) request.
[0032] In some embodiments, the method further comprises receiving, by the ERM, the broadcast request from the OAM and receiving, by the ERM, the routing request from at least one of the NFVO, the CNFM, the VIM.
[0033] In some embodiments, the method further comprises receiving, by the ERM (130), at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO. The received at least one event response comprises a success status and a failure status of the at least one routed event request.
[0034] In another exemplary embodiment, a system for routing a plurality of event requests between a plurality of components of a management and orchestration (MANO), the system includes an event routing manager (ERM), the ERM includes a receiving unit configured to receive at least one event request from at least one component of the MANO via an interface, an analyzing unit configured to analyze the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request, upon determining the at least one received event request is the routing request, an executing unit is configured to extract an event name corresponding to the at least one determined routing request, based on the determined event name, the execution unit is configured to route the at least one received event request to at least one network service of at least one corresponding component of the MANO, where upon determining the at least one received event request is the broadcast request, the execution unit configured to transmit the at least one determined broadcast request to the plurality of components of the MANO..
[0035] In some embodiments, the execution unit configured to extract a set of information from the at least one received event request. The set of information includes service details, instance details, context details.
[0036] In some embodiments, the analyzing unit configured to determine whether the set of extracted information is available in a database. Upon determining the set of extracted information is not available in the database, the execution unit is configured to add the extracted information in the database. Upon determining the set of extracted information is available in the database, the execution unit is configured to update the extracted information in the database.
[0037] In some embodiments, the receiving unit is configured to receive the broadcast request from the OAM. The receiving unit is configured to receive the routing request from at least one of the NFVO, the CNFM, the VIM.
[0038] In some embodiments, the receiving unit is configured to receive at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO. The received at least one event response comprises a success status and a failure status of the at least one routed event request.
[0039] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVES OF THE PRESENT DISCLOSURE
[0040] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0041] An objective of the present disclosure is to provide a system and a method for providing an event routing manager_operations, administration and maintenance (EM_OA) interface in order to facilitate communication between an event routing manager (ERM) and operations, administration, and maintenance (OAM).
[0042] Another objective of the present disclosure is to provide a system and a method that enable an ERM to make informed routing decisions based on an event name that is obtained from broadcasts related to various services and direct requests to specific endpoints on a designated network functions virtualization orchestrator_event routing manager (Or_EM) interface, an event routing manager_container network function manager (EM_Cnfm) interface, and an event routing manager_virtualized infrastructure manager (EM_Vi) interface.
[0043] Yet another objective of the present disclosure is to enable an event routing manager (ERM) to utilize an EM_OA interface to transmit fault, configuration, accounting, performance, and security (FCAPS) data to a central monitoring system.
[0044] Yet another objective of the present disclosure is to design services that can be independently deployed and scaled (for example, services can be created, updated, or removed frequently based on changing requirements).
[0045] Yet another objective of the present disclosure is to dynamically discover and connect the services to each other, regardless of their locations or internet protocol (IP) addresses.
[0046] Yet another objective of the present disclosure is to automatically detect failed services and facilitate rerouting of requests to alternative healthy instances or services.
[0047] 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.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0048] 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.
[0049] FIG. 1A illustrates an exemplary network architecture for implementing a system for routing an event request between a plurality of components of a management and orchestration (MANO), in accordance with an embodiment of the present disclosure.
[0050] FIG. 1B illustrates an exemplary system architecture for facilitating communication between an event routing manager (ERM), an operations, administration, and maintenance (OAM), a network functions virtualization orchestrator (NFVO), a Container Network Function Manager (CNFM), and a virtualized infrastructure manager (VIM) of the MANO, in accordance with an embodiment of the present disclosure.
[0051] FIG. 1C illustrates an exemplary block diagram of the system for routing the event request between the plurality of components of the MANO, in accordance with an embodiment of the present disclosure.
[0052] FIG. 2 illustrates another exemplary system architecture for managing details of services and instances in the ERM, in accordance with an embodiment of the present disclosure.
[0053] FIG. 3 illustrates an exemplary representation of the MANO framework architecture, in accordance with an embodiment of the present disclosure.
[0054] FIG. 4 illustrates an exemplary flow diagram for a registration of service request and routing of the event request between NFVO, CNFM, VIM, ERM, and OAM, in accordance with an embodiment of the present disclosure.
[0055] FIG. 5 illustrates an exemplary flow diagram for routing of the event requests, in accordance with an embodiment of the present disclosure.
[0056] FIG. 6 illustrates an exemplary flow diagram of a method for routing a plurality of event requests between the plurality of components of the MANO by the ERM, in accordance with an embodiment of the present disclosure.
[0057] FIG. 7 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented.
[0058] The foregoing shall be more apparent from the following 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
100B – Network Architecture
105 - Network Functions Virtualization Orchestrator (NFVO)
110 - Container Network Function Manager (CNFM)
120 - Virtualized Infrastructure Manager (VIM)
125 - Operations Administration and Maintenance (OAM)
130 – Event Routing Manager (ERM)
100C - Block Diagram
111 – Processor(s)
112 - Memory
114 – Plurality of Interfaces
116 – Processing Unit
124 –Database
200 – System Architecture
206 - Active service and instances
208-(1-6) - Plurality of services
208-1 - Service A
208-2 - Service B
208-3 - Service C
208-4 - Service D (Instance 1)
208-5 - Service D (Instance 2)
208-6 - Service F (Instance 1)
300 – Management and Orchestration (MANO) architecture
400 - Flow Diagram
500 - Flow Diagram
600 - Flow Diagram
700 - Computer system
710 - External Storage Device
720 - Bus
730 - Main Memory
740 - Read Only Memory
750 - Mass Storage Device
760 - Communication Port
770 - Processor
DETAILED DESCRIPTION
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] In a distributed system, different services need to be manually configured and updated whenever changes occur, such as the addition or removal of services. This leads to inefficiencies and increases administrative overhead due to the lack of automation. Furthermore, managing service endpoints manually becomes challenging. During the scaling of services horizontally or the addition of new services in the system, the configuration of every client that interacts with these services is required to be modified. This lack of scalability can hamper the growth and flexibility of the system. Currently, clients are required to have prior knowledge of the service’s location or internet protocol (IP) address. If services change their location or IP, clients are unable to find or connect to the services, resulting in service availability problems. Services need to use custom and ad hoc methods for discovering and communicating with each other. This reduces the potential for the reuse and integration of services.
[0068] Accordingly, there is a need for systems and methods for designing services that can be independently deployed and scaled.
[0069] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a system and a method for an event routing manager_operation, administration and maintenance (EM_OA interface) that serves as a central hub for managing event routing managers (ERMs). ERMs use the EM_OA interface to register, deregister, or re-register themselves. According to aspects of the present disclosure, a connection (for example, WebSocket connection) may be established between a central server and an EM instance after the successful registration of an ERM to an operations, administration, and maintenance (OAM). The OAM may be configured to function as a central server. The ERM may receive broadcasts related to various services from the OAM. The broadcast information enables the ERM to make informed routing decisions based on the event name, and to direct requests to specific endpoints on the designated network functions virtualization orchestrator_event routing manager (Or_EM) interface, event routing manager_container network function manager (EM_Cnfm) interface, and event routing manager_ virtualized infrastructure manager (EM_Vi) interface. The ERM also utilizes the EM_OA interface to transmit fault, configuration, accounting, performance, and security (FCAPS) data to a central monitoring system.
[0070] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs. 1A-7.
[0071] FIG. 1A illustrates an exemplary network architecture (100A) for implementing a system (108) for routing an event request between a plurality of components of a management and orchestration (MANO), in accordance with an embodiment of the present disclosure.
[0072] 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.
[0073] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE (104) may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., 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 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.
[0074] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, 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.
[0075] 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.
[0076] 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.
[0077] 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. The system (108) may be configured for routing an event request between a plurality of components of a management and orchestration (MANO).
[0078] The system (108) includes an event routing manager (ERM). The ERM receives broadcasts related to various services from an operations, administration, and maintenance (OAM). The broadcast information enables the ERM to make informed routing decisions based on the event name, and to direct requests to specific endpoints on the designated Or_EM interface, EM_Cnfm interface, and EM_Vi interface. The ERM directs a plurality of events from a plurality of event sources to appropriate event consumers or services. The ERM also utilizes the EM_OA interface to transmit fault, configuration, accounting, performance, and security (FCAPS) data to a central monitoring system. The ERM also utilizes the EM_OA interface for dynamically discovering and connecting services with each other, regardless of their locations or internet protocol (IP) addresses.
[0079] 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).
[0080] FIG. 1B illustrates an exemplary system architecture (100B) for facilitating communication between the ERM (130), the OAM (115), the NFVO (105), the CNFM (110), and the VIM (120) of the MANO (125), in accordance with an embodiment of the present disclosure.
[0081] In an implementation, the MANO (125) may primarily include three essential components: the NFVO (105), the CNFM (110), and the VIM (120). The NFVO (105) may perform orchestrating services (e.g., service design, deployment, etc.), oversee the deployment (e.g., performance monitoring, fault management, etc.), and manage resources (e.g., resource allocation, capacity planning, etc.) efficiently. The CNFM (110) may be responsible for overseeing and controlling container network functions (CNFs) (e.g., deployment and configuration of CNFs, scaling, removal of CNFs), ensuring their proper functioning (e.g., service provisioning, maintaining service registry, performance monitoring, traffic management, etc.). The VIM (120) may manage the underlying infrastructure resources required for virtualization (e.g., resource allocation, resource scaling, load balancing, resource scheduling, storage management, network provisioning, network configuration, traffic monitoring, security, etc.). The NFVO (105), the CNFM (110), and the VIM (120) may collaborate closely to facilitate the flexible and efficient deployment and management of virtualized services.
[0082] Further, in an aspect, multiple network services may be associated with each of the NFVO (105), the CNFM (110), and the VIM (120). The NFVO (105), the CNFM (110), and the VIM (120) may communicate with one another using specific event names. The ERM (130) may be responsible for directing incoming requests based on the event name to the appropriate network service, employing designated interfaces for this purpose. As a result, the overall functionality and effectiveness of the MANO (125) is enhanced through the event-driven communication framework.
[0083] The ERM (130) may communicate with the NFVO (105), the OAM (115), the CNFM (110), and the VIM (120). The ERM (130) may communicate with the OAM (115) via the EM_OA interface.
[0084] In an aspect, the EM_OA interface is used to facilitate communication between the ERM (130) and the OAM (115). The ERM (130) receives broadcasts related to various network services associated with the components of the MANO (125). The ERM (130) uses information obtained through the broadcasts (e.g., names, types, identifiers, status of network services corresponding to the components of the MANO (125)) to make informed routing decisions and direct incoming event requests to specific network services of designated component of the MANO (125).
[0085] The ERM (130) may communicate with the NFVO (105) via the Or_EM interface. In an aspect, the Or_EM interface is used to send a plurality of event requests between network services of the NFVO (105) to the CNFM (110), and the NFVO (105) to the VIM (120) based on event names.
[0086] The ERM (130) may communicate with the CNFM (110) via the EM_Cnfm interface. In an aspect, the EM_Cnfm interface is used to send a plurality of event requests between network services of the NFVO (105) to the CNFM (110) and the CNFM (110) to the VIM (120) based on event names.
[0087] The ERM (130) may communicate with the VIM (120) via the EM_Vi interface. In an aspect, EM_Vi interface is used to send a plurality of event requests between network services of the CNFM (110) to VIM (120) and the VIM (120) to the NFVO (105) based on event names.
[0088] Furthermore, the EM_OA interface may play a crucial role in facilitating communication between the ERM (130) and OAM (115). The NFVO (105), the CNFM (110), and the VIM (120) may communicate with each other through the ERM (130). The EM_OA interface may serve as a central hub for managing a plurality of event routing managers (ERMs). The ERMs may use the EM_OA interface to register, deregister, or re-register themselves.
[0089] In an implementation, the OAM (115) may function as a central server. The OAM (115) may receive information of IP, port, path, component broadcast context, and subscribe component type for the ERMs.
[0090] In an aspect of the present disclosure, a plurality of ERM instances may register themself to the OAM (115). The OAM (115) may be configured to manage all the ERM instances to perform smooth interactions with other services. The OAM (115) may maintain a list of all active and inactive ERM instances.
[0091] In an aspect, the OAM (115) broadcasts the list of all active and inactive ERM instances to the network services of the components (i.e., the NFVO (105), the VIM (120), the CNFM (110)) of the MANO (125). The components (i.e., the NFVO (105), the VIM (120), the CNFM (110)) of the MANO (125) send the event request to one active instance of ERM based on the list.
[0092] After successful registration of the ERM instances to the OAM (115), a connection (for example, WebSocket connection) may be established between the OAM (115) and the ERM instance through the EM_OA interface. The OAM (115) then broadcasts registration information to subscribed network service instances. The OAM (115) also facilitates data broadcasting, enabling network services to circulate data among their instances, thus managing high availability using the data broadcast.
[0093] In an implementation, FCAPS requests are sent by the one of components of the MANO (125) to the ERM (130) over the EM_OA interface. The ERM (130) sends the FCAPS requests to respective network service instances by determining the event name corresponding to the FCAPS requests. The network service instances may send FCAPS responses to the ERM (130). _. The ERM may consolidate all the network service FCAPS responses and send the consolidated response to an element management system (EMS).
[0094] In an implementation, the EM_OA interface may work in a high availability mode during fault tolerance for any event failure. For example, the OAM (115) may continuously monitor the health of active ERM instances through Hypertext Transfer Protocol (HTTP) requests. The OAM (115) also maintains the list of all active and inactive ERM instances. If one of the plurality ERM instances goes offline/down due to some issue, the OAM (115) may deregister that ERM instance and add the details of that instance to the inactive instances list of ERM. The OAM (115) may then broadcast these details to the load balancer and other services requiring EM information. The EM_OA interface is used to get all active service details which can be used to route requests to the appropriate active ERM instance.
[0095] In an aspect, the OAM (115) may maintain a list of all active and inactive ERM instances using the EM_OA interface. The OAM (115) may broadcast the list to all other network services so that other network services can send any event/request to only active instances of ERM (130).
[0096] Further, the ERM (130) is configured to broadcast flavor details (for example, the use of a particular active ERM instance while serving an incoming event/request) to other ERM instances using the EM_OA interface between the OAM (115) and the ERM (130). In an aspect, on selecting one of active ERM instance, the ERM broadcasts flavor details corresponding to the one selected ERM instance to other ERM instances using the EM_OA interface. The flavor details include, but are not limited to, instance name, instance identifier (ID), resource details, storage details, network configuration details, performance metrics, security details.
[0097] The ERM (130) may get instance details for other network services from the OAM (115) broadcast. The ERM (130) may cache the other network service load balancer details to route the request to a specific instance. In this way, the EM_OA interface is configured to perform async event-based implementation to utilize the EM_OA interface efficiently.
[0098] In an aspect of the present disclosure, the ERM (130) may maintain a mapping for the service name and the endpoint details (for example, fully qualified domain name (FQDN)) in a memory data structure. The ERM (130) may configure the mapping at start time and mapping can be updated at run time. Further, when the ERM (130) gets the details, the ERM (130) stores the details to map the details to all the service names and their instance details. The ERM (130) may keep the context details for the service so that the ERM (130) can accept the request from the sender service and route the request to the appropriate handler-to-receiver service.
[0099] In an aspect, network services corresponding to the NFVO (105), the CNFM (110), the VIM (120) are deployed and scaled. In an aspect, the network services corresponding to the NFVO (105) includes, but are not limited to, service orchestration network services, resources management network services, monitoring and analytics network services, policy management network services. The network services corresponding to the CNFM (110) includes, but are not limited to, virtualized network function (VNF) management network services, network service management network services, fault management network services, configuration management network services. The network services corresponding to the VIM (120) includes, but are not limited to, compute resource management network services, storage management network services, network management network services, resource monitoring network services. The network services corresponding to the NFVO (105), the CNFM (110), and the VIM (120) are created, updated, or removed frequently based on requirements. The network services are discovered and connected with each other using the interfaces between the ERM (130), the NFVO (105), the CNFM (110), and the VIM (120), regardless of their locations or IP addresses. In an example, the ERM (130) receives a request for a new container creation from the NFVO (105) for the CNFM (110). The ERM (130) analyzes the request to confirm that it is meant for the CNFM (110) and then routes it to a specific instance of the container creation network service within the CNFM (110). In this way, the network services are discovered and connected by the ERM (130) using the interfaces between the ERM (130), the NFVO (105), the CNFM (110), and the VIM (120), regardless of their locations or IP addresses.
[00100] In an aspect, the EM_OA interface supports instance management, alarm management and counter management.
[00101] In instance management, the OAM (115) provides instance details for the network services of components of the MANO (125) to the ERM via the EM_OA interface. For example, a service orchestration network service within the NFVO (105) has 100 instances, each capable of handling 100 requests within 10 minutes. However, if 1,000 requests are received within the same 10 minutes, the ERM evenly distributes these requests among the 100 available instances. In this way, the instance management is efficiently performed via the EM_OA interface.
[00102] Alarm management is used to maintain the health and performance of components of the MANO (125). It involves detecting, reporting, and responding to issues or faults that could impact network services. For example, the NFVO (105) monitors overall service orchestration and network service performance. The NFVO (105) may receive alarms from lower-layer components (e.g., the VIM (120) and the CNFM (110)) about issues affecting the network functions or services it manages. If the NFVO (105) detects that multiple Virtualized Network Functions (VNFs) are experiencing issues, the NFVO (105) analyzes whether these issues are indicative of a larger problem affecting the entire service. The NFVO (105) escalate alarms to higher-level management systems (e.g., the OAM (115) or the ERM (130) or the EMS), if the issue cannot be resolved at the NFVO level.
[00103] In counter management, a plurality of counters is used for monitoring and maintaining the performance and health of resources of the MANO (125). In an example, the counter management in the VIM (120) involves counters for tracking and managing performance metrics of resources (e.g., CPU usage, memory, disk input /output (I/O), network traffic) to ensure efficient operation and resource utilization.
[00104] Although FIG. 1B shows exemplary components of the system architecture (100B), in other embodiments, the system 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 system architecture (100B) may perform functions described as being performed by one or more other components of the system architecture (100B).
[00105] FIG. 1C illustrates an exemplary block diagram (100C) of the system (108) for routing the event request between the plurality of components of the MANO (125), in accordance with an embodiment of the present disclosure.
[00106] 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). 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.
[00107] 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 (124).
[00108] The system (108) includes the ERM (130) and the database (124). The ERM (130) includes a receiving unit (116), an analyzing unit (118), and an execution unit (122). The receiving unit (116) is configured to receive at least one event request from at least one component of the MANO (125) via an interface (i.e., EM_OA interface). In an aspect, the components of the MANO (125) include the OAM (115), the NFVO (105), the CNFM (110), and the VIM (120).
[00109] The analyzing unit (118) is configured to analyze the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request. In an aspect, the broadcast request comprises at least one of a registration request, a deregistration request, a high availability request, wherein the routing request comprises a fault, configuration, accounting, performance, and security (FCAPS) request. In an aspect, the receiving unit (116) is configured to receive the broadcast request from the OAM (115) and the routing request from at least one of the NFVO (105), the CNFM (110), the VIM (120). Upon determining the at least one received event request is the routing request, the execution unit (122) is configured to extract an event name corresponding to the at least one determined routing request. In an aspect, the execution unit (122) configured to extract a set of information from the at least one received event request. The set of information includes service details, instance details, context details. In an aspect, the service details include service type, service name, service status, etc. the instance details include instance name, instance software version, instance configurations (e.g., CPU, memory, storage), instance state, etc. The context details include service type, service operations, service configuration, operational state of service, performance metrics, security details, software versions, etc.
[00110] Further, the analyzing unit (118) is configured to determine whether the set of extracted information is available in the database (124). Upon determining the set of extracted information is not available in the database (124), the execution unit (122) is configured to add the extracted information in the database (124). Upon determining the set of extracted information is available in the database (124), the execution unit (122) is configured to update the extracted information in the database (124).
[00111] Based on the determined event name, the execution unit (122) is configured to route the at least one received event request to at least one network service of at least one corresponding component of the MANO (125).
[00112] Upon determining the at least one received event request is the broadcast request, the execution unit (122) configured to transmit the at least one determined broadcast request to the plurality of components of the MANO (125).
[00113] In an aspect, the ERM receives a new container creation request. The ERM (130) analyzes the received event request (e.g., new container creation request) to determine whether the received event request is a broadcast request or a routing request. Based on the analysis, the ERM determines the received event request (e.g., new container creation request) is a routing request. The ERM extracts an event name (e.g., container creation) from the determined routing request. The ERM (130) determines the network service (e.g., container creation network service of the CNFM (110)) of one of component of the MANO (125) based on event name. The ERM (130) routes the determined routing request to the determined network service of one of component of the MANO (125) (e.g., container creation network service of the CNFM (110)).
[00114] The receiving unit (116) is configured to receive at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO (125). In an aspect, the network service (e.g., container creation network service of the CNFM (110)) sends the event response after processing the event request (e.g., new container creation request). The event response indicates a status of the event request. The status of the event request comprises at least one of a success status and a failure status. If the processing of the event request is successful, the network service (e.g., container creation network service of the CNFM (110)) sends the success response to the ERM (130). In an aspect, if the processing of the event request is unsuccessful, the network service (e.g., container creation network service of the CNFM (110)) sends the failure response to the ERM (130).
[00115] In some embodiments, the details stored by the ERM includes at least one of a name of the at least one network service and at least one instance associated with the at least one network service.
[00116] In an embodiment, the system (108) includes the database (124) 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 (124) 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 (124) may be implemented in the ERM (130). In an aspect, the database (124) is configured to store program instructions and data corresponding to a plurality of event requests and broadcast requests. The database (124) is configured to store details (e.g., service details, instance details, context details) corresponding to the components of the MANO (125) (i.e., the NFVO (105), the CNFM (110), the VIM (120)). The program instructions include a program that implements a method for broadcasting and routing of a plurality of service requests in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification.
[00117] 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).
[00118] FIG. 2 illustrates another exemplary system architecture (200) for managing details of services and instances in the ERM (130), in accordance with an embodiment of the present disclosure.
[00119] The ERM (130) is configured to store details of active services and instances (206). The ERM (130) may include a memory to store details of active services and instances (206). A plurality of services (208-(1-6)) may arrive at the ERM (130). A plurality of instances may be associated with the plurality of services (208-(1-6)). For example, the plurality of services may include service A (208-1), service B (208-2), service C (208-3), service D – Instance 1 (208-4), service D – Instance 2 (208-5), and service F (208-6). As described above, the plurality of instances may include instance 1 and instance 2 associated with service D (208-4, 208-5), and an instance 1 associated with service F (208-6). Further, the ERM (130) may be configured to store data in the database (124).
[00120] In an implementation, the service details and the instance details of the services A-F and corresponding instances are added in an active list of the ERMs.
[00121] FIG. 3 illustrates an exemplary representation of the MANO framework architecture (300), in accordance with embodiments of the present disclosure.
[00122] As depicted in FIG. 3, the MANO framework architecture (300) may comprise several interconnected modules that work together to enable efficient resource allocation and management. The interconnected modules may include a user interface layer (302), NFV and software-defined networking (SDN) design functions (304), platform foundation services (306), platform core services (308), a platform operation, administration, and maintenance manager (310), and platform resource adapters and utilities (312).
[00123] The user interface layer (302) may serve as a primary point of interaction for the network operators and the network administrators. Through the user interface layer (302), 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.
[00124] The NFV and SDN design functions (304) may work in conjunction with the platform core services (308) 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 (304) 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 (304) 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 (304) 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.
[00125] The platform foundation services (306) may support an asynchronous event-based processing model implemented by the ERM (130), enabling concurrent handling of multiple service requests. The platform foundation services (306) may include network services elastic load balancer, identity & access manager, command line interface (CLI), central logging manager, and the ERM (130). 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.
[00126] The platform core services (308) are central to the processing and fulfillment of the service requests (i.e., at least one service request). The platform core services (308) 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 (308) 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.
[00127] The platform operation, administration, and maintenance manager (310) may oversee operational aspects of the MANO framework architecture (300). The platform operation, administration, and maintenance manager (310) 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.
[00128] The platform resource adapters and utilities (312) 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 (312) may work closely with the platform core services (308) 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 (312) 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.
[00129] 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 (302), utilize the NFV and SDN design functions (304) for the service requests analysis, leverage the platform core services (308) for the service requests fulfillment and use the platform resource adapters and utilities (312) for actual resources allocation for each of the service requests. The platform operations, administration and maintenance manager (310) 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.
[00130] FIG. 4 illustrates an exemplary flow diagram (400) for a registration of a service request and routing of an event request between the NFVO (105), the CNFM (110), the VIM (120), the ERM (130), and the OAM (115), in accordance with an embodiment of the present disclosure.
[00131] At step (412) of the flow diagram (400), the NFVO (105) may send a registration request to the OAM (115). In an aspect, the NFVO (105) may inform the OAM (115) about operational status of the NFVO (105) through the registration request and may also request to be managed or monitored by the OAM (115).
[00132] At step (414) of the flow diagram (400), the OAM (115) may send a broadcast request to the ERM (130). In an aspect, the OAM (115) may send the broadcast request to the ERM (130) to inform about the availability and details of the NFVO (105).
[00133] At step (416) of the flow diagram (400), the ERM (130) may store the broadcast request in a cache. In an aspect, the ERM (130) may store the information about the availability of the NFVO (105).
[00134] At step (418) of the flow diagram (400), the CNFM (110) may send a registration request to the OAM (115). In an aspect, the CNFM (110) may inform the OAM (115) about availability and details (e.g., identifier, operational status, name, type, etc.) of the CNFM (110) through the registration request and may also request to be managed or monitored by the OAM (115).
[00135] At step (420) of the flow diagram (400), the OAM (115) may send a broadcast request to the ERM (130). In an aspect, the OAM (115) may send the broadcast request to the ERM (130) to inform about the availability and details of the CNFM (110).
[00136] At step (422) of the flow diagram (400), the ERM (130) may store the broadcast request in a cache. In an aspect, the ERM (130) may store the information about the availability of the CNFM (110).
[00137] At step (424) of the flow diagram (400), the VIM (120) may send a registration request to the OAM (115). In an aspect, the VIM (120) may inform the OAM (115) about availability and details (e.g., identifier, operational status, name, type, etc.) of the VIM (120) through the registration request and may also request to be managed or monitored by the OAM (115).
[00138] At step (426) of the flow diagram (400), the OAM (115) may send a broadcast request to the ERM (130). In an aspect, the OAM (115) may send the broadcast request to the ERM (130) to inform about the availability and details of the VIM (120).
[00139] At step (428) of the flow diagram (400), the ERM (130) may store the broadcast request in a cache. In an aspect, the ERM (130) may store the information about the availability of the VIM (120).
[00140] At step (430) of the flow diagram (400), the NFVO (105) may send an event request to the ERM (130). In an aspect, the NFVO (105) may send the event request (e.g., request for scaling of the network functions (e.g., access mobility and management function (AMF), a session management function (SMF), a policy control function (PCF), etc.)) to the ERM (130). The event request may comprise, but is not limited to, event details such as event type (i.e., NF scaling), event identifier (ID), NF ID, scaling action (e.g., scale-in), scaling details (e.g., number of instances needs to be added, number of new resources required.
[00141] At step (432) of the flow diagram (400), the ERM (130) may send the received event request to the CNFM (110). In an aspect, the ERM (130) processes the received event request to validate the received event request. The ERM (130) routes the received event request to the CNFM (110) based on the details of the CNFM (i.e., CNFM ID) provided in the request. The ERM (130) provided the event details to the CNFM (110).
[00142] At step (434) of the flow diagram (400), the CNFM (110) may send an event response to the ERM (130). In an aspect, the CNFM (110) sends the event response to the ERM (130) to confirm receipt and processing of the event request. The CNFM (110) performs the scaling in operation (e.g., increasing resources available for the CNF to handle increased demand or load). In an example, when demand is high, actions performed such as increasing CPU = from 6 cores to 8 cores, Memory = 16 GB to 32 GB, Storage = 100GB to 200 GB, additional Instances =2.
[00143] At step (436) of the flow diagram (400), the ERM (130) may send the event response to the NFVO (105). In an aspect, on receiving the event response from the CNFM (110), the ERM (130) sends the received event response to the NFVO (105). On receiving the event response, the CNFM (110) ensures that the CNFM can handle increased load or demand effectively by adding and configuring additional resources.
[00144] FIG. 5 illustrates an exemplary flow diagram (500) for routing of the event requests, in accordance with an embodiment of the present disclosure.
[00145] At step (502) of the flow diagram (500), the ERM (130) may accept a request from a sender (e.g., publisher). In an aspect, the request is at least one of a broadcast request or a routing request. In an aspect, the sender can be one of components (e.g., NFVO (105), CNFM (110), VIM (120)) of the MANO (125). In an example, the request such as provisioning of new container creation to the CNFM (110) by the NFVO (105). The NFVO (105) may send the request (i.e., the new container creation request provisioning to the CNFM (110)).
[00146] At step (504) of the flow diagram (500), the ERM (130) may check whether the accepted request is a broadcast request or not. If the accepted request is not the broadcast request, the flow diagram (500) proceeds to step (506), and if the accepted request is the broadcast request, the flow diagram (500) proceeds to step (508). In an aspect, the broadcast request involves sending registration details corresponding to the components (e.g., one of the components (e.g., NFVO (105), VIM (120), CNFM (110)) of MANO (125)) to the ERM (130). For example, the broadcast request includes health status, availability, identifier, function types, security alerts, etc.
[00147] At step (506) of the flow diagram (500), if the accepted request is not the broadcast request, then the ERM (130) may check whether the accepted request is a routing request or not. If the accepted request is a routing request, the flow diagram (500) may proceed to step (526). In an aspect, the routing request involves sending an event from the publisher (e.g., the NFVO (105)) to the subscriber (e.g., CNFM (110)) via the ERM (130). For example, the routing requests include virtual machine (VM) resource utilization alert, VM state change (e.g., start up or shut down), security incident detection, provisioning of firewall service, etc.
[00148] At step (508) of the flow diagram (500), if the accepted request is the broadcast request, then the ERM (130) may check whether the service details of network service are available or not in the database (124). If the service details of the network service are available in the database (124), the flow diagram (500) proceeds to step (510), and if the service details of the network service are not available in the database (124), the flow diagram (500) proceeds to step (522). In an example, the broadcast request is VM health status update. The service details include service name (e.g., autoscaling, notification), service type (e.g., monitoring, scaling, logging), service endpoints, etc.
[00149] At step (510) of the flow diagram (500), if the service details of the network service corresponding to the accepted request are not available, then the ERM (130) may add the service details in the memory. On detecting that the service details of the network service are not available, the ERM (130) adds the service details for the details in the memory. Then, the flow diagram (500) proceeds to step (512).
[00150] At step (512) of the flow diagram (500), if the service details of network service for the accepted request are available, then the ERM (130) may check whether instance details of the instances of the network service are available or not in the database (124). If the instance details of the instances of the network service are available in the database (124), the flow diagram (500) proceeds to step (516), and if the instance details of the instances of the network service are not available in the database (124), the flow diagram (500) proceeds to step (514). In an example, the instance details include instance ID, instance name, instance type, performance metrics, operational status of instances (e.g., running, stopped), location, etc.
[00151] At step (514) of the flow diagram (500), if the instance details of the instance of the network service are not available, then the ERM (130) may add the instance details. On detecting that the instance details of the instance of the network service are not available, then the ERM (130) adds the instance details for the instance of the network service. Then, the flow diagram (500) proceeds to the step (518).
[00152] At step (516) of the flow diagram (500), if the instance details of the instance of the network service are available in the database, then the ERM (130) may update the details of the instance for the network service. In an aspect, on detecting that the instance details of the instance of the network service are available in the database (124), updating the details of the instance includes state of instance, instance type, performance metrics (e.g., CPU usages, CPU load, CPU core utilization, memory usage, memory utilization, etc.).
[00153] At step (518) of the flow diagram (500), after updating details of the network service instance, the ERM (130) may check whether context details of the network service are available or not in the database (124). If the context details of the network service are available in the database (124), the flow diagram (500) proceeds to step (522), and if the context details of the request are not available in the database (124), the flow diagram (500) proceeds to step (520). In an aspect, the context details of the network services refer to the characteristics that define the environment and framework within which network services operate. The context details of the network service include, but is not limited to, network service type, event type, timestamp, event description, etc.
[00154] At step (520) of the flow diagram (500), if context details of the network service are not available, then the ERM (130) may preconfigure the context details of the network service. In an aspect, preconfiguring the context details includes establishing a predefined structure and set of attributes that capture essential information about the events before the events are sent or processed. The preconfiguring of the context details includes event type, timestamp, event identifier (ID), event description, performance metrics, etc.
[00155] At step (522) of the flow diagram (500), if context details of the network service are available, then the ERM (130) may update the context details of the network service. In an example, updating the context details of the request (e.g., high CPU usage alert) include event type (e.g., High CPU Usage), event description (e.g., CPU usage exceeded the threshold of 90%), recommendation (e.g., Increased CPU and memory resources for affected VMs).
[00156] At step (524) of the flow diagram (500), the ERM (130) may receive context details update request. In an aspect, the context details update request include event identifier (ID), entity ID, entity name, current CPU usage, previous CPU usage, resource allocation, memory size, CPU cores, etc.
[00157] After receiving the context details update request, the ERM (130) may repeat the steps (518), (520), and (522).
[00158] At step (526) of the flow diagram (500), if the accepted request is a routing request, then the ERM (130) may check whether the service instance details are available in the memory or not.
[00159] At step (527) of the flow diagram (500), the ERM (130) checks whether the service instance details are available. If the service instance details are available in the memory, the flow diagram (500) proceeds to step (530), and if the service instance details are not available in the memory, the flow diagram (500) proceeds to step (528).
[00160] At step (528) of the flow diagram (500), if the service instance details are not available in the memory, the ERM (130) may send an error to the publisher. On detecting that the service instance details are not available in the memory, the ERM (130) sends the error (e.g., SERVICE_INSTANCE Details_NOT_FOUND) to the publisher.
[00161] At step (530) of the flow diagram (500), if the service instance details are available in the memory, then the ERM (130) may check whether there is more than one instance of the service. If there is more than one instance of the service, the flow diagram (500) proceeds to step (534), and if more than one instance of the service is not available, the flow diagram (500) proceeds to step (532). In an aspect, a plurality of network services of the components of the MANO (125) includes network services of container network function manager (CNFM) (110), virtualized infrastructure manager (VIM) (120), network functions virtualization orchestrator (NFVO) (105), event routing manager (ERM) (130). Each of the network services has multiple instances. Multiple instances of the CNFM such as CNFM-instance-1, CNFM-instance-2 and CNFM-instance-3. Multiple instances of VIM such as vim-instance-1, vim-instance-2. Multiple instances of NFVO such as nfvo-instance-1, nfvo-instance-2 and nfvo-instance-3. Multiple instances of ERM such as erm-instance-1, erm-instance-2 and erm-instance-3.
[00162] At step (532) of the flow diagram (500), if there is only one instance of service, then the ERM (130) may select the service FQDN details. In an aspect, on detecting there is only one instance for the network service, the ERM (130) selects the one instance using FQDN details of the network service. Then, the flow diagram (500) proceeds to the step (536).
[00163] At step (534) of the flow diagram (500), if there is more than one instance of the service, then the ERM (130) may select the one instance using an algorithm. In an aspect, on detecting there is more than one instance of the service, the ERM (130) selects one instance using the selection algorithm. The selection algorithm includes round robin algorithm, least connection algorithm, weighted round-robin algorithm, random selection algorithm, least response time algorithm, etc. In round robin algorithm, requests are distributed sequentially across a pool of instances. Each instance gets an equal share of requests in a cyclic order. In least connection algorithm, the instance is chosen with the fewest active connections. In weighted round-robin algorithm, instances are assigned different weights based on their capacity or performance. In random selection algorithm, an instance is randomly selected from the pool of instances. In least response time algorithm, the instance is chosen with the lowest response time based on recent measurements.
[00164] At step (536) of the flow diagram (500), after selecting the instance details using the algorithm, the ERM (130) may check whether the context details are available in the memory or not. If the context details are available in the memory, the flow diagram (500) proceeds to step (540), and if the context details are not available in the memory, the flow diagram (500) proceeds to step (538). In an aspect, after selecting one of the instances, the ERM (130) check whether the context details are available in the memory for the request.
[00165] At step (538) of the flow diagram (500), if the context details are not available in the memory, then the ERM (130) may route the request to the FQDN and preconfigured context. In an aspect, the request is directed to a specific network service based on the FDQN that fully specifies the domain and subdomain in the network. In an example, the publisher has an FQDN: publisher.example.com and IP Address: 10.0.0.1 and the subscriber has an FQDN: subscriber.example.com and IP Address: 10.0.0.2. The publisher resolves subscriber.example.com to the IP address 10.0.0.2. The publisher sends an event request to http://10.0.0.2:8080/events.
[00166] At step (540) of the flow diagram (500), if the context details are available in the memory, then the ERM (130) may route the request to a fully qualified domain name (FQDN) and context. For example, the ERM (130) may route the request to the appropriate load balancer service or any specific service.
[00167] FIG. 6 illustrates an exemplary flow diagram of a method (600) for routing of a plurality of event requests between the plurality of components of the MANO (125) by the ERM, in accordance with an embodiment of the present disclosure.
[00168] At step (602), the method (600) includes receiving at least one event request from at least one component of the MANO (125) via an interface (i.e., EM_OA interface). The components of the MANO (125) include the OAM (115), the NFVO (105), the CNFM (110), the VIM (120). In an aspect, the at least one received event request includes at least one of broadcast request or routing request.
[00169] At step (604), the method (600) includes analyzing by the ERM the at least one received event request to determine whether the at least one received event request is the broadcast request or the routing request. The ERM determine whether received event request is the broadcast request or the routing request by analyzing the received event request.
[00170] At step (606), the method (600) includes upon determining the at least one received event request is the routing request, extracting an event name corresponding to the at least one determined routing request. In an aspect, upon determining that the received event request is the routing request (e.g., container creation request), the ERM processes the received routing request to extract the event name (e.g., container creation). In an aspect, the routing request comprises a fault, configuration, accounting, performance, and security (FCAPS) request. The ERM receives the routing request from at least one of the NFVO (105), the CNFM (110), the VIM (120).
[00171] At step (608), the method (600) includes based on the determined event name, routing the at least one received event request to at least one network service of at least one corresponding component of the MANO (125). In an aspect, based on the determined name (e.g., container creation), the ERM (130) determines at least one network service (e.g., Container creation network service) of the at least one corresponding component (e.g., CNFM (110)). The ERM (130) routes the received event request (e.g., container creation request) to the container creation network service of the CNFM (110) of the MANO (125).
[00172] At step (610), the method (600) includes upon determining the at least one received event request is the broadcast request, transmitting the at least one determined broadcast request to the plurality of components of the MANO (125). In an aspect, if the received event request is broadcast request, the ERM transmits the broadcast request to the components (e.g., CNFM (110), VIM (120), NFVO (105), ERM) of the MANO (125). In an aspect, the broadcast request comprises at least one of a registration request, a deregistration request, a high availability request. In an aspect, the ERM (130) receives the broadcast request from the OAM (115).
[00173] In an aspect, the OAM (115) receives the registration request from any one of the components (e.g., the NFVO (105), the VIM (120), the CNFM (110), the ERM (130)) of the MANO (125). Upon successful completion of registration of the one of the components of the MANO (125), the OAM (115) sends the broadcast request to the ERM. The broadcast request is used to inform the components of the MANO (125) about the availability of the registered component of the MANO (125). In an aspect, the OAM (115) receives a list of active ERM instances using the EM_OA interface. The OAM (115) broadcasts the list of active ERM instances using the broadcast request to the network services associated with the components of the MANO (125). The broadcast request helps the network services associated with the components of the MANO (125) to send any event request to only active instances of the ERM (130). In this way, the ERM broadcasts active ERM instance details to other ERM instances using the EM_OA interface between the OAM (115) and the ERM (130). Further, the ERM (130) gets instance details corresponding to the network services of the components of the MANO (125) via the broadcast requests from the OAM (115). The ERM stores the instance details corresponding to the network services of the components of the MANO (125) and uses the instance details to route the routing event request to specific instance corresponding to the network service of the components of the MANO (125).
[00174] In an aspect, The ERM extracts a set of information from the at least one received event request. The set of information includes service details, instance details, context details. Further, the ERM determines whether the set of extracted information is available in the database (124). Upon determining the set of extracted information is not available in the database (124), the ERM adds the extracted information in the database (124). Upon determining the set of extracted information is available in the database (124), the ERM updates the extracted information in the database (124).
[00175] In an aspect. the ERM (130) extracts details corresponding to the at least one component from the received event request. The ERM (130) determines whether the details corresponding to the at least one component are available in the database (124). Upon determining that the details corresponding to the at least one component are not available in the database (124), the ERM (130) stores the extracted details corresponding to the at least one component of the MANO (125) in the database (124). The ERM (130) updates the details corresponding to the at least one component of the MANO (125) in the database (124), when the details are available. In an example, if details corresponding to the NFVO (105) is available in the database (124) of the ERM (130) and the broadcast request corresponding to the NFVO (105) is received by the ERM (130), the ERM (130) compares the available details with the details in the request. If there is difference between the available details and the details in the request, the ERM (130) updates the details corresponding to the NFVO (105) in the database (124).
[00176] In an example, if the event request corresponding to new container creation for the CNFM (110) is received by the ERM (130) from the NFVO (105), then the ERM (130) extracts the event name from the event request. Upon determining the event name (i.e. container creation for the CNFM (110)), the ERM (130) compares the CNFM (110) details stored in the database (124) and the details of the CNFM (110) from the received event request. The ERM (130) determines specific instance of the container creation network service from the CNFM (110) to process the event request.
[00177] In an aspect, the ERM receives at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO. The received at least one event response comprises a success status and a failure status of the at least one routed event request. In an aspect, after processing the event request, the determined specific instance of the network service (e.g., container creation network service of the CNFM) from the CNFM (110) sends the event response to the ERM (130). The event response indicates a status of the event request. The status of the event request comprises at least one of a success status and a failure status. If the processing of the event request is successful, the network service (e.g., container creation network service of the CNFM (110)) sends the success response to the ERM (130).
[00178] In an example, ERM (130) receives the event request for creation of a new container from the NFVO (105). The received event request (i.e., creation of the new container) is analyzed by the ERM (130) to determine details (e.g., service name, the number of instances, the instance configuration, performance requirements, etc.). The ERM (130) compares the determined details with details of the at least one component of the MANO (125) stored in the database (124). The details of the at least one component of the MANO (125) include service details, instance details, and context details. The service details include, but are not limited to, service name, service type, service level agreements (SLA), etc. The instance details include, but are not limited to, instance identifier (ID), instance status, instance configuration (e.g., number of instances, rules, policies, instance configuration, location, operational metrics, etc.). The context details include, but are not limited to, routing rules, security policies, Quality of service (QoS) policies, operational status, etc.
[00179] The ERM (130) determines a corresponding component of the MANO (125) to route the received event request. In an example, if the event request corresponding to new container creation for the CNFM (110) is received by the ERM (130) from the NFVO (105), then the ERM (130) compares the CNFM (110) details stored in the database (124) and the details of the CNFM (110) from the received event request. The ERM (130) determines specific instance of the container creation network service from the CNFM (110) to process the event request.
[00180] In an aspect, for routing the received event request to the determined corresponding component of the MANO (125), the ERM (130) is configured to determine whether service details for the received event request are available. In an example, the ERM (130) determines service details (e.g., service type – new container creation for the CNFM (110)).
[00181] Upon determining that the service details for the received event request are not available, the ERM (130) sends an error (e.g., service details not available) to the at least one component of the MANO (125). In an example, upon determining the services details for the received new container creation request are not available, the ERM (130) sends the error (i.e., service details not available for the new container creation request) to the NFVO (105).
[00182] Upon determining that the service details for the received event request are available, the ERM (130) determines whether there is more than one instance of at least one network service of the determined corresponding component of the MANO (125). Upon determining that there is more than one instance, the ERM (130) selects one instance of the at least one network service using an algorithm. In an example, the container creation network service of the CNFM (110) includes plurality of instances. The ERM (130) determines one of the plurality of instances using the algorithm (e.g., round robin algorithm).
[00183] Further, upon determining that there is only one instance of the at least one network service, the ERM (130) is configured to select a fully qualified domain name (FDQN) of the at least one network service. In an aspect, if there is only one instance for the container creation network service of the CNFM (110), the ERM (130) selects that one instance with FDQN of the network service.
[00184] Furthermore, on selecting the one instance, the ERM (130) determines whether context details are available in the database (124). In an example, context details corresponding to the new container creation request for the CNFM (110) include resource allocation, scaling policy, throughput, deployment, etc.
[00185] Upon determining that the context details for the received event request are available in the database (124), the ERM (130) routes the received event request to the FDQN and the context details. In an example, when the context details for the received event request are available in the database (124), the ERM (130) routes the FDQN and the determined context details to the selected one instance of the container creation network service of the CNFM (110).
[00186] The received event request is routed to the FQDN and a preconfigured context when the context details for the received event request are not available in the database (124). In an example, when the context details for the received event request are not available in the database (124), the ERM (130) routes the received event request to the FQDN and a preconfigured context to the selected one instance of the container creation network service of the CNFM (110). The preconfigured context includes defined resource allocation, scaling policy, performance metrics, authentication, authorization, encryption standard, etc.
[00187] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented.
[00188] As shown in FIG. 7, the computer system may include an external storage device (710), a bus (720), a main memory (730), a read-only memory (740), a mass storage device (750), communication port(s) (760), and a processor (770). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (770) may include various modules associated with embodiments of the present disclosure. The communication port(s) (760) 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) (760) 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.
[00189] The main memory (730) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (740) 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 (770). The mass storage device (750) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage device (750) 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.
[00190] The bus (720) communicatively couples the processor (770) with the other memory, storage, and communication blocks. The bus (720) 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 (770) to the computer system.
[00191] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (720) 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) (760). 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.
[00192] The exemplary computer system (700) 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 event requests between a plurality of components of a management and orchestration (MANO) by an event routing manager (ERM), the method includes receiving at least one event request from at least one component of the MANO via an interface, analyzing the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request, upon determining the at least one received event request is the routing request, extracting an event name corresponding to the at least one determined routing request, and based on the determined event name, routing the at least one received event request to at least one network service of at least one corresponding component of the MANO, where upon determining the at least one received event request is the broadcast request, transmitting the at least one determined broadcast request to the plurality of components of the MANO.
[00193] 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.
[00194] The present disclosure provides technical advancement related to EM_OA interface. This advancement addresses the limitations of existing solutions by providing the EM_OA interface for facilitating communication between the ERM and the OAM. The ERMs use the EM_OA interface to register, deregister, or re-register. The services are created, updated, or removed frequently based on changing requirements. The EM_OA interface allows automatic detection of failed services and facilitates the rerouting of requests to alternative healthy instances or services. The ERM broadcasts the flavor details to other ERM instances using the EM_OA interface between the OAM and the ERM. Further, the EM_OA interface works in a high availability mode for fault tolerance for any event failure. If one ERM instance is down during request processing, then the next available ERM instance will take care of the request.

TECHNICAL ADVANTAGES OF THE INVENTION
[00195] As is evident from the above, the present disclosure provides a technically advanced solution by providing a system and a method for an event routing manager_ operation, administration and maintenance (EM_OA) interface that serves as a central hub for managing event routing managers (ERMs). The ERMs use the EM_OA interface to register, deregister, or re-register themselves. Services are designed to be independently deployable and scalable (for example, services are created, updated, or removed frequently based on changing requirements). The services discover and connect with each other dynamically, regardless of their locations or IP addresses. The EM_OA interface allows automatic detection of failed services and facilitates the rerouting of requests to alternative healthy instances or services. This improves overall system resilience and minimizes downtime. The services dynamically locate and consume each other’s application programming interfaces (APIs) by locating and connecting with dependent services in a distributed system. Further, services can be implemented using different programming languages, frameworks, or platforms thus enabling cross-platform and heterogeneous environments. The services can be deployed without requiring the knowledge of exact locations or configurations of other services, thereby, enabling flexibility in scaling, replacing, or upgrading services without disrupting the overall system functionality. The ERM broadcasts the flavor details to other ERM instances using the EM_OA interface between the operation, administration and maintenance (OAM) and the ERM. Async event-based implementation is performed to utilize the EM_OA interface efficiently. Further, the EM_OA interface works in a high availability mode for fault tolerance for any event failure. If one ERM instance is down during request processing, then the next available ERM instance will take care of the request.
,CLAIMS:CLAIMS
We claim:
1. A method (600) for routing a plurality of event requests between a plurality of components of a management and orchestration (MANO) (125) by an event routing manager (ERM) (130), the method (600) comprising:
receiving (602) at least one event request from at least one component of the MANO (125) via an interface;
analyzing (604) the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request;
upon determining the at least one received event request is the routing request, extracting (606) an event name corresponding to the at least one determined routing request; and
based on the determined event name, routing (608) the at least one received event request to at least one network service of at least one corresponding component of the MANO (125), wherein upon determining the at least one received event request is the broadcast request, transmitting (610) the at least one determined broadcast request to the plurality of components of the MANO (125).

2. The method (600) as claimed in claim 1, wherein the plurality of components of the MANO (125) comprises of an operation, administration and maintenance (OAM) (115), a network functions virtualization orchestrator (NFVO) (105), a container network function manager (CNFM) (110) and a virtualized infrastructure manager (VIM) (120), wherein the interface is an event routing manager_ operation, administration and maintenance (EM_OA) interface.
3. The method (600) as claimed in claim 1, further comprising: extracting a set of information from the at least one received event request, wherein the set of information includes service details, instance details, context details.

4. The method (600) as claimed in claim 3, further comprising:
determining whether the set of extracted information is available in a database (124); and
upon determining the set of extracted information is not available in the database (124), adding the extracted information in the database (124), wherein upon determining the set of extracted information is available in the database (124), updating the extracted information in the database (124).

5. The method (600) as claimed in claim 1, wherein the broadcast request comprises at least one of a registration request, a deregistration request, a high availability request, wherein the routing request comprises a fault, configuration, accounting, performance, and security (FCAPS) request.

6. The method (600) as claimed in claim 1, further comprising: receiving, by the ERM (130), the broadcast request from the OAM (115), wherein receiving, by the ERM (130), the routing request from at least one of the NFVO (105), the CNFM (110), the VIM (120).

7. The method (600) as claimed in claim 1, further comprising: receiving, by the ERM (130), at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO (125), wherein the received at least one event response comprises a success status and a failure status of the at least one routed event request.

8. A system (108) for routing a plurality of event requests between a plurality of components of a management and orchestration (MANO) (125), the system (108) comprising an event routing manager (ERM) (130), the ERM (130) comprising:
a receiving unit (116) configured to receive at least one event request from at least one component of the MANO (125) via an interface;
an analyzing unit (118) configured to analyze the at least one received event request to determine whether the at least one received event request is a broadcast request or a routing request;
upon determining the at least one received event request is the routing request, an execution unit (122) is configured to extract an event name corresponding to the at least one determined routing request; and
based on the determined event name, the execution unit (122) is configured to route the at least one received event request to at least one network service of at least one corresponding component of the MANO (125), wherein upon determining the at least one received event request is the broadcast request, the execution unit (122) is configured to transmit the at least one determined broadcast request to the plurality of components of the MANO (125).

9. The system (108) as claimed in claim 8, wherein the plurality of components of the MANO (125) comprises of an operation, administration and maintenance (OAM) (115), a network functions virtualization orchestrator (NFVO) (105), a container network function (CNF) manager (CNFM) (110) and a virtualized infrastructure manager (VIM) (120), wherein the interface is an event routing manager_ operation, administration and maintenance (EM_OA) interface.

10. The system (108) as claimed in claim 8, wherein the execution unit (122) is configured to extract a set of information from the at least one received event request, wherein the set of information includes service details, instance details, context details.

11. The system (108) as claimed in claim 10, wherein
the analyzing unit (118) configured to determine whether the set of extracted information is available in a database (124); and
upon determining the set of extracted information is not available in the database (124), the execution unit (122) is configured to add the extracted information in the database (124), wherein upon determining the set of extracted information is available in the database (124), the execution unit (122) is configured to update the extracted information in the database (124).
12. The system (108) as claimed in claim 8, wherein the broadcast request comprises at least one of a registration request, a deregistration request, a high availability request, wherein the routing request comprises a fault, configuration, accounting, performance, and security (FCAPS) request.

13. The system (108) as claimed in claim 8, wherein the receiving unit (116) is configured to receive the broadcast request from the OAM (115), wherein the receiving unit (116) is configured to receive the routing request from at least one of the NFVO (105), the CNFM (110), the VIM (120).

14. The system (108) as claimed in claim 8, wherein the receiving unit (116) is configured to receive at least one event response corresponding to the at least one routed event request from the at least one network service of the at least one corresponding component of the MANO (125), wherein the received at least one event response comprises a success status and a failure status of the at least one routed event request.