Bug in downlink size handling?

Hi,

I’ve noticed some problems handling large downlinks on both v2 and v3 of TTN.
I’m testing in the AU915 region, so I don’t know if these issues apply elsewhere.

On v2:

  • TTN seems to accept downlinks of arbitrary size, and actually tries to send them to the gateway.
  • So if you queue a maximum size downlink (say, 53 bytes at SF12 in AU915) it will send
  • BUT, if there are MAC commands pending, they will be added to the packet, making it oversize
  • My gateway happens to transmit the oversize packets happily, so long as they are <= 255 bytes
  • But my devices reject oversized packets, for technical reasons
  • Obviously this is a standards compliance issue, but the v2 stack is sunsetting, so it will resolve with a bit of time

On v3:

  • TTN seems to know that a maximum packet size exists, and will keep an oversize downlink queued until the DR allows it to be sent
  • However, while an oversize downlink is in the queue, confirmed uplinks will not be acknowledged
  • And more critically for me, the maximum sizes seem to be wrong
  • At SF12/500 in AU915, I’m measuring a maximum of 28 bytes, instead of 53 bytes
  • At SF7/500 in AU915, I’m measuring a maximum of 217 bytes, instead of 242 bytes

You shouldn’t use confirmed uplink anyway - downlinks are too expensive to burn one for such purpose. If you really need a rare confirmation, do it at application level with extreme care, not crudely at link level.

At SF12/500 in AU915, I’m measuring a maximum of 28 bytes, instead of 53 bytes

Realistically, long downlinks are a bad idea

You shouldn’t use confirmed uplink anyway

Agreed. Just mentioning it because its broken. And some devices will use a confirmed uplink to force pending sticky mac commands to be acknowledged, and therefore stop taking up space in subsequent uplinks.

Realistically, long downlinks are a bad idea

Agreed. But long downlinks are sadly essential to support Semtech’s latest LR1110 chip, which consumes large almanac files. And if you have to downlink something, you want to use the largest downlinks you can, because the overhead of sending a LoRaWAN packet is on the order of 32 bytes for an empty payload. So its important that the network be able to send the specified MTUs - or devices will have to waste resources probing the MTU.

Looks like part of the problem is a clerical error in the regional parameters.

The pkg/band/au_915_928.go uses the repeater compatible frame sizes from the older regional parameters, which are:

[59 59 59 123 230 230 230 0 41 117 230 230 230 230]

or in payload size:
[51 51 51 115 222 222 222 0 33 109 222 222 222 222].

But, the 33 and 109 are a mistake - the editor seems to have subtracted 20 from all of the repeater-incompatible numbers, instead of just subtracting it from the largest payload sizes. This mistake is corrected in the latest regional parameters, where the sizes appear as:

[51 51 51 115 222 222 222 0 53 129 222 222 222 222].

However, 53 and 222 are still both 5 bytes larger than the MTUs I’m measuring.
So I suspect there is a further calculation error somewhere.

Looks like 5 is the difference between a MACPayload and a PHYPayload size.
I suspect the problem is here: lorawan-stack/downlink.go at 9100f50012bc8acd27e18286e109cda690d11d98 · TheThingsNetwork/lorawan-stack · GitHub

Just because a technology exists doesn’t mean TTN supports that rather demanding use case or long downlinks to enable it; you still have a pretty restrictive use policy to think about.

which consumes large almanac files

That’s where you start to need to think about a more viable multicast scheme than the spec yet really envisions

some devices will use a confirmed uplink to force pending sticky mac commands to be acknowledged

dubious - MAC commands typically interact with MAC commands, not the confirm/ack bits

In case anyone googles this later, I’ve opened issues

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.