Subject: [lp-wan] Proposed charter v2

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 24 Apr 2016 14:50:18 +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 collaborate with that set of
stakeholders to ensure that real demands are being served 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 requirements 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 24 Apr 2016 14:53:17 +0000

Dear all

Please note that by berlin, techX X in 1..3 will be identified, so a placeholder is fine for now.

Cheers,

Pascal

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: dimanche 24 avril 2016 16:50
> To: Juan Carlos Zuniga <[email-masked]>; Alexander Pelov <[email-masked]>;
> Paul Duffy (paduffy) <[email-masked]>; Mischa Dohler
> <[email-masked]>
> Cc: [email-masked]
> Subject: [lp-wan] Proposed charter v2
> 
> 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.
> 
> 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.
> 
> The Working Group will focus on enabling IPv6 over selected Low-Power
> Wide-Area technologies <tech1>, <Tech2> and <Tech3>, and will collaborate
> with that set of stakeholders to ensure that real demands are being served
> 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.
> 
> technologies. This document will highlight the common characteristics but
> will not aim at providing a competitive analysis.
> 
> 2. Produce requirements 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.
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Apr 2016 17:28:18 +0200

As I said, I don't like a complicated, unpronouncable name.

Doing an LPWA survey might be useful, but sounds like one of these
efforts where it is always hard to summon enough energy to complete
them.  What's the point?

A "requirements" document is a non-starter.  Are we talking about an
architecture here?  That might indeed come with objectives, but we don't
want the "requirements engineering" game.

I'm not sure I understand the compression deliverables: You want a YANG
model for installing compression state, and then technology-specific
compression formats?

Segmentation ("fragmentation") might indeed be technology-specific.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 24 Apr 2016 15:55:31 +0000

Hello Carsten:

Let's agree on what we want done, and then we'll look at the exact wording - which is still bound to change between now and Berlin.

> As I said, I don't like a complicated, unpronouncable name.
Yes, we need a specific thread on the name. There were a number of proposals with pros and cons.

* LPWAN: great for IETF consumption but wrong from the outside, seems like IETF claims it owns the technology
* 6LPWAN: too close to 6LoWPAN.
* 6WIDE: not specific enough to LPWA

...

At 6TiSCH, we ended up with a poll.

> Doing an LPWA survey might be useful, but sounds like one of these efforts
> where it is always hard to summon enough energy to complete them.
> What's the point?

An image of what is desired there is what RFC7554 is for 6TiSCH. 
A place for the IETF community to find what LPWA is about in our terms.

> want the "requirements engineering" game.

Yes, at 6TiSCH the architecture plays that role. But we are not building a full architecture here are we?
As opposed to the previous document, this (or these) one is for people participating to the external communities to educate the IETF on their needs. 
The idea would be to aggregate and organize the needs at this WG, and then use the documents to interface with other IETF WGs and ask for work there.

> model for installing compression state, and then technology-specific

Yes. Some technologies may want a plain encapsulation, put all the data inside a constant CoAP wrapper.
Some others may have existing fields that the compression may leverage in some fashion, like a port number maps in a URI.
This is certainly technology dependent and within one technology, there might be several things doable at the expense of different costs.

> Segmentation ("fragmentation") might indeed be technology-specific.
If it is fully technology-specific, then nothing for us to do. But the 6LoWPAN work indicates that there's a possibility, to be evaluated.

What do you think?

Pascal

> >> To: Juan Carlos Zuniga <[email-masked]>; Alexander Pelov
> >> <[email-masked]>; Paul Duffy (paduffy) <[email-masked]>; Mischa Dohler
> >> 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.
> >>
> >> 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
> >> Wide-Area technologies <tech1>, <Tech2> and <Tech3>, and will
> >> collaborate with that set of stakeholders to ensure that real demands
> >> are being served 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.
> >>
> >> 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 24 Apr 2016 16:02:41 +0000

All:

I agree with Carsten that the term requirement in item 2 is inadequate. 
I'll replace it with best practice and repost.

Cheers,

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: dimanche 24 avril 2016 17:28
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Juan Carlos Zuniga <[email-masked]>; Alexander Pelov <[email-masked]>;
> <[email-masked]>; [email-masked]
> Subject: Re: [lp-wan] Proposed charter v2
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Apr 2016 18:09:31 +0200

> At 6TiSCH, we ended up with a poll.

6Tisch is pronouncable.  sixloppwa isn't.

> A place for the IETF community to find what LPWA is about in our terms.

I don't object to this, I just have a grim prognosis on its success.

> Yes, at 6TiSCH the architecture plays that role. But we are not building a full architecture here are we?

I'm not sure I know what a "full architecture" is.  We are talking about
an architecture that combines a hard-state state management protocol
with a compression scheme based on that state management.  Enough of an
architecture if you ask me.

> The idea would be to aggregate and organize the needs at this WG, and then use the documents to interface with other IETF WGs and ask for work there.

That all sounds good. What we need to avoid is that proponents of a
specific solution start to fight about the "requirements" in order to
have their solution look better.  (I see that you are getting rid of the
word "requirement".)

> This is certainly technology dependent and within one technology, there might be several things doable at the expense of different costs.

Good, just wanted to make sure I read this right.

> If it is fully technology-specific, then nothing for us to do. But the 6LoWPAN work indicates that there's a possibility, to be evaluated.

Even if it is technology-specific, it still needs to be standardized.

Grüße, Carsten

---

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

> 6Tisch is pronouncable.  sixloppwa isn't.

: )

> > As opposed to the previous document, this (or these) one is for people
> participating to the external communities to educate the IETF on their
> needs.
> > The idea would be to aggregate and organize the needs at this WG, and
> then use the documents to interface with other IETF WGs and ask for work
> there.
> 
> That all sounds good. What we need to avoid is that proponents of a specific
> solution start to fight about the "requirements" in order to have their
> solution look better.  (I see that you are getting rid of the word
> "requirement".)
> 

Well item 2 now covers " best practice documents on using IETF technology in
LPWA networks directed to the selected partner bodies " which is indicated in
the previous section of the charter. But I'm still after a vector to funnel needs
from external bodies to other WG via this WG. Maybe it's item 1?

Take care, 

Pascal

---

From: Alexander Pelov <[email-masked]>
Date: Sun, 24 Apr 2016 18:27:44 +0200

I'd pronounce it "six El-P way"

Best,
Alexander

Le 2016-04-24 18:21, Pascal Thubert (pthubert) a écrit :
>> specific

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Apr 2016 19:04:11 +0200

>> sixloppwa

Let me update that to "sloppwa".

Pronouncable, but maybe not the right connotation :-)

Grüße, Carsten

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Sun, 24 Apr 2016 17:18:35 -0400

I personally never heard of any issues with LP-WAN (or 6LPWAN for that matter). 
I found it fairly descriptive and pronounceable. 
Yes, WAN is close to PAN and LAN, but I assume those interested can tell the difference ;)

Juan Carlos

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Apr 2016 23:53:34 +0200

LP-WAN is a fine term for the overall field of technology.

It is not a good IETF WG name for two reasons:

1) 6LPWAN looks to much like 6LWPAN.  Don't do that.

2) LP-WAN indeed is a fine generic term.  But we need a *new* name,
googleable, distinct, with some recognition that this is a *new*,
*specific* initiative.

Enough on this subject; to some extent this really is a matter of taste,
but also a matter of different objectives in naming this activity.

Grüße, Carsten

PS.: While we are debating terms, can we get rid of "LLN"? This is
neither well-defined, nor does it fit to what the LP-WAN people are
actually trying to do.

---

From: Mischa Dohler <[email-masked]>
Date: Mon, 25 Apr 2016 12:53:19 +0100

+1

______________________________________

Prof Mischa Dohler
Head, Centre for Telecom Research
Chair Professor, King's College London
Board of Directors, Worldsensing
Editor-in-Chief, ETT & IoT
Fellow, IEEE

www.mischadohler.com
______________________________________

On 24/04/2016 22:53, Carsten Bormann wrote:
> While we are debating terms, can we get rid of "LLN"? This is

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 12:02:10 +0000

Hello Mischa:

I’m getting a strong sense here, but then, what would we use instead? You know from your ROLL years that LLN is a consecrated term at the IETF for IOT links.
I can see WSN, “low power radio” … any suggestion?

Pascal

From: Mischa Dohler [mailto:[email-masked]]
Sent: lundi 25 avril 2016 13:53
To: Carsten Bormann <[email-masked]>; Juan Carlos Zuniga <[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]>; [email-masked]; Pascal Thubert (pthubert) <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: Re: [lp-wan] Proposed charter v2

+1

Prof Mischa Dohler

Fellow, IEEE

www.mischadohler.com<http://www.mischadohler.com>

actually trying to do.

---

From: Mischa Dohler <[email-masked]>
Date: Mon, 25 Apr 2016 13:18:42 +0100

Dear Pascal,

Could we just not use it at all? Carsten I believe proposed dropping the 
term instead of using a substitute.

(If all fails, using it is not the end of the world ...)

Thanks and with kind regards, Mischa.

On 25/04/2016 13:02, Pascal Thubert (pthubert) wrote:
>
> Hello Mischa:
>
> I’m getting a strong sense here, but then, what would we use instead? 
> You know from your ROLL years that LLN is a consecrated term at the 
> IETF for IOT links.
>
> *From:*Mischa Dohler [mailto:[email-masked]]
> *Sent:* lundi 25 avril 2016 13:53
> *To:* Carsten Bormann <[email-masked]>; Juan Carlos Zuniga 
> <[email-masked]>
> *Cc:* Paul Duffy (paduffy) <[email-masked]>; [email-masked]; 
> Pascal Thubert (pthubert) <[email-masked]>; Alexander Pelov 
> <[email-masked]>
> *Subject:* Re: [lp-wan] Proposed charter v2
>
> +1
>
> www.mischadohler.com <http://www.mischadohler.com>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 12:42:11 +0000

Trying; what about:

“
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 data collection
applications.

Those common family traits include frame sizes in tens of bytes and the order of
a few transmissions per day, a mostly upstream transmission pattern over a basic
star topology, and an optimized radio modulation.

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 operations.

<…>
“

Cheers,

Pascal

From: Mischa Dohler [mailto:[email-masked]]
Sent: lundi 25 avril 2016 14:19
To: Pascal Thubert (pthubert) <[email-masked]>; Carsten Bormann <[email-masked]>; Juan Carlos Zuniga <[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]>; [email-masked]; Alexander Pelov <[email-masked]>
Subject: Re: [lp-wan] Proposed charter v2

Dear Pascal,

Could we just not use it at all? Carsten I believe proposed dropping the term instead of using a substitute.

Pascal

From: Mischa Dohler [mailto:[email-masked]]
Sent: lundi 25 avril 2016 13:53
To: Carsten Bormann <[email-masked]><mailto:[email-masked]>; Juan Carlos Zuniga <[email-masked]><mailto:[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>; Alexander Pelov <[email-masked]><mailto:[email-masked]>
Subject: Re: [lp-wan] Proposed charter v2

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.

---

From: Mischa Dohler <[email-masked]>
Date: Mon, 25 Apr 2016 13:46:27 +0100

Very good! Thanks, Pascal.

PS: I don't want to stir troubles here but I see downstream (actuators, 
drones, robots, mems telemetry, etc) as an equally massive opportunity 
which is slowly emerging. Unless the emphasis has to be on upstream here 
(I have skipped a few email exchanges over past weeks so apologies if I 
may have missed that discussion), we could maybe remove "data 
collection". #justsaying

Mischa.

On 25/04/2016 13:42, Pascal Thubert (pthubert) wrote:
> *Sent:* lundi 25 avril 2016 14:19
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Carsten Bormann 
> <[email-masked]>; Juan Carlos Zuniga <[email-masked]>
> Alexander Pelov <[email-masked]>
>     I’m getting a strong sense here, but then, what would we use
>     instead? You know from your ROLL years that LLN is a consecrated
>     term at the IETF for IOT links.
>
>     *To:* Carsten Bormann <[email-masked]> <mailto:[email-masked]>; Juan
>     Carlos Zuniga <[email-masked]> <mailto:[email-masked]>
>     *Cc:* Paul Duffy (paduffy) <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Pascal Thubert (pthubert)
>     <[email-masked]> <mailto:[email-masked]>; Alexander Pelov
>     <[email-masked]> <mailto:[email-masked]>

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 25 Apr 2016 14:49:45 +0200

+1 for downstream as well.

I would say
"ten years" instead of 10 years.

Xavi

2016-04-25 14:46 GMT+02:00 Mischa Dohler <[email-masked]>:

> which is slowly emerging. Unless the emphasis has to be on upstream here (I
> have skipped a few email exchanges over past weeks so apologies if I may
> have missed that discussion), we could maybe remove " data collection".
> #justsaying
>
> Mischa.
>
>
> *From:* Mischa Dohler [mailto:[email-masked]
> <[email-masked]>]
> *To:* Pascal Thubert (pthubert) <[email-masked]> <[email-masked]>;
> Carsten Bormann <[email-masked]> <[email-masked]>; Juan Carlos Zuniga
> <[email-masked]> <[email-masked]>
> *Cc:* Paul Duffy (paduffy) <[email-masked]> <[email-masked]>;
> [email-masked]; Alexander Pelov <[email-masked]> <[email-masked]>
> I’m getting a strong sense here, but then, what would we use instead? You
> know from your ROLL years that LLN is a consecrated term at the IETF for
> IOT links.
>
> *From:* Mischa Dohler [mailto:[email-masked]
> <[email-masked]>]
> *To:* Carsten Bormann <[email-masked]><[email-masked]> <[email-masked]>; Juan
> Carlos Zuniga <[email-masked]> <[email-masked]>
> *Cc:* Paul Duffy (paduffy) <[email-masked]><[email-masked]>
> <[email-masked]>; [email-masked]; Pascal Thubert (pthubert)
> <[email-masked]><[email-masked]> <[email-masked]>; Alexander
> Pelov <[email-masked]> <[email-masked]>

---

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

Hi Pascal,

Very nice, I've two comments:

I also agree that upstream is a little bit restrictive, but we have to
insist on that because it has an impact on protocols and we will cover that
case. I propose something like:

Those common family traits include, over a basic star topology and an
optimized radio modulation,  frame sizes in tens of bytes and the order of

a few transmissions per day. Some technologies are using mostly
upstream transmission
pattern.

The other concern is the lasts word "operations". One goal of the wg will
be to simplify operation and management. If we say that it is already low
cost, the benefit of IETF will be not that high. I will just write

This also simplifies the deployment at

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

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 15:25:13 +0000

Dear all:

Thanks a huge bunch for this great activity. We’re progressing incredibly fast.

Laurent, please see below

Ø  I also agree that upstream is a little bit restrictive, but we have to insist on that because it has an impact on protocols and we will cover that case. I propose something like:

Ø  Those common family traits include, over a basic star topology and an optimized radio modulation,  frame sizes in tens of bytes and the order of a few transmissions per day. Some technologies are using mostly upstream transmission pattern.

Agreed, that’s exactly the point I wanted to make.

The extraordinary longevity has a lot to do with the avoidance of idle listening, which derives from a vast majority of unacknowledged upstream transmissions.

Proposal is to follow Mischa’s advice and remove data collection, and then mix his text with your proposal above as follows:

“
Those common family traits include an optimized radio modulation over a basic
star topology, frame sizes in the order of tens of bytes transmitted a few times
per day, and, though downstream may be emerge as an equally massive opportunity,
a mostly upstream transmission pattern which allows the device to stay longer in
deep sleep mode.
“

Ø  The other concern is the lasts word "operations". One goal of the wg will be to simplify operation and management. If we say that it is already low cost, the benefit of IETF will be not that high. I will just write

Ø  This also simplifies the deployment at a huge scale, and enables low costs for devices and infrastructure.

OK to avoid entering that discussion….

Thanks again!

Pascal

Laurent

On Mon, Apr 25, 2016 at 2:46 PM, Mischa Dohler <[email-masked]<mailto:[email-masked]>> wrote:
Very good! Thanks, Pascal.

PS: I don't want to stir troubles here but I see downstream (actuators, drones, robots, mems telemetry, etc) as an equally massive opportunity which is slowly emerging. Unless the emphasis has to be on upstream here (I have skipped a few email exchanges over past weeks so apologies if I may have missed that discussion), we could maybe remove " data collection". #justsaying

Mischa.

“

<…>
“

Cheers,

Pascal

From: Mischa Dohler [mailto:[email-masked]]
Sent: lundi 25 avril 2016 14:19
To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>; Carsten Bormann <[email-masked]><mailto:[email-masked]>; Juan Carlos Zuniga <[email-masked]><mailto:[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alexander Pelov <[email-masked]><mailto:[email-masked]>
Subject: Re: [lp-wan] Proposed charter v2

Dear Pascal,

Pascal

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[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]<mailto:[email-masked]>         | [email-masked]<mailto:[email-masked]>    |
+--------------------------+----------------------------------------+

---

From: Jonathan Muñoz <[email-masked]>
Date: Mon, 25 Apr 2016 18:29:04 +0200

Hello Pascal,

Thank you for putting all this together. I propose to modify this
aspect: "Those
common family traits include an optimized radio modulation over either a
star* or mesh* topology..."

Thanks,

Jonathan Muñoz

2016-04-25 17:25 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> Ø  I also agree that upstream is a little bit restrictive, but we have to
> Ø  Those common family traits include, over a basic star topology and an
> upstream transmission pattern.
>
>
>
> The extraordinary longevity has a lot to do with the avoidance of idle
> listening, which derives from a vast majority of unacknowledged upstream
> transmissions.
>
>
>
> Proposal is to follow Mischa’s advice and remove data collection, and then
> mix his text with your proposal above as follows:
>
>
>
> “
>
> Ø  The other concern is the lasts word "operations". One goal of the wg
> will be to simplify operation and management. If we say that it is already
> low cost, the benefit of IETF will be not that high. I will just write
>
>
>
> *To:* Carsten Bormann <[email-masked]> <[email-masked]>; Juan Carlos Zuniga
> [email-masked]; Pascal Thubert (pthubert) <[email-masked]>
> <[email-masked]>; Alexander Pelov <[email-masked]> <[email-masked]>

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Apr 2016 16:35:53 +0000

Hello Jonathan

We can debate that one but I think not.
What makes these technologies so simple to deploy is that they trade range for bandwidth with a single hop...

Regards,

Pascal

Le 25 avr. 2016 à 18:29, Jonathan Muñoz <[email-masked]<mailto:[email-masked]>> a écrit :

Hello Pascal,

Thank you for putting all this together. I propose to modify this aspect: "Those common family traits include an optimized radio modulation over either a star or mesh topology..."

Thanks,

Jonathan Muñoz

2016-04-25 17:25 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Dear all:

>  I also agree that upstream is a little bit restrictive, but we have to insist on that because it has an impact on protocols and we will cover that case. I propose something like:

>  Those common family traits include, over a basic star topology and an optimized radio modulation,  frame sizes in tens of bytes and the order of a few transmissions per day. Some technologies are using mostly upstream transmission pattern.

“

>  The other concern is the lasts word "operations". One goal of the wg will be to simplify operation and management. If we say that it is already low cost, the benefit of IETF will be not that high. I will just write

>  This also simplifies the deployment at a huge scale, and enables low costs for devices and infrastructure.

Thanks again!

Pascal

Laurent

Mischa.

“

<…>
“

Cheers,

Pascal

Dear Pascal,

Pascal

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.

--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156<tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026<tel:%2B%2033%202%2099%2012%207026>                 | Visit :
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445<tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030<tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in
| [email-masked]<mailto:[email-masked]>         | [email-masked]<mailto:[email-masked]>    |
+--------------------------+----------------------------------------+

---

From: Jonathan Muñoz <[email-masked]>
Date: Mon, 25 Apr 2016 18:52:43 +0200

Ok I understand but how do we provide connectivity to a node which is out
of range from the gateway?

That aspect of the topology could be loosen to provide wider range and yet
keeping it simple.

Cheers,

Jonathan

2016-04-25 18:35 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> Le 25 avr. 2016 à 18:29, Jonathan Muñoz <[email-masked]> a
> écrit :
>
> Hello Pascal,
>
> Thank you for putting all this together. I propose to modify this aspect: "Those
>> Ø  I also agree that upstream is a little bit restrictive, but we have
>> to insist on that because it has an impact on protocols and we will cover
>> that case. I propose something like:
>>
>>
>>
>> Proposal is to follow Mischa’s advice and remove data collection, and
>> then mix his text with your proposal above as follows:
>>
>>
>>
>> “
>>

---

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

Hello Jonathan:

My take is that the work at hand is really IPv6 over an extreme link technology; if one wants to mesh, route, or schedule at the layers above, that’s fine but that is not the concern of this WG.

IOW, one could use 6TiSCH above LPWA technologies, leveraging the new compression mechanisms instead of 6LoWPAN if the LPWA is the like of LoRa or SigFox, or classical 6LoWPAN in the case of 802.15.4g for instance. But that happens above the head of what we’re doing here.

Is that acceptable ?

Pascal

From: Jonathan Muñoz [mailto:[email-masked]]
Sent: lundi 25 avril 2016 18:53
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Mischa Dohler <[email-masked]>; Paul Duffy (paduffy) <[email-masked]>; Laurent Toutain <[email-masked]>; Alexander Pelov <[email-masked]>; [email-masked]; Carsten Bormann <[email-masked]>; Juan Carlos Zuniga <[email-masked]>
Subject: Re: [lp-wan] Proposed charter v2

Ok I understand but how do we provide connectivity to a node which is out of range from the gateway?

That aspect of the topology could be loosen to provide wider range and yet keeping it simple.

Cheers,

Jonathan

2016-04-25 18:35 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Jonathan

Regards,

Pascal

Thanks,

Jonathan Muñoz

“

Thanks again!

Pascal

Laurent

Mischa.

“

<…>
“

Cheers,

Pascal

Dear Pascal,

Pascal

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.

--
Jonathan Muñoz
PhD student at Gridbee Communications & INRIA Paris
+33 (0) 6 59 05 93 83<tel:%2B33%20%280%29%206%2059%2005%2093%2083>

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 25 Apr 2016 19:33:08 +0200

Dear Jonathan,

The key point here is that it costs so little to deploy an additional 
Access Point, and the penalty in terms of Duty Cycling and wasted 
bandwidth is so great, that Mesh topology should be considered lower 
priority for the moment.

I'd go even further than that - before considering mesh, we should 
consider multi-star topology, where an end-device is covered by several 
Access Points.

Both of these remarks are based on a simple principle - don't try to 
address every problem. Find a subset that is tangible and where there 
are specific demands, shared by the broader community.

I'll be happy to work with you towards a "generic topology" solution 
once we have the major questions addressed. And if we mix this with 
mostly asymmetric traffic patterns, then you have my full curiosity as a 
researcher. Until then, from business perspective, I don't see the case 
for it.

Best,
Alexander

Le 2016-04-25 18:52, Jonathan Muñoz a écrit :
>> Le 25 avr. 2016 à 18:29, Jonathan Muñoz
>> <[email-masked]> a écrit :
>> 
>> Hello Pascal,
>> 
>> aspect: "Those common family traits include an optimized radio
>> modulation over either a star_ or mesh_ topology..."
>> 
>> Thanks,
>> 
>> Jonathan Muñoz
>> 
>> Ø I also agree that upstream is a little bit restrictive, but we
>> have to insist on that because it has an impact on protocols and we
>> will cover that case. I propose something like:
>> 
>> Ø Those common family traits include, over a basic star topology
>> and an optimized radio modulation, frame sizes in tens of bytes and
>> the order of a few transmissions per day. Some technologies are
>> using mostly upstream transmission pattern.
>> 
>> The extraordinary longevity has a lot to do with the avoidance of
>> idle listening, which derives from a vast majority of unacknowledged
>> upstream transmissions.
>> 
>> Proposal is to follow Mischa’s advice and remove data collection,
>> and then mix his text with your proposal above as follows:
>> 
>> “
>> 
>> Ø The other concern is the lasts word "operations". One goal of
>> the wg will be to simplify operation and management. If we say that
>> it is already low cost, the benefit of IETF will be not that high. I
>> will just write
>> 
>> Ø This also simplifies the deployment at a huge scale, and enables
>> low costs for devices and infrastructure.
>> 
>> On Mon, Apr 25, 2016 at 2:46 PM, Mischa Dohler
>> <[email-masked]> wrote:
>> 
>> PS: I don't want to stir troubles here but I see downstream
>> (actuators, drones, robots, mems telemetry, etc) as an equally
>> massive opportunity which is slowly emerging. Unless the emphasis
>> has to be on upstream here (I have skipped a few email exchanges
>> over past weeks so apologies if I may have missed that discussion),
>> we could maybe remove " data collection". #justsaying
>> 
>> Mischa.
>> 
>> FROM: Mischa Dohler [mailto:[email-masked]]
>> SENT: lundi 25 avril 2016 14:19
>> TO: Pascal Thubert (pthubert) <[email-masked]>; Carsten Bormann
>> CC: Paul Duffy (paduffy) <[email-masked]>; [email-masked];
>> SUBJECT: Re: [lp-wan] Proposed charter v2
>> 
>> Dear Pascal,
>> 
>> FROM: Mischa Dohler [mailto:[email-masked]]
>> SENT: lundi 25 avril 2016 13:53
>> TO: Carsten Bormann <[email-masked]>; Juan Carlos Zuniga
>> <[email-masked]>
>> CC: Paul Duffy (paduffy) <[email-masked]>; [email-masked];
>> SUBJECT: Re: [lp-wan] Proposed charter v2
>> 
>> +1
>> 
>> www.mischadohler.com [1]
> https://www.ietf.org/mailman/listinfo/lp-wan [2]
> 
> --
> 
> Laurent Toutain
> 
> | Tel: +33 2 22 06 8156 [3]    | Tel: + 33 2 99 12 7026 [4]
>      | Visit :
> 
> | Fax: +33 2 22 06 8445 [5]    | Fax: +33 2 99 12 7030 [6]
>      |  http://class.touta.in [7]
> https://www.ietf.org/mailman/listinfo/lp-wan [2]
> 
>  --
> 
> Jonathan Muñoz
> +33 (0) 6 59 05 93 83 [8]
> https://www.ietf.org/mailman/listinfo/lp-wan [2]
> 
> --
> 
> Jonathan Muñoz
> Links:
> ------
> [1] http://www.mischadohler.com
> [2] https://www.ietf.org/mailman/listinfo/lp-wan
> [3] tel:%2B33%202%2022%2006%208156
> [4] tel:%2B%2033%202%2099%2012%207026
> [5] tel:%2B33%202%2022%2006%208445
> [6] tel:%2B33%202%2099%2012%207030
> [7] http://class.touta.in
> [8] tel:%2B33%20%280%29%206%2059%2005%2093%2083
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 25 Apr 2016 18:00:20 +0000

> that Mesh topology should be considered lower priority for the moment.

I tend to agree with this. To start with a single gateway path to the
network is a good starting point. Mesh models can be inserted later.

Sri

On 4/25/16, 10:33 AM, "lp-wan on behalf of Alexander Pelov"
<[email-masked] on behalf of [email-masked]> wrote:

>>> Thanks a huge bunch for this great activity. We¹re progressing
>>> incredibly fast.
>>> 
>>> Agreed, that¹s exactly the point I wanted to make.
>>> 
>>> Proposal is to follow Mischa¹s advice and remove data collection,
>>> ³
>>> ³
>>> OK to avoid entering that discussionŠ.
>>> 
>>> Thanks again!
>>> 
>>> Pascal
>>> 
>>> Laurent
>>> 
>>> ³
>>> <Š>
>>> ³
>>> I¹m getting a strong sense here, but then, what would we use
>>> I can see WSN, ³low power radio² Š any suggestion?
>>> 
>>> Pascal
>>>

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 25 Apr 2016 19:10:13 +0000

Hi Pascal,

Please see below in-line.

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 25, 2016 10:26 AM
To: Jonathan Muñoz
Cc: Mischa Dohler; Paul Duffy (paduffy); Laurent Toutain; Alexander Pelov; [email-masked]; Carsten Bormann; Juan Carlos Zuniga
Subject: Re: [lp-wan] Proposed charter v2

Hello Jonathan:

My take is that the work at hand is really IPv6 over an extreme link technology; if one wants to mesh, route, or schedule at the layers above, that’s fine but that is not the concern of this WG.
[SC>] Understanding and deciding on the basic topology support is as important as choosing IPv6 or not. Given the applications and the range of the LPWAN technology, mesh may be lower priority (due to complexity) than the simpler topologies ( example: star, single-hop). LPWAN group needs to clarify that.
We can already run IPv6 on the constrained devices – this might need a bit more optimization, a new compression technique, handling of fragmentation or putting recommendation on MTU sizes for reliable communication.

Is that acceptable ?
[SC>]  It did not make  much sense to me. 6Tisch is defined for a specific MAC layer(802.15.4e), 6lowpan is for IEEE 802.15.4 family,  LPWAN needs ‘IPv6-over-LPWA’ using constrained nodes. 6lo in current charter works on 6lowpan-modified  stack over other ‘foos’ (except TSCH due to special MAC handling).

I don’t understand  how LPWA technology can use 6TiSCH unless the MAC supports a behavior like TSCH ?

-Samita

From: Jonathan Muñoz [mailto:[email-masked]]
Sent: lundi 25 avril 2016 18:53
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Mischa Dohler <[email-masked]<mailto:[email-masked]>>; Paul Duffy (paduffy) <[email-masked]<mailto:[email-masked]>>; Laurent Toutain <[email-masked]<mailto:[email-masked]>>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>; Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Proposed charter v2

Cheers,

Jonathan

Regards,

Pascal

Thanks,

Jonathan Muñoz

“

Thanks again!

Pascal

Laurent

Mischa.

“

<…>
“

Cheers,

Pascal

Dear Pascal,

Pascal

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 26 Apr 2016 13:54:47 +0200

+1 for the downstream comment.

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 26 Apr 2016 14:01:32 +0200

About mesh vs. star, let's not get confused about what we are addressing.

IMO, LPWAN introduces a new set of PHY layers which introduce new
opportunities and new challenges.
Let's use LPWAN to make sure IETF protocols can run on top of these.
Once that is done, if people want to mesh, let'm mesh!

I suggest we don't have a "star vs mesh" fight in the charter, it's not
LPWAN's focus.

On Tue, Apr 26, 2016 at 1:54 PM, Thomas Watteyne <[email-masked]>
wrote:

>>> *To:* Pascal Thubert (pthubert) <[email-masked]>
>>> <[email-masked]>; Carsten Bormann <[email-masked]> <[email-masked]>;
>>> Juan Carlos Zuniga <[email-masked]> <[email-masked]>
>>> You know from your ROLL years that LLN is a consecrated term at the IETF
>>> for IOT links.
>>>
>>> <[email-masked]><[email-masked]> <[email-masked]>;
>>> Alexander Pelov <[email-masked]> <[email-masked]>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Jonathan Muñoz <[email-masked]>
Date: Wed, 27 Apr 2016 10:47:07 +0200

Pascal, Alexander, Thomas, all,

I agree on your comments about the first stage of this WG concerning the
topology.

Regards,

2016-04-26 14:01 GMT+02:00 Thomas Watteyne <[email-masked]>:

> On Tue, Apr 26, 2016 at 1:54 PM, Thomas Watteyne <[email-masked]
> > wrote:
>
>>>> *To:* Carsten Bormann <[email-masked]><[email-masked]> <[email-masked]>;

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Apr 2016 07:27:12 +0000

Hello Samita:

Please see below in-line:

<Pascal>

Yes and no. There is a region in the low power wide area world where now-mainstream work done at 6Lo, 6TiSCH, ROLL etc… will apply. I’d claim that IEEE802.15.4g belongs to that region.  If IEEE is interested in seeing work at LPWAN, I’m sure that there will be activity that applies, but there’s probably no need for LPWAN work for compression, fragmentation, or routing, and whatever needs to happen on these subjects can be suggested by LPWAN to the  relevant WGs.

OTOH, for most of the other technologies discussed in this list, the classical over-the-air flows can just not happen for a number of reasons that we already clarified in this list, like unbalanced transmissions, order(s) of magnitude lower rates for both bits and frame, need to live with existing air formats, etc…

For those technologies, we are considering a more centralized management, so that over-the-air protocols do not need to happen. This work will attract a crowd that is largely different from the 6Lo attendance, some from external bodies to keep the group aligned with the needs and constraints, some from the IETF from management, operations, and security.

Is that acceptable ?

<Pascal>

TSCH defines an upper mac schedule, which could apply to many lower MAC and PHY combinations. It could plainly work on 802.15.4g, and the whole 6TiSCH work could be ported. For the more constrained LPWA technologies, what I said above applies, meaning that a whole range of the 6TiSCH stack (use of 6LoWPAN, RPL, etc..) has to be reconsidered. But on paper, most of the TSCH benefits appear to be still present.

Cheers,

Pascal

-Samita

Cheers,

Jonathan

Regards,

Pascal

Thanks,

Jonathan Muñoz

“

Thanks again!

Pascal

Laurent

Mischa.

“

<…>
“

Cheers,

Pascal

Dear Pascal,

Pascal

+1

Prof Mischa Dohler

Fellow, IEEE

actually trying to do.