Issue with multiple mDot's trying to join network at the same time.

Home Forums mDot/xDot Issue with multiple mDot's trying to join network at the same time.

Tagged: ,

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #15532
    Chad Goyette
    Participant

    I am in the process of “Burning in” 10 mDot prototype boards for an upcoming project. I have them all wired to the same power source for convenience but in doing this uncovered a potential issue. When I power up the devices they all turn on simultaneously and are all trying to join the network at the same time. When I look at the lora stats in the conduits AEP admin area I can see that all EUI’s have registered with that conduit. When the mDot’s start sending messages a small handful (4 out of 10 mDot’s) are coming into the conduit with the wrong EUI (duplicate of another connected mDot). Its as if two mDot’s got registered to the same address in the conduit. I did an experiment and powered all the devices on one at a time and this seemed to solve the problem.
    My concern is that when these devices are out in the field (Note: these devices are powered by a wall adapter i.e. no battery power) and there is a power outage, when the power comes back online all of these devices will be trying to join the network at the same time where this issue may show its self.
    Has anyone else experienced this and do you have any advice?

    #15536
    Jason Reiss
    Keymaster

    This issue is a result of the shared AppKey on all devices.
    This key is used to authenticate the Join Accept message. When the devices join at the same time, they will also open RX windows at the same time allow some of the devices to receive the Join Accept messages destined for another device/DevEUI.

    However, in the join request is a random 2-byte nonce value sent from the device. This value must be known on the device in order to create a valid session key. The RNG is seeded from an rssi reading on start-up.

    Since they all share the same AppKey they will also verify the Join Accept message and and create a session. But only if the device nonce values match on two devices will a valid session be created.

    Since the devices have accepted the same session info they will report with the same network address. This may cause an event to be marked with the DevEUI of another device but the message can only be authenticated if the session keys match.

    Do you have ACK enabled on the devices?
    How are you monitoring the messages coming into the Conduit, mqtt “up” or “packet_recv” event?

    If I attempt to join with multiple devices simultaneously I can get both to join and they are assigned the same NetAddr. However the session keys differ because of the nonce values, therefore only one has a valid session. When either device sends a packet only the “packet_recv” event was seen on the Conduit for both devices. The “up” event only happened for the authenticated device with the correct session key.

    A packet sent after the join requiring a downlink with ACK or network link check would allow the device to check if it has a valid session. If a response from the network is not received then the device should attempt the join again.

    Another option is to use unique keys for each device. The lora-query utility can be used to register devices with the network server.

    LoRa Network Server

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.