LoRa specifications, variing definitions of DevAddr

LoRaWAN LoRaWAN Discussions
1

Hi,
right now LoRa 1.0.3 and 1.1 are published as well as LoRa backend interfaces v1.0:
https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf
https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf
https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf

LoRa 1.0.3 and 1.1 are specifying quite different formats of DevAddr. Version 1.0.3 (see 6.1.1 End-device address) defines:
NwkID[31…25] | NwkAddr [24…0]
without a proper explenation what NwkID or NwkAddr should look like.

LoRa 1.1 uses a different definition (6.1.2.1 End-device address):
AddrPrefix [31…32-N] | NwkAddr [31-N…0]
with N=[7…24]

LoRa backend interfaces 1.0 uses (see 13 DevAddr Assignment):
TypePrefix | NwkID | NwkAddr
All three fields can have varying lengths, but this format still matches the LoRa1.1 DevAddr definition. The TypePrefix + NwkID are components of the AddrPrefix as it is defined within LoRa 1.1 spec.
NwkAddr between LoRa 1.1 spec. and backend spec. are the same.

The specification for the backend defines a DevAddr which is compatible to LoRa 1.1 but not with LoRa 1.0.3 . It is also clear, that the definition of NwkID differs between LoRa 1.0.3 and LoRa1.1 / Backend1.0.
Are the different LoRa versions are really using incompatible or formats of DevAddr or am I missing some detail?
Also, the backend specification mentions, that some roaming modes are possible with LoRa 1.0 but also only the LoRa 1.1 DevAddr is mentioned within the backend specification. How can one use roaming with LoRa 1.0 if the defined DevAddr seems incompatible?

Well folks, that’s it. I would have liked a more structured question, but quite now my brain is fried from reading LoRa specifications…

2

Two things to keep in mind here:

  1. In all of these it’s a 32-bit number. What varies are the details of how that number is assigned. But in terms of the on-air protocol, it is simply an arbitrary number.

  2. This is the TTN forum, so “roaming” doesn’t really happen within the scope of the forum, since TTN is a single database of devices - you move between gateways, but not between networks.

3

Digital data transmissions are always carrying numbers around, therefore your statement is correct… In most cases these numbers are pretty senseless unless a protocol is applied to extract information out of all those 1s and 0s ;). My problem is, I do have a protocol which specifies how to generate / handle a specific 32bit number and on the other hand nobody seems to care. Everbody frankensteins the LoRa 1.0.x protocol to some form of LoRa 1.1 DevAddr handling o.O
Which is problematic if one wants to implement a proper network stack.

And yes, this is TTN and you don’t roam, but you know the protocol ;). Also a little idea: If the behavior of DevAddr is well defined, it should be possible to build gateways, which can handle more than one network. So one can deploy a gateway for his own, private network and could also handle messages for TTN.

4

That is already possible and implemented.

Actually the TTN standpoint is that roaming is a non starter. Search google for LoRaWAN and roaming. The first results should be Johan’s view on LoRaWAN roaming.