Hello forum, I’m wondering if I can throw out a really broad question regarding LoRaWAN Class B.
I’ve never had the need to use it before as A and C have always sufficiently covered use cases. However, I’ve just started trying to understand Class B since, from a distance, the features offered look almost intruiging. However, on first reading (version 1.0.x) it seem like there is plenty of scope for things to go weirdly wrong.
A summary of my concerns:
- It appears to work against the Aloha approach of random timing backoffs to avoid collisions.
- It doesn’t address a major Achilles heel, device clock drift, except for with vague lines like,
The end-device LoRaWAN layer takes into account the maximum possible clock drift in the scheduling of the beacon reception slot and ping slots.
- It allows for unpredictable device behaviour with variable ping slots and offers no limits here(block qoute below). I know this last one is kinda the problem of the Application layer and makes Class B comparable to LTE-M1/NBIoT eDRX Mode, but it adds complexity and I’m wondering how it work in the wild - with all it’s wonderful edge cases.
Based on the beacon strength and the battery life constraints, the end-device application selects a ping slot data rate and periodicity, this is then requested them [sic] from the end-device LoRaWAN layer.
- It could well push up bandwidth usage, especially in good signal, full battery scenarios.
- I don’t like the term “Beacon” when refering to the end device in this mode
Really curious if anyone ended up relying on Class B for any amount of time. Any comments appreciated.