Base station alarms

This page lists all base station alarms and provides for each alarm the possible root causes and guidelines to solve the associated malfunction. Guidelines often require a remote access to the base station. To learn more about remote access, see Performing remote access and rescue access.

note

The following alarms are not supported by base stations using Semtech's Basics Station packet forwarder:

• System alarms:
  • LRR software restarted by watchdog 101
  • Unusually high CPU usage level 106
  • Unusually high RAM usage level 107
  • Unusually high file system usage level 108
  • Time synchronization lost 109
  • Power failure detected 110
  • Abnormal log activation 112
  • Backhaul network interface status 121
  • GPS lock failure detected 122
• RF cell alarms:
  • Unusually low uplink traffic level 103
  • Unusually high level of invalid uplink physical CRC 104
  • Downlink frame rate exceeds the RF cell capacity 105
  • Beacon transmission failure 111

System alarms

LRR software restarted by watchdog 101

The base station LRR software gets rebooted because no uplink frames were received during a configurable time window (configured in lrr.ini, one hour by default).

This alarm is associated with an occurrence number: this is the number of LRR software restarts since the creation of the alarm. The alarm is automatically CLEARED if no new occurrence is detected during one day.

• Possible root causes:
  • Assert in the LRR software.
  • Faulty gateway (deaf).
  • The time window is configured too short.
• Guidelines:
  • Check the time window configuration in lrr.ini (autoreboottimer_nouplink parameter).
  • Collect logs and contact your support.

note

Uplink frames received with CRC error are counted as valid uplink frames in the scope of this alarm.

Base station connection status 102

The base station is not connected to ThingPark.

• Possible root causes:
  • The base station has been suspended by an administrator (MAJOR alarm).
  • The base station is not suspended but has never connected to ThingPark (WARNING alarm).
  • The base station is not suspended but is disconnected from ThingPark (CRITICAL alarm).
• Guidelines:
  • If the base station is not suspended:
    • If the base station could not come up online after being configured and provisioned, see some debug tips in Troubleshooting the base station connectivity.
    • Check the base station power for potential power failure.
    • Check the backhaul connection for potential network failure.
    • Check if the lrr.x process is running, restart it if needed.
    • Collect logs and contact your support.

Unusually high CPU usage level 106

The CPU usage of the base station reaches an abnormal level.

This alarm is automatically CLEARED if the CPU usage drops below 80%.

• Possible root causes:
  • The CPU usage exceeds 85% (WARNING alarm).
  • The CPU usage exceeds 95% (MAJOR alarm).
• Guidelines:
  • Collect logs and contact your support.

Unusually high RAM usage level 107

The RAM usage of the base station reaches an abnormal level.

This alarm is automatically CLEARED if the RAM usage drops below 75%.

• Possible root causes:
  • The RAM usage exceeds 80% (WARNING alarm).
  • The RAM usage exceeds 99% (MAJOR alarm).
• Guidelines:
  • Collect logs and contact your support.

Unusually high file system usage level 108

The file system usage of the base station reaches an abnormal level.

This alarm is automatically CLEARED if the file system usage drops below 90%.

• Possible root causes:
  • The file system usage of a partition exceeds 95% (WARNING alarm).
  • The file system usage of a partition exceeds 99% (MAJOR alarm).
• Guidelines:
  • Collect logs and contact your support.

Time synchronization lost 109

The base station lost its time synchronization.

• Possible root causes:
  • The NTP client started whereas no IP address was allocated.
  • The NTP client did not start correctly after a base station restart.
• Guidelines:
  • Restart the NTP client: settime restart.
  • Collect logs and contact your support.

Power failure detected 110

The base station is running on battery because of a power supply defect.

• Possible root causes:
  • The base station is disconnected from the power grid.
  • A power grid failure occurs.
• Guidelines:
  • Check the connection of the base station to the power grid.
  • Check the power of the grid.

Abnormal log activation 112

An abnormal activation of the LRR software log has been detected.

• Possible root causes:
  • Log is activated with a trace level > 0 without RAM disk usage (CRITICAL alarm).
  • Log is activated with a trace level > 0 for 7 days (MAJOR alarm).
• Guidelines:
  • Activate RAM disk usage if not already activated.
  • If an ongoing troubleshooting session does not justify the log activation, deactivate it.
  • If the alarm persists, contact your support if the trace level cannot be set to 0.

warning

In some cases, when a base station makes many writes into flash memory, it might damage the normal usage and behavior of the base station.

Backhaul network interface status 121

At least one backhaul link of the base station is lost.

• Possible root causes:
  • IP address issue, for instance due to DHCP.
  • For a cellular interface: 3G/LTE network failure, no SIM card, bad network coverage.
  • Bad configuration of the backhaul interface in the base station.
• Guidelines:
  • Use manual IP address allocation in case of DHCP issue.
  • Check the interface configuration and correct configuration issues if needed. To learn more, see Configuring network interfaces.
  • For alarms related to cellular backhaul: check the cellular network coverage, the status of the SIM card and the subscription with the cellular operator. You can check the cellular indicators in the INTERFACES widget of the base station's dashboard, under the Backhaul Statistics tab.

GPS lock failure detected 122

A GPS lock failure has been detected. The base station cannot use GPS position and time synchronization.

• Possible root causes:
  • The cable and/or the antenna of the GPS receiver is degraded.
  • There are not enough satellites to lock the GPS signal.
  • Strong interference on GPS receiver from surrounding transmitters results in receiver blocking.
• Guidelines:
  • Check the GPS receiver installation (cable and antenna).
  • Change the base station or the GPS antenna position to provide a better sky/satellite access or reduce interference risk from surrounding transmitters.

warning

When GPS is down, the following functions are not supported:

• Class B and beaconing.
• TDoA device geolocation.
• Time-synchronized multicast transmission.
• GPS-based base station location.

RF cell alarms

Unusually low uplink traffic level 103

The base station did not received any uplink frame for the configured duration. To learn more about the configuration of this alarm, see Configuring the BS alarm #103.

• Possible root causes:
  • There are no devices in the base station covered area.
  • The radio signal is interfered by an external jammer.
  • A defect occurs in the base station RF chain.
• Guidelines:
  • Check if there is an active device in the area covered by the base station.
  • Check if an RF equipment has been installed next to the base station (causing potential interference).
  • Scan the radio on the base station to check the noise level.
  • If the alarm persists, contact your support.

Unusually high level of invalid uplink physical CRC 104

This alarm is raised when a high level of LoRa® frames received by the base station cannot be demodulated properly, or when there are many non-LoRa® frames received by the base station with a physical preamble like LoRa®.

• Possible root causes:
  • The number of packets generated by devices in the base station covered area is too high causing frame collisions.
  • A noise is generated by another LoRa® network's base stations' nearby.
  • A jammer/non-LoRa® equipment is interfering (most likely if ratio is very high).
  • A defect occurs in the base station RF chain.
• Guidelines:
  • If the uplink duty cycle of the base station is high, switch off some devices. You can check the uplink duty cycle statistics in the DUTY CYCLE widget of the base station's dashboard, under the RF Statistics tab. The typical maximum uplink duty cycle is around 10% per logical channel.
  • Check if an RF equipment has been installed next to the base station (causing potential interference).
  • Scan the radio on the base station to check the noise level.
  • If the alarm persists, contact your support.

Downlink frame rate exceeds the RF cell capacity 105

This alarm is raised when some downlink packets were dropped by the base station (received from the network server but not sent over-the-air) because the RF cell modem was busy. Therefore, the base station was not able to send these downlink packets (for instance a downlink packet of a class 'A' device for which the transmission window is outdated).

• Possible root causes:
  • There are too many LoRaWAN® acknowledgments or MAC reconfigurations attempts.
• Guidelines:
  • Reduce the acknowledgments requested by your devices.
  • Reduce the downlinks sent by your applications.
  • Have a better repartition of the downlink MAC reconfiguration messages (for instance RF Region updates) over time to prevent temporary saturation of the downlink capacity.
  • Add a new base station to your network.
  • If the alarm persists, contact your support.

Beacon transmission failure 111

The base station failed to transmit the last class B beacon.

• Possible root causes:
  • The radio is stopped.
  • The Listen Before Talk (LBT) procedure did not allow the transmission.
  • The GPS synchronization is lost.
  • The duty cycle constraint is reached.
• Guidelines:
  • Check the radio status of the base station.
  • Check the GPS status of the base station.
  • Check the downlink duty cycle on the beacon's RF sub-band. Downlink duty cycle statistics are displayed in the DUTY CYCLE widget of the base station's dashboard, under the RF Statistics tab.
  • If the alarm persists, contact your support.

Join request replay detected (DevNonce replay) 113

The base station received a join request containing a DevNonce already used by the same device. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station 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. For more information, see Join request replay detected (DevNonce replay) 007;
    • 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.

Wrong MIC detected in Join request 114

The base station received a join request containing a wrong MIC. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station is the victim of a join request replay attack from a malicious user.
  • A 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,
    • Check the device's information and behavior and fix issues;
    • 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.

Join request replay detected (wrong MIC correlation) 115

The base station received an uplink frame for which the MIC does not match the join request previously received. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station is the victim of a join request replay attack from a malicious user.
• Guidelines:
  • 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.

Uplink frame replay detected (wrong FCnt) 116

The base station received an uplink frame containing a wrong FCnt. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station 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 base station may be the victim of an uplink frame replay attack. Stop the radio and try to identify the attacker.
  • If the device uses Activation-by-Personalization (ABP) and was recently reset, reset the device context in the corresponding device alarm. For more information, see Uplink frame replay detected (wrong FCnt) 010.
  • If the alarm persists, contact your support.

Wrong MIC detected in Uplink frame 117

The base station received an uplink frame containing a wrong MIC. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station is the victim of an uplink frame replay attack from a malicious user.
  • A 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 a device belonging to the local LoRaWAN® network. A wrong MIC has been detected because the network server checked the MIC generated by the external device using the NwkSKey of the local device.
• Guidelines:
  • If the number of the alarm occurrences is high,
    • Check the device's information and behavior and fix issues;
    • The base station may be the victim of an uplink frame replay attack. Stop the radio and try to identify the attacker.
  • If the alarm persists, contact your support.

Uplink frame replay detected (repeated FCnt) 118

The base station received an uplink frame containing a repeated FCnt beyond the maximum number of authorized repetitions. This alarm is raised on the impacted base station to allow localizing the potential attack area. 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 base station is the victim of an uplink frame replay attack from a malicious user.
  • A device exceeds its maximum number of authorized repetitions.
• Guidelines:
  • If the number of the alarm occurrences is high,
    • Check the device's information and behavior and fix issues;
    • The base station may be the victim of an uplink frame replay attack. Stop the radio and try to identify the attacker.
  • If the alarm persists, contact your support.

Invalid AppEUI detected in Join request 119

The base station 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) 120

The base station 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 base station 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:
  • The device may be configured with a wrong model in ThingPark. Check the corresponding device alarm, see Join request replay detected (invalid DevNonce) 015.
  • 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.