My understanding is that V3 increases all RX windows to at least 5 seconds, and Packet Broker effectively allows routing of traffic from a given gateway to multiple network server stack instances.
That leaves me curious about:
How are time-conflicting downlink transmit requests from distinct servers to the same gateway handled? Obviously, actual conflicts result in a rejection, but is it done in a way where the “loser” could instead route the downlink through another gateway that might have had an only slightly weaker uplink report and if it were on a different spreading factor or especially frequency than the packet conflicting in time, have it work? Or is fallback still not possible, such that if the ideal gateway is busy then downlink silently fails?
Are downlink requests queued in the infrastructure or on the gateway? Early packet forwarders could not handle a new downlink request when they already had one outstanding, so to enforce ordering no matter what the RX delay, packets were held in the network and only pushed to the gateway just before transmission, meaning that even the long join RX1/RX2 could conceivably not arrive at the gateway in time. Modern packet forwarders implement a “jit queue” and can accept multiple outstanding requests even out of order, theoretically permitting packets to be staged to the gateway as soon as generated, and the increased RX delays to truly be leveraged for reliability. But does the downlink mechanism in V3 and packet broker assume a packet forwarder with the jit queue? Does it have a way to check?
I can comment on the situation without Packet Broker.
The Gateway Server keeps a transmit schedule for each gateway. It will reject downlinks if (1) there is a conflicting transmission, (2) it would violate time-off-air (in applicable regions) or (3) it would violate the duty cycle (in applicable regions). Such a rejection is then communicated back to the Network Server, which will retry on the next gateway, and the next, etc.
The Gateway Server assumes that gateways have a JIT queue, but you can configure your gateway registration in The Things Stack with the “schedule downlink late” option if your gateway doesn’t have a JIT queue.
with Packet Broker, the Packet Broker Agent takes the role of Network Server, but I don’t know how rejections are handled by the Packet Broker Agent.
Hi, I looked (shortly!) at the packet broker API proto files and found:
in routing_services.proto:
in enums.proto:
If I interpret this right, the return values do not contain a denied option for a downlink route from packet broker to a forwarder. But I am pretty sure there is more to it…as always.
They are not conveyed back to the Network Server for retry. The plan is to do that.
Your interpretation is correct.
If there’s gonna be a notification back from the Forwarder that the downlink has been scheduled and transmitted, then it will be on a separate channel. I.e., the Forwarder will send a message with the updated message state, and we’ll be adding some error and success codes.
Hi there again,
am I reading this right that these are the (maybe first) steps needed to report a failed or successful downlink back to the sender allowing (later) some alternative routing options?
