For LoRaWAN class B, is it possible to acknowledge uplink confirmed packets in class B ping slots? or it should be in RX1/RX2 class A receive windows? It seems to me that ping slots in class B are reserved for network-initiated downlink packets, however acknowledging uplink packets should be in RX1/RX2 as specificed for class A. This issue
imho TTS doesn’t support LoRaWAN class B.
Class A confirmed uplinks will be ACKed in a Class A downlink (RX1 or RX2) by The Things Stack. If you use Class B (or Class C) with The Things Stack, you may receive MAC commands or application payloads in the Class B slots (or anytime with Class C), but not ACKs to confirmed uplinks.
That could be another argument for skipping the very airtime-wasteful LoRaWAN confirmed traffic scheme and doing one’s own more strategic confirmation scheme at application level. Not only can the scope of when an ACK is due then be customized, and the path through to the data consumer verified, and the retry strategy tuned, but then in theory the class B slots could be used for the ACK.
The LoRaWAN specification still very confusing concerning this issue. I need to know what happen at the end-device ad netServer implementation level to confirm that acknowledging an uplink packet in class B is not restricted to class A receive windows RX1/RX2 and my happen time ping slots? Do you have any reference to clarify that?
Hylke just explained that you will NOT receive confirmed uplink ACKs in the class B slots.
But confirmed uplink is extremely inefficient and you probably should not use it on TTN anyway, at least not more than very rarely, or you will quickly exceed the fair usage policy for downlinks.
I was suggesting that if you built your own confirmation and retry mechanism at application level, rather than using the one that’s part of the LoRaWAN protocol, then you could get confirmation in the class B slots - but this would be your own system, as far as LoRaWAN is concerned the packets would be unconfirmed traffic, it’s just that your data consumer would sometimes inject a downlink back that provided some progressive confirmation, hopefully of more than just a single packet at a time.
1 Like
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.