Subject: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 May 2016 09:24:35 +0000

Dear all:

In the most simplistic approach, which so far we have referred to as the remote I/O, our new protocol would instruct the LPWAN AP/GW to literally tunnel traffic from a certain device to another, inserting IPv6, UDP and COAP over the MAC and APP protocols that are present in the air. In that simplistic model, a simple source MAC is all we have to determine a flow and at the extreme, the MAC packet could be transported (even in its in is encrypted form) as a CoAP payload. This could be compared with CAPWAP, which tunnels the 802.11 frame to a controller which completes the .11 MAC process and bridges to Ethernet.

OTOH, a lot more may we achieved if the flow can be determined with a granularity beyond the simple MAC address of the device.
Ideally, the flow would also be determined some other mac (aka network) layer elements, and, to be determined, some app layer elements; the insertion process would depend on all these elements.
This is quite important considering that when the expanded packet is placed over an IP network, all the resulting processing by the routing fabric - e.g. the Internet- will be determined from the inserted headers.

The question becomes what can be signaled in the air protocol, when the frame is encoded natively as app over mac:

-        Which keys can the AP/GW access (none, MAC/Network only?, do we cover the case where the GW is also an app level GW with the app keys?)

-        What in the air protocol is signed vs. encrypted

-        Taking the reasonable assumption the AP/GW is not an app level GW, is there room in the MAC format to store a app level (opaque to the MAC) flow ID that the AP/GW can leverage for its insertion work?

-        Taking that assumption, can we live with a simple flow ID? What becomes of CoAP's Message ID and Token?

The capabilities that we can achieve depend on the answers to these fundamental questions, which in turn may depend on the protocols that we work on.

We can start guessing, playing the "what if?" game. But in truth, we're pretty much stuck till we complete the protocol selection process.

We have cross-participated for a long while now; people from IETF and LPWANs have exchanged and read specs, and the IETF has published a candidate charter.

Now is a good time for candidate LPWANs to come out and so we all kick off the work. And studying the questions above for the selected protocols would be a great start.

Pascal

---

From: Lorenzo Vangelista <[email-masked]>
Date: Mon, 23 May 2016 23:43:31 +0200

Dear Pascal,

just to be fair and clear, I am mostly interested in the LoRaWAN protocol and happy to help and work on it, to the best I can.
A fundamental aspect of this protocol, which I think everybody know, is that the GW is, in principle, a “dumb” 
packet forwarder as far as the layer above PHY are concerned. 
That said, I think we should first of all list, at least provisionally, the technologies/protocols we want to work on, and 
then clarify and agree on the terminology. I guess some of the functions you mentions for the AP/GW in the LoRaWAN 
protocol can only be handled by the central network server.  

Kind Regards

Lorenzo

> On 23 May 2016, at 11:24, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear all:
>  
> This is quite important considering that when the expanded packet is placed over an IP network, all the resulting processing by the routing fabric – e.g. the Internet- will be determined from the inserted headers.
>  
> -        Taking that assumption, can we live with a simple flow ID? What becomes of CoAP’s Message ID and Token?
>  
> We can start guessing, playing the “what if?” game. But in truth, we’re pretty much stuck till we complete the protocol selection process.
>  
> _______________________________________________
> lp-wan mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 24 May 2016 17:00:07 +0800

Dear Lorenzo，

The appearance of LoRa concept provides a good method to settle the long distance communication problem of the lpwan. But, LoRa may also do present some problems. In LoRa, gateways communicate central network servers using complete IP technologies. These gateways take the assumption that the link between the gateway and the central server has enough bandwidth. So, in LoRa, the GW is, in principle, a “dumb” packet forwarder and therefore, just forwarded packet using UDP or TCP protocols as far as the layer above PHY are concerned. However, as the lpwan developing, the number of the "node" will be very huge, these small but large-scale packets will increase the burden of the Internet. 
And more, LoRa tacitly admitted that one gateway forwarded the packet to the “regular” central server. And in future, the gateway may need forward the packet to different central servers(because, for example, the node connected the same gateway may belong to different owners).

Anyway, I completely buy the concept: nodes send the packets to the gateway, and the gateway forward them to the internet. (In most scenarios of the IOT, actually, it less common that a node needs to directly send/get information to/from a node）.

Kind Regards

Xiaowei Qin

From: Lorenzo Vangelista
Date: 2016-05-24 05:43
To: [email-masked]
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?
Dear Pascal,

Kind Regards

Lorenzo

Dear all:

 

 

Pascal

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

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 24 May 2016 16:32:07 +0200

Hi pascal,

Thanks for asking those questions.

On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all:
>
>
>
> In the most simplistic approach, which so far we have referred to as the
> remote I/O, our new protocol would instruct the LPWAN AP/GW to literally
> tunnel traffic from a certain device to another, inserting IPv6, UDP and
> COAP over the MAC and APP protocols that are present in the air. In that
> simplistic model, a simple source MAC is all we have to determine a flow
> and at the extreme, the MAC packet could be transported (even in its in is
> encrypted form) as a CoAP payload. This could be compared with CAPWAP,
> which tunnels the 802.11 frame to a controller which completes the .11 MAC
> process and bridges to Ethernet.
>

If I understand well we have the following architecture

    Object ~~~~~~ RADIO GW ======= LPWAN GW ======== LPWAN AP

For me CAPWAP is, in a sense, the equivalent of Packet Forwarder in LoRa.
The LPWAN GW is in charge of the MAC protocol, the radio gateway is
transparent in a way that it sends on the radio everything the LPWAN GW
sends with meta information indicating the channel to use, the coding,...

If I'm right, what you are talking about is more between the LPWAN AP and
the LPWAN GW.

>
>
> OTOH, a lot more may we achieved if the flow can be determined with a
> granularity beyond the simple MAC address of the device.
>
> Ideally, the flow would also be determined some other mac (aka network)
> layer elements, and, to be determined, some app layer elements; the
> insertion process would depend on all these elements.
>
> This is quite important considering that when the expanded packet is
> placed over an IP network, all the resulting processing by the routing
> fabric – e.g. the Internet- will be determined from the inserted headers.
>

In my views the LPWAN AP is aware of the LPWAN network and so can adapt
what are sent on the network and can use some specific protocols to signal
information to the LPWAN GW.

>
>
> The question becomes what can be signaled in the air protocol, when the
> frame is encoded natively as app over mac:
>
> -        Which keys can the AP/GW access (none, MAC/Network only?, do we
> cover the case where the GW is also an app level GW with the app keys?)
>

The LPWAN GW does not have to get the key for app. which means that only
the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed in
https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1
is to use a SHIM to refer to a compressed stack. The SHIM can be carried by
L3 or by L2 to optimize, which means that the LPWAN will have to send it
separately to allow the LPWAN GW to insert it into L2 frame.

> -        What in the air protocol is signed vs. encrypted

depends of MAC, it is not IETF business.

> -        Taking the reasonable assumption the AP/GW is not an app level
> GW, is there room in the MAC format to store a app level (opaque to the
> MAC) flow ID that the AP/GW can leverage for its insertion work?
>

That's why the SHIM may be important. The SHIM can be carried in Layer 3
protocol or Layer 2 protocol, so the 6LPWA working group can work on
something  generic. Then when you instantiate for 6LPWA other foo.

> The capabilities that we can achieve depend on the answers to these
> fundamental questions, which in turn may depend on the protocols that we
> work on.
>
>
>
> We can start guessing, playing the “what if?” game. But in truth, we’re
> pretty much stuck till we complete the protocol selection process.
>
>
>
> We have cross-participated for a long while now; people from IETF and
> LPWANs have exchanged and read specs, and the IETF has published a
> candidate charter.
>
>
>
> Now is a good time for candidate LPWANs to come out and so we all kick off
> the work. And studying the questions above for the selected protocols would
> be a great start.
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: "weigengyu" <[email-masked]>
Date: Wed, 25 May 2016 10:39:44 +0800

Hi, 

Probably, a basic problem is whether the smart object is treated as a independent IP node logically?

If yes, each smart node should have a IPv6 address no matter the address is kept in Gateway or in the node itself, 
no matter the address is compressed or not.

Regards, 

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Laurent Toutain 
Sent: Tuesday, May 24, 2016 10:32 PM
To: Pascal Thubert (pthubert) 
Cc: [email-masked] 
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi pascal,  

On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

  Dear all:

                       
For me CAPWAP is, in a sense, the equivalent of Packet Forwarder in LoRa. The LPWAN GW is in charge of the MAC protocol, the radio gateway is transparent in a way that it sends on the radio everything the LPWAN GW sends with meta information indicating the channel to use, the coding,...

If I'm right, what you are talking about is more between the LPWAN AP and the LPWAN GW.

In my views the LPWAN AP is aware of the LPWAN network and so can adapt what are sent on the network and can use some specific protocols to signal information to the LPWAN GW.  

The LPWAN GW does not have to get the key for app. which means that only the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed in https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1 is to use a SHIM to refer to a compressed stack. The SHIM can be carried by L3 or by L2 to optimize, which means that the LPWAN will have to send it separately to allow the LPWAN GW to insert it into L2 frame. 

That's why the SHIM may be important. The SHIM can be carried in Layer 3 protocol or Layer 2 protocol, so the 6LPWA working group can work on something  generic. Then when you instantiate for 6LPWA other foo. 

  Pascal

-- 

Laurent Toutain 
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit : 
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 25 May 2016 05:08:15 +0000

This is a good comment.

>From my point of view, the efforts around bringing IPv6 to the device is a great and any thing IETF can do that is worthy effort.  But, personally what I care and what is important on a short term basis (IMO), is the transport between the gateway and the network server, the aspects of gateway management, the aspect of radio resource management (RRM). These are some of the problem relevant for most of the LPWAN technologies and off course excluding the key NB-IOT as IETF has very little influence on its direction.  These issues are critical for realizing large scale LPWAN deployments.

In this sense, CAPWAP is a key protocol that we cannot ignore. Before we go design a new protocol, it is important to realize what is out there and the capabilities of that protocol.  Its important to understand that CAPWAP is not tied to any specific radio technology. When CAPWAP was standardized, IETF made it a point to decouple 802.11 access from the protocol allowing definition of bindings for future radio technologies. Its is also important to note the similarities in LPWAN and WLAN architectures; the three node model of Device/Gateway/NS (Client/AP/WLC), or the aspect of MAC termination on WLC, makes CAPWAP a strong candidate.

Sri

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Vangelista <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 23, 2016 at 2:43 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Dear Pascal,

A fundamental aspect of this protocol, which I think everybody know, is that the GW is, in principle, a "dumb"

Kind Regards

Lorenzo

---

From: "Ver Steeg, William (Contractor)" <[email-masked]>
Date: Wed, 25 May 2016 08:52:01 +0000

We need to be sure to remember that one of the huge advantages to several of these network types (for instance LoRaWan) is the fact that the Gateway is very nearly stateless. This allows the operator to deploy in a very lightweight, cost effective manner. There is no session established between the end node (which I generally think of as a sensor) and the gateway, end nodes come and go (as seen by the Gateway), and ideally there is no end node state kept on the Gateway.

Bill VerSteeg

P.S. sorry for being late to the thread - I have been heads-down on a LoRaWan project and just now popped up for air.....

________________________________
From: lp-wan <[email-masked]> on behalf of weigengyu <[email-masked]>
Sent: Tuesday, May 24, 2016 10:39 PM
To: Laurent Toutain; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi,

Regards,

Gengyu WEI

From: Laurent Toutain<mailto:[email-masked]>
Sent: Tuesday, May 24, 2016 10:32 PM
To: Pascal Thubert (pthubert)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi pascal,

On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

Pascal

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

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

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

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 25 May 2016 11:26:31 +0200

Hi,

I agree for the radio gateway (aka BTS) but there is other gateways in the
system. We need to have a precise definition of the gateway  otherwise it
will lead to a lot of confusion on the mailing list.

In draft draft-pelov-core-cosol-01 we propose the following definition:

 We can identify three types of entities in a typical LP-WAN.  These
   are:

   o  Node-F: far-reachable node, e.g. the end-point, object, device.

   o  Node-R: radio relay, bridging the LP-WAN radio technology to a
      different medium (often a LAN or cellular WAN).

   o  Node-G: gateway node, interconnection between the radio-relay node
      and the Internet.

   +--------+                      +--------+            +--------+
   | Node-F | <-- LP-WAN radio --> | Node-R | <-- IP --> | Node-G |
   +--------+                      +--------+            +--------+

In LoRa point of view, node-G will be the network server.

Can we agree on the mailist list to a reference architecture with a common
name associated to each componments ?

Thanks

Laurent

On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor) <
[email-masked]> wrote:

> We need to be sure to remember that one of the huge advantages to several
> of these network types (for instance LoRaWan) is the fact that the Gateway
> is very nearly stateless. This allows the operator to deploy in a very
> lightweight, cost effective manner. There is no session established between
> the end node (which I generally think of as a sensor) and the gateway, end
> nodes come and go (as seen by the Gateway), and ideally there is no end
> node state kept on the Gateway.
>
>
> Bill VerSteeg
>
>
> P.S. sorry for being late to the thread - I have been heads-down on a
> LoRaWan project and just now popped up for air.....
> ------------------------------
> *From:* lp-wan <[email-masked]> on behalf of weigengyu <
> [email-masked]>
> *Sent:* Tuesday, May 24, 2016 10:39 PM
> *To:* Laurent Toutain; Pascal Thubert (pthubert)
>
> *Cc:* [email-masked]
> *Subject:* Re: [lp-wan] The compression problem: protocol dependant? if
> so, which protocol(s)?
>
> Hi,
>
> If yes, each smart node should have a IPv6 address no matter the address
> is kept in Gateway or in the node itself,
> *From:* Laurent Toutain <[email-masked]>
> *Sent:* Tuesday, May 24, 2016 10:32 PM
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [lp-wan] The compression problem: protocol dependant? if
> so, which protocol(s)?
>
> Hi pascal,
>
>> Now is a good time for candidate LPWANs to come out and so we all kick
>> off the work. And studying the questions above for the selected protocols
>> would be a great start.
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ------------------------------

---

From: Benoît PONSARD (SIGFOX) <[email-masked]>
Date: Thu, 26 May 2016 06:32:23 +0200

Hi all,

I've just seen Laurent's email on architecture elements. I think his
definition of the architecture elements is compatible with what Sigfox is
doing (see the overall architecture attached). Names are different but main
features seem to be quite equivalent.

I'm taking the opportunity of this email to confirm that Sigfox will attend
the Berlin meeting and is ready to present its technology. I also confirm
that, after the Berlin's meeting, we have in mind to allocate some human
resources to contribute to the 6LPWA work, more actively that I'm currently
doing up to now !

BR

BPS

2016-05-25 11:26 GMT+02:00 Laurent Toutain <
[email-masked]>:

>>> -        Which keys can the AP/GW access (none, MAC/Network only?, do
>>> we cover the case where the GW is also an app level GW with the app keys?)
>>>
>>
>>> -        Taking that assumption, can we live with a simple flow ID?
>>> What becomes of CoAP’s Message ID and Token?
>>>
>>>
>>>

-- 
Benoît PONSARD
Director of Standardization
Mobile : +33 (0)6 84 74 70 71
www.sigfox.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 May 2016 04:58:14 +0000

Fantastic news Benoit!

Defining abstract architecture elements is really useful to enable multiple technologies, as long as the mapping to the actual protocol elements is straightforward.

It will be good that the mapping is explicitly documented to avoid recurring questions.

Regards,

Pascal

Le 26 mai 2016 à 06:32, Benoît PONSARD (SIGFOX) <[email-masked]<mailto:[email-masked]>> a écrit :

Hi all,

I've just seen Laurent's email on architecture elements. I think his definition of the architecture elements is compatible with what Sigfox is doing (see the overall architecture attached). Names are different but main features seem to be quite equivalent.

I'm taking the opportunity of this email to confirm that Sigfox will attend the Berlin meeting and is ready to present its technology. I also confirm that, after the Berlin's meeting, we have in mind to allocate some human resources to contribute to the 6LPWA work, more actively that I'm currently doing up to now !

BR

BPS

2016-05-25 11:26 GMT+02:00 Laurent Toutain <[email-masked]<mailto:[email-masked]>>:
Hi,

I agree for the radio gateway (aka BTS) but there is other gateways in the system. We need to have a precise definition of the gateway  otherwise it will lead to a lot of confusion on the mailing list.

Can we agree on the mailist list to a reference architecture with a common name associated to each componments ?

Thanks

Laurent

On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor) <[email-masked]<mailto:[email-masked]>> wrote:

Bill VerSteeg

________________________________
From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of weigengyu <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 24, 2016 10:39 PM
To: Laurent Toutain; Pascal Thubert (pthubert)

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

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

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

--
Benoît PONSARD
Director of Standardization
Mobile : +33 (0)6 84 74 70 71
www.sigfox.com<http://www.sigfox.com>

<Capture d’e´cran 2016-05-25 a` 05.03.08.png>
_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 26 May 2016 07:32:37 +0200

Yes, indeed!

Thanks, Benoit, for the formal confirmation of your participation. You have the first slot on our technology list for the charter! :)

We could probably take the architecture description in its own draft, independent of CoSOL.

Best,
Alexander

> Le 26 mai 2016 à 06:58, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Fantastic news Benoit!
> 
> Le 26 mai 2016 à 06:32, Benoît PONSARD (SIGFOX) <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>> Hi all,
>> 
>> 2016-05-25 11:26 GMT+02:00 Laurent Toutain <[email-masked] <mailto:[email-masked]>>:
>> Hi, 
>> 
>> 
>> On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor) <[email-masked] <mailto:[email-masked]>> wrote:
>> From: lp-wan <[email-masked] <mailto:[email-masked]>> on behalf of weigengyu <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> From: Laurent Toutain <mailto:[email-masked]>
>> To: Pascal Thubert (pthubert) <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
>> On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
>> Dear all:
>> 
>>  
>> 
>> The LPWAN GW does not have to get the key for app. which means that only the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed in https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1 <https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1> is to use a SHIM to refer to a compressed stack. The SHIM can be carried by L3 or by L2 to optimize, which means that the LPWAN will have to send it separately to allow the LPWAN GW to insert it into L2 frame.
>> 
>> | Tel: +33 2 22 06 8156 <tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026 <tel:%2B%2033%202%2099%2012%207026>                 | Visit :
>> | Fax: +33 2 22 06 8445 <tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030 <tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in <http://class.touta.in/>
>> | [email-masked] <mailto:[email-masked]>         | [email-masked] <mailto:[email-masked]>    |
>> | Tel: +33 2 22 06 8156 <tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026 <tel:%2B%2033%202%2099%2012%207026>                 | Visit :
>> | Fax: +33 2 22 06 8445 <tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030 <tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in <http://class.touta.in/>
>> | [email-masked] <mailto:[email-masked]>         | [email-masked] <mailto:[email-masked]>    |
>> www.sigfox.com <http://www.sigfox.com/>
>> 
>> <Capture d’écran 2016-05-25 à 05.03.08.png>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 May 2016 09:41:12 +0300

Hi Pascal,

I presume we are talking about this:

device ---- network_node ---- remote_end

Where device implements app_stack/LPWAN_mac
remote_end implements app_stack/transport/IP
hence, the network_node implements LPWAN_mac on one side, and transport/IP
on the other side, and take care of the interworking.

The question is: should the remote_end be aware of what's going on, or
should it think device and network_node are the same hence thinking it's
communicating with an IP-enabled device?

Alper

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 May 2016 06:47:52 +0000

Agreed, Alex.

We can fit this in the first item of the charter can't we?

Regards,

Pascal

Le 26 mai 2016 à 07:32, Alexander Pelov <[email-masked]<mailto:[email-masked]>> a écrit :

Yes, indeed!

Best,
Alexander

Le 26 mai 2016 à 06:58, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> a écrit :

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

| Fax: +33 2 22 06 8445<tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030<tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in<http://class.touta.in/>

| Fax: +33 2 22 06 8445<tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030<tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in<http://class.touta.in/>

--
Benoît PONSARD
Director of Standardization
Mobile : +33 (0)6 84 74 70 71
www.sigfox.com<http://www.sigfox.com/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 May 2016 06:58:16 +0000

Hello Alper:

My mind image is that the remote end is talking to a component of a system.

In the classical world this could be a PC with some internal and external boards connected over PCI or USB, and we'd want to address these boards. Here the system starts at the "network server" and we want a simple abstraction of what's inside.

In the IPv4 days we'd use only one IP address for the PC and point on a board with a port Nb.
With IPv6 and CoAP we have a world of opportunities, with the constraint that all gets elided in the air.

In short I'm not making the hard assumption that the IP header alone leads to one device. It may lead to a larger system, or at another extreme to one subsystem of the device.

To be refined...

Pascal

Le 26 mai 2016 ? 08:41, Alper Yegin <[email-masked]<mailto:[email-masked]>> a ?crit :

Hi Pascal,

Where device implements app_stack/LPWAN_mac
remote_end implements app_stack/transport/IP
hence, the network_node implements LPWAN_mac on one side, and transport/IP on the other side, and take care of the interworking.

The question is: should the remote_end be aware of what's going on, or should it think device and network_node are the same hence thinking it's communicating with an IP-enabled device?

Alper

On Mon, May 23, 2016 at 12:24 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

Pascal

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 26 May 2016 09:56:22 +0200

Hi Alper,

I think the first step is to agree on a common architecture, just to be
able to name things the same way. For instance "gateway" is too confusing
and will lead to some misunderstanding on exchanges on the mailing list.

>From what I see from the different architectures, we can identify four
elements. I represented it in a previous mail using Pascal terminology.

         Object ~~~~~~ RADIO GW ======= LPWAN GW ======== LPWAN AP
LoRaWAN   ????        gateway        Network Server  Application Server
SIGFOX   End Point  base station     Service centre  Application Server
CoSol    node-F        node-R           node-G            node-R

The terminology must be independent of a specific technology to avoid
confusion and to assign some properties that are not present in other
technologies. That's why cosol uses these names.

Laurent

On Thu, May 26, 2016 at 8:58 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> In the classical world this could be a PC with some internal and external
> boards connected over PCI or USB, and we'd want to address these boards.
> Here the system starts at the "network server" and we want a simple
> abstraction of what's inside.
>
> In short I'm not making the hard assumption that the IP header alone leads
> to one device. It may lead to a larger system, or at another extreme to one
> subsystem of the device.
>
> To be refined...
>
> Pascal
>
> Le 26 mai 2016 à 08:41, Alper Yegin <[email-masked]> a écrit :
>
> Hi Pascal,
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 May 2016 11:03:53 +0300

Hello Laurent,

LoRa calls the object "End-device" (or device in short).

Alper

On Thu, May 26, 2016 at 10:56 AM, Laurent Toutain <
[email-masked]> wrote:

>> In short I'm not making the hard assumption that the IP header alone
>> leads to one device. It may lead to a larger system, or at another extreme
>> to one subsystem of the device.
>>
>> To be refined...
>>
>> Pascal
>>
>> hence, the network_node implements LPWAN_mac on one side, and
>> transport/IP on the other side, and take care of the interworking.
>>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 26 May 2016 16:06:54 +0800

+1

From: Laurent Toutain
Date: 2016-05-26 15:56
To: Pascal Thubert (pthubert)
CC: [email-masked]; Alper Yegin
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?
Hi Alper,

I think the first step is to agree on a common architecture, just to be able to name things the same way. For instance "gateway" is too confusing and will lead to some misunderstanding on exchanges on the mailing list.

>From what I see from the different architectures, we can identify four elements. I represented it in a previous mail using Pascal terminology.

The terminology must be independent of a specific technology to avoid confusion and to assign some properties that are not present in other technologies. That's why cosol uses these names.

Laurent

On Thu, May 26, 2016 at 8:58 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
Hello Alper:

To be refined...

Pascal

Hi Pascal, 

Alper

On Mon, May 23, 2016 at 12:24 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
Dear all:

 

 

Pascal

---

From: Benoît PONSARD (SIGFOX) <[email-masked]>
Date: Thu, 26 May 2016 10:22:46 +0200

Hi Laurent,

the names in the architecture I attached to my previous emails are the ones
used by the ETSI/ERM/TG28/LTN specification group which is working on
specifying the radio interface of LPWAN based on ultra-narrow band
communication.

"Base station" is used to show that this element of the architecture is
much more than just a gateway. It performs quite complex fonctions and its
behavior is mainly controlled by the core network.

"Service centre" is used to show that service (as a whole) is delivered by
this entity. Once again, the service is not only point to point
communication, it's also de-duplication of radio packets, AAA, spectrum
monitoring and network monitoring.

I think the names, that will be used by 6LPWA, should reflect the
complexity of the various elements.

BR

BPS

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 26 May 2016 10:44:08 +0200

Hi Benoit,

Thanks for clearing this up! This means that from functional point of view, the "Service centre" can be divided into the components that you mentioned - AAA, supervision, etc. 

The base station is indeed a very complex equipment and the question is if the complexity is visible from the upper layers (e.g. can we simply say that we have a tunnel from the Base Station to the entry point of the "Service centre" ) ?

I actually like Pascal’s naming of the nodes very much in the sense that they capture the essence of each component. Some things are missing out of the picture - most notably the AAA and other types of servers. This brings me to the conclusion that we do need architecture draft that names the elements and that defines the different interfaces, and the corresponding terminology for ETSI, LoRa and other technologies. 

Best,
Alexander

> Le 26 mai 2016 à 10:22, Benoît PONSARD (SIGFOX) <[email-masked]> a écrit :
> 
> Hi Laurent,
> 
> the names in the architecture I attached to my previous emails are the ones used by the ETSI/ERM/TG28/LTN specification group which is working on specifying the radio interface of LPWAN based on ultra-narrow band communication.
> 
> "Base station" is used to show that this element of the architecture is much more than just a gateway. It performs quite complex fonctions and its behavior is mainly controlled by the core network.
> 
> "Service centre" is used to show that service (as a whole) is delivered by this entity. Once again, the service is not only point to point communication, it's also de-duplication of radio packets, AAA, spectrum monitoring and network monitoring.
> 
> I think the names, that will be used by 6LPWA, should reflect the complexity of the various elements.
> 
> BR
> 
> BPS
> 
> 2016-05-26 9:56 GMT+02:00 Laurent Toutain <[email-masked] <mailto:[email-masked]>>:
> Hi Alper,
> 
> On Thu, May 26, 2016 at 8:58 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Alper:
> 
> Le 26 mai 2016 à 08:41, Alper Yegin <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>> Hi Pascal,
>> 
>> On Mon, May 23, 2016 at 12:24 PM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
>> Dear all:
>> 
>>  
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 26 May 2016 09:30:47 +0000

Alex - You may want to look at the existing terminology from CAPWAP specs. Its the Station, Wireless termination point, Access controller and Application Peer (no specific term). Maps to Device, Gateway, NS, AF respectively.

RFC 5415

"WTPs are
   viewed as remote radio frequency (RF) interfaces controlled by the
   AC.  The CAPWAP protocol supports two modes of operation: Split and
   Local MAC (medium access control).  In Split MAC mode, all L2
   wireless data and management frames are encapsulated via the CAPWAP
   protocol and exchanged between the AC and the WTP.  As shown in
   Figure 1, the wireless frames received from a mobile device, which is
   referred to in this specification as a Station (STA), are directly
   encapsulated by the WTP and forwarded to the

"

Sent from my iPad

On May 26, 2016, at 1:44 AM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Benoit,

Best,
Alexander

Le 26 mai 2016 à 10:22, Benoît PONSARD (SIGFOX) <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Laurent,

BR

BPS

2016-05-26 9:56 GMT+02:00 Laurent Toutain <[email-masked]<mailto:[email-masked]>>:
Hi Alper,

Laurent

On Thu, May 26, 2016 at 8:58 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Alper:

To be refined...

Pascal

Le 26 mai 2016 à 08:41, Alper Yegin <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Alper

Pascal

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 26 May 2016 10:17:01 +0000

I very much look forward to this presentation from Benoit as well. Unless SIGFOX opens up the specs (at a protocol messaging level), this is a closed system and I'm not sure how much we can discuss about that access in IETF, both from legal and from guidelines point of view. We already know NB-IOT's own path and that mainly leaves LoRa which is yet to adopt IP and every single item here is tied to that.  In this sense and for broader applicability of this work, I hope to see SIGFOX specs.

Sri

Sent from my iPad

On May 25, 2016, at 10:32 PM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 26 May 2016 15:02:08 +0200

Hi Sri,

that's may be a good choice. If I understand well the figure

              +-+         wireless frames        +-+
              | |--------------------------------| |
              | |              +-+               | |
              | |--------------| |---------------| |
              | |wireless PHY/ | |     CAPWAP    | |
              | | MAC sublayer | |               | |
              +-+              +-+               +-+
              STA              WTP                AC

STA is the equivalent of Node-F/End Point,
the WTP the Node-R Base Station and
the AC the Node-G/Network Server

For me, CAPWAP is the equivalent of the LoRa Packet Forwarder which
encapsulates frames to be sent/received on radio, for instance:

{"rxpk":[{"tmst":14274150,"time":"2016-01-08T14:23:44.
889110Z","chan":8,"rfch":0,"freq":870.000000,"stat":1,"
modu":"LORA","datr":"SF7BW250","codr":"4/7","lsnr":9.2,"
rssi":-85,"size":40,"data":"IjYB+rAAAAAAAAUAAEEBap9iPQNlcHNpbG9
uLnQuZXUub3Jng2x1bQ=="}]}

You are right that CAPWAP may be more flexible, more secure, but for my
point of view this should not be the first priority of the working group
which should be compression and management.

Laurent

On Thu, May 26, 2016 at 12:17 PM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> I very much look forward to this presentation from Benoit as well. Unless
> SIGFOX opens up the specs (at a protocol messaging level), this is a closed
> system and I'm not sure how much we can discuss about that access in IETF,
> both from legal and from guidelines point of view. We already know NB-IOT's
> own path and that mainly leaves LoRa which is yet to adopt IP and every
> single item here is tied to that.  In this sense and for broader
> applicability of this work, I hope to see SIGFOX specs.
>
> Sri
>
> Sent from my iPad
>
> On May 25, 2016, at 10:32 PM, Alexander Pelov <[email-masked]> wrote:
>
> Yes, indeed!
>
> Thanks, Benoit, for the formal confirmation of your participation. You
> have the first slot on our technology list for the charter! :)
>
> Defining abstract architecture elements is really useful to enable
> multiple technologies, as long as the mapping to the actual protocol
> elements is straightforward.
>
> Le 26 mai 2016 à 06:32, Benoît PONSARD (SIGFOX) <[email-masked]>
> a écrit :
>
> Hi all,
>
> I'm taking the opportunity of this email to confirm that Sigfox will
> attend the Berlin meeting and is ready to present its technology. I also
> confirm that, after the Berlin's meeting, we have in mind to allocate some
> human resources to contribute to the 6LPWA work, more actively that I'm
> currently doing up to now !
>
> BR
>
> BPS
>
>
>
>> I agree for the radio gateway (aka BTS) but there is other gateways in
>> the system. We need to have a precise definition of the gateway  otherwise
>> it will lead to a lot of confusion on the mailing list.
>>
>> Can we agree on the mailist list to a reference architecture with a
>> common name associated to each componments ?
>>
>> Thanks
>>
>> Laurent
>>
>>> We need to be sure to remember that one of the huge advantages to
>>> several of these network types (for instance LoRaWan) is the fact that the
>>> Gateway is very nearly stateless. This allows the operator to deploy in a
>>> very lightweight, cost effective manner. There is no session established
>>> between the end node (which I generally think of as a sensor) and the
>>> gateway, end nodes come and go (as seen by the Gateway), and ideally there
>>> is no end node state kept on the Gateway.
>>>
>>>
>>> Bill VerSteeg
>>>
>>>
>>>> In the most simplistic approach, which so far we have referred to as
>>>> the remote I/O, our new protocol would instruct the LPWAN AP/GW to
>>>> literally tunnel traffic from a certain device to another, inserting IPv6,
>>>> UDP and COAP over the MAC and APP protocols that are present in the air. In
>>>> that simplistic model, a simple source MAC is all we have to determine a
>>>> flow and at the extreme, the MAC packet could be transported (even in its
>>>> in is encrypted form) as a CoAP payload. This could be compared with
>>>> CAPWAP, which tunnels the 802.11 frame to a controller which completes the
>>>> .11 MAC process and bridges to Ethernet.
>>>>
>>>
>>> For me CAPWAP is, in a sense, the equivalent of Packet Forwarder in
>>> LoRa. The LPWAN GW is in charge of the MAC protocol, the radio gateway is
>>>> -        Taking the reasonable assumption the AP/GW is not an app
>>>> level GW, is there room in the MAC format to store a app level (opaque to
>>>> the MAC) flow ID that the AP/GW can leverage for its insertion work?
>>>>
>>>
>>> | [email-masked] <[email-masked]>         |
>>> [email-masked]
>>> <[email-masked]>    |
>> | [email-masked] <[email-masked]>         |
>> [email-masked] <[email-masked]>
>>    |

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 26 May 2016 16:14:26 +0000

Hi Laurent,

Yes. The transport/packet forwarding is one of the functions that you get for free in addition to so many capabilities.

To your finer point that phase-1 should only be about “compressions and management”,  I’d say if the scope is only compression it is not interesting to me at least, as it not solving any immediate problems. If you say,  “management” then that overlaps with CAPWAP offers and all of this discussion is relevant.

Sri

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 26, 2016 at 6:02 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Benoît PONSARD (SIGFOX)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>, Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi Sri,

              +-+         wireless frames        +-+

For me, CAPWAP is the equivalent of the LoRa Packet Forwarder which encapsulates frames to be sent/received on radio, for instance:

{"rxpk":[{"tmst":14274150,"time":"2016-01-08T14:23:44.889110Z","chan":8,"rfch":0,"freq":870.000000,"stat":1,"modu":"LORA","datr":"SF7BW250","codr":"4/7","lsnr":9.2,"rssi":-85,"size":40,"data":"IjYB+rAAAAAAAAUAAEEBap9iPQNlcHNpbG9uLnQuZXUub3Jng2x1bQ=="}]}

You are right that CAPWAP may be more flexible, more secure, but for my point of view this should not be the first priority of the working group which should be compression and management.

Laurent

On Thu, May 26, 2016 at 12:17 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
I very much look forward to this presentation from Benoit as well. Unless SIGFOX opens up the specs (at a protocol messaging level), this is a closed system and I'm not sure how much we can discuss about that access in IETF, both from legal and from guidelines point of view. We already know NB-IOT's own path and that mainly leaves LoRa which is yet to adopt IP and every single item here is tied to that.  In this sense and for broader applicability of this work, I hope to see SIGFOX specs.

Sri

Sent from my iPad

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

--
Benoît PONSARD
Director of Standardization
Mobile : +33 (0)6 84 74 70 71<tel:%2B33%20%280%296%2084%2074%2070%2071>
www.sigfox.com<http://www.sigfox.com/>

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

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 26 May 2016 18:39:27 +0200

Dear Sri,

Thanks very much for sharing your thoughts on this point!

What would be the problems that you would like to see addressed, specifically for LoRa networks, and maybe more generally for other LPWAs?

Best,
Alexander

> Le 26 mai 2016 à 18:14, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> Hi Laurent,
> 
> From: lp-wan <[email-masked] <mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked] <mailto:[email-masked]>>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> Cc: "Benoît PONSARD (SIGFOX)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked] <mailto:[email-masked]>>, Alexander Pelov <[email-masked] <mailto:[email-masked]>>
> On Thu, May 26, 2016 at 12:17 PM, Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> wrote:
>> On May 25, 2016, at 10:32 PM, Alexander Pelov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Yes, indeed!
>>> 
>>>> Le 26 mai 2016 à 06:58, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> a écrit :
>>>> 
>>>> Fantastic news Benoit!
>>>> 
>>>>> Mobile : +33 (0)6 84 74 70 71 <tel:%2B33%20%280%296%2084%2074%2070%2071>
> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in <http://class.touta.in/>
> | [email-masked] <mailto:[email-masked]>         | [email-masked] <mailto:[email-masked]>    |

---

From: Yeoh Chun-Yeow <[email-masked]>
Date: Fri, 27 May 2016 00:55:02 +0800

Hi, Sri

Sorry for the interrupt. What you mean by "NB-IOT's own path"?

Regards,
Chun-Yeow

On Thu, May 26, 2016 at 6:17 PM, Sri Gundavelli (sgundave)
<[email-masked]> wrote:
> Thanks, Benoit, for the formal confirmation of your participation. You have
> the first slot on our technology list for the charter! :)
>
> Defining abstract architecture elements is really useful to enable multiple
> technologies, as long as the mapping to the actual protocol elements is
> straightforward.
>
> 2016-05-25 11:26 GMT+02:00 Laurent Toutain
> <[email-masked]>:
>>
>> Hi,
>>
>>
>> On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor)
>> <[email-masked]> wrote:
>>>
>>> nodes come and go (as seen by the Gateway), and ideally there is no end node
>>> state kept on the Gateway.
>>>
>>>
>>> Bill VerSteeg
>>>
>>>
>>>> simplistic model, a simple source MAC is all we have to determine a flow and
>>>> at the extreme, the MAC packet could be transported (even in its in is
>>>> encrypted form) as a CoAP payload. This could be compared with CAPWAP, which
>>>> tunnels the 802.11 frame to a controller which completes the .11 MAC process
>>>> and bridges to Ethernet.
>>>
>>>
>>>> GW, is there room in the MAC format to store a app level (opaque to the MAC)
>>>> flow ID that the AP/GW can leverage for its insertion work?
>>>
>>>
>>>> LPWANs have exchanged and read specs, and the IETF has published a candidate
>>>> charter.
>>>>
>>>>
>>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 27 May 2016 14:03:53 +0000

Hi Alex,

As I was saying in one of my earlier email, the immediate topics of interest are around the transport between the gateway and the network functions, gateway manageability, RRM on the gateways and the related issues. At this point there is no stand interop with most NS vendors providing their own packet fowarding modules for different vendor gateways and that is a real problem. Any thing and everything on compression and with the hope that SDO and the devices will adopt IPv6/CoAP stack is great, but is for long term and for certain things the ship may have already sailed.

Sri

On May 26, 2016, at 9:39 AM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:

Dear Sri,

Best,
Alexander

Le 26 mai 2016 à 18:14, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Laurent,

Sri

Hi Sri,

              +-+         wireless frames        +-+

Laurent

Sri

Sent from my iPad

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in<http://class.touta.in/>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 27 May 2016 14:21:04 +0000

Hi Chun-Yeow,

NB-IOT is viewed as one of the dominant access in the LPWAN class and at least in the SP segment. AFAIK, the SDO standardizing NB-IOT is not asking IETF for any of these work items and so understanding the target access/customers for each of these work items and the timeline of adoption may be needed. Its important to identify the gaps, market (licensed/unlicensed; SP/Ent) and get the prioritization right. 

Sri

> On May 26, 2016, at 9:55 AM, Yeoh Chun-Yeow <[email-masked]> wrote:
> 
> Hi, Sri
>

---

From: Paul Duffy <[email-masked]>
Date: Fri, 27 May 2016 11:22:07 -0400

On 5/26/2016 2:58 AM, Pascal Thubert (pthubert) wrote:
> With IPv6 and CoAP we have a world of opportunities, with the 
> constraint that all gets elided in the air.

+1

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 27 May 2016 17:34:10 +0200

Dear Sri,

Thanks a lot for pitching in on this! Indeed, having a well-defined protocol between the RADIO-GW and the LPWAN-GW would be useful, and I believe of great interest for the community as a whole. Also, on the network functions and the RADIO-GW manageability. These all would be perfect candidates for a BCP in our group. 

Would you be willing to write up a short document to outline the issues that you feel would be most pertinent for your use-case? This could be the foundation for the BCP document. One thing I’d like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions. Would OpenFlow be better suited? Or simply NETCONF? I’d be very happy to see a couple of scenarios and work on the simplest solution from there. 

Also, there should be support from the stakeholders. I don’t want to do work if it will be in conflict with the supporting technologies.

Best,
Alexander

> Le 27 mai 2016 à 16:03, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> Hi Alex,
> 
> On May 26, 2016, at 9:39 AM, Alexander Pelov <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Dear Sri,
>> 
>>> Le 26 mai 2016 à 18:14, Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Hi Laurent,
>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 27 May 2016 16:17:22 +0000

Hi Alex,

Regarding your comment on BCP document, I’m trying to understand your goal here. I’m more interested in WG defining a standardized interface/transport and not sure how BCP document gets us there.  Is it more as FYI ? Unfortunately, I don’t get any thing out of that as it is not solving my problem.

> This could be the foundation for the BCP document. One thing I’d like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions.

The link conditions / operating environment of the radio, and the choice of the protocol (for the interface between the gateway and a controller) may be independent of each other. Certainly, NETCONF, OpenFlow, or CAPWAP are some of the candidates. Also, there is the second part to this problem and it is the information model for RRM, which is radio technology specific; May be just for LoRa; NB-IOT may be out of scope and I’ve no info on SIGFOX to come out with a information model at this time, unless Benoit publishes one.

But,  I’m glad we are discussing these points.

Sri

From: Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 27, 2016 at 8:34 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "\"Benoît PONSARD (SIGFOX)\"" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Laurent Toutain <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Dear Sri,

Best,
Alexander

Le 27 mai 2016 à 16:03, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alex,

Sri

Dear Sri,

Best,
Alexander

Hi Laurent,

Sri

Hi Sri,

              +-+         wireless frames        +-+

Laurent

Sri

Sent from my iPad

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 27 May 2016 18:42:39 +0200

Dear Sri,

> Le 27 mai 2016 à 18:17, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> Hi Alex,
> 

We could do a BCP if we identify that there is already an existing protocol that does the job, but which may eventually need some clarification. For example, if we reach the conclusion that CAPWAP is the best candidate, then the document will say so - and will potentially add some guidelines on how to use it. This is, of course, if we decide that there is enough interest AND support from the technology providers to address these questions. 

I’d be happy to include this point in the charter if there is support from the mailing list. Let’s wait until the three fundamental technologies are fixed and we can continue with this point right after.

> The link conditions / operating environment of the radio, and the choice of the protocol (for the interface between the gateway and a controller) may be independent of each other. Certainly, NETCON…

I’d say that for the moment we could stick to YANG for this purpose (again, if there is support for going into that direction). There is already a YANG module for LoRa, and it will be extended easily to LoRaWAN. Adding modules for the other candidate technologies would be easy if this is the need.

Best,
Alexander

> From: Alexander Pelov <[email-masked] <mailto:[email-masked]>>
> Cc: "\"Benoît PONSARD (SIGFOX)\"" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Laurent Toutain <[email-masked] <mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked] <mailto:[email-masked]>>
>> Le 27 mai 2016 à 16:03, Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi Alex,
>> 
>>>>>>>>>> The LPWAN GW does not have to get the key for app. which means that only the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed inhttps://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1 <https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1> is to use a SHIM to refer to a compressed stack. The SHIM can be carried by L3 or by L2 to optimize, which means that the LPWAN will have to send it separately to allow the LPWAN GW to insert it into L2 frame.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 27 May 2016 17:05:10 +0000

Hello Sri:

We need to understand what the abstract architecture components are, how they map to existing LPWA protocols. Laurent made a great step in that direction, and we need to complete the protocol selection work to map that to real protocols.

In parallel, we can be interested in an exercise that presents the CAPWAP protocol entities and how they map to this architecture, if only to show that what we are doing does not already exist at the IETF. And then maybe we could show that CAPWAP is a candidate to consider in a future control protocol. This clarification work can be started any time as an  individual contribution.

The first round of the charter does not take us that far. We care to educate the IETF community and propose bases for the work. As for data plane, we consider mostly the compression, which state to install where, which compression operation, what resulting packet.

By the time that pass is done, we should have a better understanding on whether we define a management protocol and/or a frame encapsulation, and whether extending CAPWAP is the way to go. We are some steps away from that yet.

Cheers,

Pascal

From: Sri Gundavelli (sgundave)
Sent: vendredi 27 mai 2016 18:17
To: Alexander Pelov <[email-masked]>
Cc: "Benoît PONSARD (SIGFOX)" <[email-masked]>; [email-masked]; Laurent Toutain <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi Alex,

Regarding your comment on BCP document, I'm trying to understand your goal here. I'm more interested in WG defining a standardized interface/transport and not sure how BCP document gets us there.  Is it more as FYI ? Unfortunately, I don't get any thing out of that as it is not solving my problem.

> This could be the foundation for the BCP document. One thing I'd like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions.

The link conditions / operating environment of the radio, and the choice of the protocol (for the interface between the gateway and a controller) may be independent of each other. Certainly, NETCONF, OpenFlow, or CAPWAP are some of the candidates. Also, there is the second part to this problem and it is the information model for RRM, which is radio technology specific; May be just for LoRa; NB-IOT may be out of scope and I've no info on SIGFOX to come out with a information model at this time, unless Benoit publishes one.

But,  I'm glad we are discussing these points.

Sri

Dear Sri,

Would you be willing to write up a short document to outline the issues that you feel would be most pertinent for your use-case? This could be the foundation for the BCP document. One thing I'd like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions. Would OpenFlow be better suited? Or simply NETCONF? I'd be very happy to see a couple of scenarios and work on the simplest solution from there.

Also, there should be support from the stakeholders. I don't want to do work if it will be in conflict with the supporting technologies.

Best,
Alexander

Hi Alex,

Sri

Best,
Alexander

Hi Laurent,

To your finer point that phase-1 should only be about "compressions and management",  I'd say if the scope is only compression it is not interesting to me at least, as it not solving any immediate problems. If you say,  "management" then that overlaps with CAPWAP offers and all of this discussion is relevant.

Sri

Hi Sri,

              +-+         wireless frames        +-+

              | |              +-+               | |

              | | MAC sublayer | |               | |

              +-+              +-+               +-+

              STA              WTP                AC

Laurent

Sri

Sent from my iPad

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

BR

BPS

Hi,

   are:

      and the Internet.

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Dear all:

Pascal

<Capture d'écran 2016-05-25 à 05.03.08.png>

---

From: Lorenzo Vangelista <[email-masked]>
Date: Fri, 27 May 2016 19:14:00 +0200

Hello Sri,

I think you are focusing on the right item to clarify first: the "information model for RRM”
IMHO, that is really what we need to tackle first and I think the technologies we are going to 
consider need to provide us with the status of the art. Then we should abstract and make a
unified one and go on to see whether existing protocols suit the need or something new need
to be invented. 

Lorenzo

> On 27 May 2016, at 18:17, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Hi Alex,
>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 30 May 2016 10:26:09 +0800

Hi Bill,

The gateway should be nearly light weight, but it must not to be stateless. 
The key constaint for light weight of 6LPWA is the wireless link rate. 
For reducing the amount of data to exchange beween Smart objects and a gateway, keeping some data in gateway is an effective way, I think.

Regrads,

Gengyu WEI

From: Ver Steeg, William (Contractor) 
Sent: Wednesday, May 25, 2016 4:52 PM
To: weigengyu ; Laurent Toutain ; Pascal Thubert (pthubert) 
Cc: [email-masked] 
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Bill VerSteeg

Hi, 

Regards, 

Gengyu WEI

From: Laurent Toutain 

Hi pascal,  

  Dear all:

                       

  Pascal

-- 

Laurent Toutain

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 15:05:19 +0000

Hi Alex,

> We could do a BCP if we identify that there is already an existing protocol that does the job, but which may eventually need some clarification. For example, if we reach the conclusion that CAPWAP…

My point is on having a clearly defined work item on the transport and the related issues and have the WG produce standards track documents for the same. At this point CAPWAP is one protocol option and sure the WG needs to choose the protocol that after some evaluation and that needs to happen.

> I’d say that for the moment we could stick to YANG for this purpose (again, if there is support for going into that direction).

Off course, every thing is based on WG’s interest, but as you know there are only half a dozen people or so who will set the WG direction and lets make sure we prioritize the work items correctly.  YANG model is needed for all protocols and that is fine and that is the general IETF direction. But, how we deliver the IE’s needs to be decided and CAPWAP is certainly another interface that Wi-Fi  vendors want to leverage.

Sri

Date: Friday, May 27, 2016 at 9:42 AM

Dear Sri,

Le 27 mai 2016 à 18:17, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alex,

Best,
Alexander

Sri

Dear Sri,

Best,
Alexander

Hi Alex,

Sri

Dear Sri,

Best,
Alexander

Hi Laurent,

Sri

Hi Sri,

              +-+         wireless frames        +-+

Laurent

Sri

Sent from my iPad

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 15:07:07 +0000

Hi Lorenzo,

Yes. Identification of the IE’s is the first step. How we deliver those IE’s and on what transport we use is a further debate.  It is possible there may be one more than one approach and for all the good reasons.

Also I agree with the state of the art comment. I think we should also make sure we attempt to leverage what is out there and not just define some thing we believe is "state of the art", but it does exactly the same as some thing else.

Regards
Sri

From: Lorenzo Vangelista <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 27, 2016 at 10:14 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Pelov <[email-masked]<mailto:[email-masked]>>, "\"Benoît PONSARD (SIGFOX)\"" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Laurent Toutain <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hello Sri,

Lorenzo

On 27 May 2016, at 18:17, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alex,

Sri

Dear Sri,

Best,
Alexander

Hi Alex,

Sri

Dear Sri,

Best,
Alexander

Hi Laurent,

Sri

Hi Sri,

              +-+         wireless frames        +-+

Laurent

Sri

Sent from my iPad

Yes, indeed!

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

Hi all,

BR

BPS

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

Hi pascal,

Pascal

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 15:14:37 +0000

HI Pascal,

I understand your goal here, but lets also make sure we solve some problems that help deployments of LPWAN technologies in the immediate time frame.

> In parallel, we can be interested in an exercise that presents the CAPWAP protocol entities and how they map to this architecture, if only to show that what we are doing does not already exist at t…

Lets do that.

Regards
Sri

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 27, 2016 at 10:05 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Cc: "\"Benoît PONSARD (SIGFOX)\"" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Subject: RE: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hello Sri:

Cheers,

Pascal

From: Sri Gundavelli (sgundave)
Sent: vendredi 27 mai 2016 18:17
To: Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Cc: "Benoît PONSARD (SIGFOX)" <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Laurent Toutain <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi Alex,

Sri

Dear Sri,

Best,
Alexander

Hi Alex,

Sri

Best,
Alexander

Hi Laurent,

Sri

Hi Sri,

              +-+         wireless frames        +-+

              | |              +-+               | |

              | | MAC sublayer | |               | |

              +-+              +-+               +-+

              STA              WTP                AC

Laurent

Sri

Sent from my iPad

Best,
Alexander

Fantastic news Benoit!

Regards,

Pascal

BR

BPS

Hi,

   are:

      and the Internet.

Thanks

Laurent

Bill VerSteeg

Hi,

Regards,

Gengyu WEI

From: Laurent Toutain<mailto:[email-masked]>
Sent: Tuesday, May 24, 2016 10:32 PM
To:Pascal Thubert (pthubert)<mailto:[email-masked]>
Cc:[email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi pascal,

Dear all:

Pascal