Re: [lp-wan] lpwan-overview comments
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 01 July 2017 18:15 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B57127136 for <lp-wan@ietfa.amsl.com>; Sat, 1 Jul 2017 11:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K02tQ72isn4m for <lp-wan@ietfa.amsl.com>; Sat, 1 Jul 2017 11:15:37 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F13C120454 for <lp-wan@ietf.org>; Sat, 1 Jul 2017 11:15:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB938BE77; Sat, 1 Jul 2017 19:15:35 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhLT3SIuKoZ8; Sat, 1 Jul 2017 19:15:34 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DEFF4BE64; Sat, 1 Jul 2017 19:15:33 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498932934; bh=0sObFrasZwCHJdH4Q9lTF5deFcG4TUV4DBHY3ST+Eo4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VAAJ8E+21cHRfX77B3DilrF5cPPHPgVLju5zr6S0ct99xmbT659qo/YmdQ4aA4GvK 68cxdyPGCAxSaQ/llnMEHW2IPXMJNGEniQr2P8ZP6X0I7JnQvmbzChNoV0O74OuGnx 25mpZu3OuHU8yVRH3w7paHw4etdLi9MH/swd8tdQ=
To: Alper Yegin <alper.yegin@actility.com>, lp-wan@ietf.org
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <E0AE5747-8F22-4E46-ABD8-5C55E821F9A1@actility.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie>
Date: Sat, 01 Jul 2017 19:15:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <E0AE5747-8F22-4E46-ABD8-5C55E821F9A1@actility.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sfjvKCuKjL7gQX5XOTNoWNmI8XSwupnKI"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/k-n9nmolplfi3v4siDg19DziINA>
Subject: Re: [lp-wan] lpwan-overview comments
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jul 2017 18:15:39 -0000
Hiya, On 28/06/17 08:05, Alper Yegin wrote: > 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. > I made that change. > > > > > > 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 So I just don't understand how that can be correct, sorry;-) A join-request is processed by a NS (or, in 1.1 a JS). There are very few of those, maybe 1 per n/w. There are many more device-types, which do mostly map 1:1 with AppEUIs. And the same device-types can be found in many networks. So the suggested text just seems incorrect to me. I'd say we're better to just stick with 1.0.2 terms tbh. Cheers, S. > > > > > Thanks Stephen. > > Alper > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >
- [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Laurent Toutain
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request அருண்பிரபு (arunprabhu)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Alexander Pelov
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Laurent Toutain
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell