Subject: [lp-wan] Proposed charter v3

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 24 Apr 2016 16:03:40 +0000

6LPWA: "IPv6 over Low-Power Wide-Area networks".

Background/Introduction:
------------------------

A new generation of Low-power and Lossy Networks (LLNs) has emerged under the
generic name of Low-Power Wide-Area (LPWA). From the variety of LPWA technologies
that is already proposed in this market, a number of common characteristics can
be gathered which make these technologies unique and disruptive for wireless
Internet of Things (IOT) applications.

Those common family traits include ultra low bit-rate and small frame sizes,
rare transmissions, specific radio modulations, and basic topologies. This
provides a significant improvement in range and battery lifetime, simplifies and
lowers the cost of deployments at large scale.

Those benefits come at a price: the MAC-layer formats are optimized and very
specific to each individual technology. There is no network layer and the
application is often hard wired to the MAC, leading to very silo'ed deployments,
managed, secured and operated individually. Migrating from one access technology
to another implies rebuilding the whole chain.

To unleash the full power of these new technologies and their new ecosystems,
there is a need to couple them with other ecosystems that will guarantee the
interworking at the network layer and enable common components for management
and security, as well as shared application profiles. The IETF can contribute
by enabling IPv6/UDP/COAP to the devices, and propose technologies to secure the
operations and manage the devices and their gateways.

Description of Working Group:
-----------------------------

The Working Group will focus on enabling IPv6 over selected Low-Power Wide-Area
technologies <tech1>, <Tech2> and <Tech3>, and will leverage cross-participation
with the associated set of stakeholders to ensure that the work taking place
corresponds to real demands and the proposed solutions are applicable.

The group will produce informational work describing LPWA technologies for IETF
consumption, best practice documents on using IETF technology in LPWA networks
directed to the selected partner bodies, and new standards work to optimize IPv6
operations to the device.

The WG will interface with other appropriate groups in the IETF Internet,
Operations and Management, and Security Areas.

Work Items:
-----------

The group will:

1. Produce an Informational document describing and relating existing LPWA
technologies. This document will highlight the common characteristics but will
not aim at providing a competitive analysis.

2. Produce best practice documents for security and management, highlighting
potential areas where IETF technologies may be leveraged; these documents may
eventually be published as Informational RFCs.

3. Produce Standard Track documents to enable the compression of IPv6 over LPWA.
Considering the extreme constraints, the work will focus on a generic YANG data
model to enable the compression, and protocols to install the related state
at the compression end-points; the work will also include, for the selected
technologies, specific Standard Track documents to describe how the fields
relevant to the decompression are encoded over the air, if any.

4. Produce a document to enable the fragmentation of larger packets over LPWA,
either as a Best Practice leveraging existing technology, or as new Standard
Track document if that is deemed necessary.

---

From: Randy Turner <[email-masked]>
Date: Sun, 24 Apr 2016 21:38:18 -0400

Hi Pascal,

Regarding the 2nd paragraph of the proposed charter

> lowers the cost of deployments at large scale.

It seems like it would be of some value to future participants in this work if this particular paragraph
provided examples of “small frame sizes” or “radio modulations” so that some idea of the challenges
of the working group could be understood.  I say this because this same paragraph could be used to talk
about 802.15.4 networks that we currently deploy (small frame sizes, specific modulations, low bitrate, battery/energy issues) 
but that exhibit none of the characteristics that I think
LPWANs will be faced with.

My $0.02 :)

Randy

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

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Sun, 24 Apr 2016 22:59:48 -0300

Pascal,
           Randy just got to the point I was going to mention:
We should clearly define our scope and differentiate from
other technologies which are already covered by groups
such as 6lo and 6tisch.
            I think the aim here is not to exclude candidate technologies
per se, but to provide better insight on which are the target
technologies we are going to work on, at least, on the first
version of the charter.
            Regards,

                                          Diego

2016-04-24 22:38 GMT-03:00 Randy Turner <[email-masked]>:

> about 802.15.4 networks that we currently deploy (small frame sizes,
> specific modulations, low bitrate, battery/energy issues)
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 07:04:38 +0000

Sure Randy:

I’m getting numbers like 100 bytes per day, 10 km range, 10 years on a coin cell as typical expectations. I think that the mostly upstream is also a key differentiator, a show stopper for balanced protocols.

I’m getting the same feedback from Paul and Diego. We need to differentiate from the domain were 6lo applies.

Note that all the text in the first section is really to justify that work is needed at the IETF. It is a helper for the BoF but may not make it to the final charter. The text that sets the boundaries of the LPWAN WG should be in the second section. Let me chew this and come back with  a proposal.

Cheers,

Pascal

From: Randy Turner [mailto:[email-masked]]
Sent: lundi 25 avril 2016 03:38
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lp-wan] Proposed charter v3

Hi Pascal,

My $0.02 :)

Randy

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

[email-masked]<mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 25 Apr 2016 10:09:00 +0300

Hello Dear Pascal,

Thank you for doing this, and please see below for my first round of
comments/recommendations.

> 6LPWA: "IPv6 over Low-Power Wide-Area networks".
Not sure if we really want to frame these technologies as "lossy", as some
of them do have reliability features.

generic name of Low-Power Wide-Area (LPWA). From the variety of LPWA
> technologies
It may be better to simply say that the over-the-air part of the stack may
not be using IP.
If we were to get into the pros and cons of doing that in the charter, the
discussion may expand unnecessarily.

> Description of Working Group:

It'd be good to start from identifying the problems first, before
discussing the solutions here. Solution work should be gated by the problem
statement, if we really want to make sure the IETF product is used.

> Track document if that is deemed necessary.
We'd need to nail down which technologies need that.

Alper

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Apr 2016 07:14:32 +0000

I agree with all comments Alper made below.

From: lp-wan [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: 25 April 2016 09:09
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [lp-wan] Proposed charter v3

Hello Dear Pascal,

Thank you for doing this, and please see below for my first round of comments/recommendations.

Background/Introduction:
------------------------

Not sure if we really want to frame these technologies as "lossy", as some of them do have reliability features.

It may be better to simply say that the over-the-air part of the stack may not be using IP.
If we were to get into the pros and cons of doing that in the charter, the discussion may expand unnecessarily.

Work Items:
-----------

The group will:

It'd be good to start from identifying the problems first, before discussing the solutions here. Solution work should be gated by the problem statement, if we really want to make sure the IETF product is used.

Alper

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Laurent Toutain <[email-masked]>
Date: Mon, 25 Apr 2016 09:36:15 +0200

Hi Pascal,

Thank you for this charter. I've two remarks:

1) rare transmissions => rare and sometime limited transmissions.

Duty cycle may interfere with some protocols

2) In the introduction the scope is more specifically made on IPv6/UDP/CoAP
 and in work item 3: only IPv6 compression is discussed.

We must also limit the solution scope otherwise it will be difficult to
find optimal solutions. For instance, in a first approach the group may
focus on star topologies and, in the future work, on star topologies.

Laurent

-- 
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]    |
+--------------------------+----------------------------------------+

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 25 Apr 2016 09:39:15 +0200

Dear Alper,

Thanks a lot for your comments! Please, see in-line.

> Le 25 avr. 2016 à 09:09, Alper Yegin <[email-masked]> a écrit :
> 
> Hello Dear Pascal,
> 

It is indeed an open question if we should keep the LLN designation to LPWAs. For me they are LLNs, in the same sense IEEE 802.15.4 is - frames are (could) be acknowledged, but this doesn’t make it a 99,9999% reliable L2 link.

> If we were to get into the pros and cons of doing that in the charter, the discussion may expand unnecessarily.

This is still in the technology overview part, e.g. the state of the art. Currently, most of the LPWA technologies are not using natively the IP stack (over-the-air or not), so I think the current text is accurate and necessary.

> Description of Working Group:

I completely agree with you here! Did you look at draft-minaburo-lp-wan-gap-analysis-01 and draft-gomez-lpwan-ipv6-analysis-00? I’d be happy to hear your input on the subject.

> We'd need to nail down which technologies need that.

Yes, indeed! This is one of the goals of selecting the 3 leading technologies to be considered. For me, there are two major technologies that do not currently support L2 fragmentation, one of which will surely introduce it soon (LoRaWAN), while the other most probably would rely on our work here (SIGFOX). 

We already have a starting document (draft-gomez-lpwan-fragmentation-header-01), so should one of the three identified base LPWA technologies need fragmentation, we could do specific work quite rapidly.

Best,
Alexander

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 07:47:38 +0000

Hello Alper:

I think I agree with your points, but do not have an easy answer. Let us go through the intent and then we’ll see how we can adapt the text.

Ø  Not sure if we really want to frame these technologies as "lossy", as some of them do have reliability features.

Not disputing this. Most LLNs do. The term is used to position the work in the IOT space at the IETF, as opposed to, say, Ethernet, which would be 6MAN type of activity.

LLN is a wide family. IEEE 802.15.4 TSCH used in 6TiSCH is considered an LLN though some variations of the technology exhibit 5 nines of reliability.

We can try to forge another term (getting LLN was a long hard road), or attempt to avoid using one. Maybe just using IOT. Would you have a suggestion?

Migrating from one access technology to another implies rebuilding the whole chain.

Ø  It may be better to simply say that the over-the-air part of the stack may not be using IP. If we were to get into the pros and cons of doing that in the charter, the discussion may expand unnecessarily

The fact that there is no IP is not a justification for placing IP in there (at least outside the IETF). We need to explain what the value is for taking that path. I’m open to different explanation, but we need something that we can use at the BoF. Because a central question will be why he IETF should even be involved?

Note that the first section is mostly a requirement section for use at the BoF, as opposed to the second section that is descriptive of the working group. As such, is not expected to make it to the final charter.

Do you have suggestions for replacement?

o   eventually be published as Informational RFCs.

o

Ø  It'd be good to start from identifying the problems first, before discussing the solutions here. Solution work should be gated by the problem statement, if we really want to make sure the IETF product is used.
It certainly is. Please note (and see Carsten’s comments) that the IETF is changing, and at present, our A-Ds are not so keen on spending a WG round on requirement drafts. Or accepting such a draft as an Informational RFC at the end of the process.

This is why I’m attempting a work item 1 which would be the support for what you’re asking here, in a form that will have value beyond a list of requirements and hopefully will pass the IESG (see RFC 7554).

Bottom line: we need to have at least one set of well-understood requirements before the WG is formed, and then we can gather more as we go using work Item 1. This charter will act as a first pass of requirements/problem-statement, all wrapped in one. My bet is that work item 3, when fully reviewed, is a well-understood requirement that TechX will be willing to adopt at some point. This is why it is critical to get feedback on that particular work item from the TechX stakeholders.

Which boils down to your last point:

Ø  We'd need to nail down which technologies need that.

Certainly, this is priority number one.

We need  people from TechX stakeholders to present themselves on this list, review the charter, and help us write the initial work items.

Cheers,

Pascal

Cheers,

Pascal

From: Alper Yegin [mailto:[email-masked]]
Sent: lundi 25 avril 2016 09:09
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lp-wan] Proposed charter v3

Hello Dear Pascal,

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

Alper

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Apr 2016 07:55:04 +0000

Hi Pascal

Lossy or not:

Ø  The point here is that these WAN technologies aim to be low power. Loss of packets is always an issue with wireless technologies but some of these radios offer functionality already at the link layer to deal with those. The question is whether, from a marketing point of view, some of these organizations recognize themselves and their work when we talk about lossy and low power networks.

Requirements and problem statements:

Ø  While I am not a huge fan of either document requirements work nor publishing those as RFCs I believe there is a bit of work that needs to be done to analyse which problems (related to specific low power WAN technologies) to focus on. Whether the analysis is written on the WG Wiki or put into a document I don’t really care but an honest assessment of WHO needs WHAT functionality would be good.

Ciao
Hannes

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 25 April 2016 09:48
To: Alper Yegin
Cc: [email-masked]
Subject: Re: [lp-wan] Proposed charter v3

Hello Alper:

>  It may be better to simply say that the over-the-air part of the stack may not be using IP. If we were to get into the pros and cons of doing that in the charter, the discussion may expand unnecessarily

o

Cheers,

Pascal

Cheers,

Pascal

From: Alper Yegin [mailto:[email-masked]]
Sent: lundi 25 avril 2016 09:09
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] Proposed charter v3

Hello Dear Pascal,

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

Alper

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 25 Apr 2016 10:06:59 +0200

Hi Hannes,

> Le 25 avr. 2016 à 09:55, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi Pascal
>  
> Lossy or not:
>  

I see your point here. This was one of the reasons for me supporting the 6LPWA ("six el-p way") name of the proposed group - so that people can readily identify our work. (I already can imagine the "Go the six el-p way" advertisements;). Will mentioning LLNs scare some of them? This remains to be seen. 

Honestly, personally I won’t insist on LLN, and the use of LLN seems justified. So, if the group feels that this should be removed, then we’ll do it.

> Ø  While I am not a huge fan of either document requirements work nor publishing those as RFCs I believe there is a bit of work that needs to be done to analyse which problems (related to specific…

100% with you on this! We already have solid base on which to build on (draft-minaburo-lp-wan-gap-analysis-01 and draft-gomez-lpwan-ipv6-analysis-00). I’d say that we should keep using the IETF way of doing this - drafts, which will (most probably) not result in RFCs, but which will help guide the process. 

Do you like this approach?

Best,
Alexander

>  
> Ciao
> Hannes
>  
> From: lp-wan [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
> Cc: [email-masked] <mailto:[email-masked]>
> From: Alper Yegin [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you._______________________________________________
> lp-wan mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Apr 2016 08:10:01 +0000

Hi Alexander,

I am normally not a big fan of terminology discussions but unfortunately these things matter more than we would like. I call when we used the term ‘smart objects’ to distinguish ourselves from all the generic Internet of Things (IoT) terminology fluff and now we have to explain that ‘Smart Object Architecture’ is really about ‘IoT Architecture’…

Regarding the analysis work I agree that these two documents (draft-minaburo-lp-wan-gap-analysis-01 and draft-gomez-lpwan-ipv6-analysis-00) are indeed a good starting point.

Ciao
Hannes

From: Alexander Pelov [mailto:[email-masked]]
Sent: 25 April 2016 10:07
To: Hannes Tschofenig
Cc: Pascal Thubert (pthubert); Alper Yegin; [email-masked]
Subject: Re: [lp-wan] Proposed charter v3

Hi Hannes,

Le 25 avr. 2016 à 09:55, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal

Lossy or not:

>  The point here is that these WAN technologies aim to be low power. Loss of packets is always an issue with wireless technologies but some of these radios offer functionality already at the link layer to deal with those. The question is whether, from a marketing point of view, some of these organizations recognize themselves and their work when we talk about lossy and low power networks.

Requirements and problem statements:

>  While I am not a huge fan of either document requirements work nor publishing those as RFCs I believe there is a bit of work that needs to be done to analyse which problems (related to specific low power WAN technologies) to focus on. Whether the analysis is written on the WG Wiki or put into a document I don’t really care but an honest assessment of WHO needs WHAT functionality would be good.

Best,
Alexander

Ciao
Hannes

Hello Alper:

Cheers,

Pascal

Cheers,

Pascal

Hello Dear Pascal,

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

Alper

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 25 Apr 2016 11:21:57 +0200

Hi Pascal, all,

First of all, thanks a lot for the proposed charter. Please find a few
comments below:

A.- Work item 1. As you mention, this work item would be similar to what
RFC 7554 was for 6TiSCH (and I assume, to some extent, also similar to
what RFC 4919 was for 6LoWPAN), wouldn't it add value and clarification to
 explicitly add "problem statement" in its description?

B.- WG name. I have the impression (totally subjective) that "6LPWA" is
still somewhat similar to a "6LoWPAN" typo, although it is better than
"6LPWAN". In this regard, I liked Alexander's earlier proposal "6WiDe",
even if it did not explicitly contain the "low-power" component. Building
on top of that, what about "6LPWide"?

C.- I second Carsten's comment about not using the LLN term. I would
suggest the following in the proposed charter:

    s/Low-power and Lossy Networks (LLNs)/low-power wireless networks

D.- I would suggest the following:

 OLD:
   Those common family traits include ultra low bit-rate and small frame
   sizes, rare transmissions, specific radio modulations, and basic
   topologies. This provides a significant improvement in range and battery
   lifetime, simplifies and lowers the cost of deployments at large scale.

 NEW:
   Those common family traits include ultra low bit-rate (as low as
   ~10-100 bit/s) and small frame sizes (with maximum payload size
   between ~10 and ~100 bytes), rare transmissions (e.g. ~0.1
   messages/minute), specific radio modulations, and basic topologies. This
   provides a significant improvement in range (up to ~10 km) and battery
   lifetime (~10 years), simplifies and lowers the cost of deployments at
   large scale.

E.- In the charter, shouldn't we talk about LPWAN instead of LPWA? In the
first sentence, the charter mentions low power and lossy "networks", so
for consistency, we should talk about LPWA "networks". Also this would be
similar to talking about "WLAN" instead of "WLA". However, if "LPWA" is
required for better compatibility with the candidate WG name of "6LPWA", I
would accept it.

Cheers,

Carles

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 13:24:34 +0000

Hello Carles:

Thanks  bunch for your comments! Please see below:

> RFC 7554 was for 6TiSCH (and I assume, to some extent, also similar to what
> RFC 4919 was for 6LoWPAN), wouldn't it add value and clarification to

I agree on the need.
What I'd like to describe in that WI is a doc that tells 1) what the LPWA technology is (not digging into the specifics of one particular techX) and 2) what are the actual needs the IETF could contribute to serve.
This should come from the selected LPWA stakeholders, the WG being the gear box to redistributed that into the IETF.
And yes, PS&R used to be the way we did it.  Trouble is that 'problem statement' and 'requirements' are loaded at the IETF and not too much in the positive way...

Proposal for the WI 1:

"

1. Produce an Informational document describing and relating existing some LPWA
technologies. This work will document the common characteristics and highlights
actual needs that the IETF could serve; but it is not an intention to provide a
competitive analysis. It is expected that the information contained therein
originates from and is reviewed by LPWA stakeholders, and that this WG may
leverage the resulting document to suggest new activity in other WGs.
"

> B.- WG name. I have the impression (totally subjective) that "6LPWA" is still
> somewhat similar to a "6LoWPAN" typo, although it is better than
> "6LPWAN". In this regard, I liked Alexander's earlier proposal "6WiDe", even
> if it did not explicitly contain the "low-power" component. Building on top of
> that, what about "6LPWide"?

Added to the list of candidates : ) Let's keep that in a separate thread.

>     s/Low-power and Lossy Networks (LLNs)/low-power wireless networks

To avoid saying low power twice, I mixed that proposal with others to get:
"
A new generation of wireless technologies has emerged under the generic name of
Low-Power Wide-Area (LPWA), with a number of common characteristics which make
these technologies unique and disruptive for Internet of Things applications.
"
Looks good?

Point taken, but it's not like we have an alternate handy. 
Please consider my response to Alper. I'm waiting on Alper's answer.

>    lifetime (~10 years), simplifies and lowers the cost of deployments at

I see that is a real improvement, though maybe too far on the other side of precision.
Could we convey this information in a more literate way?  
Also there's redundancy if we express frame/day, bit/s and frame size.

What about 

"
This enables a range in tens of kilometers, and a long battery lifetime, with 10
years of operation on a single coin-cell. This also simplifies the deployment at
a huge scale, and enables low costs for devices, infrastructure, and operation
"

> first sentence, the charter mentions low power and lossy "networks", so for
> consistency, we should talk about LPWA "networks". Also this would be

I think that outside the IETF, LPWA is the consecrated term... Back to the WG name, let's make that a thread. 

Cheers,

Pascal

> > A new generation of Low-power and Lossy Networks (LLNs) has emerged
> > under the generic name of Low-Power Wide-Area (LPWA). From the variety
> > of LPWA technologies that is already proposed in this market, a number
> > of common characteristics can be gathered which make these
> > technologies unique and disruptive for wireless Internet of Things
> > (IOT) applications.
> >
> > topologies. This provides a significant improvement in range and
> > battery lifetime, simplifies and lowers the cost of deployments at
> > large scale.
> >
> > Those benefits come at a price: the MAC-layer formats are optimized
> > and very specific to each individual technology. There is no network
> > layer and the application is often hard wired to the MAC, leading to
> > very silo'ed deployments, managed, secured and operated individually.
> > To unleash the full power of these new technologies and their new
> > ecosystems, there is a need to couple them with other ecosystems that
> > will guarantee the interworking at the network layer and enable common
> > components for management and security, as well as shared application
> > profiles. The IETF can contribute by enabling IPv6/UDP/COAP to the
> > devices, and propose technologies to secure the operations and manage
> > the devices and their gateways.
> >
> > The Working Group will focus on enabling IPv6 over selected Low-Power
> > Wide-Area technologies <tech1>, <Tech2> and <Tech3>, and will leverage
> > cross-participation with the associated set of stakeholders to ensure
> > that the work taking place corresponds to real demands and the
> > proposed solutions are applicable.
> >
> > The group will produce informational work describing LPWA technologies
> > for IETF consumption, best practice documents on using IETF technology
> > in LPWA networks directed to the selected partner bodies, and new
> > standards work to optimize IPv6 operations to the device.
> >
> > The WG will interface with other appropriate groups in the IETF
> > Internet, Operations and Management, and Security Areas.
> >
> > Work Items:
> > -----------
> >
> > The group will:
> >
> > 1. Produce an Informational document describing and relating existing
> > LPWA technologies. This document will highlight the common
> > characteristics but will not aim at providing a competitive analysis.
> >
> > 2. Produce best practice documents for security and management,
> > highlighting potential areas where IETF technologies may be leveraged;
> > these documents may eventually be published as Informational RFCs.
> >
> > Considering the extreme constraints, the work will focus on a generic
> > YANG data model to enable the compression, and protocols to install
> > the related state at the compression end-points; the work will also
> > include, for the selected technologies, specific Standard Track
> > documents to describe how the fields relevant to the decompression are
> > encoded over the air, if any.
> >
> > 4. Produce a document to enable the fragmentation of larger packets
> > over LPWA, either as a Best Practice leveraging existing technology,
> > or as new Standard Track document if that is deemed necessary.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 25 Apr 2016 16:16:51 +0200

Hello Pascal,

Thanks for your feedback and updates!

Please find below some more inline responses:

>> what
> What I'd like to describe in that WI is a doc that tells 1) what the LPWA
> technology is (not digging into the specifics of one particular techX) and
> 2) what are the actual needs the IETF could contribute to serve.

I agree with this scope.

> This should come from the selected LPWA stakeholders, the WG being the
> gear box to redistributed that into the IETF.
> And yes, PS&R used to be the way we did it.  Trouble is that 'problem
> statement' and 'requirements' are loaded at the IETF and not too much in
> the positive way...

I see...

> leverage the resulting document to suggest new activity in other WGs.

One minor comment here: can the last sentence be read as totally excluding
the new lp-wan WG ?

>> still
>> even

Yep :)

> these technologies unique and disruptive for Internet of Things

Looks good to me!

>> battery

Yes, I agree it is good to avoid being too precise, as it may result in
somewhat limiting ourselves. Something less "accurate" but still showing
the difference with the set of 6Lo(WPAN) L1/L2 technologies should work.

> a huge scale, and enables low costs for devices, infrastructure, and

Looks good to me!

>> for

OK!

Cheers,

Carles

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 26 Apr 2016 03:55:09 +0000

Pascal,

Couple of comments.

I’m wondering why the management/security related documents will be published only as informational specs. I think it may be bit premature to state that.  I think one of the key objectives of this effort should be about enabling LPWAN deployments. Compression and other optimization are great and can be the enabler for IPv6 adoption, but I think it makes sense to take a system architecture and address various protocol gaps. Those extensions may indeed come out as standards specs, or BCP/Informational specs and we do not know at this point.

YANG is a perfectly reasonable option. But, I’d state this bit more generically. “the work will focus on defining interfaces (Ex: YANG/CAPWAP, ..etc) for installing the needed states for realizing compression or other capabilities at the endpoints”

Sri

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 25, 2016 at 12:04 AM
To: Randy Turner <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Proposed charter v3

Sure Randy:

Cheers,

Pascal

Hi Pascal,

My $0.02 :)

Randy

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Apr 2016 08:01:29 +0000

Hello Sri
potential areas where IETF technologies may be leveraged; these documents may
eventually be published as Informational RFCs.
I'm wondering why the management/security related documents will be published only as informational specs. I think it may be bit premature to state that.  I think one of the key objectives of this effort should be about enabling LPWAN deployments. Compression and other optimization are great and can be the enabler for IPv6 adoption, but I think it makes sense to take a system architecture and address various protocol gaps. Those extensions may indeed come out as standards specs, or BCP/Informational specs and we do not know at this point.

<Pascal> Agreed, we have to continue the gap analysis effort. That's critical for the BoF. For the extensions, we'll have to define on a case by case where they happen, but if there is an existing WG that can be identified for a particular piece, then we'll propose the work there. In that case, the LPWAN Wg would produce the 'architecture' BCP that position things and ties them together, while the protocol elements would be done in the proper WG/Area.

YANG is a perfectly reasonable option. But, I'd state this bit more generically. "the work will focus on defining interfaces (Ex: YANG/CAPWAP, ..etc) for installing the needed states for realizing compression or other capabilities at the endpoints"

<Pascal> YANG is the IETF way to describe configuration data models and interaction model. I may be wrongs but it seems to me that CAPWAP could be used to implement that abstraction. And so could CoAP/CBOR. I think your point is already included in "and protocols to install the related state at the compression end-points;".

Take care,

Pascal

Sure Randy:

I'm getting numbers like 100 bytes per day, 10 km range, 10 years on a coin cell as typical expectations. I think that the mostly upstream is also a key differentiator, a show stopper for balanced protocols.

I'm getting the same feedback from Paul and Diego. We need to differentiate from the domain were 6lo applies.

Cheers,

Pascal

Hi Pascal,

provided examples of "small frame sizes" or "radio modulations" so that some idea of the challenges

My $0.02 :)

Randy

Background/Introduction:
------------------------

Work Items:
-----------

The group will:

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Apr 2016 10:14:02 -0400

Looking at the thread from this week charter v2,3,5, I see a number of names.
I see the majority of names are long-standing IETF participants.  It's
appropriate that when building a charter that we hear from experienced
IETF people about what is possible, but I'm concerned that it seems like
that's all we are hearing.

I am concerned that we don't have enough participation from the LP-WAN
makers.  I'm concerned that we have the same faces on the IETF "side" of IoT
and that we are burning them out, and that the IETF has limited resources to
spend on this.

Or to put it differently: given what I perceive as a lot money backing the
LORA and other LP-WAN stuff, it doesn't seem like those vendors are
storming the IETF gates for help to do doing something interoperable.

In the ROLL/LLN space we have seen serious lack of actual attempts to
interoperate --- most vendors are used to the entire vertical and do not
engage very well without side entities.   And that's when we have, in theory,
an interoperable layer-2 (802.15.4) with a number of available chipsets.

With LPWAN, we have market verticals which seem to include layers 1 through 5
with little interest in any commonality. I'm not seeing the market push
interoperation here at all.

Of those active, only ackl.io seems to be building actual hardware.
I naturally could be wrong, but my goal here is to know who else is
really participating?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jonathan Muñoz <[email-masked]>
Date: Tue, 26 Apr 2016 16:43:24 +0200

Hello Michael,

I understand your concern. We, Gridbee Communications, are looking to the
IETF for a technical solution. If that solution meets our requirements, it
will be considered for our future product. We are building hardware based
on IEEE 802.15.4-SUN for our products.

Jonathan Muñoz

-- 
Jonathan Muñoz
PhD student at Gridbee Communications & INRIA Paris
+33 (0) 6 59 05 93 83

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Apr 2016 08:27:39 +0000

Good analysis, Michael.

It would definitely be useful to reach out to various chip manufacturers to see what their needs are. Of course, those may change over time but I could imagine there is a lot to learn from such an interaction. I am just wondering who could actually do such outreach (since you need to have contact persons with chip manufacturers in the first place).

Ciao
Hannes

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 26 April 2016 16:14
To: [email-masked]
Subject: [lp-wan] lp-wan -- critical mass of implementers

Looking at the thread from this week charter v2,3,5, I see a number of names.
I see the majority of names are long-standing IETF participants.  It's appropriate that when building a charter that we hear from experienced IETF people about what is possible, but I'm concerned that it seems like that's all we are hearing.

I am concerned that we don't have enough participation from the LP-WAN makers.  I'm concerned that we have the same faces on the IETF "side" of IoT and that we are burning them out, and that the IETF has limited resources to spend on this.

Or to put it differently: given what I perceive as a lot money backing the LORA and other LP-WAN stuff, it doesn't seem like those vendors are storming the IETF gates for help to do doing something interoperable.

In the ROLL/LLN space we have seen serious lack of actual attempts to interoperate --- most vendors are used to the entire vertical and do not
engage very well without side entities.   And that's when we have, in theory,
an interoperable layer-2 (802.15.4) with a number of available chipsets.

With LPWAN, we have market verticals which seem to include layers 1 through 5 with little interest in any commonality. I'm not seeing the market push interoperation here at all.

Of those active, only ackl.io seems to be building actual hardware.
I naturally could be wrong, but my goal here is to know who else is really participating?

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 28 Apr 2016 12:04:52 +0200

Dear Hannes, Michael,

Thanks for bringing this subject. It is indeed very important to have the technology stakeholders to participate actively. We want to solve *real* issues and this requires *real* engagement from technology providers.

The chip manufacturers are working with solution providers and telecom operators (such as SIGFOX), or are part of alliances (such as Lora Alliance). They also participate in SDOs, such as IEEE. All three organizations have expressed interest in the mailing list. Several others are following closely the discussion, and have also expressed interest.

We have set the charter with three technology placeholders and we have set the end of May as a deadline for formal engagement from the potential institutions. Having a formal engagement does require synchronization among the stakeholders, and this takes time. (Pascal sent the official invitation in the beginning of the week)

I am in complete agreement with you. We don’t want to take energy away from other groups. This is one of the reasons we are going for a new group - so that new contributors can easily identify the place here LPWA work happens and can come (independently on the layer they are working on). 

Best,
Alexander

PS.
Just to bring a short clarification, and only because Michael mentioned it. ACKLIO is a pure software company. We are working with several hardware providers (end-devices, gateways, chip manufacturers), all of which want to see IP in LPWAs.

> Le 28 avr. 2016 à 10:27, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Good analysis, Michael.
> 
> From: lp-wan [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Michael Richardson
> To: [email-masked] <mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Apr 2016 13:32:58 +0300

Hi Michael,

> I see the majority of names are long-standing IETF participants.

While I do qualify for that, my involvement in this discussion is from the
other side of the fence, as a member of Actility (a founding member of the
LoRa Alliance).

I'm also active in the LoRa Alliance. I can tell you that there is interest
among the members to evaluate this work. I'll be arranging a call among
them to have a discussion around it. At the end of the day, whether this
work will be consumed by the Alliance or its individual members depend on
the final scope of the work and the deliverables. Which are all open now
and that's what we are discussing. Speaking on behalf of my own company, I
can say we are interested enough to spend cycles on participating in the
scope discussion. And probably that's all anyone can say at this point
anyways.

Hope this helps.

Alper

> It's

-- 
Alper E. Yegin
*Head of Standards, Actility*
*Chair of Security Task Force, LoRa Alliance*
*Vice-Chair of Strategy Committee, LoRa Alliance*