The DevAddr is short, how many sensors can there be in a given network ID ?

The DevAddr is short, how many sensors can there be in a given network ID ?

The DevAddr is very short, and the actual addressing space is even shorter considering that the first 7 bits are reserved for the network identifier allocated by the LoRa alliance. In a first analysis, this seems to imply that LoRaWAN networks have a small addressing capacity which i obviously a problem for IoT.

But there is a trick:

Actually the LoRa network server can dis-ambiguate multiple sensors that have the same DevAddr short address, because each sensor has its own NwkSkey.

When the server (LRC) receives a frame from DevAddr D with message integrity code MIC, it first looks up its sensor database and finds potentially several devices, uniquely identified  by their IEEE DevEUI long address, that are associated with DevAddr D. For example it finds :
- DevEUI_1 (NwkSkey_1)
- DevEUI_2 (NwkSkey_2)
- DevEUI_3 (NwkSkey_3).

The server then computes the MIC of the received packet for each NwkSkey_x : it obtains MIC_1, MIC_2, MIC_3.

Only one MIC_x will match with the MIC present in uplink packet : the sensor associated with the correct NwkSkey.

This allows the server to identify the proper DevEUI, even in case of short address collision between multiple devices.

You will notice that in the Actility implementation of LoRaWAN, the provisioning system will reject a new sensor if it has the same DevAddr and NwkSkey than an existing one. You can also notice that in the tunnel API and in general all APIs of the network server, we use the long IEEE DevEUI : this is because the network server has resolved the ambiguity of DevAddr, and indicates the correct DevEUI.

This trick, which expands the usable addressing space of the LoRaWAN, has been patented by Actility.

    • Related Articles

    • Product Version 5.0.1 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v5.0.1. Version 5.0.1 subcomponents versioning Version 5.0.1 list of new introduced features (User Stories) and release notes for all ThingPark ...

    • Product Version 6.0 - Software Release Notes

              Versions  Version Date Author Details Rev1 2019-07-25 Actility First Version. Rev2 2020-01-07 Actility - Addition of “Feature Interaction Matrix” for each feature. - Updated the Feature Activation details for LRC record/replay tools Rev3 ...

    • Product Version 4.3 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v4.3. Version 4.3 subcomponents versioning Version 4.3 list of new introduced features (NFR’s) and release notes for all ThingPark software components ...

    • Product Version 4.2 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v4.2. Version 4.2 subcomponents versioning Version 4.2 list of new introduced features (NFR’s) and release notes for all ThingPark software components ...

    • Product Version 5.1 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Wireless Product Software v5.1. Version 5.1 subcomponents versioning Version 5.1 list of new introduced features (User Stories) and release notes for all ThingPark ...