Skip to main content

Device alarms

This page lists all device alarms and provides for each alarm the possible root causes and guidelines to solve the associated malfunction.

Battery level threshold 001​

The power of the device battery is very low.

This alarm is automatically CLEARED if the battery level goes above 40%.

  • Possible root causes:
    • The battery level is lower than 30% (WARNING alarm).
    • The battery level is lower than 10% (CRITICAL alarm).
  • Guidelines:
    • Recharge or change the battery of the device.

Traffic exceeds the downlink regulator settings 002​

The device is receiving too many downlink packets.

This alarm is associated with an occurrence number: this is the number of downlink packets exceeding the regulator settings since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • Too many acknowledgments or downlink payloads from external IoT applications.
  • Guidelines:
    • Check the downlink traffic in the RADIO TRAFFIC HISTORY and LAST 10 PACKETS widgets of the device's dashboard to verify if the device's behavior is normal.
    • Reduce the number of acknowledgments and downlink payloads sent from external IoT applications.
    • If the alarm persists, contact your support.

Traffic exceeds the uplink regulator settings 003​

The device is sending too many uplink packets.

This alarm is associated with an occurrence number: this is the number of uplink packets exceeding the regulator settings since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is wrongly configured and sends too many uplink packets. It may quickly discharge its battery.
  • Guidelines:
    • Check the uplink traffic in the RADIO TRAFFIC HISTORY and LAST 10 PACKETS widgets of the device's dashboard to verify if the device's behavior is normal.
    • Reduce the number of uplink packets sent by the device.
    • If the alarm persists, contact your support.

No uplink activity 004​

ThingPark did not receive any uplink frame from the device for the configured duration. To learn more about the configuration of this alarm, see Configuring the "no uplink activity" alarm.

  • Possible root causes:
    • The device was wrongly provisioned.
    • The device cannot catch the LoRaWAN® network due to bad RF coverage.
    • The device is turned-off.
    • The device has no power or power too low to transmit packets.
  • Guidelines:
    • If the device was wrongly provisioned, a Wrong MIC detected in Join request 008 alarm or a Wrong MIC detected in Uplink frame 016 alarm should have been raised. In this case, remove and re-provision the device with the right settings. To learn more about device provisioning, see Activating new devices.
    • Check the RF network coverage of the device and move the device if necessary.
    • Check if the device is switched-on.
    • If the power level of the device is low, a Battery level threshold 001 alarm should have been raised. In this case, recharge or change the battery of the device.
    • If the alarm persists, contact your support.

Node uses higher data rate than expected 005​

The device sends packets with a too low spreading factor (for instance, SF7 instead of SF10). This alarm is only applicable if the ADR control is activated (ADR bit set to 1 in uplink frames sent by the device).

  • Possible root causes:
    • The device's firmware does not support ADR or is configured with a fixed spreading factor.
  • Guidelines:
    • Check the device's firmware ADR configuration (refer to the manufacturer's documentation).
    • If the alarm persists, contact your support.

Node uses lower data rate than expected 006​

The device sends packets with a too high spreading factor (for instance, SF10 instead of SF8). This alarm is only applicable if the ADR control is activated (ADR bit set to 1 in uplink frames sent by the device).

  • Possible root causes:
    • The device's firmware does not support ADR or is configured with a fixed spreading factor (this is probably the case if the severity is MAJOR).
    • The device is using the spreading factor fallback procedure (also known as "data rate backoff" in LoRaWAN specification, see the note below) due to bad RF network coverage (this is probably the case if the severity is WARNING).
  • Guidelines:
    • Check the device's firmware ADR configuration (refer to the manufacturer's documentation).
    • Check the RF network coverage of the device and move the device if necessary.
    • If the alarm persists, contact your support.
Data rate backoff procedure

The device tries to reconnect to the network by downgrading the data rate (for instance a device may take the decision to increase the spreading factor from SF10 to SF11 because 3 uplink packets were sent without any acknowledgement). This is typically the consequence of a too poor Signal-to-Noise Ratio (SNR).

Join request replay detected (DevNonce replay) 007​

ThingPark received a join request containing a DevNonce already used by the device. The illegitimate join request has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of join requests with DevNonce replay received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of a join request replay attack from a malicious user.
    • The device sent a join request containing a DevNonce already used.
  • Guidelines:
    • If the number of the alarm occurrences is high:
      • If the device sent a join request containing a DevNonce already used, its DevNonce implementation does not follow the LoRaWAN® MAC layer recommendations defined by the LoRa Alliance®. Reset the device context in the network server. To do so, expand the alarm in the list as explained in Viewing the list of device alarms and click on the RESET DEVICE CONTEXT button.
      • The device may be the victim of a join request replay attack. Stop the base station radio and try to identify the attacker.
      • If the replay attack risk is high, the device is strongly recommended to implement the enhanced security feature by implementing counter-based DevNonce as recommended by the LoRa Alliance in the Technical Recommendations for Preventing State Synchronization Issues around LoRaWAN® 1.0.x Join Procedure.
    • If the alarm persists, contact your support.

Wrong MIC detected in Join request 008​

ThingPark received a join request containing a wrong MIC. The illegitimate join request has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of join requests containing a wrong MIC received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of a join request replay attack from a malicious user.
    • The device sent a join request containing a wrong MIC possibly due to wrong device provisioning (that is, a wrong AppKey was configured).
  • Guidelines:
    • If the number of the alarm occurrences is high,
      • If the device was wrongly provisioned, remove and re-provision the device with the right AppKey. To learn more about device provisioning, see Activating new devices.
      • Check the behavior of the device and fix it if needed.
      • The device may be the victim of a join request replay attack. Stop the base station radio and try to identify the attacker.
    • If the alarm persists, contact your support.

Join request replay detected (wrong MIC correlation) 009​

ThingPark received an uplink frame for which the MIC does not match the join request previously received. The illegitimate join request has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of uplink frames with wrong MIC correlation received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of a join request replay attack from a malicious user.
  • Guidelines:

Uplink frame replay detected (wrong FCnt) 010​

ThingPark received an uplink frame containing a wrong FCnt. The illegitimate uplink frame has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of uplink frames containing a wrong FCnt received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of an uplink frame replay attack from a malicious user.
    • If the device uses Activation-by-Personalization (ABP) and was recently reset, the reset may have not been detected by the network server.
  • Guidelines:
    • If the number of the alarm occurrences is high, the device may be the victim of an uplink frame replay attack. Stop the base station radio and try to identify the attacker.
    • If the device uses Activation-by-Personalization (ABP) and was recently reset, reset the device context in network server. To do so, expand the alarm in the list as explained in Viewing the list of device alarms and click on the RESET DEVICE CONTEXT button.
    • If the alarm persists, contact your support.

Uplink frame replay detected (repeated FCnt) 011​

ThingPark received an uplink frame containing a repeated FCnt beyond the maximum number of authorized repetitions. The illegitimate uplink frame has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of uplink frames containing a repeated FCnt received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of an uplink frame replay attack from a malicious user.
    • The device exceeds its maximum number of authorized repetitions.
  • Guidelines:
    • If the number of the alarm occurrences is high,
      • Check the behavior of the device and fix it if needed;
      • The device may be the victim of an uplink frame replay attack. Stop the base station radio and try to identify the attacker.
    • If the alarm persists, contact your support.

MAC command transmission blocked (transmission rejected) 012​

ThingPark blocked the transmission of the given MAC command because the device rejected it after several attempts.

  • Possible root causes:
    • The device rejects the MAC command sent by ThingPark.
  • Guidelines:
    • Check the behavior of the device and fix it if needed.
    • If the alarm persists, contact your support.

MAC command transmission blocked (no reply) 013​

ThingPark blocked the transmission of the given MAC command because the device did not reply to it after several attempts.

  • Possible root causes:
    • The device did not receive the MAC command sent by ThingPark.
    • The device's firmware does not support the MAC command but is wrongly configured in ThingPark with a model supporting it.
  • Guidelines:

Invalid AppEUI detected in Join request 014​

ThingPark received a join request containing an invalid JoinEUI (AppEUI). The maximum number of different JoinEUI (AppEUI) that can be used by the same device is 32. The illegitimate join request has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of join requests containing an invalid JoinEUI (AppEUI) received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The JoinEUI (AppEUI) value has changed too many times for this device.
  • Guidelines:
    • If the device has used more than 32 different JoinEUI (AppEUI), fix it.
    • If the alarms persist, contact your support.

Join request replay detected (invalid DevNonce) 015​

ThingPark received a join request containing an invalid DevNonce whereas the device is supposed to use counter-based DevNonce. The illegitimate join request has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of join requests containing an invalid DevNonce received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of a join request replay attack from a malicious user.
    • The device does not increment the DevNonce on each new join request.
  • Guidelines:
    • If the device is not configured with the right model, change it. To learn more, see Updating device parameters, and viewing/editing device details.
    • If the number of the alarm occurrences is high, the device may be the victim of a join request replay attack. Stop the base station radio and try to identify the attacker.
    • If the alarm persists, contact your support.

Wrong MIC detected in Uplink frame 016​

ThingPark received an uplink frame containing a wrong MIC. The illegitimate uplink frame has been dropped by ThingPark and therefore is not visible in the Wireless Logger.

This alarm is associated with an occurrence number: this is the number of uplink frames containing a wrong MIC received since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

  • Possible root causes:
    • The device is the victim of an uplink frame replay attack from a malicious user.
    • The device sent an uplink frame containing a wrong MIC possibly due to wrong device provisioning (that is, a wrong NwkSKey was configured for an ABP device).
    • A device belonging to another LoRaWAN® network has the same DevAddr than your device. A wrong MIC has been detected because the network server checked the MIC generated by the external device using the NwkSKey of your device.
  • Guidelines:
    • If the number of the alarm occurrences is high,
      • If the device uses Activation-by-Personalization (ABP) and was wrongly provisioned remove and re-provision the device with the right NwkSKey. To learn more about device provisioning, see Activating new devices.
      • Check the behavior of the device and fix it if needed.
      • The device may be the victim of an uplink frame replay attack. Stop the base station radio and try to identify the attacker.
    • If the alarm persists, contact your support.

Join loop detected 017​

ThingPark received several consecutive join requests from the device without any data uplink packet.

This alarm is associated with an occurrence number: this is the number of consecutive join request received since the creation of the alarm. The alarm is automatically CLEARED as soon as a data uplink packet is received.

  • Possible root causes:
    • The device did not receive the join accepts.
    • The battery level is too low and the device is only able to send a join request on wake up.
  • Guidelines:
    • Check the transmission status of the join accepts in the RADIO TRAFFIC HISTORY and LAST 10 PACKETS widgets of the device's dashboard: the transmission of join accepts may be in failure.
    • Check the behavior of the device (for instance the battery status) and fix it.
    • If the alarm persists, contact your support.
Last updated on
Copyright © 2024 Actility
On this page