Minimizing Alarm Notifications
There are several instances where you might want to keep the amount of alarms generated by a T:LAN to a minimum. One such example would be where alarms are forwarded via satellite. Bandwidth on a satellite link is metered and paid for in bytes (not Megabytes). So accounting for every byte consumed by alarm transmissions is crucial. Only then can you be sure that you are staying within the very limited monthly data budget plans.
But there are other situations where you want to limit the volume of alarms generated. Not just in a single node. Sometimes you need to do this across the whole network. The aim would be to reduce the load being placed on the central NMS. And the NOC staff having to cope with the constant influx of alarm messages.
This blog post highlights strategies offered by the Optima T:LAN devices. The ultimate goal: keep the amount of alarm messages generated to a minimum.
Look up the codes to restore the labels at the NMS end.
Use the alarm label to store a unique alarm code. Place the code in the first few characters of the label. This helps in situations where the alarm transmission via satellite truncates the label. At the receiving end, the NMS uses this code to reference a look-up table. The table entry is then used to replace the code, restoring the original label in its entirety.
Program all alarm inputs with a suitable QUALIFICATION PERIOD (QP). This filters out alarm instances that do not satisfy the minimum time that the alarm has to be active for. If an input goes into and out of alarm faster than the QP:
- it will not be considered valid, and
- it will not generate any alarm messages either.
This is especially helpful if you are dealing with noisy or chatter-prone inputs. See our tip about the length of the QP in the next section.
Enable AAS whenever possible. It works by limiting the amount of times an input can go into and out of alarm within a preset GUARD PERIOD. In burglar alarm systems this is sometimes referred to as SWINGER SHUTDOWN.
Once the user defined number of notifications has been exceeded, the input is forced into suppression mode. A suppression timer is started as well. The input can no longer generate alarm messages during the suppression period.
Once the suppression period expires, the input will be taken out of suppression mode, and the input is once again allowed to generate alarms.
Depending on the user selected QP, the GUARD and SUPPRESSION PERIOD are either 1h (for any QP less than 90s), or 12h (for any QP equal to or greater than 90s). Selecting a QP of at least 90s guarantees that the input will stay quiet for at least 12h. Just in case it ever exceeds the allowed number of transitions within the GUARD PERIOD.
Selecting a very low AAS count (example: 3) guarantees that the corresponding input won’t overtax the available resources at the NMS end. Or use up all the available bandwidth on an satellite link.
T:LAN units can send alarm notifications to four different NMS stations at the same time. That means one single alarm can generate up to four messages, one for each of the four possible destinations. Ensuring that an input only generates messages destined for one NMS cuts down the volume.
The ALARMS-UPLINK mode in the T:LAN allows users to define a minimum severity threshold. Alarm messages with a severity lower than the specified minimum will not be sent across the satellite link.
Choosing the right severity for the right alarms makes sense. It keeps lower rated alarms from chewing up precious bandwidth.
Pick your most important alarms. Assign a high enough severity. Then set the minimum ALARMS-UPLINK severity to match.
Certain ALARMS-UPLINK settings depend on the alarm forwarding mode. For the most efficient way of reporting alarms, select REPORT ONLY THE MOST RECENT mode. This ensures that all newly recorded IO events abort any prior event reporting for the same IO (which might still be in progress). The event forwarder immediately switches to the most recent event for the corresponding IO. This avoids situations where the T:LAN would:
- continue to try and forward multiple,
- previously recorded,
- sequential alarm messages,
- for the same IO.
REPORT ONLY THE MOST RECENT ensures only one message (carrying the most recent status information) will be in-flight at any given time.
This significantly cuts down on alarm message volume. Especially when a high number of alarm transitions are expected.
Enable ALARMS-UPLINK ACK PROCESSING. This will tell the T:LAN when it is safe to stop re-transmitting the same alarm message. An ACK means the earth station confirmed it received the original alarm. ACK PROCESSING eliminates situations where the same message might be sent multiple times.
Set up proper alarm repeat intervals.
Trap throttling enforces an upper limit as to the number of SNMP traps generated by the T:LAN in each interval.
Set this rate to either 1 or 2 to limit the number of alarm messages that may be generated during each 60s period. Throttled alarms are buffered, then re-transmitted in a future interval. Provided of course, that the trap throttling limit has not been reached during that 1 minute period.
Ralf Doewich
Optima Tele.com, Inc.
Photo Credit: Kevin Quezada/Unsplash