Knowledge Base
HOME » KNOWLEDGE BASE » FORUM

Multiple LinkCheckAns replies

I’ve implemented a LoRaWAN Network Server (NS) and recently incorporated support for LinkCheckReq and LinkCheckAns. I’m interested to learn how other NSs go about reporting LinkCheckAns, and share the approach I presently have.

LinkCheckAns is a reply sent by an NS containing a “margin” to indicate signal strength (normalised as the last received LinkCheckReq signal to noise ratio with demodulation base) and a count of the gateways that received it.

My approach is to send a LinkCheckAns for each LinkCheckReq at a gateway i.e. multiple answers to the same request. The reasons for this are twofold:

* the margin is indicated only for the last LinkCheckReq received; and
my NS is built on the approach that downlink messages should be forwarded to a packet forwarder asap, and that the packet forwarder takes care of the receive window schedule.
With the above approach, a device could then build up a clear picture of margins per gateway, which is then subsequently optimised for.

* The spec itself doesn’t appear to have detail about whether LinkCheckAns should be sent out multiple times so I feel that what I have is at least spec compliant. However, I’m interested in the approaches that other NSs have taken.

The scenario then is one sensor, two LoRaWAN gateways, both gateways connected to the one NS on another machine. The sensor’s LinkCheckReq is received by both gateways and thus twice at the NS. The NS accordingly responds twice as described.

Can you describe how other NSs manage this scenario? I presume that a single NS could wait a short period of time before sending out its answer so that it can collect info on the number of gateways the link check request was received at. If so then what should that wait time be?

Also, the spec states that the last margin should be sent along with the number of gateways. How can a node make use of this info?