Subject: Re: [lp-wan] Welcome to the mailing list on Low-Power Wide-Area Networking

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 13 Nov 2015 10:24:00 +0100

Dear Alexander,

LP-WANs are in my opinion a very interesting family of technologies for
the constrained node network space. I have seen how they are gaining
momentum in several projects I am aware of.

Regarding running IP(v6) over LP-WANs, as you mention, these technologies
definitely pose unseen constraints:

- Data rates: SigFox supports data rates between 10 bit/s and 1 kbit/s.
LoRa supports from 250 bit/s to 50 kbit/s in Europe and China, and between
980 bit/s and 21.9 kbit/s in the US.

- Payload size: SigFox supports 12-byte payloads. Depending on the pysical
data rate used, LoRa supports up to 51-230 byte and 11-230 byte MAC layer
payloads in Europe/China, and in the US, respectively.

- Message rates: in SigFox, the number of messages a constrained device
may send is limited to 140 per day.

The payload size in SigFox is really a challenge for IPv6 support. With
6LoWPAN HC, the compressed IPv6 header may be down to 3 bytes with global
addresses. The compressed UDP header would be 4 bytes. The CoAP header has
at least 4 bytes. Thus, there would only be 1 byte left for CoAP payload
(or for other purposes) in every message...

SigFox would need some mechanism to support fragmentation. For instance,
Bluetooth Low Energy leaves 19-21 bytes for the 6Lo adaptation layer in
every data channel packet (i.e. not a much higher space for data transport
than SigFox), but it supports fragmentation by itself. On the other hand,
the 6LoWPAN fragmentation header has a size of 4-5 bytes...

The most constrained variants of LoRa (e.g. the one with 11-byte maximum
payload) suffer a similar problem.

So in my opinion, at least for SigFox, and for some LoRa variants, the
main issue is the available space for upper layer data in each data unit.

Best regards,

Carles

---------------------------
Dear all,

Thank you for subscribing to this nonWG mailing list!

As you are all aware, we're witnessing a true revolution in the
IoT/telecommunications world with the arrival and the generalization of
LP-WANs. They pose a set of unseen constraints, which makes difficult
running even basic services on them. Yet, it is expected to have more
than 3 billion devices by 2020 connected over LP-WANs.

We would like to start the discussion on how the IETF stack can be used
on these networks. There is a first document, which outlines some of the
constraints, and puts forward a specific solution to a specific set of
problems. However, many questions remain opened, and I believe we should
not leave this new wave of networks out of IETF's scope.

- What would be the problems you would like to see discussed here?
- Do you see any additional radio technologies that should be included
in the list (for the moment we have listed only IEEE 802.15.4k, Semtech
Lora, SigFox and Qowisio explicitly)?
- Which are the main constraints that you feel as the more stringent?
- How do we get IP running on these networks? (IPv?)
- Do you agree that CoAP could be the signaling protocol for managing
these networks?
- ???

I've set up a GitHub repository - https://github.com/lp-wan - where to
collect the input from the mailing list.

Best,
Alexander

---

From: Mischa Dohler <[email-masked]>
Date: Fri, 13 Nov 2015 09:35:34 +0000

... which is why we were pushing for this group in the first place!

To add to the challenge, link budgets are very different in up and 
downlink. The heavy ack-culture at L2 and above will thus give us 
massive headaches here. We may want to go down the route I am pushing 
now in 3GPP as part of a 5G design, where we decouple up and downlinks; 
check eg http://arxiv.org/abs/1503.06746 (which was just accepted).

Xavi and I exchanged some ideas on IPv6 over Sigfox some years back 
which is when we decided IETF is probably the best venue; however, at 
that time everybody was still on Zigbee/.15.4(e) but we saw the raise of 
LPWANs coming (simply because it was the only technology which would 
work at scale).

Let me discuss with Xavi offline on how best to articulate that.

Kindest, Mischa.

______________________________________

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 13/11/2015 09:24, Carles Gomez Montenegro wrote:
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 13 Nov 2015 10:52:15 +0100

Hi,

2 more points here.

1) the use of contexts may help
2) LORA 1.2 (I guess) is preparing L2 fragmentation.

2015-11-13 10:35 GMT+01:00 Mischa Dohler <[email-masked]>:

> downlink. The heavy ack-culture at L2 and above will thus give us massive
> headaches here. We may want to go down the route I am pushing now in 3GPP
> as part of a 5G design, where we decouple up and downlinks; check eg
> http://arxiv.org/abs/1503.06746 (which was just accepted).
>
> Xavi and I exchanged some ideas on IPv6 over Sigfox some years back which
> is when we decided IETF is probably the best venue; however, at that time
> everybody was still on Zigbee/.15.4(e) but we saw the raise of LPWANs
> coming (simply because it was the only technology which would work at
> scale).
>

---

From: Mischa Dohler <[email-masked]>
Date: Fri, 13 Nov 2015 09:55:21 +0000

Point 2) is what the initial idea was when we discussed years back. I 
think it has potential ...

Prof Mischa Dohler

www.mischadohler.com

On 13/11/2015 09:52, Xavier Vilajosana wrote:
> 2015-11-13 10:35 GMT+01:00 Mischa Dohler <[email-masked] 
> <mailto:[email-masked]>>:
>
>     massive headaches here. We may want to go down the route I am
>     pushing now in 3GPP as part of a 5G design, where we decouple up
>     and downlinks; check eg http://arxiv.org/abs/1503.06746 (which was
>     just accepted).
>
>     Xavi and I exchanged some ideas on IPv6 over Sigfox some years
>     back which is when we decided IETF is probably the best venue;
>     however, at that time everybody was still on Zigbee/.15.4(e) but
>     we saw the raise of LPWANs coming (simply because it was the only
>     technology which would work at scale).
>
>     www.mischadohler.com <http://www.mischadohler.com>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 13 Nov 2015 11:13:11 +0100

yes, they want to use network coding for that. the problem I see still is
that in SF 12 the number of bytes to be transmitted is very small. This
will require dynamic adjusting of the fragment size according to the link
state.

X

2015-11-13 10:55 GMT+01:00 Mischa Dohler <[email-masked]>:

>> <http://arxiv.org/abs/1503.06746>http://arxiv.org/abs/1503.06746 (which
>> was just accepted).
>>
>>> I've set up a GitHub repository - <https://github.com/lp-wan>
>>> https://github.com/lp-wan - where to

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 13 Nov 2015 11:40:29 +0100

Dear Carles,

> may send is limited to 140 per day.
Thank you for your feedback! Indeed, it would be important to collect 
the full constraint set of all such technologies for the different 
regions in the world.

I suppose the message rate limitation in SigFox comes from the 
duty-cycling requirements for using the ISM bands. I imagine the 
restriction of 140 messages/day were set with a given number of 
(expected) end-devices in mind + it helps having a pricing differentiation.
> main issue is the available space for upper layer data in each data unit.
You are completely right! It is indeed one of the reasons we should look 
more into the ways of doing this.

For the moment, I like the L2 fragmentation introduced in IEEE 
802.15.4k. Should we expect to have L2 fragmentation in all underlaying 
technologies?

Best,
Alexander

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 13 Nov 2015 12:08:41 +0100

Dear Mischa, Dear Xavi,

Indeed, L2 fragmentation is already present in the IEEE 802.15.4k. The 
question is - should we rely on having such fragmentation in all 
underlaying technologies? I tend to agree with what Xavi said - 
establishing contexts (6LP, other) - could (will?) also be a part of the 
solution. Here the way the context is constructed could be of great 
importance. Implicit? Or through some explicit signaling?

Mischa, thanks for the referenced paper - I'll read it in more detail 
during the weekend; I've skimmed rapidly through it, and it seems that 
the problem you're presenting there is related to heterogeneous cellular 
network deployments (small cells + macro cells). Do you believe this 
will be an important trend in LPWANs? Operated networks for the moment 
rely on homogeneous deployments, but we are seing several actors pushing 
for more small-cell-ish approaches (such as Archos' PicoWAN).

I do believe that the problem you are mentioning is a real issue in 
LPWANs, but mainly for a different reason. The "heavy ACK headaches" are 
very real and need to be addressed, mainly because of the duty-cycling 
restrictions LPWANs must meet. An L2 ACK (or an L4, or L7 ACK for that 
matter) count towards the quota of the radio antenna that emitted them 
(e.g. an Access Point ACKing the frames of 10 000 nodes could easily be 
blocked by that). One can imagine being forced to deploy a more dense 
infrastructure deployment solely for the purpose of ACKs.. or play with 
them intelligently? Agreggating ACKs, adjusting timers, avoiding (some) 
ACKs when possible.. do you see any other ideas here?

Finally, LoRa and SigFox are (the two) best-known technologies out 
there. They are not the only ones, and I feel that even if we focus on 
these two, we should not forget about the rest. A short overview of some 
of them could be found here for example: 
http://www.eejournal.com/archives/articles/20150907-lpwa/ Maybe at some 
point we will need to define LPWAN profiles?

Best,
Alexander

Le 13/11/2015 11:13, Xavier Vilajosana a écrit :
> yes, they want to use network coding for that. the problem I see still 
> is that in SF 12 the number of bytes to be transmitted is very small. 
> This will require dynamic adjusting of the fragment size according to 
> the link state.
>
> X
>
> 2015-11-13 10:55 GMT+01:00 Mischa Dohler <[email-masked] 
>     Point 2) is what the initial idea was when we discussed years
>     back. I think it has potential ...
>
>>         To add to the challenge, link budgets are very different in
>>         up and downlink. The heavy ack-culture at L2 and above will
>>         thus give us massive headaches here. We may want to go down
>>         the route I am pushing now in 3GPP as part of a 5G design,
>>         where we decouple up and downlinks; check eg
>>         Xavi and I exchanged some ideas on IPv6 over Sigfox some
>>         years back which is when we decided IETF is probably the best
>>         venue; however, at that time everybody was still on
>>         Zigbee/.15.4(e) but we saw the raise of LPWANs coming (simply
>>         because it was the only technology which would work at scale).
>>