5 - Class B
This book explores in depth how to use Class B in end devices implementing LoRaWAN® 1.0.4. Class B mode enables the end device to receive downlinks at regular intervals. We teach you how to configure your end device to receive Class B downlinks using beacons and ping slots and best practices to follow to increase the chance of receiving downlinks while maintaining reasonable battery life.
Enabling Class B Mode
Listen for Beacons
Each gateway that supports Class B operations broadcasts a message, referred to as a beacon, once every 128 seconds. The use of beacons enables an end device to keep its internal clock synchronized with the network server as well as allowing end devices to detect a change to which gateway the beacon was received from, providing the gateway model supports adding gateway data to beacons.
Warning
Not all gateways support Class B mode. Gateways must have GPS to support Class B since GPS timing is used for the precise broadcast of the beacons. Choose gateways that have GPS and list Class B support listed in their datasheets to use Class B.
Timing of Beacons
The end device needs to calculate the precise moment the first beacon will be broadcast so that it can listen for the beacon. The end device should have already aligned its internal clock to the internal clock of the network server, as described in the prior section Request the Network Server Time. The network broadcasts beacons once every 128 seconds since its calculation of the start of the GPS epoch (January 6th, 1980, 00:00:00 UTC). The end device uses its synced internal clock to calculate when to begin listening for the first beacon. As shown in Figure 2, the end device must also consider the following adjustments that will need to be made:
-
a 1.5 millisecond delay (TBeaconDelay) to allow time for the gateway to begin broadcasting
-
a minor difference (TAccuracy) where the gateway broadcasts the message slightly earlier or later than expected. The gateway manufacturer should provide you with this timing. After the first beacon is received, the Prec field can be used to determine the maximum timing difference to expect in subsequent beacons, as described in section 13.5, ‘Beacon Precise Timing’ (page 70) of the LoRaWAN® Link Layer Specification v1.0.4.
Figure 1: Timing of beacons
Follow the guidelines in section 13.5, ‘Beacon Precise Timing’ (page 70) of the LoRaWAN Link Layer Specification v1.0.4 to find the full set of algorithms to use to calculate when to begin listening for the beacon.
Note
The end device will use the timing provided in each beacon to remain synced to the network server clock, as described in the upcoming section Processing and Using the Beacon. It then continues to listen for beacons at the appropriate times, always considering TBeaconDelay and the TAccuracy communicated in the previous beacon’s Prec field.
Data Rate and Frequency of Beacons
The frequency and data rate for receiving beacons will vary depending on the region where the end device will operate.
The default channel and data rate to use in regions with a dynamic channel plan are specified in the ‘Class B beacon and default downlink channel’ subsection for a given region in Section 2 of the RP002-1.0.4 LoRaWAN Regional Parameters specification.
Gateways broadcasting beacons to end devices in regions using a fixed channel plan employ frequency-hopping whereby the gateway broadcasts the beacon on each channel in a sequence, alternating between the channels on each broadcast. These regions all use a single default data rate. Find each region’s data rate and an algorithm to calculate the channel hopping sequence in the ‘Class B beacon’ subsection for the region in Section 2 of the RP002-1.0.4 LoRaWAN Regional Parameters specification.
Note
Check Section 1.3, ‘Regional Parameters Summary Tables’ (page 24) of the RP002-1.0.4 LoRaWAN Regional Parameters specification to find out if the region your end device will operate in uses a dynamic or fixed channel plan.
Handle Requests to Update the Frequency
The network server may request the end device update the frequency it uses to receive beacons by sending a new frequency using the BeaconFreqReq MAC command. Learn how to receive MAC commands in the Handling MAC Commands of the Receiving Messages Book. When the BeaconFreqReq MAC command is received, the end device must validate whether the new frequency is allowed by its radio. The end device then informs the network server of whether it can use the new frequency or not by sending the BeaconFreqAns MAC command back to the network server using a Class A uplink. Learn about sending uplinks containing MAC commands in the section Sending MAC Commands of the Sending Messages Book.
Details of the BeaconFreqReq and BeaconFreqAns MAC commands can be found in Section 12.2, ‘BeaconFreqReq’ (page 63) in TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification.
When the end device sends a BeaconFreqAns confirming it can use the new frequency, the network server will update the frequency it uses for sending beacons, and the end device must now listen for beacons on the new frequency. The new single frequency replaces any frequency-hopping algorithm currently in use.
The network server can request the end device return to its default frequency setting by sending a BeaconFreqReq MAC command with the Frequency field set to 0. After the end device responds confirming this is possible with the BeaconFreqAns command, it must either return to using the default frequency if it operates in a dynamic channel plan region, or the frequency-hopping algorithm for all other regions.