System and method for monitoring performance of nodes in a communication network

Abstract

Disclosed is a system (140) and a method (400) for monitoring performance of nodes (102-108) in a communication network (100). The method comprises receiving, from a user device (160), an input for generating visualization of live alarm data of the nodes, and transmitting an API call request to a scheduler via a microservice (250) to fetch (406), from a database (290), the live alarm data and geographical location information corresponding to the nodes in a geographical location. The method further comprises determining, from the nodes, an aggregated count of a group of nodes that include service affecting alarms based on the live alarm data and the geographical location information, and generating live alarm visualization data based on the aggregated count and the live alarm data corresponding to each node of the group of nodes. Thereafter, the generated live alarm visualization data is displayed on a UI of the user device.

Description

SYSTEM AND METHOD FOR MONITORING PERFORMANCE OF NODES IN A COMMUNICATION NETWORKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Indian patent application No. 202421023395, titled “system and method for real-time data visualization of live alarms for service affecting nodes” filed on March 25, 2024 and Indian patent application No. 202421023396, titled “system and method for handling call flow for generating real-time visualization data of live alarms” filed on March 25, 2024. The disclosure of the prior application is considered part of and is incorporated by reference into this patent application.TECHNICAL FIELD

[0002] The embodiments of the present disclosure generally relate to the field of wireless communication networks and systems. More particularly, the present disclosure relates to a system and a method for processing live alarm data of nodes in a communication network.BACKGROUND OF THE INVENTION

[0003] The subject matter disclosed in the background section should not be assumed or construed to be prior art merely because of its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.

[0004] In the realm of wireless communication and networking environments, efficient operation of communication networks is of utmost importance to ensure seamless communication and uninterrupted services to end users. To this end, Network Operations Centers (NOCs) play a crucial role by monitoring and performance of Network Elements (NEs) and taking corrective actions if needed, in response to any service-affecting events or alarms. An NOC refers to a centralized location where network administrators monitor and manage architecture and infrastructure of deployed communication networks.

[0005] As wireless networks continue to expand, accurate and real time data visualization of live alarms became more critical than ever for the network operators / service providers. In conventional approaches of data visualization of the live alarms, traditional server architectures have been prevalently utilized.

[0006] A traditional server may refer to an open-source web server and a servlet container. The traditional server may correspond to a robust platform for deploying Java-based applications, particularly those built using Java Servlet, Java Server Pages (JSP) and the like. However, such traditional server architectures have various shortcomings and suffered from various limitations. In particular, the traditional servers often encounter significant limitations when it comes to the data visualization. One of the major limitations associated with utilizing the traditional server is the presence of fixed resources, which are shared by multiple application programs managed by the traditional server. The fixed allocation of resources may result in inefficient utilization, leading to performance degradation, increased latency, and decreased responsiveness while generating live alarm visualization data.

[0007] Furthermore, the traditional servers lack advanced features and capabilities required for sophisticated data visualization tasks. Moreover, reliability on fixed resources within the traditional server results in scalability challenges, particularly in scenarios where a holistic view of outage patterns of alarms across different geographies is desired. Heretofore, network operation teams relied on conventional monitoring tools and terminals for monitoring network nodes that generate serviceaffecting alarms. A service-affecting alarm refers to notifications or alerts, generated by the monitoring tools, indicating potential disruptions or failures within the network infrastructure that cause a direct impact on a quality of service provided by the network nodes.

[0008] However, such approaches faced certain limitations and challenges while assessing the impact of the service-affecting alarms on specific geographical areas due to lack of comprehensive performance and data visualization tools. In particular,the conventional monitoring tools that have been utilized so far by the network operation teams are only capable of providing individual site-wise details of alarms. This caused difficulty for the network operation teams, and it became cumbersome to manage the broader geographical implications of incidents such as the service affecting alarms (i.e., outage alarms), performance degradation or failure of nodes, which impacts the performance of the communication network.

[0009] To this end, conventional monitoring tools do not offer a holistic view of outage patterns across different geographies. Additionally, the conventional monitoring tools do not provide any interactive mapping features which again is a reason to limit the ability of the network operation teams to visualize a spatial distribution of network alarms. Owing to the limitation of the conventional monitoring tools, the ability of the network operation teams to perform timely and effective analysis data related to alarms is impacted.

[0010] Therefore, to overcome aforementioned challenges and limitations associated with the conventional data visualization tools and traditional servers, there lies a need for a system and a method that can process and monitor live alarm data efficiently and can help the network operation team in visualizing live alarms for the service affecting nodes, accurately and extensively.SUMMARY

[0011] The following embodiments present a simplified summary to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key / critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0012] In an embodiment, disclosed herein is a method for monitoring performance of nodes in a communication network. The method comprises receiving, by a receiving module via a User Interface (UI) of a user device, an input for generating visualization of live alarm data associated with a plurality of nodes, and transmitting, by a transmitting module based on the input, an ApplicationProgramming Interface (API) call request to a scheduler via a microservice of a plurality of microservices. Further, the method further comprises triggering, by a triggering module based on the API call request, the scheduler to fetch, from a database, the live alarm data and geographical location information corresponding to the plurality of nodes in a geographical location. Furthermore, the method further comprises determining, by a data processing module from the plurality of nodes, an aggregated count of a group of nodes that include one or more service affecting alarms based on the live alarm data and the geographical location information. Thereafter, the method comprises generating, by the data processing module, live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes, and displaying, by a display module, the generated live alarm visualization data on a User Interface (UI) of the user device.

[0013] In one or more aspects of the present disclosure, the aggregated count of the group of nodes corresponds to a unique count of the group of nodes for each cluster of a plurality of node clusters in the geographical location. The one or more service affecting alarms correspond to outage alarms that are updated in real-time.

[0014] In one or more aspects of the present disclosure, the live alarm data and the geographical location information is fetched from the database via the scheduler at periodic time intervals.

[0015] In an aspect of the present disclosure, the method comprises storing, by the data processing module in a memory, a series of live alarm visualization data entries. Each entry of the live alarm visualization data in the memory is associated with a timestamp indicating a time of generation of the live alarm visualization data. Further, the method comprises displaying, by the display module, a selectable view option on the UI. The selectable view option corresponds to an option for accessing the stored live alarm visualization data. Furthermore, the method comprises fetching, by a data extraction module upon receiving an input via the displayed selectable view option, latest available live alarm visualization data entry from thememory based on the associated timestamp, and displaying, by the display module, the fetched live alarm visualization data entry on the UI.

[0016] In one or more aspects of the present disclosure, the method comprises determining, by the data processing module for each node of the group of nodes, a raise time of the alarm based on the live alarm data, and displaying, by the display module on the UI, the live alarm visualization data including the raise time of the alarm and the aggregated count of the group of nodes.

[0017] In some aspects of the present disclosure, the method comprises storing, by the data processing module in a memory, information related to the group of nodes and the one or more service affecting alarms. Based on the information stored in the memory, the method comprises monitoring, by a monitoring module, live alarm data of the group of nodes to determine a change in a status of the one or more service affecting alarms. Further, the method comprises updating, by the data processing module, the live alarm data in the database based on the change in the status of the one or more service affecting alarms.

[0018] In one or more aspects of the present disclosure, updating the live alarm data corresponds to an addition of data associated with the one or more service affecting alarms to the database or a deletion of the data associated with the one or more service affecting alarms from the database.

[0019] In an aspect of the present disclosure, the method comprises receiving, by the receiving module from a vendor Element Management System (EMS), the live alarm data corresponding to the plurality of nodes, and storing, by the data processing module, the live alarm data received from the one or more EMSs in the database.

[0020] In some aspects of the present disclosure, the method comprises identifying, by a Change Data Capture (CDC) module, one or more changes in alarm data processing rates associated with a corresponding node of the group of nodes based on a data throughput of the corresponding node. Further, the method comprises determining, by the CDC module, an increment or a drop in alarm data traffic of thegroup of nodes based on the one or more changes in the alarm data processing rates, and updating, by the data processing module, the live alarm visualization data based on the increment or the drop in alarm data traffic of the group of nodes.

[0021] In another embodiment, disclosed is a system for monitoring performance of nodes in a communication network. The system comprises a database, a receiving module, a transmitting module, a triggering module, a data processing module, and a display module. The database is configured to store live alarm data of a plurality of nodes. The receiving module is configured to receive, via a User Interface (UI) of a user device, for generating visualization of live alarm data associated with the plurality of nodes. The transmitting module is configured to transmit, based on the input, an Application Programming Interface (API) call request to a scheduler via a microservice of a plurality of microservices. The triggering module is configured to trigger the scheduler to fetch, from the database, the live alarm data and geographical location information corresponding to the plurality of nodes in a geographical location based on the API call request. The data processing module is configured to determine, from the plurality of nodes, an aggregated count of a group of nodes that include one or more service affecting alarms based on the live alarm data and the geographical location information, and generate live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes. The display module is configured to display the live alarm visualization data on the UI of the user device.

[0022] In an aspect of the present disclosure, the system further comprises a data extraction module, and the data processing module is further configured to store a series of live alarm visualization data entries in a memory. Each entry of the live alarm visualization data in the memory is associated with a timestamp indicating a time of generation of the live alarm visualization data. The display module is further configured to display a selectable view option on the UI. The selectable view option corresponds to an option for accessing the stored live alarm visualization data. Further, the data extraction module is configured to fetch, upon receiving an inputvia the displayed selectable view option, latest available live alarm visualization data entry from the memory based on the associated timestamp, and the display module is further configured to display the fetched latest live alarm visualization data entry on the UI.

[0023] In one or more aspects of the present disclosure, the data processing module is further configured to determine, for each node of the group of nodes, a raise time of the alarm based on the live alarm data, and the display module is further configured to display, on the UI, the live alarm visualization data including the raise time of the alarm and the aggregated count of the group of nodes.

[0024] In some aspects of the present disclosure, the system further comprises a monitoring module, and the data processing module is further configured to store, in the memory, information related to the group of nodes and the one or more service affecting alarms. Further, the monitoring module is configured to monitor, based on the information stored in the memory, live alarm data of the group of nodes to determine a change in a status of the one or more service affecting alarms. Furthermore, the data processing module is configured to update the live alarm data in the database based on the change in the status of the one or more service affecting alarms.

[0025] In one or more aspects of the present disclosure, to update the live alarm data, the data processing module is configured to add data associated with the one or more service affecting alarms to the database or remove the data associated with the one or more service affecting alarms from the database.

[0026] In an aspect of the present disclosure, the receiving module is further configured to receive, from one or more Element Management Systems (EMSs), the live alarm data corresponding to the plurality of nodes, and the data processing module is further configured to store, in the database, the live alarm data received from the one or more EMSs.

[0027] In some aspects of the present disclosure, the system further comprises a Change Data Capture (CDC) module configured to identify one or more changes inalarm data processing rates associated with a corresponding node of the group of nodes based on a data throughput of the corresponding node, and determine an increment or a drop in alarm data traffic of the group of nodes based on the one or more changes in the alarm data processing rates. The data processing module is further configured to update the live alarm visualization data based on the increment or the drop in the alarm data traffic of the group of nodes.BRIEF DESCRIPTION OF DRAWINGS

[0028] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings.

[0029] FIG. 1 illustrates an exemplary communication network, in accordance with an example embodiment of the present disclosure.

[0030] FIG. 2 illustrates an exemplary block diagram depicting a system architecture of a server for monitoring performance of nodes in the communication network, in accordance with an embodiment of the present disclosure.

[0031] FIG. 3 illustrates a flow diagram depicting a call flow between a User Interface (UI) and components of the server, in accordance with an embodiment of the present disclosure.

[0032] FIG. 4 illustrates a flowchart of a method for monitoring the performance of nodes in the communication network, in accordance with an embodiment of the present disclosure.

[0033] FIG. 5 illustrates a flowchart of a method for fetching and displaying latest live alarm visualization data on the UI, in accordance with an embodiment of the present disclosure.

[0034] FIG. 6 illustrates a flowchart of a method for updating the live alarm visualization data, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

[0035] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

[0036] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

[0037] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” which may each refer to one or more or all of the same or different embodiments. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one,but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” refers to one embodiment and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.”

[0038] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

[0039] 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.

[0040] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

[0041] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.

[0042] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0043] An object of the present disclosure is to provide a system and a method for monitoring performance of nodes in a communication network to enable a Network Operations Center (NOC) team to visualize, in real-time, live alarm data of the nodes that includes service affecting alarms.

[0044] Another object of the present disclosure is to provide a system and a method that can facilitate maintenance cluster wise ageing of outage alarms.

[0045] Yet another object of the present disclosure is to provide a system and a method that eliminates the need for an exhaustive analysis of all the nodes in the communication network by focusing only on the nodes that includes the service affecting alarms.

[0046] Yet another object of the present disclosure is to provide a system and a method that can enable integration of front-end and back-end processes for generating live alarm visualization data such that an end user can visualize in realtime, data of the live alarms with minimum latency along with data sanity. Yet another object of the present disclosure is to provide a system and a method for handling a call flow that enables the NOC team to assign priority in attending the nodes that includes the service affecting alarms in any geography or maintenance cluster, to improve end user experience.

[0047] In the disclosure, various embodiments are described using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), Extensible Radio Access Network (xRAN), and Open-Radio Access Network (O-RAN)), but these are merely examples for description. Various embodiments of the disclosure may also be easily modified and applied to other communication systems.

[0048] In order to facilitate an understanding of the disclosed invention, a number of terms are defined below.

[0049] A service affecting alarm refers to an abnormal network entity condition that categorizes an event as a fault. More specifically, the service affecting alarm corresponds to an event that indicate a condition adversely impacting a quality or availability of telecommunication services. Such alarms necessitate prompt attention to restore normal service operations.

[0050] An outage alarm signifies a total loss of service in a specific network area or cell. A cell outage refers to a total loss of radio services in a coverage area of a cell. The outage alarms are critical as they indicate complete service disruption at any node in the communication network, requiring immediate remediation.

[0051] Alarm data processing rates refers to a speed and efficiency with which a network management system processes alarm data incoming from an Element Management System (EMS). In particular, the alarm data processing rates corresponds to a rate at which alarms are received, logged, analyzed, and acted upon by the network management system.

[0052] The EMS refers to an intermediary entity between network nodes and a Network Management System (NMS) within the communication network. The EMS is responsible for collecting and aggregating performance measurements and generated alarms / events from individual network elements such as base stations / nodes of a specific vendor, and transferring the collected data to the NMS. The NMS may refer to a system responsible for monitoring and optimizing operations of the network elements.

[0053] A vendor EMS cluster refers to a group of multiple vendor-specific EMSs, where each vendor EMS is responsible for managing the network elements of aparticular vendor. The vendor EMS cluster may provide a centralized control over the network elements from different vendors for performing vendor-specific management functionalities in the communication network.

[0054] The following description provides specific details of certain aspects of the disclosure illustrated in the drawings to provide a thorough understanding of those aspects. It should be recognized, however, that the present disclosure can be reflected in additional aspects and the disclosure may be practiced without some of the details in the following description.

[0055] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 through FIG. 6, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0056] FIG. 1 illustrates an exemplary communication network 100, in accordance with an embodiment of the present disclosure. The embodiment of the communication network 100 shown in FIG. 1 is for illustration only. Other embodiments of the communication network 100 may be used without departing from the scope of this disclosure.

[0057] As shown in FIG. 1, the communication network 100 includes a vendor EMS cluster 110 including a plurality of vendor EMSs 102' through 108', where each vendor EMS is managing one or more nodes (e.g., one or more base stations). For instance, nodes 102, 104, 106, and 108 are shown in FIG. 1 for exemplary purpose, without departing form the scope of the present disclosure. Depending on the network type, the term “nodes” may refer to any component (or collection of components) configured to provide wireless access to a network, such as Transmit Point (TP), Transmit-Receive point (TRP), an Evolved Base Station (eNodeB or eNB), a 5G / NR base station (gNB), a macrocell, a femtocell, a Wi-Fi Access Point(AP), or other wirelessly enabled devices. The nodes and vendor EMSs may communicate with each other via wireless communication protocols, e.g., 5G / NR 3GPP New Radio interface / access (NR), Long Term Evolution (LTE), LTE advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi 802.1 la / b / g / n / ac, etc. For the sake of convenience, the terms “base station” and “node” are used interchangeably in the present disclosure to refer to network infrastructure components that provide wireless access to remote terminals.

[0058] Each of the vendor EMSs 102’ through 108’ (hereinafter also referred to as ‘the EMS’) may be configured to monitor, manage, and control individual Network Elements (NEs) within the communication network 100. Each of the vendor EMSs 102’ through 108’ may be controlled by one or more EMS server(s).

[0059] The communication network 100 further includes a network 120, a load balancer 130, a server 140, a distributed file system 150, a user device 160, and a gateway 170. The server 140 is connected to the vendor EMS cluster 110 via the network 120 followed by the load balancer 130. The network 120 may correspond to one of an Internet, a proprietary Internet Protocol (IP) network, or other data network. The load balancer 130 is an intermediary between the network 120 and the server 140. The load balancer 130 is configured to distribute incoming alarm data from the vendor EMS cluster 110 to one or more parsers 225 (hereinafter also referred to as the “parser 225”) (shown in FIG. 2 described below) of the server 140 for efficient parallel processing.

[0060] The server 140 is configured to process the alarm data incoming from the vendor EMS cluster 110 in real time for assessing an impact of the live alarms on performance of the nodes (for example, nodes 102 through 108) in a particular geography within the communication network 100.

[0061] The distributed file system 150 may correspond to an external file system or a file system integrated within the server 140 for storing the live alarm visualization data and other operational data. In a non-limiting example, the distributed file system 150 may refer to a system that allows access to files across multiplenetworked computers, making data retrieval more scalable and reliable. Further, the distributed file system 150 may store performance statistics and logs across distributed nodes for the live alarms.

[0062] The user device 160 corresponds to a device used by a network operation team or an end user. Further, depending on the network type, the term “user device 160” may refer to any component such as “mobile station,” “subscriber station,” “remote terminal,” “wireless terminal,” or “receive point,”. The user device 160 includes the user interface 160-1 and a communication unit 160-2. In a non-limiting example, the user interface 160-1 may facilitate display of aggregated count of nodes that includes service affecting alarms and live alarm visualization data including the raise time of the alarm.

[0063] The communication unit 160-2 may include a plurality of antennas, a plurality of Radio Frequency (RF) transceivers, a transmit processing circuitry, and a receive processing circuitry. Additionally, the user device 160 may further include circuitry, programing, applications, or a combination thereof.

[0064] The gateway 170 between the user device 160 and the server 140 may be referred to as an interface unit, and may be located on the network 120. In other embodiments, a plurality of gateways may be deployed on the network 120. In other embodiments, the gateway 170 may be located at any point in the network or network communications path between the user device 160 and the server 140.

[0065] Although FIG. 1 illustrates one example of the communication network 100, various changes may be made to FIG. 1. For example, the communication network 100 may include any number of vendor EMS, nodes, communication gateways, servers, and user devices in any suitable arrangement. Further, various components in FIG. 1 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.

[0066] FIG. 2 illustrates an exemplary block diagram depicting a system architecture of the server 140, in accordance with an example embodiment of thepresent disclosure. The embodiment of the server 140 as shown in FIG. 2 is for illustration only. However, the server 140 may come in a wide variety of configurations, and FIG. 2 does not limit the scope of the present disclosure to any particular implementation of the server 140.

[0067] As shown in FIG. 2, the server 140 includes one or more processors 210 (hereinafter also referred to as “processor 210”), a memory 215, a communication interface 220, one or more parsers 225 (hereinafter also referred to as the “parser 225”) an interface(s) 230, a distributed streaming platform 235, a scheduler 240, a Change Data Capture (CDC) Module 245, microservice(s) 250, a processing unit(s) / modules(s) 280, and a database 290. These components may be in electronic communication via one or more buses (e.g., bus 295).

[0068] The processor 210 may include a plurality of processing engines i.e., information processing task executors for efficient parallel processing of the live alarm data of the nodes that includes the service affecting alarms. The one or more components of the server 140 are communicatively coupled with the processor 210 (described below) to process the live alarm data incoming from the EMSs efficiently and generate the live alarm visualization data. The processor 210 may further include various processing circuitry and configured to execute programs or computer readable instructions stored in the memory 215. The processor 210 may also include an intelligent hardware device including a general -purpose processor, such as, for example, and without limitation, a Central Processing Unit (CPU), an Application Processor (AP), a dedicated processor, or the like, a graphics-only processing unit such as a Graphics Processing Unit (GPU), a microcontroller, a Field-Programmable Gate Array (FPGA), a programmable logic device, a discrete hardware component, or any combination thereof. In some cases, the processor 210 may be configured to operate a memory array using a memory controller. In some cases, a memory controller may be integrated into the processor 210. The processor 210 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 215) to cause the server 140 to perform various functions (e.g., monitoring performance of the nodes in the communication network 100 toidentify the nodes that includes the service affecting alarms and generate the live alarm visualization data using which the need for the exhaustive analysis of performance of all the nodes in the communication network can be eliminated).

[0069] The memory 215 is communicatively coupled to the processor 210. A part of the memory 215 may include a RAM, and another part of the memory 215 may include a flash memory or other ROM. The memory 215 is configured to store a set of instructions required by the processor 210 for controlling overall operations of the server 140. The memory 215 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 215 may, in some examples, be considered a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non- transitory" should not be interpreted that the memory 215 is non-movable. In some examples, the memory 215 can be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 215 can be an internal storage unit or it can be an external storage unit of the server 140, cloud storage, or any other type of external storage.

[0070] More specifically, the memory 215 may store computer-readable instructions 215 A including instructions that, when executed by a processor (e.g., the processor 210) cause the server 140 to perform various functions described herein. In some cases, the memory 215 may contain, among other things, a BIOS which may control basic hardware or software operation such as the interaction with peripheral components or devices.

[0071] The communication interface 220 includes an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 220 is configured to communicate internally between internal hardwarecomponents and with external devices via one or more networks. The communication interface 220 may be configured to enable the nodes to communicate with various entities of the communication network 100 (such as UEs, nodes, and databases and in some scenarios external user device) via the network 120. Examples of the communication interface 220 may include, but are not limited to, a modem, a network interface such as an Ethernet card, a communication port, and / or a Personal Computer Memory Card International Association (PCMCIA) slot and card, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, and a local buffer circuit. It will be apparent to a person of ordinary skill in the art that the communication interface 220 may include any device and / or apparatus capable of providing wireless or wired communications between the server 140 and various other entities of the communication network 100.

[0072] The parser 225 is configured to parse and extract information from the incoming live alarm data, decode a format of the live alarm data, and transform raw live alarm data into structured records for further processing.

[0073] The interface 230 may include suitable logic, circuitry, a variety of interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on a display interface or a Graphical User Interface (GUI). The variety of interfaces may include interfaces for data input and output devices, referred to as VO devices, storage devices, and the like. For example, the VO interface may have an input interface and an output interface. The interface 230 may facilitate communication of the server 140 with various devices connected to it. The interface 230 may also provide a communication pathway for one or more components of the server 140. Examples of such components include, but are not limited to, the distributed streaming platform 235, the CDC Module 245, the microservices 250, the processing module(s) 280, and the database 290.

[0074] The distributed streaming platform 235 is configured to ingest the live alarm data, process the ingested alarm data, and distribute alarm data streams to the processor 210. The distributed streaming platform 235 is further configured to handle and manage incoming stream of alarm data to ensure low-latency data processing and seamless integration with downstream components.

[0075] The scheduler 240 is connected to the processor 210 and configured to schedule execution of analytical tasks and job workflows allocated by the processor 210 to ensure timely processing of the live alarm data to identify an impact of outage nodes (i.e., nodes that includes the service affecting alarms).

[0076] The CDC Module 245 is configured to monitor one or more changes in data processing rates and dynamically adjust one or more processing parameters to detect anomalies in data throughput to ensure a consistent performance and resilience against a sudden increase or drop in live alarm data traffic. In a non-limiting example, an NOC may process 100 alarms per second during peak times. The processing of the alarms at a rate around 100 alarms per second ensures that the system can handle high volumes of alarms without delays, preventing potential bottlenecks in fault management and ensuring timely responses to critical network issues. Further, the data throughput refers to a volume of alarm data processed by the server 140 per unit of time. Thus, the CDC Module 245 monitors the rate of processing the alarms per second during peak times or at any other time interval in by monitoring the data throughput to ensure that the server 140 can handle the incoming live alarm data efficiently, allowing the NOC team to visualize and respond to the live alarms promptly.

[0077] The CDC Module 245 is further configured to determine an increment or a drop in alarm data traffic of the of nodes based on the one or more changes in the alarm data processing rates.

[0078] The microservice(s) 250 refers to a modular, independent, and a transactional component of the server 140 that is scheduled to run on a cloud infrastructure optimized for compute and modularize different functions of theserver 140, such as in managing an Application Programming Interface (API) call request received from the user device 160 via the API gateway 170, and triggering the scheduler 240 to fetch data corresponding to live alarms from the database 290.

[0079] In one or more embodiments, the processing module(s) 280 may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the server 140. In non-limiting examples, described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing modules(s) 280 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor 210 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 processing module(s) 280. In such examples, the server 140 may also 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 server 140 and the processing resource. In other examples, the processing module(s) 280 may be implemented using an electronic circuitry.

[0080] In one or more embodiments, the processing module(s) 280 may include one or more units / modules selected from any of a receiving module 262, a transmitting module 264, a triggering module 266, a data processing module 268, a display module 270, a data extraction module 272, a monitoring module 274, and other units / modules 276 (not shown). The other units / modules 276 may include, but are not limited to, a monitoring module, a data analytics module, and the like.

[0081] In an aspect, the processor 210, using the receiving module 262, is configured to receive live alarm data associated with all the nodes (i.e., nodes 102 through 108) from the EMS cluster 110. The alarms at the nodes may be monitored by the one or more EMSs of the vendor EMS cluster 110, and the live alarm datacollected as a result of the monitoring process may be stored as the live alarm data in the database 290. Further, the processor 210, using the receiving module 262, may also store the live alarm data received from the EMS cluster 110 in the database 290. The live alarm data comprises real-time information related to live alarms or active alarms at the nodes within the communication network 100. This real-time information related to the live alarms includes details such as the alarm’s raise time, severity level, affected nodes, and specific fault identifiers, such as hardware fault identifiers and software fault identifiers. In a non-limiting example, an entry of live alarm data into the database 290 may indicate that at 14:32: 10 1ST, a node (i.e., gNB) in a specific sector (i.e., Sector 2) experienced a “Transmission Failure” with a “Critical” severity level.

[0082] In an embodiment, the processor 210, using the receiving module 262, is configured to receive, via the UI 160-1 of the user device 160, an input for generating the visualization of the live alarm data associated with all the nodes in the communication network 100 (i.e., nodes 102 through 108). Further, the processor 210, using the transmitting module 264, is configured to transmit the API call request to the scheduler 240 via the microservice(s) 250 based on the input received from the user device 160. Furthermore, the processor 210, using the triggering module 266, is configured to trigger the scheduler 240 to fetch, from the database 290, the live alarm data and geographical location information corresponding to each of the nodes in a geographical location based on the transmitted API call request. In a non-limiting example, the scheduler 240 may fetch the live alarm data and the geographical location information from the database 290 at periodic time intervals, for example, after every 15 minutes, 30 minutes, or 1 hour.

[0083] In other words, when an input including a request for generating the live alarm visualization data is received from the user device 160 at the server 140, the processor 210 triggers the scheduler 240 to periodically fetch the live alarm data and geographical location information corresponding all the nodes within the communication network 100.

[0084] Further, the processor 210, using the data processing module 268, is configured to determine, from the nodes within the communication network 100, an aggregated count of a group of nodes that include the service affecting alarms (for example, nodes 102, 104 among the nodes 102 through 108) based on the live alarm data and the geographical location information fetched from the database 290. Further, the service affecting alarms correspond to outage alarms that are updated in real-time.

[0085] The group of nodes includes a total number of nodes within a group that share a common characteristic, such as experiencing the same type of alarms. For instance, if five nodes within a cluster report a “Power Failure” alarm, the aggregated count for the “Power Failure” alarm is five. The aggregated count of the group of nodes corresponds to a unique count of the group of nodes for each cluster among multiple node clusters present in the geographical location. The unique count of the group of nodes refers to the number of distinct nodes within a group that are affected by alarms, ensuring that each node is counted only once, regardless of the number of alarms it reports. This helps in assessing a spread and impact of faults across the communication network 100 and aiding in prioritizing maintenance and troubleshooting efforts to be initiated by the NOC team.

[0086] Furthermore, the processor 210, using the data processing module 268, is configured to generate the live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes. Furthermore, the processor 210, using the display module 270, is configured to display the generated live alarm visualization data on the user interface 160-1 of the user device 160. The visual representation of the live alarm visualization data may include an option using which a near real time view of the group of nodes that includes the service affecting alarms can be analyzed by the end user.

[0087] In an aspect, the processor 210, using the data processing module 268, is configured to determine, for each node among the group of nodes that includes theservice affecting alarms, a raise time of the alarm based on the live alarm data. Additionally, the processor 210, using the display module 270, is configured to display, on the user interface 160-1, the live alarm visualization data including the raise time of the alarm and the aggregated count of the group of nodes. The raise time of the alarm may refer to a specific time at which the alarm is generated or reported by the nodes upon detecting a fault or abnormal condition at the nodes. An accurate recording of the raise time is essential for event correlation, troubleshooting, and performance analysis associated with the services provided by telecom operators.

[0088] Further, the processor 210, using the data processing module 268, may be configured to store, in the memory 215, information related to the group of nodes and the service affecting alarms. In another embodiment, the processor 210, using the data processing module 268, may store the live alarm visualization data in the distributed file system 150.

[0089] In an aspect, the processor 210, using the data processing module 268, is configured to store a series of live alarm visualization data entries in the memory 215. Each entry of the live alarm visualization data in the memory 215 may be associated with a timestamp indicating a time of generation of the live alarm visualization data. Further, the processor 210, using the display module 270, is configured to display a selectable view option (not shown) on the UI 160-1. The selectable view option may correspond to an option for accessing the live alarm visualization data stored in the memory 215. When an input via the displayed selectable view option is received by the receiving module 262, the processor 210, using the data extraction module 272, may extract or fetch latest live visualization data from the memory 215 based on the associated timestamp. Thereafter, the processor 210, using the display module 270, may be configured to display the fetched latest live alarm visualization data entry on the UI 160-1 of the user device 160.

[0090] In an aspect, the processor 210, using the monitoring module 274, is configured to monitor live alarm data of the group of nodes based on the information related to the group of nodes and the service affecting alarms stored in the memory 215, and pass the result of the monitoring to the data processing module 268. Further, the processor 210, using the data processing module 268, determines whether there is change in a status of one or more service affecting alarms based on the monitoring results captured by the monitoring module 274, and updates the live alarm data in the database 290 if any change in the status of the one or more service affecting alarms is determined. In a non-limiting example, to update the live alarm data in the database 290, the data processing module 268 may add data associated with the service affecting alarms to the database 290 or may remove the data associated with the service affecting alarms from the database 290.

[0091] In an embodiment, the processor 210, using the data processing module 268, may update the live alarm visualization data based on the increment or the drop in the alarm data traffic of the group of nodes in accordance with the determination performed by the CDC module 245.

[0092] The database 290 may correspond to a centralized database system configured to store and manage the live alarm data. The database 290 is configured to maintain a comprehensive record of active / live alarms, attributes of the active / live alarms, and associated metadata. The database 290 is utilized by the processor 210 for storing the incoming live alarm data.

[0093] Although FIG. 2 illustrates one example of the server 140, various changes may be made to FIG. 2. Further, the server 140 may include any number of components in addition to those shown in FIG. 2, without deviating from the scope of the present disclosure. For example, the server 140 may include a console host to control devices that communicates with the server 140 via a wired or a wireless medium or the server 140 may be coupled to an external database that provides data storage space to the server 140. Further, various components in FIG. 2 may becombined, further subdivided, or omitted, and additional components may be added according to particular needs.

[0094] FIG. 3 illustrates a flow diagram depicting a call flow 300 between the UI 160-1 and the components of the server 140, in accordance with an embodiment of the present disclosure. With reference to FIG. 3, the user device 160 sends the input including the request for generating the live alarm visualization data corresponding to the nodes 102 through 108 to the server 140.

[0095] As shown in FIG. 3, at step 302, the input request is received by the processor 210 of the server 140 via the receiving module 262, and the processor 210 initiates the API call request based on the input. The API call request corresponds to a structured command generated by the processor 210 of the server 140 upon receiving the request for generating the live alarm visualization data. The API call request may encapsulate a set of protocols that can allow the microservice(s) 250 to interact with the scheduler 240.

[0096] Further, at step 304, the processor 210 transmits the API call request to the API gateway 170. At step 306, the microservice 250 receives the API call request transmitted by the processor 210 via the API gateway 170. At step 308, the processor 210 via the microservice 250 triggers, based on the transmitted API call request, the scheduler 240 to fetch the live alarm data from the database 290. At step 310, the scheduler 240 fetches the live alarm data and the response including the live alarm data is received by the processor 210 (steps 312, 314). At step 316, the processor 210 generates the live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes. Furthermore, at step 318, the processor 210, using the display module 270, control the user device 160 to display the generated live alarm visualization data on the UI 160-1.

[0097] FIG. 4 illustrates a flowchart depicting a method 400 for monitoring the performance of nodes (for example, nodes 102 through 108) in the communication network 100, in accordance with an embodiment of the present disclosure. Themethod 400 comprises a series of operation steps indicated by blocks 402 through412. The method 400 starts at block 402.

[0098] At block 402, the receiving module 262 receives, via the UI 160-1 of the user device 160, the input for generating the visualization of the live alarm data associated with all the nodes in the communication network 100 (i.e., nodes 102 through 108).

[0099] At block 404, the transmitting module 264 transmits the API call request to the scheduler 240 via the microservice(s) 250 when the input for generating the visualization of the live alarm data associated with all the nodes is received by the receiving module 262 the from the user device 160.

[0100] At block 406, the triggering module 266 triggers the scheduler 240 to fetch the live alarm data and geographical location information corresponding to each of the nodes in a geographical location from the database 290 based on the API call request transmitted by the transmitting module 264.

[0101] At block 408, the data processing module 268 determines, from the nodes (102 through 108) within the communication network 100, an aggregated count of a group of nodes that include the service affecting alarms (for example, nodes 102, 104 among the nodes 102 through 108) based on the live alarm data and the geographical location information fetched from the database 290.

[0102] At block 410, the data processing module 268 generates the live alarm visualization data corresponding to the nodes in the communication network 100 based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes that includes the service affecting alarms.

[0103] At block 412, the display module 270 displays the generated live alarm visualization data on the user interface 160-1 of the user device 160. In particular,1 the processor 210, using the display module 270, controls the user device 160 to display the generated live alarm visualization data on the user interface 160-1.

[0104] FIG. 5 illustrates a flowchart depicting a method 500 for fetching and displaying latest live alarm visualization data on the UI 160-1, in accordance with an embodiment of the present disclosure. The method 500 comprises a series of operation steps indicated by blocks 502 through 508. The method 500 starts at block 502.

[0105] At block 502, the data processing module 268 stores the series of live alarm visualization data entries in the memory 215. In a non-limiting example, each time the live alarm visualization data is generated, a data entry is performed by the data processing module 268 to store the live alarm visualization data in the memory 215 along with a timestamp of generation of the live alarm visualization data. Thus, the data processing module 268 associates each entry of the live alarm visualization data in the memory 215 with a timestamp indicating the time of generation of the live alarm visualization data.

[0106] At block 504, the display module 270 displays the selectable view option on the UI 160-1 for accessing the live alarm visualization data when the generated live alarm visualization data is displayed on the UI 160-1. In a non-limiting example, the selectable view option may be an option provided to the end user using which the user can view or download the live alarm visualization data stored in the memory 215.

[0107] At block 506, the data extraction module 272 fetches the latest live visualization data from the memory 215 based on the associated timestamp when the input from the user device 160 is received by the receiving module 262 via the displayed selectable view option.

[0108] At block 508, the display module 270 further displays the fetched latest live alarm visualization data along with the timestamp of data entry on the UI 160-1 of the user device 160.

[0109] FIG. 6 illustrates a flowchart depicting a method 600 for updating the live alarm visualization data, in accordance with an embodiment of the present disclosure. The method 600 comprises a series of operation steps indicated by blocks 602 through 612. The method 600 starts at block 602.

[0110] At block 602, the data processing module 268 stores the information related to the group of nodes and the service affecting alarms into the memory 215. In a non-limiting example, the data processing module 268 may analyze the live alarm data of all the nodes 102 through 108 in the communication network 100 to identify the information related to the nodes that includes the service affecting alarms and information associated with the service affecting alarms.

[0111] At block 604, the monitoring module 274 monitors live alarm data of the group of nodes (for example, node 102, 104) based on the information related to the group of nodes and the service affecting alarms stored in the memory 215, and pass the result of the monitoring to the data processing module 268.

[0112] At block 606, the data processing module 268 determines whether there is change in the status of the identified service affecting alarms based on the monitoring results captured by the monitoring module 274.

[0113] At block 608, the CDC module 245 identifies one or more changes in the alarm data processing rates associated with a corresponding node (i.e., node 102 and 104) of the group of nodes based on the data throughput of the corresponding node.

[0114] At block 610, the CDC module 245 determine the increment or the drop in the alarm data traffic of the group of nodes based on the identification of the one or more changes in the alarm data processing rates.

[0115] In an implementation, at block 612, the data processing module 268 updates the live alarm data in the database 290 if any change in the status of the one or more service affecting alarms is determined at block 606. In a non-limiting example, to update the live alarm data in the database 290, the data processing module 268 mayadd data associated with the service affecting alarms to the database 290 or may remove the data associated with the service affecting alarms from the database 290.

[0116] In another implementation, at block 612, the data processing module 268 may update the live alarm visualization data based on the increment or the drop in the alarm data traffic of the group of nodes in accordance with the identification and the determination performed by the CDC module 245 at blocks 608 and 610 (indicated by dotted lines). In particular, according to an implementation, the dotted lines provides an indication that the data processing module 268 may update the live alarm data in the database 290 directly on the basis of the determination performed at block 606 by skipping the identification and the determination steps performed by the CDC module 245 at blocks 608 and 610.

[0117] Now, referring to the technical abilities and advantageous effect of the present disclosure, various operational advantages may be provided by one or more embodiments disclosed herein such as providing real-time data visualization of live alarms for the service affecting nodes in the communication network by generating and displaying the live alarm visualization data on the user interface. The real-time data visualization of live alarms enables the network operation team to visualize, in real-time, the service affecting nodes and assign priority in attending the service affecting nodes in any geography or the maintenance cluster, thereby improving customers experience. Further, the real-time data visualization of live alarms eliminates the need for an exhaustive analysis of all the nodes in the communication network by focusing only on the nodes that includes the service affecting alarms, thereby reducing the time and effort required for analysis.

[0118] Further, the one or more embodiments disclosed herein helps the NOC team to in visualizing real-time data of live alarms for the nodes that includes the service affecting alarms, on a single glass pane view, thereby improving end user experience.

[0119] Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according toembodiments of the technology, and / or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) in the flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general -purpose computer or special purpose computer, or other programmable processing apparatus to perform a group of operations comprising the operations or blocks described in connection with the disclosed methods.

[0120] Further, these computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer- readable memory or memory devices (for example, the memory 215) that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).

[0121] It will further be appreciated that the term “computer program instructions” as used herein refer to one or more instructions that can be executed by the one or more processors (for example, the processor 210) to perform one or more functions as described herein. The instructions may also be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely.

[0122] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-describedembodiments are therefore to be construed in all aspects as illustrative and not restrictive.

[0123] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

[0124] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.LIST OF REFERENCE NUMERALS

[0125] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:100 - Communication network-108 - GNodeB (gNB) - Element Management System (EMS) cluster '-108' - Vendor EMSs - Network - Load balancer - Server - Distributed file system - User device -1 - User Interface (UI) -2 - Communication unit - Gateway - Processor - Memory A - Instructions - Communication Interface - Parser(s) - Interface(s) - Distributed streaming platform - Scheduler - Change Data Capture (CDC) Module - Microservice(s) - Processing unit(s) / modules(s) - Receiving module - Transmitting module - Triggering module - Data processing module - Display module - Data extraction module - Monitoring module - Other units / modules - Database295 - Communication bus300 - Call flow 300 between the UI 160-1 and the components of the server 140400 - Method for monitoring the performance of nodes (gNBs 102-108)500 - Method for fetching and displaying latest live alarm visualization data on the UI 160-1600 - Method for updating the live alarm visualization data

Claims

We Claim:

1. A method (400) for monitoring performance of a plurality of nodes (102-108) in a communication network (100), the method comprising: receiving, by a receiving module (262) via a User Interface (UI) (160- l)of a user device, an input for generating visualization of live alarm data associated with the plurality of nodes (102-108); transmitting, by a transmitting module (264) based on the input, an Application Programming Interface (API) call request to a scheduler (240) via a microservice of a plurality of microservices (250); triggering, by a triggering module (266) based on the API call request, the scheduler to fetch, from a database (290), the live alarm data and geographical location information corresponding to the plurality of nodes (102- 108) in a geographical location; determining, by a data processing module (268) from the plurality of nodes (102-108), an aggregated count of a group of nodes that include one or more service affecting alarms based on the live alarm data and the geographical location information; generating, by the data processing module (268), live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes; and displaying, by a display module (270), the generated live alarm visualization data on the UI of the user device.

2. The method (400) as claimed in claim 1, wherein the aggregated count of the group of nodes corresponds to a unique count of the group of nodes for each cluster of a plurality of node clusters in the geographical location, and wherein the one or more service affecting alarms correspond to outage alarms that are updated in real-time.

3. The method (400) as claimed in claim 1, wherein the live alarm data and the geographical location information is fetched from the database (290) via the scheduler (240) at periodic time intervals.

4. The method (400) as claimed in claim 1, further comprising: storing, by the data processing module (268) in a memory (215), a series of live alarm visualization data entries, wherein each entry of the live alarm visualization data in the memory is associated with a timestamp indicating a time of generation of the live alarm visualization data; displaying, by the display module (270), a selectable view option on the UI (160-1), wherein the selectable view option corresponds to an option for accessing the stored live alarm visualization data; fetching, by a data extraction module (272) upon receiving an input via the displayed selectable view option, latest available live alarm visualization data entry from the memory (215) based on the associated timestamp; and displaying, by the display module (270), the fetched live alarm visualization data entry on the UI (160-1).

5. The method (400) as claimed in claim 1, further comprising: determining, by the data processing module (268), for each node of the group of nodes, a raise time of the alarm based on the live alarm data; and displaying, by the display module (270), on the UI, the live alarm visualization data including the raise time of the alarm and the aggregated count of the group of nodes.

6. The method (400) as claimed in claim 1, further comprising: storing (602), by the data processing module (268) in a memory (215), information related to the group of nodes and the one or more service affecting alarms; monitoring (604), by a monitoring module (274), based on the information stored in the memory, live alarm data of the group of nodes todetermine (606) a change in a status of the one or more service affecting alarms; and updating (612), by the data processing module (268), the live alarm data in the database based on the change in the status of the one or more service affecting alarms.

7. The method (400) as claimed in claim 5, wherein updating the live alarm data corresponds to an addition of data associated with the one or more service affecting alarms to the database or a deletion of the data associated with the one or more service affecting alarms from the database (290).

8. The method (400) as claimed in claim 1, further comprising: receiving, by the receiving module (262) from one or more Element Management Systems (EMSs) (110), the live alarm data corresponding to the plurality of nodes (102-108); and storing, by the data processing module (268), the live alarm data received from the one or more EMSs (110) in the database (290).

9. The method (400) as claimed in claim 1, further comprising: identifying, by a Change Data Capture (CDC) module (245), one or more changes in alarm data processing rates associated with a corresponding node of the group of nodes based on a data throughput of the corresponding node; determining, by the CDC module (245), an increment or a drop in alarm data traffic of the group of nodes based on the one or more changes in the alarm data processing rates; and updating, by the data processing module (268), the live alarm visualization data based on the increment or the drop in the alarm data traffic of the group of nodes.

10. A system (140) for monitoring performance of a plurality of nodes (102-108) in a communication network (100), the system comprising:a database (290) configured to store live alarm data of the plurality of nodes (102-108); a receiving module (262) configured to receive, via a User Interface (UI) (160-1) of a user device (160), an input for generating visualization of live alarm data associated with the plurality of nodes (102-108); a transmitting module (264) configured to transmit, based on the input, an Application Programming Interface (API) call request to a scheduler (240) via a microservice of a plurality of microservices (250); a triggering module (266) configured to trigger the scheduler to fetch, from the database (290), the live alarm data and geographical location information corresponding to the plurality of nodes (102-108) in a geographical location based on the API call request; a data processing module (268) configured to: determine, from the plurality of nodes (102-108), an aggregated count of a group of nodes that include one or more service affecting alarms based on the live alarm data and the geographical location information; and generate live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes; and a display module (270) configured to display the live alarm visualization data on the UI (160-1) of the user device (160).

11. The system (140) as claimed in claim 10, wherein the aggregated count of the group of nodes corresponds to a unique count of the group of nodes for each cluster of a plurality of node clusters in the geographical location, and wherein the one or more service affecting alarms correspond to outage alarms that are updated in real-time.

12. The system (140) as claimed in claim 10, wherein the live alarm data and the geographical location information is fetched from the database (290) via the scheduler (240) at periodic time intervals.

13. The system (140) as claimed in claim 10, further comprising a data extraction module (272), wherein the data processing module (268) is further configured to store a series of live alarm visualization data entries in a memory (215), wherein each entry of the live alarm visualization data in the memory is associated with a timestamp indicating a time of generation of the live alarm visualization data, wherein the display module (270) is further configured to display a selectable view option on the UI, wherein the selectable view option corresponds to an option for accessing the stored live alarm visualization data, wherein the data extraction module (272) is configured to fetch, upon receiving an input via the displayed selectable view option, latest live visualization data from the memory (215) based on the associated timestamp, and wherein the display module (270) is further configured to display the fetched latest live alarm visualization data entry on the UI (160-1).

14. The system (140) as claimed in claim 10, wherein the data processing module (268) is further configured to determine, for each node of the group of nodes, a raise time of the alarm based on the live alarm data, and wherein the display module (270) is further configured to display, on the UI (160-1), the live alarm visualization data including the raise time of the alarm and the aggregated count of the group of nodes.

15. The system (140) as claimed in claim 10, further comprising a monitoring module (274),wherein the data processing module (268) is further configured to store, in a memory (215), information related to the group of nodes and the one or more service affecting alarms, wherein the monitoring module (274) is configured to monitor, based on the information stored in the memory (215), live alarm data of the group of nodes to determine a change in a status of the one or more service affecting alarms, and wherein the data processing module (268) is further configured to update the live alarm data in the database (290) based on the change in the status of the one or more service affecting alarms.

16. The system (140) as claimed in claim 15, wherein, to update the live alarm data, the data processing module (268) is configured to add data associated with the one or more service affecting alarms to the database (290) or remove the data associated with the one or more service affecting alarms from the database (290).

17. The system (140) as claimed in claim 10, wherein the receiving module (262) is further configured to receive, from one or more Element Management Systems (EMSs) (110), the live alarm data corresponding to the plurality of nodes; and wherein the data processing module (268) is further configured to store, in the database (290), the live alarm data received from the one or more EMSs (HO).

18. The system (140) as claimed in claim 10, further comprising a Change Data Capture (CDC) module (245) configured to: identify one or more changes in alarm data processing rates associated with a corresponding node of the group of nodes based on a data throughput of the corresponding node; anddetermine an increment or a drop in alarm data traffic of the group of nodes based on the one or more changes in the alarm data processing rates, wherein the data processing module (268) is further configured to update the live alarm visualization data based on the increment or the drop in the alarm data traffic of the group of nodes.

19. A computer program product comprising computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations comprising: receiving, via a User Interface (UI) of a user device, an input corresponding to visualization of live alarm data associated with a plurality of nodes; transmitting, based on the input, an Application Programming Interface (API) call request to a scheduler via a microservice of a plurality of microservices; triggering the scheduler to fetch, from a database, live alarm data and geographical location information corresponding to a plurality of nodes in a geographical location; determining, from the plurality of nodes, an aggregated count of a group of nodes that include one or more service affecting alarms based on the live alarm data and the geographical location information; generating live alarm visualization data based on the determined aggregated count of the group of nodes and the live alarm data corresponding to each node of the group of nodes; and displaying the generated live alarm visualization data on the UI of the user device.

Images