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
SYSTEMS AND METHODS FOR EVENT ROUTING MANAGEMENT
2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India
3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[0002] The present disclosure relates generally to the field of telecommunication systems. More particularly, the present disclosure relates to systems and methods for event routing management.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The term “Event” refers to an operation or occurrence or change in state within a network or its components that can trigger responses, alerts, or actions.
[0005] The term “Event Routing Manager” refers to an element in event-driven system where events need to be delivered from event sources to the appropriate event consumers or downstream services.
[0006] The term “Routing” refers to a process of determining the path that data packets take as they travel from a source to a destination across the network.
[0007] The term “Dynamic Routing” refers to a network routing that automatically adjusts the routing based on changing requirements.
[0008] The term “Error handling” refers to the process of detecting, managing, and recovering from errors that occur during data transmission across the network.
[0009] The term “Service Discovery” refers to the process of dynamically locating and routing events to the appropriate service instances.
[0010] The term “Hypertext Transfer Protocol (HTTP) request” refers to a request sent by a client (such as a web browser or application) to a web server to request specific resources or perform certain actions.
[0011] The term “Management and Orchestration (MANO) framework” refers to a component of the network to manage and orchestrate network services and network resources efficiently.
[0012] The term “Microservices” refers to a collection of independently deployable services of an application that communicate over the network.
[0013] The term “Publisher Microservices” refers to components or services associated with the MANO framework that produce and send messages or events to a messaging system. The publisher microservices are responsible for generating and transmitting data to a system that manages message distribution, where the data can be consumed by other components known as subscriber microservices.
[0014] The term “Subscriber microservices” or “Consumer Microservices” refers to components or services associated with the MANO framework that receive and process messages or events sent by the publisher microservices. Subscriber microservices are responsible for consuming the data published to a messaging system.
[0015] The term “Routing events” refers to the process of directing events or messages from their source to the appropriate destination or destinations based on certain criteria or rules.
[0016] The term “Retry mechanism” refers to a mechanism used to handle and recover from failures by automatically attempting to resend or re-execute a network operation or data transmission.
[0017] The term “Acknowledgment (or ACK)” refers to a signal or message sent by a recipient to confirm the receipt and processing of an event or message.
[0018] The term “Network failure” refers to a situation where the network or a portion of the network becomes non-operational or experiences significant degradation, preventing it from providing its intended services or connectivity. Network failures can disrupt communication, affect data transmission, and impact the overall performance and reliability of the network.
[0019] The term “Predefined time interval” refers to a time period that can be set or adjusted by users or administrators to control various network operations, processes, or behaviors. The predefined time interval determines how often specific actions occur, how frequently certain operations are performed, or how long certain timeouts or delays last.
[0020] The term “Event tracing” refers to the process of monitoring, recording, and analyzing events or occurrences within the system, application, or network to gain insights into its behavior, performance, and issues. It involves capturing detailed information about events as they happen and providing mechanisms to trace the sequence and impact of these events over time.
[0021] The term “Network latency” refers to a time delay experienced in transmitting data between two points in a network. It encompasses various delays such as propagation, transmission, processing, and queuing delays.
[0022] The term “Duplicate messages” refers to instances where the same message or data packet is transmitted more than once between a sender (e.g., publisher microservice) and a receiver (e.g., subscriber microservice).
[0023] The term “Event type” refers to an event with particular characteristics and implications for network management, monitoring, or operations.
[0024] These definitions are in addition to those expressed in the art.
BACKGROUND
[0025] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0026] Currently, an open-source distributed event streaming platform is employed for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. The open-source distributed event streaming platform is based on a publish/subscribe (Pub/Sub) microservice architecture and consists of a network of machines, such as brokers. Each open-source distributed event streaming platform hosts a set of partitions and manages incoming requests for writing new events to these partitions or reading events from them. In open-source distributed event streaming platform, consumers or subscriber microservices consume the events or messages from the open-source distributed event streaming platform brokers. These consumers/subscriber microservices poll for new events. An event routing manager (ERM) routes the events to the consumers/subscriber microservices as soon as the events arrive from the publisher microservices. However, in the open-source distributed event streaming platform, the ERM lacks the capability to inform the open-source distributed event streaming platform about the success or failure of event delivery to the consumers/subscriber microservices. In the open-source distributed event streaming platform, the open-source distributed event streaming platform stores events for a configurable time, regardless of whether the consumers/subscriber microservices consume the events or not. This may lead to the consumers/subscriber microservices receiving duplicate messages.
SUMMARY
[0027] In an exemplary embodiment, a system for routing a plurality of events between a plurality of publisher microservices and a plurality of subscriber microservices is described. The system comprises a receiving unit configured to receive an event from at least one publisher microservice of the plurality of publisher microservices. A detecting unit is configured to detect whether the received event is valid. Upon detecting that the received event is valid, the sending unit is configured to send the received event to at least one subscriber microservice selected from the plurality of subscriber microservices based on an event type. A processing unit is configured to store the event in a database if the event is not received by the at least one subscriber microservice. The processing unit is configured to retry delivering the event to the at least one subscriber microservice after a predefined time interval. The processing unit is configured to archive the event for tracing failure of the event responsive to determining that the at least one subscriber microservice did not receive the event after the predefined time interval.
[0028] In some embodiments, the plurality of publisher microservices and the plurality of subscriber microservices are associated with a Management and orchestration (MANO) framework.
[0029] In some embodiments, the detection unit is configured to detect the received event is valid based on checking whether name of the received event exists in the database or not.
[0030] In some embodiments, the receiving unit is configured to receive an acknowledgement from the at least one subscriber microservice. The acknowledgment comprises at least one of a success response or failure response of the reception of the event.
[0031] In some embodiments, upon receiving the acknowledgment from the at least one subscriber microservice, the sending unit is configured to send a delivery report to the at least one publisher microservice. The delivery report comprises an indication of successful reception of the event or failure in the event reception by the at least one subscriber microservice.
[0032] In some embodiments, in response to detecting that the received event is not valid, the sending unit is configured to send an error report to the at least one publisher microservice in response to detecting that the received event is not valid. The error report comprises an indication that the received event does not exist in the database.
[0033] In some embodiments, the processing unit is further configured to store the event in the database when the at least one subscriber microservice fails to receive the event.
[0034] In yet another exemplary embodiment, a method for routing a plurality of events between a plurality of publisher microservices and a plurality of subscriber microservices is described. The method comprises receiving, by a receiving unit, an event from at least one publisher microservice of the plurality of publisher microservices and detecting, by a detection unit, whether the received event is valid. The method comprises upon detecting that the received event is valid, sending, by a sending unit, the received event to at least one subscriber microservice selected from the plurality of subscriber microservices based on event type. The method further comprises storing, by a processing unit, the event in a database if the event is not received by the at least one subscriber microservice and retrying, by the processing unit, delivering the event to the at least one subscriber microservice after a predefined time interval. The method comprises archiving, by the processing unit, the event responsive to determining that the at least one subscriber microservice did not receive the event after the predefined time interval.
[0035] In some embodiments, the plurality of publisher microservices and the plurality of subscriber microservices are associated with a Management and orchestration (MANO) framework.
[0036] In some embodiments, the method comprises detecting, by the detection unit, that the received event is valid based on checking whether name of the received event exists in the database or not.
[0037] In some embodiment, the method further comprises receiving, by the receiving unit, an acknowledgement from the at least one subscriber microservice. The acknowledgment comprises at least one of a success response or failure response of the reception of the event.
[0038] In some embodiments, the method comprises upon receiving the acknowledgment from the at least one subscriber microservice, sending, by the sending unit, a delivery report to the at least one publisher microservice. The delivery report comprises an indication of successful reception of the event or failure in the event sending by the at least one subscriber microservice.
[0039] In some embodiments, the method further comprises sending, by the sending unit, an error report to the at least one publisher microservice in response to detecting that the received event is not valid. The error report comprises an indication that the received event does not exist in the database.
[0040] In some embodiments, the method comprises storing, by the processing unit, the event in the database when the at least one subscriber microservice fails to receive the event.
[0041] In some embodiments, a user equipment (UE) is communicatively coupled with a system. The system is configured to receive a connection request from the UE. The system is configured to send an acknowledgment of the connection request to the UE. The UE is configured to transmit a plurality of signals in response to the connection request. The system is configured for routing a plurality of events between a plurality of publisher microservices and a plurality of subscriber microservices.
[0042] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVE
[0043] Some of the objective of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0044] An objective of the present disclosure is to provide a system and a method for executing an efficient routing mechanism for the routing and distribution of events among the publisher microservices and subscriber microservices.
[0045] Another objective of the present disclosure is to provide a system and a method that efficiently distributes events to multiple consumers or services based on event types.
[0046] Yet another objective of the present disclosure is to provide an event routing manager (ERM) for adding or removing the event producers (or publisher microservices) and consumers (or subscriber microservices) without affecting the overall functionality or performance of the system. In this way, the ERM allows the system to scale independently. The ERM supports dynamic routing, enabling the system to adapt to changing requirements.
[0047] Yet another objective of the present disclosure is to enable the ERM to handle errors or failures during event routing. The ERM may perform a retry process and ensure reliable delivery of events even in the presence of transient failures or network issues.
[0048] Yet another objective of the present disclosure is to facilitate the ERM to incorporate service discovery mechanisms to dynamically locate and route events to appropriate service instances.
[0049] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0050] 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.
[0051] FIG. 1 illustrates an exemplary network architecture for implementing an event routing manager (ERM), in accordance with an embodiment of the present disclosure.
[0052] FIG. 2A illustrates an exemplary system architecture of a system for implementing the ERM between a plurality of publisher microservices and a plurality of subscriber microservices, in accordance with an embodiment of the present disclosure.
[0053] FIG. 2B illustrates an exemplary block diagram of the system for implementing the ERM, in accordance with an embodiment of the present disclosure.
[0054] FIG. 3 illustrates an exemplary flow diagram describing event routing between the plurality of publisher microservices and the plurality of subscriber microservices through the ERM, in accordance with an embodiment of the present disclosure.
[0055] FIG. 4 illustrates an exemplary flow diagram of a method for routing the plurality of events between the plurality of publisher microservices and the plurality of subscriber microservices, in accordance with an embodiment of the present disclosure.
[0056] FIG. 5 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented.
[0057] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 Network architecture
102 User
104 User Equipment (UE)
106 Network
108 System
110 Event Routing Manager (ERM)
200A System architecture
202-1 First publisher microservice (MS)1
202-2 Second publisher microservice MS2
206-1 First subscriber microservice MS1
206-2 Second subscriber microservice MS2
206-3 Third subscriber microservice MS3
200B Block Diagram
212 Processor
214 Memory
216 Interface(s)
218 Receiving Unit
220 Sending Unit
222 Processing Unit
224 Detection Unit
228 Database
300 Flow Diagram
400 Flow Diagram
500 Computer System
510 External Storage Device
520 Bus
530 Main Memory
540 Read-Only Memory
550 Mass Storage Device
560 Communication Ports
570 Processor
DETAILED DESCRIPTION
[0058] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0059] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0060] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0061] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0062] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0063] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0064] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0065] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0066] Currently, an open-source distributed event streaming platform is employed for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. The open-source distributed event streaming platform is based on a publish/subscribe (Pub/Sub) microservice architecture and consists of a network of machines, such as brokers. Each open-source distributed event streaming platform hosts a set of partitions and manages incoming requests for writing new events to these partitions or reading events from them. In open-source distributed event streaming platform, consumers or subscriber microservices consume the events or messages from the open-source distributed event streaming platform brokers. These consumers/subscriber microservices poll for new events. An event routing manager (ERM) routes the events to the consumers/subscriber microservices as soon as the events arrive from the publisher microservices. However, in the open-source distributed event streaming platform, the ERM lacks the capability to inform the open-source distributed event streaming platform about the success or failure of event delivery to the consumers/subscriber microservices. In the open-source distributed event streaming platform, the open-source distributed event streaming platform stores events for a configurable time, regardless of whether the consumers/subscriber microservices consume the events or not. This may lead to the consumers/subscriber microservices receiving duplicate messages.
[0067] Accordingly, there is a need for systems and methods for efficient event routing management.
[0068] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a system and a method for informing an event producer/publisher microservice about success or failure of event delivery to a consumer/subscriber microservice through an event routing manager (ERM). According to aspects of the present disclosure, a producer/publisher microservice may send an event to the ERM. Upon receiving the event, the ERM may send an acknowledgment to the producer/publisher microservice. The ERM may then deliver the received event to a consumer/subscriber microservice. After successfully delivering the event to the consumer/subscriber microservice, the ERM may send a delivery report to the producer/publisher microservice indicating that the ERM successfully delivered the event to the consumer/subscriber microservice. Further, if the event cannot be delivered to the consumer/subscriber microservice for some reason, the ERM may notify the producer/publisher microservice about the event delivery failure. According to an aspect, the ERM may not store the event when the subscriber microservice successfully receives the event. The ERM stores the event in case the subscriber microservice fails to receive the event. Furthermore, the ERM supports retry mechanism in case of event delivery failure. The ERM retries to deliver the event to the consumer/subscriber microservice for certain predefined time interval (i.e., configurable time interval). After the predefined time interval, the ERM archives the event, where a user can trace all failure events.
[0069] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0070] FIG. 1 illustrates an exemplary network architecture for implementing an event routing manager (ERM), in accordance with an embodiment of the present disclosure.
[0071] As illustrated in FIG. 1, one or more user equipments (104-1, 104-2…104-N) may be connected to the system (108) through a network (106). A person of ordinary skill in the art will understand that the one or more user equipments (104-1, 104-2…104-N) may be collectively referred as user equipments (104) and individually referred as a user equipment (104). One or more users (102-1, 102-2…102-N) may provide one or more requests to the system (108). A person of ordinary skill in the art will understand that the one or more users (102-1, 102-2…102-N) may be collectively referred as users (102) and individually referred as a user (102). Further, the user equipments (104) may also be referred as a user equipment (UE) (104) or as UEs (104) throughout the disclosure.
[0072] In an embodiment, the UE (104) may include, but not be limited to, a mobile, a laptop, etc. Further, the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, audio aid, microphone, or keyboard. Furthermore, the UE (104) may include a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, and a mainframe computer. Additionally, input devices for receiving input from the user (102) such as a touchpad, touch-enabled screen, electronic pen, and the like may be used. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.
[0073] Referring to FIG. 1, the network (106) may include at least one of a Fifth Generation (5G) network, Sixth Generation (6G) network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0074] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a 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.
[0075] In an embodiment, the network architecture (100) further includes a system (108). The system (108) includes an event routing manager (ERM) (110). In an aspect, the ERM (110) may provide a centralized and efficient mechanism for event routing and distribution in event-driven architectures. In an implementation, the ERM (110) is combination of event-based architecture and publisher microservice/subscriber microservice architecture. The ERM (110) may combine event-based messaging with a publisher microservice/subscriber microservice (pub/sub) pattern. The ERM (110) may act as a router and is responsible for receiving events (for example, HTTP requests), extracting information about the events, and routing the events to the relevant services based on the information extracted about the events (such as event names). In an implementation, since the ERM (110) is an event-based architecture that is based on pub/sub pattern, the ERM (110) may support sequence order of events as well as parallel events. In an implementation, the ERM (110) may deliver events to a consumer based on priority.
[0076] In an embodiment, the UE (104) is communicatively coupled with the system (108). The system (108) may receive a connection request from the UE (104). The system (108) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. The system (108) may be configured for routing a plurality of events between a plurality of publisher microservices and a plurality of subscriber microservices.
[0077] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
[0078] Referring to FIG. 2A, an exemplary system architecture (200A) of the system (108) for implementing the ERM (110) between a plurality of publishers microservices (MS) (202) and a plurality of subscribers microservices (MS) (206) associated with a Management and orchestration (MANO) framework, in accordance with an embodiment of the present disclosure.
[0079] In an aspect, the plurality of publisher microservices and the plurality of subscriber microservices are associated with a Management and Orchestration (MANO) framework. The microservices refer to software components in the MANO framework designed to perform specific functions corresponding to management and orchestration.
[0080] According to aspects of the present disclosure, the plurality of publisher microservices (202) may be associated with a plurality of microservices (MS), for example, a first publisher microservice MS1 (202-1) and a second publisher microservice MS2 (202-2). Also, the plurality of subscriber microservices (206) may be associated with a plurality of microservices (MS), for example, a first subscriber microservice MS1 (206-1), a second subscriber microservice MS2 (206-2), and a third subscriber microservice MS3 (206-3). A person of ordinary skill in the art will understand that the one or more publisher microservices (202-1, 202-2) may be collectively referred as publisher microservices (202) and individually referred as a publisher microservice (202). Further, a person of ordinary skill in the art will understand that the one or more subscriber microservices (206-1, 206-2, 206-3) may be collectively referred to as subscriber microservices (206) and individually referred to as a subscriber microservice (206).
[0081] In an example, in a cellular network, the plurality of publisher microservices includes, but is not limited to, a user equipment (UE) event microservice, a network performance monitoring microservice, a resource allocation microservice, a network slice management microservice, a fault management microservice, etc. The plurality of subscriber microservices includes, but is not limited to, a user activity monitoring microservice, a network optimization service, a billing and usage analytics microservice, an incident response microservice.
[0082] The plurality of publisher microservices (MSs) (202) may be configured to register a plurality of events and then publish (or send) the registered events to the ERM (110). In an example, the first publisher MS1 (202-1) may send Event 1 to the ERM (110) and the second publisher MS2 (202-2) may send Event 2 to the ERM (110). The ERM (110) may send an acknowledgment to both the first publisher MS1 (202-1) and the second publisher MS2 (202-2) on successfully receiving the events from the first publisher MS1 (202-1) and the second publisher MS2 (202-2). Further, the ERM (110) is configured to extract information about the received events. The extracted event information may assist the ERM (110) to identify the type of events. In an aspect, the event types refer to specific categories of events that can occur. The events are used to communicate changes in the state of functions, resources, or services. In an example, the event types in the cellular network may include, but not limited to, call setup and termination event, location update, network congestion alert, handover, authentication and authorization events, roaming events, message delivery events, etc.
[0083] The ERM (110) may then fetch a list of all subscriber microservices. The ERM (110) may select one or more subscriber microservices from the list of all subscriber microservices based on the extracted information about the received events. In an implementation, the ERM (110) may send or route the events to the one or more subscriber microservices based on the event types. In an example, the ERM (110) may send the Event 1 to the first subscriber MS1 (206-1) and the second subscriber MS2 (206-2). The first subscriber MS1 (206-1) and the second subscriber MS2 (206-2) may subscribe to Event 1. Furthermore, the ERM (110) may send the Event 2 to the third subscriber MS3 (206-3). The third subscriber MS3 (206-3) may subscribe to the Event 2. Accordingly, the ERM (110) is configured to route the received events from the publisher microservices to the subscriber microservices according to the event types.
[0084] After receiving corresponding events from the ERM (110), each of the first subscriber MS1 (206-1), the second subscriber MS2 (206-2), and the third subscriber MS3 (206-3) may be configured to send an acknowledgement to the ERM (110), where the acknowledgement is indicative of successful event delivery. The ERM (110) may then send the delivery report of events to the corresponding publisher MS. For example, the ERM (110) may send a delivery report to the first publisher MS1 (202-1). The delivery report sent to the first publisher MS1 (202-1) may indicate that Event 1 was successfully delivered to the first subscriber MS1 (206-1) and the second subscriber MS1 (206-2). Also, the ERM (110) may send a delivery report to the second publisher MS1 (202-2). The delivery report sent to the second publisher MS1 (202-2) may indicate that Event 2 was successfully delivered to the third subscriber MS1 (206-3). Accordingly, the ERM (110) is configured to support acknowledgment report as well as delivery report. Therefore, the ERM (110) ensures the end-to-end delivery of events from the publisher microservices to the subscriber microservices.
[0085] In an implementation, if the ERM (110) does not receive an acknowledgement from any of the first subscriber MS1 (206-1), the second subscriber MS1 (206-2), the third subscriber MS1 (206-3), the ERM (110) may perform retry mechanism. In an example, if the ERM (110) does not receive an acknowledgement from the first subscriber MS1 (206-1), then the ERM (110) may store the Event 1 in a database. Further, the ERM (110) may retry to deliver the Event 1 to the first subscriber MS1 (206-1) for predefined time interval. The ERM (110) checks whether the retry for event delivery is successful after the predefined time interval. If the ERM (110) determines that the retry is successful, then the ERM (110) may send a delivery report to the first publisher MS1 (202-1). The delivery report may be indicative of successful reception of the event by the first subscriber MS1 (206-1). When the ERM (110) detects that the retry has failed, the ERM (110) may archive the event. The ERM (110) may allow users to use the stored event for tracing failure events. In this way, the ERM (110) is configured to store the event in the database only in case when the subscriber microservice fails to receive the event. In this way, the ERM (110) provides a centralized and efficient mechanism for event routing and distribution in the event-driven architectures.
[0086] Although FIG. 2A shows exemplary components of the system architecture (200A), in other embodiments, the system architecture (200A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2A. Additionally, or alternatively, one or more components of the system architecture (200A) may perform functions described as being performed by one or more other components of the system architecture (200A).
[0087] FIG. 2B illustrates an exemplary block diagram (200B) of the system (108) for implementing the ERM (110), in accordance with an embodiment of the present disclosure.
[0088] Referring to FIG. 2B, in an embodiment, the system (108) may include one or more processor(s) (212). The one or more processor(s) (212) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (212) may be configured to fetch and execute computer-readable instructions stored in a memory (214) of the system (108). The memory (214) 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 (214) may comprise any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0089] In an embodiment, the system (108) may include an interface(s) (216). The interface(s) (216) may comprise a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) (216) may facilitate communication through the system (108). The interface(s) (216) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a database (228).
[0090] In an aspect, the system (108) comprises the event routing manager (ERM) (110). The ERM (110) comprises a receiving unit (218), a sending unit (220), a processing unit (222), and a detection unit (224).
[0091] The receiving unit (218) is configured to receive an event from the publisher MS (202). In an aspect, the publisher MS (202) generates the event based on a specific trigger corresponding to occurrence of condition. In an example, a user device logging to a network. The publisher MS (e.g., user equipment (UE) event microservice) generates an event (e.g., user device registered).
[0092] The detection unit (224) is configured to detect whether the received event is valid. In an aspect, the detection unit (224) is configured to detect that the received event is valid based on checking whether name of the received event exists in the database (228). Upon detecting that name of the received event exists in the database, then the received event is valid. If name of the received event does not exist in the database (228), then the received event is not valid. For example, the detection unit (224) detects whether the received event (e.g., user device registered) exists in the database or not. If the received event (e.g., user device registered) exists in the database (228), then the received event is valid. Otherwise, the received event is not valid.
[0093] In response to detecting that the received event is not valid, the sending unit (220) is configured to send an error report to the publisher microservice (202). The error report comprises an indication that the received event does not exist in the database (228). In an example, the received event (e.g., user device registered) does not exist in the database (228), then the error report (indicating user device registered event does not exist on the database) is sends to the publisher microservice (e.g., UE event microservice).
[0094] Upon detecting that the received event is valid, the sending unit (220) is configured to send the received event to the subscriber microservice (e.g., subscriber microservice (206-1)) selected from the plurality of subscriber microservices (206-1, 206-2, 206-3). The subscriber microservice is selected based on event type. The selection of the subscriber microservices based on event types is done to deliver relevant information and ensure efficient network operation. In an example, upon detecting that the received event is valid (i.e., the received event (e.g., user device registered) exists in the database (228)), the event type (e.g., user activity) is determined. Based on the determined event type, the received event is sent to the corresponding subscriber microservice (e.g., User activity monitoring service).
[0095] The receiving unit (218) is configured to receive an acknowledgement from the subscriber microservice (206-1). The acknowledgement comprises at least one of a success response or failure response of the reception of the event by the subscriber microservice. In an example, the subscriber microservice (e.g., User activity monitoring service) successfully receives the event, then the subscriber microservice (e.g., User activity monitoring service) sends the success response indicating successful delivery of the event. Further, if the subscriber microservice (e.g., User activity monitoring service) does not receive the event, then the subscriber microservice (e.g., User activity monitoring service) sends the failure response indicating failure in the reception of the event.
[0096] Upon receiving the acknowledgment from the at least one subscriber microservice (206), the sending unit (220) is configured to send a delivery report to the publisher (202). The delivery report is indicative of the successful reception of the event or failure in event reception by the subscriber microservice (206-1).
[0097] If the event is not received by the subscriber microservice (206-1), the processing unit (222) is configured to store the event in the memory (214) or the database (228). In an example, if the subscriber microservice (e.g., User activity monitoring service) does not receive the event, then the event (e.g., user device registered) is stored in the database (228).
[0098] The processing unit (222) is configured to retry delivering the event to the subscriber microservice (206-1) after a predefined time interval. The processing unit (222) is configured to determine whether the subscriber microservice (206-1) received the event after the predefined time interval. The processing unit (222) is configured to archive the event for tracing failure of event responsive to determining that the subscriber microservice (206-1) did not receive the event after the predefined time interval. In an example, the processing unit (222) retries delivering the event (e.g., user device registered) after the predefined time interval (e.g., 10 minutes). After delivering the event again after the predefined time interval (e.g., 10 minutes), the processing unit (222) determines whether the event is received by the subscriber microservice (e.g., User activity monitoring service). If the event is not received by the subscriber microservice (e.g., User activity monitoring service), the processing unit (222) retries sending the event for a predefined number of times (e.g., 5 times). Suppose the subscriber microservice (e.g., User activity monitoring service) does not receive the event after the predefined number of times (e.g., 5 times). In that case, the processing unit (222) archives the event to determine a reason for the failure of event reception. In an example, the reason for the failure includes, but is not limited to, a network connectivity issue, device configuration errors, downtimes, timeout, etc.
[0099] In an aspect, the ERM (110) supports acknowledgement i.e., when the publisher microservice (202) sends an event to the ERM (110), the publisher microservice (202) receives an acknowledgment (ACK) from the ERM (110) that it has received the event. Further, after successfully delivering the event to consumer/subscriber microservice (206), the ERM (110) delivers a delivery report to the publisher microservice (206) that the ERM (110) has successfully delivered the event to the consumer/subscriber microservice (206). If the event is not delivered to the consumer/subscriber microservice (206) for some reasons. The publisher microservice (202) may receive negative acknowledgment from the consumer/subscriber microservice (206). In this way, the publisher microservice (202) receives the success as well as failure delivery report from the ERM (110).
[00100] In an aspect, the ERM (110) is configured to handle the plurality of events either in one of sequence order or in parallel. Handling of events in sequence order refers to the process of managing and processing events in the sequence order. For example, events such as call initiation, handoff, and call termination must be processed in sequence. Call setup events are handled first, followed by handoff or termination events, to ensure that the call is fully established before other processes occur. Handling events in the correct sequence is essential for the reliable operation of the network. By ensuring that events are processed in the proper order, networks can maintain efficient operations, provide high-quality service, and deliver a seamless user experience. Further, handling of events in parallel in the network involves managing multiple events simultaneously. For example, when a user is simultaneously involved in a call while also using mobile data for browsing, both events (call setup and data transmission) are handled in parallel without interference. Managing simultaneous events is essential for enhancing network efficiency and providing a smooth user experience.
[00101] In an aspect, the ERM (110) is configured to deliver the plurality of events based on priority of the plurality of events. In an implementation, the ERM (110) manages and prioritizes the transmission of events based on priority (e.g., importance or urgency). For example, highest priority events include natural disasters, severe weather warnings, etc., medium priority events include network maintenance, service interruptions, etc., and low priority events include promotional messages, routine update, etc. The emergency alerts are delivered to the subscriber microservices (206) quickly and reliably even in situations where the network (106) might be congested or experiencing high traffic.
[00102] In an aspect, the ERM (110) is configured to store the event in the database (228) only when the subscriber microservice (206) fails to receive the event. The ERM (110) does not store event when all subscriber microservices (206) received events successfully. The ERM (110) only stores event when the event cannot be delivered to one or more subscriber microservice (206). In this way, the ERM (110) stores event in the database (228) only in case of one or more subscriber microservice (206) will fail to receive event. This improves efficiency of the system (108).
[00103] In an aspect, the database (228) is configured to store program instructions. The database (228) is configured to store the event received from the receiving unit (218). The program instructions include a program that implements a method routing a plurality of events between a plurality of publisher microservices (202) and a plurality of subscriber microservices (206) by an event routing manager (ERM) (110) in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification. The database (228) may be configured to store the events, delivery reports, error reports, and acknowledgments. The database (228) may include any computer-readable medium known in the art including, for example, volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM) and/or nonvolatile memory, such as Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[00104] Although FIG. 2B shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2B. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).
[00105] FIG. 3 illustrates an exemplary flow diagram (300) describing event routing between the producer/publisher microservice (202) and the consumer/subscriber microservice (206) associated with the MANO framework through the ERM (110), in accordance with an embodiment of the present disclosure.
[00106] At step (302) of the flow diagram (300), the ERM (110) may receive an event from the publisher microservice (202). The ERM (110) may extract event information from the received event. The event information may include, but is not limited to, event type, event name, event identifier (ID), event status, timestamp, etc. For example, event type – subscriber location, event name – subscriber location update, User ID = 202, Old Location = Latitude:32.2128, Longitude:64.0960, New Location = Latitude:40.7128, Longitude:74.0060, Timestamp = 2024-02-08T20:00:00Z.
[00107] At step (304) of the flow diagram (300), the ERM (110) may check whether the received event exists or not. The ERM (110) checks if the extracted event information of the received event matches with event data in the database (228). If the extracted event information of the received event matches with event data in the database (228), then the ERM (110) determines that event exists. If the extracted event information of the received event does not match with event data in the database (228), then the ERM (110) determines that event does not exist. If the ERM (110) determines that the event does not exist, the flow diagram (300) may proceed to step (306) (i.e., ‘No’ branch). If the ERM (110) determines that the event exists, the flow diagram (300) may proceed to step (308) (i.e., ‘Yes’ branch).
[00108] At step (306) of the flow diagram (300), the ERM (110) may send an error to the publisher microservice (202) if the event does not exist. Further, when the ERM (110) detects that the event does not exist, then that event may be added to the ERM (110) at runtime.
[00109] At step (308) of the flow diagram (300), when the ERM (110) detects that the event exists, the ERM (110) may send the received event to an appropriate subscriber microservice (206) from a plurality of subscriber microservices (206). In order to send the received event to an appropriate subscriber microservice (206), the ERM (110) may fetch a list of all the subscriber microservices (206). The ERM (110) may then extract information about the event and send the event to the appropriate subscriber microservice (206) from the list of the subscriber microservices (206) according to the event information. In an implementation, the ERM (110) is also configured to send an acknowledgement to the publisher microservice (202) after receiving the event from the publisher microservice (202). After sending the event to the subscriber microservice (206), the ERM (110) may wait for an acknowledgment from the subscriber microservice (206) about the event delivery.
[00110] At step (310) of the flow diagram (300), the ERM (110) may check whether the event has been successfully received or not by the subscriber microservice (206). In an implementation, the ERM (110) may check if an acknowledgement about the success event delivery is received from the subscriber microservice (206). If the ERM (110) receives an acknowledgement from the subscriber microservice (206), the flow diagram (300) may proceed to step (312) (i.e., ‘Yes’ branch). If the ERM (110) does not receive an acknowledgement from the subscriber microservice (206), the flow diagram (300) may proceed to step (314) (i.e., ‘No’ branch).
[00111] At step (312) of the flow diagram (300), when the ERM (110) receives the acknowledgement from the subscriber microservice (206) about the successful reception of the event, the ERM (110) may send delivery report to the publisher microservice (206). The delivery report may be indicative of successful reception of the event by the subscriber microservice (206).
[00112] At step (314) of the flow diagram (300), when the ERM (110) does not receive the acknowledgement from the subscriber microservice (206), i.e., the subscriber microservice (206) is unable to receive the event (for example, due to the network failure), the ERM (110) may store the event in the database (228) and retry sending the event to the subscriber microservice (206) for a predefined time interval.
[00113] At step (316) of the flow diagram (300), the ERM (110) checks whether the retry for event delivery for the predefined time interval is successful or not. If the ERM (110) determines that the retry is successful, then the flow diagram (300) may proceed to step (318) (i.e., ‘Yes’ branch). If the ERM (110) determines that the retry has failed, the flow diagram (300) may proceed to step (320) (i.e., ‘No’ branch).
[00114] At step (318) of the flow diagram (300), the ERM (110) may send a delivery report to the publisher microservice (202). The delivery report may be indicative of successful reception of the event by the subscriber microservice (206).
[00115] At step (320) of the flow diagram (300), when the ERM (110) detects that the retry has failed, the ERM (110) may archive the event. The ERM (110) may allow users to use the stored event for tracing failure events. In this way, the ERM (110) is configured to store the event in the database (228) only in case when the subscriber microservice (206) fails to receive the event.
[00116] The ERM (110) may provide mechanism to handle errors or failures during the event routing. The ERM (110) also includes retry mechanism and ensures reliable delivery of events even during transient failures or network issues. This improves dynamic routing of events, error handling of events and providing reliability and maintainability of the system.
[00117] FIG. 4 illustrates an exemplary flow diagram of a method (400) for routing a plurality of events between a plurality of publisher microservices (202) and a plurality of subscriber microservices (206) associated with the MANO framework by the ERM (110), in accordance with an embodiment of the present disclosure.
[00118] At step 402, the method (400) includes receiving an event from at least one publisher microservice (202). In an aspect, the publisher microservices (202) generate the event based on specific triggers (e.g., network status changes, user activity, or resource allocation updates). The publisher microservices (202) send the generated event to the ERM (110). The ERM (110) receives the event from the at least one publisher microservice (202). In an aspect, the publisher microservices (202) send the events for maintaining network operations (e.g., network management, performance monitoring, session management, billing and charging, security, authentication and authorization, etc.).
[00119] At step 404, the method (400) includes detecting whether the received event is valid. The ERM (110) detects whether the received event is valid or not. In an aspect, the ERM (110) detects that the received event is valid based on checking whether name of the received event exists in the database (228) or not. If the name of the received event exists in the database (228), then the received event is valid. Otherwise, the received event is invalid.
[00120] At step 406, the method (400) includes, upon detecting that the received event is valid, sending the received event to at least one subscriber microservice (206) selected from the plurality of subscriber microservices (206). The at least one subscriber microservice is selected based on event type. In an aspect, upon detecting that the received event is valid, the ERM (110) processes the received event to determine the event name. The ERM (110) then determines at least one subscriber microservice from the plurality of subscriber microservices (206) based on the determined event name. further, upon receiving the event from the ERM (110), the at least one subscriber microservice (206) sends an acknowledgement to the ERM (110). The acknowledgement includes a success response or a failure response. Upon successfully receiving the event, the at least one subscriber microservice (206) sends the acknowledgement as the success response. Otherwise, the at least one subscriber microservice (206) sends the acknowledgement as the failure response. The ERM (110) sends the received acknowledgement to the at least one publisher microservice to inform about reception of the event (e.g., successful reception of the event or failure of the event) by the at least one subscriber microservice (206).
[00121] The method (400) includes sending a delivery report to the at least one publisher microservice (202). The delivery report comprises an indication of successful reception of the event by the at least one subscriber microservice (206). In an aspect, when the ERM (110) receives the acknowledgement as the success response from the at least one subscriber microservice (206), the ERM (110) sends the delivery report (to indicate successful reception of the event by the at least one subscriber microservice (206)) to the at least one publisher microservice (202).
[00122] The method (400) includes, in response to detecting that the received event is not valid, sending an error to the at least one publisher microservice (202). The error report comprises an indication that the received event does not exist in the database (228). In an aspect, upon receiving the event from the at least one publisher microservice, the ERM (110) searches the name of the received event in the database (228). If the name of the received event does not exist in the database (228), then the received event is not valid. The ERM (110) sends the error to the at least one publisher microservice (202) to indicate that the received event does not exist in the database (228).
[00123] At step 408, the method (400) includes if the event is not received by the at least one subscriber microservice (206), storing the event in the database (228). In an aspect, upon receiving the acknowledgement as the failure response from the at least one subscriber microservice (206), the ERM (110) determines that the event is not received by the at least one subscriber microservice (206). The ERM (110) stores the event in the database (228). In an aspect, the ERM (110) stores the event in the database (228) only if it is detected that the event is not received by the at least one subscriber microservice (206).
[00124] At step 410, the method (400) includes retrying delivering the event to the at least one subscriber microservice (206) after a predefined time interval. On detecting that the event is not received by the at least one subscriber microservice (206), the ERM (110) is retried to deliver the event to the at least one subscriber microservice (206) for the predefined time interval. For example, the publisher microservice (202) (e.g., a service provider) sends a notification about a billing issue to subscriber microservices (206) (e.g., billing microservice). Some notifications fail to be delivered successfully due to network issues, server unavailability, or subscriber device problems. The publisher microservice (202) retries sending the event to the subscriber microservice (206) after the predefined time interval. The predefined time interval (e.g., after every 30 minutes for 5 retries). The publisher microservice (202) retries sending the event 5 times after every 30 minutes.
[00125] At step 412, the method (400) includes archiving the event for tracing failure of the event responsive to determining that the at least one subscriber microservice (206) did not receive the event after the predefined time interval. The method (400) includes determining whether the at least one subscriber microservice (206) received the event after the predefined time interval. While retrying to send the event to the at least one subscriber microservice (206), the ERM (110) determines whether the at least one subscriber microservice (206) has received the event after the predefined time interval. For example, while retrying to send the event to the at least one subscriber microservice (206), the ERM (110) determines whether the at least one subscriber microservice (206) has received the event after 30 minutes. Further, on determining that the at least one subscriber microservice (206) did not receive the event after the predefined time interval (i.e., determining that the subscriber microservice die not receive the event after 5 retries), the event is archived for tracing failure of event. For example, on determining that the at least one subscriber microservice (206) did not receive the event after 30 minutes for 5 times, the ERM (110) archives the event to trace failure of the event. Failure of the event may be due to, but is not limited to, factors such as signal interference, network congestion, network outages, configuration issues, signal quality issues, handover issues, and authentication or authorization problems, etc.
[00126] FIG. 5 illustrates an exemplary computer system (500) in which or with which embodiments of the present disclosure may be implemented.
[00127] As shown in FIG. 5, the computer system (500) may include an external storage device (510), a bus (520), a main memory (530), a read-only memory (540), a mass storage device (550), communication port(s) (560), and a processor (570). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (570) may include various modules associated with embodiments of the present disclosure. The communication port(s) (560) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) (560) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.
[00128] The main memory (530) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (540) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor (570). The mass storage device (550) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage device (550) includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks.
[00129] The bus (520) communicatively couples the processor (570) with the other memory, storage, and communication blocks. The bus (520) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (570) to the computer system.
[00130] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (520) to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (560). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[00131] The exemplary computer system (500) is configured to execute a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for routing a plurality of events between a plurality of publisher microservices and a plurality of subscriber microservices by an event routing manager (ERM) is described. The method comprises receiving an event from a publisher microservice and detecting whether the received event is valid or not. The method comprises in response to detecting that the received event is valid, sending the received event to a subscriber microservice selected from the plurality of subscriber microservices based on event type. The method comprises sending a delivery report to the publisher microservice. The method further comprises sending an error report to the publisher microservice in response to detecting that the received event is not valid. The method further comprises storing the event in the database if the event is not received by the subscriber microservice and retrying delivering the event to the subscriber microservice after a predefined time interval. The method comprises archiving the event for tracing failure of the event responsive to determining that the subscriber microservice did not receive the event after the predefined time interval.
[00132] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
[00133] The present disclosure provides technical advancement related to event routing management. This advancement addresses the limitations of existing solutions by providing an event routing manager (ERM) to deliver events from event publisher microservices to appropriate event subscriber microservices or downstream services. The ERM stores an event in the database only in case when one or more subscriber microservices fail to receive event. The ERM does not store event when all subscriber microservices receive the event successfully. This offers significant improvements in system efficiency. The disclosed invention handle errors or failures during the event routing. The ERM also includes retry mechanism and ensures the reliable delivery of events even during transient failures or network issues. This improves dynamic routing of events and error handling of events.
ADVANTAGES OF THE INVENTION
[00134] As is evident from the above, the present disclosure provides a technically advanced solution by providing a system and a method for efficient event routing management. The ERM offers advantages such as decoupling, scalability, dynamic routing, error handling, visibility, and contributing to the overall flexibility, reliability, and maintainability of the system. The ERM receives the events from the publisher microservices, processes the events, and sends the events to the subscriber microservices. The ERM then informs the event publisher microservices about success and/or failure of event delivery to the subscriber microservices. The ERM supports acknowledgement report and delivery report when publisher microservice service sends an event to the ERM. The publisher microservice receives an acknowledgment from the ERM that it has received that event. After successfully delivering the event to subscriber microservice, the ERM delivers a delivery report to publisher microservice that the ERM has successfully delivered the event to the subscriber microservice. If the event cannot be delivered to the subscriber microservice for some reasons, the ERM may notify the publisher microservice about delivery failure.
[00135] The ERM is configured to store an event in the database only in case when one or more subscriber microservices fail to receive event. The ERM does not store event when all subscriber microservices receive the event successfully. As a result, overall efficiency of the system is improved. The ERM provides a mechanism to handle errors or failures during the event routing. The ERM also includes retry mechanism and ensures the reliable delivery of events even during transient failures or network issues. This improves dynamic routing of events and error handling of events. The ERM may incorporate event discovery mechanisms to dynamically locate and route events to the appropriate service instances, thereby enabling the system to adapt to the changing requirements. The ERM is configured to add or remove the event producers and consumers without affecting the overall functionality or performance of the system. In this way, the ERM may allow the system to scale independently.
[00136] The ERM may deliver events from event publisher microservices to appropriate event subscriber microservices or downstream services in an event-driven system. In an example, the ERM plays a vital role in providing interface between publisher microservices and subscriber microservices for event routing. The ERM may efficiently distribute events to multiple subscriber microservices, or services based on events (for example, events may include customer account creation, customer address changing, and customer invoice paid events). Further, the ERM may incorporate event discovery mechanisms to dynamically locate and route events to the appropriate service instances.
,CLAIMS:CLAIMS
We claim:
1. A system (108) for routing a plurality of events between a plurality of publisher microservices (202) and a plurality of subscriber microservices (206), the system (108) comprising:
a receiving unit (218) configured to receive an event from at least one publisher microservice (202) of the plurality of publisher microservices (202);
a detection unit (224) configured to detect whether the received event is valid;
upon detecting that the received event is valid, a sending unit (220) configured to send the received event to at least one subscriber microservice (206) selected from the plurality of subscriber microservices (206) based on an event type; and
a processing unit (222) configured to:
store the event in a database (228) if the event is not received by the at least one subscriber microservice (206);
retry delivering the event to the at least one subscriber microservice (206) after a predefined time interval; and
archive the event responsive to determining that the at least one subscriber microservice (206) did not receive the event after the predefined time interval.

2. The system (108) as claimed in claim 1, wherein the plurality of publisher microservices (202) and the plurality of subscriber microservices (206) are associated with a Management and orchestration (MANO) framework.

3. The system (108) as claimed in claim 1, wherein the detection unit (224) is configured to detect that the received event is valid based on checking whether name of the received event exists in the database (228) or not.

4. The system (108) as claimed in claim 1, wherein the receiving unit (218) configured to receive an acknowledgement from the at least one subscriber microservice (206), wherein the acknowledgment comprises at least one of a success response or failure response of the reception of the event.

5. The system (108) as claimed in claim 4, wherein upon receiving the acknowledgment from the at least one subscriber microservice (206), the sending unit (220) is configured to send a delivery report to the at least one publisher microservice (202), wherein the delivery report comprises an indication of successful reception of the event or failure in event reception by the at least one subscriber microservice (206).

6. The system (108) as claimed in claim 1, wherein in response to detecting that the received event is not valid, the sending unit (220) is configured to send an error report to the at least one publisher microservice (202), wherein the error report comprises an indication that the received event does not exist in the database (228).

7. The system (108) as claimed in claim 1, wherein the processing unit (222) is configured to store the event in the database (228) when the at least one subscriber microservice (206) fails to receive the event.

8. A method (400) for routing a plurality of events between a plurality of publisher microservices (202) and a plurality of subscriber microservices (206), the method (400) comprising:
receiving (402), by a receiving unit (218), an event from at least one publisher microservice (202) of the plurality of publisher microservices (202);
detecting (404), by a detection unit (224), whether the received event is valid;
upon detecting that the received event is valid, sending (406), by a sending unit (220), the received event to at least one subscriber microservice (206) selected from the plurality of subscriber microservices (206) based on an event type;
storing (408), by a processing unit (222), the event in a database (228) if the event is not received by the at least one subscriber microservice (206);
retrying (410), by the processing unit (222), delivering the event to the at least one subscriber microservice (206) after a predefined time interval; and
archiving (412), by the processing unit (222), the event responsive to determining that the at least one subscriber microservice (206) did not receive the event after the predefined time interval.

9. The method (400) as claimed in claim 8, wherein the plurality of publisher microservices (202) and the plurality of subscriber microservices (206) are associated with a Management and orchestration (MANO) framework.

10. The method (400) as claimed in claim 8 further comprising detecting, by the detection unit (224), that the received event is valid based on checking whether name of the received event exists in the database (228) or not.

11. The method (400) as claimed in claim 8 further comprising: receiving, by the receiving unit (218), an acknowledgement from the at least one subscriber microservice (206), wherein the acknowledgment comprises at least one of a success response or failure response of the reception of the event.

12. The method (400) as claimed in claim 11 further comprising: upon receiving the acknowledgment from the at least one subscriber microservice (206), sending, by the sending unit (220), a delivery report to the at least one publisher microservice (202), wherein the delivery report comprises an indication of successful reception of the event or failure in the event sending by the at least one subscriber microservice (206).

13. The method (400) as claimed in claim 8 further comprising in response to detecting that the received event is not valid, sending, by the sending unit (220), an error report to the at least one publisher microservice (202), wherein the error report comprises an indication that the received event does not exist in the database (228).

14. The method (400) as claimed in claim 8 further comprising storing, by the processing unit (222), the event in the database (228) when the at least one subscriber microservice (206) fails to receive the event.

15. A user equipment (UE) (104) communicatively coupled with a system (108), the coupling comprises steps of:
receiving, by the system (108), a connection request;
sending, by the system (108), an acknowledgment of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein the system (108) is configured for routing a plurality of events between a plurality of publisher microservices (202) and a plurality of subscriber microservices (206) as claimed in claim 1.