Alarms used for troubleshooting devices

You can use the following table to help you troubleshoot devices. They explain the meaning of each alarm, its probable cause and corrective actions.

Devices' alarms

Alarm ID	Alarm name	Explanation	Possible Root Causes	Guidelines
001	Battery level threshold (state-driven)	The power of the battery is very low.	The battery of the device has a very low power.	Change the battery of the device.
002	Traffic exceeds the downlink regulator settings (event-driven)	The device is receiving too many packets.	Too many acknowledgments or downlink packets from Application Servers. The limit set by the Administrator does not match the device behavior.	Check the downlink packets sent to verify if the device's behavior is normal. If the alarm persists, contact your support.
003	Traffic exceeds the uplink regulator settings (event-driven)	The device exceeds the Administrator policy.	The device may send too many packets. It may quickly discharge the battery.	If the power level of the device is low, change the battery. Reduce the number of packets sent by the device. If the alarm persists, contact your support.
004	No uplink activity warning (state-driven)	The device has not sent any packet for the past X hours according to the thresholds you have defined. To learn more, click	The device is OFF. No power or power too low to transmit packets. The device cannot connect to the network. Wrong provisioning of the device.	Check if the device is ON. If the power level of the device is low, change the battery. If the device is not located in the coverage area of the network, move the device. Check the device information. If the alarm persists, contact your support.
005	Node uses higher data rate than expected (state-driven)	The device sends packets whose Spreading Factor is too low (e.g. SF7 instead of SF10)	The device's firmware does not support ADR or is configured with a fixed Spreading Factor. The device did not receive the LoRaWAN® ADR command to adjust Spreading Factor.	Check the device's firmware ADR configuration (see your device documentation). If the alarm persists, contact your support.
006	Node uses lower data rate than expected (state-driven)	The device sends packets whose Spreading Factor is too high (e.g. SF10 instead of SF8)	The device's firmware does not support ADR or is configured with a fixed Spreading Factor. The device did not receive the LoRaWAN® ADR command to adjust Spreading Factor. The device is using Spreading Factor fallback procedure (SNR degraded).	Check the device's firmware ADR configuration (see your Device documentation). Check the coverage of the device and move the device if necessary. If the alarm persists, contact your support.
007	Join request replay detected (DevNonce replay) (event-driven)	A DevNonce replay has been detected in a Join request (Last occurrence was for the given DevNonce)	The device is the victim of a join request replay attack. The device sent a join request containing a DevNonce already used.	If the number of the alarm occurrences is high: If the device sent a join request containing a DevNonce already used, fix it. The device may be the victim of a join request replay attack. Stop the radio and try to identify the attacker. If the alarm persists, contact your support.
008	Wrong MIC detected in Join request (event-driven)	A wrong MIC has been detected in a Join request	The device is the victim of a join request adversary attack. The device sent a join request containing a wrong MIC possibly due to wrong device provisioning (e.g. bad Appkey).	If the number of the alarm occurrences is high: Check the device's information and behavior, and fix issues. The device may be the victim of a join request replay attack. Stop the radio and try to identify the attacker. If the alarm persists, contact your support.
009	Join request replay detected (wrong MIC correlation) (event-driven)	A wrong MIC correlation has been detected between a Join request and the following uplink packet (Last occurrence was for the given DevNonce)	The device is the victim of a join request replay attack.	If the number of the alarm occurrences is high, the device may be the victim of a join request replay attack. Stop the radio and try to identify the attacker. If the alarm persists, contact your support.
010	Uplink frame replay detected (wrong FCnt) (event-driven)	A wrong FCnt has been detected in an uplink packet (Last occurrence was for the given FCnt)	The device is the victim of an uplink packet replay attack. The device reset has not been detected by the Network Server.	If the number of the alarm occurrences is high, the base station may be the victim of a join request replay attack. Stop the radio and try to identify the attacker. If the alarm persists, contact your support.
012	MAC command transmission blocked (transmission rejected) (state-driven)	The transmission of the given MAC command has been blocked after a given attempts and rejected.	The device rejects the MAC command sent by the Network Server.	Check the behavior of the device and fix it. If the alarm persists, contact your support.
013	MAC command transmission blocked (no reply) (state-driven)	The transmission of the given MAC command has been blocked after a given number of attempts because of no reply.	The device did not receive the MAC command sent by the Network Server. The device's firmware does not support the MAC command.	Check if the device is ON. If the power level of the device is low, change the battery. If the device is not located in the coverage area of the LoRaWAN® network, move the device. Check the behavior of the device and fix it. If the alarm persists, contact your support.
014	Invalid AppEUI detected in Join request (event-driven) For LoRaWAN® 1.0 OTAA devices, only applies if the device supports counter-based DevNonce and has been created using a model activating this behavior. Applies to all LoRaWAN® 1.1 OTAA devices.	An invalid AppEUI issue has been detected in a Join request concerning the used AppEUI (or JoinEUI in LoRaWAN® 1.1).	The device has changed too many times its AppEUI/JoinEUI value (maximum allowed: 32).	If a LoRaWAN® 1.0 device, check that it supports the counter-based DevNonce feature and that the model used to create the device is correct. If yes, the replay attack risk will not jeopardize the device operation. If not, change the model. If the device has used more than 32 different AppEUIs, fix it. Check the behavior of the device and fix it. If the alarm persists, contact your support.
015	Join request replay detected (invalid DevNonce) (event-driven) For LoRaWAN® 1.0 OTAA devices, only applies if the device supports counter-based DevNonce and has been created using a model activating this behavior. Applies to all LoRaWAN® 1.1 OTAA devices.	A DevNonce replay attack has been detected in a Join request concerning the DevNonce used with the AppEUI (or JoinEUI in LoRaWAN® 1.1).	A DevNonce has been reused with the same AppEUI/Join EUI: The device is the victim of a join request replay attack.	If a LoRaWAN® 1.0 device, check that it supports the counter-based DevNonce feature and that the model used to create the device is correct. If yes, the replay attack risk will not jeopardize the device operation. If not, change the model.> If the number of the alarm occurrences is high, the device may be the victim of a join request replay attack. Stop the radio and try to identify the attacker. If the alarm persists, contact your support.