Device classes

ThingPark supports all the LoRaWAN® device classes, they are described below:

• Class A devices: All end-devices must implement this class.

  • This class offers the lowest power consumption, it is suitable for applications that require only downlink communication from the server shortly after the end-device has sent an uplink transmission.
  • Each uplink transmission from the device is followed by two short receive slots, known as RX1 and RX2 slots and used to receive potential downlink frames.
  • Downlink communications from the server at any other time will have to wait until the next uplink initiated by the end-device.

• Class B devices: Ideal class for battery-powered actuators requiring latency-controlled downlinks.

  • In addition to Class A receive windows, Class B-enabled end-devices open extra receive windows at scheduled times (also known as ping slots).
  • In order for the end-device to open its receive window at a scheduled time, it receives a time-synchronized Beacons from base stations. Beacons are sent every 128 seconds by default.
  • When used in a multicast group context, multicast downlinks are transmitted to the group of end-devices according to the selected ping slot period. To learn more, see Multicast group.

• Class C devices (Continuously listening): Ideal class for battery-powered actuators requiring minimal latency in downlink communication.

  • Class C-capable end-devices allow nearly continuously open receive windows, which are closed only when transmitting. The device can receive downlink frames at any time as long as it is not transmitting an uplink frame.
  • Class C-enabled end-devices use more power to operate than Class A or Class-B-enabled, but they offer the lowest latency for communication between servers and end-devices.
  • When used in a multicast group context, multicast downlinks can be transmitted at any time to the group of end-devices. To learn more, see Multicast group.

The following table explains the main characteristics of each class of device and gives examples of use cases that you may need to implement to your IoT network.

Device Class	Characteristics	Examples of Use Cases
Class A (Baseline)	All devices support Class A mode. This mode is very suitable for battery-powered devices. No specific prerequisite on base station. Not available for multicast group.	Most smart metering applications without stringent downlink latency constraints (no actuation): meter readings, etc.… Tracking use cases Smart agriculture, Smart city (for instance, smart parking…)
Class B (Beacon)	Optional mode, a class-B capable device can dynamically switch between class A and class B modes. Base stations should transmit Beacon signals to synchronize devices. Base station time synchronization by GPS is mandatory in this release. Available for multicast group.	IoT applications implying device actuation such as shut-down gas meters or water meters’ valve. Multicast applications (the same downlink frame is sent to many end-devices at the same time).
Class C (Continuously listening)	This mode is only relevant for mains-powered devices, as opposed to battery-powered devices for class A. The device can receive downlink frames anytime while it is not transmitting an uplink frame. No specific prerequisite on base station the side. Available for multicast group.	Street lighting applications with mains-powered end-devices Multicast applications (the same downlink frame is sent to many end-devices at the same time)