Management of alarms' occurrences
The ThingPark platform manages the number of occurrences of alarms that are raised according to a classification of alarms.
State-driven alarms
Event-driven alarms
For a state-driven alarm, the number of occurrences is not applicable and always set to 1.
For an event-driven alarm, the number of occurrences increases each time the event associated with the alarm is detected. Hence, a high number of occurrences of an event-driven alarm can be considered as an aggravating factor of the severity of the alarm.
Note Existing alarms are not migrated. Hence, existing state-driven alarms with a number of occurrences greater than 1 will still exist after an upgrade. For these alarms, the number of occurrences will be reset to 1 when the alarm will be recycled (that is, updated from clear to non-clear state).
The following tables detail this categorization.
Base station alarms triggered by a state
| Alarm number | Alarm description |
|---|---|
| 102 | Base station connection status |
| 103 | Unusually low uplink traffic level |
| 104 | Unusually high level of invalid uplink physical CRC |
| 105 | Downlink frame rate exceeds the RF cell capacity |
| 106 | Unusually high CPU usage level |
| 107 | Unusually high RAM usage level |
| 108 | Unusually high file system usage level |
| 109 | Time synchronization lost |
| 110 | Power failure detected |
| 111 | Beacon transmission failure |
| 112 | Abnormal log activation |
| 121 | Backhaul network interface status |
Base station alarms triggered by an event
| Alarm number | Alarm description |
|---|---|
| 101 | LRR software restarted by watchdog |
| 114 | Wrong MIC detected in Join request |
| 115 | Join request replay detected (wrong MIC correlation) |
| 116 | Uplink frame replay detected (wrong FCnt) |
| 117 | Wrong MIC detected in Uplink frame |
| 118 | Uplink frame replay detected (repeated FCnt) |
| 119 | Invalid AppEUI detected in Join request |
| 120 | Join request replay detected (invalid DevNonce) |