LoRaWAN Class C End Devices: How to Implement Devices That "Need to Be Woken Up Anytime"

2026-10-01 09:59:21 · Views 1

Introduction

LoRaWAN is widely known for its features of "low power consumption, power efficiency, and occasional data reporting". However, there is a category of applications that are completely different — they need to be woken up by the server at any time: smart locks require remote unlocking, street lights need dimming at any moment, irrigation valves must be switched on and off according to instructions, and personnel positioning badges may need to trigger an alarm with one tap. This type of "downlink real-time performance" requirement corresponds to Class C among the three terminal types defined in the LoRaWAN specification. Choosing the wrong device class will either prevent downlink data from reaching the device, or drain the battery in just a few days.

1. Three Device Classes of LoRaWAN

The LoRaWAN specification defines three types of terminals: Class A, B and C. Their core difference lies in "when the device listens to the server":

‌Class A (Default, Bidirectional Communication)‌: The device stays in sleep mode most of the time. Only after actively uploading data will it briefly open two receive windows to wait for a response from the server. This is the most power-saving mode and the default choice for the vast majority of sensors — but it has a limitation: if the server wants to actively contact the device, it must wait for the device's next data upload.
‌Class B (Bidirectional, Scheduled Reception)‌: Based on Class A, the gateway sends down Beacon signals for time synchronization. The device periodically opens receive windows at fixed time points. The server can reach the device at the agreed time, but the device still needs to wake up periodically, with power consumption between Class A and Class C.
‌Class C (Bidirectional, Continuous Reception)‌: The device keeps the receive window open almost all the time. As long as it is not sending data, it is listening. The server can send down instructions at any time, achieving the lowest latency. The tradeoff is the highest power consumption, which basically requires continuous power supply or large-capacity batteries.

2. Applications That Must Use Class C

The judgment criterion is simple: whether "low-latency downlink" is required. Typical scenarios include:

‌Smart Locks‌: Remote unlocking, temporary authorization, and permission revocation. If the lock uses Class A, the server has to wait for the next heartbeat of the lock to complete unlocking, which makes the user experience completely unacceptable.
‌Remote Control Devices‌: Valves, relays, water pumps, fans, lighting — any device that "needs to respond immediately after an operation" requires Class C.
‌Personnel Positioning Badges (Alarm Linkage)‌: When an emergency occurs, the management end must immediately send an alarm or confirmation instruction to a specific badge. Waiting for the next heartbeat would be too late.
‌Devices Requiring Frequent Parameter Modification‌: For example, adjusting the collection frequency, triggering threshold on demand, or performing remote reset.

For pure reporting devices — such as temperature and humidity sensors, liquid level meters, and livestock ear tags (which only send several location reports a day) — Class A is sufficient. Forcing Class C on these devices will only waste power unnecessarily.

3. Costs and Precautions of Class C

Class C is not free of tradeoffs:

‌High Power Consumption‌: The receiver works continuously, with current usually at the milliampere level. Devices powered by button batteries can hardly last more than a few days. Therefore, Class C terminals usually require mains power, solar energy or large-capacity battery solutions. This is why many "remote control" products are designed with mains-powered versions.
‌High Gateway Pressure‌: Each Class C device continuously occupies downlink channel resources. The number of Class C devices that a single gateway can carry is far less than that of Class A. During deployment, a hybrid strategy of "sleep mode + wake-up" should be adopted, and only devices that truly require real-time performance are configured as Class C.
‌Power-saving Compromise Solution‌: Many manufacturers implement a "quasi-Class C" design — the device stays in Class A sleep mode normally. When control is needed, the platform sends a wake-up instruction. After waking up, the device briefly enters the continuous reception state to process the instruction, and then goes back to sleep. This is a practical balance between power consumption and real-time performance.

4. Suggestions for Product Design

First distinguish between "real-time" and "pseudo-real-time" requirements: unlocking is real-time, while modifying the reporting frequency is pseudo-real-time (which can wait for the next heartbeat). Only consider Class C for scenarios with true real-time requirements.
Determine power consumption based on the power supply method: use Class C if mains power or solar energy is available; for portable devices powered purely by batteries, prioritize the "wake-up" solution instead of forcing Class C.
Leave margin for gateway selection: if there are a large number of Class C terminals in the deployment, evaluate the gateway processing capacity and channel planning in advance, and partition the network if necessary.
Design the device class as an optional configuration: the same hardware supports A/C switching (via firmware or platform configuration), allowing customers to choose according to their deployment scenarios. This is a common practice for OEM products to improve adaptability.

Summary

Class C solves the problem of "whether the server can find the device at any time" in LoRaWAN, and it is a rigid requirement for products such as smart locks, remote controls, and emergency alarms. However, it trades power consumption and gateway resources for real-time performance, so not all devices should use it. A practical product solution is: most sensors use Class A to save power, while devices that truly require low-latency downlink use Class C, and reserve the switching capability on the hardware — granting the "ability to be woken up at any time" only to the devices that need it, so that both control requirements can be met, and the battery life and network capacity of the entire network can be guaranteed.