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 TO MANAGE ROUTING OF REQUESTS IN A 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 NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of communication network management and, more specifically, to a system and a method to manage request routing by means of a micro-service and a dedicated interface (e.g., event routing interface or the like) in the communication network.
BACKGROUND OF THE INVENTION
[0002] A communication network comprises of many network elements which are configured to operate in specific manners to improve credibility of the communication network. The communication network incorporates inventories to safe-keep resources and mechanism to efficiently distribute resources to all Network Functions (NFs) in the communication network so as to process service requests in the communication network. An Inventory Management (IM) service maintains a virtual inventory and a limited physical inventory. The IM service maintains the relation between physical and virtual resources with respect to overlay to manage storage memory allocation. Also, it describes physical and virtual resources in view of different attributes (e.g., subscription status, version information, error logs or the like) using updates from external micro-service. Thus, the data accuracy of the inventory depends on the micro-services which create, update, and delete the resources (e.g., network link, bandwidth, network node information or the like) and at the same time, the inventory updated an event with the IM service. Other services can query IM relations, attributes etc. using query Application Programming Interface (API) provided by the IM service.
[0003] A network management, other than the inventory management, also includes various micro-services operating simultaneously to perform various activities (e.g., event sharing, event publishing or the like). Amongst many micro-services event, a routing manger (ERM) is a micro-service which is used to route a request to and from at required micro-services. The ERM may be configured to act as a middle layer service platform to connect multiple micro-services to an inventory manager (e.g., Physical and Virtual Resource Manager (PVIM)).
[0004] An existing routing mechanism is easily subjected to congestions and have possible down time. Also, in the present routing mechanism, the same request event cannot be reused rather the request event has to be recreated each time thus impacting the service quality. Presently, there is no available mechanism to establish a dedicated routing pathway to achieve multiple micro-service connection. There is a need for an interface to manage incoming requests, route the request properly and send out information corresponding to the requests.
[0005] Therefore, there is a need for a system and a corresponding method to operate the ERM via a dedicated interface so that a network can be operated with ease.
SUMMARY OF THE INVENTION
[0006] One or more embodiments of the present disclosure provide a system and a method to manage routing of requests in a network.
[0007] In one aspect of the present invention, the method to manage routing of requests in a network. The method includes identifying, by one or more processors, at least one of, a recipient and a first event type from a first event received from a source. Further, the method includes registering, by one or more processors, at an Event Routing Manager (ERM), the first event by designating at least one of: the source as a subscriber, the recipient as a publisher and storing the first event type of the event. Further, the method includes routing, by the one or more processors, the first event from the ERM to the recipient based on checking details of the first event including at least one of, the source, the publisher and the first event type. If a second event is received from the recipient in response to routing the first event to the recipient, the method includes identifying, by the one or more processors, at least one of, the recipient and a second event type from the second event. Further, the method includes registering, by one or more processors, at the ERM, the second event by designating at least one of: the recipient as the subscriber, the source as the publisher and storing the second event type of the second event. Further, the method includes routing, by the one or more processors, the second event from the ERM to the source based on checking details of the second event including at least one of, the publisher and the second event type.
[0008] In an embodiment, the source is at least one a microservice.
[0009] In an embodiment, routing, the first event from the ERM to the recipient based on checking details of the first event including at least one of, the publisher and the first event type, includes at least one of the steps of: checking, by the one or more processors, if the first event type includes a first keyword as per the registered first event at the ERM, checking, by the one or more processors, the details of the publisher from the first event as per the registered first event at the ERM, and routing, by the one or more processors, the first event to the recipient based on the details of at least one of the first event type and the publisher.
[0010] In an embodiment, routing, the second event from the ERM to the source based on checking details of the second event including at least one of, the publisher and the second event type, includes at least one of the steps of: checking, by the one or more processors, if the second event type includes a second keyword as per the registered second event at the ERM, checking, by the one or more processors, the details of the publisher from the second event as per the registered second event at the ERM, and routing, by the one or more processors, the second event to the source based on the details of the second event type and the publisher.
[0011] In an embodiment, the first event type and the second event type are stored in a storage unit.
[0012] In an embodiment, the one or more processors, establishes a communication channel between an inventory and the ERM, wherein the communication channel is an interface.
[0013] In an embodiment, the interface is at least one of, an Inventory Manager_Event Manager (IM_EM) interface.
[0014] In one aspect of the present invention, the system to manage routing of requests in a network is disclosed. The system includes an identifying unit, a registering unit and a routing agent. The identifying unit is configured to identify at least one of: a recipient and a first event type from a first event received from a source. The registering unit is configured to register, at an ERM, the first event by designating at least one of: the source as a subscriber, the recipient as a publisher and storing the first event type of the event. The routing agent is configured to route the first event from the ERM to the recipient based on checking details of the first event including at least one of, the source, the publisher and the first event type. If a second event is received from the recipient in response to routing the first event to the recipient, the identifying unit is configured to identify at least one of, the recipient and a second event type from the second event. The registering unit is configured to register, at the ERM, the second event by designating at least one of: the recipient as the subscriber, the source as the publisher and storing the second event type of the second event. The routing agent is configured to, route, the second event from the ERM to the source based on checking details of the second event including at least one of, the publisher and the second event type.
[0015] In one aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer-readable instructions causes a processor to identify, at least one of, a recipient and a first event type from a first event received from a source. The processor registers, at an ERM, the first event by designating at least one of: the source as a subscriber, the recipient as a publisher and storing the first event type of the event. Further, the processor routes, the first event from the ERM to the recipient based on checking details of the first event including at least one of, the source, the publisher and the first event type. If a second event is received from the recipient in response to routing the first event to the recipient, the processor identifies, at least one of, the recipient and a second event type from the second event. Further, the processor registers, at the ERM, the second event by designating at least one of, the recipient as the subscriber, the source as the publisher and storing the second event type of the second event. Further, the processor routes, the second event from the ERM to the source based on checking details of the second event including at least one of, the publisher and the second event type.
[0016] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS
[0017] 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.
[0018] FIG. 1 is an exemplary block diagram of an environment to manage routing of requests in a communication network, according to various embodiments of the present disclosure.
[0019] FIG. 2 is a block diagram of a system of FIG. 1, according to various embodiments of the present disclosure.
[0020] FIG. 3 is an example schematic representation of the system of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system.
[0021] FIG. 4 illustrates an example system to manage and route request from a micro-service via an event routing interface, according to various embodiments of the present system.
[0022] FIG. 5 illustrates an example workflow of an interaction in between a Physical Virtual Inventory Manager (PVIM) and an ERM, in accordance with an embodiment of the present invention.
[0023] FIG. 6 illustrates an example flow diagram of a method for managing routing of requests in a network, in accordance with an embodiment of the present invention.
[0024] FIG. 7 illustrates an architecture framework (e.g., MANO architecture framework), in which the present invention can be implemented , in accordance with an embodiment of the present invention.
[0025] FIG. 8 is an exemplary flow diagram illustrating the method for managing routing of requests in the communication network, according to various embodiments of the present disclosure.
[0026] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
[0027] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION
[0028] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0029] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0030] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0031] Before discussing example, embodiments in more detail, it is to be noted that the drawings are to be regarded as being schematic representations and elements that are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software or a combination thereof.
[0032] Further, the flowcharts provided herein, describe the operations as sequential processes. Many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of operations maybe re-arranged. The processes may be terminated when their operations are completed, but may also have additional steps not included in the figured. It should be noted, that in some alternative implementations, the functions/acts/ steps noted may occur out of the order noted in the figured. For example, two figures shown in succession may, in fact, be executed substantially concurrently, or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
[0033] Further, the terms first, second etc… may be used herein to describe various elements, components, regions, layers and/or sections, it should be understood that these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are used only to distinguish one element, component, region, layer or section from another region, layer, or a section. Thus, a first element, component, region layer, or section discussed below could be termed a second element, component, region, layer, or section without departing form the scope of the example embodiments.
[0034] Spatial and functional relationships between elements (for example, between modules) are described using various terms, including “connected,” “engaged,” “interfaced,” and “coupled.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the description below, that relationship encompasses a direct relationship where no other intervening elements are present between the first and second elements, and also an indirect relationship where one or more intervening elements are present (either spatially or functionally) between the first and second elements. In contrast, when an element is referred to as being "directly” connected, engaged, interfaced, or coupled to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., "between," versus "directly between," "adjacent," versus "directly adjacent," etc.).
[0035] The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
[0036] As used herein, the singular forms “a,” “an,” and “the,” are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, the terms “and/or” and “at least one of” include any and all combinations of one or more of the associated listed items. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, 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.
[0037] Unless specifically stated otherwise, or as is apparent from the description, terms such as “processing” or “computing” or “calculating” or “determining” of “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device/hardware, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0038] Various embodiments of the present invention provide a system and method to manage requests initiated by various micro-services and an inventory manager (e.g., PVIM), to route requests to and from a PVIM in the communication network to achieve optimum time and data management efficiently by using a dedicated interface (e.g., event routing interface or the like). However, the invention is not to be limited to only these embodiments.
[0039] Most of the event request routing is managed separately via multiple interface causing congestion and slow operation of the micro-services network. Moreover, each time a request is initiated a new event must be created which is time and resource consuming. To facilitate solution of this problem, in various embodiments of the present invention, the system and method can be used to route requests for various micro-service and interact with the PVIM in a network by means of the dedicated interface to achieve optimum time and data management efficiently.
[0040] FIG. 1 illustrates an exemplary block diagram of an environment (100) to manage routing of requests in a communication network (106), according to various embodiments of the present disclosure. The environment (100) comprises a plurality of user equipment’s (UEs) (102-1, 102-2, ……,102-n). The at least one UE (102-n) from the plurality of the UEs (102-1, 102-2, ……102-n) is configured to connect to a system (108) via a communication network (106). Hereafter, label for the plurality of UEs or one or more UEs is 102.
[0041] In accordance with yet another aspect of the exemplary embodiment, the plurality of UEs (102) may be a wireless device or a communication device that may be a part of the system (108). The wireless device or the UE (102) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, 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, a computer device, and so on), 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 or Voice Over Internet Protocol (VoIP) capabilities. In an embodiment, the UEs (102) may include, but are not limited to, any electrical, electronic, electro-mechanical or an 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, where the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs (102) may not be restricted to the mentioned devices and various other devices may be used. A person skilled in the art will appreciate that the plurality of UEs (102) may include a fixed landline, and a landline with assigned extension within the communication network (106).
[0042] The communication network (106), may use one or more communication interfaces/protocols such as, for example, Voice Over Internet Protocol (VoIP), 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as Code Division Multiple Access (CDMA), CDMA2000, Wideband CDMA (WCDMA), Radio Frequency Identification (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0043] The communication network (106) includes, by way of example but not limitation, one or more of 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. The communication network (106) may include, but is not limited to, a Third Generation (3G) network, a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, a New Radio (NR) network, a Narrow Band Internet of Things (NB-IoT) network, an Open Radio Access Network (O-RAN), and the like.
[0044] The communication network (106) may also 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 communication network (106) may also include, by way of example but not limitation, one or more of 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, a VOIP or some combination thereof.
[0045] One or more network elements can be, for example, but not limited to a base station that is located in the fixed or stationary part of the communication network (106). The base station may correspond to a remote radio head, a transmission point, an access point or access node, a macro cell, a small cell, a micro cell, a femto cell, a metro cell. The base station enables transmission of radio signals to the UE (102) or a mobile transceiver. Such a radio signal may comply with radio signals as, for example, standardized by a 3rd Generation Partnership Project (3GPP) or, generally, in line with one or more of the above listed systems. Thus, a base station may correspond to a NodeB, an eNodeB, a Base Transceiver Station (BTS), an access point, a remote radio head, a transmission point, which may be further divided into a remote unit and a central unit. The 3GPP specifications cover cellular telecommunications technologies, including radio access, core network, and service capabilities, which provide a complete system description for mobile telecommunications.
[0046] The system (108) is communicatively coupled to a server (104) via the communication network (106). The server (104) can be, for example, but not limited to a standalone server, a server blade, a server rack, an application server, a bank of servers, a business telephony application server (BTAS), a server farm, a cloud server, an edge server, home server, a virtualized server, one or more processors executing code to function as a server, or the like. In an implementation, the server (104) may operate at various entities or a single entity (include, but is not limited to, a vendor side, a service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, a defense facility side, or any other facility) that provides service.
[0047] The environment (100) further includes the system (108) communicably coupled to the server (e.g., remote server or the like) (104) and each UE of the plurality of UEs (102) via the communication network (106). The remote server (104) is configured to execute the requests in the communication network (106).
[0048] The system (108) is adapted to be embedded within the remote server (104) or is embedded as an individual entity. The system (108) is designed to provide a centralized and unified view of data and facilitate efficient business operations. The system (108) is authorized to access to update/create/delete one or more parameters of their relationship between the requests for a microservice, which gets reflected in real-time independent of the complexity of network.
[0049] In another embodiment, the system (108) may include an enterprise provisioning server (for example), which may connect with the remote server (104). The enterprise provisioning server provides flexibility for enterprises, ecommerce, finance to update/create/delete information related to the requests for the microservice in real time as per their business needs. A user with administrator rights can access and retrieve the requests for the microservice and perform real-time analysis in the system (108).
[0050] The system (108) may include, by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a business telephony application server (BTAS), a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an implementation, system (108) may operate at various entities or single entity (for example include, but is not limited to, a vendor side, service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, ecommerce side, finance side, a defense facility side, or any other facility) that provides service.
[0051] However, for the purpose of description, the system (108) is described as an integral part of the remote server (104), without deviating from the scope of the present disclosure. Operational and construction features of the system (108) will be explained in detail with respect to the following figures.
[0052] FIG. 2 illustrates a block diagram of the system (108) provided for managing routing of requests in the communication network (106), according to one or more embodiments of the present invention. As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), an input/output interface unit (206), a display (208), an input device (210), and the database (214). Further the system (108) may comprise one or more processors (202). The one or more processors (202), hereinafter referred to as the processor (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system (108) includes one processor. However, it is to be noted that the system (108) may include multiple processors as per the requirement and without deviating from the scope of the present disclosure.
[0053] An information related to the microservice may be provided or stored in the memory (204) of the system (108). Among other capabilities, the processor (202) is configured to fetch and execute computer-readable instructions stored in the memory (204). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0054] The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system (108) may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and the database (214). The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s).
[0055] The information related to the microservice may further be configured to render on the user interface (206). The user interface (206) may include functionality similar to at least a portion of functionality implemented by one or more computer system interfaces such as those described herein and/or generally known to one having ordinary skill in the art. The user interface (206) may be rendered on the display (208), implemented using Liquid Crystal Display (LCD) display technology, Organic Light-Emitting Diode (OLED) display technology, and/or other types of conventional display technology. The display (208) may be integrated within the system (108) or connected externally. Further the input device(s) (210) may include, but not limited to, keyboard, buttons, scroll wheels, cursors, touchscreen sensors, audio command interfaces, magnetic strip reader, optical scanner, etc.
[0056] The database (214) may be communicably connected to the processor (202) and the memory (204). The database (214) may be configured to store and retrieve the request pertaining to features, or services or workflow of the system (108), access rights, attributes, approved list, and authentication data provided by an administrator. In another embodiment, the database (214) may be outside the system (108) and communicated through a wired medium and a wireless medium.
[0057] Further, the processor (202), in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor (202). In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by an electronic circuitry.
[0058] In order for the system (108) to manage routing of requests in the commination network (106), the processor (202) includes an identifying unit (216), a registering unit (218), a routing agent (220) and a storage unit (222). The identifying unit (216), the registering unit (218), the routing agent (220) and the storage unit (222) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by the electronic circuitry.
[0059] In order for the system (108) to manage routing of requests in the communication network (106), the identifying unit (216), the registering unit (218), the routing agent (220) and the storage unit (222) are communicably coupled to each other.
[0060] The identifying unit (216) identifies a recipient and a first event type from a first event received from a source (e.g., microservice or the like). The microservice is a design and architectural pattern that organizes network functions into small, independent, and loosely coupled services. Each microservice handles a specific aspect of the network functionality and can be developed, deployed, and scaled independently. For example, if the event type is “event”, then the ERM (404) will pass the request to the publisher, and if the event type is “eventAck” then the ERM (404) will pass the request to subscriber.
[0061] Further, the registering unit (218) registers, at the ERM (404), the first event by designating the source as the subscriber, the recipient as the publisher and storing the first event type of the event. In an example, from FIG. 4, when the micro-service wants to send the request to the PVIM (406) then, that the event should be registered in the ERM (404) as publisher as the PVIM (406) and subscriber as other micro-service via an Inventory Manager_Event Manager (IM_EM) interface (408). In an embodiment, the Inventory Manager_Event Manager (IM_EM) may also be called as the Inventory Manager_Event Routing Manager (IM_EM). The first event type is “send the event to the ERM (404)” (as shown in FIG. 4).
[0062] The routing agent (220) routes the first event from the ERM (404) to the recipient based on checking details of the first event including the source, the publisher and the first event type. In an embodiment, the routing agent (220) routes the first event from the ERM (404) to the recipient by checking, if the first event type includes a first keyword (e.g., first event related keyword) as per the registered first event at the ERM (404), checking, the details of the publisher from the first event as per the registered first event at the ERM (404), and routing, the first event to the recipient based on the details of at least one of the first event type and the publisher. The details include identifiers, labels, or attributes that help in routing decisions. Also, the details include an event metadata is used for determining where and how the event should be routed.
[0063] If the second event is received from the recipient in response to routing the first event to the recipient, the identifying unit (216) identifies the recipient and the second event type from the second event. The registering unit (218) registers, at the ERM (404), the second event by designating the recipient as the subscriber, the source as the publisher and storing the second event type of the second event. In an example, from FIG. 4, when the PVIM (406) wants to send the request to other micro-service then that the event should be registered in the ERM (404) with the subscriber as the PVIM (406) and publisher as other micro-service via the IM_EM interface (408).
[0064] The routing agent (220) routes the second event from the ERM (404) to the source based on checking details of the second event including the publisher and the second event type. In an embodiment, the routing agent (220) routes the second event from the ERM (404) to the source by checking, if the second event type includes a second keyword (e.g., event acknowledgment or the like) as per the registered second event at the ERM (404), checking the details of the publisher from the second event as per the registered second event at the ERM (404) and routing the second event to the source based on the details of the second event type and the publisher. Further, the first event type and the second event type are stored in the storage unit (222). The example for manage routing of requests in the network (106) is explained in FIG. 4 to FIG. 6.
[0065] FIG. 3 is an example schematic representation of the system (300) of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE (102-1) and the system (108) for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0066] As mentioned earlier, the first UE (102-1) includes one or more primary processors (305) communicably coupled to the one or more processors (202) of the system (108). The one or more primary processors (305) are coupled with a memory (310) storing instructions which are executed by the one or more primary processors (305). Execution of the stored instructions by the one or more primary processors (305) enables the UE (102-1). The execution of the stored instructions by the one or more primary processors (305) further enables the UE (102-1) to execute the requests in the communication network (106).
[0067] As mentioned earlier, the one or more processors (202) is configured to transmit a response content related to the microservice to the UE (102-1). More specifically, the one or more processors (202) of the system (108) is configured to transmit the response content to at least one of the UE (102-1). A kernel (315) is a core component serving as the primary interface between hardware components of the UE (102-1) and the system (108). The kernel (315) is configured to provide the plurality of response contents hosted on the system (108) to access resources available in the communication network (106). The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0068] As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210). The operations and functions of the one or more processors (202), the memory (204), the input/output interface unit (206), the display (208), and the input device (210) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure. Further, the processor (202) includes the identifying unit (216), the registering unit (218), the routing agent (220) and the storage unit (222). The operations and functions of the identifying unit (216), the registering unit (218), the routing agent (220) and the storage unit (222) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure.
[0069] FIG. 4 illustrates an example system (400) to manage and route request from micro-services via an event routing interface (e.g., IM_EM interface) (408), according to various embodiments of the present system.
[0070] The example system (400) includes a source (e.g., MS-X) (402), the event routing manger (ERM) (404), the PVIM (406) and an event routing interface (e.g., IM_EM interface) (408) having a subscription module (not shown) to receive requests from various micro-services and send out information to various micro-services. Also, the IM_EM interface includes a creation module (not shown) to create the event requests and store created request events to reuse them and the routing agent (220) to route requests to designated network services. The PVIM (406) manages and stores all available data, resource, and information in the network (406). The source (402) communicates with the ERM (404). The present system (400) may further include one or more database (214) interacting with the PVIM (406).
[0071] The ERM (404), by means of the IM_EM interface (408), is configured to route all the incoming requests to the PVIM (406) and all the outgoing request from the PVIM (406). The IM_EM interface (408) follows a subscription and notification model based on the events which are published to it. Each micro service registers its standard platform events with the ERM (404). For each event, there can be multiple subscribers. Whenever the event of interest is received, the notifications are sent by the ERM (404) to the subscribers informing them of the event. When the micro-service wants to send request to the PVIM (406) then that event should be registered in the ERM (404) as publisher as the PVIM (406) and subscriber as other micro-service by means of the subscription module of the IM_EM interface (408). Similarly, when the PVIM (406) wants to send the request to other micro-service then that event should be registered in the ERM (404) with subscriber as the PVIM (406) and publisher as other micro-service. The IM_EM interface (408) searches for the created subscription in the events for publisher name as ‘PVIM’. If the IM_EM interface (408) finds a ‘true’ match then, the IM_EM interface (408) creates an event for sending a request to the PVIM (406) by the creation module (not shown). The IM_EM interface (408) checks again for the event which is being sent by the PVIM (406) for the publisher name, and redirects the request to same publisher by means of a routing module (330). For example: If event type is “event” then ERM (404) will pass the request to publisher, and If event type is “eventAck” then ERM (404) will pass the request to subscriber.
[0072] The present system (400) is capable of performing requested routing where a specific request may be routed to pre-defined network service provider upon the subscription. The system (400) is also configured to address operational issues for new request subscriber and publisher. The present system (400) have provision to store and reuse created event requests.
[0073] The ERM (404), the IM_EM interface (408), the PVIM (406) and the database (214) are also configured to interact with various servers, network elements and other network components present in the network (106). The present system (400) is also configured to interact with a management and orchestration module to manage various workflow. The PVIM (406) keeps all information in the network inventory and manages the inventory. The database (214) may be one or more in number and may be index database, virtual database, or graphical database.
[0074] For any operation the system (400) may implement API as a medium of communication to communicate with server(s) in the network (106). The system (400) may operates and exchanges information in JSON (JavaScript Object Notation) format.
[0075] FIG. 5 illustrates an example workflow of the interaction between the inventory for example the PVIM (406) and the ERM (404), in accordance with an embodiment of the present invention. The PVIM (406) and the ERM (404) are exchanging information via a communication channel which is an interface. In an embodiment, the interface is at least one of, an Inventory Manager_Event Manager (IM_EM) interface (408). The IM_EM interface (408) is configured to receive and transmit data between the PVIM (406) and the ERM (404). The operations and functions of the PVIM (406) and the ERM (404) are already explained in FIG. 5. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure.
[0076] In preferred embodiments, the system and method executed by the said system by the PVIM (406) which may be based on Management and orchestration framework which is a telec-cloud infrastructure interface, as a key element of the network functions virtualization (NFV) architecture. The PVIM (406) may coordinate network resources for cloud-based applications and manage any virtual network functions (VNFs) or container network function (CNF) and/or other network services. The PVIM (406) may be configured to interact with various APIs (application programming interface).
[0077] FIG. 6 illustrates an example flow diagram (600) of a method for managing routing of requests in the communication network (106), in accordance with an embodiment of the present invention.
[0078] At 602, when any micro-service wants to send request to the PVIM (406) then, that the event should be registered in the ERM (404) as publisher as the PVIM (406) and subscriber as other micro-service via the IM_EM interface (408). At 604, when the PVIM (406) wants to send request to other micro-service then that event should be registered in the ERM (404) with subscriber as the PVIM (406) and publisher as other micro-service via the IM_EM interface (408).
[0079] At 606, the event routing interface (e.g., IM_EM interface) (408) checks in the event for publisher name as the PVIM (406) and if finds true then it will send request to the PVIM (406). At 608, the IM_EM interface (408) checks for the event which is being sent by the PVIM (406) for the publisher name, and redirects the request to same publisher. At 610, the ERM (404) processes the requests, and if the event type is “event” then the ERM (404) will pass the request to the publisher, and if the event type is “event-Ack” then the ERM (404) will pass the request to subscriber via the IM_EM interface (408).
[0080] The proposed method can be used to achieve request management efficiently by using the IM_EM interface (408)
[0081] In preferred embodiments, the system and method may be executed in a manner where for any operation, an API is considered a medium of communication and every operation may be performed via http request, for communication between user and other network elements like server. The information exchanges is performed in JSON format.
[0082] FIG. 7 illustrates an architecture framework (700) (e.g., MANO architecture framework), in which the present invention can be implemented, in accordance with an embodiment of the present invention. The system architecture (700) includes the user interface (206), a Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) design function module (702), a platform foundation service module (704), a platform core service module (706), and a platform resource adapter and utilities module (708).
[0083] The NFV and SDN design function module (702) is crucial for modernizing network infrastructure by enabling virtualized, scalable, and programmable network functions and management systems, particularly within the framework of CNFs. The platform foundation service module (704) refers to the underlying services and infrastructure components that support and enable the deployment, operation, and management of containerized network functions. The platform foundation service module (704) provides the essential capabilities and resources required for the CNF environment to function effectively.
[0084] The platform core service module (706) refers to the fundamental services and components that are essential for the core functionality and operation of containerized network functions. These services are critical for the effective deployment, execution, and management of CNFs, providing the necessary support and infrastructure for their operation. The platform resource adapter and utilities module (708) refers to a set of components and tools designed to manage and adapt various resources and services necessary for the operation of CNFs. The platform resource adapter and utilities module (708) plays a crucial role in integrating CNFs with underlying infrastructure and services, providing the necessary support for efficient operation, resource utilization, and interoperability.
[0085] The NFV and SDN design function module (702) includes a VNF lifecycle manger (702a), a VNF catalog (702b), a network service catalog (702c), a network slicing and service chaining manger (702d), a physical and virtual resource manager (702e), and a CNF lifecycle manager (702f).
[0086] The VNF lifecycle manager (702a) is responsible for managing the entire lifecycle of Virtual Network Functions (VNFs). The VNF lifecycle manager (702a) ensures that VNFs or CNFs are deployed, configured, monitored, scaled, and eventually decommissioned effectively. The VNF catalog (702b) (referred to as a CNF catalog) is a repository or registry that stores information about various containerized network functions and their configurations. The VNF catalog (702b) serves as a central reference for managing and deploying CNFs, providing details about their capabilities, requirements, and how they can be used within the network environment. The network service catalog (702c) is a comprehensive repository that organizes and manages the information related to network services composed of multiple CNFs or other network functions. The network service catalog (702c) serves as a central resource for defining, deploying, and managing these services within a containerized network environment.
[0087] The network slicing and service chaining manger (702d) is a crucial component responsible for orchestrating and managing network slicing and service chaining functionalities. These functionalities are essential for efficiently utilizing network resources and delivering tailored network services in a dynamic and scalable manner. The physical and virtual resource manager (702e) is a critical component responsible for overseeing and managing both physical and virtual resources required to support the deployment, operation, and scaling of CNFs. The physical and virtual resource manager (702e) ensures that the necessary resources are allocated efficiently and effectively to meet the performance, availability, and scalability requirements of containerized network functions.
[0088] Further, the CNF lifecycle manager (702f) is a component responsible for overseeing the entire lifecycle of containerized network functions. This includes the management of CNFs from their initial deployment through ongoing operation and maintenance, up to their eventual decommissioning. The CNF lifecycle manager (702f) ensures that the CNFs are efficiently deployed, monitored, scaled, updated, and removed, facilitating the smooth operation of network services in a containerized environment.
[0089] The platform foundation service module (704) includes a microservice elastic load balancer (704a), an identity and access manager (704b), a command line interface (704c), a central logging manger (704d) and the event routing manger (404).
[0090] The microservice elastic load balancer (704a) is a specific type of load balancer designed to dynamically distribute network traffic across a set of microservices running in a containerized environment. Its primary purpose is to ensure efficient resource utilization, maintain high availability, and improve the performance of network services by evenly distributing incoming traffic among multiple instances of microservices. The identity and access manager (704b) is a critical component responsible for managing and securing access to containerized network functions and their resources. The identity and access manager (704b) ensures that only authorized users and systems can access specific resources, and it enforces policies related to identity verification, authentication, authorization, and auditing within the CNF ecosystem.
[0091] The central logging manger (704d) is a component responsible for aggregating, managing, and analyzing log data from various containerized network functions and associated infrastructure components. This centralized approach to logging ensures that logs are collected from disparate sources, consolidated into a single repository, and made accessible for monitoring, troubleshooting, and auditing purposes. The event routing manger (404) is a component responsible for handling the distribution and routing of events and notifications generated by various parts of the CNF environment. This includes events related to system status, performance metrics, errors, and other operational or application-level events. The event routing manger (404) ensures that these events are efficiently routed to the appropriate consumers, such as monitoring systems, alerting systems, or logging infrastructure, for further processing and action.
[0092] The platform core service module (706) includes an NFV infrastructure monitoring manager (706a), an assurance manager (706b), a performance manger (706c), a policy execution engine (706d), a capacity monitoring manger (706e),a release management repository (706f), a configuration manger and GCT (706g), a NFV platform decision analytics unit (706h), a platform NoSQL DB (706i), a platform scheduler and Cron Jobs module (706j), a VNF backup & upgrade manger (706k), a micro service auditor (706l), and a platform operation, administration and maintenance manager (706m).
[0093] The NFV infrastructure monitoring manager (706a) monitors the underlying infrastructure of NFV environments, including computing, storage, and network resources. The NFV infrastructure monitoring manager (706a) provides real-time visibility into resource health, performance, and utilization. Further, the NFV infrastructure monitoring manager (706a) detects and alerts on infrastructure issues. Further, the NFV infrastructure monitoring manager (706a) integrates with monitoring tools to ensure reliable operation of CNFs.
[0094] The assurance manager (706b) manages the quality and reliability of network services by ensuring compliance with service level agreements (SLAs) and operational standards. The performance manger (706c) optimizes the performance of CNFs by tracking and analyzing key performance indicators (KPIs). The policy execution engine (706d) enforces and applies policies within the CNF environment to manage operations and access. Further, the policy execution engine (706d) executes policies related to security, resource allocation, and service quality. Further, the policy execution engine (706d) executes policies translates policy rules into actionable configurations and enforces compliance across CNFs.
[0095] The capacity monitoring manger (706e) monitors and manages the capacity of resources within the CNF environment to ensure optimal usage and avoid resource shortages. The release management repository (706f) stores and manages software releases, configurations, and versions of CNFs. Further, the release management repository (706f) keeps track of different versions of CNFs.
[0096] The configuration manger and Generic Configuration Tool (GCT) (706g) manages the configuration of CNFs and related infrastructure components. The NFV platform decision analytics unit (706h) analyzes data from a NFV platform to support decision-making and strategic planning.
[0097] The platform NoSQL database (DB) (706i) is used for storing and managing large volumes of unstructured or semi-structured data within the CNF environment. The platform scheduler and Cron Jobs module (706j) manages scheduled tasks and periodic operations within the CNF environment. The VNF backup & upgrade manger (706k) oversees the backup and upgrade processes for Virtual Network Functions (VNFs) within the CNF environment.
[0098] The micro service auditor (706l) monitors and audits microservices to ensure compliance with operational and security standards. The platform operation, administration and maintenance manager (706m) manages the overall operation, administration, and maintenance of the CNF platform.
[0099] The platform resource adapter and utilities module (708) includes a platform external API adaptor and gateway (708a), a generic decoder and indexer (708b), a swarm adaptor (708c), an openstack API adaptor (708d) and a NFV gateway (708e).
[00100] The platform external API adaptor and gateway (708a) facilitates communication between the CNF platform and external systems or services by providing an interface for API interactions. The generic decoder and indexer (708b) decodes and indexes various types of data and logs within the CNF environment. The swarm adaptor (708c) facilitates communication between a swarm clusters and the CNF environment, including container deployment, scaling, and management.
[00101] The openstack API adaptor (708d) provides an interface for the CNF platform to interact with OpenStack APIs, enabling operations such as provisioning, scaling, and managing virtual resources. The NFV gateway (708e) manages and facilitates communication between NFV (Network Functions Virtualization) components and external networks or services.
[00102] FIG. 8 is an exemplary flow diagram (800) illustrating the method for managing routing of requests in the communication network (106), according to various embodiments of the present disclosure.
[00103] At 802, the method includes identifying the recipient and the first event type from the first event received from the source. In an embodiment, the method allows the identifying unit (216) to identify the recipient and the first event type from the first event received from the source.
[00104] At 804, the method includes registering, at the ERM (404), the first event by designating the source as the subscriber, the recipient as the publisher and storing the first event type of the event. In an embodiment, the method allows the registering unit (218) to register, at the ERM (404), the first event by designating the source as the subscriber, the recipient as the publisher and storing the first event type of the event.
[00105] At 806, the method includes routing the first event from the ERM (404) to the recipient based on checking details of the first event including the source, the publisher and the first event type. In an embodiment, the method allows the routing agent (220) to route the first event from the ERM (404) to the recipient based on checking details of the first event including the source, the publisher and the first event type.
[00106] If the second event is received from the recipient in response to routing the first event to the recipient, at 808, the method includes identifying the recipient and the second event type from the second event. In an embodiment, the method allows the identifying unit (216) to identify the recipient and the second event type from the second event.
[00107] At 810, the method includes registering, at the ERM (404), the second event by designating the recipient as the subscriber, the source as the publisher and storing the second event type of the second event. In an embodiment, the method allows the registering unit (218) to register, at the ERM (404), the second event by designating the recipient as the subscriber, the source as the publisher and storing the second event type of the second event.
[00108] At 812, the method includes routing the second event from the ERM (404) to the source based on checking details of the second event including the publisher and the second event type. In an embodiment, the method allows the routing agent (220) to route the second event from the ERM (404) to the source based on checking details of the second event including the publisher and the second event type.
[00109] Below is the technical advancement of the present invention:
[00110] The proposed method performs easy routing and simplified performance of the event routing manager by means of a dedicated interface for monitoring and managing the requests. The proposed method minimizes error in the workflow. Based on the proposed method, the operation is less time consuming. The proposed method avoids prolonging request processing time and ease of request routing for efficient information exchange. The proposed method provides an operation and management to add/modify request subscriber publisher in a simple manner. The proposed method provides provision to reuse previously created request events. The proposed method does not impact network service. The proposed method uses an async event-based implementation to utilize interface efficiently. The proposed method enables a fault tolerance for any event failure. The interface works in a high availability mode and if one inventory instance went down during request processing then the next available instance will take care of this request.
[00111] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS. 1-8) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00112] Method steps: A person of ordinary skill in the art will readily ascertain that the illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00113] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS
[00114] Environment - 100
[00115] UEs– 102, 102-1-102-n
[00116] Server - 104
[00117] Communication network – 106
[00118] System – 108
[00119] Processor – 202
[00120] Memory – 204
[00121] User Interface – 206
[00122] Display – 208
[00123] Input device – 210
[00124] Database – 214
[00125] Identifying unit– 216
[00126] Registering unit – 218
[00127] Routing agent– 220
[00128] Storage unit– 224
[00129] Response unit – 226
[00130] System - 300
[00131] Primary processors -305
[00132] Memory– 310
[00133] Kernel– 315
[00134] Example system – 400
[00135] Source (e.g., MS-X) – 402
[00136] ERM – 404
[00137] PVIM - 406
[00138] IM_EM interface- 408
[00139] System architecture – 700
[00140] NFV and SDN design function – 702
[00141] VNF lifecycle manger - 702a
[00142] VNF catalog - 702b
[00143] Network service catalog - 702c
[00144] Network slicing and service chaining manger - 702d
[00145] Physical and virtual resource manager - 702e
[00146] CNF lifecycle manger - 702f
[00147] Platform foundation service module - 704
[00148] Microservice elastic load balancer - 704a
[00149] identity and access manager - 704b
[00150] Command line interface - 704c
[00151] Central logging manger - 704d
[00152] platform core service module – 706
[00153] NFV infrastructure monitoring manager - 706a
[00154] Assurance manager - 706b
[00155] Performance manger - 706c
[00156] Policy execution engine - 706d
[00157] Capacity monitoring manger - 706e
[00158] Release management repository - 706f
[00159] Configuration manger and GCT - 706g
[00160] NFV platform decision analytics - 706h
[00161] Platform NoSQL DB - 706i
[00162] Platform scheduler and cron Jobs module - 706j
[00163] VNF backup & upgrade manger - 706k
[00164] Micro service auditor - 706l
[00165] Platform operation, administration and maintenance manager - 706m
[00166] Platform resource adapter and utilities module – 708
[00167] Platform External API adaptor and gateway - 708a
[00168] Generic decoder and indexer - 708b
[00169] Swarm adaptor 708c
[00170] Openstack API adaptor - 708d
[00171] NFV gateway - 708e
,CLAIMS:CLAIMS:
We Claim:
1. A method to manage routing of requests in a network (106), the method comprising the steps of:
identifying, by one or more processors (202), at least one of, a recipient and a first event type from a first event received from a source;
registering, by one or more processors (202), at an Event Routing Manager (ERM) (404), the first event by designating at least one of: the source as a subscriber, the recipient as a publisher and storing the first event type of the event;
routing, by the one or more processors (202), the first event from the ERM (404) to the recipient based on checking details of the first event including at least one of, the source, the publisher and the first event type;
if a second event is received from the recipient in response to routing the first event to the recipient, identifying, by the one or more processors (202), at least one of, the recipient and a second event type from the second event;
registering, by one or more processors (202), at the ERM (404), the second event by designating at least one of: the recipient as the subscriber, the source as the publisher and storing the second event type of the second event; and
routing, by the one or more processors (202), the second event from the ERM (404) to the source based on checking details of the second event including at least one of, the publisher and the second event type.

2. The method as claimed in claim 1, wherein the source is at least one of, a microservice.

3. The method as claimed in claim 1, wherein the step of, routing, the first event from the ERM (404) to the recipient based on checking details of the first event including at least one of, the publisher and the first event type, includes at least one of the steps of:
checking, by the one or more processors (202), if the first event type includes a first keyword as per the registered first event at the ERM (404);
checking, by the one or more processors (202), the details of the publisher from the first event as per the registered first event at the ERM (404); and
routing, by the one or more processors (202), the first event to the recipient based on the details of at least one of the first event type and the publisher.

4. The method as claimed in claim 1, wherein the step of, routing, the second event from the ERM (404) to the source based on checking details of the second event including at least one of, the publisher and the second event type, includes at least one of the steps of:
checking, by the one or more processors (202), if the second event type includes a second keyword as per the registered second event at the ERM (404);
checking, by the one or more processors (202), the details of the publisher from the second event as per the registered second event at the ERM (404); and
routing, by the one or more processors (202), the second event to the source based on the details of the second event type and the publisher.

5. The method as claimed in claim 1, wherein the first event type and the second event type are stored in a storage unit (222).

6. The method (500) as claimed in claim 1, wherein the one or more processors, establishes a communication channel between an inventory manager and the ERM, wherein the communication channel is an interface.

7. The method as claimed in claim 6, wherein the interface is at least one of, an Inventory Manager_Event Manager (IM_EM) interface.

8. A system (108) to manage routing of requests in a network, the system (108) comprising:
an identifying unit (216), configured to, identify, at least one of, a recipient and a first event type from a first event received from a source;
a registering unit (218), configured to, register, at an Event Routing Manager (ERM) (404), the first event by designating at least one of: the source as a subscriber, the recipient as a publisher and storing the first event type of the event;
a routing agent (220), configured to, route, the first event from the ERM (404) to the recipient based on checking details of the first event including at least one of, the source, the publisher and the first event type;
if a second event is received from the recipient in response to routing the first event to the recipient, the identifying unit (216), configured to, identify, at least one of, the recipient and a second event type from the second event;
the registering unit (218), configured to, register, at the ERM (404), the second event by designating at least one of: the recipient as the subscriber, the source as the publisher and storing the second event type of the second event; and
the routing agent (220), configured to, route, the second event from the ERM (404) to the source based on checking details of the second event including at least one of, the publisher and the second event type.

9. The system (108) as claimed in claim 8, wherein the source is at least one of, a microservice.

10. The system (108) as claimed in claim 8, wherein the routing agent (220), routes, the first event from the ERM to the recipient by at least one of:
checking, if the first event type includes a first keyword as per the registered first event at the ERM (404);
checking, the details of the publisher from the first event as per the registered first event at the ERM (404); and
routing, the first event to the recipient based on the details of at least one of the first event type and the publisher.

11. The system (108) as claimed in claim 8, wherein the routing agent (220), routes, the second event from the ERM (404) to the source by:
checking, if the second event type includes a second keyword as per the registered second event at the ERM (404);
checking, the details of the publisher from the second event as per the registered second event at the ERM (404); and
routing, the second event to the source based on the details of the second event type and the publisher.

12. The system (108) as claimed in claim 8, wherein the first event type and the second event type are stored in a storage unit (222).

13. The system (108) as claimed in claim 8, wherein a communication channel is established between an inventory manager and the ERM (404), wherein the communication channel is an interface.

14. The system (108) as claimed in claim 13, wherein the interface is at least one of, an Inventory Manager_Event Manager (IM_EM) interface.