Subject: [lp-wan] Proposed charter v4

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

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

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

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.

Those common traits include an optimized radio modulation over a simple star
topology, frame sizes in the order of tens of bytes transmitted a few times per
day, and, though downstream may be emerging as an equally massive opportunity, a
transmission pattern which is generally upstream and allows the devices to stay
longer in low-energy deep-sleep mode.

This enables a range in tens of kilometers, and a long battery lifetime, with up
to ten years of operation on a single coin-cell. This also enables simple and
scalable deployments with low-cost devices and thin infrastructures.

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

To unleash the full power of LPWA technologies and their ecosystems, there is a
need to couple them with other ecosystems that will guarantee the inter-working
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
connectivity 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 connectivity over a selection of
Low-Power Wide-Area technologies, <tech1>, <Tech2> and <Tech3>.

These technologies present similar characteristics of rare and widely unbalanced
over-the-air transmissions, with little capability to alter the frame formats to
accommodate this work, which makes it so that existing IETF work (6lo) cannot be
trivially applied.

The Working Group will leverage cross-participation with the associated set of
stakeholders to ensure that the work taking place corresponds to real demands
and that the proposed solutions are indeed applicable.

The group will produce informational work, for IETF consumption, describing LPWA
technologies and their needs, best practice documents on using IETF technologies
in LPWA networks directed to the selected entities, and new standard track work
to optimize IPv6-based communications to the end device, down to the remote-I/O
model where the device itself is not fully aware of the whole stack.

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

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

The group will:

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.

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. It is an expectation that the
resulting document(s) may contribute to the interaction with LPWA stakeholders
and lead to additional work in the future.

3. Produce Standard Track documents to enable the compression of a CoAP/UDP/IPv6
packet over LPWA. Considering the extreme constraints, the work will focus on a
generic YANG data model to describe 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: Thomas Watteyne <[email-masked]>
Date: Tue, 26 Apr 2016 14:23:07 +0200

Pascal,

Thanks for putting together this. Some suggestions.

GENERAL COMMENT
should the beginning of the charter discuss about capacity issues when lots
of these long range devices are used in the same area, if no coordination
is done?

ABOUT
Those common traits include an optimized radio modulation over a simple star
topology, frame sizes in the order of tens of bytes transmitted a few times
per
day, and, though downstream may be emerging as an equally massive
opportunity, a
transmission pattern which is generally upstream and allows the devices to
stay
longer in low-energy deep-sleep mode.
COMMENTS
- we might want to remove "over a simple star topology", or just say
"generally over a simple star topology"
- is "tens of bytes" true? aren't we dealing with <10 bytes in some of the
technologies considered?

ABOUT
This enables a range in tens of kilometers
COMMENTS
Tens of km means at least 20, which might be a stretch, especially in
non-LOS environments. Why not "This enables a range of several kilometers"?

ABOUT
up to ten years of operation on a single coin-cell
COMMENTS
"up to" suggests there is a hard stop at 10 years. Why not "possibly ten
years of"

ABOUT
the inter-working at the network
COMMENTS
a paragraph earlier the charter says there is no network layer. I
understand what you mean, I would just make sure this doesn't confuse people

OLD
new standard track
NEW
new standards track

OLD
highlights actual needs
NEW
highlight actual needs

ABOUT
the work will focus on a generic YANG data model to describe the compression
COMMENT
I agree that the work item is important, but I don't see how the YANG
formalism is useful for describing compression

Thomas

On Mon, Apr 25, 2016 at 7:13 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

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

-- 
_______________________________________

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: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Tue, 26 Apr 2016 12:47:02 +0000

Dear all,

Some remarks, comments:
----------------------
Old text:
The group will:
1. Produce an Informational document describing and relating existing some LPWA
technologies.
New text:
The group will:
1. Produce an Informational document describing and relating existing LPWA
technologies and architectures.
----------------------
Then the order of the deliverables are not adequate. I suggest that we do the following:

  1.  description of technologies and architectures
  2.  Produce Standard Track documents to enable the compression of a CoAP/UDP/IPv6 packet over LPWA
  3.  Produce a document to enable the fragmentation of larger packets over LPWA
  4.  Produce best practice documents for security and management

4 could be complete after 1, 2 and 3 only.

Also I do not like the term “best practice”. It could be off track for the IETF. I rather say informational document on bla bla.

Last point, each Standard documents will include a security section, right? Do we want to mention this as well?

Many thanks for putting this proposal together.

Patrick

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 26 April 2016 at 14:23
To: Pascal THUBERT <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Proposed charter v4

Pascal,

GENERAL COMMENT
should the beginning of the charter discuss about capacity issues when lots of these long range devices are used in the same area, if no coordination is done?

ABOUT
Those common traits include an optimized radio modulation over a simple star
topology, frame sizes in the order of tens of bytes transmitted a few times per
day, and, though downstream may be emerging as an equally massive opportunity, a
transmission pattern which is generally upstream and allows the devices to stay
longer in low-energy deep-sleep mode.
COMMENTS
- we might want to remove "over a simple star topology", or just say "generally over a simple star topology"
- is "tens of bytes" true? aren't we dealing with <10 bytes in some of the technologies considered?

ABOUT
This enables a range in tens of kilometers
COMMENTS
Tens of km means at least 20, which might be a stretch, especially in non-LOS environments. Why not "This enables a range of several kilometers"?

ABOUT
up to ten years of operation on a single coin-cell
COMMENTS
"up to" suggests there is a hard stop at 10 years. Why not "possibly ten years of"

ABOUT
the inter-working at the network
COMMENTS
a paragraph earlier the charter says there is no network layer. I understand what you mean, I would just make sure this doesn't confuse people

OLD
new standard track
NEW
new standards track

OLD
highlights actual needs
NEW
highlight actual needs

ABOUT
the work will focus on a generic YANG data model to describe the compression
COMMENT
I agree that the work item is important, but I don't see how the YANG formalism is useful for describing compression

Thomas

On Mon, Apr 25, 2016 at 7:13 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
<6LPWA>: "IPv6 over Low-Power Wide-Area networks".

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

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

The group will:

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

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Apr 2016 15:32:16 +0000

Hello Patrick:

Ack for the typos.

About item 4: Please note that producing BCP is perfectly fine at the IETF, just like STD track and informational (Intended status: Best Current Practice). Now I can buy that we may do informational work there as opposed to BCP. Let's start with BCP, and we may decide otherwise depending on the content that is produced.

Thanks for all!

Pascal

From: Patrick Wetterwald (pwetterw)
Sent: mardi 26 avril 2016 14:47
To: Thomas Watteyne <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lp-wan] Proposed charter v4

Dear all,

Some remarks, comments:
----------------------
Old text:
The group will:

Also I do not like the term "best practice". It could be off track for the IETF. I rather say informational document on bla bla.

Patrick

Pascal,

GENERAL COMMENT

ABOUT

ABOUT

ABOUT

ABOUT

OLD
new standard track
NEW
new standards track

OLD
highlights actual needs
NEW
highlight actual needs

ABOUT

Thomas

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

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

The group will:

Thomas Watteyne, PhD

---

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

Hello Thomas:

GENERAL COMMENT

<Pascal> There are things around to address capacity, like power management, and more can be brought in, like scheduling. There is some coordination, and again more could be brought in. Adding those topics may work but may create lengthy discussions which will better fit an installed structure.

ABOUT

<Pascal> We are just giving an order. WISA can be down to 1 byte but then that’s hardly Long Range : )
What about:
“
Those common traits include an optimized radio modulation, a typical deployment
as a simple star topology, frame sizes in the order of tens of bytes transmitted
a few times per day, and, though downstream may be supported, a mostly upstream
transmission pattern that allows the devices to spend most of their time in
low-energy deep-sleep mode.
“

ABOUT

<Pascal> Depends on the PHY, and the environment. I can go with that proposal but let’s see how others react when I publish.

ABOUT

<Pascal> OK

ABOUT

<Pascal> What about

“
To unleash the full power of LPWA technologies and their ecosystems, there is a
need to couple them with other ecosystems that will guarantee the inter-working
by introducing a network layer, and enable common components for management and
security, as well as shared application profiles.
“
OLD
new standard track
NEW
new standards track

<Pascal> What about
“
and new standard work to optimize IPv6-based communications to
the end device, down to the remote-I/O model where the device is not fully aware
of the whole stack.
“
OLD
highlights actual needs
NEW
highlight actual needs

<Pascal> Yes

ABOUT

<Pascal> Because we  need to publish a compression state into the “GW” as opposed to learn it like RoHC does…

Thanks for all Thomas!

Pascal

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

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

The group will:

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 27 Apr 2016 18:09:06 +0200

inline

On Tue, Apr 26, 2016 at 7:48 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Thomas:
>
>
>
> GENERAL COMMENT
>
> should the beginning of the charter discuss about capacity issues when
> lots of these long range devices are used in the same area, if no
> coordination is done?
>
>
>
> <Pascal> There are things around to address capacity, like power
> management, and more can be brought in, like scheduling. There is some
> coordination, and again more could be brought in. Adding those topics may
> work but may create lengthy discussions which will better fit an installed
> structure.
>

ok

> low-energy deep-sleep mode.

looks good!

> <Pascal> Depends on the PHY, and the environment. I can go with that
> proposal but let’s see how others react when I publish.
>

eager to see the reaction

> "up to" suggests there is a hard stop at 10 years. Why not "possibly ten

thanks

> security, as well as shared application profiles.

perfect

> the end device, down to the remote-I/O model where the device is not fully

perfect

> <Pascal> Yes

thanks

> opposed to learn it like RoHC does…

OK

> Thanks for all Thomas!

thanks!!

Thomas Watteyne, PhD

www.thomaswatteyne.com