Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

From: Antti Ratilainen <[email-masked]>
Date: Wed, 1 Jun 2016 07:31:04 +0000

Hello Sri, all,

I noticed this discussion about NB-IoT and wanted to weigh in, as I'm working on these topics in Ericsson Research.
Inclusion of NB-IoT has been discussed in 3GPP and it is very much in their interest to have NB-IoT included as one of the considered technologies in this IETF's LP-WAN work.
During last meeting, 3GPP CT WG1 agreed to send the following LS to IETF: LS on consideration of NB-IoT as a target technology in the LPWAN BoF 
Can be found here from 3GPP site: http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/Docs/C1-163121.zip
Should be available soon also on IETF side.
In the LS, 3GPP informs that it is interested co-operate with IETF to ensure that efficient protocols for low power devices are developed and that 3GPP radio access technologies (such as NB-IoT, EC-GSM-IoT and Cat-M1 access) are considered in the LP-WAN discussions.
I don't think there is any reason to rule out NB-IoT as out of scope (any more than there is for SigFox for example). As was said, NB-IoT is viewed as one of the  significant accesses in the LP-WAN class and I believe such an integral part should be considered as a candidate for any improvements.  

Best regards,
Antti
	
-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 27. toukokuuta 2016 17:21
To: Yeoh Chun-Yeow
Cc: [email-masked]
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi Chun-Yeow,

NB-IOT is viewed as one of the dominant access in the LPWAN class and at least in the SP segment. AFAIK, the SDO standardizing NB-IOT is not asking IETF for any of these work items and so understanding the target access/customers for each of these work items and the timeline of adoption may be needed. Its important to identify the gaps, market (licensed/unlicensed; SP/Ent) and get the prioritization right. 

Sri

> On May 26, 2016, at 9:55 AM, Yeoh Chun-Yeow <[email-masked]> wrote:
> 
> Hi, Sri
> 
> Sorry for the interrupt. What you mean by "NB-IOT's own path"?
> 
> Regards,
> Chun-Yeow
> 
> On Thu, May 26, 2016 at 6:17 PM, Sri Gundavelli (sgundave) 
> <[email-masked]> wrote:
>> I very much look forward to this presentation from Benoit as well. 
>> Unless SIGFOX opens up the specs (at a protocol messaging level), 
>> this is a closed system and I'm not sure how much we can discuss 
>> about that access in IETF, both from legal and from guidelines point 
>> of view. We already know NB-IOT's own path and that mainly leaves 
>> LoRa which is yet to adopt IP and every single item here is tied to 
>> that.  In this sense and for broader applicability of this work, I hope to see SIGFOX specs.
>> 
>> Sri
>> 
>> Sent from my iPad
>> 
>> On May 25, 2016, at 10:32 PM, Alexander Pelov <[email-masked]> wrote:
>> 
>> Yes, indeed!
>> 
>> Thanks, Benoit, for the formal confirmation of your participation. 
>> You have the first slot on our technology list for the charter! :)
>> 
>> We could probably take the architecture description in its own draft, 
>> independent of CoSOL.
>> 
>> Best,
>> Alexander
>> 
>> 
>> Le 26 mai 2016 à 06:58, Pascal Thubert (pthubert) 
>> <[email-masked]> a écrit :
>> 
>> Fantastic news Benoit!
>> 
>> Defining abstract architecture elements is really useful to enable 
>> multiple technologies, as long as the mapping to the actual protocol 
>> elements is straightforward.
>> 
>> It will be good that the mapping is explicitly documented to avoid 
>> recurring questions.
>> 
>> Regards,
>> 
>> Pascal
>> 
>> Le 26 mai 2016 à 06:32, Benoît PONSARD (SIGFOX) 
>> <[email-masked]> a écrit :
>> 
>> Hi all,
>> 
>> I've just seen Laurent's email on architecture elements. I think his 
>> definition of the architecture elements is compatible with what 
>> Sigfox is doing (see the overall architecture attached). Names are 
>> different but main features seem to be quite equivalent.
>> 
>> I'm taking the opportunity of this email to confirm that Sigfox will 
>> attend the Berlin meeting and is ready to present its technology. I 
>> also confirm that, after the Berlin's meeting, we have in mind to 
>> allocate some human resources to contribute to the 6LPWA work, more 
>> actively that I'm currently doing up to now !
>> 
>> BR
>> 
>> BPS
>> 
>> 
>> 
>> 2016-05-25 11:26 GMT+02:00 Laurent Toutain
>> <[email-masked]>:
>>> 
>>> Hi,
>>> 
>>> 
>>> I agree for the radio gateway (aka BTS) but there is other gateways 
>>> in the system. We need to have a precise definition of the gateway  
>>> otherwise it will lead to a lot of confusion on the mailing list.
>>> 
>>> In draft draft-pelov-core-cosol-01 we propose the following definition:
>>> 
>>> We can identify three types of entities in a typical LP-WAN.  These
>>>   are:
>>> 
>>>   o  Node-F: far-reachable node, e.g. the end-point, object, device.
>>> 
>>>   o  Node-R: radio relay, bridging the LP-WAN radio technology to a
>>>      different medium (often a LAN or cellular WAN).
>>> 
>>>   o  Node-G: gateway node, interconnection between the radio-relay node
>>>      and the Internet.
>>> 
>>>   +--------+                      +--------+            +--------+
>>>   | Node-F | <-- LP-WAN radio --> | Node-R | <-- IP --> | Node-G |
>>>   +--------+                      +--------+            +--------+
>>> 
>>> 
>>> In LoRa point of view, node-G will be the network server.
>>> 
>>> Can we agree on the mailist list to a reference architecture with a 
>>> common name associated to each componments ?
>>> 
>>> Thanks
>>> 
>>> Laurent
>>> 
>>> On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor) 
>>> <[email-masked]> wrote:
>>>> 
>>>> We need to be sure to remember that one of the huge advantages to 
>>>> several of these network types (for instance LoRaWan) is the fact 
>>>> that the Gateway is very nearly stateless. This allows the operator 
>>>> to deploy in a very lightweight, cost effective manner. There is no 
>>>> session established between the end node (which I generally think 
>>>> of as a sensor) and the gateway, end nodes come and go (as seen by 
>>>> the Gateway), and ideally there is no end node state kept on the Gateway.
>>>> 
>>>> 
>>>> Bill VerSteeg
>>>> 
>>>> 
>>>> P.S. sorry for being late to the thread - I have been heads-down on 
>>>> a LoRaWan project and just now popped up for air.....
>>>> 
>>>> ________________________________
>>>> From: lp-wan <[email-masked]> on behalf of weigengyu 
>>>> <[email-masked]>
>>>> Sent: Tuesday, May 24, 2016 10:39 PM
>>>> To: Laurent Toutain; Pascal Thubert (pthubert)
>>>> 
>>>> Cc: [email-masked]
>>>> Subject: Re: [lp-wan] The compression problem: protocol dependant? 
>>>> if so, which protocol(s)?
>>>> 
>>>> Hi,
>>>> 
>>>> Probably, a basic problem is whether the smart object is treated as 
>>>> a independent IP node logically?
>>>> 
>>>> If yes, each smart node should have a IPv6 address no matter the 
>>>> address is kept in Gateway or in the node itself, no matter the 
>>>> address is compressed or not.
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Gengyu WEI
>>>> Network Technology Center
>>>> School of Computer
>>>> Beijing University of Posts and Telecommunications
>>>> 
>>>> From: Laurent Toutain
>>>> Sent: Tuesday, May 24, 2016 10:32 PM
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: [email-masked]
>>>> Subject: Re: [lp-wan] The compression problem: protocol dependant? 
>>>> if so, which protocol(s)?
>>>> 
>>>> Hi pascal,
>>>> 
>>>> Thanks for asking those questions.
>>>> 
>>>> On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) 
>>>> <[email-masked]> wrote:
>>>>> 
>>>>> Dear all:
>>>>> 
>>>>> 
>>>>> 
>>>>> In the most simplistic approach, which so far we have referred to 
>>>>> as the remote I/O, our new protocol would instruct the LPWAN AP/GW 
>>>>> to literally tunnel traffic from a certain device to another, 
>>>>> inserting IPv6, UDP and COAP over the MAC and APP protocols that 
>>>>> are present in the air. In that simplistic model, a simple source 
>>>>> MAC is all we have to determine a flow and at the extreme, the MAC 
>>>>> packet could be transported (even in its in is encrypted form) as 
>>>>> a CoAP payload. This could be compared with CAPWAP, which tunnels 
>>>>> the 802.11 frame to a controller which completes the .11 MAC process and bridges to Ethernet.
>>>> 
>>>> 
>>>> If I understand well we have the following architecture
>>>> 
>>>>    Object ~~~~~~ RADIO GW ======= LPWAN GW ======== LPWAN AP
>>>> 
>>>> For me CAPWAP is, in a sense, the equivalent of Packet Forwarder in LoRa.
>>>> The LPWAN GW is in charge of the MAC protocol, the radio gateway is 
>>>> transparent in a way that it sends on the radio everything the 
>>>> LPWAN GW sends with meta information indicating the channel to use, the coding,...
>>>> 
>>>> If I'm right, what you are talking about is more between the LPWAN 
>>>> AP and the LPWAN GW.
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> OTOH, a lot more may we achieved if the flow can be determined 
>>>>> with a granularity beyond the simple MAC address of the device.
>>>>> 
>>>>> Ideally, the flow would also be determined some other mac (aka 
>>>>> network) layer elements, and, to be determined, some app layer 
>>>>> elements; the insertion process would depend on all these elements.
>>>>> 
>>>>> This is quite important considering that when the expanded packet 
>>>>> is placed over an IP network, all the resulting processing by the 
>>>>> routing fabric - e.g. the Internet- will be determined from the inserted headers.
>>>> 
>>>> 
>>>> In my views the LPWAN AP is aware of the LPWAN network and so can 
>>>> adapt what are sent on the network and can use some specific 
>>>> protocols to signal information to the LPWAN GW.
>>>>> 
>>>>> 
>>>>> 
>>>>> The question becomes what can be signaled in the air protocol, 
>>>>> when the frame is encoded natively as app over mac:
>>>>> 
>>>>> -        Which keys can the AP/GW access (none, MAC/Network only?, do we
>>>>> cover the case where the GW is also an app level GW with the app 
>>>>> keys?)
>>>> 
>>>> 
>>>> The LPWAN GW does not have to get the key for app. which means that 
>>>> only the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed 
>>>> in
>>>> https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-c
>>>> ontext/?include_text=1 is to use a SHIM to refer to a compressed 
>>>> stack. The SHIM can be carried by
>>>> L3 or by L2 to optimize, which means that the LPWAN will have to 
>>>> send it separately to allow the LPWAN GW to insert it into L2 frame.
>>>>> 
>>>>> -        What in the air protocol is signed vs. encrypted
>>>> 
>>>> 
>>>> depends of MAC, it is not IETF business.
>>>>> 
>>>>> -        Taking the reasonable assumption the AP/GW is not an app level
>>>>> GW, is there room in the MAC format to store a app level (opaque 
>>>>> to the MAC) flow ID that the AP/GW can leverage for its insertion work?
>>>> 
>>>> 
>>>> That's why the SHIM may be important. The SHIM can be carried in 
>>>> Layer 3 protocol or Layer 2 protocol, so the 6LPWA working group 
>>>> can work on something  generic. Then when you instantiate for 6LPWA other foo.
>>>>> 
>>>>> -        Taking that assumption, can we live with a simple flow ID? What
>>>>> becomes of CoAP's Message ID and Token?
>>>>> 
>>>>> 
>>>>> 
>>>>> The capabilities that we can achieve depend on the answers to 
>>>>> these fundamental questions, which in turn may depend on the 
>>>>> protocols that we work on.
>>>>> 
>>>>> 
>>>>> 
>>>>> We can start guessing, playing the "what if?" game. But in truth, 
>>>>> we're pretty much stuck till we complete the protocol selection process.
>>>>> 
>>>>> 
>>>>> 
>>>>> We have cross-participated for a long while now; people from IETF 
>>>>> and LPWANs have exchanged and read specs, and the IETF has 
>>>>> published a candidate charter.
>>>>> 
>>>>> 
>>>>> 
>>>>> Now is a good time for candidate LPWANs to come out and so we all 
>>>>> kick off the work. And studying the questions above for the 
>>>>> selected protocols would be a great start.
>>>>> 
>>>>> 
>>>>> 
>>>>> Pascal
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lp-wan mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Laurent Toutain
>>>> +--- VoIP (recommended) ---+----------- Télécom Bretagne 
>>>> +-----------+
>>>> | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 |
>>>> Visit :
>>>> | Mob: +33 6 800 75 900    |                                        |
>>>> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
>>>> http://class.touta.in
>>>> | [email-masked]         | [email-masked]    |
>>>> +--------------------------+----------------------------------------+
>>>> 
>>>> ________________________________
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Laurent Toutain
>>> +--- VoIP (recommended) ---+----------- Télécom Bretagne 
>>> +-----------+
>>> | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 |
>>> Visit :
>>> | Mob: +33 6 800 75 900    |                                        |
>>> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
>>> http://class.touta.in
>>> | [email-masked]         | [email-masked]    |
>>> +--------------------------+----------------------------------------+
>>> 
>>> _______________________________________________
>>> lp-wan mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 
>> 
>> 
>> --
>> Benoît PONSARD
>> Director of Standardization
>> Mobile : +33 (0)6 84 74 70 71
>> www.sigfox.com
>> 
>> <Capture d'écran 2016-05-25 à 05.03.08.png>
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 1 Jun 2016 09:47:22 +0200

Dear Antti,

Thank you for bringing this out to our attention. We’ve never really ruled out NB-IoT, but we didn’t want to overstep our mandate. This is the reason we wanted the stakeholders to express their willingness for the IETF to do standardization work.

This LS seems like a great step in this direction! This means that we could include it as the second 6LPWA technology for our charter. 

What will be the next steps in this direction from your opinion? Do you see items of interest that we’re not currently covering in the proposed charter?

Best,
Alexander

> Le 1 juin 2016 à 09:31, Antti Ratilainen <[email-masked]> a écrit :
> 
> Hello Sri, all,
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 1 Jun 2016 17:16:02 +0000

Hi Antti,

Thanks for the update.

Trying to understand the CT1¹s view here. Not clear from the liaison
statement. Is CT considering the use of IETF protocols for as control/user
plane path ?  Some new NAS signaling  ? Can you provide some additional
comments on what work items will be of use from 3GPP point of view ? This
is for Release 13 ?

Regards
Sri

On 6/1/16, 12:31 AM, "Antti Ratilainen" <[email-masked]>
wrote:

>Hello Sri, all,
>
>I noticed this discussion about NB-IoT and wanted to weigh in, as I'm
>working on these topics in Ericsson Research.
>Inclusion of NB-IoT has been discussed in 3GPP and it is very much in
>their interest to have NB-IoT included as one of the considered
>technologies in this IETF's LP-WAN work.
>During last meeting, 3GPP CT WG1 agreed to send the following LS to IETF:
>LS on consideration of NB-IoT as a target technology in the LPWAN BoF
>Can be found here from 3GPP site:
>http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/Docs/C1-
>163121.zip
>In the LS, 3GPP informs that it is interested co-operate with IETF to
>ensure that efficient protocols for low power devices are developed and
>that 3GPP radio access technologies (such as NB-IoT, EC-GSM-IoT and
>Cat-M1 access) are considered in the LP-WAN discussions.
>I don't think there is any reason to rule out NB-IoT as out of scope (any
>more than there is for SigFox for example). As was said, NB-IoT is viewed
>as one of the  significant accesses in the LP-WAN class and I believe
>such an integral part should be considered as a candidate for any
>improvements.  
>
>Best regards,
>Antti
>	
>NB-IOT is viewed as one of the dominant access in the LPWAN class and at
>least in the SP segment. AFAIK, the SDO standardizing NB-IOT is not
>asking IETF for any of these work items and so understanding the target
>access/customers for each of these work items and the timeline of
>adoption may be needed. Its important to identify the gaps, market
>(licensed/unlicensed; SP/Ent) and get the prioritization right.
>
>Sri
>
>
>
>

---

From: Lorenzo Vangelista <[email-masked]>
Date: Thu, 2 Jun 2016 15:13:25 +0200

Hello Antti,

could you share with us the latest specification for NB-IoT (or a pointer to the 3GPP site
where to find them) ?

Many thanks in advance

Kind Regards

Lorenzo

> On 01 Jun 2016, at 09:31, Antti Ratilainen <[email-masked]> wrote:
> 
> Hello Sri, all,
>

---

From: Antti Ratilainen <[email-masked]>
Date: Thu, 2 Jun 2016 16:03:52 +0000

Dear Lorenzo,

The next 3GPP plenary meeting is in two weeks, and there the proposed changes from accepted Change Requests (CRs) to the actual specifications are approved. There is no separate specification or document for NB-IoT, but the specified information about NB-IoT will be contained in a set of specifications depending on the issue.
The latest Change Requests (CRs) about NB-IoT haven't yet been implemented in the 3GPP specifications, but good specification to start with is 36.300, which provides an overview and overall description of the E-UTRAN radio interface protocol architecture.
You can find the latest (agreed) CR to this specification with the introduction of NB-IoT here:
http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_94/Docs/R2-164415.zip
But as I said, this is still a CR, which isn't in the actual final specification yet (but it should be accepted to the final specification in the next 3GPP plenary if nothing goes wrong, as it is agreed upon).

Best regards,
Antti
	
-----Original Message-----
From: Lorenzo Vangelista [mailto:[email-masked]] 
Sent: 2. kesäkuuta 2016 16:13
To: Antti Ratilainen
Cc: [email-masked]
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)? --> specs of NB-IoT

Hello Antti,

could you share with us the latest specification for NB-IoT (or a pointer to the 3GPP site where to find them) ?

Many thanks in advance

Kind Regards

Lorenzo

> During last meeting, 3GPP CT WG1 agreed to send the following LS to 
> IETF: LS on consideration of NB-IoT as a target technology in the 
> LPWAN BoF Can be found here from 3GPP site: 
> http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/Docs
> /C1-163121.zip Should be available soon also on IETF side.
>>> We could probably take the architecture description in its own 
>>> draft, independent of CoSOL.
>>> 
>>> Best,
>>> Alexander
>>> 
>>> 
>>>>> that the Gateway is very nearly stateless. This allows the 
>>>>> operator to deploy in a very lightweight, cost effective manner. 
>>>>> There is no session established between the end node (which I 
>>>>> generally think of as a sensor) and the gateway, end nodes come 
>>>>> and go (as seen by the Gateway), and ideally there is no end node state kept on the Gateway.
>>>>> 
>>>>> 
>>>>> Bill VerSteeg
>>>>> 
>>>>> 
>>>>> P.S. sorry for being late to the thread - I have been heads-down 
>>>>> on a LoRaWan project and just now popped up for air.....
>>>>> 
>>>>> Probably, a basic problem is whether the smart object is treated 
>>>>> as a independent IP node logically?
>>>>> 
>>>>>> as the remote I/O, our new protocol would instruct the LPWAN 
>>>>>> AP/GW to literally tunnel traffic from a certain device to 
>>>>>> another, inserting IPv6, UDP and COAP over the MAC and APP 
>>>>>> protocols that are present in the air. In that simplistic model, 
>>>>>> a simple source MAC is all we have to determine a flow and at the 
>>>>>> extreme, the MAC packet could be transported (even in its in is 
>>>>>> encrypted form) as a CoAP payload. This could be compared with 
>>>>>> CAPWAP, which tunnels the 802.11 frame to a controller which completes the .11 MAC process and bridges to Ethernet.
>>>>> 
>>>>> 
>>>>> The LPWAN GW is in charge of the MAC protocol, the radio gateway 
>>>>> is transparent in a way that it sends on the radio everything the 
>>>>> The LPWAN GW does not have to get the key for app. which means 
>>>>> that only the LPWAN can compress IPv6/UDP/ULP. In fact what we 
>>>>> proposed in