FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR ROUTING AN EVENT REQUEST”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.
2
METHOD AND SYSTEM FOR ROUTING AN EVENT REQUEST
FIELD OF INVENTION
[0001]
Embodiments of the present disclosure generally relate to methods and systems of 5 information technology and network performance management. More particularly, embodiments of the present disclosure relate to a method and system for routing an event request.
BACKGROUND 10
[0002]
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 15 present disclosure, and not as an admission of prior art.
[0003]
The existing system faces a critical challenge in efficiently managing job/task creation and scheduling across various microservices through the Platform Schedulers & Cron Jobs (PSC). While the PSC serves as a centralized platform, enabling this functionality, the system 20 encounters difficulties in seamlessly routing requests to and from the required microservices via the event routing manager (ERM). The PS_EM interface plays a pivotal role in handling incoming and outgoing requests through a Publisher and Subscriber policy, however, ensuring smooth communication remains a concern. Additionally, the registration of standard platform events by each microservice with the ERM leads to potential complications, especially in cases 25 where multiple subscribers are involved for a single event. This issue hinders the timely dissemination of notifications to the concerned parties, impacting overall system performance. Furthermore, the extensive interaction of the PSC with various microservices, including Capacity Monitoring Manager (CP), Backup and Upgrade Manager (BR), Microservice Audit Editor (AU), Physical and Virtual Inventory Manager (IM), and Edge Load Balancer (LB), 30 introduces additional complexities that need to be addressed for enhanced operational efficiency.
3
[0004]
Therefore, there are a number of limitations to the existing solutions and in order to overcome these and such other limitations of the known solutions it is necessary to provide an efficient solution for routing an event request.
SUMMARY 5
[0005]
This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
10
[0006]
An aspect of the present disclosure may relate to a method for routing an event request. The method includes receiving, by a transceiver unit, at an event routing manager (ERM) module, a request for publishing an event, wherein the request comprises a source service and a destination service for the event. Next, the method includes detecting, by a processing unit at the ERM module, the source service and the destination service. Thereafter, the method 15 includes routing, by the transceiver unit by the ERM module, the request from source service to the destination service.
[0007]
In an exemplary aspect of the present disclosure, wherein, prior to receiving, by the transceiver unit, at the ERM module, the request for publishing an event, the method comprises 20 registering, by the processing unit at the ERM module, the source service and the destination service of the event to be published.
[0008]
In an exemplary aspect of the present disclosure, the method further comprises registering, by the processing unit at the ERM module, a primary service as the source service 25 and a secondary service as the destination service for the event to be published.
[0009]
In an exemplary aspect of the present disclosure, the primary service corresponds to at least a Platform Schedulers & Cron Jobs (PSC) module, and wherein the secondary service corresponds to one or more other services. 30
[00010]
In an exemplary aspect of the present disclosure, the PSC module and the ERM module are communicatively coupled using a PS_EM interface.
4
[00011]
In an exemplary aspect of the present disclosure, the method further comprises registering, by the processing unit at the ERM module, the secondary service as the source service and the primary service as the destination service for the event to be published.
[00012]
In an exemplary aspect of the present disclosure, wherein in response to the 5 source service being the secondary service, and the destination service being the primary service, the method comprises routing, by the transceiver unit at the ERM module, the request from the secondary service to the primary service.
[00013]
In an exemplary aspect of the present disclosure, wherein the event comprises 10 at least one of an event type and an eventAck type.
[00014]
In an exemplary aspect of the present disclosure, wherein, in response to the source service being a primary service, and the destination service being a secondary service, the method comprises routing, by the transceiver unit at the ERM module, the request from the 15 primary service to the secondary service.
[00015]
In an exemplary aspect of the present disclosure, wherein the request for publishing the event further comprises an event name and an event type, and wherein the method further comprises detecting, by the processing unit at the ERM module, the event name 20 and the event type from the request; and routing, by the transceiver unit at the ERM module, the request based on the detected event name and event type.
[00016]
Another aspect of the present disclosure may relate to a system for routing an event request. The system comprises an event routing manager (ERM) module. The event 25 routing manager (ERM) module comprises a transceiver unit configured to receive a request for publishing an event, wherein the request comprises a source service and a destination service for the event; a processing unit configured to detect the source service and the destination service; and the transceiver unit further configured to route the request from source service to the destination service. 30
[00017]
Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instructions for routing an event request, the instructions include executable code which, when executed by one or more units of a system,
5
causes: a transceiver unit of the system to receive a request for publishing an event, wherein
the request comprises a source service and a destination service for the event; a processing unit of the system to detect the source service and the destination service; and the transceiver unit of the system to further route the request from source service to the destination service.
5
[00018]
Yet another aspect of the present disclosure may relate to a user equipment (UE). The UE comprises a processor configured to transmit, to an event routing manager (ERM) module, a request for publishing an event, wherein the request comprises a source service and a destination service for the event, wherein for routing an event request, process comprises: detecting, by a processing unit at the ERM module, the source service and the 10 destination service, and routing, by the transceiver unit by the ERM module, the request from source service to the destination service.
OBJECTS OF THE DISCLOSURE
15
[00019]
This section is provided to introduce certain objects and aspects of the present invention in a simplified form that are further described below in the description. In order to overcome at least a few problems associated with the known solutions as provided in the previous section, an object of the present invention is to substantially reduce the limitations and drawbacks of the prior arts as described hereinabove. 20
[00020]
An object of the invention is to provide a solution for automatically routing a request to a publisher and a subscriber.
[00021]
Another object of the invention is to provide a solution that detects a first event 25 comprising a registration of the PSC as a publisher and a microservice as the subscriber and a second event comprising a registration of the PSC as a subscriber and a microservice as the publisher.
[00022]
Yet another object of the present invention is to provide a solution that 30 automatically detects in at least one of the first event and the second event at least one of a name of the publisher and a type of the event.
DESCRIPTION OF THE DRAWINGS
6
[00023]
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 5 clearly illustrating the principles of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such 10 components.
[00024]
FIG. 1 illustrates an exemplary block diagram of a management and orchestration (MANO) architecture.
15
[00025]
FIG. 2 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.
[00026]
FIG. 3 illustrates an exemplary block diagram of a system for routing an event 20 request, in accordance with exemplary implementations of the present disclosure.
[00027]
FIG. 4 illustrates a method flow diagram for routing an event request, in accordance with exemplary implementations of the present disclosure.
25
[00028]
FIG. 5 illustrates an exemplary system architecture of a platform scheduler and cron jobs (PSC/PS) microservice, in accordance with exemplary implementations of the present disclosure.
[00029]
The foregoing shall be more apparent from the following more detailed 30 description of the disclosure.
DETAILED DESCRIPTION
7
[00030]
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 may each be used independently of one another or with any combination of other features. An individual feature 5 may not address any of the problems discussed above or might address only some of the problems discussed above.
[00031]
The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing 10 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.
15
[00032]
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 skills in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. 20
[00033]
Also, it is noted that individual embodiments may be described as a process which 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 may be performed in parallel or concurrently. In addition, the order of 25 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.
[00034]
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 30 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
8
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—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
5
[00035]
As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a 10 microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor. 15
[00036]
As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic and/or computing device or equipment, capable of implementing 20 the features of the present disclosure. The user equipment/device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a 25 processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.
[00037]
As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form 30 readable by a computer or similar machine. For example, a computer-readable medium includes read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices or other types of machine-
9
accessible storage media. The storage unit stores at least the data that may be required by one
or more units of the system to perform their respective functions.
[00038]
As used herein “interface” or “user interface” refers to a shared boundary across which two or more separate components of a system exchange information or data. The 5 interface may also be referred to as a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.
[00039]
All modules, units, components used herein, unless explicitly excluded herein, 10 may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc. 15
[00040]
As used herein the transceiver unit includes at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units/components within the system and/or connected with the system. 20
[00041]
As used herein, Policy Execution Engine (PEEGN) module provides a network function virtualisation (NFV) software defined network (SDN) platform functionality to support dynamic requirements of resource management and network service orchestration in the virtualized network. 25
[00042]
As used herein, Physical and Virtual Inventory Manager (PVIM) module maintains the inventory and its resources. After getting a request to reserve resources from PEEGN, PVIM adds up the resources consumed by a particular network function as used resources and removes them from free resources. Further, the PVIM updates this in any 30 unstructured or non-relational database (such as NoSQL database).
[00043]
As discussed in the background section, the current known solutions have several shortcomings. The present disclosure aims to overcome the above-mentioned and other
10
existing problems in this field of technology by providing
a method and system for routing an event request.
[00044]
The foregoing shall be more apparent from the following more detailed description of the disclosure. 5
[00045]
Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[00046]
FIG. 1 illustrates an exemplary block diagram representation of a management 10 and orchestration (MANO) architecture/ platform [100], in accordance with exemplary implementation of the present disclosure. The MANO platform [100] may be developed for managing telecom cloud infrastructure automatically, managing design or deployment design, managing instantiation of network node(s)/ service(s) etc. The MANO platform [100] deploys the network node(s) in the form of Virtual Network Function (VNF) and Cloud-native/ 15 Container Network Function (CNF). The system as provided by the present disclosure may comprise one or more components of the MANO platform [100]. The MANO platform [100] may be used to auto-instantiate the VNFs into the corresponding environment of the present disclosure so that it could help in onboarding other vendor(s) CNFs and VNFs to the platform.
20
[00047]
As shown in FIG. 1, the MANO platform [100] comprises a user interface layer [102], a network function virtualization (NFV) and software defined network (SDN) design function module [104], a platform foundation services module [106], platforms core services module [108] and a platform resource adapters and utilities module [112]. All the components are assumed to be connected to each other in a manner as obvious to the person skilled in the 25 art for implementing features of the present disclosure.
[00048]
The NFV and SDN design function module [104] comprises a VNF lifecycle manager (compute) [1042], a VNF catalogue [1044], a network services catalogue [1046], a network slicing and service chaining manager [1048], a physical and virtual resource manager 30 [1050] and a CNF lifecycle manager [1052]. The VNF lifecycle manager (compute) [1042] may be responsible for deciding on which server of the communication network the microservice will be instantiated. The VNF lifecycle manager (compute) [1042] may manage
11
the overall flow of incoming/ outgoing requests during interaction with the user. The VNF
lifecycle manager (compute) [1042] may be responsible for determining which sequence to be followed for executing the process. For e.g. in an AMF network function of the communication network (such as a 5G network), sequence for execution of processes P1 and P2 etc. The VNF catalogue [1044] stores the metadata of all the VNFs (also CNFs in some cases). The network 5 services catalogue [1046] stores the information of the services that need to be run. The network slicing and service chaining manager [1048] manages the slicing (an ordered and connected sequence of network service/ network functions (NFs)) that must be applied to a specific networked data packet. The physical and virtual resource manager [1050] stores the logical and physical inventory of the VNFs. Just like the VNF lifecycle manager (compute) [1042], the 10 CNF lifecycle manager [1052] may be used for the CNFs lifecycle management.
[00049]
The platforms foundation services module [106] comprises a microservices edge load balancer [1062], an identity & access manager [1064], a command line interface (CLI) [1066], a central logging manager [1068], and an event routing manager (ERM) module 15 [1070]. The microservices edge load balancer [1062] may be used for maintaining the load balancing of the request for the services. The identity & access manager [1064] may be used for logging purposes. The command line interface (CLI) [1066] may be used to provide commands to execute certain processes which require changes during the run time. The central logging manager [1068] may be responsible for keeping the logs of every service. These logs 20 are generated by the MANO platform [100]. These logs are used for debugging purposes. The event routing manager (ERM) module [1070] may be responsible for routing the events i.e., the application programming interface (API) hits to the corresponding services. The ERM module [1070] manages the routing of requests between microservices in an event-driven system. When one service (such as publisher) triggers an event, the request is directed by the 25 ERM module [1070] to the target microservice (such as subscriber). The ERM module [1070] enables asynchronous communication, supports fault tolerance such that the tasks are rerouted if a service fails, thus maintaining system reliability and efficiency.
[00050]
The platforms core services module [108] comprises NFV infrastructure 30 monitoring manager [1082], an assure manager [1084], a performance manager [1086], a policy execution engine [1088], a capacity monitoring manager (CMM) [1090], a release management (mgmt.) repository [1092], a configuration manager & GCT [1094], an NFV
12
platform decision analytics
(NPDA) [1096], a platform NoSQL DB [1098]; a platform schedulers and cron jobs [1100], a VNF backup & upgrade manager [1102], a microservice auditor [1104], and a platform operations, administration and maintenance (OAM) module [1106]. The NFV infrastructure monitoring manager [1082] monitors the infrastructure part of the NFs. For e.g., any metrics such as CPU utilization by the VNF. The assure manager [1084] 5 may be responsible for supervising the alarms the vendor may be generating. The performance manager [1086] may be responsible for managing the performance counters. The policy execution engine (PEEGN) [1088] may be responsible for managing all of the policies. The capacity monitoring manager (CMM) [1090] may be responsible for sending the request to the PEEGN [1088]. The release management (mgmt.) repository (RMR) [1092] may be 10 responsible for managing the releases and the images of all of the vendor's network nodes. The configuration manager & (GCT) [1094] manages the configuration and GCT of all the vendors. The NFV platform decision analytics (NPDA) [1096] helps in deciding the priority of using the network resources. It may be further noted that the policy execution engine (PEEGN) [1088], the configuration manager & GCT [1094] and the NPDA [1096] work together. The 15 platform NoSQL DB [1098] may be a database for storing all the inventory (both physical and logical) as well as the metadata of the VNFs and CNF. The platform schedulers and cron jobs [1100] schedules and manages the tasks across various microservices. The PSC [1100] facilitates in automating execution of jobs often based on time interval or based on a triggering event. The PSC [1100] facilitates in dispatching the requests to appropriate microservices, 20 enabling efficient task scheduling and execution.
[00051]
The VNF backup & upgrade manager [1102] takes backup of the images, binaries of the VNFs and the CNFs and produces those backup on demand in case of server failure. The microservice auditor [1104] audits the microservices. For e.g., in a hypothetical 25 case, instances not being instantiated by the MANO platform [100] may be using the network resources. In such cases, the microservice auditor [1104] audits and informs the same so that resources can be released for services running in the MANO platform [100]. The audit assures that the services only run on the MANO platform [100]. The platform operations, administration and maintenance (OAM) module [1106] may be used for newer instances that 30 are spawning. The OAM module [1106] refers to a centralised system that manages the scheduling, execution and monitoring of tasks across various microservices. The OAM module [1106] facilitates efficient task distribution, automates scheduling jobs, and handles administration by tracking task execution and system performance. Additionally, the OAM
13
module [1106] supports maintenance by rerouting tasks in case o
f failures, enhancing the overall resilience and reliability of the system.
[00052]
The platform resource adapters and utilities module [112] further comprises a platform external API adaptor and gateway [1122]; a generic decoder and indexer (XML, CSV, 5 JSON) [1124]; a docker service adaptor [1126]; an OpenStack API adapter [1128]; and a NFV gateway [1130]. The Docker Service Adapter (DSA) is a microservices-based system designed to deploy and manage Container Network Functions (CNFs) and their components (CNFCs) across Docker nodes. It offers REST endpoints for key operations, including uploading container images to a Docker registry, terminating CNFC instances, and creating Docker 10 volumes and networks. CNFs, which are network functions packaged as containers, may consist of multiple CNFCs. The DSA facilitates the deployment, configuration, and management of these components by interacting with Docker's API, ensuring proper setup and scalability within a containerized environment. This approach provides a modular and flexible framework for handling network functions in a virtualized network setup. 15
[00053]
The platform external API adapter and gateway [1122] may be responsible for handling the external services (to the MANO platform [100]) that require the network resources. The generic decoder and indexer (XML, CSV, JSON) [1124] gets directly the data of the vendor system in the XML, CSV, JSON format. The docker service adaptor [1126] may 20 be the interface provided between the telecom cloud and the MANO platform [100] for communication. The OpenStack API adapter [1128] may be used to connect with the virtual machines (VMs). The NFV gateway [1130] may be responsible for providing the path to each service going to/incoming from the MANO platform [100].
25
[00054]
Referring to FIG. 2, an exemplary block diagram of a computing device [200] (also referred herein as a computer system [200]) upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure, is shown. In an implementation, the computing device [200] may also implement a method for routing an event request utilising the system. In another implementation, the 30 computing device [200] itself implements the method for routing an event request using one or more units configured within the computing device [200], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
14
[00055]
The computing device [200] may include a bus [202] or other communication mechanism for communicating information, and a hardware processor [204] coupled with the bus [202] for processing information. The hardware processor [204] may be, for example, a general-purpose microprocessor. The computing device [200] may also include a main memory [206], such as a random-access memory (RAM), or other dynamic storage device, coupled to 5 the bus [202] for storing information and instructions to be executed by the processor [204]. The main memory [206] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor [204]. Such instructions, when stored in non-transitory storage media accessible to the processor [204], render the computing device [200] into a special-purpose machine that is customized to 10 perform the operations specified in the instructions. The computing device [200] further includes a read only memory (ROM) [208] or other static storage device coupled to the bus [202] for storing static information and instructions for the processor [204].
[00056]
A storage device [210], such as a magnetic disk, optical disk, or solid-state drive 15 is provided and coupled to the bus [202] for storing information and instructions. The computing device [200] may be coupled via the bus [202] to a display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device [214], including alphanumeric and other keys, touch screen input means, etc. may be coupled 20 to the bus [202] for communicating information and command selections to the processor [204]. Another type of user input device may be a cursor controller [216], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor [204], and for controlling cursor movement on the display [212]. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a 25 second axis (e.g., y), that allow the device to specify positions in a plane.
[00057]
The computing device [200] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computing device [200] causes or programs the computing 30 device [200] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device [200] in response to the processor [204] executing one or more sequences of one or more instructions contained in the main memory [206]. Such instructions may be read into the main memory [206] from another storage
15
medium, such as the storage device [210]. Execution of the sequences of instructions contained
in the main memory [206] causes the processor [204] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
5
[00058]
The computing device [200] also may include a communication interface [218] coupled to the bus [202]. The communication interface [218] provides a two-way data communication coupling to a network link [220] that is connected to a local network [222]. For example, the communication interface [218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication 10 connection to a corresponding type of telephone line. As another example, the communication interface [218] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [218] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of 15 information.
[00059]
The computing device [200] can send messages and receive data, including program code, through the network(s), the network link [220] and the communication interface [218]. In the Internet example, a server [230] might transmit a requested code for an application 20 program through the Internet [228], the ISP [226], the local network [222], the host [224] and the communication interface [218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage device [210], or other non-volatile storage for later execution.
25
[00060]
Referring to FIG. 3, an exemplary block diagram of a system [300] for routing an event request is shown, in accordance with the exemplary implementations of the present disclosure. The system [300] comprises at least one event routing manager (ERM) module [1070]. The ERM module [1070] comprises at least one transceiver unit [302] and at least one processing unit [304]. Also, all of the components/ units of the system [300] are assumed to be 30 connected to each other unless otherwise indicated below. Also, in FIG. 3 only a few units are shown, however, the system [300] may comprise multiple such units or the system [300] may comprise any such numbers of said units, as required to implement the features of the present
16
disclosure. In an implementation, the system [300] may reside in a server or a network entity.
In yet another implementation, the system [300] may reside partly in the server/ network entity.
[00061]
The system [300] is configured for routing an event request, with the help of the interconnection between the components/units of the system [300]. 5
[00062]
The system [300] comprises a transceiver unit [302]. The transceiver unit [302] at the ERM module [1070] is configured to receive a request for publishing an event. The request may comprise a source service and a destination service for the event. In an exemplary implementation, the service may be a microservice. In an exemplary implementation, the ERM 10 module [1070] via the transceiver unit [302] may route the request for publishing the event to and from at required services or microservices. The event may comprise at least one of an event type and an eventAck type. In an implementation, examples of the event may include, but not limited to, actions such as completion of a scheduled task, initiation of backup process, or occurrence of a system failure. For example, when a microservice completes a data processing 15 job, it can trigger an event that notifies other microservices to begin their tasks, such as sending a report or updating a database. Further, in an example a hypertext transfer protocol (HTTP) request is sent/forwarded to an event routing manager (ERM) module [1070], which routes the event from the publisher (requesting entity) to the relevant subscribers (such as network function orchestrators, storage units, and service adaptors). Additionally, events can include, 20 for example, OTP generation and consumption. For example, ERM module [1070] checks who is the publisher who generates the OTP and then also checks who are the subscribers i.e. which microservice instance consumes the OTP.
[00063]
In an exemplary implementation, the source service and destination service may 25 be such as a platform schedulers & cron jobs (PSC) module and a policy execution engine (PEEGN) module and physical and a virtual inventory manager (PVIM) module.
[00064]
The system [300] further comprises a processing unit [304] at the ERM module [1070]. The processing unit [304] is configured to detect the source service and the destination 30 service. The processing unit [304] is communicatively coupled with the transceiver unit [302]. The processing unit [304] is configured to receive events from the transceiver unit [302].
17
[00065]
The processing unit [304] is configured to detect the source service and destination service based on publisher and subscriber policy implemented at the ERM module [1070]. In an exemplary implementation, prior to receiving the request for publishing the event, the processing unit [304] is configured to register, at the ERM module [300a], the source service and the destination service of the event to be published. Each service or microservice 5 registers its events with the ERM module [1070]. For each event, there can be multiple subscribers. Whenever any event is published, the notifications are sent by the ERM module [1070] to the subscribers informing them of the said event. The processing unit [304] is configured to register a primary service as the source service and a secondary service as the destination service for the event to be published. In an exemplary implementation, the primary 10 service corresponds to at least a platform schedulers & cron jobs (PSC) module and the secondary service corresponds to one or more other services.
[00066]
In an exemplary implementation, if any service sends a request to the PSC module, then that event should be registered in ERM module [1070] with the PSC module as 15 a publisher for that event and other services as a subscriber.
[00067]
In an exemplary implementation, the processing unit [304] is configured to register the secondary service as the source service and the primary service as the destination service for the event to be published at the ERM module [300a]. For example, secondary 20 service such as other services acts as source service and primary service such as PSC module acts as destination service.
[00068]
In an exemplary aspect, one or more other services corresponds to various functionalities within the system that enhance the overall performance and management of 25 network and virtualised resources. The one or more other services can include, but are nor limited only to virtual network function (VNF) lifecycle management, capacity monitoring, and event routing management. For example, VNF lifecycle management oversees creation, scaling, and termination of VNFs such that network services are deployed and maintained efficiently within the system. 30
[00069]
In an exemplary implementation, the capacity monitoring manager as a core service within the system monitors resource utilisation across microservices. In a scenario where traffic to a particular microservice increases, CPM would detect the spike and either
18
allocate more resources to the affected service or notify other services
such as edge load balancer to distribute the load across additional instances of the microservice preventing a system bottleneck. Simultaneously, the ERM module facilitates that all the requests are correctly routed between the source and destination services. If one service instance fails or becomes unresponsive, the ERM dynamically reroutes the request to another available service 5 instance enabling uninterrupted processing of tasks.
[00070]
The transceiver unit [302] at the ERM module [1070] is further configured to route the request from source service to the destination service. In an exemplary implementation, the transceiver unit [302] is configured to route the request based on the 10 detected event name and event type (e.g., event type, eventAck type).
[00071]
In an exemplary implementation, in response to the source service being a primary service, and the destination service being a secondary service the transceiver unit [302] at the ERM module [1070] is configured to route the request from the primary service to the 15 secondary service. For example, the PSC module acts as a source service and other services act as a destination service. The transceiver unit [302] based on the event type routes the request from the PSC module to the other service.
[00072]
In an exemplary implementation, in response to the source service being the 20 secondary service, and the destination service being the primary service the transceiver unit [302] at the ERM module [1070] is configured to route the request from the secondary service to the primary service. For example, other services act as a source service and PSC module acts as a destination service. The transceiver unit [302] based on the eventACK type routes the request from the other service to the PSC module. 25
[00073]
In an exemplary implementation, PS_EM interface communicatively attaches the PSC module and ERM module [1070]. PS_EM interface is used to route all the incoming requests to the PSC module and all the outgoing requests from the PSC module. In an implementation, the PS_EM interface may check in the event for the publisher as a PSC module 30 and if found true, then it will send a request to the PSC module. Further, if the event type is “event” then ERM module [1070] passes the request to the publisher, and if the event type is “eventAck” then ERM passes the request to the subscriber.
19
[00074]
The PS_EM interface can comprise at least one of http and web-socket based connections. In an embodiment, the PS_EM interface is configured to facilitate exchange of information using hypertext transfer protocol (http) rest application programming interface (API). In an embodiment, the http rest API is used in conjunction with JSON and/or XML communication media. In another embodiment, the PS_EM interface is configured to facilitate 5 exchange of information by establishing a web-socket connection between the PSC module, and the ERM module. A web-socket connection may involve establishing a persistent connectivity between the PSC module, and the ERM module. An example of the web-socket based communication includes, without limitation, a transmission control protocol (TCP) connection. In such a connection, information, such as operational status, health, etc. of 10 different components may be exchanged through the interface using a ping-pong based communication.
[00075]
Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various components/units can be implemented 15 interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the 20 intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[00076]
Referring to FIG. 4 an exemplary method [400] flow diagram, for routing an event request, in accordance with exemplary implementations of the present disclosure is 25 shown. In an implementation the method [400] is performed by the system [300]. As shown in FIG. 4, the method [400] starts at step [402].
[00077]
At step [404], the method [400] as disclosed by the present disclosure comprises receiving, by a transceiver unit [302], at an event routing manager (ERM) module [300a], a 30 request for publishing an event, wherein the request comprises a source service and a destination service for the event. The method [400] implemented by the transceiver unit [302] at the ERM module [1070] may receive the request for publishing the event. The request may comprise a source service and a destination service for the event. In an exemplary
20
implementation, the service may be a microservice. In an exemplary implementation, the ERM
module [1070] via the transceiver unit [302] may route the request for publishing the event to and from at required services or microservices. The event may comprise at least one of an event type and an eventAck type. In an implementation, examples of the event may include, but not limited to, actions such as completion of a scheduled task, initiation of backup process, or 5 occurrence of a system failure. For example, when a microservice completes a data processing job, it can trigger an event that notifies other microservices to begin their tasks, such as sending a report or updating database. Further, in an example a hypertext transfer protocol (HTTP) request is sent/forwarded to an event routing manager (ERM) module [1070], which routes the event from the publisher (requesting entity) to the relevant subscribers (such as network 10 function orchestrators, storage units, and service adaptors). Additionally, an Event can include, for example, OTP generation and consumption. For example, ERM module [1070] checks who is the publisher who generates the OTP and then also checks who are the subscribers i.e. which microservice instance consumes the OTP.
15
[00078]
In an exemplary implementation, the source service and destination service may be such as a platform schedulers & cron jobs (PSC) module and a policy execution engine (PEEGN) module and physical and a virtual inventory manager (PVIM) module.
[00079]
Next, at step [406], the method [400] as disclosed by the present disclosure 20 comprises detecting, by a processing unit [304] at the ERM module [300a], the source service and the destination service. The processing unit [304] is communicatively coupled with the transceiver unit [302]. The method [400] may be implemented by the processing unit [304] may receive an event from the transceiver unit [302].
25
[00080]
The processing unit [304] may detect the source service and destination service based on publisher and subscriber policy implemented at the ERM module [1070]. In an exemplary implementation, prior to receiving the request for publishing the event, the processing unit [304] may register, at the ERM module [300a], the source service and the destination service of the event to be published. Each service or microservice registers its 30 events with the ERM module [1070]. For each event, there can be multiple subscribers. Whenever any event is published, the notifications are sent by the ERM module [1070] to the subscribers informing them of the said event. The processing unit [304] may register a primary service as the source service and a secondary service as the destination service for the event to
21
be published. In an exemplary implementation, the primary service corresponds to at least a
platform schedulers & cron jobs (PSC) module and the secondary service corresponds to one or more other services.
[00081]
In an exemplary implementation, if any service sends a request to the PSC 5 module, then that event should be registered in ERM module [1070] with the PSC module as a publisher for that event and other services as a subscriber.
[00082]
In an exemplary implementation, the processing unit [304] may register the secondary service as the source service and the primary service as the destination service for 10 the event to be published at the ERM module [300a]. For example, secondary service such as other services acts as source service and primary service such as PSC module acts as destination service.
[00083]
Next, at step [408], the method [400] as disclosed by the present disclosure 15 comprises routing, by the transceiver unit by the ERM module [300a], the request from source service to the destination service. In an exemplary implementation, the transceiver unit [302] may route the request based on the detected event name and event type (e.g., event type, eventAck type).
20
[00084]
In an exemplary implementation, in response to the source service being a primary service, and the destination service being a secondary service the transceiver unit [302] at the ERM module [1070] may route the request from the primary service to the secondary service. For example, the PSC module acts as a source service and other services act as a destination service. The transceiver unit [302] based on the event type routes the request from 25 the PSC module to the other service. For example, the primary service is platform schedulers and cron jobs, which manages and schedules event requests. For example, when an event like system maintenance or data backup is triggered, the PSC schedules and coordinates the execution of the required tasks. Once the PSC schedules the event, it interacts with one or more other services (such as secondary services), such as a capacity monitoring service or a backup 30 manager service, which performs the specific operations related to the event. In case, the primary service (such as PSC) handles the scheduling and coordinating of the event request, and the secondary services carry out the execution of the tasks, such as monitoring system capacity or performing backups. The secondary services could include additional
22
microservices like a microservice audit editor
or an inventory manager, depending on the type of event being processed.
[00085]
In an exemplary implementation, in response to the source service being the secondary service, and the destination service being the primary service the transceiver unit 5 [302] at the ERM module [1070] may route the request from the secondary service to the primary service. For example, other services act as a source service and PSC module acts as a destination service. The transceiver unit [302] based on the eventACK type routes the request from the other service to the PSC module.
10
[00086]
Thereafter, the method [400] terminates at step [410].
[00087]
Referring to FIG. 5 illustrates an exemplary system architecture [500] of a platform scheduler and cron jobs (PSC/PS) microservice, in accordance with exemplary implementations of the present disclosure. As shown in FIG. 5, the system architecture [500] 15 of PSC microservice comprises a CRON & Schedulers Management [502], a Cron Management [504], a Task Management [506], a FCAP Management [508], an Event Handling [510], a HA and Fault Tolerance [512], a Data Modelling Framework [514], a ES-DB Client [516], a ERM [518], a ES [520], an ELB [522], a VNF manager [524], VM [526] (VM1 [526a],..VMn [526n]), a GUI Interface [528], a CLI interface [530] and EDGE-LB [532]. 20
[00088]
CRON & Schedulers Management [502] is used for scheduling of the cron jobs.
[00089]
Cron Management [504] is used to manage all the active and inactive crons created at PSC end. 25
[00090]
Task Management [506] is used to manage all the active and inactive tasks created at PSC end.
[00091]
FCAP management [508] manages all the counters and alarms created at PSC. 30
[00092]
Event Handling [510] manages all the events between microservices.
23
[00093]
HA and Fault Tolerance [512] handles all the requests if one running instance goes down, then another active instance will complete that request.
[00094]
Data Modelling Framework [514] is used to manage and check incoming and outgoing format data at PSC end. 5
[00095]
ERM [518] is Event Routing Manager which is used to send the requests between publisher microservice to subscriber microservice.
[00096]
ELB [522] is Edge Load balancer which is used to send the requests between 10 the active instances of one microservice to another microservice.
[00097]
ES-DB Client [516] and ES [520] manage task related data for the microservices at PSC end.
15
[00098]
VNF manager [524] manages the one or more VM [526] in a virtual environment in a network functions virtualization (NFV) architecture or virtualized infrastructure.
[00099]
GUI Interface [528] is used to communicate with ERM [518] for sending the 20 request to the microservices.
[000100]
CLI interface [530] is used to communicate or trigger the EDGE-LB [532] for managing the load of the microservices.
25
[000101]
All components and units communicate with each-other for scheduling and managing a task request. In a used case scenario, for example three instances of the PSC microservices, such as, instance 1, instance 2 and instance 3 are available in the network. If one of the instances, such as instance 2 goes down, these components/units switch or schedule the task of the instance 2 to the instance 1 or instance 3 based on predefined criteria and 30 maintain the high availability of the network.
[000102]
The present disclosure may relate to a non-transitory computer-readable storage medium storing instruction for routing an event request which, when executed by one or more
24
units of a system, causes:
a transceiver unit [302] to receive a request for publishing an event, wherein the request comprises a source service and a destination service for the event; a processing unit [304] to detect the source service and the destination service; and the transceiver unit [302] further to route the request from source service to the destination service.
5
[000103]
The present disclosure may relate to a user equipment (UE). The UE comprises a processor configured to: transmit, to an event routing manager (ERM) module [1070], a request for publishing an event, wherein the request comprises a source service and a destination service for the event, wherein for routing an event request, process comprises: detecting, by a processing unit [304] at the ERM module [1070], the source service and the 10 destination service, and routing, by the transceiver unit [302] by the ERM module [1070], the request from source service to the destination service.
[000104]
The present disclosure relates to a method for automatically routing a request to a publisher and a subscriber. More particularly, the novel aspect of the present invention as 15 disclosed in the present disclosure facilitates efficient handling of requests between microservices, ensuring optimal resource allocation and task execution. Additionally, the implementation incorporates a robust fault tolerance mechanism to mitigate the impact of event failures. Operating in a high availability mode, the interface is designed to seamlessly transition requests to the next available platform schedulers & cron jobs (PSC) instance in the event of a 20 failure, thereby ensuring uninterrupted service delivery. Moreover, the innovative design allows for dynamic role-switching between microservices, enabling the PSC module to function as either a source or destination microservice depending on the specific operational context. This adaptable framework provides a versatile and resilient foundation for improved event routing and management within the system, ultimately resulting in a significant technical 25 advancement in the platform's capabilities.
[000105]
As is evident from the above, the present disclosure provides a technically advanced solution for automatically routing a request to a publisher and a subscriber. The present solution offers a notable technical advantage: firstly, it streamlines request routing, 30 providing a seamless and efficient process for directing requests between microservices. This not only optimizes resource allocation but also improves overall system performance. Secondly, the solution simplifies operational tasks related to adding or modifying request subscribers and publishers. This results in a more streamlined and user-friendly process,
25
reducing potential points of error and accelerating system maintenance. Additionally, the
framework promotes request reusability, allowing for the efficient utilization of requests across different contexts. This not only reduces redundancy but also enhances system-wide efficiency. Importantly, the solution is non-service impacting, ensuring that any modifications or updates to the request handling process do not disrupt the normal operation of other services. This 5 guarantees a seamless transition to the improved system, minimizing downtime and maintaining continuity in service delivery.
[000106]
While considerable emphasis has been placed herein on the disclosed embodiments, it will be appreciated that many embodiments can be made and that many 10 changes can be made to the embodiments without departing from the principles of the present disclosure. These and other changes in the embodiments of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.
26
We Claim:
1.
A method for routing an event request, the method comprising:
-
receiving, by a transceiver unit [302], at an event routing manager (ERM) module [1070], a request for publishing an event, wherein the request comprises a source service and a destination service for the event; 5
-
detecting, by a processing unit [304] at the ERM module [1070], the source service and the destination service, and
-
routing, by the transceiver unit at the ERM module [1070], the request from source service to the destination service.
10
2.
The method as claimed in claim 1, wherein, prior to receiving, by the transceiver unit, at the ERM module [1070], the request for publishing an event, the method comprises registering, by the processing unit [304] at the ERM module [1070], the source service and the destination service of the event to be published.
15
3.
The method as claimed in claim 2, wherein the method further comprises registering, by the processing unit [304] at the ERM module [1070], a primary service as the source service and a secondary service as the destination service for the event to be published.
4.
The method as claimed in claim 3, wherein the primary service corresponds to at least a 20 Platform Schedulers & Cron Jobs (PSC) module, and wherein the secondary service corresponds to one or more other services.
5.
The method as claimed in claim 4, wherein the PSC module and the ERM module are communicatively coupled using a PS_EM interface. 25
6.
The method as claimed in claim 3, wherein the method comprises registering, by the processing unit [304] at the ERM module [1070], the secondary service as the source service and the primary service as the destination service for the event to be published.
30
7.
The method as claimed in claim 3, wherein in response to the source service being the secondary service, and the destination service being the primary service, the method
27
comprises routing, by the transceiver unit [302] at the ERM module [1070], the request
from the secondary service to the primary service.
8.
The method as claimed in claim 1, wherein the event comprises at least one of an event type and an eventAck type. 5
9.
The method as claimed in claim 1, wherein, in response to the source service being a primary service, and the destination service being a secondary service, the method comprises routing, by the transceiver unit [302] at the ERM module [1070], the request from the primary service to the secondary service. 10
10.
The method as claimed in claim 1, wherein the request for publishing the event further comprises an event name and an event type, and wherein the method further comprises:
-
detecting, by the processing unit [304] at the ERM module [1070], the event name and the event type from the request; and 15
-
routing, by the transceiver unit [302] at the ERM module [1070], the request based on the detected event name and event type.
11.
A system for routing an event request, the system comprising:
-
an event routing manager (ERM) module [1070] comprising: 20
-
a transceiver unit [302] configured to receive a request for publishing an event, wherein the request comprises a source service and a destination service for the event;
-
a processing unit [304] configured to detect the source service and the destination service; and 25
-
the transceiver unit [302] further configured to route the request from source service to the destination service.
12.
The system as claimed in claim 11, wherein, prior to receiving the request for publishing an event, the processing unit [304] is configured to register, at the ERM 30 module [1070], the source service and the destination service of the event to be published.
28
13.
The system as claimed in claim 12, wherein the processing unit [304] is configured to register, at the ERM module [1070], a primary service as the source service and a secondary service as the destination service for the event to be published.
14.
The system as claimed in claim 13, wherein the primary service corresponds to at least 5 a Platform Schedulers & Cron Jobs (PSC) module, and wherein the secondary service corresponds to one or more other services.
15.
The system as claimed in claim 14, wherein the PSC module and the ERM module are communicatively coupled using a PS_EM interface. 10
16.
The system as claimed in claim 13, wherein the processing unit [304] is configured to register, at the ERM module [1070], the secondary service as the source service and the primary service as the destination service for the event to be published.
15
17.
The system as claimed in claim 13, wherein in response to the source service being the secondary service, and the destination service being the primary service the transceiver unit [302] at the ERM module [1070] is configured to route the request from the secondary service to the primary service.
20
18.
The system as claimed in claim 11, wherein the event comprises at least one of an event type and an eventAck type.
19.
The system as claimed in claim 11, wherein, in response to the source service being a primary service, and the destination service being a secondary service the transceiver unit 25 [302] at the ERM module [1070] is configured to route the request from the primary service to the secondary service.
20.
The system as claimed in claim 11, wherein the request for publishing the event further comprises an event name and an event type, and wherein: 30
-
the processing unit [304] is further configured to detect the event name and the event type from the request; and
-
the transceiver unit [302] is further configured to route the request based on the detected event name and event type.
29
21.
A user equipment (UE) comprising:
-
a processor configured to:
o
transmit, to an event routing manager (ERM) module [1070], a request for publishing an event, wherein the request comprises a source service and a 5 destination service for the event, wherein for routing an event request, process comprises:
▪
detecting, by a processing unit [304] at the ERM module [1070], the source service and the destination service, and
▪
routing, by a transceiver unit [302] at the ERM module [1070], the 10 request from source service to the destination service.