LinkCheckAns payload content

[Piotr Diop]

Hi,
From LoRaWAN 1.0.2 spec:

The gateway count (GwCnt) is the number of gateways that successfully received the last
LinkCheckReq command.

Based on that, how can the MTCAP (FW 1.4.16, Network Server 2.0.19) sometimes answer more than 1 ? Here’s an example of the mac command sent in response to my end device requesting LinkCheckReq:
lora/xx-xx-xx-xx-xx-xx-xx-xx/mac_sent {“appeui”:”yy-yy-yy-yy-yy-yy-yy-yy”,”deveui”:”xx-xx-xx-xx-xx-xx-xx-xx”,”gweui”:”zz-zz-zz-zz-zz-zz-zz-zz”,”opts”:”021102“}

Thanks

[Jason Reiss]

The uplink would need to be received on two channels with the same sequence number. Or received twice with the same sequence number and eliciting a downlink. Normally the network server will ignore a repeat packet with a LinkCheckReq, but if it was a confirmed packet an ACK would be generated.

What frequency was the packet received on?
Are there multiple packet_recv messages being output to MQTT?

Is the LinkCheckReq being added to a confirmed uplink?
Is that uplink being retransmitted because of missed ACK?

[Piotr Diop]

You’re right ! The behavior is due to having same sequence number in the linkcheckReq and it comes from the fact that my end device reboots in the early boot sequence.

In detail, the failing case goes as follows:
0) The linkCheckReq is set so the linkcheckReq is set for every Tx.
1) My end device joins the network
2) The 1st packet it sends is a confirmed packet + linkcheckReq with a given {fcnt:”N”, seqn:N”}
3) Mac command is answered with {opts:”02xx01} (so far so good)

Then due to software issue the end device reboots and the above sequence repeats.
So MQTT gets mac_recv with {id:”2″} and the exact same fcnt and seqn.
So network server must think this is a repeat packet but since this happens to be an ACK one, it has to answer with {opts:”02xx02}

Thanks for detailed answer !

[Author]

Posts