Subject: [lp-wan] Next steps on LP-WANs

From: Alexander Pelov <[email-masked]>
Date: Tue, 1 Dec 2015 23:12:40 +0100

Dear all,

I would like to make a short recap of the multiple discussions we had 
during the past weeks. I'd like to solicit you for potential 
contributors to several of the documents that we should produce in the 
next couple of weeks.

We saw that there are a significant number of existing technologies that 
must be taken into account, among which:
- Semtech Lora, IEEE802.15.4k, IEEE802.15.4g, Qowisio, SigFox, 
Weightless W/N/P, RPMA

These technologies must be categorized and described in terms which can 
be used for the specific problem statement of LP-WANs, and which must 
provide with enough material to identify the applicable approaches. 
These include:
- The device characteristics
- MTU size
- Bit-rate
- Fragmentation handling at L2
- Security at L2
- Intended application space (and expected traffic type)

Special attention must be taken to address more global issues, such as:
- deployment architectures (infrastructure: star, p2p, hetnets)
- heavy-ACK, cross-layer headaches (due to duty-cycling restrictions 
among others)
- monitoring device health (battery, reception)
- fine-grained parameter setting (both network and application)
- AAA
- mobility
- uni-directional communications
- security implications for upper layers

In particular, we should also take into account the fact that due to the 
extremely limited bit-rate, and the typically low message-rate, there 
are some solutions that become feasible, where in more classical 
networks these would be considered unreasonable. Finally, a special 
attention should be put on the assumptions in the work on CIoT.

I'd like to propose to start a work on a couple of documents related to 
the above issues. These include, for the moment:
1) L2 LP-WAN technologies
2) Problem statement
3) LP-WAN architectures
4) Best Current Practices that could apply to LP-WANs

The base of these documents may include the following (but not limited to):
- http://www.eejournal.com/archives/articles/20150907-lpwa/
- draft-pelov-core-cosol
- 3GPP TR 23.720, TR 45.820
- ETSI LTN
- IEEE 802.15.4k, IEEE 802.15.4g
- The full set of RFCs and drafts from relevant IETF groups (e.g. 6lo, 
6tisch, ace)

Would you be willing to work on any of the above three documents? Do you 
see any additional document on which we could start contributing in the 
near future?

Best,
Alexander

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 1 Dec 2015 17:00:42 -0600

Hi,

I believe that it may be useful to view the networks being considered
by this working group as "bandwidth-constrained networks" (rather than
"constrained-node networks").

Likewise, I think it might be useful to describe these networks as
"low-bandwidth WANs", or perhaps more appropriately "ultra-low-bandwidth
WANs" (rather than low-power WANs).

In my view, this change in terminology and perspective may help us focus
on what really makes these networks different.

In many of these networks that I have seen, bandwidth, not node
capacity, is most constrained (and valuable) resource.  Again, in my
view, it often makes sense in many of these systems to increase the
storage and processing requirements of nodes in order to reduce
bandwidth requirements.  Node capacity can be increased fairly easily,
while bandwidth generally cannot.

An extreme example of these sorts of networks is interplanetary links.
Bandwidth is the most valuable, the most constrained, resource.
Substantial resources are employed, particularly on the terrestrial end
of the link, to make sure that every bit on the link counts.

I will try to type up some more widely deployed examples.

I am concerned that the 6lowpan groups may have become overly focused on
networks that use cheap, limited-capacity nodes (i.e., node-constrained
networks).  I think that it is important, particularly in this working
group, to recognize that the system level (and protocol) optimizations
that are appropriate for node-constrained networks may not be most
appropriate for bandwidth-constrained networks.

Permit me to argue by way of example that there are cases where the
focus of severely constrained nodes may be misplaced.  Earlier, someone
suggested an example of a bandwidth-constrained network being used
to control a valve in a remote location.  Some seemed to think that
this valve would likely be controlled by a severely constrained node.
In my view, this would probably be a poor system-level design
decision.  Rather, in many situations it would probably make sense to
use a more powerful node.  Cost is unlikely to be a concern,
particularly compared to the cost of the valve and of the whole system.
Likewise, power is probably not a problem: the valve probably requires
substantial power (at least compared to the power required by the
valve).  And, the radio is likely to require quite a bit of power,
again compared to the power required by a more-appropriately sized
node.

Yes, I recognized that there are probably systems being proposed that
are based on an assumption that the nodes will be severely constrained.
(And business plans that assume node-constrained, wide-area, wireless
networks.)  On the other hand, there are a lot of existing systems that
are bandwidth-constrained, where additional processor power and memory
could be beneficial.  I think that these latter networks could benefit
from IP standardization.  Moreover, these networks already have a
proven business case.

(In future messages, I will suggest that narrowband VHF and UFH data
radios ought to be added to the link-layer technologies considered by
this group.  There are a lot of these devices in use, and I think that
having IP operate over them in a standard, interoperable way could be
a bit win.)

(In future email, I will also provide some [real-world] examples of
ultra-narrowband links that are severely bandwidth constrained, but
probably don't meet the definition of "low power" that most in this
group seem to hold.)

-tjs

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 19:22:03 -0500

> on what really makes these networks different.

If this is really what the group is about, then your change in terminology is
definitely appropriate.

My understanding of the technologies that Alexander mentioned is that
increases in complexity in the hub is not a problem, but that the spoke nodes
are usually significantly energy constrained, even if they might be
memory/CPU rich (class 2+. I'd like to see rfc7228 define a class 3)

    > of the link, to make sure that every bit on the link counts.

I agree that this is extreme, but is it in scope?

    > probably don't meet the definition of "low power" that most in this

good.

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 2 Dec 2015 10:16:35 +0800

Hi all,

> Timothy J. Salo<[email-masked]> wrote: I believe that it may be useful 
> to view the networks being considered

I agree.
If it is constructed of low power and contrained nodes,
the network seems not to be a WAN.

Besides it is required to have a reference of WAN and one hop radio range.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Timothy J. Salo
Sent: Wednesday, December 02, 2015 7:00 AM
To: [email-masked]
Subject: [lp-wan] Bandwidth-Constrained Networks

Hi,

-tjs

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 2 Dec 2015 12:36:57 +0800

Hi Alexander,

> - Semtech Lora, IEEE802.15.4k, IEEE802.15.4g, Qowisio, SigFox, Weightless 
> W/N/P, RPMA

It seems not.
What do you mean WAN, wide area networks?
Typically, all IEEE802.15.x documents are for PAN, personal area networks.

So,  one point must be clear,
this WG (LP-WAN) concerns technologies of WAN.
Right or not?

Regrads,

Gengyu WEI
-----原始邮件----- 
From: Alexander Pelov
Sent: Wednesday, December 02, 2015 6:12 AM
To: [email-masked]
Subject: [lp-wan] Next steps on LP-WANs

Dear all,

Best,
Alexander

---

From: Paul Duffy <[email-masked]>
Date: Wed, 2 Dec 2015 00:02:04 -0500

Greetings

Like it or not the collection of tech listed below is generally referred 
to as LPWAN.

It would be helpful if we stick with that badge.

On 12/1/2015 11:36 PM, weigengyu wrote:
> Hi Alexander,
>
>> We saw that there are a significant number of existing technologies 
>> that must be taken into account, among which:
> -----原始邮件----- From: Alexander Pelov

---

From: "weigengyu" <[email-masked]>
Date: Wed, 2 Dec 2015 13:19:24 +0800

Hi paduffy,

I wish that the badge represents the technologies concerned with no relation 
to "like or not".
And it would be good to share some references about which techonogies are 
used in WAN.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Paul Duffy
Sent: Wednesday, December 02, 2015 1:02 PM
To: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

Greetings

---

From: Paul Duffy <[email-masked]>
Date: Wed, 2 Dec 2015 00:28:16 -0500

I don't see the term LPWAN as unreasonable.

A WAN is a network used to transmit data over large geo distances.   If 
10 - 20 km is large enough, "WAN" fits this tech.

And a lot of these endpoints (most?) will be operated on very low power 
budgets.

IMO the name LPWAN ... this ship has already sailed. Let's not confuse 
the market.

On 12/2/2015 12:19 AM, weigengyu wrote:
> Hi paduffy,
>
> I wish that the badge represents the technologies concerned with no 
> relation to "like or not".
> And it would be good to share some references about which techonogies 
> are used in WAN.
>
> Regards,
>
> Gengyu WEI
> -----原始邮件----- From: Paul Duffy
> .

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Dec 2015 06:29:08 +0000

Agreed,

Pascal

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Paul Duffy
> (paduffy)
> Sent: mercredi 2 décembre 2015 06:28
> To: weigengyu <[email-masked]>
> Cc: [email-masked]
> IMO the name LPWAN ... this ship has already sailed. Let's not confuse the
> market.
> 
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 2 Dec 2015 08:06:05 +0100

Hi Gengyu,

What you mention also happens with many 802.15.4-2003 or 802.15.4-2006
networks. They are not 'personal area networks' in many deployments, but
the technology was developed under the 802.15 umbrella... So there is some
mismatch between the theoretical scope of the technology (WPAN) and the
actual use of it (quite often not really a WPAN).

There were comments some time ago in this regard, suggesting that the 'P'
in 6LoWPAN should disappear, for this very reason. I suspect this is one
of the reasons why today we have a WG called 'only' 6Lo...

So, in my opinion, there is no problem to consider e.g. 802.15.4g in the
set of LP-WAN technologies.

Greetings,

Carles

>> Weightless

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 2 Dec 2015 08:55:02 +0100

Hi,

To complement what Carles says, with 15.4g we can have stable links of
2-3km which IMHO is not PAN but WAN (or MAN if you like).

So I guess LPWAN is appropiate.

regards,
Xavi

2015-12-02 8:06 GMT+01:00 Carles Gomez Montenegro <[email-masked]>:

> > -----åŽŸå§‹é‚®ä»¶-----

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 2 Dec 2015 09:38:44 +0100

+1 for LPWAN

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 30 96 6312    | 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: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Wed, 2 Dec 2015 08:43:19 +0000

LPWAN is used evrywhere even in the press. Let’s stick to it.

Patrick

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 2 December 2015 at 09:38
To: Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>>, weigengyu <[email-masked]<mailto:[email-masked]>>, Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Next steps on LP-WANs

+1 for LPWAN

On Wed, Dec 2, 2015 at 8:55 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

To complement what Carles says, with 15.4g we can have stable links of 2-3km which IMHO is not PAN but WAN (or MAN if you like).

regards,
Xavi

2015-12-02 8:06 GMT+01:00 Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>>:
Hi Gengyu,

Greetings,

Carles

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

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

_______________________________________________
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 30 96 6312    | 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: oana iova <[email-masked]>
Date: Wed, 2 Dec 2015 10:29:34 +0100

Hi Alexander,

I could participate in the document related to L2 LP-WAN technologies
and/or the Problem statement.

Cheers,
Oana

On Tue, Dec 1, 2015 at 11:12 PM, Alexander Pelov <[email-masked]> wrote:

> during the past weeks. I'd like to solicit you for potential contributors
> to several of the documents that we should produce in the next couple of
> weeks.
>
> These technologies must be categorized and described in terms which can be
> used for the specific problem statement of LP-WANs, and which must provide
> with enough material to identify the applicable approaches. These include:
> - heavy-ACK, cross-layer headaches (due to duty-cycling restrictions among
> others)
> extremely limited bit-rate, and the typically low message-rate, there are
> some solutions that become feasible, where in more classical networks these
> would be considered unreasonable. Finally, a special attention should be
> put on the assumptions in the work on CIoT.
>

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 2 Dec 2015 10:56:21 +0100

Hello,

I think it is important to start working on the content of this group. I
created a table with the technologies that have been discussed during the
past weeks. As you will see I have not filled everything because I'm not
specialist of each technology, I count on you to contribute not only in
filling it but also if I missed some parameter to add it.

I think this will help us to describe more precisely the requirements of
the LP-WAN technologies. That will probably help to complete the documents
that Alexander has mentioned in point 1 to 4.

https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing

Thanks
Ana Minaburo

---

From: oana iova <[email-masked]>
Date: Wed, 2 Dec 2015 11:21:08 +0100

Hello,

Does anybody have more details about the technology used by Qowisio? After
reading the latest news, it seems like they joined the LoRa Alliance:
http://www.unlockpwd.com/qowisio-lora-joined-the-alliance-and-launched-the-first-dual-mode-network-unb-lora/

Best,
Oana

On Wed, Dec 2, 2015 at 10:56 AM, Ana Minaburo <[email-masked]> wrote:

>> provide with enough material to identify the applicable approaches. These
>> include:

---

From: Mischa Dohler <[email-masked]>
Date: Wed, 2 Dec 2015 10:32:36 +0000

+1

______________________________________

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

www.mischadohler.com
______________________________________

On 02/12/2015 07:55, Xavier Vilajosana wrote:
> 2015-12-02 8:06 GMT+01:00 Carles Gomez Montenegro
> <[email-masked] <mailto:[email-masked]>>:
>
>     Hi Gengyu,
>
>      > To: [email-masked] <mailto:[email-masked]>
>      > The base of these documents may include the following (but not
>     limited
>      > to):
>      > [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Florian Meier <[email-masked]>
Date: Wed, 02 Dec 2015 12:18:11 +0100

Dear all,
renaming would make the confusion in this area even worse, but I agree 
that we have to define a precise problem statement.
Many of the traditional constraints are getting less relevant 
(especially regarding the computational power and memory of the nodes), 
while we still can not overcome the physics of wireless transmissions.

Regarding the documents I would highly suggest a collaborative approach, 
e.g. Etherpad, Google Docs..., so that everyone can contribute his 
personal expertise. Otherwise, we probably end up with very biased 
documents.

I personally have some experience in medium access, especially with 
regard to scalability [1,2], that might also be relevant for LP WANs 
(the papers are focused on IEEE 802.15.4 mesh networks, but the 
techniques can be easily adapted). Furthermore, I take part in a 
research project about the implementation of an actual industrial 
application that might highly benefit from LP WANs [3] and have 
therefore some insights about pratice-oriented requirements. So I would 
be happy to analyze existing or future LP WANs technologies accordingly 
and contribute to the documents.

Greetings,
Florian Meier

[1] Florian Meier and Volker Turau. An Analytical Model for Fast and 
Verifiable Assessment of Large Scale Wireless Mesh Networks. In 
Proceedings of the Design of Reliable Communication Networks (DRCN), 
March 2015

[2] Florian Meier and Volker Turau. Analytical Model for IEEE 802.15.4 
Multi-Hop Networks with Improved Handling of Acknowledgements and 
Retransmissions. arXiv:1501.07594, January 2015

[3] http://www.ti5.tu-harburg.de/research/projects/autor/

---

From: Bill Gage <[email-masked]>
Date: Wed, 2 Dec 2015 15:18:50 +0000

I agree. I think this "low bandwidth" (or rather "small PHY PDU") clarification will also help to distinguish the problem area from those of other working groups (like 6lo and core).

I also suggest that the concept of "low energy operation (over the radio link)" be retained because there are also many use cases where the devices are expected to operate for years using only battery power. For example, this may have an impact if one of the goals is to minimise the number of PHY PDUs that are transmitted and received by a device. 

Note that "low energy operation" is influenced by more than just (low) transmit power. The name "LP-WAN" is probably okay for now because it provides some immediate context for the reader. The problem statement can be used to clarify any ambiguities.

Cheers ...

> From: Timothy J. Salo [mailto:[email-masked]]
> Sent: Tuesday, December 1, 2015 6:01 PM
> To: [email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 2 Dec 2015 17:32:48 +0100

Dear all,

from Worldsensing side we have deep experience with that technology an
thousands of nodes deployed worldwide. I guess we can contribute
significantly to it.

regards,
Xavi

2015-12-02 12:18 GMT+01:00 Florian Meier <[email-masked]>:

> Many of the traditional constraints are getting less relevant (especially
> regarding the computational power and memory of the nodes), while we still
> can not overcome the physics of wireless transmissions.
>
> e.g. Etherpad, Google Docs..., so that everyone can contribute his personal
> expertise. Otherwise, we probably end up with very biased documents.
>
> I personally have some experience in medium access, especially with regard
> to scalability [1,2], that might also be relevant for LP WANs (the papers
> are focused on IEEE 802.15.4 mesh networks, but the techniques can be
> easily adapted). Furthermore, I take part in a research project about the
> implementation of an actual industrial application that might highly
> benefit from LP WANs [3] and have therefore some insights about
> pratice-oriented requirements. So I would be happy to analyze existing or
> future LP WANs technologies accordingly and contribute to the documents.
>
> Greetings,
> Florian Meier
>
> Verifiable Assessment of Large Scale Wireless Mesh Networks. In Proceedings
> of the Design of Reliable Communication Networks (DRCN), March 2015
>

---

From: Bill Gage <[email-masked]>
Date: Wed, 2 Dec 2015 17:58:30 +0000

Hello Alexander -

Item (4) Best Current Practices may be replaced by, or augmented with, a gap analysis. Or do you plan to put the gap analysis into the problem statement (2)?

Cheers ...

> From: Alexander Pelov [mailto:[email-masked]]
> Sent: Tuesday, December 1, 2015 5:13 PM
> To: [email-masked]

---

From: Zhen Cao <[email-masked]>
Date: Wed, 2 Dec 2015 22:23:01 +0100

Hi Alexander,

Nice summary.

But I do not think IETF is the place to document L2 LP-WAN techs.
However, implications of L2 to the upper layer and L2 adaption layer
are within the scope.

Best regards,
Zhen
On Tue, Dec 1, 2015 at 11:12 PM, Alexander Pelov <[email-masked]> wrote:
> I'd like to propose to start a work on a couple of documents related to the
> above issues. These include, for the moment:

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 3 Dec 2015 00:53:39 +0100

Dear Bill,

Thanks for the suggestion - I agree that the document could probably be 
best re-framed as a gap analysis document. At some point, we could merge 
it with the problem statement, if this leads to a more clear description 
of the topic. Would you be willing to contribute to any of these two 
documents?

Thanks!

Best,
Alexander

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 3 Dec 2015 01:10:19 +0100

Dear Zhen,

The purpose of collecting information on L2 LP-WAN technologies is only 
to be able to extract the relevant constraints and use-cases for the 
future work on bringing IP to them (+ management, AAA, others from the 
IETF world). I don't think that spending a couple of days on agreeing 
what constitutes a typical MTU, a minimal bitrate, or a connectivity 
pattern in LP-WANs would be a waste of time.

On the contrary. If we don't do this work now, we cannot be sure that 
our existing tools do not fit our needs. I agree with you that I would 
rather have a ready-to-use list and skim through it (we all have some 
ideas on some of the technologies). But in the absence of such source, I 
don't think we have a choice. There are already some people that 
expressed willingness to contribute to this effort (and the Google Doc 
has been updated already).

I will be glad if you would also consider contributing, for example by 
looking for critical analysis or other state-of-the-art document that we 
should take into account.

Best,
Alexander

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Dec 2015 12:01:40 +0000

I think that fewer small docs from different specialists may have more weight, even if in the end we merge some of that work as we did in DetNet.

The characterization doc that explains what's so special and yet common to these technologies, and why it is outside existing scopes will be critical. 

So will be a problem statement that clarifies actual needs that cannot be addressed by existing IETF work/ working groups.

Cheers 
Pascal

> Le 3 déc. 2015 à 01:10, Alexander Pelov <[email-masked]> a écrit :
> 
> Dear Zhen,
> 
> The purpose of collecting information on L2 LP-WAN technologies is only to be able to extract the relevant constraints and use-cases for the future work on bringing IP to them (+ management, AAA, others from the IETF world). I don't think that spending a couple of days on agreeing what constitutes a typical MTU, a minimal bitrate, or a connectivity pattern in LP-WANs would be a waste of time.
> 
> On the contrary. If we don't do this work now, we cannot be sure that our existing tools do not fit our needs. I agree with you that I would rather have a ready-to-use list and skim through it (we all have some ideas on some of the technologies). But in the absence of such source, I don't think we have a choice. There are already some people that expressed willingness to contribute to this effort (and the Google Doc has been updated already).
> 
> I will be glad if you would also consider contributing, for example by looking for critical analysis or other state-of-the-art document that we should take into account.
> 
> Best,
> Alexander
> 
>

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 2 Dec 2015 18:28:25 -0700

I like LPWAN - but I will admit I'm biased.

         Geoff

On 12/02/2015 01:43 AM, Patrick Wetterwald (pwetterw) wrote:
> From: lp-wan <[email-masked] 
> <mailto:[email-masked]>> on behalf of Laurent Toutain 
> <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Carles Gomez Montenegro 
> <[email-masked] <mailto:[email-masked]>>, weigengyu 
> <[email-masked] <mailto:[email-masked]>>, Alexander 
> Pelov <[email-masked] <mailto:[email-masked]>>
>     On Wed, Dec 2, 2015 at 8:55 AM, Xavier Vilajosana
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         To complement what Carles says, with 15.4g we can have stable
>         links of 2-3km which IMHO is not PAN but WAN (or MAN if you
>         like).
>
>             > The base of these documents may include the following
>             (but not limited
>             > to):
>     | [email-masked] <mailto:[email-masked]>         |
>     [email-masked]
>     <mailto:[email-masked]>    |

---

From: "weigengyu" <[email-masked]>
Date: Wed, 9 Dec 2015 11:42:31 +0800

Hi Alexander,

Your works are appreciated.
Especially, the docs you mentioned in your email should be as a basis for 
discussions.

I agree to do things based on L2 LP-WAN technologies and have suggestions:

1. Make definitions about WAN, wireless WAN and LP-WAN in this WG.

2. About IEEE802.15.x, IEEE's doc should be noticed no matter what  people 
call it.
IEEE 802.15.4TM-2011: "IEEE Standard for Local and metropolitan area 
networks--Part 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPANs)".

3. For wireless L2 technogies, the range of radio signal should be 
concerned.
In LoRa, the range is one hop distance.
In LTN,  "LTN enables long range data transportation (distances up to 40 km 
in open field) and
has the capacity to communicate with underground equipment, using minimal 
power consumption."

According to ETSI GS LTN 001 V1.1.1 (2014-09), the contents in
"Table 2: Usage oriented characteristics related to the devices connected to 
the network,
Typical distance "day light indoor" (see note 1) density of antenna
• Range from a device to an antenna" is 10-12 km (city) and 40-60 km 
(countyside)"

In the same table, IEEE802.15.4 is 10m.

So, what technologyies are intended to concern as WAN and LP-WAN 
technologies?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Alexander Pelov
Sent: Thursday, December 03, 2015 8:10 AM
To: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

Dear Zhen,

Best,
Alexander

Le 02/12/2015 22:23, Zhen Cao a écrit :
>> the

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 10 Dec 2015 00:13:42 +0100

Dear Gengyu,

Le 09/12/2015 04:42, weigengyu a écrit :
> Especially, the docs you mentioned in your email should be as a basis 
> for discussions.
>
Thanks. I think this was somehow implicit, but should be made explicit 
in the document.

>
> 2. About IEEE802.15.x, IEEE's doc should be noticed no matter what  
> people call it.
Agreed.

> In LTN,  "LTN enables long range data transportation (distances up to 
> 40 km in open field) and
> has the capacity to communicate with underground equipment, using 
> minimal power consumption."
>
> "Table 2: Usage oriented characteristics related to the devices 
> connected to the network,
I think we can definitely out-rule 10m as not WAN. However, we'll 
include 802.15.4k and 802.15.4g.

Best,
Alexander

---

From: "weigengyu" <[email-masked]>
Date: Thu, 10 Dec 2015 13:58:38 +0800

Hi Alexander,

> I think we can definitely out-rule 10m as not WAN. However, we'll include 
> 802.15.4k and 802.15.4g.

The following titles are 802.15.4g and 802.15.4k
IEEE Standard for Local and metropolitan area networks—
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
Amendment 3: Physical Layer (PHY) Specifications for Low-Data-Rate, 
Wireless, Smart Metering Utility Networks

Local and metropolitan area networks—
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
Amendment 5: Physical Layer Specifications for Low Energy, Critical 
Infrastructure Monitoring Networks

In 802.15.4.k
4.3 Network topologies
4.3.1 Star network formation

Low energy critical infrastructure monitoring (LECIM) networks primarily 
operate in a star topology.
LECIM networks are typically asymmetric in energy supply and capability, 
having a PAN coordinator that
is mains powered (or otherwise provided a substantial power source) and 
energy and/or cost constrained
devices. The PAN coordinator typically monitors the channel more often than 
a device. A device sleeps
unless it has a data frame to send.

By the above contexts, the range of radio link between a device and 
coordinator is short.
And wide area coverages are based on longer range of links beween 
coordinators, which are main powered, not low power.

So, it is better to have clear and explicit descriptions of LP-WAN with some 
reference networks.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Alexander Pelov
Sent: Thursday, December 10, 2015 7:13 AM
To: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

Dear Gengyu,

Agreed.

> In LTN,  "LTN enables long range data transportation (distances up to 40 
> km in open field) and
> "Table 2: Usage oriented characteristics related to the devices connected 
> to the network,

Best,
Alexander

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 10 Dec 2015 08:26:48 +0100

Gengyu,

I don't understand what you are proposing at all. IEEE802.15.4g has a range
of multiple km, and definitly falls in the scope of LP-WAN.

Thomas

On Thu, Dec 10, 2015 at 6:58 AM, weigengyu <[email-masked]> wrote:

> devices. The PAN coordinator typically monitors the channel more often
> than a device. A device sleeps
> So, it is better to have clear and explicit descriptions of LP-WAN with
> some reference networks.
>
> Regards,
>
> Gengyu WEI

---

From: "weigengyu" <[email-masked]>
Date: Thu, 10 Dec 2015 21:44:24 +0800

Hi Thomas, 

Just want to be clear what the range of LP-WAN is. 

Here are two references: 
[1] On communication and interference range of IEEE 802.15.4g smart utility networks
Author(s): Chin-Sean Sum, Nat. Inst. of Inf. & Commun. Technol. (NICT), Yokosuka, Japan, Rahman, M.A. ; Liru Lu ; Kojima, F. ; Harada, H.

[2] A star-topology sensor network system for agriculture using 802.15.4k standard
Authors: Yasutaka Tada, Shuzo Kato

By Ref.1 on 802.15.4g, it could be about 100 meters.  
“As a result, we have found that the achievable communication range of SUN devices in the GHz-order bands, 
the higher-UHF bands and the lower-UHF bands are 33m, 65m and 104m respectively. 
The critical interferer-to-victim distance below which, causing intolerable degradation to the victim receiver, 
is found to be 20m for typical urban and 35m for hilly rural environment.”

By Ref.2 on 802.15.4k, it could be several kilometers.
“This paper introduces a sensor network with star topology for agriculture applications in Japan. 
The system is based on Direct Sequence Spread Spectrum (DSSS) PHY of the IEEE 802.15.4k standard. 
It will operate It can operate in 920–928 MHz band with MHz bandwidth according to Japanase regulations. 
According to our analysis it has a range of 20 kms in line of sight and 5 kms in none-line-of-sight environment.”

Maybe you have other reference papers.

The L2 technologies woule be different if the radio range is different when concerning effeciency.

Regards,

Gengyu WEI

From: Thomas Watteyne 
Sent: Thursday, December 10, 2015 3:26 PM
To: weigengyu 
Cc: Alexander Pelov ; [email-masked] 
Subject: Re: [lp-wan] Next steps on LP-WANs

Gengyu, 

I don't understand what you are proposing at all. IEEE802.15.4g has a range of multiple km, and definitly falls in the scope of LP-WAN.

Thomas

  Hi Alexander,

    I think we can definitely out-rule 10m as not WAN. However, we'll include 802.15.4k and 802.15.4g.

  The following titles are 802.15.4g and 802.15.4k
  IEEE Standard for Local and metropolitan area networks—
  Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
  Amendment 3: Physical Layer (PHY) Specifications for Low-Data-Rate, Wireless, Smart Metering Utility Networks

  Local and metropolitan area networks—
  Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
  Amendment 5: Physical Layer Specifications for Low Energy, Critical Infrastructure Monitoring Networks

  In 802.15.4.k
  4.3 Network topologies

  Low energy critical infrastructure monitoring (LECIM) networks primarily operate in a star topology.
  LECIM networks are typically asymmetric in energy supply and capability, having a PAN coordinator that
  is mains powered (or otherwise provided a substantial power source) and energy and/or cost constrained
  devices. The PAN coordinator typically monitors the channel more often than a device. A device sleeps
  unless it has a data frame to send.

  By the above contexts, the range of radio link between a device and coordinator is short.
  And wide area coverages are based on longer range of links beween coordinators, which are main powered, not low power.

  So, it is better to have clear and explicit descriptions of LP-WAN with some reference networks.

  Regards,

  Gengyu WEI

  Dear Gengyu,

    Hi Alexander,

    Your works are appreciated.
    Especially, the docs you mentioned in your email should be as a basis for discussions.

    2. About IEEE802.15.x, IEEE's doc should be noticed no matter what  people call it.
    IEEE 802.15.4TM-2011: "IEEE Standard for Local and metropolitan area networks--Part 15.4:
    Low-Rate Wireless Personal Area Networks (LR-WPANs)".

  Agreed.

    3. For wireless L2 technogies, the range of radio signal should be concerned.
    In LoRa, the range is one hop distance.
    In LTN,  "LTN enables long range data transportation (distances up to 40 km in open field) and
    has the capacity to communicate with underground equipment, using minimal power consumption."

    According to ETSI GS LTN 001 V1.1.1 (2014-09), the contents in
    "Table 2: Usage oriented characteristics related to the devices connected to the network,
    Typical distance "day light indoor" (see note 1) density of antenna
    • Range from a device to an antenna" is 10-12 km (city) and 40-60 km (countyside)"

    So, what technologyies are intended to concern as WAN and LP-WAN technologies?

  Best,
  Alexander

    Regards,

    Gengyu WEI

    Dear Zhen,

    Best,
    Alexander

      Hi Alexander,

      Nice summary.

      Best regards,
      Zhen

---

From: Bill Gage <[email-masked]>
Date: Thu, 10 Dec 2015 14:16:09 +0000

Hello Gengyu -

As mentioned in another set of emails on this reflector, perhaps "Bandwidth-Constrained Networks" (or rather "small PHY PDU") is a better characterisation of the problem area.

"Low energy operation" is also important in many deployments where devices are expected to operate with only battery power for many years. Note that "low energy operation" encompasses more than just (low) transmit power.

Cheers ...

> From: weigengyu [mailto:[email-masked]]
> Sent: Thursday, December 10, 2015 8:44 AM
> Author(s): Chin-Sean Sum, Nat. Inst. of Inf. & Commun. Technol. (NICT),
> Yokosuka, Japan, Rahman, M.A. ; Liru Lu ; Kojima, F. ; Harada, H.
> The critical interferer-to-victim distance below which, causing
> intolerable degradation to the victim receiver,
> I don't understand what you are proposing at all. IEEE802.15.4g has a
> range of multiple km, and definitly falls in the scope of LP-WAN.
> 
> Thomas
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2015 14:31:31 +0000

Dear all:

I’m not sure we want to enumerate radios that can reach a certain range but radios that exhibit new constraints which either disqualifies the existing work at the IETF, or requires new operations to complete them.

As it goes, 4g qualifies as an Neighbor Area Network (that’s how the work was dubbed initially) but does not seem to pose particular problem compared to, say, 802.15.4 in the 2.4GHz range. At least it is successfully used for large smartgrid meshes using combinations of existing IETF technologies such as RPL and 6LoWPAN.

This contrasts with LoRA or SigFox, for which transporting an IPv6 MTU or expecting asynchronous responses is certainly challenging. I understand that we care to understand what the new issues are and solve them starting from the most generic ones.

Cheers,

Pascal

From: lp-wan [mailto:[email-masked]] On Behalf Of weigengyu
Sent: jeudi 10 décembre 2015 14:44
To: Thomas Watteyne <[email-masked]>
Cc: [email-masked]; Alexander Pelov <[email-masked]>
Subject: Re: [lp-wan] Next steps on LP-WANs

Hi Thomas,

Here are two references:

Regards,

Gengyu WEI

From: Thomas Watteyne<mailto:[email-masked]>
Sent: Thursday, December 10, 2015 3:26 PM
To: weigengyu<mailto:[email-masked]>
Cc: Alexander Pelov<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] Next steps on LP-WANs

Gengyu,

Thomas

On Thu, Dec 10, 2015 at 6:58 AM, weigengyu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alexander,
I think we can definitely out-rule 10m as not WAN. However, we'll include 802.15.4k and 802.15.4g.

In 802.15.4.k
4.3 Network topologies

Regards,

Gengyu WEI

Dear Gengyu,

Best,
Alexander

Regards,

Gengyu WEI

Dear Zhen,

Best,
Alexander

Nice summary.

Best regards,
Zhen
On Tue, Dec 1, 2015 at 11:12 PM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 10 Dec 2015 18:46:17 +0100

Hi Gengyu,

the range for a 15.4g network depends also on the link budget of the
transducer. Commercial transducers today for 15.4g feature link budgets of
around 150dB. (see semtech sx1272 for example). With that link budget you
can easily reach 2km.

regards,
Xavi

2015-12-10 14:44 GMT+01:00 weigengyu <[email-masked]>:

> *From:* Thomas Watteyne <[email-masked]>
> *Sent:* Thursday, December 10, 2015 3:26 PM
> *To:* weigengyu <[email-masked]>
> *Cc:* Alexander Pelov <[email-masked]> ; [email-masked]
> *Subject:* Re: [lp-wan] Next steps on LP-WANs
>
> Gengyu,
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 10 Dec 2015 19:09:03 +0100

+1. 15.4g is a perfect fit for 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: Joaquin Cabezas <[email-masked]>
Date: Tue, 15 Dec 2015 15:32:33 +0100

+1 here too. We use 802.15.4g and the ranges are pretty impressive with 
a Texas Instruments CC1125 (and our secret sauce, of course!)

btw, I've just joined the list, this is a very hot topic and I hope this 
will be a very active mail list

BR,
Joaquín.

El 10/12/2015 a las 19:09, Thomas Watteyne escribió:
> On Thu, Dec 10, 2015 at 6:46 PM, Xavier Vilajosana 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi Gengyu,
>
>     the range for a 15.4g network depends also on the link budget of
>     the transducer. Commercial transducers today for 15.4g feature
>     link budgets of around 150dB. (see semtech sx1272 for example).
>     With that link budget you can easily reach 2km.
>
>     regards,
>     Xavi
>
>
>
>     2015-12-10 14:44 GMT+01:00 weigengyu <[email-masked]
>     <mailto:[email-masked]>>:
>
>         Hi Thomas,
>         Author(s): Chin-Sean Sum, Nat. Inst. of Inf. & Commun.
>         Technol. (NICT), Yokosuka, Japan, Rahman, M.A. ; Liru Lu ;
>         Kojima, F. ; Harada, H.
>
>         “As a result, we have found that the achievable communication
>         range of SUN devices in the GHz-order bands,
>         The critical interferer-to-victim distance below which,
>         causing intolerable degradation to the victim receiver,
>         It will operate It can operate in 920–928 MHz band with MHz
>         bandwidth according to Japanase regulations.
>         According to our analysis it has a range of 20 kms in line of
>         sight and 5 kms in none-line-of-sight environment.”
>         *From:* Thomas Watteyne <mailto:[email-masked]>
>         *To:* weigengyu <mailto:[email-masked]>
>         *Cc:* Alexander Pelov <mailto:[email-masked]> ; [email-masked]
>         <mailto:[email-masked]>
>         I don't understand what you are proposing at all.
>         IEEE802.15.4g has a range of multiple km, and definitly falls
>         in the scope of LP-WAN.
>
>         Thomas
>         On Thu, Dec 10, 2015 at 6:58 AM, weigengyu
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hi Alexander,
>
>                 I think we can definitely out-rule 10m as not WAN.
>                 However, we'll include 802.15.4k and 802.15.4g.
>
>
>             Amendment 3: Physical Layer (PHY) Specifications for
>             Low-Data-Rate, Wireless, Smart Metering Utility Networks
>
>             Amendment 5: Physical Layer Specifications for Low Energy,
>             Critical Infrastructure Monitoring Networks
>
>             In 802.15.4.k
>             4.3 Network topologies
>             Low energy critical infrastructure monitoring (LECIM)
>             networks primarily operate in a star topology.
>             LECIM networks are typically asymmetric in energy supply
>             and capability, having a PAN coordinator that
>             is mains powered (or otherwise provided a substantial
>             power source) and energy and/or cost constrained
>             devices. The PAN coordinator typically monitors the
>             channel more often than a device. A device sleeps
>             And wide area coverages are based on longer range of links
>             beween coordinators, which are main powered, not low power.
>
>                 In LTN,  "LTN enables long range data transportation
>                 (distances up to 40 km in open field) and
>                 has the capacity to communicate with underground
>                 equipment, using minimal power consumption."
>
>                     On Tue, Dec 1, 2015 at 11:12 PM, Alexander Pelov
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>
> www.thomaswatteyne.com <http://www.thomaswatteyne.com>

---

From: Florian Meier <[email-masked]>
Date: Tue, 15 Dec 2015 16:05:19 +0100

Is there even a standard procedure to measure "range"?
Without that it is quite useless to name any ranges, especially since 
the environment has such a huge impact.

For example from own measurements I can say that 500mW pure 2-FSK, 5 
kbps @ 869 MHz generated with a CC110L/CC1190 combo can easily reach 
several kilometers with line-of-sight, but the connection might be 
useless at several meters if something blocks the view.

And even line-of-sight measurements are very difficult and hard to 
reproduce. It took me forever to find a suitable location with >1km 
line-of-sight without any trees in-between.

Any ideas? Or are we just going to trust the statements by the 
manufacturers?

Greetings,
Florian Meier

On 15.12.2015 15:32, Joaquin Cabezas wrote:
>> <<mailto:[email-masked]>[email-masked]>
>> wrote:
>>
>>     Hi Gengyu,
>>
>>     2015-12-10 14:44 GMT+01:00 weigengyu
>>     <<mailto:[email-masked]>[email-masked]>:
>>
>>         Hi Thomas,
>>         <<mailto:[email-masked]>[email-masked]> wrote:
>>
>>             Hi Alexander,
>>
>>             To: <mailto:[email-masked]>[email-masked]
>>                 To: <mailto:[email-masked]>[email-masked]
>>                     <<mailto:[email-masked]>[email-masked]> wrote:
>>
>>                     <mailto:[email-masked]>[email-masked]
>>                     <https://www.ietf.org/mailman/listinfo/lp-wan>https://www.ietf.org/mailman/listinfo/lp-wan
>>
>>

---

From: Joaquin Cabezas <[email-masked]>
Date: Tue, 15 Dec 2015 16:12:58 +0100

I can't find my spherical cow on this business :D I guess 'range' is 
only valid once you have deployed a similar scenario, and you are able 
to provide a confidence interval based on experience. The battle over 
the range reminds me of the clock speed war for processors back in the 
90s (the Megahertz_myth)

BR,
Joaquín.

---

From: Bill Gage <[email-masked]>
Date: Tue, 15 Dec 2015 15:21:24 +0000

Why do we care about range? Can someone tell me how range impacts anything of interest to this group?

The only area where I have seen range play a role is with *short* range communications where you need to use multi-hop protocols to get from source to destination. It's not obvious to me that there is anything new being proposed here that would necessitate reopening this subject in a new WG.

Cheers ...

> From: Florian Meier [mailto:[email-masked]]
> Sent: Tuesday, December 15, 2015 10:05 AM
> To: [email-masked]
> >>                     <https://www.ietf.org/mailman/listinfo/lp-
> wan>https://www.ietf.org/mailman/listinfo/lp-wan
> >>
> >>

---

From: Florian Meier <[email-masked]>
Date: Tue, 15 Dec 2015 16:34:06 +0100

I would say because it is called lp-WAn, where the WA stands for wide area.
So for me the actual point with lp-wans is to have a suitable range of 
several kilometers (or at least one) and THAT is the real challenge for 
wireless networks operating in license free bands.
For everything with shorter range I do not see a reason for a "new" 
technology (named lp-wan) since we already have common IEEE 802.15.4 
etc. Or do I get something wrong here?

Greetings,
Florian Meier

@Bill Gage: Sorry for double-posting, I hit the wrong reply button.

---

From: Bill Gage <[email-masked]>
Date: Tue, 15 Dec 2015 15:41:04 +0000

But this is an IETF group, not a radio group, so I ask again -- how does "range" impact anything of interest?

In a previous thread, it was argued that the real issue is "constrained bandwidth" or, more accurately, "small PHY PDUs". I think that is the differentiator. The discussion over range isn't highlighting any issue that haven't been addressed by other IETF WGs.

Cheers ...

@Florian: me too :-}

> Sent: Tuesday, December 15, 2015 10:34 AM
> > The only area where I have seen range play a role is with *short* range
> communications where you need to use multi-hop protocols to get from
> source to destination. It's not obvious to me that there is anything new
> being proposed here that would necessitate reopening this subject in a new
> WG.
> >
> > Cheers ...
> >
> >>>>          [1] On communication and interference range of IEEE
> 802.15.4g
> >>>>          smart utility networks
> >>>>
> >>>>          the higher-UHF bands and the lower-UHF bands are 33m, 65m
> and
> >>>>          104m respectively.
> >>>>          “This paper introduces a sensor network with star topology
> for
> >>>>          agriculture applications in Japan.
> >>>>          The system is based on Direct Sequence Spread Spectrum
> (DSSS)
> >>>>          PHY of the IEEE 802.15.4k standard.
> >>>>                  1. Make definitions about WAN, wireless WAN and LP-
> WAN
> >>>>                  in this WG.
> >>>>
> >>>>                  2. About IEEE802.15.x, IEEE's doc should be noticed
> no
> >>>>                  matter what people call it.
> >>>>                  So, what technologyies are intended to concern as
> WAN
> >>>>                  and LP-WAN technologies?
> >>>>
> >>>>
> >>>>              Best,
> >>>>              Alexander
> >>>>
> >>>>
> >>>>                  Regards,
> >>>>
> >>>>
> >>>>                  Gengyu WEI
> >>>>                  future work on bringing IP to them (+ management,
> AAA,
> >>>>                  others from the
> >>>>                  what constitutes a typical MTU, a minimal bitrate,
> or
> >>>>                  a connectivity
> >>>>                  our existing tools do not fit our needs. I agree
> with
> >>>>                  you that I would
> >>>>                  ideas on some of the technologies). But in the
> absence
> >>>>                  of such source, I
> >>>>                      However, implications of L2 to the upper layer
> and
> >>>>                      L2 adaption layer
> >>>>                      are within the scope.
> >>>>
> >>>>                      Best regards,
> >>>>                      Zhen
> >>>>                          4) Best Current Practices that could apply
> to
> >>>>                          LP-WANs
> >>>>

---

From: Pat Kinney <[email-masked]>
Date: Tue, 15 Dec 2015 09:43:41 -0600

I agree with the comments that ranges are often specmanship, i.e. numbers on the spec sheet that are often meaningless to the users' needs.  

But as to the question about concern for range and how it impacts protocols, the trade-offs in the physical layer and MAC sublayer are significant.  The PHY gets range by either increasing transmit power (limited by regulatory) or by increasing sensitivity.  A dominant method to increasing sensitivity is by a reduction in the data rate to increase the energy per bit.  A lower date rate requires more energy in transmit and in receive due to increased message time.  So the protocols for long ranges need to be very stringent on how often to send messages, the amount of data in each message, the overhead for each message, and methodologies to avoid collisions to reduce retransmissions. 

Pat
 
On 15, Dec2015, at 9:21, Bill Gage <[email-masked]> wrote:

Cheers ...

---

From: Bill Gage <[email-masked]>
Date: Tue, 15 Dec 2015 15:47:40 +0000

+1.

This is essentially the discussion that was started in the earlier "Bandwidth-Constrained Networks" thread ...

> From: Pat Kinney [mailto:[email-masked]]
> Sent: Tuesday, December 15, 2015 10:44 AM
> I agree with the comments that ranges are often specmanship, i.e. numbers
> on the spec sheet that are often meaningless to the users' needs.
> 
> But as to the question about concern for range and how it impacts
> protocols, the trade-offs in the physical layer and MAC sublayer are
> significant.  The PHY gets range by either increasing transmit power
> (limited by regulatory) or by increasing sensitivity.  A dominant method
> to increasing sensitivity is by a reduction in the data rate to increase
> the energy per bit.  A lower date rate requires more energy in transmit
> and in receive due to increased message time.  So the protocols for long
> ranges need to be very stringent on how often to send messages, the amount
> of data in each message, the overhead for each message, and methodologies
> to avoid collisions to reduce retransmissions.
> 
> Pat
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Dec 2015 15:48:24 +0000

Hello Florian:

Whether the tech is a b or c, the question is what's new for the IETF to work on. Hopefully the answer is common to a b and c and whether we did not list tech d does not really matter if it has the same problems and we end up solving them.

Another angle is that if a mesh that operates on the NAN with 15.4g works the same as a mesh operating indoors with 802.15.4  in the 2.4 from the IETF protocols standpoint then it does not matter that it is long range, the problem is already solved.

I'm more interested - like Bill I understand - in qualifying LPWAN as hub and spoke with particular issues like long sleep periods, ultra-short MTU, and very slow transmission rate, and see if existing IETF work covers this case or not. If not, wee what we can do.

Cheers,

Pascal

> From: lp-wan [mailto:[email-masked]] On Behalf Of Florian Meier
> Sent: mardi 15 décembre 2015 16:34
> To: [email-masked]
> So for me the actual point with lp-wans is to have a suitable range of several
> kilometers (or at least one) and THAT is the real challenge for wireless networks
> operating in license free bands.
> technology (named lp-wan) since we already have common IEEE 802.15.4 etc.
> Or do I get something wrong here?
> 
> Greetings,
> Florian Meier
> 
> communications where you need to use multi-hop protocols to get from source
> to destination. It's not obvious to me that there is anything new being proposed
> here that would necessitate reopening this subject in a new WG.
> >
> > Cheers ...
> >
> >>> +1 here too. We use 802.15.4g and the ranges are pretty impressive
> >>> +with
> >>> btw, I've just joined the list, this is a very hot topic and I hope
> >>> this will be a very active mail list
> >>>
> >>> BR,
> >>> Joaquín.
> >>>
> >>>>              Part 15.4: Low-Rate Wireless Personal Area Networks
> >>>> (LR-
> >> WPANs)
> >>>>              Part 15.4: Low-Rate Wireless Personal Area Networks
> >>>> (LR-
> >> WPANs)
> >>>> Research Scientist & Innovator, Inria Sr Networking Design Eng,
> >>>> Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF
> >>>> 6TiSCH
> >>>>

---

From: Florian Meier <[email-masked]>
Date: Tue, 15 Dec 2015 17:17:20 +0100

I think that is a very good point to differentiate between the 
technologies by there requirements for the upper layers and not the 
achievements on the physical layer.
Of course, as Pet has elaborated and I was suggesting, there is a very 
high correlation, but now I think I got Bill's point and I like the idea 
to distance from the actual technology and to focus on the issues that 
Pascal has mentioned.

By the way: I am very curious how security will be implement under such 
constraints. Even with the 127 bytes MTU and 250 kBit/s of IEEE 802.15.4 
that is far from easy.

Greetings,
Florian Meier

---

From: Joaquin Cabezas <[email-masked]>
Date: Tue, 15 Dec 2015 18:13:16 +0100

Yesterday I attended a 'Machina Research' webinar and there was a 
definition for the "WA" part: "At least 500m of signal range directly 
between the gateway and the endpoint, assuming challenging conditions". 
Yet this is an arbitrary range and also with vague caracteristics 
("directly", "challenging"), we could consider something similar 
(independently from radios) and then go for the interesting topics 
related to IETF.

One topic that I particularly would like to address is the use of COAP 
on sleepy devices (related to 3. LP-WAN architectures)

BR,
Joaquín.

El 15/12/2015 a las 17:17, Florian Meier escribió:
> high correlation, but now I think I got Bill's point and I like the 
> idea to distance from the actual technology and to focus on the issues 
> that Pascal has mentioned.
>
> By the way: I am very curious how security will be implement under 
> such constraints. Even with the 127 bytes MTU and 250 kBit/s of IEEE 
> 802.15.4 that is far from easy.
>
> Greetings,
> Florian Meier
>
>> Whether the tech is a b or c, the question is what's new for the IETF 
>> to work on. Hopefully the answer is common to a b and c and whether 
>> we did not list tech d does not really matter if it has the same 
>> problems and we end up solving them.
>>
>> Another angle is that if a mesh that operates on the NAN with 15.4g 
>> works the same as a mesh operating indoors with 802.15.4 in the 2.4 
>> from the IETF protocols standpoint then it does not matter that it is 
>> long range, the problem is already solved.
>>
>> I'm more interested - like Bill I understand - in qualifying LPWAN as 
>> hub and spoke with particular issues like long sleep periods, 
>> ultra-short MTU, and very slow transmission rate, and see if existing 
>> IETF work covers this case or not. If not, wee what we can do.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> source
>>>>>>>           the higher-UHF bands and the lower-UHF bands are 33m, 
>>>>>>> 65m and
>>>>>>>           104m respectively.
>>>>>>>           is found to be 20m for typical urban and 35m for hilly 
>>>>>>> rural
>>>>>>>           environment.”
>>>>>>>           “This paper introduces a sensor network with star 
>>>>>>> topology for
>>>>>>>           The L2 technologies woule be different if the radio 
>>>>>>> range is
>>>>>>>           different when concerning effeciency.
>>>>>>>           Regards,
>>>>>>>           Gengyu WEI
>>>>>>>               By the above contexts, the range of radio link 
>>>>>>> between a
>>>>>>>               device and coordinator is short.
>>>>>>>               So, it is better to have clear and explicit 
>>>>>>> descriptions
>>>>>>>               of LP-WAN with some reference networks.
>>>>>>>
>>>>>>>               Regards,
>>>>>>>
>>>>>>>               Gengyu WEI
>>>>>>>                   I agree to do things based on L2 LP-WAN 
>>>>>>> technologies
>>>>>>>                   and have suggestions:
>>>>>>>
>>>>>>>                   1. Make definitions about WAN, wireless WAN 
>>>>>>> and LP-WAN
>>>>>>>                   in this WG.
>>>>>>>
>>>>>>>               Thanks. I think this was somehow implicit, but 
>>>>>>> should be
>>>>>>>               made explicit
>>>>>>>               in the document.
>>>>>>>
>>>>>>>
>>>>>>>                   2. About IEEE802.15.x, IEEE's doc should be 
>>>>>>> noticed no
>>>>>>>                   IEEE 802.15.4TM-2011: "IEEE Standard for Local 
>>>>>>> and
>>>>>>>                   metropolitan area networks--Part 15.4:
>>>>>>>                   According to ETSI GS LTN 001 V1.1.1 (2014-09), 
>>>>>>> the
>>>>>>>                   contents in
>>>>>>>                   "Table 2: Usage oriented characteristics 
>>>>>>> related to
>>>>>>>                   the devices connected to the network,
>>>>>>>                   So, what technologyies are intended to concern 
>>>>>>> as WAN
>>>>>>>                   and LP-WAN technologies?
>>>>>>>
>>>>>>>
>>>>>>>               Best,
>>>>>>>               Alexander
>>>>>>>
>>>>>>>
>>>>>>>                   Regards,
>>>>>>>
>>>>>>>
>>>>>>>                   Gengyu WEI
>>>>>>>                   The purpose of collecting information on L2 
>>>>>>> LP-WAN
>>>>>>>                   technologies is only
>>>>>>>                   to be able to extract the relevant constraints 
>>>>>>> and
>>>>>>>                   use-cases for the
>>>>>>>                   future work on bringing IP to them (+ 
>>>>>>> management, AAA,
>>>>>>>                   others from the
>>>>>>>                   IETF world). I don't think that spending a 
>>>>>>> couple of
>>>>>>>                   days on agreeing
>>>>>>>                   what constitutes a typical MTU, a minimal 
>>>>>>> bitrate, or
>>>>>>>                   a connectivity
>>>>>>>                   our existing tools do not fit our needs. I 
>>>>>>> agree with
>>>>>>>                   you that I would
>>>>>>>                   rather have a ready-to-use list and skim 
>>>>>>> through it
>>>>>>>                   (we all have some
>>>>>>>                   don't think we have a choice. There are 
>>>>>>> already some
>>>>>>>                   people that
>>>>>>>                   expressed willingness to contribute to this 
>>>>>>> effort
>>>>>>>                   (and the Google Doc
>>>>>>>                       But I do not think IETF is the place to 
>>>>>>> document
>>>>>>>                       L2 LP-WAN techs.
>>>>>>>                       However, implications of L2 to the upper 
>>>>>>> layer and
>>>>>>>                       L2 adaption layer
>>>>>>>                       are within the scope.
>>>>>>>
>>>>>>>                       Best regards,
>>>>>>>                       Zhen
>>>>>>>                           4) Best Current Practices that could 
>>>>>>> apply to
>>>>>>>                           LP-WANs
>>>>>>>

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 15 Dec 2015 11:50:00 -0600

On 12/15/2015 9:43 AM, Pat Kinney wrote:
> ... But as to the question about concern for range and how
> it impacts protocols, the trade-offs in the physical layer
> and MAC sublayer are significant.  The PHY gets range by
> either increasing transmit power (limited by regulatory)
> or by increasing sensitivity.  A dominant method to increasing
> sensitivity is by a reduction in the data rate to increase
> the energy per bit.  A lower date rate requires more energy in
> transmit and in receive due to increased message time.  So the
> protocols for long ranges need to be very stringent on how often
> to send messages, the amount of data in each message, the overhead
> for each message, and methodologies to avoid collisions to reduce
>retransmissions.

Absolutely.

My concern about referring to these networks as "low-power"
(rather than as "bandwidth-constrained") is that reusing
the name "low-power" may lead us to believe that we can
simply reuse, without examination, existing IETF protocols
developed for low-power wireless networks.

Of course, this would probably work.  But, it probably wouldn't
work as well as protocols that were designed to minimize bandwidth
usage (rather than to minimize the storage and processing required
at the nodes, as were the existing IETF low-power protocols).

As always, there is some tension between engineering excellence and
expediency.  I am suggesting that we favor engineering excellence
over expediency, that we examine this tradeoff rather than simply
reuse (without examination) existing IETF solutions developed for
low-power wireless networks.  I also understand that some, in this
instance, may favor expediency.

I suppose we could alternatively simply reuse the existing low-power
protocols, label these protocols developed (or applied) by this
proposed working group as "experimental", and see how well they
actually work in bandwidth-constrained environments.

-tjs

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 15 Dec 2015 11:59:20 -0600

On 12/15/2015 9:41 AM, Bill Gage wrote:
> ... In a previous thread, it was argued that the real issue
> is "constrained bandwidth" or, more accurately, "small PHY PDUs". ...

In my view, constrained bandwidth and small PHY PDUs are somewhat
unrelated [1].

We have experience with small PHY PDUs.  ATM uses 48-byte cells,
although the loss rate for ATM is many, many orders of magnitude
less than that of wireless networks, so existing solutions may
not be directly applicable.

I believe that the constrained bandwidth is the characteristic
that will most affect the design of protocols for supporting
IP over these networks.  Protocols optimized for these
environments should probably trade processing and storage for
bandwidth.  It is also likely that some traditional IP-related
functionality should not be supported by these networks (if
this would reduce bandwidth usage).

[1]  OK, OK, you don't want to run really large PDUs in
environments, because the relatively high bit-error rates
will cause unreasonably high packet-loss rated.  But, we
are already using relatively small PDUs with 802.15.4.

-tjs

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 15 Dec 2015 19:56:38 +0100

Dear all,

Indeed, what we're interested in are the constraints these radios put on 
the upper layers. The first document that we'll produce is on exactly 
this and will be based on the table started by Ana, where everyone's 
been contributing for the past weeks.

For me personally, Low-Power WAN, are a separate class of networks, 
because of the combination of the following characteristics:
- one-hop topology (no need for routing on the radio link)
- low throughput (possibly orders of magnitude lower than what we're 
used to seeing in most LLNs)
- in license-free bands -> duty-cycling + very sleepy nodes -> DTN-like 
behavior
- in license-free bands + low throughput -> limited PDU size (some 
technologies limit to 12 Bytes)
- long-range -> ultra-dense networks (50k-100+k nodes)
- long-range, in license-free bands -> coexistence of multiple 
ultra-dense networks
- long-range, in license-free bands -> extreme case of hidden-node 
collisions -> increased packet loss probability
- long-range -> large-scale deployments (e.g. covering a city, or a 
country) -> mobility management, roaming
- (in some cases) uni-directional communications for non negligible 
fraction of an end-point lifetime

I would (somewhat arbitrarily, somewhat from deployment experience) put 
the limits at 1.5 km in urban, and 10 km in line-of-sight, with 
omni-directional antennas. This, however, should be more a rule of 
thumb, and I'd consider any technology that has the aforementioned 
characteristics to be LP-WAN.

These characteristics are maybe incomplete, but I think they are a good 
starting for the gap analysis / problem statement. Do you see anything 
that's missing? Or maybe a point that should be put in a separate category?

Best,
Alexander

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 15 Dec 2015 13:09:19 -0600

On 12/15/2015 12:56 PM, Alexander Pelov wrote:
> ...
> ...

If what you want is a working group that works on low-data-rate,
wireless, smart metering utility networks, then I think that's what you
should call the working group.

There are a _lot_ of low-power, wide-area, wireless networks that meet
many, but not all, of the criteria that you specify.  It doesn't seem
to me that you ought to select an inclusive name, like "low-power", when
you want to address only a very small portion of what that name implies.

-tjs

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 15 Dec 2015 13:48:34 -0600

I question many of the implications that you appear to be suggesting.
Perhaps, you should just enumerate the characteristics of the networks
that you want to focus on, rather than seemingly trying to justify the
design of a particular technology or product.

> - one-hop topology (no need for routing on the radio link)

This is pretty significant, I think.  I assume that this means
that there is never, ever any need to run an IP routing protocol
over these networks.  Or, a link-layer routing protocol.

(I keep wondering why you want to run IP, but that question is best
left to another thread.)

What are the chances that in the future that someone will want to
extend these networks to employ routing?  That is, that they will
want to layer IP routing on top of these networks.

> used to seeing in most LLNs)

Yes.  And, at a system level, bandwidth may be the most constrained
resource.  As such, a good system design should probably be willing
to trade other resources for bandwidth.

> - in license-free bands -> duty-cycling + very sleepy nodes -> DTN-like

This isn't an implication of using license-free bands.  It is really
more an implication of using battery-powered nodes (or any nodes
with limited electrical energy available).

Personally, I would be cautious about referencing DTN.  DTN implies
that bundles (or something) are passed from node-to-node over a
multi-hop path, where at any given instant there is unlikely to be
an end-to-end path.  But, since you aren't doing any routing, this
reference seems more likely to cause confusion and false analogies.

> technologies limit to 12 Bytes)

Neither license-free bands or low throughput imply really small
PDU sizes.  I have narrowband data radios that support both
licensed and license-free bands that run 4,800 bps or 9,600 bps,
but have much larger PDUs.  Yes, really large PDUs in the face
of high (uncorrected) bit error rates are bad, because they
lead to high packet-loss rates.

I suspect that the choice of 12 byte PDUs was the result of some
other objectives, perhaps wanting to share a limited-bandwidth
channel with thousands or tens-of-thousands of end devices.

> - long-range -> ultra-dense networks (50k-100+k nodes)

No, there are lots of sparse low-bandwidth, wide-area networks.
The ones that you are interested in simply aren't.

I suppose you could argue that ultra-dense networks -> long-range,
because you couldn't fit that many nodes in a small area, but
the converse doesn't seem to be true.

> - long-range, in license-free bands -> coexistence of multiple

I see no reason this is true, in general.

Perhaps more significantly, lots of ultra-dense networks operating
in license-free bands implies a pretty high noise floor.  But, this
is a characteristic of license-free bands in urban environments in
general: there is a ton of devices in these bands.  In my experience,
admittedly somewhat limited, long-range communications in
license-free bands is rather difficult.

You might simply want to remind people that multiple networks
need to coexist gracefully, and so there needs to be some method
of isolating the networks.  Which is true for pretty much any
wireless network.

> collisions -> increased packet loss probability

Hidden node problems are pretty much a fact of life in most wireless
networks.  Of course, operation in license-free bands in urban
environments over any distance is difficult.  I suspect that a
lot of the packet loss is the result of interference from other
devices, but can't cite any research to prove this.

> country) -> mobility management, roaming

I don't think either wide-area operation or large-scale deployment
implies mobility.  Of course, you have nodes coming and going.
But, since these are defined to be one-hop networks, the topology
of the network never changes (it is still only a star).

What are you trying to suggest here?  That the collection of
end nodes is somewhat dynamic over time?  Well, dynamic beyond
that caused by using license-free bands in an urban environment?

> fraction of an end-point lifetime

This is an important, and somewhat unique characteristic, I think.
However, if this work focuses on smart meter networks, will this
result in a problem if someone tries to apply these networks to
different problems, one that make greater use of bidirectional
communications?  Should we focus on the currently conceived
application, or create a more general solution that may be
useful for a range of applications?

-tjs

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 15 Dec 2015 22:09:00 +0100

Dear Timothy,

Metering is just one of the cases which are covered by LP-WANs. Of 
course, I don't to limit our work to these networks. I just want to make 
sure, that we'll be able to get IP on them, along with the whole 
Internet ecosystem.

Which are the characteristics which do not seem generic enough to you?

Best,
Alexander

---

From: "weigengyu" <[email-masked]>
Date: Wed, 16 Dec 2015 10:13:05 +0800

Hi Alexznder,

Thanks for your clarifications.

There is still one,
In LP-WAN，Low Power means low transmission power, or low signal power.
Right or not?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Alexander Pelov
Sent: Wednesday, December 16, 2015 2:56 AM
To: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

Dear all,

Best,
Alexander

Le 15/12/2015 17:17, Florian Meier a écrit :
>> Whether the tech is a b or c, the question is what's new for the IETF to 
>> work on. Hopefully the answer is common to a b and c and whether we did 
>> not list tech d does not really matter if it has the same problems and we 
>> end up solving them.
>>
>> Another angle is that if a mesh that operates on the NAN with 15.4g works 
>> the same as a mesh operating indoors with 802.15.4 in the 2.4 from the 
>> IETF protocols standpoint then it does not matter that it is long range, 
>> the problem is already solved.
>>
>> I'm more interested - like Bill I understand - in qualifying LPWAN as hub 
>> and spoke with particular issues like long sleep periods, ultra-short 
>> MTU, and very slow transmission rate, and see if existing IETF work 
>> covers this case or not. If not, wee what we can do.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> several
>>>>>>>           The L2 technologies woule be different if the radio range 
>>>>>>> is
>>>>>>>               By the above contexts, the range of radio link between 
>>>>>>> a
>>>>>>>                   1. Make definitions about WAN, wireless WAN and 
>>>>>>> LP-WAN
>>>>>>>                   in this WG.
>>>>>>>
>>>>>>>               Thanks. I think this was somehow implicit, but should 
>>>>>>> be
>>>>>>>               made explicit
>>>>>>>               in the document.
>>>>>>>
>>>>>>>
>>>>>>>                   "Table 2: Usage oriented characteristics related 
>>>>>>> to
>>>>>>>                   IETF world). I don't think that spending a couple 
>>>>>>> of
>>>>>>>                   days on agreeing
>>>>>>>                   rather have a ready-to-use list and skim through 
>>>>>>> it
>>>>>>>                   (we all have some
>>>>>>>                   don't think we have a choice. There are already 
>>>>>>> some
>>>>>>>                   people that

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 15 Dec 2015 22:07:59 +0100

Dear Timothy,

Best,
Alexander

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 16 Dec 2015 13:07:40 +0100

Hello,

I would like to thanks all of you that have fill the table
https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing

This is a great job that finally can be use to determine the missing points
to be done as you have start discussing.

For continue the discussion, I start preparing a document for the
requirements of LPWAN networks.
Range is only important for upper layers at the IETF work we need to do,
because it determines the packet size, more the range is long, less data
can be transferred. So this property give us a limit of the MTU (very
short) that we need to take into account for the header stack we plan to
use.

Here you will find the document I started, please modify/complete
https://docs.google.com/document/d/12tjuGD80VlZsC_3AqIQrPcVuNgjO1V3dzxkOTVUsBAM/edit?usp=sharing

Thanks

Ana

On Tue, Dec 15, 2015 at 10:07 PM, Alexander Pelov <[email-masked]> wrote:

> Dear Timothy,
>
> Metering is just one of the cases which are covered by LP-WANs. Of course,
> I don't to limit our work to these networks. I just want to make sure, that
> we'll be able to get IP on them, along with the whole Internet ecosystem.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2015 09:27:01 -0500

I don't think it matters to be precise about what are LP-WANs, or whether
they can do metering or whether they are 5km or 15km or interplanetary distances.

What matters are:
     1) why are *they* different than WPANs, specifically, why do current
        6lowpan specifications fail?
        [Emphasis on *they*, because maybe there are different technologies
        which have different problems, and a single solution doesn't suit all]

     2) what are the topologies -- I was told strict star at first, but
        now I hear different things.

Maybe 6lowpan HC/IPHC/NHC works great, but that Efficient-ND timer BAR
needs to be multiplied by factor Q, and we just need to write that down.

Myself, I care really only about the topologies: if it's strict star with an
incumbent telco tower in the middle, then it's boring to me personally.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 16 Dec 2015 13:41:25 -0600

At the risk of repetition, a key element of 6tisch is the use of synchronization to enable determinism.  Even with a slotframe that has many shared timeslots, a device still needs to transmit or receive at specific times.  An lp-wan doesn’t need this synchronization, however, since there is no well known time, for a lp-wan leaf node to save energy the hub or central device needs to be always available.

As far as topology, the network could be a star network or a cluster of star networks.

Pat

On 16, Dec2015, at 8:27, Michael Richardson <[email-masked]> wrote:

What matters are:

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 16 Dec 2015 21:18:18 +0100

Hi Pat,

I tend to disagree. :) . we can have synchronization in lp-wan, with very
strict clocks and adaptive synchronization techniques. LP-WAN tend to be
subject to lower data rates as modulations are more robust using more chips
per bit or other smarter encoding. LoRa has a becon enabled mode of
operation which enables slight "synchronization".

For me one main difference is the payload size which tends to be smaller
than the 127B in common PAN networks. Also the fact that topologies tend to
be stars of stars or few hop networks.

regads,
Xavi

2015-12-16 20:41 GMT+01:00 [email-masked] <
[email-masked]>:

> At the risk of repetition, a key element of 6tisch is the use of
> synchronization to enable determinism.  Even with a slotframe that has many
> shared timeslots, a device still needs to transmit or receive at specific
> times.  An lp-wan doesn’t need this synchronization, however, since there
> is no well known time, for a lp-wan leaf node to save energy the hub or
> central device needs to be always available.
>

---

From: Joaquín Cabezas <[email-masked]>
Date: Wed, 16 Dec 2015 21:43:59 +0100

Indeed, for big smart metering deployments synchronization is desirable. I would add as a difference the massive number of devices that an LPWA concentrator is expected to serve. It will affect routing as well as efficiency on implementation.

BR,
Joaquín.

El 16/12/2015 21:18, Xavier Vilajosana <[email-masked]> escribió:
>
> Hi Pat,
>
> I tend to disagree. :) . we can have synchronization in lp-wan, with very strict clocks and adaptive synchronization techniques. LP-WAN tend to be subject to lower data rates as modulations are more robust using more chips per bit or other smarter encoding. LoRa has a becon enabled mode of operation which enables slight "synchronization".
>
> For me one main difference is the payload size which tends to be smaller than the 127B in common PAN networks. Also the fact that topologies tend to be stars of stars or few hop networks.
>
> regads,
> Xavi 
>
> 2015-12-16 20:41 GMT+01:00 [email-masked] <[email-masked]>:
>>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 16 Dec 2015 16:36:10 -0500

On 12/16/2015 3:43 PM, Joaquín Cabezas wrote:
> Indeed, for big smart metering deployments synchronization is desirable.

Why?

> I would add as a difference the massive number of devices that an LPWA concentrator is expected to serve. It will affect routing as well as efficiency on implementation.
>
> BR,
> Joaquín.
>

---

From: Joaquín Cabezas <[email-masked]>
Date: Wed, 16 Dec 2015 23:04:28 +0100

Normally water utilities want to read every meter at the same moment, several times a day. With some synchronization mechanism every meter will send that message at different times. This is critical for a concentrator with thousands of meters.

BR,
Joaquín.

---

From: Paul Duffy <[email-masked]>
Date: Wed, 16 Dec 2015 17:36:32 -0500

I think we need to agree what is meant here by "synchronization".

Are we talking about a set of meters using a synchronized time base for 
stamping meter reads, or the need for a centrally synchronized data link 
to provide these readings to the utility back end?

---

From: Joaquín Cabezas <[email-masked]>
Date: Wed, 16 Dec 2015 23:55:47 +0100

Option 2, to avoid ten of thousands of devices trying to access the medium simultaneously. A collision avoidance mechanism wouldn't be enough if the number of devices is very high (if we want to maximize the battery life).

BTW, this is a specific scenario. It's important because water meters market is so big, but I don't mean that any lpwan out there should provide this feature.

BR,
Joaquín.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 16 Dec 2015 17:05:03 -0600

Typical collision avoidance mechanisms use back-offs to spread out in time the devices trying to transmit.  With typical clock drifts and properly set back-off durations, the loading of the medium will become more consistent.  This mechanism is used in most wireless networks, such as 802.11 and 802.15.4. The concentrator can timestamp the data from each meter to provide the authorities with the read time.

Pat

On 16, Dec2015, at 16:55, Joaquín Cabezas <[email-masked]> wrote:

BR,
Joaquín.

---

From: Joaquín Cabezas <[email-masked]>
Date: Thu, 17 Dec 2015 00:17:44 +0100

On 802.15.4 we rely on CSMA/CA, but when a *huge* number of devices try to send at the same time, this mechanism is not efficient on terms of energy, because you have to use the Energy Detection several times and you can't have a "near-determinist" battery life assumption, which is critical if you have to sign an SLA with the customer.

BR,
Joaquín.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 16 Dec 2015 17:45:23 -0600

Joaquin;

From your emails, it seems that your requirements essentially rule out CSMA operation, so that leaves TDMA.  Since 6tisch is TDMA, then 6tisch seems to fit your requirements, so I do not understand why lp-wan is different from 6tisch.  BTW: in Europe, ETSI 300-328 (2.5 GHz) and ETSI 300 220 (less than 1 GHz) requires LBT for devices with transmit power greater than 10 dBm.  So there will be occasions when even a TDMA device will have to back off transmitting and sense the medium again.

Pat

On 16, Dec2015, at 17:17, Joaquín Cabezas <[email-masked]> wrote:

BR,
Joaquín.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2015 21:38:01 -0500

Xavier Vilajosana <[email-masked]> wrote:
    > For me one main difference is the payload size which tends to be
    > smaller than the 127B in common PAN networks. Also the fact that
    > topologies tend to be stars of stars or few hop networks.

My understanding is that BTLE has the same issue... yes, RFC7668
mentions a MTU of 27-4=23.  So the question again is: is there something that
a specific LP-WAN technology does that couldn't be solved with the same
mechanism as 7668?

I'm trying to figure out what work there is to do here.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2015 21:39:33 -0500

Joaquín Cabezas <[email-masked]> wrote:
    > Indeed, for big smart metering deployments synchronization is
    > desirable. I would add as a difference the massive number of devices
    > that an LPWA concentrator is expected to serve. It will affect routing
    > as well as efficiency on implementation.

How will routing be affected in a star-topology where the hub device (the
LPWA concentrator) is controlling the sleep cycle of all the devices?

---

From: Florian Meier <[email-masked]>
Date: Thu, 17 Dec 2015 08:12:08 +0100

That is different from my interpretation of the ETSI 300 220-1. 
According to Table 5 in Section 7.2.3, the allowed transmission power 
does not depend on the use of LBT, but on the used frequency range.
Yes, different frequency ranges have different spectrum access
and mitigation requirements, but in all cases it is possible to use a 
low duty cycle instead of LBT and in LP-WANs this is exactly what we 
have, so I do not see the need of LBT (apart from the fact that it might 
reduce collisions that can be advantageous for the LP-WAN itself).

By the way: Apart from the range 863 MHz to 870 MHz LBT always requires 
AFA, too (see Note 3).

Greetings,
Florian

---

From: [email-masked]
Date: Thu, 17 Dec 2015 07:32:40 -0800

What I mean is that if you have so many devices on the same concentrator
and you are dealing with duty cycles and so on, you won't want to mess
with routing and will opt for a star topology (making it boring, as you
said :P and definitely it is)

Best Regards,
Joaquín

>
> JoaquÃ­n Cabezas <[email-masked]> wrote:

---

From: "weigengyu" <[email-masked]>
Date: Fri, 18 Dec 2015 15:24:21 +0800

Hi Ana, 

> For continue the discussion, I start preparing a document for the requirements of LPWAN networks. 
That’s great.

> because it determines the packet size, more the range is long, less data can be transferred. 
> So this property give us a limit of the MTU (very short) that we need to take into account for the header stack we plan to use.

Strictly speaking, range determines L2 frame length. 
Theoretically, the payload length of L2 frame effects on MTU. 
But, if this WG has no intention to define a new version of IP (Not IPv6), it should meet IPv6 MTU requirements. 
An adaption layer would be needed to deliver IPv6 packet on LP-WAN L2 frames as 6lowpan WG did.. 
If there is an adation layer between L2 and IP, the payload length of adation layer must be or greater than 1280  (the minimum IPv6 MTU).

Regards, 

Gengyu WEI

From: Ana Minaburo 
Sent: Wednesday, December 16, 2015 8:07 PM
To: [email-masked] 
Subject: Re: [lp-wan] Next steps on LP-WANs

Hello, 

I would like to thanks all of you that have fill the table https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing

This is a great job that finally can be use to determine the missing points to be done as you have start discussing.

For continue the discussion, I start preparing a document for the requirements of LPWAN networks. 
Range is only important for upper layers at the IETF work we need to do, because it determines the packet size, more the range is long, less data can be transferred. So this property give us a limit of the MTU (very short) that we need to take into account for the header stack we plan to use.

Thanks

Ana

  Dear Timothy,

  Metering is just one of the cases which are covered by LP-WANs. Of course, I don't to limit our work to these networks. I just want to make sure, that we'll be able to get IP on them, along with the whole Internet ecosystem.

  Best,
  Alexander

      ...

    -tjs

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

---

From: Joaquin Cabezas <[email-masked]>
Date: Fri, 18 Dec 2015 08:43:02 +0100

Hi Gengyu,

this is a non-WG mailing list, and I guess there is no intention to 
define any RFC or protocol, but identifying potential candidates that 
can deliver a "LPWAN" (both radio technologies and IETF solutions) and 
discuss them. At least for now, that's what I understood from the group 
description. Someone correct me if I'm wrong.

However, I like 6loWPAN

BR,
Joaquín.

El 18/12/2015 a las 8:24, weigengyu escribió:
> > So this property give us a limit of the MTU (very short) that we 
> need to take into account for the header stack we plan to use.
> But, if this WG has no intention to define a new version of IP (Not 
> IPv6), it should meet IPv6 MTU requirements.
> If there is an adation layer between L2 and IP, the payload length of 
> adation layer must be or greater than 1280  (the minimum IPv6 MTU).
> Regards,
> Gengyu WEI
> *From:* Ana Minaburo <mailto:[email-masked]>
> *Sent:* Wednesday, December 16, 2015 8:07 PM
> *To:* [email-masked] <mailto:[email-masked]>
> This is a great job that finally can be use to determine the missing 
> points to be done as you have start discussing.
> Range is only important for upper layers at the IETF work we need to 
> do, because it determines the packet size, more the range is long, 
> less data can be transferred. So this property give us a limit of the 
> MTU (very short) that we need to take into account for the header 
> stack we plan to use.
> On Tue, Dec 15, 2015 at 10:07 PM, Alexander Pelov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear Timothy,
>
>     course, I don't to limit our work to these networks. I just want
>     to make sure, that we'll be able to get IP on them, along with the
>     whole Internet ecosystem.
>
> ------------------------------------------------------------------------

---

From: Florian Meier <[email-masked]>
Date: Fri, 18 Dec 2015 09:45:00 +0100

Transmitting 1280 bytes over for example SIGFOX with 12 byte payload per 
packet requires 107 packets neglecting any overhead. The throughput is 
specified as max. 140 packets per day.

I don't think we want to support IPv6 MTUs...

My personal vision would be to have IPv6 only to the lp-wan concentrator 
and over that just a tiny adaptation layer to deliver (for example) CoAP 
messages to the nodes.

Greetings,
Florian

On 18.12.2015 08:24, weigengyu wrote:
>  > So this property give us a limit of the MTU (very short) that we need
> to take into account for the header stack we plan to use.
>     course, I don't to limit our work to these networks. I just want to
>     make sure, that we'll be able to get IP on them, along with the

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 08:56:51 +0000

Spot on.

There are a number of use cases out there where the last IoT hop cannot qualify as IPv6. But we'd want the first hop router to make it so that the rest of the way is IPv6. How would we do a socket over LPWAN?

Cheers,

Pascal

> Sent: vendredi 18 décembre 2015 09:45
> To: weigengyu <[email-masked]>; [email-masked]
> My personal vision would be to have IPv6 only to the lp-wan concentrator and
> over that just a tiny adaptation layer to deliver (for example) CoAP messages to
> the nodes.
> 
> Greetings,
> Florian
> 
> > That's great.
> >  > Range is only important for upper layers at the IETF work we need
> > to do,  > because it determines the packet size, more the range is
> > long, less data can be transferred.
> > *Subject:* Re: [lp-wan] Next steps on LP-WANs Hello, I would like to
> > thanks all of you that have fill the table
> > https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-
> fHjl9FNiNvYfdB4
> > txN4hDQ-w/edit?usp=sharing This is a great job that finally can be use
> > to determine the missing points to be done as you have start
> > discussing.
> > MTU (very
> > short) that we need to take into account for the header stack we plan
> > to use.
> > ----------------------------------------------------------------------
> > -- _______________________________________________
> > lp-wan mailing list
> > [email-masked]

---

From: "weigengyu" <[email-masked]>
Date: Fri, 18 Dec 2015 16:57:28 +0800

Hi Joaquín, 

Thank you for your explanations.
I got it. 
This is a non-IETF WG mailing list.

I do think 6loWPAN is great too. 
However, if comparing the possible adaption layer functions of LP-WAN with that of 6loWPAN, 
the reliability control are needed as an alternative, I think.

While 802.15.4 has its reliable mechanism by retransmission and 6loWPAN do not have reliable delivery.
It may not a problem of 6loWAPN with PAN’s delay. 
But for low rate LP-WAN, reliable delivery are required. 
And there are existed some works on adding reliable functionality onto 802.15.4. 

Regards,

Gengyu WEI

From: Joaquin Cabezas 
Sent: Friday, December 18, 2015 3:43 PM
To: [email-masked] 
Subject: Re: [lp-wan] Next steps on LP-WANs

Hi Gengyu,

this is a non-WG mailing list, and I guess there is no intention to define any RFC or protocol, but identifying potential candidates that can deliver a "LPWAN" (both radio technologies and IETF solutions) and discuss them. At least for now, that's what I understood from the group description. Someone correct me if I'm wrong.

However, I like 6loWPAN

BR,
Joaquín.

  Hi Ana, 

  That’s great.

  Regards, 

  Gengyu WEI

  From: Ana Minaburo 

  Hello, 

  Thanks

  Ana

    Dear Timothy,

    Best,
    Alexander

        ...

      -tjs

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

---

From: "weigengyu" <[email-masked]>
Date: Fri, 18 Dec 2015 17:10:52 +0800

Hi Florian,

>I don't think we want to support IPv6 MTUs...

I do not think so.
Do you try to define anothter network protocol or a dummy network protocol?
Or anything else?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Florian Meier
Sent: Friday, December 18, 2015 4:45 PM
To: weigengyu ; [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

Greetings,
Florian

On 18.12.2015 08:24, weigengyu wrote:
> do,

---

From: "weigengyu" <[email-masked]>
Date: Fri, 18 Dec 2015 17:07:00 +0800

Hi Ana, 

Supporting IPv6 is an common sense in any networks.

Could you make it clear “this mailing list suppose to define the gaps for LPWAN at IETF”, 
whether does LP-WAN support IPv6? 

Regards, 

Gengyu WEI

From: Ana Minaburo 
Sent: Friday, December 18, 2015 4:29 PM
To: weigengyu 
Subject: Re: [lp-wan] Next steps on LP-WANs

Hello, 

First this is not a working group, this mailing list suppose to define the gaps for LPWAN at IETF. This means we need to find a solution using IETF protocols. Second anybody wants to create a new IP version, this is out of the scope of this mailing list. Third anybody want to modify physical layer  this is also out of the scope also.

Then we are suppose to TAKE OUT the singular characteristics of LPWAN that distinguish them from what has already been define in the different IETF working groups managing the constrained nodes. This could be a little subtle but we need to consolidate a real need for this networks. After then we can decide if what is already done can be use or LPWAN needs a new protocol, for the moment this is not really clear, not until we have done requirements and differences.

Last L2 MTU is very important for IETF frames. This determines the real MTU for IP stack, and the need of fragmentation or not. You can study the 6top adaptation layer, perhaps you will find some work that can be used here.

Cheers
Ana

On Fri, Dec 18, 2015 at 8:24 AM, weigengyu <[email-masked]> wrote:

  Hi Ana, 

  That’s great.

  Regards, 

  Gengyu WEI

  From: Ana Minaburo 

  Hello, 

  Thanks

  Ana

    Dear Timothy,

    Best,
    Alexander

        ...

      -tjs

---

From: Florian Meier <[email-masked]>
Date: Fri, 18 Dec 2015 14:57:30 +0100

The main problem here is addressing.

Since a socket is usually identified by IP address and port and the IP
endpoint is the first hop router, the only possibility to identify the
individual nodes is by using the port number, but that sounds like a
dirty hack.

Of course, 6LoWPAN could be used to provide IPv6 from end to end, but
not without disallowing certain functionality and giving up full IPv6
compatibility (especially regarding the MTU).

So a compromise would be some kind of intermediate layer that
encapsulates one or multiple packets to be sent to or received from the
radio.
For example the Internet MANET Encapsulation Protocol (IMEP) already
contains some applicable ideas, but also many things that are not
meaningful in this context. Also the Zigbee Encapsulation Protocol is a
step into this direction, but is more optimized for pure monitoring and
logging.
In the most basic form this would be a header with one or multiple bytes
specifying the address of the node between a UDP and a CoAP header. As
soon as the router receives such a packet, it unpacks the CoAP packet
and sends it to the respective node. When receiving a packet via the
radio, the node address is prepended and the message is sent via UDP.
This could for example be extended to allow for aggregation of multiple
messages (e.g. request the state of all nodes at once).

Actually I have built something similar for an IEEE 802.15.4 network. In
retrospective 6LoWPAN would have been applicable in my scenario, too,
but it works quite good and has lower overhead (but of course less
functionality) as 6LoWPAN. I guess there are many existing proprietary
solutions that work similar (and maybe even standards that I am not
aware of), so a standardization might be meaningful.

Greetings,
Florian

---

From: Bill Gage <[email-masked]>
Date: Fri, 18 Dec 2015 13:58:13 +0000

When characterising some of these LPWAN technologies, could you also identify whether the RAT is connection-less or connection-oriented.

Generically, connection-less implies a datagram transport with source and destination explicitly indicated in each datagram. Connection-oriented implies a transport with source and destination implied by the connection identifier; the connection identifier may be explicit in the transport PDU or implied through some characteristic of the transport (e.g. time slot number, spreading code).

Thanks ...

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Friday, December 18, 2015 3:57 AM
> There are a number of use cases out there where the last IoT hop cannot
> qualify as IPv6. But we'd want the first hop router to make it so that the
> rest of the way is IPv6. How would we do a socket over LPWAN?
> 
> Cheers,
> 
> Pascal
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 14:08:38 +0000

Hello Bill: 

There's the end to end session, and then there's the state that can be left at the GW for compression purposes over the LPWAN, like a PPP / van Jacobson or something. The latter is not end to end. What I mean is that aving a compression state at the network edge of a slow access link does not mean connection oriented. At least not as defined in the connection oriented vs connection less at the time of the IP vs. SNA wars. But nevertheless it makes sense to have the socket handled by the GW, pay the price at the beginning and use it from thee on.

Cheers,

Pascal

> From: lp-wan [mailto:[email-masked]] On Behalf Of Bill Gage
> Sent: vendredi 18 décembre 2015 14:58
> To: [email-masked]; [email-masked]
> When characterising some of these LPWAN technologies, could you also identify
> whether the RAT is connection-less or connection-oriented.
> 
> Generically, connection-less implies a datagram transport with source and
> destination explicitly indicated in each datagram. Connection-oriented implies a
> transport with source and destination implied by the connection identifier; the
> connection identifier may be explicit in the transport PDU or implied through
> some characteristic of the transport (e.g. time slot number, spreading code).
> 
> Thanks ...
> 
> 
> > There are a number of use cases out there where the last IoT hop
> > cannot qualify as IPv6. But we'd want the first hop router to make it
> > so that the rest of the way is IPv6. How would we do a socket over LPWAN?
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > > Transmitting 1280 bytes over for example SIGFOX with 12 byte payload
> > > per packet requires 107 packets neglecting any overhead. The
> > > throughput is specified as max. 140 packets per day.
> > >
> > > >  > Range is only important for upper layers at the IETF work we
> > > > need to do,  > because it determines the packet size, more the
> > > > range is long, less data can be transferred.
> > > >  > So this property give us a limit of the MTU (very short) that
> > > > we need to take into account for the header stack we plan to use.
> > > > But, if this WG has no intention to define a new version of IP
> > > > (Not IPv6), it should meet IPv6 MTU requirements.
> > > > If there is an adation layer between L2 and IP, the payload length
> > > > of adation layer must be or greater than 1280  (the minimum IPv6 MTU).
> > > > Regards,
> > > > Gengyu WEI
> > > > *Subject:* Re: [lp-wan] Next steps on LP-WANs Hello, I would like
> > > > to thanks all of you that have fill the table
> > > > txN4hDQ-w/edit?usp=sharing This is a great job that finally can be
> > > > use to determine the missing points to be done as you have start
> > > > discussing.
> > > > to do, because it determines the packet size, more the range is
> > > > long, less data can be transferred. So this property give us a
> > > > limit of the MTU (very
> > > > short) that we need to take into account for the header stack we
> > > > plan to use.
> https://docs.google.com/document/d/12tjuGD80VlZsC_3AqIQrPcVuNgjO1V3d
> > > zx
> > > > kOTVUsBAM/edit?usp=sharing
> > > > Thanks
> > > > Ana
>

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 18 Dec 2015 16:00:40 +0100

Hi,

That's a good topic for the group.

This limit was establish to avoid to limit too much the packet size during
PMTU discovery. If we don't have PMTU discovery is some part of the LPWA
architecture, this constraint is not needed.

Laurent

On Fri, Dec 18, 2015 at 10:10 AM, weigengyu <[email-masked]> wrote:

> -----原始邮件----- From: Florian Meier

---

From: Robert Cragie <[email-masked]>
Date: Fri, 18 Dec 2015 15:53:25 +0000

I have been following the discussion so far with interest and here are some of my views.

## LPWAN (or LP-WAN)
The LPWAN term is used widely so I agree that it should be used (note "LPWAN" is also the term most used, not "LP-WAN"). Regarding "PAN" - this is historical. 802.15 has extended way beyond the initial remit. The same applies for LAN and WAN to some extent - the boundaries have become blurred.

## Bandwidth constrained networks
RFC7228 does distinguish constrained node and constrained network as two axes of constraint. The constrained network definition clearly covers bandwidth constraints. The intent of using the "constrained" adjective generally is that it means that a deployed device has a degree of constraint in at least one of the axes. We could introduce more axes or split the existing axes up more granularly but on the whole, I think RFC7228 does a good job of capturing constraint in the two areas most relevant to a networked device. The classes of device generally refer more to the constrained node axis and, as stated in this discussion, it is unlikely a Class 0 device would be considered, although I guess it can't be ruled out.

## Link budget and topology
Range is all about link budget, as already mentioned in this discussion. 802.15.4 devices using the 2.4 GHz DSSS PHY can achieve a range much more than 10m if 20dBm Tx power is used with a high sensitivity receiver, often with an energy penalty. Link budgets are also much higher with lower data rates so that has a significance as well, however lower data rates mean the radio needs to be on longer to achieve the same throughput so there is an energy penalty. It would be interesting to get a rough Joules/metre figure for a reference payload for some of these technologies.

Range must then be considered alongside network topology. A star topology may require long range radios to achieve its aim of wide area communication as it can only do it over one hop, whereas a mesh topology may not require long range radios and rely on the availability of repeaters/routers. There is clearly a wide spectrum here from very low data rate, very wide area star networks (e.g. Time from NPL on long wave transmitters) to relatively high data rate, neighbourhood area mesh networks (e.g. Wi-SUN).

One thing isn't really clear - is this just about one-hop star networks? Are we not looking at mesh topologies? This isn't clear from the outset. There is talk of "peer-to-peer" and "heterogeneous" networks - by these, do we mean mesh and mesh/star hybrids or something else?

There is a lot of discussion about "low power" vs. "bandwidth constrained" and whether the "LP" in LPWAN is appropriate. The technologies generally under consideration **are** relatively low power compared to other WANs, so it seems a reasonable distinction. There is no reason this should influence the choice of suitable protocols to run over these networks; we should consider a wider range of properties offered by MAC/PHY.

## L2 properties
It is the L2 (and below) properties that are important and maybe these could be categorised. These then provide a bearing for the higher layers. This cross-layer configuration is important. Some things we may need to think about:

- Bandwidth
- Link budget
- Uplink/downlink rates
- Rx/Tx power
- Payload size
- Packet size
- L2 fragmentation
- Use of acknowledgements
- Channel access
- Channels
  - Globally useable
  - Licence free

## Synchronisation
There is a difference between tight synchronisation for channel access purposes, as is done in TDMA networks like 6tisch uses and loose synchronisation where devices may wish to communicate (more or less) at the same time. In the latter case, techniques already mentioned like CSMA are used but in addition device usually apply jitter to sending readings, not to mention the fact that they will not be exactly synchronised wrt. wall clock time anyway.

## End-to-end communication
There is an important discussion about whether it has to be IP(v6) all the way to the end node or not. There is also discussion about "hacks" regarding addressing. Using ports is not the only way to distinguish endpoints; if IPv6 is used, the end nodes can have their own address. How that address is transported between the end node and the next hop (presumably gateway in a star topology) is irrelevant to some extent as long as it can be reconstructed. This is the essence of how 6LoWPAN works (eliding IPv6 addresses based on mapping to L2 address) and contexts can also be used to statefully elide prefixes. Consideration has to be given to timeouts when using CoAP etc.

On the other hand, there is also the case for keeping the communication between the end node and an IP gateway non-IP, especially where the technology is severely limited in MAC PDU size and where achieving IPv6 MTUs is almost impossible without considerable fragmentation. There are many cases where it may be prudent to aggregate data at the gateway node as well, for example providing a collection of readings from multiple sensors in a single CoAP/UDP datagram to the cloud. There could be a more straightforward CoAP proxy model, which does not necessarily imply any data aggregation. In both cases, there is no strict requirement for the end node to gateway communication to be IP.

There are certainly advantages of having IP end-to-end, most notably end-to-end security based on well-known methods e.g. DTLS.

## Security and authentication
There seems to be an assumption about security being provided at L2. It is likely many technologies will provide the ability to add packet security at L2 over one hop. This may be authentication only or authentication and encryption. However, this assumes symmetric keys have got there in the first place. Other aspects we probably need to think about:

- Network access and authorisation
  - Use of EAP/AAA
- Key distribution
  - Multicast and pairwise keys
- Use of public keys
- Use of higher layer security (DTLS/CoSE)
- Application/user authentication and authorisation (ace)

Robert

From: lp-wan [mailto:[email-masked]] On Behalf Of Laurent Toutain
Sent: 18 December 2015 15:01
To: weigengyu
Cc: [email-masked]; Florian Meier
Subject: Re: [lp-wan] Next steps on LP-WANs

Hi,

This limit was establish to avoid to limit too much the packet size during PMTU discovery. If we don't have PMTU discovery is some part of the LPWA architecture, this constraint is not needed.

Laurent

On Fri, Dec 18, 2015 at 10:10 AM, weigengyu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Florian,
I don't think we want to support IPv6 MTUs...

I do not think so.

Regards,

Gengyu WEI
To: weigengyu ; [email-masked]<mailto:[email-masked]>

Greetings,
Florian

to take into account for the header stack we plan to use.
Strictly speaking, range determines L2 frame length.
Theoretically, the payload length of L2 frame effects on MTU.
But, if this WG has no intention to define a new version of IP (Not
IPv6), it should meet IPv6 MTU requirements.
An adaption layer would be needed to deliver IPv6 packet on LP-WAN L2
frames as 6lowpan WG did..
If there is an adation layer between L2 and IP, the payload length of
adation layer must be or greater than 1280  (the minimum IPv6 MTU).
Regards,
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
*From:* Ana Minaburo <mailto:[email-masked]<mailto:[email-masked]>>
*Sent:* Wednesday, December 16, 2015 8:07 PM
*To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
*Subject:* Re: [lp-wan] Next steps on LP-WANs
Hello,
I would like to thanks all of you that have fill the table
https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing
This is a great job that finally can be use to determine the missing
points to be done as you have start discussing.
For continue the discussion, I start preparing a document for the
requirements of LPWAN networks.
Range is only important for upper layers at the IETF work we need to do,
because it determines the packet size, more the range is long, less data
can be transferred. So this property give us a limit of the MTU (very
short) that we need to take into account for the header stack we plan to
use.
Here you will find the document I started, please modify/complete
https://docs.google.com/document/d/12tjuGD80VlZsC_3AqIQrPcVuNgjO1V3dzxkOTVUsBAM/edit?usp=sharing
Thanks
Ana
On Tue, Dec 15, 2015 at 10:07 PM, Alexander Pelov <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Dear Timothy,

    Best,
    Alexander

            ...
            For me personally, Low-Power WAN, are a separate class of
            networks,
            because of the combination of the following characteristics:
            ...

        If what you want is a working group that works on low-data-rate,
        wireless, smart metering utility networks, then I think that's
        what you
        should call the working group.

        There are a _lot_ of low-power, wide-area, wireless networks
        that meet
        many, but not all, of the criteria that you specify.  It doesn't
        seem
        to me that you ought to select an inclusive name, like
        "low-power", when
        you want to address only a very small portion of what that name
        implies.

        -tjs

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

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

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: Bill Gage <[email-masked]>
Date: Fri, 18 Dec 2015 16:08:25 +0000

## Low energy operation
In some deployments, devices must operate on batteries for many years. Battery conservation mechanisms may include low transmit power but also include other aspects such as:
- minimising the number of PDUs transmitted and received
- minimising the length of PDUs transmitted and received
- keeping the transmitter and receiver turned off as much as possible
- etc.

Some of the existing IP protocols involve handshakes that are not optimised in one or more of these dimensions.

Cheers ...

From: Robert Cragie [mailto:[email-masked]] 
Sent: Friday, December 18, 2015 10:53 AM
Subject: Re: [lp-wan] Next steps on LP-WANs

## LPWAN (or LP-WAN)

## L2 properties

- Bandwidth
- Link budget
- Uplink/downlink rates
- Rx/Tx power
- Payload size
- Packet size
- L2 fragmentation

## Synchronisation

Robert

Hi,

Laurent 

I do not think so.

Regards,

Gengyu WEI

Greetings,
Florian

 > For continue the discussion, I start preparing a document for the
 > Range is only important for upper layers at the IETF work we need to do,
 > because it determines the packet size, more the range is long, less
data can be transferred.
 > So this property give us a limit of the MTU (very short) that we need

    Dear Timothy,

    Best,
    Alexander

            ...

        -tjs

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 10:43:57 -0600

Bill has captured some very good aspects for low energy operation.  However, these aspects are not limited to LPWAN since they are also key for many WPAN networks including 6tisch.

Pat
 
On 18, Dec2015, at 10:08, Bill Gage <[email-masked]> wrote:

## Low energy operation

Cheers ...

## LPWAN (or LP-WAN)

## L2 properties

- Bandwidth
- Link budget
- Uplink/downlink rates
- Rx/Tx power
- Payload size
- Packet size
- L2 fragmentation

## Synchronisation

Robert

Hi,

Laurent 

I do not think so.

Regards,

Gengyu WEI

Greetings,
Florian

    Dear Timothy,

    Best,
    Alexander

            ...

        -tjs

---

From: Bill Gage <[email-masked]>
Date: Fri, 18 Dec 2015 17:57:16 +0000

They weren't meant to be LPWAN specific ;-) 

Sometimes looking at a specific problem also highlights some more generic problems. LPWAN might be the (current) problem domain but, hopefully, any solution coming from these deliberations will have applicability to other domains.

Cheers ...

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 18, 2015 11:44 AM
> Bill has captured some very good aspects for low energy operation.
> However, these aspects are not limited to LPWAN since they are also key
> for many WPAN networks including 6tisch.
> 
> Pat
> 
> In some deployments, devices must operate on batteries for many years.
> Battery conservation mechanisms may include low transmit power but also
> include other aspects such as:
> Some of the existing IP protocols involve handshakes that are not
> optimised in one or more of these dimensions.
> 
> Cheers ...
> 
> 
> The LPWAN term is used widely so I agree that it should be used (note
> "LPWAN" is also the term most used, not "LP-WAN"). Regarding "PAN" - this
> is historical. 802.15 has extended way beyond the initial remit. The same
> applies for LAN and WAN to some extent - the boundaries have become
> blurred.
> 
> RFC7228 does distinguish constrained node and constrained network as two
> axes of constraint. The constrained network definition clearly covers
> bandwidth constraints. The intent of using the "constrained" adjective
> generally is that it means that a deployed device has a degree of
> constraint in at least one of the axes. We could introduce more axes or
> split the existing axes up more granularly but on the whole, I think
> RFC7228 does a good job of capturing constraint in the two areas most
> relevant to a networked device. The classes of device generally refer more
> to the constrained node axis and, as stated in this discussion, it is
> unlikely a Class 0 device would be considered, although I guess it can't
> be ruled out.
> 
> Range is all about link budget, as already mentioned in this discussion.
> 802.15.4 devices using the 2.4 GHz DSSS PHY can achieve a range much more
> than 10m if 20dBm Tx power is used with a high sensitivity receiver, often
> with an energy penalty. Link budgets are also much higher with lower data
> rates so that has a significance as well, however lower data rates mean
> the radio needs to be on longer to achieve the same throughput so there is
> an energy penalty. It would be interesting to get a rough Joules/metre
> figure for a reference payload for some of these technologies.
> 
> Range must then be considered alongside network topology. A star topology
> may require long range radios to achieve its aim of wide area
> communication as it can only do it over one hop, whereas a mesh topology
> may not require long range radios and rely on the availability of
> repeaters/routers. There is clearly a wide spectrum here from very low
> data rate, very wide area star networks (e.g. Time from NPL on long wave
> transmitters) to relatively high data rate, neighbourhood area mesh
> networks (e.g. Wi-SUN).
> 
> One thing isn't really clear - is this just about one-hop star networks?
> Are we not looking at mesh topologies? This isn't clear from the outset.
> There is talk of "peer-to-peer" and "heterogeneous" networks - by these,
> do we mean mesh and mesh/star hybrids or something else?
> 
> There is a lot of discussion about "low power" vs. "bandwidth constrained"
> and whether the "LP" in LPWAN is appropriate. The technologies generally
> under consideration **are** relatively low power compared to other WANs,
> so it seems a reasonable distinction. There is no reason this should
> influence the choice of suitable protocols to run over these networks; we
> should consider a wider range of properties offered by MAC/PHY.
> 
> ## L2 properties
> It is the L2 (and below) properties that are important and maybe these
> could be categorised. These then provide a bearing for the higher layers.
> This cross-layer configuration is important. Some things we may need to
> think about:
> 
> - Bandwidth
> - Link budget
> - Uplink/downlink rates
> - Rx/Tx power
> - Payload size
> - Packet size
> - L2 fragmentation
> There is a difference between tight synchronisation for channel access
> purposes, as is done in TDMA networks like 6tisch uses and loose
> synchronisation where devices may wish to communicate (more or less) at
> the same time. In the latter case, techniques already mentioned like CSMA
> are used but in addition device usually apply jitter to sending readings,
> not to mention the fact that they will not be exactly synchronised wrt.
> wall clock time anyway.
> 
> There is an important discussion about whether it has to be IP(v6) all the
> way to the end node or not. There is also discussion about "hacks"
> regarding addressing. Using ports is not the only way to distinguish
> endpoints; if IPv6 is used, the end nodes can have their own address. How
> that address is transported between the end node and the next hop
> (presumably gateway in a star topology) is irrelevant to some extent as
> long as it can be reconstructed. This is the essence of how 6LoWPAN works
> (eliding IPv6 addresses based on mapping to L2 address) and contexts can
> also be used to statefully elide prefixes. Consideration has to be given
> to timeouts when using CoAP etc.
> 
> On the other hand, there is also the case for keeping the communication
> between the end node and an IP gateway non-IP, especially where the
> technology is severely limited in MAC PDU size and where achieving IPv6
> MTUs is almost impossible without considerable fragmentation. There are
> many cases where it may be prudent to aggregate data at the gateway node
> as well, for example providing a collection of readings from multiple
> sensors in a single CoAP/UDP datagram to the cloud. There could be a more
> straightforward CoAP proxy model, which does not necessarily imply any
> data aggregation. In both cases, there is no strict requirement for the
> end node to gateway communication to be IP.
> 
> There are certainly advantages of having IP end-to-end, most notably end-
> to-end security based on well-known methods e.g. DTLS.
> 
> There seems to be an assumption about security being provided at L2. It is
> likely many technologies will provide the ability to add packet security
> at L2 over one hop. This may be authentication only or authentication and
> encryption. However, this assumes symmetric keys have got there in the
> first place. Other aspects we probably need to think about:
> 
> fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing
> 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: "Timothy J. Salo" <[email-masked]>
Date: Fri, 18 Dec 2015 19:43:35 -0600

> Supporting IPv6 is an common sense in any networks.

I probably don't believe this.

An easy example is deep space networks.

I believe that I recall Dave Clark saying, perhaps 25 years ago,
something to the effect of: "Don't do anything in a protocol that
you wouldn't do to Mars".  In the intervening decades, we have
learned a lot about protocol design.  Today, there is a pretty strong
consensus that using TCP to Mars is a bad idea.  (For those who
are interested in protocol design, I recommend looking at the
protocols used for deep space communications: <http://www.ccsds.org/>.)
Some time ago, JPL and Vint Cerf started a project, I think it was
called "The Interplanetary Internet", to develop protocols for
deep space communications.  I think this was the start of the
DTN protocols, although I don't know that they are actually
used in deep space communications.  Does anyone know?  In other
words, deep space networks were believed to be enough different
than terrestrial networks to warrant the development of new
protocols.

I looked at the SIGFOX web pages, particularly
<http://makers.sigfox.com>.  The maximum message size on SIGFOX
networks is 12 bytes, although the lower-layer protocol includes a
timestamp and a device id.  A device can transmit a maximum of six
messages an hour.  That is, the maximum bandwidth available to a remote
device is 72 bytes per _hour_.  So, sending a 1280-byte IPv6 packet,
without header compression, would take over 17 hours.

I think a reasonable argument can be made that SIGFOX networks should
probably _not_ support packets as large as the minumum IPv6 MTU: 1280
bytes.

I agree with the earlier comments that suggest that perhaps the IPv6
endpoint ought to reside in the gateway, rather than in the remote node.
Of course, the gateway could give remote Internet users the impression
of end-to-end transparency between the remote SIGFOX device and the
Internet host, but the actually protocol on the SIGFOX network might
not be anything close to IPv6.

Admittedly, this approach conflicts with the deeply held IETF ideology
concerning end-to-endedness and end-to-end transparency.  But, I
think that a good argument can be made that we may need to do something
dramatically different in wireless networks with the bandwidth to
a remote node of tens-of-bytes per _hour_.  Sort of like the
Internet protocols needed to be rethought for use in deep space
communications.

-tjs

---

From: [email-masked]
Date: Sat, 19 Dec 2015 03:42:17 -0800

> end node to gateway communication to be IP.

I've been doing some tests on this:

0. set a Linux box with a IPv6 link and a connection to the LPWAN
1. IP aliasing to create a unique IPv6 address for every device on the LPWAN
2. Install and modify a CoAP proxy that receives requests for any IPv6
destination address
3. the CoAP proxy get the destination IPv6 address, looks on a table and
provide an answer on behalf of that particular device

I know it's kind of dirty, but this way I have a global reachable IPv6
address that answers like the node itself. Do you have conducted any test
with a similar approach?

BR,
Joaquín.

> On Fri, Dec 18, 2015 at 10:10 AM, weigengyu
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Florian,
> -----åŽŸå§‹é‚®ä»¶----- From: Florian Meier
> Thatâ€™s great.
> *To:* [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> On Tue, Dec 15, 2015 at 10:07 PM, Alexander Pelov
> <[email-masked]<mailto:[email-masked]>
>     Le 15/12/2015 20:09, Timothy J. Salo a Ã©crit :
>
> <mailto:[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]<mailto:[email-masked]>>
> +--- VoIP (recommended) ---+----------- TÃ©lÃ©com Bretagne -----------+
> | [email-masked]<mailto:[email-masked]>         |
> [email-masked]<mailto:[email-masked]>
>    |

---

From: "weigengyu" <[email-masked]>
Date: Thu, 31 Dec 2015 09:44:21 +0800

Hi Timonthy,

I do not think that ""The Interplanetary Internet" is an adquate example to 
compare with LPWAN.
Being on the ground it is required to make LPWAN interconnect with IPv6 
based Internet.

So, I still think it is required to support IPv6 for any networks nowadays.
For SIGFOX, when the number and density of nodes is as large as that is 
specified in this mailing list,
wat addressing mechanism is adopted?
For addressing and supporting IPv6, 6loWPAN is a good example to learn, I 
think.

Regards,

And happy new year!

Gengyu WEI
-----原始邮件----- 
From: Timothy J. Salo
Sent: Saturday, December 19, 2015 9:43 AM
Cc: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

-tjs

---

From: "weigengyu" <[email-masked]>
Date: Thu, 31 Dec 2015 09:57:06 +0800

Hi Joaquín,

We did.
And we know that: there are many Non-IP networks, there had been many 
network technology with native protocol stack which is not IP.
But, many of them have turned to support IP.

There are still some networks where application protocols are directly put 
on link layer protocol without
network layer protocol (IP) or transport layer protocols (TCP/UDP).
Even though they can work and interconnnect to Internet through specific 
gateway,
it seems not to be adquate for LPWAN specified in this mailing list when 
considering the number and density of nodes.

Regards,

And happy new year!

Gengyu WEI
-----原始邮件----- 
From: [email-masked]
Sent: Saturday, December 19, 2015 7:42 PM
To: Robert Cragie
Cc: [email-masked]
Subject: Re: [lp-wan] Next steps on LP-WANs

BR,
Joaquín.