Keep alive interval (PULL_DATA) operation with Class A

Gateways
1

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?

2

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.

3

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?

Thanks.

4

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:

https://github.com/brocaar/lora-gateway-bridge/blob/master/internal/gateway/backend.go#L27

1 Like
5

Hi @brocaar

First of all thanks for this amazing stack! I’m also baffled by your amazing community support. :slight_smile:

Quick question about the keepalive_interval: How high can this interval be without losing the MQTT connection? Is this a MQTT setting? Or does the GW bridge decide when to close the connection without data?

André

6

The keepalive_interval is related to the UDP “connection”. As UDP is state-less and your gateway might be behind a NAT, this will make the gateway send periodic “keep-alive” UDP packets to “keep the UDP connection open”, so that your NAT / router knows to which internal IP incoming UDP data must be routed.

Unless there is a reason for it, I would leave it to 10 seconds.

2 Likes
7

Merci. So that’s a matter of UDP traffic between the forwarder and the GW bridge?

8

Yes, that is correct. See also: