[lp-wan] lpwan-overview comments

[Alper Yegin <[e-mail]>]

Dear LPWAN WG members and Stephen,

I made one more pass over the LoRaWAN section of the I-D and spotted the following points:


   A LoRaWAN network has a short network identifier ("NwkID") which is a
   seven-bit value.  A private network (common for LoRaWAN) can use the
   value zero.  

   If a network wishes to support "foreign" end-devices
   then the NwkID needs to be registered with the LoRA Alliance, in
   which case the NwkID is the seven least significant bits of a
   registered 24-bit NetID.  (Note however, that the methods for
   "roaming" are defined in the upcoming LoRaWAN 1.1 specification.)

   In order to operate nominally on a LoRaWAN network, a device needs a
   32-bit device address, which is the catenation of the NwkID and a
   25-bit device-specific network address that is assigned when the
   device "joins" the network (see below for the join procedure) or that
   is pre-provisioned into the device.


In the LoRa Alliance we made a change to the way DevAddrs are generated based on the NetIDs. It’s no longer simply using the 7 least-significant-bits of NetID as the 7 most-significant-bits of the DevAddr. Even though the generation scheme was already described in the LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit value, hence it did not matter how that value was generated as far as the end-device is concerned. The new scheme, which allows more efficient allocation and use of NetIDs, is described in the Backend Interfaces spec, which is not published yet.

What that means is, in this I-D, we better not describe "NwkID=7 bits” detail. 

So, I’d  propose to rewrite the above 3 paragraphs as follows (further text massage welcome!):


   In order to operate nominally on a LoRaWAN network, a device needs a
   32-bit device address, that is assigned when the
   device "joins" the network (see below for the join procedure) or that
   is pre-provisioned into the device.  In case of roaming devices, the device address
   is assigned based on the 24-bit NetID that is allocated to the networks
   by the LoRa Alliance. Non-roaming devices can be assigned device addresses
   by the network without relying on a LoRa Alliance-assigned NetID.







   End-devices are assumed to work with one or a quite limited number of
   applications, identified by a 64-bit AppEUI, which is assumed to be a
   registered IEEE EUI64 value.



AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it identifies the JS.
JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the latest definition of the AppEUI in LW1.0.2 is as follows:



The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies

the entity able to process the JoinReq frame.

 
So, we better not treat it as application identifier, but as identifier of the entity that can authenticate the Join-request frames.

For example, instead of:

AppEUI	IEEE EUI64 naming the application

We better say:

AppEUI	IEEE EUI64 naming the entity that processes Join-request




Thanks Stephen.

Alper