DESC:FORM 2
THE PATENTS ACT, 1970 (39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)

SYSTEM AND METHOD FOR MONITORING PERFOMANCE OF NODES IN A COMMUNICATION NETWORK

Jio Platforms Limited, an Indian company, having registered address at Office -101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India

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

TECHNICAL FIELD
[0001] 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 monitoring performance of nodes and visualizing a mass outage area for outage nodes in a communication network.
BACKGROUND OF THE INVENTION
[0002] 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.
[0003] 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 Operation Centers (NOCs) play a crucial role by monitoring 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.
[0004] Heretofore, network operations team of conventional communication networks relied on monitoring tools and terminals for monitoring network nodes that generate service-affecting 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 can cause a direct impact on a quality of service provided by the network nodes. 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 visualization tools.
[0005] Accordingly, conventional monitoring tools that have been utilized so far offered only individual site-wise details of alarms and failed to offer a holistic view of a mass outage area for outage nodes across different geographies. This caused difficulty for network operators, and it became cumbersome to manage broader geographical implications of incidents such as mass outage nodes, which impacted the performance of the communication networks. An outage node refers to any node in a communication network where disruptions or failures in one or more network services occur.
[0006] This limitation of the conventional monitoring tools further hampered the ability of the network operations teams to perform timely and effective analysis of data related to the mass outage nodes, which is crucial for minimizing service disruptions and optimizing network performance.
[0007] Therefore, to overcome aforementioned challenges and limitations associated with the conventional monitoring tools, there lies a need for a system and a method that can help the network operations team in monitoring the performance of the nodes in the communication network, accurately and extensively.
SUMMARY
[0008] 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.
[0009] According to an aspect of the present disclosure, disclosed herein is a method for monitoring performance of nodes in a communication network. The method comprises receiving, by an acquisition module from a user device, a first input for alarm data corresponding to outage nodes within a geographical region and triggering, by an execution module based on the first input, a scheduler to fetch the alarm data corresponding to the outage nodes from a database. Furthermore, the method comprises determining, by a determination module, an aggregated count of the outage nodes for one or more locations of a plurality of locations within the geographical region based on the fetched alarm data and geographical location information of the outage nodes. The aggregated count of the outage nodes corresponds to a unique cluster-wise count of the outage nodes for the one or more locations. Thereafter, the method comprises generating, by a data processing module, alarm visualization data based on the determined aggregated count of the outage nodes and controlling, by the data processing module, the user device to display the generated alarm visualization data corresponding to the outage nodes.
[0010] In one or more implementations, the method comprises categorizing, by the data processing module, the one or more locations within the geographical region based on a predefined criteria associated with the fetched alarm data and the determined aggregated count of the outage nodes. The predefined criteria include one or more of severity of outages, number of affected nodes, or duration of outages. Further, the method comprises assigning, by the data processing module, a sequential priority to the categorized one or more locations for remedial actions.
[0011] In one or more implementations, the unique cluster-wise count of the outage nodes corresponds to a count of the outage nodes for each maintenance zone of one or more maintenance zones within the one or more locations.
[0012] In one or more implementations, the generated alarm visualization data corresponding to the outage nodes is displayed on a User Interface (UI) of the user device in a layered map view.
[0013] In one or more implementations, the layered map view comprises at least one of a count of one or more of outage sites, outage cells and outage alarms within the one or more locations, or one or more-color coded indicators representative of a sequential priority assigned to the one or more locations for the remedial actions.
[0014] In one or more implementations, the method comprises controlling, by the data processing module, the UI to display one or more options for visualizing the alarm data corresponding to a mass outage area within the geographical region and receiving, by the acquisition module via the UI of the user device, a second input in response to the display of the one or more options for visualizing the alarm data. Further, the method comprises controlling, by the data processing module, the UI of the user device to display the generated alarm visualization data based on the second input.
[0015] In one or more implementations, the second input corresponds to a selection operation performed by a user in response to the display of the one or more options for visualizing the alarm visualization data corresponding to the mass outage area.
[0016] According to another aspect of the present disclosure, disclosed is a system for monitoring performance of nodes in a communication network. The system comprises an acquisition module, an execution module, a determination module, and a data processing module. The acquisition module is configured to receive, from a user device, a first input for alarm data corresponding to outage nodes within a geographical region. The execution module is configured to trigger, based on the first input, a scheduler to fetch the alarm data corresponding to the outage nodes from a database. Furthermore, the determination module is configured to determine an aggregated count of the outage nodes for one or more locations of a plurality of locations within the geographical region based on the fetched alarm data and geographical location information of the outage nodes. The aggregated count of the outage nodes corresponds to a unique cluster-wise count of the outage nodes for the one or more locations. The data processing module is configured to generate alarm visualization data based on the determined aggregated count of the outage nodes and control the user device to display the generated alarm visualization data corresponding to the outage nodes. The unique cluster-wise count of the outage nodes corresponds to a count of the outage nodes for each maintenance zone of one or more maintenance zones within the one or more locations. The generated alarm visualization data corresponding to the outage nodes is displayed on a User Interface (UI) of the user device in a layered map view. The layered map view comprises at least one of a count of one or more of outage sites, outage cells, and outage alarms within the one or more locations or one or more color coded indicators representative of a sequential priority assigned to the one or more locations for remedial actions.
[0017] In one or more implementations, the data processing module is configured to categorize, based on a predefined criteria associated with the fetched alarm data and the determined aggregated count of the outage nodes, the one or more locations within the geographical region. The predefined criteria include one or more of severity of outages, number of affected nodes, or duration of outages. The data processing module is further configured to assign a sequential priority to the categorized one or more locations for remedial actions.
[0018] In one or more implementations, the data processing is configured to control the UI to display one or more options for visualizing the alarm data corresponding to a mass outage area within the geographical region. The acquisition module is configured to receive, via the UI, a second input in response to the display of the one or more options for visualizing the alarm data.
[0019] In one or more implementations, the data processing module is configured to control, based on the second input, the UI to display the generated alarm visualization data. The second input corresponds to a selection operation performed by a user in response to the display, on the UI, of the one or more options for visualizing the alarm data corresponding to the mass outage area.
BRIEF DESCRIPTION OF DRAWINGS
[0020] 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.
[0021] FIG. 1 illustrates a block diagram depicting a communication system for monitoring performance of nodes in a communication network, in accordance with an embodiment of the present disclosure.
[0022] FIG. 2 illustrates a block diagram depicting various components of a processor of the communication system, in accordance with an embodiment of the present disclosure.
[0023] FIG. 3 illustrates a User Interface (UI) framework depicting an example UI for visualizing a real-time alarm data corresponding to a mass outage area, in accordance with an embodiment of the present disclosure.
[0024] FIG. 4 illustrates a UI framework depicting an example UI for visualizing the real-time alarm data corresponding to a specific outage area, in accordance with an embodiment of the present disclosure.
[0025] FIG. 5 illustrates a flowchart depicting a method for monitoring the performance of the nodes in the communication network, in accordance with an embodiment of the present disclosure.
[0026] FIG. 6 illustrates a schematic architecture diagram depicting a computing system, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
[0027] 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.
[0028] 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.
[0029] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” or “some implementations” which may each refer to one or more or all of the same or different embodiments or implementations. 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” or “in an implementation” refers to one embodiment or one implementation and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.” Further, the term, for example, “in one or more implementations” refers to “at least one implementation, or more than one implementation, or all implementations.”
[0030] 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.”
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] The present invention relates to a system and a method for monitoring performance of nodes in a communication network. An aspect of the present disclosure is to provide a system and a method for visualizing, in real-time, a mass outage area for outage nodes in the communication network that enables to assign priority in attending the outage nodes in any geography or maintenance cluster, thereby improving customers’ experience.
[0036] Another aspect of the present disclosure is to provide a system and a method that facilitates efficient and seamless communication between a User Interface (UI) and components of a server for generating real-time alarm visualization data corresponding to the mass outage area, on a single glass pane view, thereby improving users’ experience.
[0037] Another aspect of the present disclosure is to provide a system and a method that eliminates need for an exhaustive analysis of all the nodes in the communication network by focusing only on the outage nodes, thereby reducing analysis time and effort required during monitoring of the performance of the nodes within the communication network.
[0038] In order to facilitate an understanding of the disclosed invention, a number of terms are defined below.
[0039] A node refers to an individual network entity involved in data transmission or service delivery within a communication network.
[0040] A Network Element (NE) refers to any individual device or logical entity within a telecommunication network, such as a router, a switch, or a base station. The NE is the lowest manageable unit in a network and supports execution of specific network functions.
[0041] A Network Operations Center (NOC) refers to a centralized location where network administrators monitor and manage architecture and infrastructure of deployed communication networks.
[0042] A service-affecting alarm refers to notifications or alerts, generated by monitoring tools, indicating potential disruptions or failures within a network infrastructure that can cause a direct impact on a quality of service provided by network nodes.
[0043] An alarm corresponds to a network generated event indicating a deviation from normal operational behavior, typically triggered by a fault, a threshold breach, or a service affecting condition.
[0044] An active alarm database corresponds to a data repository storing real time fault management notifications, allowing network operators to view, analyze, and respond to ongoing outages.
[0045] A historical database corresponds to a long-term storage system for past network alarms and faults, used for trend analysis, predictive maintenance, and post event troubleshooting.
[0046] A load balancer, in the context of the present disclosure, corresponds to a network device or a software that distributes incoming data traffic among multiple servers to ensure optimal resource utilization, fault tolerance and system stability. The load balancer ensures efficient resource utilization and minimizes system overload.
[0047] An outage node refers to any node in a communication network where disruptions or failures in one or more network services occur.
[0048] An Element Management System (EMS) corresponds to a management system that handles a specific subset of network functions, focusing on management of individual Network Elements (NEs). The EMS is responsible for fault management, configuration management, performance monitoring, and security management within the scope of its associated NEs. The EMS operates below a Network Management System (NMS) in network management hierarchy.
[0049] An NMS refers to a higher-level management system that coordinates and monitors overall operations of a telecommunication network. The NMS integrates multiple EMSs to manage the entire network infrastructure and provides end-to-end fault, configuration, and performance management.
[0050] A distributed streaming platform corresponds to a real time processing system designed to handle high volume continuous data flows for fault and performance management. The distributed streaming platform supports event driven analytics and alarm correlation.
[0051] A microservices framework corresponds to a network architecture, where independent microservices communicate over Application Programming Interfaces (APIs), enabling modular, scalable, and resilient network management applications.
[0052] A microservice refers to individual components that perform specific tasks within a system, for example, a test execution microservice could be responsible for running the network tests, while data processing microservice could handle data transformation and storage.
[0053] An API Gateway corresponds to a centralized interface that exposes network management functionalities through standardized REpresentational State Transfer (REST) APIs enabling seamless interaction between external applications and the NMSs.
[0054] A User Interface (UI), in context of the present disclosure, corresponds to a graphical front-end application that represents real time network monitoring data allowing the network operators to interact with alarms, view outages and conduct analysis.
[0055] A distributed file system corresponds to a scalable and fault tolerant data storage system that distributes network event logs across multiple nodes for redundancy and fast retrieval.
[0056] Fault management refers to a network function responsible for detecting, isolating, and resolving issues affecting service availability and performance. The fault management includes alarm generation, correlation, and resolution processes.
[0057] Performance management refers to a network function of continuous monitoring and reporting of network parameters to ensure optimal service quality, including alarm thresholds, Key Performance Indicators (KPIs) and predictive analysis.
[0058] 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.
[0059] FIG. 1 illustrates a block diagram depicting a communication system 100 for monitoring the performance of the nodes in the communication network, in accordance with an embodiment of the present disclosure. The embodiment of the communication system 100 shown in FIG. 1 is for illustration only. In particular, the communication system 100 corresponds to a communication system and hereinafter may also be referred to as the “system 100”. Other embodiments of the communication system 100 may be used without departing from the scope of this disclosure.
[0060] As shown in FIG. 1, the communication system 100 includes a vendor Element Management System (EMS) cluster 110 including a plurality of vendor associated EMSs 101' through 104' (hereinafter also referred to as vendor EMSs 101’ through 104’ or EMSs 101’ through 104’), where each vendor EMS is managing multiple nodes (e.g., base stations). For instance, nodes 101, 102, 103, and 104 are shown in FIG. 1 for exemplary purposes, without departing form the scope of the present disclosure.
[0061] The nodes 101 through 104 may correspond to network devices such as routers, switches, and other infrastructure components. Each node continuously monitors its own operational parameters. When an anomaly occurs such as hardware degradation, service degradation or outright failure, the node generates an alarm event. The nodes 101 through 104 may perform initial self-diagnostics before reporting issues, ensuring that only data related to the service affecting alarms are forwarded. The nodes 101 through 104 communicate with their respective EMS using vendor specific protocols and send detailed alarm data including timestamps, severity levels, and fault types, allowing the EMSs 101’ though 104’ to gather, standardize, and preprocess the data.
[0062] 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 Fifth Generation/New Radio (5G/NR) base station (gNB), a macrocell, a femtocell, a Wireless Fidelity (WiFi) Access Point (AP), or other wirelessly enabled devices. The nodes and the vendor EMSs may communicate with each other via wireless communication protocols, e.g., 5G/NR Third Generation Partnership Project (5G/NR 3GPP) New Radio interface/access (NR), Long Term Evolution (LTE), LTE Advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi 802.11a/b/g/n/ac, etc.
[0063] Each of the vendor EMSs 101’ through 104’ may be configured to monitor, manage, and control individual NEs i.e., the nodes 101 through 104 within the communication system 100. Each of the vendor EMSs 101’ through 104’ may be controlled by EMS server(s). Each of the EMSs 101’ through 104’ is configured to collect and aggregate the alarm data from the network node it oversees. This aggregation enables a local consolidation of the alarm data before transmission. Each of the EMSs 101’ through 104’ is configured to collect and preprocess raw data from the nodes 101 through 104 and standardize vendor specific data formats into a common format for upstream communication. Once aggregated and normalized, each of the EMSs 101’ through 104’ forwards the alarm data via a secure network channel to the server 140. The EMSs 101’ through 104’ may be further configured to configure the NEs, perform the fault management, and optimize the performance of the communication network to ensure smooth network operations. Each of the vendor EMSs 101’ through 104’ acts as an intermediary layer between the nodes 101 through 104 and the NMS.
[0064] The communication system 100 further includes a network 120, a load balancer 130, a server 140, a distributed file system 150, a user device 160 and an API gateway 170. The server 140 is connected to the vendor EMS cluster 110 via the network 120 followed by the load balancer 130.
[0065] The network 120 may correspond to one of an Internet, a proprietary Internet Protocol (IP) network, or other data network. The network 120 may include wired and/or wireless networks. For example, the network 120 may include a cellular network for e.g., a 5G network, a LTE network, a 3G network, a Code Division Multiple Access (CDMA) network, etc.), a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, and/or a combination of these or other types of networks.
[0066] The network 120 is configured to provide communication channels required to transmit the alarm data between the EMS cluster 110 and the server 140. The network 120 supports real time data transfer, which is critical for timely outage detection and response.
[0067] The load balancer 130 is an intermediary between the network 120 and the server 140. The load balancer 130 is configured to evenly distribute incoming alarm data from the vendor EMS cluster 110 across available processing resources in the server 140. This ensures no single processor is overloaded. In event of failure of a processing unit, the load balancer 130 reroutes traffic, maintaining continuous data flow and system’s availability. By dynamically managing the data streams, the load balancer 130 supports system’s scalability as the volume of alarms increases during a mass outage.
[0068] The server 140 forms a core component of the system 100, where real-time processing, data storage, and visualization generation occur. The server 140 may include various components such as a parser 141, a distributed streaming platform 142, a memory 143 including a microservices framework 143-1, a scheduler 144, a processor 145, an active alarm database 146, a history alarm database 147, a Change Data Capture (CDC) Module 148, and a communication interface 149.
[0069] The parser 141 is configured to parse and extract information from the incoming alarm data, decode a format of the alarm data, and transform raw alarm data into structured records for further processing. The parser 141 receives unprocessed alarm data from the load balancer 130 and breaks down the raw data into individual tokens or fields (for example, timestamp, node identifier, alarm type, severity, error types) to prepare for further processing.
[0070] The distributed streaming platform 142 is configured to ingest the alarm data, process the ingested alarm data, and distribute alarm data streams to the processor 145. The distributed streaming platform 142 is further configured to analyze incoming alarm events, correlate related events, and identify patterns that may indicate the mass outage, or other issue.
[0071] The memory 143 may include the microservices framework 143-1 having a plurality of microservices. The microservices framework 143-1 corresponds to a network architecture, where independent microservices communicate. The microservices framework 143-1 is configured to break down the entire processing task into smaller, independent services. Each microservice might handle specific functions such as data ingestion, parsing, processing, or the like.
[0072] A part of the memory 143 may include a Random Access Memory (RAM), and another part of the memory 143 may include a flash memory or other Read Only Memory (ROM).
[0073] The memory 143 is configured to store a set of instructions required by the processor 145 for controlling overall operations of the server 140. The memory 143 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 Memories (EEPROM). In addition, the memory 143 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 143 is non-movable. In some examples, the memory 143 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 RAM) or cache). The memory 143 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.
[0074] The scheduler 144 is communicatively connected to the processor 145. The scheduler 144 is configured to schedule execution of analytical tasks and job workflows allocated by the processor 145 such as data aggregation, triggering of analytics, and updating in-memory data caches. The scheduler 144 triggers regular data pulls from the EMS cluster 110 and the active alarm database 146. This ensures that the system 100 always works with the most recent data.
[0075] The processor 145 includes various information processing task executors for efficient parallel processing of the alarm data of the outage nodes. The processor 145 is configured to process incoming real-time alarm data efficiently and generate outage alarm visualization data. The processor 145 is configured to execute algorithms for alarm aggregation, severity classification, and predictive analysis. The processor 145 is configured to handle computationally intensive tasks of correlating alarms and determining outage clusters. The processor 145 may be further configured to run statistical models and machine learning algorithms to predict trends, validate data and assign priorities to different geographical areas.
[0076] The processor 145 may include processors or other processing devices that controls the overall operation of the server 140. For example, the processor 145 is configured to execute programs and other processes stored in the memory 143. The processor 145 is further configured to store data in the memory 143 and fetch the data from the memory 143 as required by an execution process.
[0077] The processor 145 may include various processing circuitry and communicates with the memory 143 and the communication interface 149. The processor 145 may include a plurality of processors, 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).
[0078] The active alarm database 146 may correspond to a centralized database system configured to store and manage the real-time alarm data. The active alarm database 146 is configured to maintain a comprehensive record of active alarms and attributes of the active alarms. The active alarm database 146 may be utilized by the processor 145 for storing the incoming alarm data from the EMS cluster 110. The active alarm database 146 may be optimized for rapid read or write operations to support immediate visualization and decision making. The active alarm database 146 may enable real time queries to fetch a current state of network outages for visualization on the UI.
[0079] The history alarm database 147 may correspond to a repository that stores historical data related to the alarms generated within the system over time. The historical alarm database 147 may store information about past outage alarms including type of outage alarm, event time associated with the outage alarm, severity level of the outage alarm, and the like. The history alarm database 147 may provide data for generating historical performance reports and help in understanding the outage patterns over time. The history alarm database 147 may provide data to analytics modules that generate insights such as Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR). In the context of present disclosure, the MTBF corresponds to an average time duration between consecutive failures of network components that trigger the outage alarms. The MTTR corresponds to an average time required to diagnose, repair, and restore network services after a failure. The MTTR is derived from timestamps of outage occurrence and resolution stored in the history alarm database 147.
[0080] The CDC module 148 is configured to monitor changes in data processing rates and dynamically adjust processing parameters to detect anomalies in data throughput.
[0081] The communication interface 149 includes an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 149 is configured for communicating internally between internal hardware components and with external devices via one or more networks.
[0082] The server 140 may further include a history reconciliation module and active reconciliation module (not shown in figures). The history reconciliation module may compare the historical alarm data with current alarm data to identify any inconsistencies or discrepancies and may facilitate troubleshooting and error detection. The active reconciliation module may determine consistency between the current alarm data and the historical alarm data stored in the history alarm database 147.
[0083] The distributed file system 150 may be integrated within the server 140 for storing large volumes of real-time alarm visualization data and other operational data. The distributed file system 150 is configured to provide a scalable and fault-tolerant storage system, capable of handling entire operation specific data across distributed clusters of files associated with the server 140.
[0084] The user device 160 corresponds to a device used by the network operation team or the end user. Further, 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 a UI 160-1 and a communication unit 160-2. The UI 160-1 facilitates display of the generated real-time alarm visualization data and the determined aggregated count of the outage nodes. 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.
[0085] Although FIG. 1 illustrates one example of the communication system 100, various changes may be made to FIG. 1. For example, the communication system 100 may include any number of vendor EMS, nodes, and servers in any suitable arrangement. Further, in another example, the server 140 may include any number of components in addition to the components shown in FIG. 1. Further, various components in FIG. 1 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.
[0086] FIG. 2 illustrates a block diagram depicting various components of the processor 145 of the communication system 100, in accordance with an embodiment of the present disclosure.
[0087] The processor 145 may include units/modules selected from any of an acquisition module 145-1, an execution module 145-2, a determination module 145-3 and a data processing module 145-4. The processor 145 may include, but are not limited to, other modules such as an analytics module, a monitoring module, and the like. Each of the modules of the processor 145 may be communicatively connected to one another.
[0088] The processor 145 is configured to receive, from the EMS cluster 110 via the network 120 followed by the load balancer 130, the alarm data associated with the outage nodes, and to store the received alarm data in the active alarm database 146.
[0089] Further, in an implementation, the processor 145, using the acquisition module 145-1, is configured to receive, via the User Interface (UI) 160-1 of the user device 160, a first input for alarm data corresponding to the outage nodes. In an implementation, the acquisition module 145-1 may receive the first input that may indicate a need to fetch or refresh the alarm data corresponding to the nodes experiencing service affecting alarms. In an example implementation, a network operator while monitoring a live dashboard on an NOC terminal notices unusual activity and clicks a “Refresh alarm data” button on the UI 160-1. This click generates the first input that is transmitted from the user device 160 to the acquisition module 145-1. Alternatively, the first input may be generated automatically by a periodic timer or triggered by an event, for example, detection of an abnormal surge in the outage nodes.
[0090] The processor 145, using the execution module 145-2, is configured to trigger, based on the received first input, the scheduler 144 to fetch the alarm data corresponding to the outage nodes from the active alarm database 146. In an implementation, upon receiving the network operator’s input, the scheduler 144 is activated. The scheduler 144 is configured to query the active alarm database 146 periodically (for instance, every 30 seconds) to retrieve latest alarm data that corresponds to the outage nodes. For example, the scheduler 144 may retrieve data such as Node A (located in region X) indicating critical outage, Node B (located in region Y) indicating major outage and Node C (located in region Z) indicating minor outage. This periodic fetching of the alarm data ensures that the system 100 is always working with up-to-date information.
[0091] The processor 145, using the determination module 145-3, is configured to determine an aggregated count of the outage nodes for locations of a plurality of locations within the geographical region based on the alarm data fetched from the active alarm database 146 and geographical location information of the outage nodes. The determination module 145-3 processes the raw alarm data and uses the geographical location information (such as Global Positioning System (GPS) coordinates, region identifiers (IDs), or maintenance cluster IDs) to group the alarms. The determination module 145-3 then calculates a unique count of the outage nodes per defined cluster or region. In an example implementation, suppose the fetched alarm data shows 50 alarms from the nodes in Region A (maintenance cluster 1), 30 alarms from the nodes in the Region A (maintenance cluster 2) and 20 alarms from the nodes in Region B (maintenance cluster 3). The determination module 145-3 aggregates these counts to provide a summarized view: Region A: 80 outage nodes (split between the two clusters) and Region B: 20 outage nodes. This aggregation helps in identifying geographic hotspots that require immediate attention.
[0092] In an example implementation, the determination module 145-3 upon identifying a mass outage occurring due to a fiber cut affecting multiple cell towers, may detect the outages and group the affected cell towers into a maintenance zone or cluster. This maintenance cluster may be highlighted on a layered map view, allowing the network operators to quickly assess the affected region. In another example implementation, the determination module 145-3 upon detecting a power outage impacting a set of network nodes (for e.g., routers, base stations, or switching centers) groups the network nodes into a maintenance cluster based on shared power dependencies.
[0093] The processor 145, using the data processing module 145-4, is further configured to generate the real-time alarm visualization data based on the determined aggregated count of the outage nodes. The data processing module 145-4 takes the aggregated count of the outage nodes and converts the aggregated counts into a format suitable for visual display. This may include creating graphical elements such as charts, maps, or color-coded indicators that highlight the severity and concentration of outages in different geographical regions.
[0094] Further, the processor 145, using the data processing module 145-4, is configured to control the UI 160-1 of the user device 160 to display the generated real-time alarm visualization data in a color code format indicating the outage nodes based on a reception of a second input in response to the displayed option. The processor 145, using the data processing module 145-4, is further configured to control the UI 160-1 to display the generated real-time alarm visualization data in the layered map view. For instance, in an example implementation, the data processing module 145-4 may generate a layered map visualization and may assign red overlays to regions with more than 70 outage nodes (indicating critical issues), orange overlays to regions between 40 to 70 outage nodes (indicating major issues) and yellow or green overlays to regions with fewer than 40 outage nodes (indicating mower impact). This visualization helps in timely conveying to the network operator where the highest priority repairs are needed.
[0095] After generating the map overlays and graphical indicators, the data processing module 145-4 controls the UI 160-1 to render the updated visualization. The network operator’s dashboard then updates in real time, showing a map with color ordered regions and clickable options for further drill down (for example, clicking on Region A reveals detailed information about individual outage nodes). The network operator can then prioritize actions based on this display or request further details.
[0096] The processor 145 may further store the generated real-time alarm visualization data in the distributed file system 150. The processor 145 is configured to perform distributed data processing tasks in parallel and may execute various analytical algorithms and computations stored in the memory 143 to analyze incoming alarm data and may identify an impact of the outage nodes or alarms.
[0097] FIG. 3 illustrates a UI framework depicting an example UI 300 (hereinafter may be simply referred to as a UI 300) for visualizing the real-time alarm visualization data corresponding to the mass outage area, in accordance with an embodiment of the present disclosure. The UI 300 includes a header section at the top, which includes a cognitive platform 310 for outage visualization, a navigation panel, a search bar 320, and the like. The cognitive platform 310 includes various options for visualizing the real-time alarm data. The options may include an option for visualizing mass outage data across different geographies in the map view.
[0098] The navigation panel enables switching between different views (e.g., national level view, regional level view, node level view, and the like). The search bar 320 allows the users to search specific nodes, alarms, or geographic locations.
[0099] Referring to FIG. 3, a left side section of the cognitive platform 310 presents the KPIs related to network outages. The following parameters are displayed via the cognitive platform 310: total outage sites (i.e., number of sites experiencing the service-affecting alarms), total outage cells (i.e., number of individual network cells impacted), severity levels (through color coded representation of minor, major and critical alarms), cluster wise aggregated count of the outage nodes, alarm trends, and the like.
[0100] Once the end user selects the option for visualizing the real-time alarm visualization data corresponding to the mass outage area, the data processing module 145-4 of the processor 145 controls the UI 160-1 to display the generated real-time alarm visualization data in the color code format indicating the outage nodes across different geographies. When the user selects one of the color codes depicting the real-time alarm visualization data for any specific geography, the data processing module 145-4 of the processor 145 may control the UI 160-1 to display a number of outage sites and a number of outage nodes for the specific geography. The outage nodes may be grouped within predefined maintenance zones. Further, the data processing module 145-4 of the processor 145 may also control the UI 160-1 to display the real-time alarm visualization data for each of the geographical regions in a single map view, using which the end user can drill down from service area level view to maintenance/business cluster view to node level view.
[0101] The cognitive platform 310 may further include options such as sites 322, prediction layers 324, measured layers 326, hybrid layers 328, analytics 330, network 332, interference migration 334, low utilized layers 336, live alarm 338, locations and boundaries 340, base maps 342, my layers 344, and the like.
[0102] The option “site 322” typically displays a list or map overlay of individual network sites and allows the network operator to see outage information at a granular level (e.g., base stations, cell towers).
[0103] The option “prediction layers 324” overlays forecasted outage conditions onto the map and shows which geographic regions are at a high risk for outages allowing the network operator to allocate resources accordingly.
[0104] The option “measured layers 326” shows real time, measured outage data collected directly from the network. The option “measured layers 326” update the map with latest outage information, including the number of alarms and affected nodes.
[0105] The option “hybrid layers 328” combines elements from both prediction and measured layers and our first a comprehensive view that integrates forecasted risks with actual, real-time data.
[0106] The option “analytics 330” provides analytical tools and visualizations related to network performance and outage events to offer trend analysis, statistical breakdowns, and performance KPIs. The option “analytics 330” assists in identifying recurring issues or patterns that could be addressed to prevent future outages.
[0107] The option “network 332” is focused on displaying overall network topology and helps in visualizing how different network elements (nodes, sites, clusters) are interconnected.
[0108] The option “interference migration 334” tracks and visualizes interference patterns across the network. The option “interference migration 334” may show how interference from external sources such as electromagnetic interference or overlapping frequencies affects network performance.
[0109] The option “low utilized layers 336” highlights areas or network elements that are underutilized and provides insight into capacity and load distribution across the network.
[0110] The option “live alarm 338” displays active, real time alarm data. The option “live alarm 338” provides immediate visual feedback on ongoing issues within the network.
[0111] The option “locations and boundaries 340” overlays administrative or operational boundaries on the map. The option “locations and boundaries 340” helps contextualize outage data within defined geographic or organizational zones.
[0112] The option “base maps 342” provides underlying geographic context upon which all other data layers are overlaid. The option “base maps 342” may offer multiple map views such as satellite, street, or terrain views.
[0113] The option “my layers 344” allows the users to customize the layers to be displayed on the UI 160-1. The option “my layers 344” provides a personalized interface where the network operators can save their preferred configurations.
[0114] FIG. 4 illustrates a UI framework depicting an example UI 400 for visualizing the real-time alarm visualization data corresponding to a specific outage area, in accordance with an embodiment of the present disclosure. The UI framework provides the end user with the cognitive platform including a plurality of options for visualizing the real-time alarm data for the specific outage area in the map view. Once the end user selects the option for visualizing the real-time alarm visualization data corresponding to the specific outage area, the data processing module 145-4 of the processor 145 controls the UI 160-1 to display the generated real-time alarm visualization data indicating multiple alarms that are generated for the specific outage area. When the user selects one of the alarms from the multiple alarms depicting the real-time alarms for the specific outage area, the data processing module 145-4 of the processor 145 may control the UI 160-1 to display information related to the alarm selected by the end user.
[0115] FIG. 5 illustrates a flowchart depicting a method 500 for monitoring the performance of the nodes in the communication network, in accordance with an embodiment of the present disclosure. The method 500 comprises a series of operation steps indicated by blocks 502 through 510. Although the method 500 shows example blocks of steps 502 to 510, in some embodiments, the method 500 may include additional steps, fewer steps or steps in different order than those depicted in FIG. 5. In other embodiments, the steps 502 to 510 may be combined or may be performed in parallel. The method 500 starts at block 502.
[0116] At block 502, the acquisition module 145-1 of the processor 145 receives, via the UI 160-1 of the user device, the first input for the alarm data corresponding to the outage nodes within a specified geographical region.
[0117] At block 504, the execution module 145-2 of the processor 145 triggers the scheduler 144 to fetch the real-time alarm data corresponding to the outage nodes from the active alarm database 146.
[0118] At block 506, the determination module 145-3 of the processor 145 determines, for each geography, the aggregated count of the outage nodes based on the fetched alarm data and the geographical location information of the outage nodes. The aggregated count of the outage nodes corresponds to the unique cluster-wise count of the outage nodes for the one or more locations within the geographical region. The unique cluster-wise count of the outage nodes corresponds to a count of the outage nodes for each maintenance zone of the maintenance zones within the one or more locations.
[0119] At block 508, the data processing module 145-4 of the processor 145 generates real-time alarm visualization data based on the determined aggregated count of the outage nodes.
[0120] At block 510, the data processing module 145-4 of the processor 145 controls the UI 160-1 to display the real-time alarm visualization data corresponding to the outage nodes. The generated alarm visualization data corresponding to the outage nodes is displayed on the UI 160-1 of the user device 160 in the layered map view. The layered map view, in the context of the present disclosure, represents network outage data at multiple levels allowing the network operators to drill down from a high-level national view to individual network elements. For instance, Layer 1 represents national or regional view and shows a heatmap with different colors representing outage severity across regions. Layer 2 represents group outages based on clusters, network zones, or affected service areas, Layer 3 represents node level or site level view and focuses on specific network components such as base stations, fiber links, or network nodes, and Layer 4 represents drilling down to network element level and displays alarm data related to a specific router, switch, or the like.
[0121] The layered map view comprises at least one of a count of outage sites, outage cells, and outage alarms within the one or more locations, or color-coded indicators representative of a sequential priority assigned to the one or more locations for remedial actions. The network operators upon detecting any outage scenarios for instance, upon detecting fiber cut, initiates remedial actions such as initiating failover mechanism, rerouting traffic, and the like.
[0122] The data processing module 145-4 is configured to categorize, based on a predefined criteria associated with the fetched alarm data and the determined aggregated count of the outage nodes, the one or more locations within the geographical region. The predefined criteria include severity of outages, number of affected nodes, or duration of outages, and the like. The data processing module 145-4 is further configured to assign a sequential priority to the categorized one or more locations for remedial actions.
[0123] The data processing module 145-4 is configured to control the UI 160-1 to display options for visualizing the alarm data corresponding to a mass outage area within the geographical region. The acquisition module 145-1 is configured to receive, via the UI 160-1 of the user device 160, a second input in response to the displayed options for visualizing the alarm data.
[0124] The data processing module 145-4 of the processor 145 is configured to control the UI 160-1 to display the generated real-time alarm visualization data in the color code format indicating the outage nodes based on the reception of the second input in response to the displayed option on the UI 160-1.
[0125] FIG. 6 illustrates a schematic architecture diagram depicting a computing system 600, in accordance with an embodiment of the present disclosure. The computing system 600 includes a network 602, a network interface 604, a processor 606, an Input/Output (I/O) interface 608 and a non-transitory computer readable storage medium 610 (hereinafter may also be referred to as the “storage medium 610” or the “storage media 610”).
[0126] The network interface 604 includes wireless network interfaces such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA) or wired network interfaces such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers-864 (IEEE-864).
[0127] The processor 606 may include various processing circuitry and communicate with the storage medium 610 and the I/O interface 608. The processor 606 is configured to execute instructions stored in the storage medium 610 and to perform various processes. The processor 606 may include an intelligent hardware device including a general-purpose processor, such as, for example, and without limitation, the CPU, the AP, a dedicated processor, or the like, a graphics-only processing unit such as the GPU, a microcontroller, a Field-Programmable Gate Array (FPGA), a programmable logic device, a discrete hardware component, or any combination thereof. The processor 606 may be configured to execute computer-readable instructions 610-1 stored in the storage medium 610 to cause the server 140 to perform various functions.
[0128] The storage medium 610 stores a set of instructions 610-1 required by the processor 606 for controlling its overall operations. The storage medium 610 further stores a microservices framework 610-2.
[0129] The storage media 610 may include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like. For example, the storage media 610 may include, but are not limited to, hard drives, floppy diskettes, optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magnetic or optical cards, solid-state memory devices, or other types of physical media suitable for storing electronic instructions. In one or more implementations, the storage media 610 includes a Compact Disk-Read Only Memory (CD-ROM), a Compact Disk-Read/Write (CD-R/W), and/or a Digital Video Disc (DVD).
[0130] In one or more embodiments, the storage medium 610 stores computer program code configured to cause the computing system 600 to perform at least a portion of the processes and/or methods. Accordingly, in at least one embodiment, the computing system 600 performs the method for monitoring the performance of the nodes in the communication network.
[0131] Embodiments of the present disclosure have been described above with reference to flowchart illustrations of methods and systems according to embodiments of the disclosure, 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 method.
[0132] 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 143 or the storage medium 610) that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions 610-1 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).
[0133] 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 145 or the processor 606) to perform one or more functions as described herein. The instructions 610-1 may also be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely.
[0134] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or more embodiments may include providing the system and the method for visualizing, in real-time, the mass outage area for the outage nodes in the communication network that enables to assign priority in attending the outage nodes in any geography or maintenance cluster, thereby improving the customers’ experience.
[0135] A further potential advantage of the one or more embodiments disclosed herein may include facilitating efficient and seamless communication between the UI and the components of the server for generating the real-time visualization data corresponding to the mass outage area, on the single glass pane view, thereby improving the customers’ experience.
[0136] In particular, according to one or more embodiments disclosed herein, both UI application and backend code is tightly coupled in such a way that the user can visualize the generated real-time alarm visualization data with minimum latency along with data sanity. This also enables the operations team to monitor a set of nodes in the case of any special events or continuous monitoring of crucial sites to keep 100% uptime of the network.
[0137] 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-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.
[0138] 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.
[0139] 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
[0140] 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 System/System
101-104 – Nodes
101’-104’ – vendor associated EMSs, vendor EMSs, EMSs
110- EMS cluster
120 - Network
130 – Load Balancer
140 - Server
141 – Parser
142 – Distributed Streaming Platform
143 - Memory
143-1 – Microservices Framework
144 – Scheduler
145 – Processor
145-1 – Acquisition Module
145-2 – Execution Module
145-3 – Determination Module
145-4 – Data Processing Module
146 – Active Alarm Database
147 - History Alarm Database
148 – CDC Module
149 – Communication Interface
150 – Distributed File System
160 – User Device
160-1 – User Interface (UI)
160-2 – Communication Unit
170 – API Gateway
300 – Example UI
310 – Cognitive Platform
320 – Search Option
322 - Site
324 – Prediction Layers
326 – Measured Layers
328 – Hybrid Layers
330 – Analytics
332 – Network
334 – Interference Migration
336 – Low Utilized Layers
338 – Live Alarm
340 – Locations and Boundaries
342 – Base Maps
344 – My Layers
400 – Example UI
500 – Method for monitoring performance of nodes
600 - Computing System
602 - Network
604 - Network interface
606 - Processor
608 – I/O Interface
610 - Storage Medium
610-1 - Instructions
,CLAIMS:We Claim:

1. A method (500) for monitoring performance of nodes (101-104) in a communication network, the method (500) comprising:
receiving, by an acquisition module (145-1) from a user device (160), a first input for alarm data corresponding to outage nodes within a geographical region;
triggering, by an execution module (145-2) based on the first input, a scheduler (144) to fetch the alarm data corresponding to the outage nodes from a database (146);
determining, by a determination module (145-3), an aggregated count of the outage nodes for one or more locations of a plurality of locations within the geographical region based on the fetched alarm data and geographical location information of the outage nodes, wherein the aggregated count of the outage nodes corresponds to a unique cluster-wise count of the outage nodes for the one or more locations;
generating, by a data processing module (145-4), alarm visualization data based on the determined aggregated count of the outage nodes; and
controlling, by the data processing module (145-4), the user device (160) to display the generated alarm visualization data corresponding to the outage nodes.

2. The method (500) as claimed in claim 1, further comprising:
categorizing, by the data processing module (145-4), the one or more locations within the geographical region based on a predefined criteria associated with the fetched alarm data and the determined aggregated count of the outage nodes, wherein the predefined criteria include one or more of severity of outages, number of affected nodes, or duration of outages; and
assigning, by the data processing module (145-4), a sequential priority to the categorized one or more locations for remedial actions.

3. The method (500) as claimed in claim 1, wherein the unique cluster-wise count of the outage nodes corresponds to a count of the outage nodes for each maintenance zone of one or more maintenance zones within the one or more locations.

4. The method (500) as claimed in claim 1, wherein the generated alarm visualization data corresponding to the outage nodes is displayed on a User Interface (UI) (160-1) of the user device (160) in a layered map view.

5. The method (500) as claimed in claim 4, wherein the layered map view comprises at least one of:
a count of one or more of outage sites, outage cells, and outage alarms within the one or more locations; or
one or more color coded indicators representative of a sequential priority assigned to the one or more locations for remedial actions.

6. The method (500) as claimed in claim 1, comprising:
controlling, by the data processing module (145-4), the UI (160-1) to display one or more options for visualizing the alarm data corresponding to a mass outage area within the geographical region;
receiving, by the acquisition module (145-1) via the UI (160-1), a second input in response to the display of the one or more options for visualizing the alarm data; and
controlling, by the data processing module (145-4), the UI (160-1) to display the generated alarm visualization data based on the second input.

7. The method (500) as claimed in claim 6, wherein the second input corresponds to a selection operation performed by a user in response to the display, on the UI (160-1), of the one or more options for visualizing the alarm visualization data corresponding to the mass outage area.

8. A system (100) for monitoring performance of nodes (101-104) in a communication network, the system (100) comprising:
an acquisition module (145-1) configured to receive, from a user device (160), a first input for alarm data corresponding to outage nodes within a geographical region;
an execution module (145-2) configured to trigger, based on the first input, a scheduler (144) to fetch the alarm data corresponding to the outage nodes from a database (146);
a determination module (145-3) configured to determine an aggregated count of the outage nodes for one or more locations of a plurality of locations within the geographical region based on the fetched alarm data and geographical location information of the outage nodes, wherein the aggregated count of the outage nodes corresponds to a unique cluster-wise count of the outage nodes for the one or more locations; and
a data processing module (145-4) configured to:
generate alarm visualization data based on the determined aggregated count of the outage nodes; and
control the user device (160) to display the generated alarm visualization data corresponding to the outage nodes.

9. The system (100) as claimed in claim 8, wherein the data processing module (145-4) is configured to:
categorize, based on a predefined criteria associated with the fetched alarm data and the determined aggregated count of the outage nodes, the one or more locations within the geographical region, wherein the predefined criteria include one or more of severity of outages, number of affected nodes, or duration of outages; and
assign a sequential priority to the categorized one or more locations for remedial actions.

10. The system (100) as claimed in claim 8, wherein the unique cluster-wise count of the outage nodes corresponds to a count of the outage nodes for each maintenance zone of one or more maintenance zones within the one or more locations.

11. The system (100) as claimed in claim 8, wherein the generated alarm visualization data corresponding to the outage nodes is displayed on a User Interface (UI) (160-1) of the user device (160) in a layered map view.

12. The system (100) as claimed in claim 11, wherein the layered map view comprises at least one of:
a count of one or more of outage sites, outage cells, and outage alarms within the one or more locations; or
one or more color coded indicators representative of a sequential priority assigned to the one or more locations for remedial actions.

13. The system (100) as claimed in claim 8, wherein:
the data processing module (145-4) is configured to control the UI (160-1) to display one or more options for visualizing the alarm data corresponding to a mass outage area within the geographical region; and
the acquisition module (145-1) is configured to receive, via the UI (160-1), a second input in response to the display of the one or more options for visualizing the alarm data.

14. The system (100) as claimed in claim 13, wherein the data processing module (145-4) is configured to control, based on the second input, the UI (160-1) to display the generated alarm visualization data.

15. The system (100) as claimed in claim 13, wherein the second input corresponds to a selection operation performed by a user in response to the display, on the UI (160-1), of the one or more options for visualizing the alarm data corresponding to the mass outage area.