LoRaWAN Frame Counter Resets: Investigate Missing Data Without Weakening Replay Protection
A LoRaWAN sensor restarts after maintenance. The gateway still hears its packets, but the application stops receiving fresh measurements. Before changing antennas or weakening security settings, check whether the device and network server still agree on the session and frame counters.
The useful distinction is between radio reception and acceptance by the network. A received packet can be rejected before a payload decoder ever sees it. This guide shows how to investigate a suspected counter reset, preserve evidence and plan recovery with replay protection intact.
What the counter protects
Frame counters help distinguish new traffic from previously transmitted messages. The Things Stack best-practice documentation calls for incrementing counters and preserving session information, including counters and nonces, across regular power cycles. A counter problem therefore belongs in the session investigation, rather than being treated as a sensor calibration error.
Keep these quantities separate in your notes: the network frame counter, the sensor’s measured value and any application total. A frame counter is not a rainfall total, production count or temperature sample number. Resetting a measurement total does not establish a new radio session.
Confirm the activation mode first
With ABP, the device is provisioned with a fixed address and session keys. The Things Stack’s ABP and OTAA comparison explains that resetting an ABP frame counter can cause messages to be dropped. With OTAA, a successful join establishes a new session with derived session keys. An ordinary restart and a successful new join are different events; do not assume one proves the other.
Identify the actual device, firmware, LoRaWAN version and server configuration. A general troubleshooting note is not proof that every model loses counters on restart. For a replacement unit, also verify the identity against the asset register rather than assuming that a reused dashboard name identifies the same hardware.
Worked example: heard by the gateway, rejected upstream
Hypothetical example: before maintenance, an ABP device’s accepted uplink counter is 8,420. After a restart, a gateway log shows traffic from the expected device address with a counter starting at zero. The application’s last measurement remains unchanged.
This pattern is consistent with a session-counter mismatch, but it is not the complete diagnosis. Correlate timestamps, identity and the network server’s rejection event. A different device or an unrelated packet can otherwise lead the investigation in the wrong direction. A gateway reception alone does not prove that the network validated or delivered the reading.
Dragino’s LoRaWAN communication debugging guide describes this ABP restart symptom and recommends comparing gateway and server traffic. Its discussion also includes relaxed counter checks as a workaround. For an operational monitoring system, retain replay protection and have the network administrator resolve the session lifecycle instead of making that workaround the permanent configuration.
A practical investigation checklist
1. Preserve the timeline. Record the last accepted uplink, maintenance or power event, first post-maintenance gateway reception and exact rejection message. Export relevant events before changing the device record. Keep root keys and session keys out of screenshots, ordinary email and shared troubleshooting notes.
2. Check the radio path separately. Confirm that traffic reaches the expected network server and device record. Record the regional plan and channel configuration. For an Australian installation, verify the intended AU915 configuration against the actual hardware variant and deployment plan; do not copy another region’s settings from an example.
3. Compare the session evidence. Note the activation mode and the counters exposed by the supported diagnostic interface. Check whether a new join succeeded, whether the device retained its session and whether an administrator recently restored a server backup or replaced a device record. Avoid changing several variables at once.
4. Choose an approved recovery path. For OTAA equipment, use the exact manufacturer and server procedure for establishing or restoring the appropriate session. For ABP equipment with lost state, escalate to the network administrator and manufacturer for a supported re-provisioning plan. Do not blindly set the server’s counter to zero while retaining old session material.
5. Prove the application has recovered. Observe several newly accepted uplinks, then confirm that the application stores fresh timestamps and plausible decoded values. Check the associated offline indication and notification path under an agreed test plan. Document the monitoring gap; a resumed stream does not recreate missing measurements.
Prevent a repeat during maintenance
Include restart behaviour in the commissioning acceptance criteria. On a test device or within an approved maintenance window, record the session state before and after a permitted restart and verify continued reporting. Do not interrupt a device that supports an operational alarm without arranging the required monitoring coverage.
Avoid repeated resets as a troubleshooting loop. They can destroy useful evidence and create more join traffic. The Things Stack documentation advises against unnecessary systematic rejoins during network failures. If several sensors fail together, investigate shared infrastructure and server events before treating each sensor as an independent hardware failure.
Close the job with a clear record of the cause, recovery method, retained security controls and post-recovery evidence. For future purchases, ask how the exact firmware preserves session state and what the supported recovery process is. That question is more useful than assuming a power cycle will always restore communications.
Sources and pictured product
Need help with your application?
For instrument enquiries, visit ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854. Include the model, firmware, activation mode and redacted event timeline.
For monitoring and automation projects, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Device and protocol integration must be confirmed for your application.
Comments