Method and system for generating conditional alarm in a network

Abstract

The present disclosure provides a method (500) and system (108) for generating a conditional alarm in a network (106). A network function (NF) receives a plurality of requests from at least one network entity and monitors them to detect faults. Upon detecting a fault, the system (108) checks whether the number of requests exceeds a first preconfigured value. If the first preconfigured value is met or exceeded, it calculates the error percentage and compares it with a second preconfigured threshold. Based on the comparison, the conditional alarm is either raised or discarded. The conditional alarm is mapped to a severity level, critical, major, or minor, based on a predefined error range. The conditional alarm is then communicated to a NMS (306) for display to network operators. The system minimizes false alarms in low-traffic scenarios and ensures accurate fault reporting for efficient network management.

Description

METHOD AND SYSTEM FOR GENERATING CONDITIONAL ALARM IN A NETWORKRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of telecommunications. More particularly, the present disclosure relates to a method and a system for generating a conditional alarm in a network.DEFINITION

[0003] The term ‘Network Function (NF)’ as used herein in the specification refers to an entity within a telecommunication network that performs specific network operations, such as, but not limited to, handling call flows, managing network resources, and maintaining communication protocols. Examples of network functions include, but are not limited to, a Policy Control Function (PCF), a Session Management Function (SMF), and a Charging Function (CHF).

[0004] The term ‘FCAPS’ as used herein in the specification refers to a Fault, Configuration, Accounting, Performance, and Security management. The FCAPS is a microservice used in network management that provides a comprehensive approach for managing and monitoring the health, configuration, usage, performance, and security of various network resources and network functions.

[0005] The term ‘Conditional alarm’ as used herein in the specification refers to an alarm that is triggered only when specific conditions are met. For example, the conditional alarm is raised when both, for e.g., a total number of requests and an event percentage, exceed their respective predefined thresholds. The conditional alarm may be categorized by severity, such as critical, major, or minor, based on the impact of the condition on the network.

[0006] The term ‘Error percentage’ as used herein in the specification refers to a ratio of a number of errors detected by the network function to a total number of requests processed, expressed as a percentage.

[0007] The term ‘Severity level’ as used herein in the specification refers to a classification of the conditional alarm based on the criticality of the condition that triggered the alarm. Severity levels may include critical, major, and minor, each indicating the urgency and potential impact of the issue on the network.

[0008] The term ‘NMS’ as used herein in the specification refers to a Network Management System, which is a software platform or a set of tools used for managing, monitoring, and controlling network resources within the telecommunication network. The NMS provides functionalities such as fault detection, performance monitoring, configuration management, and security management, helping network administrators to maintain the health and efficiency of the network.

[0009] These definitions are in addition to those expressed in the art.BACKGROUND

[0010] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhancethe understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0011] In modern telecommunication networks, ensuring reliable and efficient network operations is critical. Network functions continuously monitor various network system parameters to detect potential issues that may impact the network performance and stability. A key aspect of this monitoring is the generation of conditional alarms, which alert network operators about abnormal conditions that require immediate attention.

[0012] The conditional alarms are a specific type of alarm that is triggered when certain predefined conditions or thresholds are met within the network function. The conditional alarms are essential for identifying and addressing issues like memory overload, congestion, high error rates, and other potential system failures. Typically, the conditional alarms are categorized by severity levels, such as critical, major, and minor, depending on the extent of deviation from normal operation and the potential impact on the network. A critical alarm represents a serious failure within the network function that requires urgent corrective action. A major alarm indicates a moderatelevel fault that should be addressed to prevent potential degradation of service. Meanwhile, a minor alarm often signals less significant issues, such as the successful initialization of network modules or other low-impact events.

[0013] The network functions maintain error counters for a variety of failure scenarios, and conditional alarms are raised based on these counter values and predefined thresholds. These predefined thresholds are generally calculated as a percentage of the total number of requests handled within a specific time window. If the error percentage surpasses the configured threshold, the system triggers the corresponding alarm based on its severity classification.

[0014] However, a key challenge in existing implementations lies in the reliance on these static, predefined percentage-based thresholds. When the number of total requests is low, even a few errors can lead to a disproportionately high error percentage. For example, if only 10 requests are processed and 2 result in errors, the calculated error rate is 20%, potentially exceeding the threshold for a critical alarm. This occurs despite the absolute number of errors being low, which may not genuinely reflect a critical issue. As a result, misleading alarms may be raised, overstating the severity of the system’s condition and potentially leading to unnecessary operational responses.

[0015] Additionally, the existing systems often fail to consider the context in which these alarms are triggered, such as the total volume of requests or the type of errors occurring. This may result in alarms that either overstate or understate the severity of the situation.

[0016] There is, therefore, a need in the art to provide a method and a system that can mitigate the disadvantages of the prior art.SUMMARY OF THE DISCLOSURE

[0017] In an exemplary embodiment, a method for generating a conditional alarm in a network is described. The method includes receiving, by a receiving module, a plurality of requests from at least one network entity. The method includes detecting, by a threshold monitoring module, at least one fault within the network by monitoring the plurality of received requests. The method further includes determining, by the threshold monitoring module, whether a number of the plurality of received requests exceeds a first preconfigured value upon detecting the at least one fault. The method includes calculating, by the threshold monitoring module, an error percentage based on the number of the plurality of received requests and one or more failed requests upon determining that the number of the plurality of received requests exceeds the firstpreconfigured value. The method includes comparing, by the threshold monitoring module, the calculated error percentage with a second preconfigured value. The method includes performing, by an alarm generation module, a control action on the conditional alarm based on the comparison.

[0018] In some embodiments, the method further includes determining, by the threshold monitoring module, a total number of requests received in a predefined time period among the plurality of received requests. The method further includes identifying, by the threshold monitoring module, a set of requests that failed among the total number of requests. The method further includes classifying, by the threshold monitoring module, the set of requests as the one or more failed requests.

[0019] In some embodiments, calculating the error percentage includes calculating, by the threshold monitoring module, the error percentage based on the number of the plurality of received requests and the one or more failed requests using an error percentage calculation technique.

[0020] In some embodiments, the control action includes one of a raising action to raise the conditional alarm and a discarding action to discard the conditional alarm.

[0021] In some embodiments, upon determining that the calculated error percentage exceeds the second preconfigured value, the method further includes performing, by the alarm generation module, the raising action on the conditional alarm to raise the conditional alarm.

[0022] In some embodiments, performing the raising action includes mapping, by the alarm generation module, the calculated error percentage with a preconfigured error range to identify a severity level for the conditional alarm, wherein the severity level comprises one of a critical severity level, a major severity level, and a minor severity level. The method further includes identifying, by the alarm generation module, an alarm type of the conditional alarm to be raised based on the identifiedseverity level, wherein the alarm type comprises one of a critical alarm, a major alarm and a minor alarm. The method further includes performing, by the alarm generation module, the raising action on the conditional alarm to raise the conditional alarm based on the identified alarm type.

[0023] In some embodiments, upon determining that the calculated error percentage does not exceed the second preconfigured value, the method further includes performing, by the alarm generation module, the discarding action to discard the conditional alarm.

[0024] In some embodiments, the method further includes establishing, by the receiving module, a connection with a network management system (NMS), wherein the NMS is configured to display the generated conditional alarm on a user interface (UI) to alert a user.

[0025] In some embodiments, the method further includes storing, by the threshold monitoring module, information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels in a database.

[0026] In another exemplary embodiment, a system for generating a conditional alarm in a network is described. The system includes a receiving module configured to receive a plurality of requests from at least one network entity. The system includes a threshold monitoring module configured to detect at least one fault within the network by monitoring the plurality of received requests. Upon detection of the at least one fault, the threshold monitoring module is configured to determine whether a number of the plurality of received requests exceeds a first preconfigured value. Upon determining that the number of the plurality of received requests exceeds the first preconfigured value, the threshold monitoring module is configured tocalculate an error percentage based on the number of the plurality of received requests and one or more failed requests and compare the calculated error percentage with a second preconfigured value. The system includes an alarm generation module configured to perform a control action on the conditional alarm based on the comparison.

[0027] In an exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform a method for generating a conditional alarm in a network. The method includes receiving, by a receiving module, a plurality of requests from at least one network entity. The method includes detecting, by a threshold monitoring module, at least one fault within the network by monitoring the plurality of received requests. Upon detecting the at least one fault, the method includes determining, by the threshold monitoring module, whether a number of the plurality of received requests exceeds a first preconfigured value. Upon determining that the number of the plurality of received requests exceeds the first preconfigured value, the method includes calculating, by the threshold monitoring module, an error percentage based on the number of the plurality of received requests and one or more failed requests. The method further includes comparing, by the threshold monitoring module, the calculated error percentage with a second preconfigured value. The method further includes performing, by an alarm generation module, a control action on the conditional alarm based on the comparison.

[0028] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure, and are not restrictive.OBJECTIVES OF THE PRESENT DISCLOSURE

[0029] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0030] An objective of the present disclosure is to provide a method and a system for generating a conditional alarm in a network.

[0031] Another objective of the present disclosure is to provide a method for generating the conditional alarm based on both a total number of requests, and an error percentage calculation, ensuring that the conditional alarm is only raised when truly necessary.

[0032] Another objective of the present disclosure is to enable a network function to differentiate between varying levels of alarm severity (e.g., a critical, a major, and a minor) based on a degree of error percentage breaches, allowing for effective network management.

[0033] Another objective of the present disclosure is to minimize the occurrence of false alarms and missed alarms by using dynamic thresholds and contextual evaluation of network parameters.

[0034] Another objective of the present disclosure is to implement a configurable minimum threshold for total request volume, which acts as a filter to prevent misleading alarm generation when system activity is low.

[0035] Another objective of the present disclosure is to enhance operational efficiency by ensuring that alarms are triggered based not only on the occurrence of errors but also on their proportional significance relative to the overall request load.

[0036] Another objective of the present disclosure is to provide a scalable and adaptive alarm evaluation mechanism that remains effective across varying networkloads and dynamic traffic conditions, thereby improving the reliability and responsiveness of network function monitoring systems.

[0037] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

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

[0039] FIG. 1 illustrates an exemplary network architecture in which or with a system configured for generating a conditional alarm in a network may be implemented, in accordance with embodiments of the present disclosure.

[0040] FIG. 2 illustrates an exemplary block diagram of the system configured for generating the conditional alarm in the network, in accordance with embodiments of the present disclosure.

[0041] FIG. 3 illustrates an exemplary system architecture for generating the conditional alarm in the network, in accordance with an embodiment of the present disclosure.

[0042] FIG. 4 illustrates an exemplary process flow diagram for generating the conditional alarm in the network, in accordance with an embodiment of the present disclosure.

[0043] FIG. 5 illustrates an exemplary flow diagram of a method for generating the conditional alarm in the network, in accordance with an embodiment of the present disclosure.

[0044] FIG. 6 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.

[0045] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture102 - User(s)104 - User Equipments (UEs)106 - Network108 - System200 -Block Diagram202 - Processor(s)204 - Memory206 - Interface(s)208 - FCAPS (Fault, Configuration, Accounting, Performance, and Security management) Module210 - Database212 - Receiving Module214 - Threshold monitoring module216 - Alarm generation module300 - System architecture302 - Network function304 - FCAPS (Fault, Configuration, Accounting, Performance, and Security management)306 - Network Management System (NMS)400 - Process Flow Diagram500 - Method Flow Diagram600 - Computer System610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port(S)670 - ProcessorDETAILED DESCRIPTION

[0046] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0047] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0048] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes,algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0049] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0050] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0051] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore,the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0052] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0053] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0054] In modern telecommunications networks, ensuring the seamless and efficient operation of a network function is crucial. One of the critical aspects of network management involves detecting and responding to abnormal conditions that may compromise network performance. To achieve this, conditional alarms are employed at the network function level, designed to identify unusual conditions of network system such as memory overload, congestion risks, and other potential faults. These alarms are typically categorized into different severity levels (e.g., critical, major, and minor), each indicating varying degrees of the network system issues.

[0055] The critical alarms signal a severe failure within the network function that requires immediate attention to prevent significant service disruption. The major alarms, on the other hand, indicate moderate faults that need to be addressed but may not require the same level of urgency as critical alarms. Additionally, the minor alarms typically denote successful initialization of network modules or minor issues that do not pose a significant threat to the network stability.

[0056] The network function maintains counters for various error scenarios, and these counters are essential in determining when and what type of the conditional alarm is to be raised. The conditional alarm is triggered based on pre-configured threshold values, which are calculated as a percentage of the total number of requests processed by the network function. However, this mechanism, while effective in many cases, encounters a significant challenge when the total number of requests is very low. In such instances, even a small number of errors can disproportionately inflate the calculated error percentage, potentially leading to the generation of higher severity alarms than warranted by the actual number of errors.

[0057] This severity may cause unnecessary alarm fatigue among operations teams, as it does not accurately reflect the true state of the network. Conventional alarm systems, which rely on static thresholds or absolute error counts, may not be equippedto handle this problem, often resulting in misleading severity levels that may divert attention from genuinely critical issues.

[0058] The present disclosure addresses this problem through an efficient approach that combines dynamic thresholds with a contextual evaluation of total request volumes. By incorporating a configurable minimum threshold (e.g., a first preconfigured threshold) for the total number of requests, the system effectively filters out scenarios where low request volumes may artificially increase error percentages. This adaptive method ensures that the conditional alarm is generated only when it truly reflects a significant issue within the network, thereby enhancing the precision and relevance of the alarm notifications.

[0059] Moreover, the present disclosure is responsible for differentiating between the critical, major, and minor severity levels based on the extent of error percentage breaches (which may be determined by comparing the calculated error percentage with a second preconfigured threshold). This allows for more targeted responses, enabling operations teams to prioritize their actions based on the actual impact of the errors relative to the overall network activity. In complex network environments where operational efficiency is dominant, the approach for the alarm management offers a significant advantage by reducing false alarms and improving the overall reliability of the network function.

[0060] Therefore, the present disclosure provides a substantial improvement over the conventional alarm systems by introducing a dynamic, context-aware method for generating conditional alarms. By considering both the relative impact of errors and the total request volume, the system provides more accurate notifications, ultimately contributing to more effective and proactive management of the network function.

[0061] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0062] FIG. 1 illustrates an exemplary network architecture 100 in which or with which a system 108 configured for generating a conditional alarm in a network 106 may be implemented, in accordance with embodiments of the present disclosure.

[0063] As illustrated in FIG. 1 , the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2... 104-N associated with one or more users 102-1, 102-2... 102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2... 102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2... 104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.

[0064] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users 102 and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multisensing, network- connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud- computing system or any other device that is network-connected.

[0065] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, asmartphone, a phablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.

[0066] In FIG. 1 , the UE 104 may communicate with the system 108 through the network 106 for sending or receiving various types of data. In an example, the UE 104 may send a plurality of requests, which are handled by a network function (NF) that is included in the system 108, such as a Binding Support Function (BSF). Upon receiving the plurality of request, the system 108 may calculate a percentage of errors relative to a total number of requests. Before making any comparisons, the system 108 may check if the total number of received requests exceeds a configured minimum threshold value that can be ignored. If the total number of requests meets or exceeds the configured threshold, the system 108 proceeds to compare the calculated error percentage against the configured threshold value. Based on the comparison, if the error percentage exceeds the threshold, the system 108 raises a conditional alarm witha severity corresponding to the level of error percentage breach (Critical, Major, Minor).

[0067] If the error percentage does not exceed the threshold, no conditional alarm is generated, mitigating unnecessary alerts when the error percentage is inflated due to a small absolute number of errors relative to a very low total request count. The detailed explanation and flow for generating the conditional alarm in the network 106 are described further with reference to FIG. 2 to FIG. 5.

[0068] In an embodiment, the network 106 may include at least one of a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and / or with the system 108. The network 106 may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network 106 may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0069] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, 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.

[0070] In an embodiment, the UE 104 is communicatively coupled with the network 106. The network 106 may receive a connection request from the UE 104. The network 106 may send an acknowledgment of the connection request to the UE 104. The UE 104 may transmit a plurality of signals in response to the connection request.

[0071] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.

[0072] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for generating the conditional alarm in the network 106, in accordance with embodiments of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1.

[0073] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random- Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.

[0074] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, a Fault Configuration Accounting Performance and Security (FCAPS) module 208 and a database 210.

[0075] In an embodiment, the system 108 is configured to generate the conditional alarm in the network 106. The conditional alarm is a system-generated notification that is triggered based on the evaluation of one or more predefined operational thresholds within a network function. The conditional alarm is not raised for every fault or failure but is conditionally triggered when specific criteria, such as error rates, exceed configured threshold values. The conditional alarm serves to alert network operators or network systems about abnormal or undesirable operating conditions that may require corrective action. The conditional alarm may be categorized into multiple severity levels, including but not limited to critical, major, and minor, depending on the magnitude of deviation from normal behavior or the potential impact on network performance. For instance, a critical alarm may indicate a significant or urgent failure that demands immediate intervention, a major alarm indicates a moderate kind of fault, whereas a minor alarm may signal a less severe or informational condition.

[0076] In an embodiment, the system 108 may include a network function (NF) such as a Binding Network Function (BSF). The network function (NF) may be connected to the FCAPS module 208. The FCAPS module 208 is a microservice used in network management that provides a comprehensive approach for managing and monitoring the health, configuration, usage, performance, and security of variousnetwork resources. The FCAPS module 208 may include a receiving module 212, a threshold monitoring module 214, and an alarm generation module 216.

[0077] In an embodiment, the receiving module 212 may be configured to receive a plurality of requests from at least one network entity. In an example, the at least one network entity may be the UE 104, other network functions such as Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), or any microservice that interacts with the system 108 by exchanging messages or triggering actions and external systems or applications such as monitoring systems, network orchestration platforms etc.

[0078] In an aspect, the plurality of requests may include, but are not limited to, a session initiation request, a session update request, session terminate request, a call setup request, handovers, authentication requests, or other service-related requests, initiated by the at least one network entity (for e.g. the UE 104).

[0079] In an embodiment, the plurality of requests may be transmitted over standard network interfaces and protocols such as Hypertext Transfer Protocol (HTTP), Diameter, proprietary signaling interfaces etc. The receiving module 212 may be equipped with interfaces and logic to capture, decode, and process the plurality of incoming requests. Additionally, the receiving module 212 may listen on specific communication ports available on the network function, monitor predefined network interfaces and other components within the system 108 to receive the plurality of requests.

[0080] In an embodiment, the threshold monitoring module 214 is configured to detect at least one fault within the network 106 by monitoring the plurality of requests. The at least one fault may refer to any abnormal or undesired condition in the network 106 that could affect its performance, reliability, or availability. The at least one fault may include, but is not limited to, unusual spikes, packet drops, sessionfailures, request timeouts, congestion events, authentication errors, resource allocation failures, or excessive retransmissions. The threshold monitoring module 214 may detect the at least fault by continuously tracking various performance counters, error logs, and status indicators associated with the processing of the plurality of requests. In an example embodiment, the threshold monitoring module 214 may be configured to monitor the plurality of requests received from the at least one network entity. The threshold monitoring module 214 continuously tracks a volume of the plurality of received requests. This monitoring is essential for understanding a real-time operational load on the network 106 and for detecting any unusual spikes or drops in activity that may indicate potential issues.

[0081] In an embodiment, the threshold monitoring module 214 is configured to determine whether the number of the plurality of received requests exceeds a first preconfigured value. The first preconfigured value serves as a baseline to assess whether the volume of network activity is significant enough to justify further analysis for fault detection. The first preconfigured value may be set corresponding to the permissible limit of the network function to receive the number of the plurality of requests from the at least one network entity. The first preconfigured value may be set by network operators or administrators based on historical traffic patterns, service level agreements (SLAs), or operational requirements. In an example, the first preconfigured value may be set as 12 requests within a predefined time window, such as one minute. This means that if the threshold monitoring module 214 detects that fewer than 12 requests have been received during that interval, it will consider the traffic volume too low for meaningful fault analysis and will not proceed with error percentage calculation. However, if the number of the plurality of received requests exceeds or equals the first preconfigured value, i.e., 12 requests, the threshold monitoring module 214 considers the traffic volume sufficient and continues with further evaluation. This approach helps prevent misleading alarms that might occur due to inflated error ratios in low-traffic scenarios.

[0082] In an embodiment, upon determining that the number of the plurality of received requests exceeds the first preconfigured value, the threshold monitoring module 214 is configured to calculate an error percentage based on the number of the plurality of received requests and one or more failed requests using an error percentage calculation technique. If the number of the plurality of requests exceeds the first preconfigured value, it signifies that the network function is experiencing an unusually high level of activity. This may be indicative of various scenarios such as a surge in user demand, a network outage causing re-registration requests, or even a potential security issue like a denial-of-service attack. In an example, if the first preconfigured value is set at 12 requests per monitoring cycle, the threshold monitoring module 214 will begin calculating the error percentage or fault patterns only after receiving more than 12 requests.

[0083] In an aspect, the threshold monitoring module 214 is configured to determine a total number of requests received in a predefined time period among the plurality of received requests. In other words, the threshold monitoring module 214 keeps track of the plurality of requests received within a specific time window (such as the last 5 minutes or 1 hour). Additionally, the threshold monitoring module 214 is configured to identify a set of requests that failed among the total number of requests. The threshold monitoring module 214 may identify the set of requests that failed by analyzing response codes, error flags, or failure indicators associated with each received request. Each request may generate a status response upon completion such as success, timeout, rejection, or failure. The threshold monitoring module 214 may scan these responses and extract the ones marked with predefined failure conditions (e.g., HTTP errors, session rejection codes, or timeout flags). By applying logical rules or pattern matching to these response attributes, the threshold monitoring module 214 filters out the set of requests that failed from the total number of requests. Further, the threshold monitoring module 214 is configured to classify the set of requests as the one or more failed requests. In an example, if 12 requests are received within a 5-minuteinterval and 7 of those requests fail due to session timeout errors, the threshold monitoring module 214 identifies those 7 as the one or more failed requests.

[0084] In an aspect, the calculation of the error percentage is crucial for evaluating the overall health of the network function when the number of the plurality of requests exceeds the first preconfigured value. This calculation may help to determine the extent of abnormal conditions within a network system, such as network failures, misconfigurations, or overloads. In an example, the network system may refer to a comprehensive framework of interconnected hardware and software components designed to facilitate seamless communication, efficient data transmission, and consistent service delivery across the network 106. The network function may comprise essential elements such as routers, switches, servers, network functions and communication protocols that coordinate to handle user requests, manage sessions, enforce policies, and ensure optimal network performance. These components operate in unison to maintain stability, scalability, and reliability within the network infrastructure. Any malfunction, disruption, or degradation within the network system can adversely impact its operations, potentially resulting in service delays, reduced performance, or complete outages, which in turn may affect end-user experience and critical network services.

[0085] In order to calculate the error percentage, the threshold monitoring module 214 is configured to calculate the error percentage based on the number of the plurality of received requests and the one or more failed requests using the error percentage calculation technique. In an aspect, the error percentage calculation technique uses a formula that divides the number of the one or more failed requests by the total number of the plurality of received requests and then multiplies the result by 100 to express it as a percentage. For example, if a total number of 15 requests is received and the threshold monitoring module 214 identifies that 3 of those requestshave failed due to issues like rejection or timeout, the error percentage is calculated as: (3 - 15) x 100 = 20%.

[0086] In an embodiment, the threshold monitoring module 214 is configured to compare the calculated error percentage with a second preconfigured value. In an aspect, the second preconfigured value represents the acceptable error rate for the network function. If the error percentage exceeds the second preconfigured threshold, it indicates that the network system is experiencing a higher-than-expected level of errors, which may compromise its performance and reliability, leading the alarm generation module 216 to generate the conditional alarm.

[0087] In an embodiment, the alarm generation module 216 is configured to perform a control action on the conditional alarm based on the comparison. The control action may include one of a raising action to raise the conditional alarm and a discarding action to discard the conditional alarm. The raising action means generating and sending out the generated conditional alarm to indicate that a fault has occurred. The discarding action means not generating the conditional alarm, effectively ignoring the fault as it is not severe enough based on the second preconfigured value.

[0088] In an aspect, upon determining that the calculated error percentage exceeds the second preconfigured value, the alarm generation module 216 is configured to perform the raising action on the conditional alarm to raise the conditional alarm. In an example, if the threshold monitoring module 214 calculates the error percentage of 20%, and the second preconfigured value (threshold) is set at 15%, the alarm generation module 216 identifies that the error percentage has exceeded the allowed limit. As a result, it performs the raising action to trigger the conditional alarm, indicating that the fault severity has crossed the acceptable threshold and needs attention.1

[0089] In order to perform the raising action, the alarm generation module 216 is further configured to map the calculated error percentage with a preconfigured error range to identify a severity level for the conditional alarm. The severity level includes one of a critical severity level, a major severity level, and a minor severity level. The preconfigured error range may be a defined percentage interval that is set in advance to classify the severity of errors in the network system.

[0090] Additionally, the alarm generation module 216 is configured to identify an alarm type of the conditional alarm to be raised based on the identified severity level. The alarm type includes one of a critical alarm, a major alarm and a minor alarm. For example, if the alarm generation module 216 identifies the severity level as the critical severity level, then it identifies the alarm type as the critical alarm type, whereas if the identified severity level is the major severity level, the alarm type is determined as the major alarm type. Similarly, if the severity level is identified as the minor severity level, the alarm type is set as the minor alarm type. In an aspect, once the alarm type is identified, the alarm generation module 216 is configured to perform the raising action on the conditional alarm to raise the conditional alarm based on the identified alarm type.

[0091] By way of an example, consider a scenario where the network function handles 1,000 requests within the network 106 and the preconfigured error range is set as 80% for critical severity level, 40% to 80% for major severity level and below 40 % for minor severity level. Out of these 1,000 requests, 850 failed due to a critical error in the network system, resulting in an error percentage of 85%. Since this error percentage exceeds the 80% preconfigured error range, the alarm generation module 216 may raise the critical alarm. This alarm may immediately alert the user (i.e., network operators) that a severe problem is affecting the network system. The network system may be an integrated set of hardware and software components responsible for enabling communication, data transmission, and service delivery across the network106. A failure within the network system may disrupt these operations, leading to degraded service or outages. The critical alarm may likely prompt emergency measures, such as reallocating resources, restarting critical components, or even temporarily shutting down parts of the network system to prevent a complete failure. Now, consider another situation where 600 out of the 1,000 requests fail, leading to a 60% error percentage. This percentage falls within the 40% to 80% range, triggering a major alarm. While this situation is less severe than the previous one, it still indicates a significant issue within the network 106. The major alarm may likely lead to a thorough investigation by the operations team. The network operators or operation team may focus on identifying specific subsystems or modules causing the errors, adjusting configurations of the network system, or increasing resource allocations to handle the load more effectively. Although immediate action is required, the situation is not as urgent as with a critical alarm. Further, consider another scenario where only 300 out of the 1,000 requests fail, resulting in a 30% error percentage. This percentage is below the 40% threshold, so the alarm generation module 216 may raise the minor alarm. The minor alarm suggests that while there are some issues, they are not severe enough to impact the overall network system. It may indicate that the network 106 is still in a stable state, but may need monitoring to ensure that the situation does not escalate. Operations teams may use this information to track trends or to perform routine maintenance to prevent minor issues from becoming more serious in the future.

[0092] In an aspect, upon determining that the calculated error percentage does not exceed the second preconfigured value, the alarm generation module 216 is configured to perform the discarding action to discard the conditional alarm. In an example, if the total number of received requests in a predefined time period is 15 and only 1 of them fails, the calculated error percentage would be approximately 6.67%. If the second preconfigured value is set to 10%, this calculated error percentage does not exceed the second preconfigured value. Therefore, the alarm generation module 216 performs the discarding action, and no conditional alarm is raised, since the level oferror is not considered significant enough to warrant attention. This prevents unnecessary alerts and helps maintain operational efficiency by ensuring that only meaningful alarms are generated.

[0093] The error percentage is relevant when the total number of requests is high. In such cases, even a small percentage of errors may represent a significant number of failed requests, supporting a higher severity alarm. Conversely, if the total number of requests is low, the system 108 may ensure that a few errors do not disproportionately raise the conditional alarm.

[0094] Once the conditional alarm is generated, the subsequent operation involves notifying the network operators regarding the abnormal conditions detected in the network function. To facilitate this, the receiving module 212 is configured to establish a connection with a Network Management System (NMS). The NMS is configured to display the generated conditional alarm on a user interface (UI) to a user (also referred to as the network operators). The NMS acts as a central interface through which the generated conditional alarms, configurations, and performance metrics are aggregated and visualized for administrative purposes. Upon generation of the conditional alarm, the receiving module 212 transmits the relevant alarm data to the NMS using standard communication protocols such as Simple Network Management Protocol (SNMP) or RESTful APIs. Once received, the NMS processes this alarm data and displays the generated conditional alarm on the UI accessible to the user (i.e., network operators). The displayed conditional alarm includes details such as the severity level (e.g., critical, major, or minor), timestamp, affected network function, and a brief description of the fault, thereby enabling prompt attention and corrective action by the operational team.

[0095] In an embodiment, the system 108 may include the database 210 that includes a wide range of information essential for managing the generated conditional alarm that may be either stored or generated as a result of functionalities implementedby any of the components of the system 108. In an aspect, the threshold monitoring module 214 is configured to store information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels in the database 210.

[0096] Although FIG. 2 shows exemplary components of the system 108, in other embodiments, the system 108 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system 108 may perform functions described as being performed by one or more other components of the system 108.

[0097] FIG. 3 illustrates an exemplary system architecture 300 for generating the conditional alarm in the network 106, in accordance with an embodiment of the present disclosure. FIG. 3 is described in conjunction with FIGs 1 and 2.

[0098] The system architecture 300 illustrates various network management components, such as a network function 302, a Fault, Configuration, Accounting, Performance, and Security (FCAPS) 304, and a Network Management System (NMS) 306 working in a sequence to ensure that the conditional alarm is accurately generated and managed.

[0099] The network function 302 is responsible for monitoring the total number of the plurality of requests from the at least one network entity (for e.g. the UE 104). The network function 302 continuously tracks network activity and is connected to a database 210. The database 210 stores relevant data, including request counts, error logs, information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels.The database 210 serves as a repository for storing historical data and configurations that the network function 302 accesses to perform its monitoring and evaluation tasks.

[0100] The FCAPS 304 is a crucial component responsible for management and administration tasks within the network 106, including fault detection, performance monitoring, and security management. The FCAPS 304 processes the information received from the network function 302 and determines the appropriate response, such as raising the conditional alarm.

[0101] In an aspect, the FCAPS 304 is responsible for detecting the at least one fault, such as unusual spikes, packet drops, session failures, request timeouts, congestion events, authentication errors, resource allocation failures, or excessive retransmissions in the network 106 by monitoring the plurality of received requests. Upon detecting the at least one fault, the FCAPS 304 determines whether the number of the plurality of received requests exceeds the first preconfigured value.

[0102] In an aspect, upon determining that the number of the plurality of received requests exceeds the first preconfigured value, the FCAPS 304 calculates the error percentage based on the number of the plurality of received requests and one or more failed requests. Additionally, the FCAPS 304 compares the calculated error percentage with the second preconfigured value. The second preconfigured value represents the acceptable error rate for the network function 302. Further, based on the comparison, the FCAPS 304 performs the control action, such as the raising action to raise the conditional alarm and the discarding action to discard the conditional alarm.

[0103] In an aspect, upon determining that the calculated error percentage exceeds the second preconfigured value, the FCAPS 304 performs the raising action on the conditional alarm to raise the conditional alarm.

[0104] In an aspect, upon determining that the calculated error percentage does not exceed the second preconfigured value, the FCAPS 304 performs the discarding action to discard the conditional alarm.

[0105] The NMS 306 receives data from the FCAPS 304 and enables monitoring and interaction using the user interface or a control panel that is accessed by the user (e.g., network operators or administrators). By using the user interface or the control panel, the user can monitor the network’s health and performance. If the conditional alarm is raised, the NMS 306 alerts the user, allowing them to take corrective actions. The NMS 306 also logs the alarm and other relevant data for future analysis and auditing.

[0106] FIG. 4 illustrates an exemplary process flow 400 diagram for generating the conditional alarm in the network 106, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2 and 3.

[0107] At step 402, the method 400 begins with the initiation of the application. In an example, the application may be the system 108. This is the starting point where the system 108 or application begins to execute its operations.

[0108] At step 404, after the application starts, the method 400 proceeds with the initialization of various modules that are essential for the basic functioning of the system 108 when the application starts. Examples of these modules may include, but are not limited to, the receiving module 212, the threshold monitoring module 214, the alarm generation module 216, memory allocation modules, Input / Output (VO) modules, configuration loader, and device drivers. The memory allocation modules manage the allocation and initialization of memory resources needed by the application. Further, the VO modules are responsible for managing input and output operations to ensure that the application can correctly handle data coming into and going out of the system 108, such as communication with hardware components orother software layers. Further, the configuration loader is responsible for loading and applying the necessary configuration settings for the application. These settings may include system parameters, environment variables, or user preferences that need to be applied at startup. Additionally, the device drivers allow the application to communicate effectively with hardware components like network cards, storage devices, or sensors when the application interacts with the hardware devices.

[0109] In an aspect, the receiving module 212 is responsible for receiving the plurality of requests from the at least one network entity. The receiving module 212 acts as the interface between the network function 302 and external network entities, ensuring that all incoming requests are accurately captured and passed on for further analysis.

[0110] At 406, once the modules are initialized, the threshold monitoring module 214 monitors for the at least one fault within the network 106 by monitoring the plurality of received requests. If a fault occurs, the method 400 continues to the next step. If no fault occurs, the process may loop back or remain in a monitoring state.

[0111] At 408, when the fault occurs, the threshold monitoring module 214 checks whether the total number of the received requests is less than the first preconfigured threshold. If the total number of the plurality of received requests is less than the first preconfigured threshold, no alarm is raised, at step 410. This prevents the system 108 from generating the alarm in scenarios where the network activity is too low. In such a scenario, the calculation of error percentage may also be ignored. This step ensures that the conditional alarm is only considered when the request volume is sufficiently significant.

[0112] At step 412, the threshold monitoring module 214 checks whether the total number of the plurality of received requests exceeds the first preconfiguredthreshold. If the total number of requests exceeds the first preconfigured threshold, the method 400 moves to the next step.

[0113] At step 414, upon determining that the total number of the plurality of requests exceeds the first preconfigured threshold, the threshold monitoring module 214 calculates the error percentage based on the number of the plurality of received requests and the one or more failed requests using the error percentage calculation technique. The threshold monitoring module 214 then compares the calculated error percentage against the second preconfigured threshold to determine if an alarm needs to be raised.

[0114] At step 416, if the error percentage exceeds the second preconfigured threshold, the alarm generation module 216 raises one of a critical, major, or minor alarm, depending on the severity of the issue detected. This alarm is communicated to the NMS 306 for further action.

[0115] At step 418, when the modules are successfully initialized, in such condition, if a minor fault or issue occurs, the system 108 may choose to raise a minor alarm directly, at step 420. This allows for handling less severe issues without triggering the critical alarm. For example, if the minor fault occurs, such as a temporary dip in performance, a non-critical configuration error, or a brief network glitch, the system 108 recognizes that while these issues may not immediately threaten the overall stability or performance, they may still require attention to prevent any potential mishappening.

[0116] At step 424, the method 400 checks whether the NMS 306 is connected. If the NMS 306 is connected, the method 400 continues to step 430, otherwise, the method 400 moves to step 422.

[0117] At step 422, if the NMS 306 is disconnected, the method 400 records the event in the database 210 at step 426 and waits for the NMS 306 to reconnect.

[0118] At step 428, once the NMS 306 is reconnected, the method 400 updates the database 210 and resumes normal operation by displaying the status on the NMS 306 dashboard.

[0119] At step 430, the method 400 updates the NMS dashboard with the latest information, including any raised alarms and the status of the network 106. This ensures that network administrators are informed of any issues that need attention.

[0120] FIG. 5 illustrates another exemplary flow diagram of a method 500 for generating the conditional alarm in the network 106, in accordance with an embodiment of the present disclosure. FIG. 5 is explained with reference to FIG. 2.

[0121] At step 502, the method 500 includes receiving, by the receiving module 212, a plurality of requests from at least one network entity, such as the UE 104. The method includes establishing, by the receiving module 212, a connection with a network management system (NMS). The NMS is configured to display the generated conditional alarm on a user interface (UI) to alert a user.

[0122] At step 504, the method 500 includes detecting, by the threshold monitoring module 214, at least one fault within the network 106 by monitoring the plurality of received requests.

[0123] At step 506, the method 500 includes determining, by the threshold monitoring module 214, whether a number of the plurality of received requests exceeds a first preconfigured value upon detecting the at least one fault.

[0124] At step 508, the method 500 includes calculating, by the threshold monitoring module 214, an error percentage based on the number of the plurality of received requests and one or more failed requests upon determining that the number of the plurality of received requests exceeds the first preconfigured value. In order to identify the one or more failed request, the method includes determining, by thethreshold monitoring module 214, a total number of requests received in a predefined time period among the plurality of received requests. The method further includes identifying, by the threshold monitoring module 214, a set of requests that failed among the total number of requests and classifying, by the threshold monitoring module 214, the set of requests as the one or more failed requests. The method includes, calculating, by the threshold monitoring module 214, the error percentage based on the number of the plurality of received requests and the one or more failed requests using an error percentage calculation technique.

[0125] At step 510, the method 500 includes comparing, by the threshold monitoring module 214, the calculated error percentage with a second preconfigured value.

[0126] At step 512, the method 500 includes performing, by the alarm generation module 216, a control action on the conditional alarm based on the comparison. The control action includes one of a raising action to raise the conditional alarm and a discarding action to discard the conditional alarm. In an aspect, the method includes performing, by the alarm generation module 216, the raising action on the conditional alarm to raise the conditional alarm upon determining that the calculated error percentage exceeds the second preconfigured value. The method further includes performing, by the alarm generation module 216, the discarding action to discard the conditional alarm upon determining that the calculated error percentage does not exceed the second preconfigured value. In an aspect, for performing the raising action, the method includes mapping, by the alarm generation module 216, the calculated error percentage with a preconfigured error range to identify a severity level for the conditional alarm. The severity level includes one of a critical severity level, a major severity level, and a minor severity level. The method further includes identifying, by the alarm generation module 216, an alarm type of the conditional alarm to be raised based on the identified severity level. The alarm type includes one of a critical alarm,a major alarm and a minor alarm. The method further includes performing, by the alarm generation module 216, the raising action on the conditional alarm to raise the conditional alarm based on the identified alarm type. In an aspect, the method includes storing, by the threshold monitoring module 214, information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels in a database 210.

[0127] FIG. 6 illustrates an example computer system 600 in which or with which the embodiments of the present disclosure may be implemented.

[0128] As shown in FIG. 6, the computer system 600 may include an external storage device 610, a bus 620, a main memory 630, a read-only memory 640, a mass storage device 650, a communication port(s) 660, and a processor 670. A person skilled in the art will appreciate that the computer system 600 may include more than one processor and communication ports. The processor 670 may include various modules associated with embodiments of the present disclosure. The communication port(s) 660 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 ports(s) 660 may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 600 connects.

[0129] In an embodiment, the main memory 630 may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 640 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input / output system (BIOS) instructions for the processor 670. The mass storage device 650 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage solutionsinclude, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces).

[0130] In an embodiment, the bus 620 may communicatively couple the processor(s) 670 with the other memory, storage, and communication blocks. The bus 620 may be, e.g. a Peripheral Component Interconnect PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 670 to the computer system 600.

[0131] In another embodiment, operator, and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus 620 to support direct operator interaction with the computer system 600. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 660. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 600 limit the scope of the present disclosure.

[0132] In an exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for alarm generation based on dynamic thresholds and contextual evaluation of total request volumes. The Network Function (NF) checks if the total number of requests less than a configured minimum threshold value, error calculation can be ignored. If the total number of requests meets or exceeds the configured threshold, the NF calculates the percentage of errors relative to the total number of requests. The NF further compares the calculated error percentage againstthe configured threshold value. If the error percentage exceeds the threshold, the NF generates severity-based alarm corresponding to the level of error percentage breach (critical, major, minor).

[0133] The present disclosure provides a technical advancement in the field of network fault management and alarm generation within communication systems. By introducing a conditional alarm mechanism based on dynamic error percentage evaluation and request volume thresholds, the system ensures more accurate and context-aware fault detection. The use of a dual-threshold model comprising a minimum request volume threshold and a configurable error percentage threshold prevents the generation of misleading alarms that may arise from low traffic scenarios. This intelligent filtering approach significantly reduces false positives, minimizes unnecessary operator intervention, and enhances the reliability of network monitoring. Additionally, the mapping of error percentages to predefined severity levels (critical, major, or minor) enables precise and prioritized fault reporting. The system’s integration with the Network Management System (NMS) further facilitates real-time visibility and responsive network maintenance. Overall, the disclosure presents a scalable and efficient alarm generation framework that improves the operational robustness of network functions and ensures the timely resolution of genuine network anomalies.

[0134] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0135] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0136] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.ADVANCEMENTS OF THE PRESENT DISCLOSURE

[0137] The present disclosure described herein above has several technical advantages as follows:

[0138] The present disclosure provides a solution for accurately managing alarm generation in scenarios where the volume of incoming requests varies over time. By implementing a threshold check for the total number of requests before evaluating the error percentage, the system effectively filters out situations where a small number of errors may disproportionately increase the error percentage, which may otherwisetrigger a higher severity alarm. This ensures that alarm is not unnecessarily raised for minor issues, thereby maintaining focus on more significant and impactful problems.

[0139] The present disclosure provides an alarm system that generates alarm based on both the total number of requests received and the calculated error percentage. By ensuring that the total request volume exceeds a configured minimum threshold (e.g., the first preconfigured threshold) before the alarm is generated, the system improves the reliability of alarm notifications, aligning them more closely with the actual operational impact on the network.

[0140] The present disclosure helps in reduction of alert fatigue among the network operations teams. The system minimizes the generation of false alarms, particularly in situations where infrequent errors may otherwise skew the error percentage. This allows for a more targeted and efficient response to genuine issues that have a more significant impact on network performance, such as critical failures or moderate faults that could affect overall system stability

[0141] The present disclosure provides an adaptive alarm management system that optimizes the alarm generation process by considering both the relative impact of errors and the total request volume. This dual consideration improves the accuracy, relevance, and efficiency of alarm notifications in complex network environments, ultimately leading to better decision-making and faster resolution of critical network issues.

Claims

We claim:

1. A method (500) for generating a conditional alarm in a network (106), the method (500) comprising: receiving (502), by a receiving module (212), a plurality of requests from at least one network entity; detecting (504), by a threshold monitoring module (214), at least one fault within the network by monitoring the plurality of received requests; upon detecting the at least one fault, determining (506), by the threshold monitoring module (214), whether a number of the plurality of received requests exceeds a first preconfigured value; upon determining that the number of the plurality of received requests exceeds the first preconfigured value, calculating (508), by the threshold monitoring module (214), an error percentage based on the number of the plurality of received requests and one or more failed requests; comparing (510), by the threshold monitoring module (214), the calculated error percentage with a second preconfigured value; and performing (512), by an alarm generation module (216), a control action on the conditional alarm based on the comparison.

2. The method (500) as claimed in claim 1, comprises: determining, by the threshold monitoring module (214), a total number of requests received in a predefined time period among the plurality of received requests; identifying, by the threshold monitoring module (214), a set of requests that failed among the total number of requests; and classifying, by the threshold monitoring module (214), the set of requests as the one or more failed requests.

3. The method (500) as claimed in claim 1, wherein calculating the error percentage comprises: calculating, by the threshold monitoring module (214), the error percentage based on the number of the plurality of received requests and the one or more failed requests using an error percentage calculation technique.

4. The method (500) as claimed in claim 1, wherein the control action comprises one of a raising action to raise the conditional alarm and a discarding action to discard the conditional alarm.

5. The method (500) as claimed in claim 4, wherein upon determining that the calculated error percentage exceeds the second preconfigured value, performing, by the alarm generation module (216), the raising action on the conditional alarm to raise the conditional alarm.

6. The method (500) as claimed in claim 5, wherein performing the raising action comprises: mapping, by the alarm generation module (216), the calculated error percentage with a preconfigured error range to identify a severity level for the conditional alarm, wherein the severity level comprises one of a critical severity level, a major severity level, and a minor severity level; identifying, by the alarm generation module (216), an alarm type of the conditional alarm to be raised based on the identified severity level, wherein the alarm type comprises one of a critical alarm, a major alarm and a minor alarm; and performing, by the alarm generation module (216), the raising action on the conditional alarm to raise the conditional alarm based on the identified alarm type.

7. The method (500) as claimed in claim 4, wherein upon determining that the calculated error percentage does not exceed the second preconfigured value, performing, by the alarm generation module (216), the discarding action to discard the conditional alarm.

8. The method (500) as claimed in claim 1, comprising: establishing, by the receiving module (212), a connection with a network management system (NMS), wherein the NMS is configured to display the generated conditional alarm on a user interface (UI) to alert a user.

9. The method (500) as claimed in claim 1, comprising: storing, by the threshold monitoring module (214), information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels in a database (210).

10. A system (108) for generating a conditional alarm in a network (106), the system comprising: a receiving module (212) configured to receive a plurality of requests from at least one network entity; a threshold monitoring module (214) configured to: detect at least one fault within the network by monitoring the plurality of received requests; upon detection of the at least one fault, determine whether a number of the plurality of received requests exceeds a first preconfigured value; upon determining that the number of the plurality of received requests exceeds the first preconfigured value, calculate an error percentage based on the number of the plurality of received requests and one or more failed requests; andcompare the calculated error percentage with a second preconfigured value; and an alarm generation module (216) configured to: perform a control action on the conditional alarm based on the comparison.

11. The system (108) as claimed in claim 10, wherein the threshold monitoring module (214) configured to: determine a total number of requests received in a predefined time period among the plurality of received requests; identify a set of requests that failed among the total number of requests; and classify the set of requests as the one or more failed requests.

12. The system (108) as claimed in claim 11, wherein the threshold monitoring module (214) configured to: calculate the error percentage based on the number of the plurality of received requests and the one or more failed requests using an error percentage calculation technique.

13. The system (108) as claimed in claim 10, wherein the control action comprises one of a raising action to raise the conditional alarm and a discarding action to discard the conditional alarm.

14. The system (108) as claimed in claim 13, wherein upon determining that the calculated error percentage exceeds the second preconfigured value, the alarm generation module (216) is configured to perform the raising action on the conditional alarm to raise the conditional alarm.

15. The system (108) as claimed in claim 14, wherein to perform the raising action, the alarm generation module (216) is configured to: map the calculated error percentage with a preconfigured error range to identify a severity level for the conditional alarm, wherein the severity level comprises one of a critical severity level, a major severity level, and a minor severity level; identify an alarm type of the conditional alarm to be raised based on the identified severity level, wherein the alarm type comprises one of a critical alarm, a major alarm and a minor alarm; and perform the raising action on the conditional alarm to raise the conditional alarm based on the identified alarm type.

16. The system (108) as claimed in claim 13, wherein upon determining that the calculated error percentage exceeds the second preconfigured value, the alarm generation module (216) is configured to perform the discarding action to discard the conditional alarm.

17. The system (108) as claimed in claim 10, wherein the receiving module (212) is configured to: establish a connection with a network management system (NMS), wherein the NMS is configured to display the generated conditional alarm on a user interface (UI) to alert a user.

18. The system (108) as claimed in claim 10, wherein the threshold monitoring module (214) is configured to: store information related to at least one of the plurality of received requests, the total number of failed requests, the first preconfigured value, the second preconfigured value, and the preconfigured error range associated with each of the severity levels in a database (210).

19. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for generating a conditional alarm in a network, the method comprising: receiving (502), by a receiving module (212), a plurality of requests from at least one network entity; detecting (504), by a threshold monitoring module (214), at least one fault within the network by monitoring the plurality of received requests; upon detecting the at least one fault, determining (506), by the threshold monitoring (214), whether a number of the plurality of received requests exceeds a first preconfigured value; upon determining that the number of the plurality of received requests exceeds the first preconfigured value, calculating (508), by the threshold monitoring module (214), an error percentage based on the number of the plurality of received requests and one or more failed requests; comparing (510), by the threshold monitoring module (214), the calculated error percentage with a second preconfigured value; and performing (512), by an alarm generation module (216), a control action on the conditional alarm based on the comparison.

Images