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

Abstract

Disclosed is a system (100) and a method (300) for monitoring historical performance of nodes (120) in a communication network. The method comprises receiving a plurality of parameters for generating visualization data of historical alarms corresponding to the nodes (120) of one or more vendors for a geographical location during a user defined time-period. Based on the plurality of parameters, historical alarm data is fetched from a first database (270-1). Based on the fetched historical alarm data, an alarm type of each of the historical alarms corresponding to the nodes (120) for each vendor of the one or more vendors, and a count of the historical alarms of each alarm is determined. Subsequently, based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count or a performance trend of the historical alarms for each alarm type is generated.

Description

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

[0001] This application claims the benefit of Indian patent application No. 202421024191 titled “system and method for alarm trend visualisation in multi- nodal networks” filed on March 26, 2024, Indian patent application No. 202421025479, titled “User Interface (UI) framework for visualization of alarms of nodes in a communication network” filed on March 28, 2024, and Indian patent application No. 202421025480, titled “system and method for handling call-flow for visualization of trend of alarms in a network” filed on March 28, 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. More particularly, the present disclosure relates to a system and method for monitoring historical performance 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 as a result 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] With diverse and ever-increasing consumer demand for high-speed network connectivity, there has been an expansion of network resources by the network operators to meet the consumer demands. It has become pertinent for network operators to monitor the health of the network resources to maintain seamless and reliable network services to the users. A Network Operations Center (NOC) isa centralized location from where the network operators monitor nodes in different service areas of a communication network, round the clock for network disruptions and failures.

[0005] In the communication network, the service areas are divided into a number of geographies, and the geographies are further bifurcated into multiple maintenance cluster and business cluster for administrative purposes. Further, to serve different functionalities and provide communication services in the communication network, each of the service areas are served by nodes of different product types from different vendors, having similar or different functionalities. Depending upon functionalities offered by different vendors and to maintain a quality of service in the communication network, nodes from different vendors are strategically spread across the clusters. In such a scenario, it becomes crucial for the network operators to identify repeating causes of alarms in the nodes from different vendors based on alarms raised in the past, and thereby compare performance of the nodes from different vendors comprehensively, to maintain optimal performance and quality of the network.

[0006] However, increasing number of the nodes in each service area and fluctuating status of each of these nodes with varying network conditions, has added to complexity of monitoring the health of the nodes. Traditionally, the network operators have relied upon conventional performance management tools for analyzing performance outage data of the nodes from different vendors individually, to assess the performance of the nodes.

[0007] A manual process of analyzing performance of the nodes of different vendors in a complex wireless network is cumbersome and prone to errors. Moreover, as the performance data for a node from each vendor has to be fetched from a different Element Management System (EMS), each maintained by a different vendor, a NOC engineer has to login to multiple EMSs for monitoring a specific geography in the network. Further, the performance data fetched from the EMS, pertains to an individual site within a geography having site specific detailsrelated to the nodes. Thus, it becomes difficult for the NOC engineer to assess an impact of the performance of the nodes from site specific data of different vendors on network quality across a particular geography.

[0008] Further, monitoring of alarms raised by the nodes about a service affecting issue or a non-service affecting issue faced by the nodes, is particularly reliant upon an underlying server architecture. To monitor repeating issues faced by the nodes, the network operators rely upon manual filtering of such alarm data fetched from traditional servers. While the traditional servers may provide a robust platform for deploying Java-based applications, particularly those built using Java Servlet, Java Server Pages (JSP), and the like, these servers lack capabilities to handle multiple application programs required for handling large volumes of data for advanced alarm monitoring and visualization tasks. The aforementioned limitations associated with the traditional server limits scalability and efficiency of utilization of the communication network.

[0009] Therefore, there is a need for an efficient system and method that can facilitate advanced alarm monitoring and alarm visualization tasks, and can overcome the aforementioned shortcomings and limitations associated with the conventional performance management tools.SUMMARY

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

[0011] In an embodiment, disclosed herein is a method for monitoring historical performance of a plurality of nodes in a communication network. The method comprises receiving, by a reception unit from a user device, a plurality of parameters for generating visualization data of historical alarms corresponding to the plurality of nodes of one or more vendors for a geographical location during a user definedtime-period. Further, the method comprises fetching, by a task execution unit based on the plurality of parameters, historical alarm data from a first database. The historical alarm data comprises details related to the historical alarms raised at the plurality of nodes within the geographical location. Furthermore, the method comprises determining, by a determination unit based on the fetched historical alarm data, an alarm type of each of the historical alarms corresponding to the plurality of nodes for each vendor of the one or more vendors. The method also comprises determining, by the determination unit based on the determined alarm type and the historical alarm data, a count of the historical alarms of each alarm type corresponding to the plurality of nodes. Thereafter, the method comprises generating, by a data processing unit based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count of the historical alarms of each alarm type within the geographical location or a performance trend of the historical alarms for each alarm type within the geographical location during the user defined time-period.

[0012] In one or more embodiments, the method further comprises determining the alarm type, by the determination unit, comprises mapping each historical alarm from the historical data with one or more pre-defined alarm types using an alarm reference table.

[0013] In one or more embodiments, the method further comprises transmitting, by the task execution unit, based on the reception of the plurality of parameters, an Application Programming Interface (API) request to at least one distributed microservice of a plurality of distributed microservices. Further, the method comprises creating, by the task execution unit using the at least one distributed microservice, a record of the plurality of parameters in a second database upon the transmission of the API request. Furthermore, the method comprises transmitting, by the task execution unit upon creation of the record of the plurality of parameters, a query to the first database via the at least one distributed microservice. The method further comprises fetching, by the task execution unit in response to the transmitted query, the historical alarm data from the first database.

[0014] In one or more embodiments, the method further comprises storing, by the data processing unit, the generated visualization data in the second database. Further, the method comprises controlling, by the data processing unit, a User Interface (UI) of the user device to display the visualization data based on a reception of an input from the user device for visualizing the historical alarms corresponding to the plurality of nodes. The visualization data is displayed on the UI upon fetching the stored visualization data from the second database using the at least one distributed microservice.

[0015] In one or more embodiments, the method further comprises controlling, by the data processing unit, the UI of the user device to display a nested navigation tab for selecting one of a site, a service area, and a maintenance cluster within the geographical location. Further, the method comprises controlling, by the data processing unit, the UI of the user device to display the performance trend of the historical alarms corresponding to a selection of one of the site, the service area, and the maintenance cluster within the geographical location. Further, the controlling, by the data processing unit, the UI comprises displaying the aggregated count of the historical alarms on the UI. The aggregated count of the historical alarms is categorized by at least one of the one or more vendors, the alarm type, the selected site, the service area, and the maintenance cluster within the geographical location in a descending order.

[0016] In one or more embodiments, the performance trend of the historical alarms indicates one of the count of the historical alarms for each alarm type for a plurality of time intervals within the user defined time-period, or the aggregated count of the historical alarms raised at the plurality of nodes for the plurality of time intervals. The count or the aggregated count is displayed on the UI in a chronological sequence of the plurality of time intervals.

[0017] In one or more embodiments, the method further comprises receiving, by the reception unit from one or more nodes among the plurality of nodes, a message indicating clearance of one or more alarms raised at the one or more nodes. Theclearance of the one or more alarms corresponds to a change in a status of the one or more alarms from an active state to a resolved state. Further, the method comprises updating, by the data processing unit, the historical alarm data in the first database with the one or more alarms along with a timestamp of the clearance of each alarm among the one or more alarms.

[0018] In one or more embodiments, the plurality of parameters includes one or more of the alarm type of the historical alarms to be visualized, the geographical location of the plurality of nodes, the user defined time-period for visualization of the historical alarms, a vendor identifier of the plurality of nodes, a Radio Access Technology (RAT) supported by the plurality of nodes, and an identifier of the plurality of the nodes.

[0019] In one or more embodiments, the historical alarm data includes node identifier of each of the plurality of the nodes, an impact of each of the historical alarms at each of the plurality of the nodes, a raise time of each of the historical alarms, a clear time of each of the historical alarms, a root cause of the historical alarms, and an alarm identifier of each of the historical alarms. The historical alarm data is fetched based on at least one of a user action, a scheduled task, or an event- driven process.

[0020] In another embodiment, disclosed herein is a system for monitoring historical performance of a plurality of nodes in a communication network. The system comprises a reception unit, a task execution unit, a determination unit, and a data processing unit. The reception unit is configured to receive, from a user device, a plurality of parameters for generating visualization data of historical alarms corresponding to the plurality of nodes of one or more vendors for a geographical location during a user defined time-period. The task execution unit is configured to fetch, based on the plurality of parameters, historical alarm data from a first database. The historical alarm data comprises details related to the historical alarms raised at the plurality of nodes within the geographical location. The determination unit is configured to determine, based on the fetched historical alarmdata, an alarm type of each of the historical alarms corresponding to the plurality of nodes for each vendor of the one or more vendors. The determination unit is further configured to determine, based on the alarm type and the historical alarm, a count of the historical alarms of each alarm type corresponding to the plurality of nodes. Thereafter, the data processing unit is configured to generate, based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count of the historical alarms for each alarm type within the geographical location or a performance trend of the historical alarms of each alarm type within the geographical location during the user defined time-period.

[0021] In one or more embodiment, the determination unit is further configured to map each historical alarm from the historical data with one or more pre-defined alarm types using an alarm reference table to determine the alarm type.

[0022] In one or more embodiment, the task execution unit is further configured to transmit, based on the received plurality of parameters, an Application Programming Interface (API) request to at least one distributed microservice of a plurality of distributed microservices. The task execution unit is further configured to create, using the at least one distributed microservice, a record of the plurality of parameters in a second database upon the transmission of the API request. Further, the task execution unit is configured to transmit, upon creation of the record of the plurality of parameters, a query to the first database via the at least one distributed microservice. Furthermore, the task execution unit is configured to fetch, in response to the transmitted query, the historical alarm data from the first database.

[0023] In one or more embodiment, the data processing unit is further configured to store the generated visualization data in the second database and control a User Interface (UI) of the user device to display the visualization data based on a reception of an input from the user device for visualizing the historical alarms corresponding to the plurality of nodes. The visualization data is displayed on theUI upon fetching the stored visualization data from the second database using the at least one distributed microservice.

[0024] In one or more embodiment, the data processing unit is further configured to control the UI of the user device to display a nested navigation tab for selecting one of a site, a service area, and a maintenance cluster within the geographical location. Further, the data processing unit is configured to the control the UI of the user device to display the performance trend of the historical alarms corresponding to a selection of the one of the site, the service area, and the maintenance cluster within the geographical location. The data processing unit is further configured to display, on the UI, the aggregated count of the historical alarms. The aggregated count of the historical alarms is categorized by at least one of the one or more vendors, the alarm type, the selected site, the service area, and the maintenance cluster within the geographical location in a descending order.

[0025] In one or more embodiment, the reception unit is further configured to receive from one or more nodes among the plurality of nodes, a message indicating clearance of one or more alarms raised at the one or more nodes. The clearance of the one or more alarms corresponds to a change in a status of the one or more alarms from an active state to a resolved state. The data processing unit is further configured to update the historical alarm data in the first database with the one or more alarms along with a timestamp of clearance of each alarm among the one or more alarms.

[0026] In one or more embodiments, the first database and the second database correspond to one or more of an in-memory storage, a distributed database, a distributed file system, a relational database, a centralized database, a non-relational database, a hierarchical database, a network database, or an in-memory database including a distributed in-memory data storage.BRIEF DESCRIPTION OF DRAWINGS

[0027] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. Theaccompanying 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 the purpose of consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings. In the drawings:

[0028] Fig. 1 illustrates an exemplary environment of a system for monitoring historical performance of nodes in a communication network, in accordance with an embodiment of the present disclosure.

[0029] Fig. 2 illustrates a block diagram depicting exemplary components of a server, in accordance with an embodiment of the present disclosure.

[0030] Fig. 3 illustrates a flow chart of a method for monitoring the historical performance of the nodes in the communication network, in accordance with an embodiment of the present disclosure.

[0031] Fig. 4 illustrates a call flow diagram depicting information exchange between a user device and the components of the server for monitoring the historical performance of the nodes in the communication network, in accordance with an embodiment of the present disclosure.

[0032] Fig. 5 illustrates an example of a first Graphical User Interface (GUI) for input of parameters for monitoring historical performance of the plurality of nodes in the communication network, in accordance with an embodiment of the present disclosure.

[0033] Fig. 6 illustrates an example of a second GUI for visualizing a performance trend for nodes of different vendors in a geographical location, in accordance with an embodiment of the present disclosure.

[0034] Fig. 7 illustrates an example of a third GUI for visualizing a performance trend of historical alarms for a type of node of different vendors, in accordance with an embodiment of the present disclosure.

[0035] Fig. 8 illustrates an example of a fourth GUI for visualizing an aggregated count of historical alarms categorized by service area, in accordance with an embodiment of the present disclosure.

[0036] Fig. 9 illustrates an example of a fifth GUI for visualizing an aggregated count of historical alarms categorized by the type of node, in accordance with an embodiment of the present disclosure.

[0037] Fig. 10 illustrates an example of a sixth GUI for visualizing maintenance cluster wise aggregated count of the historical alarms, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

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

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

[0040] 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.”

[0041] 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 or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.”

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

[0043] 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 willprovide 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.

[0044] 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 and in the appended claims, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.

[0045] 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 and the appended claims. 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.

[0046] The present disclosure relates to a system and a method for monitoring historical performance of a plurality of nodes in a communication network. An object of the present disclosure is to provide a system and a method that facilitates visualization of a trend of historical alarms raised at the plurality of nodes in the communication network over time and across geographical regions, aiding in proactive network management.

[0047] 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 and enables visualization of aggregated alarms and the trend of historical alarms only on the nodes of a site or a maintenance cluster.

[0048] Yet another object of the present disclosure is to provide a system and a method for facilitating seamless integration between front-end and back-end processes for monitoring historical performance of the plurality of nodes in thecommunication network. Still another object of the present disclosure is to provide a system and a method that allows the user to take preemptive corrective actions by aggregating and analyzing timely insights on performance of the plurality of nodes, in a user-friendly interface with minimum latency.

[0049] Various aspects of the present disclosure illustrate the system and the method for monitoring historical performance of the plurality of nodes in the communication network. Alarms may be generated by the nodes in an event of outage of the node, or any other performance impacting events faced by the node. The performance impacting events may include malfunctioning of the node, connectivity issue, non-service affecting issues or performance degrading issues. During varying network conditions, alarms raised by the plurality of nodes (alternatively referred to as “nodes”) may vary and the nodes have to be monitored to ensure efficient performance of the communication network.

[0050] A user, generally a network operator or a network operations team, tasked for monitoring health and performance of the nodes, utilizes a front-end of the system, to configure a request for monitoring historical performance of the nodes in the communication network to seamlessly generate visualization data of historical alarms raised by the nodes of one or more vendors for a geographical location in a user specified time -period. The system and the method utilize a microservices platform to handle call flow between front-end processes and back-end processes, for executing the request for monitoring historical performance of the nodes in the communication network. The system and the method enable visualization of an aggregated count of the historical alarms and a performance trend the historical alarms raised in any geography in one go, thereby reducing time and effort spent on manual comparison of performance metrics of the nodes.

[0051] In the disclosure, various embodiments are described using terms used in 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 modified and applied to other communication systems.

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

[0053] Historical alarms correspond to alarms raised at a node in the communication network or a network management system that have now been cleared or resolved. The historical alarms may be raised due to an event of complete outage at the node or the network resource, and / or due to a minor, major, or critical fault at the node affecting performance of the node or the network resource. The historical alarms serve as records of faults, issues, or outages in the communication network in a past time frame.

[0054] A performance degrading alarm refers to an alarm generated by a node or a network resource or a network management system indicating a condition that performance of the node or the network resource has deteriorated beyond a predefined threshold level but has not resulted in a complete failure. Such alarm serves as an early warning to a network administrator or network operations team for enabling prompt attention in order to prevent one or more service disruptions.

[0055] A service affecting alarm refers to an alarm generated by a node or a network resource or a network management system signifying a total loss of service or complete outage in the node or the network resource. The service affecting alarm are critical as they indicate complete service disruption at any node in the communication network, requiring immediate remediation.

[0056] A service area refers to a geographical region covered by a group of nodes in a communication network. The service area may be determined using a radio coverage provided by the nodes in a communication network. For example, the service area of a single node in a network environment may be a few kilometers in radius.

[0057] A maintenance cluster refers to a grouping of service areas managed together by a network administrator or network operations team for maintaining operational efficiency of the communication network.

[0058] Distributed microservices (interchangeably referred to as microservices) are independently deployable software in which complex applications are composed of small and independent processes. The distributed microservice may be developed as a suite of small services, each running in its own process and communicating with lightweight mechanisms such as Application Programming Interface(s) (API). Each microservice may adhere to a well-defined API.

[0059] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. Fig. 1 through Fig. 10 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.

[0060] Fig. 1 illustrates an exemplary environment of a system 100 for monitoring historical performance of the nodes in a communication network, in accordance with an embodiment of the present disclosure. The embodiment of the environment of a system 100 shown in Fig. 1 is for illustration only. Other embodiments of the environment of the system 100 may be used without departing from the scope of this disclosure.

[0061] As shown in Fig. 1, the system 100 includes a server 110, a plurality of nodes 120-1 to 120-n (collectively referred to as “nodes 120”), a Network Management Console (NMC) 130, an API gateway 140, and a vendor Element Management System (EMS) cluster 160. Each component of the system 100 may be communicatively coupled with other components of the system 100 via a network

[0062] The server 110 may be a network of computers, a software framework, or a combination thereof, that may provide a generalized approach to create a server implementation. Examples of the server 110 may include, but are not limited to, personal computers, laptops, mini-computers, mainframe computers, any nontransient and tangible machine that can execute a machine-readable code, cloudbased servers, distributed server networks, or a network of computer systems. The server 110 may be realized through various web-based technologies such as, but not limited to, a Java web-framework, a .NET framework, a personal home page (PHP) framework, or any web-application framework.

[0063] Typically, the term nodes 120 may include one of at least one Base Station (BS), at least one relay, and at least one Distributed Unit (DU). The BS may be a network infrastructure that provides wireless access to one or more terminals. Examples of the BS include, but are not limited to, a macro cell, a femtocell, wireless “Access Point (AP),” “evolved NodeB (eNodeB) (eNB),” “5th Generation (5G) node,” “next generation NodeB (gNB),” “wireless point,” “Transmission / Reception Point (TRP).” The BS may provide wireless access in accordance with wireless communication protocols, e.g., 5G / NR 3GPP New Radio interface / access (NR), LTE, LTE-A, High Speed Packet Access (HSPA), Wi-Fi 802.11a / b / g / n / ac, etc. Aspects of the present disclosure are intended to include, or otherwise cover, any technology (known or later developed) bearing same or similar characteristics as of the above-mentioned BS, without deviating from the scope of the present disclosure. The nodes 120 serve a plurality of “user equipment” or “UE”. The UE may refer to any component such as “mobile station,” “subscriber station,” “remote terminal,” “wireless terminal,” or “receive point.” Examples of the UE include, but is not limited to, portable handheld electronic devices such as a mobile phone, a tablet, a laptop, a smart watch etc., or fixed electronic devices such as a desktop computer, computing device, etc. The UE may correspond to, but is not limited to, any of mobile devices, tablets, or other portable devices utilized by users to access services provided by the network 150.

[0064] The NMC 130 (alternatively referred to as a “user device 130”) may correspond, but not limited to, a desktop computer, a portable computing device such as a laptop, a tablet computer, a handheld computer, a mobile phone, wearable computer, or any other device suitable to provide front end services. The front-end services may include a Graphical User Interface (GUI) 132 (alternatively referred to as “User Interface (UI) 132” or “front-end interface 132”) for accessing different functionalities of the system 100. The GUI 132 may include a software or a web application for initiating user requests for determining and visualizing alarm trends. The GUI 132 may allow the user to select a geographic area and a time -period for visualization of the aggregated count of the historical alarms and the performance trend of the historical alarms. The NMC 130 may further include a communication unit 134 for communicating with the server 110. The communication unit 134 may include a plurality of antennas, a plurality of Radio Frequency (RF) transceivers, a transmit processing circuitry, and a receive processing circuitry. The communication unit 134 may allow the NMC 130 to receive from the server 110 an output corresponding to the user request.

[0065] The NMC 130 may be in communication with the server 110 via the network 150. Further, the network 150 enables communication between various components of the system 100. The network 150 may include wired connections, wireless connections such as a proprietary Internet Protocol (IP) network, Internet, or in accordance with other wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMAX), Wi-Fi 802.11a / b / g / n / ac, or a combination of wired and wireless connections.

[0066] The NMC 130 may communicate with the server 110 via the API gateway 140 to provide dynamic and secure API routing for requests from the users via the GUI 134. Typically, the API gateway 140 may be an API oriented serially centralized management and control server that acts as a bridge between the NMC 130 and the server 110 for providing functionalities such as permission verification for the request, load balancing, caching, and monitoring of requests from the NMC 130. The API gateway 140 may provide an interface for REpresentational StateTransfer (REST) or Hypertext Transfer Protocol (HTTP) based APIs between the server 110 and the NMC 130.

[0067] Further, the server 110 may communicate with the vendor EMS cluster 160 (individually referred to as “EMS 160”) for different vendors via a North Bound Interface (NBI) interface. The vendor EMS cluster 160 may be a group of EMS of different vendors of the nodes 120. The EMS 160 is configured to manage one or more of a specific type of telecommunications network element. The key functions of the EMS 160 may include, but not limited to, handling data related to fault, configuration, accounting, performance, and security in the communication network. In another embodiment, the server 110 may utilize an Operational Support System (OSS) application for fetching data related to fault, configuration, accounting, performance, and security in the communication network through the EMS 160. Particularly, the EMS 160 of each of the one or more vendors comprises alarm data of the nodes 120. The alarms may be triggered in the node due to performance degrading reasons and service affecting reasons in the node. The alarms may be streamed in almost real time from the EMSs 160 upon a request from the server 110 or may be fetched at a pre-defined frequency.

[0068] Although Fig. 1 illustrates one example of the system 100, various changes may be made to Fig. 1. For example, the system 100 may include any number of nodes and user devices in any suitable arrangement, without deviating from the scope of the present disclosure. Further, various components in Fig. 1 may be combined, further subdivided, or omitted, and additional components may be added according to particular needs. It is understood that alternate embodiments of the system 100 are possible wherein one or more of the components of the system 100 may communicate with each other through the network 150.

[0069] Fig. 2 illustrates a block diagram depicting exemplary components of the server 110, in accordance with an embodiment of the present disclosure. The embodiment of the server 110 as shown in Fig. 2 is for illustration only. However, the server 110 may come in a wide variety of configurations, and Fig. 2 does notlimit the scope of the present disclosure to any particular implementation of the server 110.

[0070] As shown in Fig. 2, the server 110 includes an Input-Output (I / O) interface 200, one or more processors 210 (hereinafter may also be referred to as “processor 210 or “at least one processor 210”), a memory 220, processing unit(s) / module(s) 230, a parser 240, a distributed stream processing platform 250, a scheduler 260, one or more databases 270-1 to 270-n (alternatively referred to as “databases 270”), a communication interface 280, and distributed microservice(s) 290. Components of the server 110 are coupled to each other via a communication bus 295.

[0071] The VO interface 200 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on the server 110. For example, the I / O interface 200 may have an input interface and an output interface. The input interface may be configured to enable the user to provide input(s) to trigger (or configure) the server 110 to perform various operations for monitoring the historical performance of the nodes 120. Examples of the input interface may include, but are not limited to, a touch interface, a mouse, a keyboard, and the output interface includes a digital display, an analog display, or a touch screen display. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface including known, related art, and / or later developed technologies without deviating from the scope of the present disclosure.

[0072] The processor 210 may include processing circuitry, logic, interface(s), and / or code(s), and may be configured to communicate with other components of the server 110 (i.e., the memory 220, the processing unit(s) / module(s) 230, the parser 240, the distributed stream processing platform 250, the scheduler 260, the databases 270, the communication interface 280, and the distributed microservice(s) 290), via the communication bus 295. Examples of the communication bus 295 may include, but are not limited to, a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal SerialBus (USB), and a Front Side Bus (FSB). Aspects of the present disclosure are intended to include or otherwise cover any type of coupling means present or related to later developed technologies, that may be configured to for connect the processor 210 to the other subsystems of the server 110, as the communication bus 295, without deviating from the scope of the present disclosure.

[0073] The processor 210 may include various processing circuitry configured to execute instructions 220-1 (hereinafter interchangeably referred to as “a set of instructions 220-1”) stored in the memory 220 and to cause the server 110 to perform various processes for monitoring historical performance of the nodes 120. The processor 210 may also include a plurality of analytics engines i.e., information processing units for controlling overall operation of the server 110 associated with embodiments of the present disclosure and for performing one or more operations for monitoring historical performance of the nodes 120 in the communication network. The analytics engines may be configured to handle a set of tasks or computations executed by the processor 210 in a distributed computing environment. For an example, the processor 210 is configured to execute programs and processes to execute instruction(s) or code(s) stored in the memory 220 pertaining to monitoring of the historical performance of the nodes 120. The processor 210 is further configured to move data into or out of the memory 220 as required by an execution process of the server 110.

[0074] Examples of the processor 210 may include, but are not limited to, a Central Processing Unit (CPU), an Application Processor (AP), a dedicated processor, a graphics-only processing unit such as a Graphics Processing Unit (GPU), a programmable logic device, or any combination thereof.

[0075] The memory 220 is configured to store the set of instructions 220-1 required by the processor 210 for controlling overall operations of the server 110. A part of the memory 220 may include a RAM, a cache memory, or a ROM. The memory 220 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 220 may, in some examples, be implemented using 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 220 is non-movable. 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 220 can be an internal storage unit or it can be an external storage unit of the server 110, cloud storage, or any other type of external storage. In some embodiments, when the memory 220 is external to the server 110, the memory 220 may be removably attached to the server 110. Aspects of the present disclosure are intended to include or otherwise cover any data storage medium as ‘the memory 220’, without deviating from the scope of the present disclosure.

[0076] In an aspect, the processor 210 is configured to receive the alarm data from the EMS 160 including service affecting alarms and performance degrading alarms raised at the nodes 120. The alarm data may include both historical alarm data and active alarm data. The processor 210 instructs the parser 240 to process the alarm data according to predefined protocols, decode a format of the alarm data, and transform raw alarm data into structured records for further processing.

[0077] The processor 210 utilizes the distributed stream processing platform 250 for receiving the alarm data processed by the parser 240 streamed from the EMS 160. The distributed stream processing platform 250 may correspond to a cluster of distributed stream processing servers forming a part of the server 110 or may be a part of an external environment in communication with the server 110. The distributed stream processing platform 250 is configured to ingest the alarm data in real-time, process the ingested alarm data, and distribute the ingested alarm data as streams to the databases 270 and / or the processing unit(s) / module(s) 230 of the processor 210. The distributed stream processing platform 250 is further configuredto handle and manage incoming stream of the alarm data and thus ensure low- latency data processing and seamless integration with downstream components.

[0078] Upon processing of the alarm data, the processor 210 is configured to generate as an output, the visualization data including information related to an aggregated count of the historical alarms of each alarm type within a geographical location or a performance trend of the historical alarms for each alarm type within the geographical location during the user defined time-period.

[0079] The databases 270 may include a first database 270-1 and a second database 270-2. The first database 270-1 may store the historical alarm data from the alarm data received by the distributed stream processing platform 250. The historical alarms correspond to alarms that were raised by the nodes and have been resolved. The historical alarm data comprises details corresponding to the historical alarms raised at the nodes 120 for the one or more vendors within the geographical location. The historical alarms may correspond to a service affecting alarm or a performance degrading alarm. Furthermore, each of the service affecting alarms and the performance degrading alarms may have several types of alarms. Therefore, each historical alarm may fall into a category of same or different alarm type.

[0080] The historical alarm data may be stored in a meaningful message format in the first database 270-1. The historical alarm data may comprise, but not limited to, details related to the historical alarms raised at the nodes 120 within the geographical location, a node identifier of each of the nodes 120, an impact of each of the historical alarms at each of the nodes 120, severity level of each of the historical alarm, a raise time of each of the historical alarms, a clear time of each of the historical alarms, a root cause of the historical alarms, an alarm identifier of each of the historical alarms. In the first database 270-1, the alarm data received from the vendor EMS cluster 160 may be updated in real time or may be updated periodically, such as at an hourly basis, daily basis, or weekly basis.

[0081] The second database 270-2 may store the visualization data generated by the processor 210 for visualizing the aggregated count of the historical alarms of eachalarm type within the geographical location or the performance trend of the historical alarms for each alarm type within the geographical location during the user defined time-period. The databases 270 may be implemented as one or more of centralized database, Relational Database Management System (RDBMS), Non- Relational Database Management System, Hierarchical Database Management System, Network Database Management System, an in-memory database including a distributed in-memory data storage, distributed database, or a distributed file system.

[0082] In one embodiment, both the first database 270-1 and the second database 270-2 corresponds to one or more of the distributed database, the in-memory storage, or the distributed file system. In one embodiment, the first database 270-1 corresponds to one of the in-memory storage or the distributed file system, and the second database 270-2 corresponds to one of the in-memory storage or the relational database. In another embodiment, one or more of the first database 270-1 and the second database 270-2 may be an external database implemented as a non-relational distributed database or the distributed files system outside the server 110 in a manner utilizing resources of a computing device separate from the server 110 itself. In another embodiment, there may be only a single database for serving the functionality of both the first database 270-1 and the second database 270-2.

[0083] The communication interface 280 may manage communications with the NMC 130, the network 150, and the EMS 160. For example, the communication interface 280 may manage the reception of the alarm data from the EMS 160. The communication interface 280 may include an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 280 is configured for communicating with external devices via one or more networks. Further, the communication interface 280 may also provide a communication pathway for one or more components of the server 110. Examples of such components include, but are not limited to, the processing unit(s) / module(s) 230 and the databases 270.

[0084] In an embodiment, the processing unit(s) / module(s) 230 may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the server 110. In non-limiting examples, described herein, such combinations of hardware and programming may be implemented in several different ways. The processing unit(s) / module(s) 230 may include suitable logic, circuitry, interfaces, and / or codes. For example, the programming for the processing unit(s) / module(s) 230 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.

[0085] In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing unit(s) / module(s) 230. In such examples, the server 110 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 110 and the processing resource. In other examples, the processing unit(s) / module(s) 230 may be implemented using an electronic circuitry.

[0086] In one or more embodiments, the processing unit(s) / module(s) 230 may include one or more modules selected from any of a reception unit 232, a task execution unit 234, a determination unit 236, a data processing unit 238, and other units (not shown in Fig. 2). The processing unit(s) / module(s) 230 are communicatively coupled with each other.

[0087] In one embodiment, based on the ingested alarm data received by the distributed stream processing platform 250 from one or more nodes among the plurality of nodes 120, the processor 210, using the reception unit 232, may parse or receive a message indicating clearance of one or more alarms raised at the one or more nodes. The clearance of the one or more alarms may correspond to a change in a status of the one or more alarms from an active state to a resolved state. Thedata processing unit 238 is configured to update the historical alarm data in the first database 270-1 with the one or more alarms along with a timestamp of the clearance of each alarm among the one or more alarm. For an example, upon receiving the clearance of the one or more alarms, a record of an active alarm in a database of the databases 270 storing active alarm data from the alarm data is cleared. The record is then moved or added or copied to the historical alarm data in the first database 270-1. Further, a clear time of the historical alarm in the first database 270-1 is added corresponding to a raise time of the historical alarm. The historical alarm data in the first database 270-1 may be updated through a Change Data Capture (CDC) module (not shown in Fig. 2) to ensure that the first database 270-1 maintains an accurate record of the historical alarms.

[0088] The other units such as a reconciliation unit may identify any inconsistencies or discrepancies in the historical alarm data stored in the first database 270-1 with reference to the ingested alarm data and the one or more database 270 storing active alarm data. The reconciliation unit may help in ensuring data integrity and accuracy and facilitate troubleshooting and error detection.

[0089] In one embodiment, the processor 210, using the reception unit 232, may receive from the user device 130, parameters for generating visualization data of historical alarms corresponding to the nodes 120 of the one or more vendors. The visualization data may be generated for the historical alarms raised during the user defined time-period by the nodes 120 in a geographical location. For generating the visualization data, the processor 210, using the task execution unit 234 is configured to fetch based on the received parameters, historical alarm data from the first database 270-1. Upon receiving the parameters from the user device 130, the historical alarm data may be fetched by the processor 210 from the first database 270-1 using the scheduler 260 periodically at a predefined time interval or upon a user action.

[0090] In one embodiment, the processor 210, using the determination unit 236, determines based on the fetched historical alarm data, an alarm type of each of thehistorical alarms corresponding to the plurality of nodes for each vendor of the one or more vendors. The processor 210, using the determination unit 236, further determines based on the determined alarm type and the historical alarm data, a count of the historical alarms of each alarm type corresponding to the nodes 120. Furthermore, the processor 210, using the data processing unit 238, generates the visualization data based on the determined count of the historical alarms. The visualization data includes, but not limited to, information related to at least one of the aggregated count of the historical alarms of each alarm type within the geographical location or the performance trend of the historical alarms for each alarm type within the geographical location during the user defined time -period.

[0091] Based on a reception of an input received from the user via the user device 130 for visualizing the historical alarms corresponding to the nodes 120, the processor 210 controls, using the data processing unit 238, the GUI 132 to display at least one of the aggregated count of the historical alarms of each alarm type within the geographical location or the performance trend of the historical alarms for each alarm type. The data processing unit 238 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to enable the server 110 to render output(s) to the NMC 130. In some aspects of the present disclosure, the data processing unit 238 may be a controlling engine for executing various operations for displaying the visualization data on the NMC 130. In some other aspects of the present disclosure, the data processing unit 238 may control the GUI 132 on the NMC 130 for user interaction. Further, the data processing unit 238 may control the GUI 132 to display the visualization data in a graphical format, a pictorial format, or as statistical data on the NMC 130.

[0092] Further, the server 110 may host a plurality of distributed microservices 290 (alternatively referred to as “microservices 290”, or “distributed microservice 290”). The server 110 may utilize a plurality of computing resources where the plurality of microservices 290 may be deployed, and a plurality of storage devices such as a database may be provided in the computing resource for each microservice. It must be understood that the microservices platform may also be hosted outside the server110 in a similar manner utilizing the resources of a computing device separate from the server 110 itself. The NMC 130 may access the microservices 290 via the API gateway 140. The microservices 290 may be utilized by the processor 210 to handle call flow between the front-end interface 132 and the processing unit(s) 230. The processor 210 utilizes the microservices 290 to create a record of the received parameters specified by the user in a user request via the NMC 130 for generating the visualization data of the historical alarms. The microservices 290 also fetches the historical alarm data corresponding to the parameters and provides the user with the visualization data of the historical alarms generated by the processor 210.

[0093] Although Fig. 2 illustrates one example of server 110, various changes may be made to Fig. 2. For example, the server 110 may include any number of components in addition to the components shown in Fig. 2. Further, various components in FIG. 2 may be combined, further subdivided, or omitted, and additional components may be added according to particular needs. A detailed description of the method for monitoring historical performance of the plurality of the nodes 120 in the communication network is described further below.

[0094] In an alternate embodiment, each processing unit / module of the processing unit(s) / module(s) 230 (i.e., the reception unit 232, the task execution unit 234, the determination unit 236, the data processing unit 238) is configured to independently perform various operations of the processor 210, as described herein, without deviating from the scope of the present disclosure.

[0095] Fig. 3 illustrates a flow chart of a method 300 for monitoring historical performance of the nodes 120 in the communication network, in accordance with an embodiment of the present disclosure. Example blocks of step 302 to 314 of the method 300 are performed by one or more components of the server 110 as disclosed in Fig. 2, for monitoring the historical performance of the nodes 120 in the communication network. Although the method 300 shows example blocks of steps 302 to 314, in some embodiments, the method 300 may include additional steps,fewer steps or steps in different order than those depicted in Fig. 3. In other embodiments, the steps 302-314 may be combined or may be performed in parallel.

[0096] The method 300 includes receiving by the processor 210, at step 302, using the reception unit 232 from the user device 130, the parameters for generating the visualization data of the historical alarms corresponding to the nodes 120 of the one or more vendors for the geographical location during the user defined time -period. The parameters includes, but not limited to, one or more of the alarm type of the historical alarms to be visualized, the geographical location of the nodes 120, the user defined time-period for visualization of the historical alarms, a vendor identifier of the nodes 120, a Radio Access Technology (RAT) supported by the plurality of nodes such as 4thGeneration (4G) and 5thGeneration (5G), and an identifier of the nodes 120.

[0097] At step 304, the processor 210, using the task execution unit 234, fetches the historical alarm data from the first database 270- 1 based on the received parameters. In particular, the historical alarm data is fetched based on at least one of the user action such as upon receiving the user request for displaying the visualization data, a scheduled task set by the scheduler 260, or an event-driven process such as in an event of complete or sudden outage in a service area in the geographical location.

[0098] At step 306, the processor 210, using the determination unit 236, determines based on the fetched historical alarm data, the alarm type of each of the historical alarms corresponding to the nodes 120 for each vendor of the one or more vendors. The alarm type is determined using an alarm reference table stored in the one or more database 270. The alarm reference table comprises one or more pre-defined alarm types of the service affecting alarms and the performance degrading alarms of nodes 120 of one or more vendors. The pre-defined alarm types corresponding to the service affecting alarms may include, but not limited to, heartbeat failure alarm indicating one or more of a broken radio link to the core network of the communication network, service unavailability at a user plane at a node among the nodes 120, issue in backhaul connectivity, hardware malfunctioning at a node of thenodes 120, and site outage at a node of the nodes 120. The pre-defined alarm types corresponding to the service affecting alarms may include, but not limited to, loss in signal quality, degradation in cable quality connecting various parts of the communication network around a node among the nodes 120, and internal or external interference at a node among the nodes 120. Each vendor of the one or more vendors of the nodes 120 may have a different name for each of the alarm type among the pre-defined alarm types of the service affecting alarms and the performance degrading alarms.

[0099] The determination unit 236 maps each historical alarm from the historical data with the one or more pre-defined alarm types of the service affecting alarms and the performance degrading alarms. Accordingly, upon mapping each historical alarm from the historical data, the determination unit 236 determines the alarm type of each historical alarm corresponding to the service affecting alarms and the performance degrading alarms.

[0100] At step 308, the processor 210, using the determination unit 236, based on the determined alarm type and the historical alarm data, determines the count of the historical alarms of each alarm type raised at each node among the nodes 120. For example, it may be determined that five alarms related to issue in backhaul connectivity were identified to be raised at node A of vendor X of the nodes 120 in the geographical area in the user-defined time-period. It may further be determined that three alarms related to loss in signal quality and one alarm related to issue in the backhaul connectivity were identified to be raised at node B of vendor Y of the nodes 120 along with one alarm related to issue in backhaul connectivity was identified to be raised at node C of vendor Y in the geographical area in the user- defined time period.

[0101] At step 310, the processor 210, using the data processing unit 238, generates the visualization data based on the determined count of the historical alarms. The visualization data includes the information related to at least one of the aggregated count of the historical alarms of each alarm type within the geographical location orthe performance trend of the historical alarms for each alarm type within the geographical location during the user defined time -period.

[0102] The aggregated count of historical alarms corresponds to a summation or a total of a count of each alarm type of the service affecting alarms and the performance degrading alarms raised at a node among the nodes 120 of the one or more vendors in the geographical location at the user-defined time -period. For instance, in the above example, the aggregated count of the alarms at node A of vendor X is five alarms and the aggregated count of the alarms at node B, and node C of vendor Y is five alarms.

[0103] The performance trend of the historical alarms indicates either an individual count of the historical alarms for each alarm type for a plurality of time intervals within the user defined time-period, or the aggregated count of the historical alarms raised at the nodes 120 for the plurality of time intervals. For instance, the performance trend indicates an individual count of five alarms at the node A of vendor X related to issue in the backhaul connectivity along with time interval of each alarm raised in the user defined time -period and an individual count of one alarm each at the node B and the node C of vendor Y related to issue in the backhaul connectivity along with time interval of each alarm raised in the user defined time period. The individual count may be an alarm count of each type of historical alarm raised at each node among the nodes 120 corresponding to categories with respect to one or more nodes of the nodes 120, the maintenance cluster, and the service area in the geographical location.

[0104] At step 312, the processor 210, using the data processing unit 238, stores the generated visualization data in the second database 270-2. At step 314, the processor 210, using the data processing unit 238, controls the UI 132 of the user device 130 to display the visualization data based on the reception of the input from the user device 130 for visualizing the historical alarms corresponding to the nodes 120. The visualization data is displayed on the UI 132 upon fetching the storedvisualization data from the second database 270-2 using the distributed microservice 290.

[0105] The processor 210 controls the user device 130 to display options for receiving from the user, a selection of preferred form for the generated visualization data i.e., one of the aggregated count or the performance trend. The selection may be obtained via a nested navigation tab. Upon receiving the selection, the visualization data is displayed on the UI 132 upon fetching the stored visualization data from the second database 270-2 using the distributed microservice 290. Based on the selection made by the user, the visualization data including the performance trend of the historical alarms corresponding to a selection of one of the site, the service area, and the maintenance cluster within the geographical location may be displayed in one or more of a graphical format, pictorial format, tabular format or as statistical data.

[0106] In one embodiment, the processor 210, using the data processing unit 238, controls the UI 132 of the user device 130 to display the nested navigation tab for selecting one of the site, the service area, and the maintenance cluster within the geographical location. The data processing unit 238 controls the UI 132 to display options for selection of the maintenance cluster within the geographical location, the service area within the maintenance cluster, and the site within the service area.

[0107] Through the nested navigation tab, the user may select the maintenance cluster within the geographical location for viewing the performance trend of the nodes 120 within the site. Through the selection made in the nested navigation tab, the user may further select the service area within the maintenance cluster for viewing the performance trend of the nodes 120 within the service area. Furthermore, the user may select the site within the service area for viewing the performance trend of the nodes 120 within the site. The functionality provided by the nested navigation tab enables the user to drill down to a node level view of the performance trend of the nodes 120 within the site falling in the service area of the maintenance cluster, thereby enabling the user to locate an exact node of the nodes120 facing one or more of the service affecting alarms or performance degrading alarms impacting the communication network, at a single click.

[0108] In one embodiment, the data processing unit 238 controls the UI 132 to display the aggregated count of the historical alarms on the UI 132. The aggregated count of the historical alarms is categorized by at least one of the one or more vendors, the alarm type, the selected site, the service area, and the maintenance cluster within the geographical location. Furthermore, the aggregated count may be displayed in an ascending order or a descending order.

[0109] In one embodiment, the data processing unit 238 controls the UI 132 to display the performance trend of the historical alarms indicating the count of the historical alarms for each alarm type for a plurality of time intervals such as an hourly basis or daily basis within the user defined time-period such a week, a month, or a quarter year. In another embodiment, the data processing unit 238 controls the UI 132 to display the performance trend of the historical alarms indicating the aggregated count of the historical alarms raised at the plurality of nodes 120 for the plurality of time intervals such as the hourly basis or the daily basis or weekly basis. The count or the aggregated count in the performance trend is displayed on the UI 132 in a chronological sequence of the plurality of time intervals.

[0110] In one embodiment, the UI 132 and backend process of monitoring the historical performance of the nodes 120 implemented over the server 110 are tightly coupled in such a way that the user request for generating the visualization data for the nodes 120 of the one or more vendors in the geographic location in the user defined time period is fulfilled with minimum latency.

[0111] Fig. 3 presents an embodiment of the present disclosure where various operations (i.e., presented by way of the steps 302 through 314) are performed by the processor 210 using the processing unit(s) / module(s) 230. However, as will be appreciated by a person of ordinary skill in the art, in an alternate embodiment, the various operations of the steps 302 through 314 may be performed independentlyby the processing unit(s) / module(s) 230, without deviating from the scope of the present disclosure.

[0112] Fig. 4 illustrates a call flow diagram 400 depicting information exchange between the user device 130 and the components of the server 110 for monitoring the historical performance of the nodes 120 in the communication network, in accordance with an embodiment of the present disclosure. In particular, the call flow diagram 400 depicts a detailed illustration of one or more steps of the method 300 along with information flow between the one or more components of the server 110.

[0113] At instance 402, the user through the UI 132 running on the user device 130 interacts with the server 110 via the API gateway 140. The UI 132 provides an interface for the users to create a request configuration by input of the plurality of parameters for monitoring historical performance of the plurality of nodes 120 in the communication network. The request configuration includes the parameters such as one or more of the alarm type of the historical alarms to be visualized, the geographical location of the plurality of nodes, the user defined time-period for visualization of the historical alarms, the vendor identifier of the plurality of nodes, the RAT supported by the plurality of nodes such as 4G and 5G, and the identifier of the plurality of the nodes 120. The request configuration may be sent as the API request to the API gateway 140 for routing to an application server (alternatively referred to as “App server” or the “server 110”).

[0114] At instance 404, the API gateway 140 communicates the request configuration to the processor 210. The API gateway 140 initiates, via the task execution unit 234, the API request to the distributed microservice 290 deployed in the server 110. At instance 406, the processor 210 using the task execution unit 234, creates the record of the parameters in the second database 270-2, upon transmission of the API request.

[0115] The processor 210, at instance 408, upon creation of the record in the second database 270-2, the processor 210 using the task execution unit 234, transmits aquery to the first database 270-1 via the at least one distributed microservice 290 for fetching the historical alarm data corresponding to the received parameters.

[0116] In response, at instance 410, the processor 210 using the task execution unit 234, fetches from the first database 270-1 the historical alarm data including details related to the historical alarms raised by the nodes 120 for the one or more vendors in the geographical location during the user defined time period as specified by the user in the request configuration. Alternatively, the historical alarm data may be collected at a pre-defined time interval by running the scheduler 260 for fetching the historical alarm data from the first database 270-1. The processor 210 using the data processing unit 238, generates the visualization data based on the determined alarm type and the count of historical alarms of each alarm type.

[0117] Further, at instance 412, the processor 210 using the data processing unit 238, stores the generated visualization data in the second database 270-2. At instance 414, the second database 270-2 may initiate a call to the distributed microservice 290 for fetching the generated visualization data from the first database 270-1 for display to the user. Based on a reception of the input from the user device 130 for visualizing the historical alarms corresponding to the plurality of nodes, the generated visualization data is fetched from the first database 270-1. At instance 416, the distributed microservice 290 may initiate the API request to the API gateway 140.

[0118] At instance 418, the processor 210 using the data processing unit 238, forwards the API request to the UI 132 and controls display of the user device 130 on the UI 132 for display of the generated visualization data. The UI 132 may present the user with the trends for visualization in the graphical form, the pictorial format, the tabular format, or as statistical data.

[0119] In one embodiment, the processor 210 using the data processing unit 238, controls the GUI 132 of the user device 130 for displaying the generated visualization data. It may be understood that the GUI 132 comprises one or more screens to enable the user to view performance trends of the historical alarms, detailsof the historical alarms, and the aggregated count of the historical alarms in one or more of the node wise, vendor wise, site wise, service area wise, or maintenance cluster wise manner.

[0120] Fig. 5 illustrates an example of a first GUI 500 for input of the parameters for monitoring historical performance of the plurality of nodes 120 in the communication network, in accordance with an embodiment of the present disclosure. The processor 210, using the data processing unit 238, controls the first GUI 500 to include a user dashboard displaying a personalized user profile. The first GUI 500 may include options for selecting the plurality of parameters though optional filters 500-1 to 500-7 such as a filter 500-1 for RAT, for example, 4G, 5G or 6G, filter 500-2 for the one or more vendors of the nodes 120, filter 500-3 for the geographical location to be monitored, filter 500-4 for an Identifier (Id) or a type of node, filter 500-5, 500-6 for an alarm type corresponding to each vendor distinguished by an alarm identifier, and filter 500-7 for a time period of analyzing the alarms raised at the nodes 120.

[0121] In one embodiment, the processor 210 using the data processing unit 238, controls the first GUI 500 to display filters 500-1 to 500-7 to select different types of alarm for a same vendor, for viewing comparative analysis of different historical alarms for same vendor. In yet another embodiment, the first GUI 500 includes filters 500-1 to 500-7 to display the visualization data for comparing similar type of historical alarm for any two vendors.

[0122] Through the filter 500-3 for the geographical location displayed in the first GUI 500, the processor 210 using the reception unit 232, is configured to receive an input of the service regions or domains relevant to the nodes being analyzed. The first GUI 500 may present a drop-down list of pre-defined geographic locations including specific countries, local maintenance regions, or global coverage area. Through the filter 500-2 for the one or more vendors of the nodes, the processor 210 using the data processing unit 238, controls the first GUI 500 to display options for receiving a selection of the one or more vendors from a dropdown list of availablevendors. The processor 210 using the data processing unit 238, controls the first GUI 500 to display options for further selection of nodes from the one or more vendors through the filter 500-4 for the Identifier (Id) or the type of node for monitoring the historical performance, providing flexibility in comparative analysis of performance of nodes 120 of different vendors.

[0123] Similarly, the processor 210, using data processing unit 238, controls the first GUI 500, through the filter 500-7 for time period, to display options for receiving a selection of pre-defined time intervals (e.g., daily, weekly, monthly) or specify custom date ranges, to compare the historical alarms raised at the nodes 120 of the one or more vendors and assess their respective historical performances. In one embodiment, the reception unit 232 is configured to receive a selection of the inputs that are displayed against corresponding options for filters 500-1 to 500-7 in form of an expandable drop-down list. After receiving the selection of the filters 500-1 to 500-7, the processor 210 using the data processing unit 238, is configured to control the first GUI 500 to prompt the user to select an “Apply” button to visualization of the alarm data or a “Cancel” button to discard the plurality of filters 500-1 to 500-7.

[0124] In one embodiment, the processor 210 using the data processing unit 238, controls the first GUI 500 to display options for further selection of the alarm type from the filter 500-5, 500-6 for the alarm type corresponding to the node 120 of each vendor for monitoring the historical performance, providing flexibility in comparative analysis of performance of nodes 120 of different vendors corresponding to specific types of alarms. Upon receiving a selection of a first alarm type and a second alarm type from the filter 500-5, 500-6 for the alarm type corresponding to the node 120 of each vendor of the one or more vendors and a selection for visualization of the performance trend segregated by the service area, the processor 210, using the data processing unit 238, is configured to control display of a second GUI 600.

[0125] Fig. 6 illustrates an example of the second GUI 600 for visualizing a performance trend for nodes 120 of different vendors in the geographical region, in accordance with an embodiment of the present disclosure. The processor 210 is configured to control the user device 130, to display on the second GUI 600, the performance trend of the count of the first alarm type and the count of the second alarm type raised by the nodes of a first vendor and a second vendor in the geographical region selected by the user, respectively. The visualization data including the performance trend is displayed on the second GUI 600 in a graphical form such as a bar graph, histogram, or a pie chart. The processor 210 is configured to control the user device 130 to display the second GUI 600 including the visualization data in form of a bar graph where vertical axis represents the alarm count, and the horizontal axis displays each of the dates in the selected time -period. The bar graph may be color coded to represent the count of each alarm type of the nodes of each vendor.

[0126] In an embodiment, based on a selection operation performed by the user on the second GUI 600, the processor 210, using the data processing unit 238, is configured to control the user device 130 to display options for generating a plurality of various types of charts such as line graphs or area charts to visualize the alarm data. In another embodiment, based on a selection by the user, the processor 210 is configured to display the visualization data in the pictorial form or the graphical form.

[0127] The processor 210, using the data processing unit 238, is configured to control the second GUI 600 to display interactive controls to customize the visualization based on their preferences. The second GUI 600 may further include a toggle button to change visibility of the visualization data by adjusting axis scales and chart types. When the toggle button is pressed, the processor 210, using the data processing unit 238, is configured to optimize visualization of the historical alarm data for easy analysis.

[0128] In one embodiment, when the user makes a selection of the first alarm type and the second alarm type from the filter 500-5, 500-6 for the alarm type corresponding to the node 120 of each vendor of the one or more vendors and a selection for visualization of performance trend segregated by the type of node, the processor 210, using the data processing unit 238, is configured to display a third GUI 700 display screen for displaying node wise performance trend of the historical alarms.

[0129] Fig. 7 illustrates an example of the third GUI 700 for visualizing the performance trend of the historical alarms for a type of node of different vendors, in accordance with an embodiment of the present disclosure. The processor 210, using the data processing unit 238, is configured to control the third GUI 700 to display the visualization data of the node wise comparative performance trend of the historical alarms of the first alarm type and the second alarm type raised by various nodes of the first vendor and the second vendor. The processor 210, using the data processing unit 238, is further configured to control the user device 130 to display the third GUI 700 including the visualization data as the bar graph, based on a selection by the user, where a vertical axis represents the alarm count, and the horizontal axis displays each of the dates in the user specified time period, the various nodes raising the first alarm type and the second alarm type. Upon receiving a selection to segregate the performance trend based on the type of node, the processor 210, using the data processing unit 238, is configured to display the performance trend of the historical alarm data across the user specified time-period based on the type of node of the one or more vendors.

[0130] Further, in one embodiment, when the user makes a selection of the first alarm type and the second alarm type from the filter 500-5, 500-6 for the alarm type corresponding to the node 120 of each vendor of the one or more vendors and a selection for visualization of the total alarm count segregated by the service area, the processor 210, using the data processing unit 238, is configured to control the user device 130 to display a fourth GUI 800 for displaying the aggregated alarm count. Through selection of the tab “Total (By Geography)”, the user may view thetotal alarm count or aggregated count of the historical alarms of each alarm type within the geographical location during the user defined time-period.

[0131] Fig. 8 illustrates an example of the fourth GUI 800 for visualizing an aggregated count of historical alarms categorized by service area, in accordance with an embodiment of the present disclosure. The processor 210, using the data processing unit 238, is configured to control the user device 130 to display the fourth GUI 800 including the visualization data of the aggregated alarm count of the first alarm type and the second alarm type raised by various nodes of the first vendor and the second vendor, in different service area or geographic locations of various states and regions covered under the service area. The processor 210, using the data processing unit 238, is configured to generate the visualization data based on the count of alarms of nodes of each of the vendors, thereby enabling the user to compare performance of equipment supplied by various vendors in the service area.

[0132] The fourth GUI 800 is configured to display an option 800-1 for visualizing aggregated count of the historical alarms and an option 800-2 for visualizing the performance trend in the count of historical alarms or the aggregated count of historical alarms over the user- specified time -period. The fourth GUI 800 is further configured to display a nested navigation tab 800-3. Through the nested navigation tab 800-3, the processor 210, using the data processing unit 238, is configured to display options for receiving the selection one of the site, the service area, and the maintenance cluster within the geographical location. The data processing unit 238, controls the fourth GUI 800 to display the performance trend of the historical alarms raised at the nodes 120 corresponding to the selection of one of the site, the service area, and the maintenance cluster within the geographical location.

[0133] In another embodiment, based on the selection of one of the site, the service area, or the maintenance cluster within the geographical location, the processor 210 is configured to generate the visualization data indicating the aggregated alarm count of each alarm type of the historical alarms raised at the nodes 120. The aggregated count of alarms is segregated by at least one of vendors, service area,type of node, and the alarm type in the site, the service area, and the maintenance cluster.

[0134] Further, in one embodiment, when the user makes a selection of the first alarm type and the second alarm type from the type of alarm 500-5, 500-6 corresponding to the node of each vendor of the one or more vendors and a selection for visualization of the aggregated count of the historical alarms segregated by the type of node, the processor 210, using the data processing unit 238, is configured to control the user device 130 to display a fifth GUI 900 including information displaying the aggregated count of the historical alarms.

[0135] Fig. 9 illustrates an example of the fifth GUI 900 for visualizing an aggregated count of historical alarms categorized by the type of node, in accordance with an embodiment of the present disclosure. The fifth GUI 900 includes the visualization data of the aggregated alarm counts of the first alarm type and the second alarm type raised by various nodes of a user specified type of node of the first vendor and the second vendor. In one embodiment, the processor 210, using the data processing unit 238, is configured to generate the visualization data indicating comparison of any two co-related alarms raised at multiple nodes of the type of nodes of the one or more vendors, selected by the user. The fifth GUI 900 enables the user to analyze node level incidence of the count of historical alarms during the selected period for any geography. In one embodiment, the fifth GUI 900 includes the visualization data including information related to the historical alarms raised at the nodes 120, the impact of the alarms, the clear time of the historical alarm along with the determined alarm type and probable cause of the historical alarms. The user may also be able to bucketize the alarms into different categories to identify a repeating fault or issue in the node and apprise the vendor of a fault or performance issue of the node for corrective action.

[0136] Furthermore, the processor 210, using the data processing unit 238, is configured to control the user device 130 to display the visualization data of the nodes by view of maintenance clusters. Fig. 10 illustrates an example of a sixth GUI1000 for visualizing maintenance cluster wise aggregated count of the historical alarms, in accordance with an embodiment of the present disclosure. The processor 210, using the data processing unit 238, is configured to control the user device 130 to display the sixth GUI 1000 including the visualization data of a comparative performance trend of the count of historical alarms of the first alarm type and the second alarm type raised by various nodes of the first vendor and the second vendor, in different maintenance clusters in a selected geographic location of various states and regions covered under the service area. The processor 210, using the data processing unit 238, is configured to display through the sixth GUI 1000 a bar graph for the comparative trend of alarm functionality at a maintenance cluster / business cluster level. In one embodiment, the sixth GUI 1000 is configured to display the bar graph in a descending order of the alarm count and in addition display complete details of the nodes with the occurrence count of alarm along with reasons of causes of the alarms may also be downloaded for further analysis.

[0137] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by the system and the method disclosed herein include enabling the network operation team / field operation team to monitor the historical performance of the nodes from a maintenance cluster level to a service area level to a node level for a specific period by generating and displaying the visualization data of the historical alarms of each alarm type or the performance trend of the historical alarms.

[0138] Another advantage offered by the present disclosure is to enable the network operation team to visualize the performance trend of a particular type of alarm for any particular geographic location which can further be drilled down to incidences of such alarms to the node level for a deep dive analysis of repeated occurrence of the particular type of alarm. The system and the method disclosed herein thus serves as a monitoring tool in case of repetitive historical faults due to any outages, software upgrade, or hardware malfunctioning in the nodes in the communication network. Further, the GUIs and the generated visualization data as described here in one or more embodiments can help in enabling the network operation team to assessthe performance of the maintenance clusters and improve network availability which in turn result in reduction of customer complaints.

[0139] Furthermore, the visualization data generated by the disclosed system and the method ensures data integrity and make sure that critical data related to the alarms is reported to the user. Furthermore, the system and the method disclosed herein helps in monitoring the historical performance of the nodes with minimum latency and provides the visualization data to the user on command or a request from the user.

[0140] Still another noteworthy advantage of the present disclosure is that the disclosed system and the method allows the user to view comparative trends and total alarm counts of the individual products across the vendors, enabling assessment of their relative performance and identifying the areas for improvement the network. Further, disclosed system and the method allows the user to analyze vendor related performance of the nodes to analyze repeated causes of alarms, if any, and based on preemptive network performance, change the vendors if needed. Still another advantage of the present disclosure is that the disclosed system and the method enables the user to view alarm trend functionality seamlessly in a single glass pane view. The easy display of the visualization data of the historical alarms on the UI helps the network operations team to view comparative historical performance trends and counts of historical alarms of the individual nodes to assess their relative performance and identify the areas for improvement in the communication network.

[0141] Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments 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 implementedby 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.

[0142] 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 220) 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).

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

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

[0145] 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 oneembodiment 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.

[0146] 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

[0147] 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 - System for monitoring historical performance of the nodes in a communication network110 - Server120 - Nodes130 - Network Management Console (NMC)132 - Graphical User Interface (GUI)134 - Communication unit140 - Application Programming Interface (API) gateway150 - Network160 - Vendor Element Management System (EMS) cluster200 - Input-Output (VO) interface210 - Processor(s)220 - Memory220-1 - Instructions230 - Processing unit(s) / module(s)232 - Reception unit234 - Task execution unit236 - Determination unit238 - Data processing unit240 - Parser250 - Distributed stream processing platform260 - Scheduler270 - Databases270-1 - First database270-2 - Second database280 - Communication interface290 - Distributed Microservice(s)295 - Communication bus300 - Method for monitoring the historical performance of the nodes 120 in the communication network302-314 - Operation steps of the method 300400 - Call flow diagram depicting information exchange between the user device 130 and the components of the server 110402-418 - Operation steps of the call flow diagram 400500 - Example of first Graphical User Interface (GUI) for input of parameters for monitoring historical performance of the nodes 120 500-1 - Filter for selecting Radio Access Technology (RAT) 500-2 - Filter for selecting one or more vendors of the nodes500-3 - Filter for selecting a geographical location500-4 - Filter for selecting an Identifier (Id) or a type of node500-5 - 500-6 - Filter for selecting an alarm identifier or an alarm type corresponding to each vendor500-7 - Filter for selecting a time-period600 - Example of second GUI for visualizing a performance trend for nodes 120 of different vendors in a geographical region700 - Example of third GUI for visualizing a performance trend of historical alarms for a type of node of different vendors800 - Example of fourth GUI for visualizing an aggregated count of historical alarms categorized by service area800-1 - Option for visualizing aggregated count of historical alarms800-2 - Option for visualizing performance trend of the historical alarms800-3 - Nested navigation tab900 - Example of fifth GUI for visualizing an aggregated count of historical alarms categorized by the type of node1000 - Example of sixth GUI for visualizing maintenance cluster wise aggregated count of the historical alarms

Claims

WE CLAIM:

1. A method (300) for monitoring historical performance of a plurality of nodes (120) in a communication network, the method (300) comprising: receiving, by a reception unit (232) from a user device (130), a plurality of parameters for generating visualization data of historical alarms corresponding to the plurality of nodes (120) of one or more vendors for a geographical location during a user defined time -period; fetching, by a task execution unit (234) based on the plurality of parameters, historical alarm data from a first database (270-1), wherein the historical alarm data comprises details related to the historical alarms raised at the plurality of nodes (120) within the geographical location; determining, by a determination unit (236) based on the fetched historical alarm data, an alarm type of each of the historical alarms corresponding to the plurality of nodes (120) for each vendor of the one or more vendors; determining, by the determination unit (236) based on the determined alarm type and the historical alarm data, a count of the historical alarms of each alarm type corresponding to the plurality of nodes (120); and generating, by a data processing unit (238) based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count of the historical alarms of each alarm type within the geographical location or a performance trend of the historical alarms for each alarm type within the geographical location during the user defined time-period.

2. The method (300) as claimed in claim 1, wherein determining the alarm type, by the determination unit (236), comprises mapping each historical alarm from the historical data with one or more pre-defined alarm types using an alarm reference table.

3. The method (300) as claimed in claim 1, further comprising: transmitting, by the task execution unit (234) based on the reception of the plurality of parameters, an Application Programming Interface (API) request to at least one distributed microservice of a plurality of distributed microservices (290);creating, by the task execution unit (234) using the at least one distributed microservice, a record of the plurality of parameters in a second database (270-2) upon the transmission of the API request; transmitting, by the task execution unit (234) upon creation of the record of the plurality of parameters, a query to the first database (270-1) via the at least one distributed microservice; and fetching, by the task execution unit (234) in response to the transmitted query, the historical alarm data from the first database (270-1).

4. The method (300) as claimed in claim 3, further comprising: storing, by the data processing unit (238), the generated visualization data in the second database (270-2); and controlling, by the data processing unit (238), a User Interface (UI) (132) of the user device (130) to display the visualization data based on a reception of an input from the user device (130) for visualizing the historical alarms corresponding to the plurality of nodes (120), wherein the visualization data is displayed on the UI (132) upon fetching the stored visualization data from the second database (270-2) using the at least one distributed microservice.

5. The method (300) as claimed in claim 4, further comprising: controlling, by the data processing unit (238), the UI (132) of the user device (130) to display a nested navigation tab for selecting one of a site, a service area, and a maintenance cluster within the geographical location; and controlling, by the data processing unit (238), the UI (132) of the user device (130) to display the performance trend of the historical alarms corresponding to a selection of one of the site, the service area, and the maintenance cluster within the geographical location, wherein controlling, by the data processing unit (238), the UI (132) comprises displaying the aggregated count of the historical alarms on the UI (132), and wherein the aggregated count of the historical alarms is categorized by at leastone of the one or more vendors, the alarm type, the selected site, the service area, and the maintenance cluster within the geographical location in a descending order.

6. The method (300) as claimed in claim 1, wherein the performance trend of the historical alarms indicates one of the count of the historical alarms for each alarm type for a plurality of time intervals within the user defined time-period, or the aggregated count of the historical alarms raised at the plurality of nodes (120) for the plurality of time intervals, and wherein the count or the aggregated count is displayed on the UI (132) in a chronological sequence of the plurality of time intervals.

7. The method (300) as claimed in claim 1, further comprising: receiving, by the reception unit (232) from one or more nodes among the plurality of nodes (120), a message indicating clearance of one or more alarms raised at the one or more nodes, wherein the clearance of the one or more alarms corresponds to a change in a status of the one or more alarms from an active state to a resolved state; and updating, by the data processing unit (238), the historical alarm data in the first database (270-1) with the one or more alarms along with a timestamp of the clearance of each alarm among the one or more alarms.

8. The method (300) as claimed in claim 1, wherein the plurality of parameters includes one or more of the alarm type of the historical alarms to be visualized, the geographical location of the plurality of nodes (120), the user defined time period for visualization of the historical alarms, a vendor identifier of the plurality of nodes (120), a Radio Access Technology (RAT) supported by the plurality of nodes (120), and an identifier of the plurality of the nodes.

9. The method (300) as claimed in claim 1, wherein: the historical alarm data includes node identifier of each of the plurality of the nodes, an impact of each of the historical alarms at each of the plurality of the nodes, a raise time of each of the historical alarms, a clear time of each of thehistorical alarms, a root cause of the historical alarms, and an alarm identifier of each of the historical alarms; and the historical alarm data is fetched based on at least one of a user action, a scheduled task, or an event-driven process.

10. A system ( 100) for monitoring historical performance of a plurality of nodes (120) in a communication network, the system (100) comprising: a reception unit (232) configured to receive, from a user device (130), a plurality of parameters for generating visualization data of historical alarms corresponding to the plurality of nodes (120) of one or more vendors for a geographical location during a user defined time-period; a task execution unit (234) configured to fetch, based on the plurality of parameters, historical alarm data from a first database (270-1), wherein the historical alarm data comprises details related to the historical alarms raised at the plurality of nodes (120) within the geographical location; a determination unit (236) configured to: determine, based on the fetched historical alarm data, an alarm type of each of the historical alarms corresponding to the plurality of nodes (120) for each vendor of the one or more vendors; and determine, based on the alarm type and the historical alarm, a count of the historical alarms of each alarm type corresponding to the plurality of nodes (120); and a data processing unit (238) configured to generate, based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count of the historical alarms for each alarm type within the geographical location or a performance trend of the historical alarms of each alarm type within the geographical location during the user defined timeperiod.

11. The system (100) as claimed in claim 10, wherein, to determine the alarm type, the determination unit (236) is configured to map each historical alarm fromthe historical data with one or more pre-defined alarm types using an alarm reference table.

12. The system (100) as claimed in claim 10, wherein the task execution unit (234) is further configured to: transmit, based on the received plurality of parameters, an Application Programming Interface (API) request to at least one distributed microservice of a plurality of distributed microservices (290); and create, using the at least one distributed microservice, a record of the plurality of parameters in a second database (270-2) upon the transmission of the API request; transmit, upon creation of the record of the plurality of parameters, a query to the first database (270-1) via the at least one distributed microservice; and fetch, in response to the transmitted query, the historical alarm data from the first database (270-1).

13. The system (100) as claimed in claim 12, wherein the data processing unit (238) is further configured to: store the generated visualization data in the second database (270-2); and control a User Interface (UI) (132) of the user device (130) to display the visualization data based on a reception of an input from the user device (130) for visualizing the historical alarms corresponding to the plurality of nodes (120), wherein the visualization data is displayed on the UI (132) upon fetching the stored visualization data from the second database (270-2) using the at least one distributed microservice.

14. The system (100) as claimed in claim 13, wherein the data processing unit (238) is further configured to: control the UI (132) of the user device (130) to display a nested navigation tab for selecting one of a site, a service area, and a maintenance cluster within the geographical location; andcontrol the UI (132) of the user device (130) to display the performance trend of the historical alarms corresponding to a selection of the one of the site, the service area, and the maintenance cluster within the geographical location, wherein the data processing unit (238) is further configured to display, on the UI (132), the aggregated count of the historical alarms, and wherein the aggregated count of the historical alarms is categorized by at least one of the one or more vendors, the alarm type, the selected site, the service area, and the maintenance cluster within the geographical location in a descending order.

15. The system (100) as claimed in claim 12, wherein the first database (270-1) and the second database (270-2) correspond to one or more of an in-memory storage, a distributed database, a distributed file system, a relational database, a centralized database, a non-relational database, a hierarchical database, a network database, or an in-memory database including a distributed in-memory data storage.

16. The system (100) as claimed in claim 10, wherein the performance trend of the historical alarms indicates one of the count of the historical alarms for each alarm type for a plurality of time intervals within the user defined time period, or the aggregated count of the historical alarms raised at the plurality of nodes (120) for the plurality of time intervals, and wherein the count or the aggregated count is displayed on the UI (132) in a chronological sequence of the plurality of time intervals.

17. The system (100) as claimed in claim 10, wherein: the reception unit (232) is further configured to receive from one or more nodes among the plurality of nodes (120), a message indicating clearance of one or more alarms raised at the one or more nodes, wherein the clearance of the one or more alarms corresponds to a change in a status of the one or more alarms from an active state to a resolved state; and the data processing unit (238) is further configured to update the historical alarm data in the first database (270-1) with the one or more alarms along with a timestamp of clearance of each alarm among the one or more alarms.

18. The system (100) as claimed in claim 10, wherein the plurality of parameters includes one or more of the alarm type of the historical alarms to be visualized, the geographical location of the plurality of nodes (120), the user defined time-period for visualization of the historical alarms, a vendor identifier of the plurality of the nodes, a Radio Access Technology (RAT) supported by the plurality of the nodes, and an identifier of the plurality of the nodes.

19. The system (100) as claimed in claim 10, wherein: the historical alarm data includes node identifier of each of the plurality of the nodes, an impact of each of the historical alarms at each of the plurality of the nodes, a raise time of each of the historical alarms, a clear time of each of the historical alarms, a root cause of the historical alarms, and an alarm identifier of each of the historical alarms; and the historical alarm data is fetched based on at least one of a user action, a scheduled task, or an event-driven process.

20. 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, from a user device, a plurality of parameters for generating visualization data of historical alarms corresponding to the plurality of nodes of one or more vendors for a geographical location during a user defined time-period; fetching, based on the plurality of parameters, historical alarm data from a first database, wherein the historical alarm data comprises details related to the historical alarms raised at the plurality of nodes within the geographical location; determining, based on the fetched historical alarm data, an alarm type of each of the historical alarms corresponding to the plurality of nodes for each vendor of the one or more vendors; determining, based on the determined alarm type and the historical alarm data, a count of the historical alarms of each alarm type corresponding to the plurality of nodes; andgenerating, based on the determined count of the historical alarms, the visualization data including information related to at least one of an aggregated count of the historical alarms of each alarm type within the geographical location or a performance trend of the historical alarms for each alarm type within the geographical location during the user defined time-period.

Images