Re: [lp-wan] lpwan-overview comments

[Stephen Farrell <[e-mail]>]

Hiya,

On 28/06/17 09:05, Alper Yegin wrote:
> 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.
> 

Given the stated milestones I guess that we should stick with
describing 1.0.2 in the WG overview draft.

Cheers,
S.

PS: I'll respond to the other mail in a bit.



> Alper
> 
> 
> 
> 
> 
>> On Jun 28, 2017, at 10:56 AM, Alexander Pelov <[e-mail]> 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 <[e-mail] <mailto:[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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
> 
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>