Keep alive interval (PULL_DATA) operation with Class A


When using Class A on end devices does the keep alive interval configuration in GW’s really serve a purpose? It seems that the keep alive interval drives PULL_DATA for the GW to poll the Server for TX data. However, in operation for Class A if the Server has a message queued it does not produce a PULL_RESP from the server to the GW until the GW pushes data which opens up a downlink RX window.

I’ve done some experimenting with keep alive times. I have a test system with 1 minute node Uplink data and my keep alive time set to 5 minutes. If I queue a downlink immediately after my last node UL then at the next UL interval I see the server schedule DL via PULL_RESP as a result of the GW PUSH_DATA. I never see a DL in response to PULL_DATA.

Can I make keep alive interval arbitrarily large say 24 hours to reduce backhaul traffic?


I believe it is not really the purpose to “pull” data, but to ‘poke holes’ when behind a NAT or firewall (as UDP is stateless, the gateway needs to send data periodically to make sure that downlink data is routed through the firewall or NAT).

Note that the Gateway Bridge will also unsubscribe from the gateway MQTT topics when it does not receive any of these periodical packets from the packet-forwarder.


As usual, thanks for the prompt response Orne. Thanks for the clarification.

Per my analysis using TCPDUMP the PULL_DATA/PULL_ACK keep alive polling results in 72 UDP bytes over cellular backhaul at whatever keep alive is programmed into each GW. The GWs I’ve purchased all showed up with a 10 second keep alive interval which means that the cellular backhaul is 622.08Kbytes a day or 18.7 Mbytes/month just for this keep alive.

Given your description how far can I reduce the keep alive polling rate so that the Gateway Bridge running on my server (not on the GWs) will not unsubscribe as you describe? Is the unsubscribe period configureable?



Yes, please see your global_conf.json or local_conf.json packet-forwarder config file:

The MQTT unsubscribe happens after one minute and is (currently) not configurable: