Is anyone successfully operating a gateway with a 2G cellular internet connection? I’m finding this is working fine for uplinks. Downlink ACKs also work when there is very little traffic on the connection. The moment the connection is busy the downlink ACKs miss their window. I guess this is probably to be expected because there is so little bandwidth available, but has anyone managed to work around this somehow?
My gateway has a gateway-bridge. I’ve tried pointing the gateway’s packet forwarder to the gateway-bridge in chirpstack instead, but same result.
Thanks 
You can try increasing RX window delay time: https://www.chirpstack.io/network-server/install/config/
# Class A RX1 delay
#
# 0=1sec, 1=1sec, ... 15=15sec. A higher value means ChirpStack Network Server has more
# time to respond to the device as the delay between the uplink and the
# first receive-window will be increased.
rx1_delay=1 # DefaultThanks Martin. I have previously tried increasing it, including all the way to 15. However, it is the packet-forwarder that is rejecting the downlink ACK, and I don’t think the delay is configurable in the packet forwarder. Even if I could increase the allowable delay in the packet forwarder, surely this would cause me to miss the end device’s receive window? I think the devices themselves would need to be programmed with a longer receive window, and the packet forwarder code modified to allow for this. Maybe I have misunderstood something?
Thanks
James
Time for downlink message (ACK) is computed by the server, not packet-forwarder, so you can increase it with server settings. It is also part of LoRaWAN specification and can be changed by mac-commands.
In other words:
I think the devices themselves would need to be programmed with a longer receive window
Yes.
… and the packet forwarder code modified to allow for this.
No.
Problem can be with your device which does not necesarilly have to support the mac-commands for this feature in which case you would have to adjust this manually, which is also questionable.
For over-the-air adjustment using mac-commands you need to have working downlink channel so the change can be sent to device in the first place, which may be a problem in your case - that way the change will never get to device and will never really increse.
There are more details to this, but I would suggest you to first try messing about with this feature and see how the device responds.
1 Like
Hi Martin - really appreciated your detailed response - thank you!
Putting aside for the moment making any change to the end devices, the bit I’m not getting is that if I don’t need to modify the packet-forwarder code to allow for a longer delay, how does it know to allow the longer rx1 delay? The values appear to be hard-coded in jitqueue.c
Regardless of the reason / mechanism for that and whether or not it works, I believe I am (also) falling foul of this bug in the packet-forwarder:
When I increase the delay in the network server to 5 seconds, restart the service and then re-test, the packet-forwarder is still rejecting downlinks that have a delay of less than 5 seconds.
Configuring the network server for a 5 second delay:
[network_server.network_settings]
# Class A RX1 delay
#
# 0=1sec, 1=1sec, ... 15=15sec. A higher value means ChirpStack Network Server has more
# time to respond to the device as the delay between the uplink and the
# first receive-window will be increased.
rx1_delay=5
Error in packet-forwarder log:
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=2055655192, packet=2053921987, type=0)
2055655192μs - 2053921987μs = 1.73 seconds
If I’m not mistaken the packet-forwarder should timestamp the packet with its local time when uplink is received on gateway. It is then forwarded to network server to check activation etc.
If required the server will schedule Class-A downlink message by increasing the same timestamp appropriately (according to your settings in network-server.toml and/or device-profile). It is then sent back to gateway’s packet-forwarder which should ACK if it can transmit in scheduled time.
Other than that I don’t know exact inner workings as I didn’t really have any (major) problems when changing delay parameter.