Abstract: ABSTRACT SYSTEM AND METHOD FOR HANDLING ALARMS IN A NETWORK A system and a method of handling alarms in a network is described. The method includes classifying a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network. The method further includes scheduling a task with a specified time interval for handling the child alarms post identification of the parent alarms. The method further includes correlating common attributes between the parent alarms and the child alarms. The method further includes generating a trouble ticket with identities of the parent alarms and identities of the child alarms associated with one or more of the parent alarms. Ref. Fig. 4
DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR HANDLING ALARMS IN A NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION
THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.
FIELD OF THE INVENTION
[0001] The present invention generally relates to node domain alarm correlation, more particularly relates to a system and method for automated inter/intra node domain alarm correlation.
BACKGROUND OF THE INVENTION
[0002] Efficient network management is vital for telecom operators to ensure continuous service delivery and maintain operational continuity. This is a critical piece in the overall telecommunication network management solution which enables visualization and management of use cases. It is the sole mediator for moderating and managing the Fault Configuration Administration Performance Security (FCAPS) data of the network elements and provides a single pane of glass for the Network Operations Centre.
[0003] The visualization and monitoring of use cases is performed by a Network Management System (NMS) which is a common platform that can integrate with all network function elements / nodes, it supports different types of protocols by integrating with the devices (hardware & software). Once integration is done all configuration data of the node is extracted, if a node is running successfully and there is a fault in the node, the node generates an alarm which is sent to NMS.
[0004] Typically, in case of a fault in one part of the system, the main node having a fault as well as neighboring nodes raise alarms. Therefore, due to one fault, multiple modules may not work resulting in multiple alarms due to a single fault, issuing multiple trouble tickets. The trouble tickets are equivalent to complaints with associated alarm information condensed together. The information carried in these alarms are restricted to who raised said alarm and minimum information about the issue, information on neighboring domain etc. are not offered. This makes it difficult to pinpoint the faulty equipment thereby increases the work to be performed by the rectifying team as they need to go through all the trouble tickets raised not just by the main/faulty node but also all the neighboring nodes. This can be time consuming.
[0005] Therefore, currently the alarms are raised not just by the actual node having fault but multiple others (neighboring) for a single fault due to the existence of many to one connection between elements within a system, resulting in many more alarms than the actual quantum of fault. Further, these alarms offer insufficient information about the fault, resulting in multiple alarms with information insufficient to instantly lead the rectification process to the source, making it difficult to pinpoint the faulty equipment and the failure recovery process time consuming.
[0006] Thus, there is a need for a solution which addresses the above mentioned shortcomings.
SUMMARY OF THE INVENTION
[0007] One or more embodiments of the present disclosure provide a system and method of handling alarms in a network.
[0008] In one aspect of the present invention, a system for handling alarms in a network is disclosed. The system includes a correlation engine configured to classify a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network. The correlation engine schedules a task with a specified time interval for handling the child alarms upon identifying the parent alarms. The correlation engine correlates common attributes between the parent alarms and the child alarms. The system further includes a trouble ticket processor configured to generate a trouble ticket with identities of the parent alarms and the identities of the child alarms associated with one or more of the parent alarms.
[0009] In one aspect, the system further comprises an enrichment engine for enriching the plurality of alarms prior classification by the correlation engine. The correlation engine modifies existing alarms stored in a database with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms. The correlation engine classifies the plurality of alarms as the child alarms when corresponding parent alarms are not identified in the specified time interval. The correlation engine groups the plurality of alarms based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms. The correlation engine groups the plurality of alarms as the child alarms when corresponding parent alarms are already present within the specified time interval. The correlation engine promotes the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated. The identification is created based on one of a type of correlation applied, relationship status, and newly populated information corresponding to the modifications made. The correlation engine identifies association between the parent alarms and the child alarms based on a point of interaction (POI) relationship. The correlation engine identifies association between the parent alarms and the child alarms based on intra, inter, cross domain relationships between the plurality of alarms.
[0010] In another aspect of the present invention, a method of handling alarms in a network is described. The method includes classifying a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network. The method further includes scheduling a task with a specified time interval for handling the child alarms post identification of the parent alarms. The method further includes correlating common attributes between the parent alarms and the child alarms. The method further includes generating a trouble ticket with identities of the parent alarms and identities of the child alarms associated with one or more of the parent alarms.
[0011] In one aspect, the plurality of alarms is enriched prior to classification by the correlation engine. The plurality of alarms is classified as the child alarms when corresponding parent alarms are not identified within the specified time interval. The existing alarms stored in a database are modified with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms. The plurality of alarms is classified as the child alarms when corresponding parent alarms are already present within the specified time interval. The plurality of alarms is grouped based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms. The child alarms are promoted in the order of preference of their respective trigger times when the parent alarms are terminated. A type of correlation applied, relationship status, and newly populated information corresponding to the modifications made for creating the identification are identified. An association between the parent alarms and the child alarms is identified based on a point of interaction (POI) relationship. An association between the parent alarms and the child alarms is identified based on intra, inter, cross domain relationships between the plurality of alarms.
[0012] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0014] FIG. 1 illustrates a network architecture of a system for handling alarms in a network, according to one or more embodiments of the present disclosure;
[0015] FIG. 2 illustrates a block diagram of the system for handling alarms in a network, according to various embodiments of the present system;
[0016] FIG. 3 illustrates a block diagram of the system communicating with a node for handling alarms, according to various embodiments of the present system;
[0017] FIG. 4 illustrates a system operation architecture for handling alarms in a network, according to one or more embodiments of the present disclosure;
[0018] FIG. 5 illustrates a flow chart of a method executed when a scheduled task for a parent alarm is triggered, according to one or more embodiments of the present disclosure; and
[0019] FIG. 6 illustrates a flow chart of a method of handling alarms in a network, according to one or more embodiments of the present disclosure.
[0020] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0021] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0022] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0023] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0024] In accordance with an exemplary embodiment of the invention, alarms raised due to system fault/failure are analyzed to identify eligibility of alarms for correlation depending on whether the issue causing failure can affect the service. Additionally, relationship between said alarms, if any, are analyzed, where common attributes between alarms are identified. The alarms are correlated to generate a single trouble ticket containing sufficient information required to identify the common root cause of the system fault/failure.
[0025] In accordance with an exemplary embodiment, the relation identification of alarms involves recognizing a parent-child relationship, which is identified by the alarm name (unique ID). Typically, a parent alarm sources to the source of main fault, while the child alarms are generated by the neighboring/surrounding nodes as a result of the parent alarm/main fault, such that resolving the parent alarm / fault would ideally result in resolving of the child alarm / fault(s). After a relationship between alarms and common attributes between alarms are identified, the alarms are corelated based on common attributes. Correlation of alarms enables reducing multiple trouble ticket generation to a single trouble ticket containing sufficient information to tackle the system fault/failure.
[0026] Further, in accordance with the exemplary embodiment, where relation identification of alarms involves a parent-child relationship (defined by the alarm name (unique ID)), and wherein after resolution of the parent alarm if the child alarms are yet unresolved or where parent alarms are prematurely terminated before specified time interval, such unresolved child alarm(s) are automatically promoted to parent alarm(s).
[0027] Further, in accordance with an exemplary embodiment, if only a single alarm having no similarities with other alarms is raised, it is identified as a parent alarm, and a task is scheduled at a pre-defined time (time-based correlation) to check the system database for similar alarms (child alarm) after the lapse of such pre-defined time. If after the pre-defined time period the parent alarm is resolved additional information is collectively created by modifying the addition text of parent alarm with the aggregated information of the child alarms and runtime translation of referenced alarm attributes in the template and the alarms are correlated to generate a single trouble ticket.
[0028] In accordance with an exemplary embodiment, the relation identification of alarms involves recognizing a POI (point of interaction) relationship. Further, alarms having a common point of interaction are tagged and a single trouble ticket for the issue is generated.
[0029] Further in accordance with an exemplary embodiment, the relation identification of alarms involves recognizing intra, inter, cross domain relationships between alarms.
[0030] FIG. 1 illustrates a network architecture of a system for handling alarms in a network. The network architecture comprises a plurality of network nodes 102-1, 102-2,……,102-n. At least one of the network nodes 102-1 through 102-n may be configured to connect to a server 105. For ease of disclosure, a network node whose alarms are handled is referred as node 102.
[0031] The node 102 may comprise a memory such as a volatile memory (e.g., RAM), a non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, etc.), an unalterable memory, and/or other types of memory. In one implementation, the memory might be configured or designed to store data. The node 102 may connect with the server 105 for sending alarms. The node 102 may be configured to connect with the server 105 through a communication network 110. The communication network 110 may use one or more communication interfaces/protocols such as, for example, VoIP, 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, Radio Frequency (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0032] The server 105 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a business telephony application server (BTAS), a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise, a defence facility, or any other facility that provides content.
[0033] Further, the server 105 may be communicably connected to a system 125, via the communication network 110. The system 125 may be configured to access services subscribed by enterprises, and additional services as mentioned above.
[0034] A person skilled in the art will appreciate that the plurality of nodes 102 may include end devices and intermediary devices. The end devices serve as originator of data or information flowing through the communication network 110. For example, the end devices may include workstations, laptops, desktop computers, printers, scanners, servers (file servers, web Servers), mobile phones, tablets, and smart phones. The intermediary devices are configured to forward data from one point to another in a communication network 110. For example, the intermediary devices may include hubs, modems, switches, routers, bridges, repeaters, security firewalls, and wireless access points.
[0035] The communication network 110 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The communication network 110 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0036] The communication network 110 may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.
[0037] The system 125 (alternatively referred as a Network Management system (NMS) 125) is communicably coupled to the server 105 and each of the first node 102-1, the second node 102-2, and the third node 102-n via the communication network 110. The system 125 is configured to handle repetitive alarms and auditing. The system 125 is adapted to be embedded within the server 105 or is embedded as an individual entity. However, for the purpose of description, the system 125 is described as an integral part of the server 105, without deviating from the scope of the present disclosure.
[0038] In various embodiments, the system 125 may be generic in nature and may be integrated with any application including a System Management Facility (SMF), an Access and Mobility Management Function (AMF), a Business Telephony Application Server (BTAS), a Converged Telephony Application Server (CTAS), any SIP (Session Initiation Protocol) Application Server which interacts with core Internet Protocol Multimedia Subsystem (IMS) on Industrial Control System (ISC) interface as defined by Third Generation Partnership Project (3GPP) to host a wide array of cloud telephony enterprise services, a System Information Blocks (SIB)/ and a Mobility Management Entity (MME).
[0039] Session Management Function (SMF) is a control function that manages user sessions including establishment, modification and release of sessions, and allocates IP addresses for IP PDU sessions. The SMF communicates indirectly with the UE through the AMF that relays session-related messages between the devices and the SMF.
[0040] Access and Mobility Management Function (AMF) is a key component in 5G mobile networks, responsible for managing access to the network and handling mobility-related functions for user equipment (UE), such as smartphones, tablets, and IoT devices. AMF works closely with other network functions to facilitate seamless connectivity, mobility, and quality of service for mobile users.
[0041] Business Telephony Application Server (BTAS) is a server-based system that provides telephony services and applications for businesses. It serves as a central platform for managing and delivering various voice communication services, such as voice calls, voicemail, conferencing, and interactive voice response (IVR) systems.
[0042] Converged Telephony Application Server (CTAS) is a server-based system that integrates various telephony and communication services into a single platform, enabling businesses to streamline their communication infrastructure and offer a wide range of communication features. CTAS combines traditional telephony services with advanced IP-based communication capabilities to provide a unified and cohesive communication experience.
[0043] SIP (Session Initiation Protocol) application server is a server-based system that facilitates the establishment, management, and termination of communication sessions using the SIP protocol. SIP application servers play a central role in IP-based telecommunications networks, enabling a wide range of real-time communication services, including voice calls, video calls, instant messaging, presence, and multimedia conferencing.
[0044] Internet Protocol Multimedia Subsystem (IMS) is a standardized architecture that enables the delivery of multimedia communication services over IP networks, including voice, video, messaging, and presence services. IMS is designed to provide a framework for delivering real-time communication services in a flexible, scalable, and interoperable manner.
[0045] Cloud telephony enterprise services refer to communication solutions delivered over the cloud that cater specifically to the needs of businesses and organizations. These services leverage cloud technology to provide scalable, flexible, and cost-effective communication solutions, including voice calls, messaging, collaboration tools, and contact center capabilities.
[0046] System Information Blocks (SIBs) are messages broadcast by a base station (eNodeB in LTE, NodeB in UMTS, or eNB in 5G) to provide essential information to mobile devices (UEs) in a cellular network. SIBs contain network-related information necessary for UEs to access and operate within the network efficiently. These blocks are periodically transmitted over broadcast channels, allowing UEs to receive and decode them even when they are not actively engaged in communication.
[0047] In the context of mobile networks, specifically in the LTE (Long-Term Evolution) and 5G architectures, the Mobility Management Entity (MME) is a key network element responsible for managing mobility-related functions for user equipment (UE) or mobile devices. The MME is part of the Evolved Packet Core (EPC) network in LTE and the 5G Core (5GC) network in 5G, serving as a control plane entity that handles signaling and control procedures for mobility management.
[0048] Operational and construction features of the system 125 will be explained in detail successively with respect to different figures. FIG. 2 illustrates a block diagram of the system 125 for handling alarms in a network, according to one or more embodiments of the present disclosure.
[0049] As per the illustrated embodiment, the system 125 includes one or more processors 205, a memory 210, and an input/output interface unit 215. The one or more processors 205, hereinafter referred to as the processor 205, may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system 125 includes the processor 205. However, it is to be noted that the system 125 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. Among other capabilities, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0050] In an embodiment, the input/output (I/O) interface unit 215 includes a variety of interfaces, for example, interfaces for data input and output devices, referred to as Input/Output (I/O) devices, storage devices, and the like. The I/O interface unit 215 facilitates communication of the system 125. In one embodiment, the I/O interface unit 215 provides a communication pathway for one or more components of the system 125. Examples of such components include, but are not limited to, the nodes 102, a database 220, and a distributed cache 225.
[0051] The database 220 is one of, but is not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache database, and so forth. The foregoing examples of the database 220 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0052] The distributed cache 225 is a pool of Random-Access Memory (RAM) of multiple networked computers into a single in-memory data store for use as a data cache to provide fast access to data. The distributed cache 225 is essential for applications that need to scale across multiple servers or are distributed geographically. The distributed cache 225 ensures that data is available close to where it’s needed, even if the original data source is remote or under heavy load.
[0053] Further, the processor 205, in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 125 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 125 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0054] For the system 125 to handle alarms in a network, the processor 205 implements a correlation engine 228 communicably coupled to each of the first node 102-1, the second node 102-2, and the third node 102-n via the communication network 110. Accordingly, the correlation engine 228 is configured to classify a plurality of alarms received from the node 102 into parent alarms or child alarms associated with the parent alarms. Each alarm may be indicative of a hardware, software, or network issue associated with the node 102. The correlation engine 228 classifies the plurality of alarms based on a policy configured for a network in which the node 102 is present. The correlation engine 228 may identify association between the parent alarms and the child alarms based on a point of interaction (POI) relationship, or intra, inter, cross domain relationships between the plurality of alarms.
[0055] The correlation engine 228 schedules a task with a specified time interval for handling the child alarms post identification of the parent alarms. The correlation engine 228 classifies the plurality of alarms as the child alarms when corresponding parent alarms are not identified within the specified time interval. The correlation engine 228 also classifies the plurality of alarms as the child alarms when corresponding parent alarms are already present within the specified time interval. The correlation engine 228 also correlates common attributes between the parent alarms and the child alarms.
[0056] The correlation engine 228 modifies existing alarms stored in the database 220 with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms. Corresponding to the modifications made for creating the identification, the correlation engine 228 identifies one of a type of correlation applied, relationship status, and newly populated information.
[0057] The correlation engine 228 promotes the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated. The correlation engine 228 groups the plurality of alarms based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms.
[0058] The processor 205 further implements a Trouble Ticket (TT) processor 230 communicably coupled to the correlation engine 228 for generating a trouble ticket with identities of the parent alarms and identities of the child alarms associated with the parent alarms.
[0059] The processor 205 further implements an enrichment engine 235 communicably coupled to the correlation engine 228 for enrichment of the plurality of alarms prior to classification by the correlation engine 228. Enrichment means appending of new attributed into an alarm. The enrichment may be of two types, physical enrichment and logical enrichment.
[0060] The database 220 of the system 125 serves as a non-structured (NoSQL) database that stores the enrichment data collected during one or more of the physical enrichment and the logical enrichment. The database 220 plays a crucial role in persistently storing and managing data related to alarms.
[0061] Referring to FIG. 3 illustrating a block diagram of the system 125 communicating with a first node 102-1 for handling alarms, a preferred embodiment of the system 125 is described. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first node 102-1 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0062] The first node 102-1 includes one or more primary processors 305 communicably coupled to the processor 205 of the system 125. The one or more primary processors 305 are coupled with a memory unit 310 storing instructions which are executed by the one or more primary processors 305. Execution of the stored instructions by the one or more primary processors 305 enables the first node 102-1 to provide an alarm corresponding to an event. The first node 102-1 further includes a kernel 315 which is a core component serving as the primary interface between hardware components of the first network device 110a and the plurality of services at the database 220. The kernel 315 is configured to provide the plurality of services on the first node 102-1 to resources available in the communication network 110. The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0063] In the preferred embodiment, the correlation engine 228 of the processor 205 is communicably connected to the kernel 315 of the first node 102-1. The correlation engine 228 is configured to classify a plurality of alarms received from the node 102 into parent alarms or child alarms associated with the parent alarms. Each alarm may be indicative of a hardware, software, or network issue associated with the node 102. In one implementation, the correlation engine 228 may classify the plurality of alarms based on a policy configured for a network in which the node 102 is present. The policy may include one or more rules defined based on understanding of architecture and operation of the network including the node 102. Attributes of the alarms and values of the attributes are checked based on the rules, and the alarms are classified as parent alarms or child alarms. For example, certain alarm ID, alarm format, start with, end with, and probable causes would be predefined for identification of the parent alarms and the child alarms. Based on matching of one or more of these parameters, the alarms will be classified as the parent alarms or the child alarms.
[0064] In another implementation, the correlation engine 228 may identify association between the parent alarms and the child alarms based on a point of interaction (POI) relationship, or intra, inter, cross domain relationships between the plurality of alarms. The POI relationship means a functional relation between a node with several other nodes due to which the several other nodes raise alarms when a fault is associated with the node.
[0065] The intra domain relationships pertain to alarms that are related or correlated within the same administrative or operational domain. For example, within a single network or organizational domain, alarms from different devices (routers, switches, servers) may be correlated to identify a root cause or common issue affecting local operations. Such relationships help in local troubleshooting, incident response, and maintenance within a specific network segment or administrative boundary.
[0066] The inter domain relationships involve alarms that span across different administrative or operational domains but within the same overarching network or service provider. For example, alarms from different segments of a large network (e.g., core network, access network) may be correlated to understand how issues in one domain affect others or to track service-level impacts. Such relationships facilitate coordination and communication between different operational teams or departments within the same organization or service provider.
[0067] The cross domain relationships refer to alarms that are correlated or related across entirely separate administrative or operational domains, often involving different organizations or service providers. For example, alarms related to interconnections between different service providers, where issues in one provider's network affect services provided by another. Such relationships support collaboration, coordination, and troubleshooting across organizational boundaries, ensuring efficient resolution of cross-network or inter-provider issues.
[0068] The correlation engine 228 schedules a task with a specified time interval for handling the child alarms post identification of the parent alarms. The correlation engine 228 classifies the plurality of alarms as the child alarms when corresponding parent alarms are not identified within the specified time interval. The correlation engine 228 also classifies the plurality of alarms as the child alarms when corresponding parent alarms are already present within the specified time interval. The correlation engine 228 also correlates common attributes between the parent alarms and the child alarms.
[0069] The correlation engine 228 modifies existing alarms stored in the database 220 with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms. Corresponding to the modifications made for creating the identification, the correlation engine 228 identifies one of a type of correlation applied, relationship status, and newly populated information. The correlation applied refers to the common attributes or combination of attributes obtained from different alarms. The relationship status refers to a parent child relationship or a group relationship in which all alarms are related to each other. The newly populated information refers to a final result obtained after performing an operation like correlation between attributes of different alarms.
[0070] The correlation engine 228 promotes the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated. The correlation engine 228 groups the plurality of alarms based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms.
[0071] The processor 205 further implements a Trouble Ticket (TT) processor 230 configured to generating a trouble ticket with identities of the parent alarms and identities of the child alarms associated with the parent alarms. The processor 205 further implements an enrichment engine 235 configured to the correlation engine 228 for enrichment of the plurality of alarms prior to classification by the correlation engine 228. Enrichment means appending new attributes into the alarm. The enrichment may be physical enrichment and logical enrichment. The physical enrichment involves including static data of an associated node within a corresponding alarm, and the logical enrichment involves including contextual information related to network protocols, routing, virtual configurations, and logical relationships between network elements into the alarm. Physical enrichment attributes may comprise a device location, device type, interface details, serial numbers, rack or cabinet number, power supply status, temperature and environmental conditions, device health and status, software and firmware versions, and connectivity information. Logical enrichment attributes may comprise Internet Protocol (IP) address, routing protocols, Virtual Local Area Network (VLAN) configurations, network topology, virtual network configurations, network service mappings, logical relationships between network elements, network policies, and Access Control Lists (ACLs).
[0072] An IP address, or Internet Protocol address, is a numerical label assigned to each device connected to a computer network that uses the Internet Protocol for communication. It serves two main purposes: identifying the host or network interface and providing the location of the device in the network. There are two primary versions of IP addresses currently in use: IPv4, which consists of four sets of numbers separated by periods (e.g., 192.0.2.1), and IPv6, which uses a longer hexadecimal format (e.g., 2001:0db8:85a3:0000:0000:8a2e:0370:7334). IP addresses are essential for devices to communicate with each other over the internet.
[0073] Routing protocols are a set of rules or algorithms that determine the best path for data packets to travel from one network to another in a computer network. These protocols are essential for routers to exchange information and make decisions about how to forward data across interconnected networks. A few common routing protocols include Distance Vector Routing Protocol, Link-State Routing Protocol, Hybrid Routing Protocol, and Border Gateway Protocol.
[0074] VLAN (Virtual Local Area Network) configurations involve setting up and managing virtual LANs within a network infrastructure. VLANs allow you to segment your network logically, even if devices physically connect to the same switch or router.
[0075] Network topology refers to the physical or logical layout of a computer network. It defines how devices such as computers, servers, switches, routers, and other peripherals are interconnected and how data flows between them. A few common network topologies include star topology, bus topology, ring topology, mesh topology, and tree topology.
[0076] Virtual network configurations involve setting up and managing virtual networks within a physical network infrastructure. These virtual networks operate independently of the physical hardware, allowing for greater flexibility, scalability, and resource optimization.
[0077] Network service mapping is the process of identifying and documenting the relationships and dependencies between network services and the underlying IT infrastructure components that support them. This mapping provides a visual representation of how various services are interconnected and how they rely on specific hardware, software, and configurations within the network.
[0078] Logical relationships between network elements refer to the connections and dependencies that exist between various components in a network at a conceptual or logical level. These relationships define how data flows, how devices communicate, and how services are delivered within the network.
[0079] Network policies are sets of rules, guidelines, and procedures that govern how a network is managed, configured, secured, and used. These policies define the acceptable use of network resources, establish security measures, and outline procedures for network administration. A few common types of network policies include Acceptable user policy, security policy, access control policy, data retention policy, and network configuration policy.
[0080] FIG. 4 illustrates a system operation architecture for handling alarms in a network, according to one or more embodiments of the present disclosure. A collector component 405 collects stream data from network elements, parses and transforms the stream data into alarms of standardized format, and pushes the alarms into an alarm stream 408. The alarms can be of two types, raise alarm and clear alarm. An FM master module 410 consumes the alarms from the alarm stream 408 and stores them into the distributed cache 225. Upon identifying that an alarm is already stored, the FM master module 410 updates occurrence count and timestamp array of the alarm in the distributed cache 225.
[0081] The raise FM module 415 fetches the alarms from the distributed cache 225 based on their unique identifiers and performs various operations on the alarms, such as planned event processing, AI-based correlation to identify patterns or related events, and trouble ticketing to initiate incident management processes. The raise FM module 415 also updates metadata associated with the alarms, enriches the alarms with additional information or context, and inserts them into the database 220. The clear FM module 420 retrieves clear alarms corresponding to the unique alarm identifiers from the distributed cache 225 and check the database 220 for presence of associated raise alarms. The clear FM module 420 deletes the raise alarms from an active section when the associated raise alarms are identified to be present and stream the clear alarms for retrying when the associated raise alarms are identified to be absent. After deleting the raise alarms from the active section, the clear FM module 420 adds clearance metadata to the alarms, and stores them in an archived section of the database 220. A retry FM module 425 check the database 220 for presence of the raise alarms corresponding to retry alarm data and deletes the raise alarms from the active section when identified to be present. If the raise alarms are not found, the retry FM module 425 increments the retry count and reproduces the data into the retry stream for subsequent retries.
[0082] The enrichment engine 235 performs enrichment of the alarms. Enrichment means appending new attributes into the alarms, and may be of two types, physical enrichment and logical enrichment. Post enrichment of the alarms by the enrichment engine 235, the correlation engine 228 classifies the alarms into parent alarms or child alarms associated with the parent alarms. The correlation engine 228 classifies the alarms based on a policy configured for a network in a node raising the alarms is present. The correlation engine 228 may identify association between the parent alarms and the child alarms based on a point of interaction (POI) relationship, or intra, inter, cross domain relationships between the alarms.
[0083] The correlation engine 228 schedules a task with a specified time interval for handling the child alarms post identification of the parent alarms. The correlation engine 228 classifies the alarms as the child alarms when corresponding parent alarms are not identified within the specified time interval. The correlation engine 228 also classifies the alarms as the child alarms when corresponding parent alarms are already present within the specified time interval. The correlation engine 228 also correlates common attributes between the parent alarms and the child alarms. The correlation engine 228 modifies existing alarms stored in the database 220 with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms. Corresponding to the modifications made for creating the identification, the correlation engine 228 identifies one of a type of correlation applied, relationship status, and newly populated information. The correlation engine 228 promotes the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated. The correlation engine 228 groups the alarms based on the common attributes when the alarms are not classified as the parent alarms and the child alarms.
[0084] The Trouble Ticket (TT) processor 230 generates a trouble ticket with identities of the parent alarms and identities of the child alarms associated with the parent alarms.
[0085] FIG. 5 illustrates a flow chart of a method 500 executed when a scheduled task for a parent alarm is triggered, according to one or more embodiments of the present disclosure. For the purpose of description, the method 500 is described with the embodiments as illustrated in FIGS. 1 and 4 and should nowhere be construed as limiting the scope of the present disclosure.
[0086] At step 505, the method 500 includes the step of receiving an alarm corresponding to a network event, by a processor. The alarm may indicate a hardware, software, or network issue associated with a node present in a network.
[0087] At step 510, the method 500 includes the step of determining whether a received alarm is a parent alarm. When a single alarm having no similarities with other alarms is raised, it is identified as a parent alarm. When the received alarm isn’t identified as a parent alarm, no action is taken, at step 515. Alternatively, when the received alarm is identified as a parent alarm, a time-based correlation task is scheduled, at step 520.
[0088] At step 520, the method 500 includes the step of scheduling the time-based correlation task to check a database for presence of one or more similar alarms i.e. child alarms, after lapse of specified time.
[0089] At step 525, the method 500 includes the step of determining if the parent alarm is still active. After resolution of the parent alarm, if the child alarms are yet unresolved or where parent alarms are prematurely terminated before specified time interval, such unresolved child alarms are automatically promoted to parent alarms, at step 530. When no child alarms are found, the task is terminated, at step 535.
[0090] At step 540, the method 500 includes the step of creating additional information when the alarms remain unsolved i.e. are active. The additional information is collectively created by modified addition text of parent alarm with the aggregated information of the child alarms and runtime translation of references alarm attributes in the template.
[0091] At step 545, the method 500 includes the step of raising a trouble ticket by correlating the alarms. Such trouble ticket contains sufficient information required to identify common root cause of an issue corresponding to the alarm.
[0092] FIG. 6 illustrates a flow chart of a method 600 executed for handling alarms in a network, according to one or more embodiments of the present disclosure. For the purpose of description, the method 600 is described with the embodiments as illustrated in FIGS. 1 and 4 and should nowhere be construed as limiting the scope of the present disclosure.
[0093] At step 605, the method 600 includes the step of classifying a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms. The plurality of alarms is classified based on a policy configured for the network.
[0094] At step 610, the method 600 includes the step of scheduling a task with a specified time interval. The task is scheduled for handling the child alarms post identification of the parent alarms.
[0095] At step 615, the method 600 includes the step of correlating common attributes between the parent alarms and the child alarms.
[0096] At step 620, the method 600 includes the step of generating a trouble ticket with identities of the parent alarms and identities of the child alarms associated with one or more of the parent alarms.
[0097] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 205. The processor 205 is configured to classify a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network. The processor 205 is further configured to schedule a task with a specified time interval for handling the child alarms post identification of the parent alarms. The processor 205 is further configured to correlate common attributes between the parent alarms and the child alarms. The processor 205 is further configured to generate a trouble ticket with identities of the parent alarms and identities of the child alarms associated with one or more of the parent alarms.
[0098] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS.1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0099] The above described techniques (of handling alarms) of the present disclosure provide multiple advantages, including supporting various types of protocols for handling alarms. The proposed method saves time and efforts required for management of alarms by reducing overall number of trouble tickets to be resolved through enablement of correlation of alarms. Present invention also offers human readable form of attributes. Further, the Invention describes correlating multiple alarms based on parent child relationship and POI (point of interaction) relationship, and allocates a single TT (trouble ticket) for the issue. The proposed invention also facilitates handling of intra / inter / cross domain relationships between alarms.
[00100] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.
[00101] Server: A server may include or comprise, by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise, a defence facility, or any other facility that provides content.
[00102] Network: A network may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[00103] UE/ Wireless Device: A wireless device or a user equipment (UE) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UEs may communicate with the system via set of executable instructions residing on any operating system. In an embodiment, the UEs may include, but are not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs may not be restricted to the mentioned devices and various other devices may be used.
[00104] System (for example, computing system): A system may include one or more processors coupled with a memory, wherein the memory may store instructions which when executed by the one or more processors may cause the system to perform offloading/onloading of broadcasting or multicasting content in networks. An exemplary representation of the system for such purpose, in accordance with embodiments of the present disclosure. In an embodiment, the system may include one or more processor(s). The one or more processor(s) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) may be configured to fetch and execute computer-readable instructions stored in a memory of the system. The memory may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and a database. The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s). In such examples, the system may include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine(s) may be implemented by electronic circuitry. In an aspect, the database may comprise data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor or the processing engines.
[00105] Computer System: A computer system may include an external storage device, a bus, a main memory, a read-only memory, a mass storage device, communication port(s), and a processor. A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The communication port(s) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects. The main memory may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory may be any static storage device(s) including, but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor. The mass storage device may be any current or future mass storage solution, which may be used to store information and/or instructions. The bus communicatively couples the processor with the other memory, storage, and communication blocks. The bus can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), universal serial bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor to the computer system. Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to the bus to support direct operator interaction with the computer system. Other operator and administrative interfaces may be provided through network connections connected through the communication port(s). In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
REFERENCE NUMERALS
[00106] Node – 102;
[00107] Server – 105;
[00108] Communication network - 110;
[00109] System - 125;
[00110] One or more processors -205;
[00111] Memory – 210;
[00112] Input/output interface unit – 215;
[00113] Database – 220;
[00114] Distributed cache – 225;
[00115] Correlation engine – 228;
[00116] Trouble Ticket (TT) processor – 230;
[00117] Enrichment engine – 235;
[00118] Primary processor of first node - 305;
[00119] Memory unit of first node – 310;
[00120] Kernel of the first node – 315;
[00121] Collector component – 405;
[00122] Alarm stream – 408;
[00123] FM master – 410;
[00124] Raise FM module – 415;
[00125] Clear FM module – 420; and
[00126] Retry FM module – 425.
,CLAIMS:We Claim:
1. A method of handling alarms in a network, the method comprising the steps of:
classifying, by a correlation engine (228), a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network;
scheduling, by the correlation engine (228), a task with a specified time interval for handling the child alarms post identification of the parent alarms;
correlating, by the correlation engine (228), common attributes between the parent alarms and the child alarms; and
generating, by a trouble ticket processor (230), a trouble ticket with identities of the parent alarms and identities of the child alarms associated with one or more of the parent alarms.
2. The method as claimed in claim 1, comprising enriching, by an enrichment engine (235), the plurality of alarms prior to classification by the correlation engine (228).
3. The method as claimed in claim 1, comprising classifying, by the correlation engine (228), the plurality of alarms as the child alarms when corresponding parent alarms are not identified within the specified time interval.
4. The method as claimed in claim 1, comprising modifying, by the correlation engine (228), existing alarms stored in a database (220) with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms.
5. The method as claimed in claim 1, comprising classifying, by the correlation engine (228), the plurality of alarms as the child alarms when corresponding parent alarms are already present within the specified time interval.
6. The method as claimed in claim 1, comprising grouping, by the correlation engine (228), the plurality of alarms based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms.
7. The method as claimed in claim 1, comprising promoting, by the correlation engine (228), the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated.
8. The method as claimed in claim 4, comprising, identifying one of a type of correlation applied, relationship status, and newly populated information corresponding to the modifications made for creating the identification.
9. The method as claimed in claim 1, comprising identifying, by the correlation engine (228), association between the parent alarms and the child alarms based on a point of interaction (POI) relationship.
10. The method as claimed in claim 1, comprising identifying, by the correlation engine (228), association between the parent alarms and the child alarms based on intra, inter, cross domain relationships between the plurality of alarms.
11. A system (125) for handling alarms in a network, the system (125) comprising:
a correlation engine (228) configured to classify a plurality of alarms into parent alarms or child alarms associated with one or more of the parent alarms, based on a policy configured for the network, wherein the correlation engine (228) schedules a task with a specified time interval for handling the child alarms upon identifying the parent alarms, and wherein the correlation engine (228) correlates common attributes between the parent alarms and the child alarms; and
a trouble ticket processor (230) configured to generate a trouble ticket with identities of the parent alarms and the identities of the child alarms associated with one or more of the parent alarms.
12. The system as claimed in claim 11, comprises an enrichment engine (235) for enriching the plurality of alarms prior classification by the correlation engine (228).
13. The system as claimed in claim 11, wherein the correlation engine (228) modifies existing alarms stored in a database (220) with the attributes for associating the existing alarms as the child alarms with one or more of the parent alarms.
14. The system as claimed in claim 11, wherein the correlation engine (228) classifies the plurality of alarms as the child alarms when corresponding parent alarms are not identified in the specified time interval.
15. The system as claimed in claim 11, wherein the correlation engine (228) groups the plurality of alarms based on the common attributes when the plurality of alarms is not classified as the parent alarms and the child alarms.
16. The system as claimed in claim 11, wherein the correlation engine (228) groups the plurality of alarms as the child alarms when corresponding parent alarms are already present within the specified time interval.
17. The system as claimed in claim 11, wherein the correlation engine (228) promotes the child alarms in the order of preference of their respective trigger times when the parent alarms are terminated.
18. The system as claimed in claim 13, wherein the identification is created based on one of a type of correlation applied, relationship status, and newly populated information corresponding to the modifications made.
19. The system as claimed in claim 11, wherein the correlation engine (228) identifies association between the parent alarms and the child alarms based on a point of interaction (POI) relationship.
20. The system as claimed in claim 11, wherein the correlation engine (228) identifies association between the parent alarms and the child alarms based on intra, inter, cross domain relationships between the plurality of alarms.
| # | Name | Date |
|---|---|---|
| 1 | 202321046100-STATEMENT OF UNDERTAKING (FORM 3) [09-07-2023(online)].pdf | 2023-07-09 |
| 2 | 202321046100-PROVISIONAL SPECIFICATION [09-07-2023(online)].pdf | 2023-07-09 |
| 3 | 202321046100-FORM 1 [09-07-2023(online)].pdf | 2023-07-09 |
| 4 | 202321046100-FIGURE OF ABSTRACT [09-07-2023(online)].pdf | 2023-07-09 |
| 5 | 202321046100-DRAWINGS [09-07-2023(online)].pdf | 2023-07-09 |
| 6 | 202321046100-DECLARATION OF INVENTORSHIP (FORM 5) [09-07-2023(online)].pdf | 2023-07-09 |
| 7 | 202321046100-FORM-26 [20-09-2023(online)].pdf | 2023-09-20 |
| 8 | 202321046100-Proof of Right [22-12-2023(online)].pdf | 2023-12-22 |
| 9 | 202321046100-DRAWING [27-06-2024(online)].pdf | 2024-06-27 |
| 10 | 202321046100-COMPLETE SPECIFICATION [27-06-2024(online)].pdf | 2024-06-27 |
| 11 | Abstract1.jpg | 2024-09-19 |
| 12 | 202321046100-Power of Attorney [11-11-2024(online)].pdf | 2024-11-11 |
| 13 | 202321046100-Form 1 (Submitted on date of filing) [11-11-2024(online)].pdf | 2024-11-11 |
| 14 | 202321046100-Covering Letter [11-11-2024(online)].pdf | 2024-11-11 |
| 15 | 202321046100-CERTIFIED COPIES TRANSMISSION TO IB [11-11-2024(online)].pdf | 2024-11-11 |
| 16 | 202321046100-FORM 3 [27-11-2024(online)].pdf | 2024-11-27 |
| 17 | 202321046100-FORM 18 [20-03-2025(online)].pdf | 2025-03-20 |