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

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR ESTABLISHING COMMUNICATION BETWEEN USERS AND A MICROSERVICES ARCHITECTURE
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 or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[0002] The present disclosure generally relates to the field of event routing in wireless communication systems. More particularly, the present disclosure relates to a method and a system for establishing communication between users and a microservices architecture.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘Management and Orchestration (MANO) architecture’ used hereinafter in the specification refers to a framework that manages and orchestrates virtualized network functions and resources in a Network Functions Virtualization (NFV) environment.
[0005] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to an intermediary component that facilitates communication between microservices associated with the MANO architecture, routing user requests and responses to network slice allocations, and resource allocation and management.
[0006] The expression ‘event’ used hereinafter in the specification refers to a specific action that can trigger a system to take a particular action. In an example, the event may include user requests, network traffic, system configuration changes, security incidents, and the like.
[0007] The expression ‘microservices’ used hereinafter in the specification refers to a software architecture where an application is structured as a collection of small, independent services that communicate over a network. In the context of the MANO architecture, microservices are used to manage and automate various network functions and services, enabling flexibility, scalability, and efficient resource utilization.
[0008] The expression ‘service discovery mechanism’ used hereinafter in the specification refers to a process or a technique used to locate and route the user requests to appropriate microservices associated with the MANO framework. The service discovery mechanism dynamically identifies available microservices and their instances, using a round-robin technique to efficiently distribute user requests across these microservices.
[0009] The expression ‘publisher’ used hereinafter in the specification refers to an entity that initiates and sends a user request.
[0010] The expression ‘subscriber’ used hereinafter in the specification refers to an entity (e.g., a specific microservice) that receives and responds to the user request.
[0011] These definitions are in addition to those expressed in the art.
BACKGROUND
[0012] 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.
[0013] In modern software architectures, especially microservices, effective event management, and routing are critical for ensuring smooth communication and operational efficiency. As organizations increasingly adopt microservices to build scalable and flexible applications, the complexity of managing interactions among numerous independent microservices and event handling has become a significant challenge. Microservices architecture allows applications to be built as a collection of loosely coupled services, each responsible for a specific functionality. This design promotes agility, scalability, and faster deployment cycles. However, the microservices architecture also challenges inter-microservice communication, especially regarding event-driven interactions.
[0014] Moreover, this architectural shift towards the microservices architecture has also introduced complexities that hinder seamless user (e.g., a developer or an administrator) experiences. This is because the developers and the administrators may have limited control over an individual microservice and also need to rely on different tools and interfaces for each microservice. Due to this, various challenges arise with respect to monitoring, debugging, and troubleshooting any issues that occur due to the failure of any microservice. As many microservices interact with each other, the operational tasks (for example, scaling microservices, deploying updates, and managing configurations) require more manual effort and coordination. This makes microservices architecture complex. Without proper access controls, the microservices may lead to security vulnerabilities or unauthorized changes. To manage the microservices, developers and administrators have to rely on custom scripts and tools. These scripts increase the maintenance burden and may not offer the same level of consistency and reliability.
[0015] Therefore, there is a need to provide a method and a system that facilitates communication between users and microservices associated with microservices architecture.

OBJECTIVES
[0016] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0017] An objective of the present disclosure is to provide a system and a method for facilitating communication between a user and a microservices architecture using an Event routing Manager User Interface (EM_UI) associated with an Event Routing Manager (ERM). The EM_UI receives user requests from a user and directs the user requests based on an event name to an appropriate microservice associated with the microservices architecture.
[0018] An objective of the present disclosure is to enable asynchronous communication between the user and microservices associated with the microservices architecture (e.g., a Management and Orchestration (MANO) architecture) using the EM_UI.
[0019] An objective of the present disclosure is to provide fault tolerance during user request failure using the EM_UI. The EM_UI can route an event during microservice failures, ensuring that user interactions and user requests continue to be processed even when certain microservices are temporarily unavailable.
[0020] An objective of the present disclosure is to provide event-based security. The EM_UI routes authentication and authorization events to relevant microservices to ensure that only authorized users have access to certain features or data associated with the MANO architecture.
[0021] An objective of the present disclosure is to facilitate event-driven communication to update the EM_UI in real-time. For instance, using the EM_UI, the user can enable push notifications to the EM_UI when relevant events occur, ensuring a responsive and interactive user experience.
[0022] An objective of the present disclosure is to facilitate the broadcasting of events to groups of microservices that have subscribed to specific events using the EM_UI. This group-based event routing ensures that all relevant microservices receive the same user request simultaneously, particularly in scenarios where multiple microservices need to respond to the same event.
[0023] An objective of the present disclosure is to enhance scalability by efficiently accommodating a large number of microservices and events using the EM_UI.
[0024] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
SUMMARY
[0025] In an exemplary embodiment, a method for establishing communication between users and a microservices architecture is disclosed. The method includes receiving, by an Event Routing Manager (ERM), at least one user request corresponding to an event from a user, provided using a User Interface (UI). The method includes analyzing, by the ERM, the at least one user request to identify a microservice associated with the microservices architecture. The method includes routing, by the ERM, the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request. The method includes receiving, by the ERM, an event acknowledgement corresponding to the at least one user request associated with the event, from the microservice. The method includes displaying, by the ERM, the event acknowledgement to the user using the UI.
[0026] In an embodiment, the UI corresponds to an Event routing Manager UI (EM_UI).
[0027] In an embodiment, the at least one user request comprises at least one of an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request.
[0028] In an embodiment, the method further includes receiving, by the ERM, at least one input from the user through the UI. The at least one input includes a username and a password. The method further includes authenticating, by the ERM, the at least one input based on an associated authorization information stored in a database. The method further includes granting, by the ERM, an access to the user for sending the at least one user request upon a successful authorization.
[0029] In an embodiment, the microservice associated with the microservice architecture is identified based on a publisher and at least one subscriber.
[0030] In an embodiment, the method to route the at least one user request to the microservice associated with the microservices architecture further includes employing, by the ERM, a load balancing technique to route the at least one user request to the microservice associated with the microservices architecture.
[0031] In an embodiment, the microservice is configured to process the at least one user request and generate the acknowledgement based on the processing of the at least one user request.
[0032] In an embodiment, the event acknowledgement is one of a positive acknowledgement indicating a successful fulfillment of the at least one user request, and a negative acknowledgement indicating a failure in fulfillment of the at least one user request.
[0033] In an embodiment, the method further includes upon receiving the negative acknowledgement, redirecting, by the ERM, the at least one user request to an alternative microservice from a plurality of microservices associated with the microservices architecture.
[0034] In another exemplary embodiment, a system for establishing communication between users and a microservices architecture is disclosed. The system including an Event Routing Manager (ERM) is configured to receive at least one user request corresponding to an event from a user, provided using a User Interface (UI). The ERM is configured to analyze the at least one user request to identify a microservice associated with the microservices architecture. The ERM is configured to route the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request. The ERM is configured to receive an event acknowledgement corresponding to the at least one user request associated with the event, from the microservice. The ERM is configured to display the event acknowledgement to the user using the UI.
[0035] In an embodiment, the UI corresponds to an Event routing Manager UI (EM_UI).
[0036] In an embodiment, the at least one user request includes at least one of an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request.
[0037] In an embodiment, the ERM is further configured to receive at least one input from the user through the UI. The at least one input includes a username and a password. The ERM is further configured to authenticate the at least one input based on an associated authorization information stored in a database. The ERM is further configured to grant an access to the user for sending the at least one user request upon a successful authorization.
[0038] In an embodiment, the microservice associated with the microservice architecture is identified based on a publisher and at least one subscriber.
[0039] In an embodiment, to route the at least one user request to the microservice associated with the microservices architecture, the ERM is further configured to employ a load balancing technique to route the at least one user request to the microservice associated with the microservices architecture.
[0040] In an embodiment, the microservice is configured to process the at least one user request and generate the acknowledgement based on the processing of the at least one user request.
[0041] In an embodiment, the event acknowledgement is one a positive acknowledgement indicating a successful fulfillment of at least one user request and a negative acknowledgement indicating a failure in fulfillment of at least user request.
[0042] In an embodiment, upon receiving the negative acknowledgement, the ERM is further configured to redirect the at least one user request to an alternative microservice from a plurality of microservices associated with the microservices architecture.
[0043] The present disclosure discloses a User Equipment (UE) communicatively coupled with a network. The coupling includes a step of receiving, by the network, a connection request from the UE. The coupling includes a step of sending, by the network, an acknowledgement of the connection request to the UE. The coupling includes a step of transmitting a plurality of signals in response to the connection request. Based on the connection request, establishment of communication between users and a microservices architecture within the network is performed.
[0044] 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.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0045] 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.
[0046] FIG. 1 illustrates an exemplary network architecture for implementing a system for establishing communication between users and a microservices architecture, in accordance with an embodiment of the present disclosure.
[0047] FIG. 2 illustrates an exemplary block diagram of the system configured for establishing communication between the users and the microservices architecture, in accordance with an embodiment of the present disclosure.
[0048] FIG. 3 illustrates an exemplary block diagram depicting communication between a user and a microservice associated with the microservices architecture using an Event Routing Manager (ERM), in accordance with an embodiment of the present disclosure.
[0049] FIG. 4 illustrates an exemplary microservices architecture, in accordance with embodiments of the present disclosure.
[0050] FIG. 5 illustrates an exemplary flow diagram of a method for establishing communication between the users and the microservices architecture, in accordance with embodiments of the present disclosure.
[0051] FIG. 6 illustrates an exemplary process flow depicting a method for establishing communication between the users and the microservices architecture, in accordance with embodiments of the present disclosure.
[0052] FIG. 7 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0053] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 – Network architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
200 – Block Diagram
202 – Processor(s)
204 - Memory
206 – Plurality of Interfaces
208 – Event Routing Manager (ERM)
210 – Database
300 – Exemplary Block Diagram
302 – User Interface (UI)
304 - Microservice
400 – MANO framework architecture
402 - User interface layer
404 - Network Functions Virtualization (NFV) and Software-Defined Networking SDN design function
406 - Platform foundation service
408 – Platform core service
410 – Platform operation, administration, and maintenance manager
412 – Platform resource adapters and utilities
500 – Flow Diagram
600 – Process Flow Diagram
700 – Computer System
710 – External Storage Device
720 – Bus
730 – Main Memory
740 – Read Only Memory
750 – Mass Storage Device
760 – Communication Port
770 – Processor
DETAILED DESCRIPTION
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] As used herein, an "electronic device", or "portable electronic device", or "user device" or "communication device" or "user equipment" or "device" refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[0062] Further, the user device may also comprise a "processor" or "processing unit" includes processing unit, wherein the processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0063] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology is also seen. The development, in this respect, has been incremental in the order of Second Generation (2G), Third Generation (3G), Fourth generation (4G), and now Fifth Generation (5G), and more such generations are expected to continue in the forthcoming time.
[0064] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0065] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when a Second Generation (2G) technology was introduced. A 3G technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. A 4G technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, the 5G technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. A Sixth Generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way of connecting and interacting with technology.
[0066] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0067] Embodiments herein relate to a method for establishing communication between users and a microservices architecture. The microservices architecture may correspond to a Management and Orchestration (MANO) architecture. In some embodiments, the microservices architecture may correspond to a Network Functions Virtualization (NFV) - Software-Defined Networking (SDN) architecture. The ERM may be configured to establish the communication between the users and the microservices architecture. In particular, the method includes receiving at least one user request corresponding to an event from a user, provided using a User Interface (UI). The UI may correspond to an Event routing Manager UI (EM_UI). The at least one user request includes at least one of an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request. The method further includes analyzing the at least one user request to identify a microservice associated with the microservices architecture. The method further includes routing the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request. The method further includes receiving an event acknowledgement corresponding to the at least one user request associated with the event from the microservice. The method further includes displaying the event acknowledgement to the user using the UI.
[0068] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0069] FIG. 1 illustrates an exemplary network architecture 100 of a system 108 for establishing communication between the users and the microservices architecture, in accordance with an embodiment of the present disclosure. The microservices architecture may correspond to a Management and Orchestration (MANO) architecture. In some embodiments, the microservices architecture may correspond to Network Functions Virtualization (NFV) - Software-Defined Networking (SDN) architecture. The system 108 may include an Event Routing Manager (ERM). The ERM may be configured to establish the communication between the users and the microservices architecture. As illustrated in FIG. 1, the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2…104-N associated with one or more users 102-1, 102-2…102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2…102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2…104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, any number of the UE 104 may be included without departing from the scope of the ongoing description.
[0070] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users 102 and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0071] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. 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, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.
[0072] In FIG. 1, the UE 104 may communicate with the system 108 through the network 106. In particular, the UE 104 may be communicatively coupled with the network 106. The coupling including steps of receiving, by the network 106, a connection request from the UE 104. Upon receiving the connection request, the coupling including steps of sending, by the network 106, an acknowledgment of the connection request to the UE 104. Further, the coupling including steps of transmitting a plurality of signals in response to the connection request. The plurality of signals is responsible for communicating with the system 108 to establish the communications between the users and microservices architecture within the network 106.
[0073] 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 the RAN, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0074] 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.
[0075] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for establishing the communication between the users and the microservices architecture, in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1. The microservices architecture may correspond to the MANO architecture.
[0076] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 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) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.
[0077] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 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, an ERM 208 and a database 210. The ERM 208 may be configured to establish the communication between the users and the MANO architecture (microservices architecture).
[0078] In an embodiment, the ERM 208 is configured to receive at least one user request corresponding to an event from a user. The user may provide the at least one user request using a User Interface (UI). The user may be, for example, a developer or an administrator. The UI may correspond to an Event routing Manager User Interface (EM_UI). The EM_UI is used to accept the at least one user request received from the user for resource creation, modification, and decommissioning of microservices through each microservice lifecycle. The user can easily start, stop, scale, or update any microservice as required by sending the at least one user request to the ERM 208 using the EM_UI, ensuring efficient resource management and adaptability to changing demands. Examples of the at least one user request may include, but are not limited to, an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request.
[0079] Upon receiving the at least one user request, the ERM 208 is configured to analyze the at least one user request to identify a microservice associated with the MANO architecture. The microservice associated with the microservice architecture is identified based on a publisher and at least one subscriber. The publisher and the at least one subscriber may be configured with a Hypertext Transfer Protocol (HTTP) header. The HTTP header may be included within the at least one user request. The publisher may correspond to an entity (e.g., the EM_UI) that initiates and sends the at least one user request. The subscriber may correspond to an entity (e.g., a specific microservice) that receives and responds to the at least one user request. The HTTP header may include metadata or routing information that helps identify an appropriate publisher and a subscriber for a given user request. To identify the microservice, the ERM 208 may use publishers and subscribes mapping, and the routing information included in the HTTP header.
[0080] Upon identifying the microservice, the ERM 208 may route the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request. Further, based on the processing, the ERM 208 may be configured to receive an event acknowledgement corresponding to the at least one user request associated with the event from the microservice. The event acknowledgement may be one of a positive acknowledgement indicating a successful fulfillment of the at least one user request and a negative acknowledgement indicating a failure to fulfill the at least one user request. Upon receiving the event acknowledgement, the ERM 208 is configured to display the event acknowledgement to the user using the UI. This complete method performed by the ERM 208 in conjunction with the processor 202 for establishing the communication between the user and the MANO architecture is further explained in detail in FIGS. 3 – 6.
[0081] In an embodiment, the system 108 may include the processor 202 that may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 202. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 202 may be processor-executable instructions stored on a non-transitory machine-readable storage medium. The hardware for the processor 202 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processor 202. In such examples, the system 108 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system 108 and the processing resource. In other examples, the processor 202 may be implemented by electronic circuitry.
[0082] In an embodiment, the system 108 may include a database 210 that includes data (e.g., the at least one user request, the identified microservice, the event acknowledgement, the publishers and subscribers mapping, a plurality of HTTP headers, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor 202 or the ERM 208.
[0083] FIG. 3 illustrates an exemplary block diagram 300 depicting communication between a user and a microservice associated with the microservices architecture using an ERM (i.e., the ERM 208), in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with FIGS. 1 and 2. The microservices architecture may correspond to the MANO architecture.
[0084] In FIG. 3, a UI 302, the ERM 208, the database 210, and a microservice 304 are depicted. The UI 302 may correspond to the EM_UI. In an embodiment, the UI 302 may be part of the system 108, which includes the ERM 208. In another embodiment, the UI 302 may be a Graphical User Interface (GUI) of a user device (e.g., the UE 104) associated with the user. The user device may be configured to communicate with the ERM 208 using the network 106. Initially, the user may provide at least one user input to the ERM 208 using the UI 302. The user may be the developer or the administrator. The at least one user input may include a username and a password. In some embodiments, the at least user input may be a voice input, a facial gesture, a fingerprint, and the like. The at least one user input may be used to authenticate the user to ensure that only an authorized user can access certain features or data within the UI 302. Upon receiving the at least one user input, the ERM 208 may be configured to authenticate the at least one input based on an associated authorization information stored in the database 210. The associated authorization information may be obtained while registering the user with the MANO architecture. In order to authenticate the user, the associated authorization information may be retrieved from the database 210. Further, the associated authorization information may be matched with the at least one user input to validate the user. If the associated authorization information matches with the at least one user input, then the authentication of the user may be a successful authentication. Further, upon successful authentication, the user may be granted an access for sending the at least one user request to the ERM 208. In some embodiments, if the associated authorization information does not match with the at least one user input, then the authentication of the user may be an unsuccessful authentication. In this embodiment, the user may be restricted from sending the at least one user request to the ERM 208. In some embodiments, the UI 302 is configured to route authentication and authorization events associated with the user to a relevant microservice to ensure that only authorized users have access to certain features or data within the UI.
[0085] Once the user is successfully authenticated, at step 306, the user is configured to send the at least one user request (depicted as a UI event request) corresponding to the event to the ERM 208 using the UI 302. Further, upon receiving the UI event request, the ERM 208 is configured to analyze the UI event request to identify a relevant microservice, i.e., a microservice 304 associated with the MANO architecture to process the UI event request. The microservice 304 may be determined based on a publisher and at least one subscriber. The publisher and at least one subscriber may be identified based on an HTTP header included within the UI event request. The publisher may correspond to the UI 302. The subscriber may correspond to the microservice 304. The HTTP header may include information, i.e., a publisher Identifier (ID), a subscriber ID, and an event name. Further, based on the information included in the HTTP header, the ERM 208 is configured to retrieve data provisioned within the database 210. The data, for example, may include publishers and subscriber mapping, description of various events and actions associated with the events, and routing rules for routing the UI event request to an appropriate microservice, i.e., the microservice 304.
[0086] Further, at step 308, the ERM 208 may route the UI event request to the microservice 304 to process the UI event request. The UI event request may be routed by the ERM 208 to the microservice 304 by employing a load balancing technique (e.g., a round-robin load balancing technique). The round-robin load balancing technique is applied by the ERM 208 to evenly distribute incoming user requests, i.e., UI event requests across multiple instances of the microservice 304. Further, the microservice 304 is configured to process the UI event request to generate the event acknowledgement. The event acknowledgement may be one of the positive acknowledgement indicating the successful fulfillment of the UI event request and the negative acknowledgement indicating the failure to fulfill the UI event request. Once the event acknowledgement is generated, at step 310, the microservice 304 may send the event acknowledgement generated for the UI event request to the ERM 208. Upon receiving the event acknowledgement, at step 312, the ERM 208 may display the event acknowledgement to the user using the UI 302. In an embodiment, upon receiving the negative acknowledgement, the ERM 304 may re-direct the UI event request to an alternative microservice from a plurality of microservices associated with the MANO architecture. In other words, when the ERM 208 receives the negative acknowledgement from the microservice 304, then in addition to displaying the negative acknowledgement to the user using the UI 302, the ERM 208 redirects the UI event request to another microservice for processing.
[0087] In an aspect, the UI 302 is configured to enhance the operations of the ERM 208 such that the ERM 208 has access to a wide range of functions (or microservices) supported by the MANO architecture. The UI 302 is used by the user (e.g., the developer or the administrator) to manage and monitor resources (e.g., switches, firewalls, routers, etc.). The present disclosure is configured to allow the user to define and orchestrate microservices using the UI 302.
[0088] In an aspect, the ERM 208 plays an important role in event-driven architecture where an event request, e.g., the UI event request (i.e., the at least on user request) needs to be delivered from event producers, e.g., the UI 302 (i.e., the publisher) to appropriate event consumers, e.g., the microservice 304 (i.e., the subscriber). The ERM 208 is configured to distribute the event request by efficiently distributing each request to multiple consumers or microservices based on the event name. Further, the ERM 208 helps add multiple event publishers and subscribers in the event-driven architecture without affecting the overall system's functionality or performance. The ERM 208 supports dynamic routing of the event request in the event-driven architecture by enabling the UI 302 to adapt to the changing requirements. The ERM 208 provides various mechanisms (e.g., retry mechanism) to handle errors or failures during event request routing and ensure reliable delivery of the event requests even in transient failures or network issues.
[0089] In a distributed system, the UI 302, in conjunction with the ERM 208, uses a service discovery mechanism to dynamically locate and route the event request to the appropriate microservice instances. In an aspect, the UI 302 is configured to provide advanced automation features and improved scalability. In an embodiment, the ERM 208 is configured to store the event requests in the case when one or more microservices fail to receive the event requests. Thus, the efficiency of an overall network gets improved. Further, the ERM 208 is configured to support a retry mechanism in case of failure by sending the event request after an expiry of a pre-defined time interval, e.g., 5 minutes.
[0090] The MANO architecture includes mainly three essential components: an orchestrator, a Container Network Function (CNF) manager, and a Virtual Infrastructure Manager (VIM). The orchestrator (also known as NFV orchestrator (NFVO)) is configured to cooperate with a CNF catalogue management, a network service catalogue, and a policy execution engine. The NFVO is configured to perform orchestration of resources of the network functions virtualization infrastructure (NFVI) and lifecycle management of network service (NS) instances (instantiation, scaling, termination, update, etc. of NS instances). The NFVO plays a crucial role in orchestrating services, overseeing the deployment, and managing resources efficiently. The CNF manager is configured to determine lifecycle of the CNF instances (for example, instantiation, update, query, scaling, termination, etc.). The CNF manager is configured to control containerized network functions (CNFs), ensuring their proper functioning. The VIM is configured to act as an orchestration adapter. The VIM is configured to manage computing, storage, and network resources of the NFVI, monitors a failure of the NFVI, and monitor resources of the NFVI. The VIM is configured to manage the underlying infrastructure resources required for virtualization.
[0091] These three components collaborate closely to facilitate the flexible and efficient deployment and management of virtualized microservices. Within each of these components, multiple microservices operate that communicate with one another using specific event names. The ERM 208 is configured to direct incoming event requests (e.g., the UI event request) based on the event name to an appropriate microservice (e.g., the microservice 304) using a designated interface, e.g., Event routing Manager Orchestrator (EM_Or) interface, Event routing Manager Virtual Infrastructure Manager (EM_Vi) interface, etc. The event-driven communication framework discussed in the FIG. 3 enhances the overall functionality and effectiveness of the MANO architecture. The present disclosure enables the users to define and execute automated workflows for tasks like provisioning new virtual resources or scaling microservices based on demand. In an aspect, the user may perform a registration or a deregistration of each ERM within a network (i.e., the network 106) using the UI 302. The UI 302 accepts the event request (also referred to as at least one user request) for resource creation, modification, and decommissioning of the microservices throughout the microservices lifecycle. The UI 302 is used to start, stop, scale, or update microservices as per his requirements.
[0092] The UI 302, i.e., the EM_UI is configured to connect to each microservice in the MANO architecture using an event description, as illustrated in Table 1. In an example, the EM_UI serves as a connection point for more than 20 microservices and handles over 300 events in the MANO architecture, thereby allowing the EM_UI to accommodate many microservices and events efficiently.
[0093] Table 1 represents a mapping of a publisher with one or more subscribers, along with an events description associated with each subscriber. Table 1 may be stored in the database 210. In Table 1, each row of the first column represents the publisher, e.g., the UI 302. Further, each row of a second column represents a plurality of subscribers mapped to the publisher. Each subscriber may correspond to a microservice associated with the MANO architecture. Further, each row of a third column represents an event description used to provide details of the event along with an action that the subscriber performs corresponding to each event.

Publisher Subscriber Event description
UI Cloud Management Gateway (CMG) Application Programming Interface (API) to create Graphic Content Tool (GCT)
UI Open Service Architecture (OSA) To get a list of available host/hypervisor w.r.t VIM site
UI Virtualized Business Resource Manager (VBRM) API to disable backup profile
UI Cloud Management Platform (CMP) To modify thresholds of VNF resources (virtual Central Processing Unit (CPU), a Random Access Memory (RAM), Storage)
UI Physical Virtualized Infrastructure Manager (PVIM) API to get VIM resource at host aggregate level
UI CMP To get thresholds of VNF resources (vCPU, RAM, Storage)
UI Access Management (AM) API to get all alarm type List
UI CMG API to get VIM resource statistics
UI CMG API to get elasticity policy list
UI VBRM API to create backup profile
UI VBRM API to view backup profile list
UI VBRM API to enable backup profile
UI Virtual Network Function Component (VNFC) Associate volume to VNFC
UI Network Service Control Manager (NSCM) API to terminate VNF in network service
UI CMG Fetch Config parameter list
UI CMG API to delete template
UI CMP API to create vim threshold
UI CMP API to modify vim threshold
UI Resource Management and Reporting (RMR) API to fetch draft information
UI CMG API to apply template
UI VBRM API to initiate re-store
UI VBRM API to update backup profile
UI PVIM API to get termination status of VNF
UI VBRM API to delete backup profile
UI CMP To get thresholds of VIM resources (vCPU, RAM, Storage)

[0094] For example, each event with its corresponding event description may be predefined and stored in the database as content depicted in Table 1. In some embodiments, each event may be added dynamically consisting of microservices names for each event as the publisher and the at least one subscriber. In an example, the system (102) is configured to route the event requests corresponding to the events during the microservice failure, ensuring that user interactions and the event requests can be processed even when certain microservices are temporarily unavailable.
[0095] In an example, the ERM 208 is configured to enable asynchronous communication between the UI 302 and the microservice 304 in the MANO architecture. This asynchronous communication is useful for managing high-throughput scenarios efficiently and handling tasks that don't require immediate responses.
[0096] In an example, the ERM 208 is configured to enable the broadcasting of the event request to groups of microservices that have subscribed to a specific event. This group-based event routing ensures that relevant microservices receive the same request simultaneously, making it useful for scenarios where multiple microservices need to act on the same event.
[0097] The ERM 208 is configured to use several service discovery mechanisms, such as a service registry (i.e., the database 210) for routing configurations to map microservice names and Fully Qualified Domain Name (FQDN) addresses.
[0098] In an aspect, any microservice (e.g., the microservice 304) can dynamically add events in runtime in the database 210 associated with the ERM 208 using the UI 302. The microservice can dynamically remove events in runtime in the database 210 associated with the ERM 208 using the UI 302. In addition, the microservices may be added or removed by any publisher corresponding to the event in runtime that is present in the database 210 associated with the ERM 208, using the UI 302.
[0099] In an aspect, the ERM 208 is configured to incorporate event routing configurations, which are used to distribute incoming event requests across multiple instances of the microservices using the load balancing technique, such as the round-robin load balancing technique, which helps in optimizing resource utilization and improving overall system performance. In an example, the event routing configurations can incorporate circuit-breaking patterns, where the event requests are redirected to an alternative microservice instance or when an error response (i.e., the negative acknowledgement) is received by the UI 302 when a particular microservice fails to respond.
[00100] In an embodiment, manual user efforts were involved to add, modify, or remove events. The users had to rely on cumbersome workflows, which could lead to errors and inconsistencies in event handling. Whereas in the present invention, the user can send the user request (also referred to as the event request), such as the event addition request, the event deletion request, etc., to the ERM 208. Upon receiving the user request, the ERM 208 may direct the user request to an appropriate microservice within the MANO architecture. Further, the microservices may perform a suitable action based on the user request and provide the event acknowledgment to the user.
[00101] In an embedment, feedback (i.e., the event acknowledgement) received from the ERM 208 corresponding to the user request was often limited or delayed, meaning the user would have to wait for the feedback without real-time updates on a status of their user requests. This lack of real-time feedback hindered effective decision-making and operational efficiency. Whereas, in the present invention facilitates the user to activate notifications corresponding to each user requests send to the ERM 208. Upon activation of the notifications, the ERM 208 may provide the real-time feedback (i.e., the event acknowledgement) corresponding to a user request for which the user activated the notification.
[00102] FIG. 4 illustrates an exemplary microservices architecture (i.e., a MANO architecture 400), in accordance with embodiments of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3.
[00103] As depicted in FIG. 4, the MANO architecture 400 may comprise several interconnected modules that work together to enable efficient resource allocation and management. These modules may include a user interface layer 402, NFV and SDN design functions 404, platform foundation services 406, platform core services 408, a platform operation, administration, and maintenance manager 410, and platform resource adapters and utilities 412.
[00104] The user interface layer 402 may serve as a primary point of interaction for network operators and network administrators. Through the user interface layer 402, various parameters associated with the ERM 208 may be configured and adjusted based on specific requirements. These parameters may include a number of microservices associated with ERMs, a number of ERMs that can be deployed simultaneously, and other relevant settings.
[00105] The NFV and SDN design functions 404 may work in conjunction with the platform core services 408 to analyze and route the user requests received by the ERM 208. These modules may be responsible for identifying the microservice (e.g., a target microservice) within the MANO architecture based on a type of the resource allocation required. These modules may utilize a mapping of user request types to target microservices maintained by the ERM 208 to ensure accurate routing of each user request. The NFV and SDN design functions 404 may include a Virtual Network Function (VNF) lifecycle manager (compute) that is a specialized component focused on managing compute resources associated with a VNF throughout their lifecycle. The NFV and SDN design functions 404 may include a VNF catalog that is a repository that stores and manages metadata, configurations, and templates for the VNF, facilitating their deployment and lifecycle management. The NFV and SDN design functions 404 may include a network services catalog, a network slicing and service chaining manager, a physical and virtual resource manager, and a CNF lifecycle manager. The network services catalog serves as a repository for managing and storing detailed information about network services, including their specifications and deployment requirements. The network slicing and service chaining manager is responsible for orchestrating network slices and service chains, ensuring efficient allocation and utilization of the network resources tailored to various services. The physical and virtual resource manager oversees both the physical resources and the virtual resources, handling their allocation, monitoring, and optimization to ensure seamless operation across the network infrastructure. The CNF lifecycle manager manages the complete lifecycle of a CNF, including onboarding, instantiation, scaling, monitoring, and termination, thereby facilitating the efficient deployment and operation of network functions in a cloud-native environment.
[00106] The platform foundation services 406 may support an asynchronous event-based processing model implemented by the ERM 208, enabling concurrent handling of multiple user requests. They may also facilitate bi-directional communication interfaces (a Network Management System Event Routing Manager (NMS_EM) interface and an Event routing Manager Microservice (EM_MS)) used by the ERM 208 to interact with the external systems and the MANO framework microservices. The platform foundation services 406 may include a microservices elastic load balancer, an identity & access manager, a Command Line Interface (CLI), a central logging manager, and a ERM (e.g., the ERM 208). The microservices elastic load balancer ensures that incoming traffic (i.e., the user requests) is evenly distributed across multiple microservices, enhancing performance and availability. The identity & access manager handles user identity management and access control, enforcing permissions and roles to secure resources and services. The CLI offers a text-based method for users to interact with the MANO architecture 400, enabling command execution and configuration management. The central logging manager consolidates log data from various system components, providing a unified view for effective monitoring, troubleshooting, and data analysis.
[00107] The platform core services 408 are central to the processing and fulfillment of the user requests (i.e., the at least one user request). The platform core services 408 may work together to allocate network slices, manage virtualized network functions, and orchestrate the underlying virtualized infrastructure resources based on each of the at least one user request routed by the ERM 208. The platform core services 408 may include an NFV infrastructure monitoring manager, an assurance manager, a performance manager, a policy execution engine, a capacity monitoring manager, a release management repository, a configuration manager and Global Control Tower (GCT), a NFV platform decision analytics platform, a Not Only Structured Query Language (SQL) database (NoSQL DB), platform schedulers & jobs, a VNF backup & upgrade manager, and a microservice auditor. The NFV infrastructure monitoring manager tracks and oversees the health and performance of the NFV infrastructure. The assurance manager ensures service quality and compliance with operational standards. The performance manager monitors the system performance metrics to optimize efficiency. The policy execution engine enforces and executes policies across the MANO framework. The capacity monitoring manager tracks the resources usage and forecasts future needs. The release management repository manages software releases and version control. The configuration manager handles the system configurations, ensuring consistency and automation. The GCT provides a centralized oversight and a management of the MANO framework operations. The NFV platform decision analytics platform utilizes data analytics to support decision-making. The NoSQL DB stores unstructured data to support flexible and scalable data management. The platform schedulers and jobs automate and schedule routine tasks and workflows. The VNF backup and upgrade manager oversees the backup and upgrading of VNFs. The microservice auditor ensures the integrity and compliance of the microservices across the MANO architecture 400.
[00108] The platform operation, administration, and maintenance manager 410 (i.e., the OAM 310) may oversee operational aspects of the MANO architecture 400. The platform operation, administration, and maintenance manager 410 may be responsible for implementing a load-balancing mechanism used by the ERM 208 to distribute the user requests (also referred to as a service request) across multiple instances of microservices associated with the MANO architecture.
[00109] The platform resource adapters and utilities 412 may provide necessary tools and interfaces for interacting with an underlying network infrastructure, i.e., the NFV architecture. These components may be crucial in translating the service requests into actionable commands for the resources (also referred to as the network resources) allocation and management. The platform resource adapters and utilities 412 may work closely with the platform core services 408 to ensure that allocated resources meet specified requirements. Together, these modules create a cohesive and efficient system for managing the resources allocation. The platform resource adapters and utilities 412 may include a platform external Application Programming Interface (API) adapter and gateway, a generic decoder and indexer, an orchestration adapter, an API adapter, and a NFV gateway. The platform external API adapter and gateway facilitates seamless integration with external APIs and manages data flow between the external systems and the MANO framework. The generic decoder and indexer processes and organizes data from various formats such as an eXtensible Markup Language (XML), a Comma Separated Values (CSV), and a JavaScript Object Notation (JSON), ensuring compatibility and efficient indexing. The orchestration adapter manages interactions with container orchestration clusters, enabling container orchestration and scaling. The API adapter interfaces with cloud services, allowing integration and management of cloud resources. Finally, the NFV gateway acts as a bridge for NFV communications, coordinating between NFV components and other platform elements.
[00110] The ERM 208 may interact with all these modules to facilitate an end-to-end process of a user request handling. The ERM 208 may receive the user request through the user interface layer 402, utilize the NFV and SDN design functions 404 for the user requests analysis, leverage the platform core services 408 for the service requests fulfillment and use the platform resource adapters and utilities 412 for actual resources allocation for each user request. The platform operations, administration and maintenance manager 410 may oversee this entire process, ensuring efficient operation and fault tolerance. This integrated approach may enable the MANO architecture 400 to efficiently manage a complex process of the resources allocation and management, potentially providing a flexible and responsive system capable of meeting diverse service requirements in a dynamic network environment.
[00111] FIG. 5 illustrates an exemplary flow diagram of a method 500 for establishing the communication between the users and the microservices architecture, in accordance with embodiments of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3 and 4. The microservices architecture may correspond to the MANO architecture 400. Each step of the method 500 may be performed by the ERM 208.
[00112] In order to establish the communication between a user and the MANO architecture, initially, at least one input may be received from the user through the UI (i.e., the UI 302). The user may be the developer or the administrator. The UI 302 may correspond to the EM_UI. The at least one input includes the username and the password. At least one user input may be used to authenticate the user to ensure that only an authorized user has access to certain features (i.e., the microservices) or data (e.g., the publisher-subscriber mapping) within the UI 302. Upon receiving the at least one user input, the at least one input may be authenticated based on the associated authorization information stored in a database (e.g., the database 210). The associated authorization information may be obtained while registering the user with the MANO architecture. In order to authenticate the user, the associated authorization information may be retrieved from the database. Further, the associated authorization information may be matched with the at least one user input to validate the user. If the associated authorization information matches with the at least one user input, then the authentication of the user may be a successful authentication. Further, upon successful authentication, the user may be granted an access for sending the at least one user request. In some embodiments, if the associated authorization information does not match with the at least one user input, then the authentication of the user may be an unsuccessful authentication. In this embodiment, the user may be restricted from sending the at least one user request to the ERM 208.
[00113] Upon the successful authentication, at step 502, the at least one user request corresponding to the event may be received from the user. The user may provide the at least one user request to the ERM 208 using the UI 302. Examples of the at least one user request may include, but are not limited to, the event addition request, the event removal request, the event updation request, the publisher addition request, and the publisher removal request. Examples of the event may include, but are not limited to, a Graphic Content Tool (GCT) creation event, an available Hosts List retrieval event, a backup profile disabling event, a VNF resource thresholds modification event, and the like. The event refers to a significant occurrence or a change within that MANO architecture that results from user requests.
[00114] Upon receiving the at least one user request, at step 504, the at least one user request may be analyzed to identify the microservice (e.g., the microservice 304) associated with the microservices architecture. The microservice associated with the microservice architecture is identified based on the publisher and the at least one subscriber. The publisher and the at least one subscriber may be configured with the HTTP header. The HTTP header may be included within the at least one user request. The publisher may correspond to the entity (e.g., the EM_UI, i.e., the UI 302) that initiates or sends the at least one user request. The subscriber may correspond to the entity (e.g., the microservice 304) that receives for and responds to the at least one user request. The HTTP header may contain metadata or routing information that helps identify an appropriate publisher and a subscriber for a given user request. For example, the routing information includes a publisher Identifier (ID), a subscriber ID, and an event name. To identify the microservice, the ERM 208 may use publishers and subscribers mapping provisioned in the database 210 and the routing information included in the HTTP header. In an embodiment, the database 210 may also include a description of various events and actions associated with the events and routing rules for routing the event request to the microservice 304.
[00115] Upon identifying the microservice, at step 506, the at least one user request may be routed to the microservice associated with the microservices architecture for processing the at least one user request. The at least one user request may be routed to the microservice by employing the load balancing technique, e.g., the round-robin load balancing technique. The round-robin load balancing is a technique used to distribute incoming user requests evenly across a pool of microservices or resources. Each user request is assigned to the next microservice in a circular order, ensuring that all microservices handle an equal share of the workload, optimizing resource utilization and improving overall performance of the microservices architecture. Upon receiving the at least one user request, the microservice is configured to process the at least one user request and generate the event acknowledgement based on the processing of the at least one user request. The event acknowledgement may one of the positive acknowledgement indicating the successful fulfillment of the at least one user request and the negative acknowledgement indicating the failure to fulfill the at least one user request. Once the event acknowledgement is generated, at step 508, the event acknowledgement may be received from the microservice.
[00116] Upon receiving the event acknowledgement, at step 510, the event acknowledgement may be rendered to the user using the UI 302. In an embodiment, upon receiving the negative acknowledgement, the at least one user request may be redirected to an alternative microservice from a plurality of microservices associated with the microservices architecture. In other words, when the ERM 208 receives the negative acknowledgement from the microservice, then in addition to displaying the negative acknowledgement to the user using the UI 302, the ERM 208 redirects at least one user request to another microservice for processing.
[00117] FIG. 6 illustrates an exemplary process flow diagram of a method 600 for establishing communication between the users and the microservices architecture, in accordance with embodiments of the present disclosure. FIG. 6 is explained in conjunction with FIGS. 1, 2, 3, 4, and 5. The microservices architecture may correspond to the MANO architecture.
[00118] The communication between the users and the microservices architecture may be established using the UI 302. The UI 302 may correspond to the EM_UI. The UI 302 serves as a central hub for managing ERMs, e.g., the ERM 208. The ERM 208 may use the UI 302 to accept the at least one user request from the user. In an embodiment, the ERM 208 may use the UI 302 to accept the at least one user input, i.e., the username and the password received from the user.
[00119] Initially, at step 602, the user may provide the at least one user input (also referred to as an event request or the service request) corresponding to the event using the UI 302 to the ERM 208. Examples of the at least one user request include the event addition request, the event removal request, the event updation request, the publisher addition request, the publisher removal request, and the like. The event addition request initiates the creation of a new event. The event addition request enables the user to expand a range of events that can trigger actions or responses in the MANO architecture. The event deletion request is used to delete an existing event from the database 210 associated with the ERM 208, ensuring that it is no longer available for processing. The event updation request modifies details of an existing event, allowing the user to change event parameters, such as the event name, the event description, and the microservices subscribed for the event, as needed. The publisher addition request registers a new publisher with the ERM 208, enabling the new publisher to send events or notifications to subscribed microservices. The publisher removal request deregisters an existing publisher associated with the ERM 208, preventing the existing publisher from sending events or notifications to any microservices. Examples of the event may include, but are not limited to, the GCT creation event, the available hosts list retrieval event, the backup profile disabling event, the VNF resource thresholds modification event, and the like.
[00120] Upon receiving the event request, the ERM 208 is configured to analyze the event request to identify the microservice associated with the MANO architecture for processing the event request. The event request may include the HTTP header. The HTTP header may include the routing information associated with the event. For example, the routing information includes the publisher ID, the subscriber ID, and the event name. The ERM 208 processes the routing information within the HTTP header to identify the event name, e.g., create a backup profile event. Further, the ERM 208 identifies a publisher, e.g., the UI 302, that initiated the event request using the publisher ID. Further, the ERM 208 identifies an intended subscriber (i.e., the microservice 304) that has subscribed for the event type. The ERM 208 may identify the intended subscriber based on publishers and subscribers mapping provisioned in the database 210 associated with the ERM 208. In an embodiment, the database 210 may also include a description of various events and actions associated with the events and routing rules for routing the event request to the microservice 304. Upon identifying the microservice 304, at step 604, the ERM 208 routes the event request to the microservice 304 associated with the MANO architecture. The event request may be routed by the ERM 208 to the microservice 304 by employing the round-robin load balancing technique. The round-robin load balancing technique is applied by the ERM 208 to evenly distribute incoming event requests across multiple instances of the microservice 304.
[00121] Further, the microservice 304 is configured to process the event request to generate the event acknowledgement. The event acknowledgement may be one of the positive acknowledgement indicating the successful fulfillment of the event request and the negative acknowledgement indicating the failure to fulfill the event request. Once the event acknowledgement is generated, at step 606, the microservice 304 may send the event acknowledgement generated for the event request to the ERM 208. Upon receiving the event acknowledgement, at step 608, the ERM 208 may display the event acknowledgement to the user using the UI 302. In an embodiment, the UI 302 may be the GUI configured to display the event acknowledgement to the user based on the user's preferences. For example, the event acknowledgement may be rendered to the user in the form of a report displaying details of processing the event request during the positive acknowledgement or a reason for the failure of the microservice 304 in fulfilling the event request along with the negative acknowledgement. In an embodiment, upon receiving the negative acknowledgement, the ERM 208 may re-direct the event request to the alternative microservice from the plurality of microservices associated with the MANO architecture. In other words, when the ERM 208 receives the negative acknowledgement from the microservice 304, then in addition to displaying the negative acknowledgement to the user using the UI 302, the ERM 208 redirects the event request to another microservice for processing.
[00122] FIG. 7 illustrates an exemplary computer system 700 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 7, the computer system 700 may include an external storage device 710, a bus 720, a main memory 730, a read-only memory 740, a mass storage device 750, communication port(s) 760, and a processor 770. A person skilled in the art will appreciate that the computer system 700 may include more than one processor and communication ports. The processor 770 may include various modules associated with embodiments of the present disclosure. The communication port(s) 760 may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 760 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 700 connects.
[00123] The main memory 730 may be Random-Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 740 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor 770. The mass storage device 750 may be any current or future mass storage solution, which can be used to store information and/or instructions. The mass storage device 750 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, a Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.
[00124] The bus 720 communicatively couples the processor 770 with the other memory, storage, and communication blocks. The bus 720 may be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 770 to the computer system 700.
[00125] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 720 to support direct operator interaction with the computer system 700. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 760. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 700 limit the scope of the present disclosure.
[00126] 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 skills in the art.
[00127] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
[00128] While considerable emphasis has been placed herein on 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 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 implemented merely as illustrative of the disclosure and not as a limitation.
[00129] The present disclosure provides technical advancement related to establishment of communication between the users and the microservices architecture (e.g., the MANO architecture). This advancement addresses the limitations of existing solutions by introducing the EM_UI associated with the ERM that acts as an intelligent intermediary between the user and the microservice associated with the MANO architecture. The EM_UI enables asynchronous communication between the user and microservices associated with the MANO architecture. This asynchronous communication is beneficial for managing tasks that do not require immediate responses, allowing for more efficient handling of high-throughput scenarios. Further, the EM_UI facilitates the broadcasting of events to groups of microservices that have subscribed to specific events. This group-based event routing ensures that all relevant microservices receive the same request simultaneously, making it ideal for scenarios where multiple microservices need to respond to the same event. The EM_UI acts as a central connection point for a pre-defined number of microservices (e.g., 20 microservices), managing a pre-defined number of events (e.g., more than 300 events) within the context of the MANO architecture. This scalability enables the system to efficiently accommodate a large number of the microservices and the events.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00130] The present disclosure provides a method and a system for facilitating communication between a user and with a microservices architecture using an Event routing Manager User Interface (EM_UI) associated with an Event Routing Manager (ERM). The EM_UI interface that receives user requests from a user and directs the user requests based on an event name to an appropriate microservice associated with the microservices architecture.
[00131] The present disclosure enables asynchronous communication between the user and microservices associated with the microservices architecture (e.g., a Management and Orchestration (MANO) architecture) using the EM_UI.
[00132] The present disclosure provides fault tolerance during a user request failure using the EM_UI. The EM_UI can route an event around microservice failures, ensuring that user interactions and the user request continue to be processed even when certain microservices are temporarily unavailable.
[00133] The present disclosure provides event-based security. The EM_UI routes authentication and authorization events to relevant microservices to ensure that only authorized users can access certain features or data associated with the MANO architecture.
[00134] The present disclosure facilitates event-driven communication to update the EM_UI in real-time. For instance, using the EM_UI, the user can enable push notifications to the EM_UI when relevant events occur, ensuring a responsive and interactive user experience.
[00135] The present disclosure facilitates the broadcasting of events to groups of microservices that have subscribed to specific events using the EM_UI. This group-based event routing ensures that all relevant microservices receive the same request simultaneously, particularly in scenarios where multiple microservices need to respond to the same event.
[00136] The present disclosure enhances scalability by efficiently accommodating a large number of the microservices and the events using the EM_UI.
,CLAIMS:CLAIMS
We Claim:
1. A method (500) for establishing communication between users and a microservices architecture, the method (500) comprising:
receiving (502), by an Event Routing Manager (ERM) (208), at least one user request corresponding to an event from a user (102), provided using a User Interface (UI) (302);
analyzing (504), by the ERM (208), the at least one user request to identify a microservice associated with the microservices architecture;
routing (506), by the ERM (208), the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request;
receiving (508), by the ERM (208), an event acknowledgement corresponding to the at least one user request associated with the event, from the microservice; and
displaying (510), by the ERM (208), the event acknowledgement to the user (102) using the UI (302).

2. The method (500) as claimed in claim 1, wherein the UI (302) corresponds to an Event routing Manager UI (EM_UI).

3. The method (500) as claimed in claim 1, wherein the at least one user request comprises at least one of an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request.

4. The method (500) as claimed in claim 1, further comprising:
receiving, by the ERM (208), at least one input from the user (102) through the UI (302), wherein the at least one input comprises a username and a password;
authenticating, by the ERM (208), the at least one input based on an associated authorization information stored in a database (210); and
granting, by the ERM (208), an access to the user (102) for sending the at least one user request upon a successful authorization.

5. The method (500) as claimed in claim 1, wherein the microservice associated with the microservice architecture is identified based on a publisher and at least one subscriber.

6. The method (500) as claimed in claim 1, wherein routing the at least one user request to the microservice associated with the microservices architecture further comprises:
employing, by the ERM (208), a load balancing technique to route the at least one user request to the microservice associated with the microservices architecture.

7. The method (500) as claimed in claim 1, wherein the microservice is configured to process the at least one user request and generate the acknowledgement based on the processing of the at least one user request.

8. The method (500) as claimed in claim 1, wherein the event acknowledgement is one of:
a positive acknowledgement indicating a successful fulfillment of the at least one user request, and
a negative acknowledgement indicating a failure in fulfillment of the at least user request.

9. The method (500) as claimed in claim 8, further comprising:
upon receiving the negative acknowledgement, redirecting, by the ERM (208), the at least one user request to an alternative microservice from a plurality of microservices associated with the microservices architecture.

10. A system (108) for establishing communication between users and a microservices architecture, the system (108) comprising:
an Event Routing Manager (ERM) (208) configured to:
receive (502) at least one user request corresponding to an event from a user (102), provided using a User Interface (UI) (302);
analyze (504) the at least one user request to identify a microservice associated with the microservices architecture;
route (506) the at least one user request to the microservice associated with the microservices architecture for processing the at least one user request;
receive (508) an event acknowledgement corresponding to the at least one user request associated with the event, from the microservice; and
display (510) the event acknowledgement to the user using the UI (302).

11. The system (108) as claimed in claim 10, wherein the UI (302) corresponds to an Event routing Manager UI (EM_UI).

12. The system (108) as claimed in claim 10, wherein the at least one user request comprises at least one of an event addition request, an event removal request, an event updation request, a publisher addition request, and a publisher removal request.

13. The system (108) as claimed in claim 10, wherein the ERM (208) is further configured to:
receive at least one input from the user (102) using the UI (302), wherein the at least one input comprises a username and a password;
authenticate the at least one input based on an associated authorization information stored in a database (210); and
grant an access to the user (102) for sending the at least one user request upon a successful authorization.

14. The system (108) as claimed in claim 10, wherein the microservice associated with the microservice architecture is identified based on a publisher and at least one subscriber.

15. The system (108) as claimed in claim 10, wherein, to route the at least one user request to the microservice associated with the microservices architecture, wherein the ERM (208) is further configured to:
employ a load balancing technique to route the at least one user request to the microservice associated with the microservices architecture.

16. The system (108) as claimed in claim 10, wherein the microservice is configured to process the at least one user request and generate the acknowledgement based on the processing of the at least one user request.

17. The system (108) as claimed in claim 10, wherein the event acknowledgement is one of:
a positive acknowledgement indicating a successful fulfillment of the at least one user request, and
a negative acknowledgement indicating a failure in fulfillment of the at least user request.

18. The system (108) as claimed in claim 17, wherein the ERM (208) is further configured to:
upon receiving the negative acknowledgement, redirect the at least one user request to an alternative microservice from a plurality of microservices associated with the microservices architecture.

19. A user equipment (UE) (104) communicatively coupled with a network (106), the coupling comprises steps of:
receiving, by the network (106), a connection request from the UE (104);
sending, by the network (106), an acknowledgement of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein based on the connection request, establishment of communication between users and a microservices architecture is performed by a method (500) as claimed in claim 1.