Multiple LinkCheckAns replies


(Huntc) #1

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:

  1. the margin is indicated only for the last LinkCheckReq received; and
  2. 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.

Thanks.


(Jac Kersing) #2

DAfter reading and rereading your message it is not clear to me: are you sending multiple replies to one uplink using different gateways?


(Huntc) #3

Sorry if it isn’t clear. The scenario 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.


(Jac Kersing) #4

Sounds like you are creating your own denial of service attack if you instruct two gateways to respond…

The node will only listen for data in two timeslots, if you transmit both replies in the same timeslot (RX1 for instance) the radio signals of both gateways will interfere and chances are neither signal can be received by the node. (The node listens at one frequency at one spreading factor, not multiple like a gateway).
If you transmit one response in RX1 and it is received the node will not open a receiving window in RX2 and as a result the node never receives the second response.

So unless you’re able to combine multiple responses in one packet (and I don’t think the current standard allows for that but I might be mistaken) multiple responses won’t work.


(Huntc) #5

Thanks. What you state makes sense.

Can you describe how other NSs manage this scenario? I presume that a single NS must 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?

Thanks.


(Jac Kersing) #6

Sorry, I don’t know how other NSs manage this, I haven’t implemented one myself. I know TTN waits a few hundred milliseconds after the first gateway reports a packet to allow other gateways to report the same packet before forwarding the packet with metadata (including gateway details) to the application. Probably the same mechanism is used for LinkCheckAns if that is currently implemented.
If you really want to know, the sources for V2 and V3 of the TTN back-end can be found on github.

On the node I haven’t used link checks (yet) so I haven’t given any thought to using the information.


(Huntc) #7

Thanks again. Now asking Semtech: https://lora-developers.semtech.com/knowledge-base/forum/viewthread/23/