Class B support

[johanstokking]

Summary:

Class B devices should be supported

Why do we need this?

To support Class B devices and make end customers happy

What is already there? What do you see now?

No class B support

What is missing? What do you want to see?

Class B support

How do you propose to implement this?

According to the spec

Notes:

• In class C, there is a timeout within which the device can respond to downlink traffic (i.e. MAC answer, downlink ack). During this time, NS may not send other downlink. This is not specified for class B; i.e. there is no requirement for the device to answer downlink traffic in ping slots before the next ping slot, and there is no requirement for the NS to hold traffic while the device has not responded. When implementing this, we may want to consider confirmed downlink (so that the device responds per spec, before the next ping slot), like we do with class C. Background here: https://github.com/TheThingsNetwork/lorawan-stack/pull/412#discussion_r270765410

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/833 by @rvolosatovs

[johanstokking]

@rvolosatovs can you make a plan for this?

[rvolosatovs]

Couple of things are required: a. Possibly add fields to MAC state, which NS would use for timing b. Possibly implement BeaconTiming MAC (deprecated in 1.0.3+) c. Utilize the class B slot in processDownlinkTask d. Account for class B slot in e.g. nextDataDownlinkAt (and so properly time downlink tasks)

Is time synchronized between gateways connected to the stack? Does GS have any control over it?

How does NS schedule the class B downlink? Do we let GS be responsible for actual timing of the downlinks? NS can express the timing as the delay after the beacon - I suppose that is the cleanest, since NS has no knowledge of gateway time. (but we need all gateways to have synced clocks I suppose for correct operation)

[johanstokking]

b. Possibly implement BeaconTiming MAC (deprecated in 1.0.3+)

Class B was experimental in LoRaWAN <= 1.0.2. I think we should;

• implement it for 1.0.3 and 1.0.4
• see if 1.1 is like 1.0.3 or 1.0.4, and if not, reconsider if we should support Class B in 1.1
• implement it for 1.1.1 (when it comes out)

Is time synchronized between gateways connected to the stack? Does GS have any control over it?

How does NS schedule the class B downlink? Do we let GS be responsible for actual timing of the downlinks?

Gateways they are assumed to have absolute time synchronization via GPS. You can use absolute_time in TxRequest and GS will figure it out. Note that the comment on that field is wrong; ping slots are also in absolute time slots.

NS can express the timing as the delay after the beacon - I suppose that is the cleanest, since NS has no knowledge of gateway time. (but we need all gateways to have synced clocks I suppose for correct operation)

I think in fact everything is GPS time based.

[rvolosatovs]

So gateways autonomously send the beacon then, we assume that all beaconing gateways are in sync and so NS just uses the absolute time

[johanstokking]

Yes

[rvolosatovs]

I think I should be able to get a working prototype in a week or so. Do we have a class B device available for testing?

[pffreitas]

This would be great! 👍

[carlosgarbiatti]

+1

[kanocarra]

Would be extremely useful please

[rvolosatovs]

Some progress is made in https://github.com/TheThingsNetwork/lorawan-stack/pull/1611 Unfortunately, Kerlink Wirnet station gateway refuses to send class B beacons and until I get my hands on an actual beaconing gateway to test this I don't think I can continue. For the very curious/brave with access to a beaconing gateway - you can try bdbf7a677 - any input would be very welcome and helpful at this point! I have an example mbed-os class B device here: https://github.com/rvolosatovs/mbed-os-example-lorawan-class-b/commit/dd98eb4fb5ae8b761c4c14d3b1048a8adf4305f6