EP-4740384-A1 - SYSTEM AND METHOD FOR TICKET MANAGEMENT OF PLANNED EVENTS IN A NETWORK
Abstract
A system and a method of ticket management of planned events is described. The method includes receiving alarms related to operation of nodes or services operational in a network. An alarm raised during a planned event (PE) is identified from the alarms. The alarm is identified based on one or more of operational task data, a start schedule, and an end schedule of the PE, the PE indicating a time window for performing maintenance on a node in the network. Attributes of the alarm raised during the PE are updated using data present in a PE profile. A request corresponding to the alarm is sent to a TT processor (235) for creation or termination of a TT, and the request is addressed within a predefined time period after end of the PE.
Inventors
- BHATNAGAR, AAYUSH
- BISHT, SANDEEP
- MISHRA, RAHUL
- VERMA, AKASH
- MISHRA, SOMYA
- Singla, Deepanshu
- KASHYAP, Namrata Rammurat
Assignees
- Jio Platforms Limited
Dates
- Publication Date
- 20260513
- Application Date
- 20240703
Claims (18)
- 1. A method of ticket management of planned events in a network, the method comprising the steps of: receiving, by a fault processor (230), one or more alarms related to operation of one or more nodes or services operational in a network; identifying, by the fault processor (230), an alarm, from the one or more alarms, raised during a planned event (PE), wherein the alarm is identified based on one or more of operational task data, a start schedule, and an end schedule of the PE; updating, by the fault processor (230), attributes of the alarm raised during the PE, using data present in a PE profile; sending, by the fault processor (230), a request, to a TT processor (235) for creation or termination of a TT corresponding to the alarm; and addressing, by the TT processor (235), the request for creation or termination of the TT, within a predefined time period after end of the PE.
- 2. The method as claimed in claim 1, wherein the data present in the PE profile provides details of the PE and includes one or more of Service Affecting flag, change ID or PE ID, impacted network element ID, PE start time, PE end time, date when PE row was inserted in database, and a unique key.
- 3. The method as claimed in claim 1, wherein the operational task data includes identities of nodes expected to become inactive during the PE.
- 4. The method as claimed in claim 1, the PE indicates a time window for performing maintenance on a node in the network.
- 5. The method as claimed in claim 1, comprising creating, by the TT processor (230), the TT based on a user input provided through a user interface (UI).
- 6. The method as claimed in claim 1, wherein the request for creation and termination of the TT is sent to the TT processor (230) using a Hypertext Transfer Protocol (HTTP) stream or message stream.
- 7. The method as claimed in claim 1, wherein the TT processor (230) stores and retrieves the alarm from a persist storage for creation and termination of the TT.
- 8. The method as claimed in claim 6, wherein for creation of the TT, the TT processor (230): obtains the alarm from the persist storage; determines that a status of the alarm is active; and changes a service affecting attribute of the alarm to Service Affecting (SA) and a TT status of the alarm to initiated, when severity of the alarm is critical or major.
- 9. The method as claimed in claim 1, wherein the attributes of the alarm comprise one or more of Change ID (CID), Non-Service Affecting (NSA) CID, Service Affecting (SA) CID, planned maintenance, and an outage information.
- 10. A system for ticket management of planned events in a network, the system comprising: a fault processor (230) configured to: receive one or more alarms related to operation of one or more nodes or services operational in a network; identify an alarm, from the one or more alarms, raised during a planned event (PE), wherein the alarm is identified based on one or more of operational task data, a start schedule, and an end schedule of the PE; update attributes of the alarm raised during the PE, using data present in a PE profile; and send a request, corresponding to the alarm, to a TT processor (230) for creation or termination of a TT, and the TT processor (235) configured to address the request for creation or termination of the TT, within a predefined time period after end of the PE.
- 11. The system as claimed in claim 10, wherein the data present in the PE profile provides details of the PE and includes one or more of Service Affecting flag, change ID or PE ID, impacted network element ID, PE start time, PE end time, date when PE row was inserted in database, and a unique key.
- 12. The system as claimed in claim 10, wherein the PE indicates a time window for performing maintenance on a node in the network.
- 13. The system as claimed in claim 10, wherein the operational task data comprises one of a Service Affecting Flag, PE identification (ID), impacted network element ID, and a unique key.
- 14. The system as claimed in claim 10, wherein the fault processor (230) sends the request for creation and termination of the TT using a Hypertext Transfer Protocol (HTTP) stream or message stream.
- 15. The system as claimed in claim 10, wherein the attributes of the alarm comprise one or more of Change ID (CID), Non-Service Affecting (NSA) CID, Service Affecting (SA) CID, planned maintenance, and an outage information.
- 16. The system as claimed in claim 10, wherein for creation of the TT, the TT processor (235) is configured to: obtain the alarm from the persist storage; determine that a status of the alarm is active; and change a service affecting attribute of the alarm to SA and a TT status of the alarm to initiated, when severity of the alarm is critical or major.
- 17. A network equipment (102) comprising: one or more processors coupled with a memory, wherein said memory stores instructions which when executed by the one or more processors causes the network equipment to: transmit one or more alarms related to operation of one or more nodes or services operational in a network, wherein the one or more processors is configured to perform the steps as claimed in claim 1.
- 18. A non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor (205), cause the processor (205) to: 1 receive one or more alarms related to operation of one or more nodes or services operational in a network; identify an alarm from the one or more alarms raised during a planned event (PE), wherein the alarm is identified based on one or more of operational task data, a start schedule, and an end schedule of the PE, the PE indicates a time window for performing maintenance on a node in the network; update attributes of the alarm raised during the PE, using data present in a PE profile; send a request, corresponding to the alarm, to a TT processor (230) for creation or termination of a TT; and address the request for creation or termination of the TT, within a predefined time period after end of the PE.
Description
SYSTEM AND METHOD FOR TICKET MANAGEMENT OF PLANNED EVENTS IN A NETWORK FIELD OF THE INVENTION [0001] The present invention generally relates to alarm management in a network, and in particular, to a system and a method of handling and managing alarms with regard to Planned Events (PE) in a network. BACKGROUND OF THE INVENTION [0002] Network Alarm Monitoring Systems monitor equipment for notable events - otherwise referred to as "alarms". An alarm may be indicative of an issue related to a hardware, software, or network related issue. In one scenario, an alarm may indicate that a network equipment is failing and a network outage about to occur. Typically, an Alarm Monitoring System should organize and interpret the severity of incoming alarms in real-time, which will help to coordinate maintenance and repair efforts throughout the network. It is an essential part of any Network Management System (NMS). [0003] Alarms can be broadly divided in to two types: 'critical alarms' and 'standard alarms'. Each has their own advantages but also comes with an associated set of challenges. Standard alarms are typically low-priority in nature and are often expected or even scheduled. A critical alarm draws attention to a serious emergency. These can range from things that simply impact on planned production schedules (such as a broken machine) to incidents that threaten the physical safety of staff (such as a fire). Critical alarms are often linked to serious situations with multiple factors that need to be taken into account, often creating confusion amongst responders and managers alike. [0004] Good and effective alarm management systems ensure that organisations can enjoy substantial long term cost savings due to less down time during significant incidents, whilst also allowing control room staff to concentrate on the day to day running of a facility. It also means that critical alarms can be picked up and managed in a more efficient and depending upon the priority level. [0005] By automating the process by which alarms are dealt with, we can eliminate the issue of conflict when it comes to critical vs standard alarms. A critical alarm management system will both sift through notifications for high-priority and high-risk alarms and ensure that they get a swift and comprehensive response. [0006] In the Network Management System, there are several possible events for raising the alarms at any particular time. Some of the alarms raised may need some external resolution. So, these alarms have to be assigned to the concerned resources. This is done by assigning a Trouble Ticket (TT) and managing and tracking the progress of the TT. Ultimately, the objective is that the issue should be resolved and the specific TT is terminated once the issue is resolved. This lifecycle between creation and termination of TTs is called TT management. The TT creation can be also done manually along with profile-based automation. [0007] It is common in network management to schedule Planned Events (PE). For example, a Planned Event (PE) may help in the maintenance activity of the node. Whenever any planned maintenance is going on at any node, the time window as per the schedule will be communicated to all the teams concerned. That window is referred to as Planned Event (PE). During the time of PE, other nodes of the cluster may try to communicate with the node and upon failing may create some alarms. Even in systems when no tickets are assigned based upon alarms raised during a PE, there may still be some automated tickets raised for the nodes which are not aware about the planned events. These alarms may get piled up and clog the system by raising TT, which is not desired. [0008] But at the same time, not all alarms raised during the outage can be ignored and there may have been raised some alarms, which in normal times may need TT assignment. For example, critical alarms and the like. [0009] Therefore, there is a need for systems and methods for managing alarms more efficiently, especially with regard to planned events. The alarm should be managed based upon priority and false alarms should be identified so that false tickets are not raised and the system does not get clogged with piling false tickets. SUMMARY OF THE INVENTION [0010] One or more embodiments of the present disclosure provide a system and method of ticket management of planned events in a network. [0011] In one aspect of the present invention, a system for ticket management of planned events in a network is disclosed. The system includes a fault processor configured to receive one or more alarms related to operation of one or more nodes or services operational in a network. The fault processor is further configured to identify an alarm, from the one or more alarms, raised during a planned event (PE). The alarm is identified based on one or more of operational task data, a start schedule, and an end schedule of the PE. The PE indicates a time window for performing maintenan