Experience with or opinions off LoRaWAN Class B?

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:

  1. It appears to work against the Aloha approach of random timing backoffs to avoid collisions.
  2. 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.

  1. 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.

  1. It could well push up bandwidth usage, especially in good signal, full battery scenarios.
  2. I don’t like the term “Beacon” when refering to the end device in this mode :grin:

Really curious if anyone ended up relying on Class B for any amount of time. Any comments appreciated.