Re: [lp-wan] lpwan-overview comments

Hi Alex,

No, they’d not.
Btw, the I-D is based on the LoRaWAN 1.0.2.
And we are working towards publishing the LoRaWAN 1.1 in September.
Depending on the pace of IETF processing this I-D, it may stay with LoRaWAN 1.0.2 details, or an update may fold in LoRaWAN 1.1 changes as well.

Alper

> On Jun 28, 2017, at 10:56 AM, Alexander Pelov <a@ackl.io> wrote:
> 
> 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 <alper.yegin@actility.com <mailto:alper.yegin@actility.com>> 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
>> lp-wan@ietf.org <mailto:lp-wan@ietf.org>
>> https://www.ietf.org/mailman/listinfo/lp-wan
> 