Re: [lp-wan] lpwan-overview comments

[Alexander Pelov <[e-mail]>]

Thanks for the comments and the detailed review, Alper!

I guess the changes you describe are not likely to be changed until the specs you describe get published, right?

Thanks again,
Alexander


> Le 28 juin 2017 à 09:05, Alper Yegin <[e-mail]> a écrit :
> 
> 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
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan