# Gateway Downlink Queue Management with V3 and Packet Broker **URL:** \ **Category:** LoRaWAN Discussions\ **Created:** [February 8, 2021, 9:49pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998 "2021-02-08T21:49:07Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [February 8, 2021, 9:49pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998/1 "2021-02-08T21:49:07Z")
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? ---
**Author:** ![htdvisser](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/htdvisser/32/45312_2.png) [@htdvisser](https://www.thethingsnetwork.org/forum/u/htdvisser)\ **Post date:** [February 10, 2021, 4:31pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998/2 "2021-02-10T16:31:41Z")
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. ---
**Author:** ![LanMarc77](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lanmarc77/32/35697_2.png) [@LanMarc77](https://www.thethingsnetwork.org/forum/u/LanMarc77)\ **Post date:** [February 21, 2021, 1:55pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998/3 "2021-02-21T13:55:46Z")
Hi, I looked (shortly!) at the packet broker API proto files and found: in routing\_services.proto: ![2021-02-21 14_49_40-api_routing_services.proto at master · packetbroker_api](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/d/1/d173636002d55080d897c85b5a003de1a6f3ad18.png) in enums.proto: ![2021-02-21 14_49_55-api_enums.proto at master · packetbroker_api](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/f/1/f13e109ed0d6ffdc4798e2b092bd49130d2c189d.png) 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. ---
**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\ **Post date:** [March 1, 2021, 4:51pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998/4 "2021-03-01T16:51:08Z")
> [@htdvisser](#): > > _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. They are not conveyed back to the Network Server for retry. The plan is to do that. > [@LanMarc77](#): > > 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. 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. ---
**Author:** ![LanMarc77](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lanmarc77/32/35697_2.png) [@LanMarc77](https://www.thethingsnetwork.org/forum/u/LanMarc77)\ **Post date:** [May 22, 2021, 7:18pm UTC](https://www.thethingsnetwork.org/forum/t/gateway-downlink-queue-management-with-v3-and-packet-broker/43998/5 "2021-05-22T19:18:45Z")
Hi there again, am I reading [this](https://github.com/packetbroker/api/commit/850b20fe590effeac635fc0ef5fd34eddca31a99) 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?