LinkCheckAns payload content

Home › Forums › Lora Network Server › LinkCheckAns payload content

Tagged: 

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • June 19, 2018 at 11:26 am #23891
    Piotr Diop
    Participant

    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

    June 19, 2018 at 11:59 am #23898
    Jason Reiss
    Keymaster

    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?

    June 20, 2018 at 4:51 am #23915
    Piotr Diop
    Participant

    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
Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.