Subject: [lp-wan] NB IOT joining 6LPWA [was: The compression problem: protocol dependant?...]

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Jun 2016 13:33:01 +0000

And reciprocally, Antti, 

would you says that the proposed charter is a good start from the LTE-NB1 point of view?

For memory, the current draft is stored here:
https://bitbucket.org/lpwan/docs/src/master/charter-ietf-lpwan-00.txt?at=master&fileviewer=file-view-default

In particular, I have this feeling that the compression story that we are putting in place is the perfect evolution from the RoHC technique to fit IOT. Do I have that right?

Cheers,

Pascal

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Alexander Pelov
> Sent: mercredi 1 juin 2016 09:47
> To: Antti Ratilainen <[email-masked]>
> Cc: [email-masked]; Yeoh Chun-Yeow <[email-masked]>; Sri
> Gundavelli (sgundave) <[email-masked]>
> Subject: Re: [lp-wan] The compression problem: protocol dependant? if so,
> which protocol(s)?
> 
> Dear Antti,
> 
> Thank you for bringing this out to our attention. We’ve never really ruled out
> NB-IoT, but we didn’t want to overstep our mandate. This is the reason we
> wanted the stakeholders to express their willingness for the IETF to do
> standardization work.
> 
> This LS seems like a great step in this direction! This means that we could include
> it as the second 6LPWA technology for our charter.
> 
> What will be the next steps in this direction from your opinion? Do you see items
> of interest that we’re not currently covering in the proposed charter?
> 
> Best,
> Alexander
> 
> 
> > Le 1 juin 2016 à 09:31, Antti Ratilainen <[email-masked]> a écrit
> :
> >
> > Hello Sri, all,
> >
> > I noticed this discussion about NB-IoT and wanted to weigh in, as I'm working
> on these topics in Ericsson Research.
> > Inclusion of NB-IoT has been discussed in 3GPP and it is very much in their
> interest to have NB-IoT included as one of the considered technologies in this
> IETF's LP-WAN work.
> > During last meeting, 3GPP CT WG1 agreed to send the following LS to
> > IETF: LS on consideration of NB-IoT as a target technology in the
> > LPWAN BoF Can be found here from 3GPP site:
> > http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-
> CN1/TSGC1_98_Osaka/Docs
> > /C1-163121.zip Should be available soon also on IETF side.
> > In the LS, 3GPP informs that it is interested co-operate with IETF to ensure that
> efficient protocols for low power devices are developed and that 3GPP radio
> access technologies (such as NB-IoT, EC-GSM-IoT and Cat-M1 access) are
> considered in the LP-WAN discussions.
> > I don't think there is any reason to rule out NB-IoT as out of scope (any more
> than there is for SigFox for example). As was said, NB-IoT is viewed as one of
> the  significant accesses in the LP-WAN class and I believe such an integral part
> should be considered as a candidate for any improvements.
> >
> > Best regards,
> > Antti
> >

---

From: Antti Ratilainen <[email-masked]>
Date: Thu, 2 Jun 2016 15:41:01 +0000

Hi all,

Thanks for your good responses, I’m pleased to see there is interest to adopt 3GPP technologies in this work.
As I mentioned, we would like 3GPP lp-wan techs (NB-IoT, EC-GSM-IoT and Cat-M1 access)  to be considered. As the IETF work should be transparent for the local link, the characteristics (bandwidth, delays etc.) of those three could be combined to have just one set of characteristics to be dealt with.
In these techs both options, IP (IPv4 and IPv6) as well as other protocols can be used for user data delivery. The other protocols could be any protocols which should be seen as transparent for local link, such suitable options could also be discussed/developed in IETF. What we would like to see is compression profiles for these links with support to both data delivery procedures, IP delivery and generic data delivery (referred to as non-IP in 3GPP). 
3GPP links allow user data to be transported both via Control Plane (CP) and User Plane (UP), but I don’t think it matters whether CP or UP is used as long as the characteristics of the given link is known.
About the compression technique, RoHC would be good starting point, however stateless compression would also be interesting to look into. I believe 3GPP would like that  IETF could also consider looking into transport protocols which would better support these constrained links and traffic characteristics.

Regarding the proposed charter, it could reflect traffic characteristics which are implying less data and more seldom e.g. small amount of data sent once a day or even once a week. Also the 10 year operation time with a single coin-cell battery requirement sounds a bit ambitious for the considered technologies.

About 3GPP releases, Release-13 is soon to be closed. If this IETF work requires changes in 3GPP protocols, it would need to be in Release-14 the earliest, the scope of which has not been agreed on at the present time. 

BR,
Antti

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: 1. kesäkuuta 2016 16:33
To: Alexander Pelov; Antti Ratilainen
Cc: [email-masked]
Subject: NB IOT joining 6LPWA [was: The compression problem: protocol dependant?...]

And reciprocally, Antti, 

Cheers,

Pascal

> Subject: Re: [lp-wan] The compression problem: protocol dependant? if 
> so, which protocol(s)?
> 
> Dear Antti,
> 
> Thank you for bringing this out to our attention. We’ve never really 
> ruled out NB-IoT, but we didn’t want to overstep our mandate. This is 
> the reason we wanted the stakeholders to express their willingness for 
> the IETF to do standardization work.
> 
> This LS seems like a great step in this direction! This means that we 
> could include it as the second 6LPWA technology for our charter.
> 
> What will be the next steps in this direction from your opinion? Do 
> you see items of interest that we’re not currently covering in the proposed charter?
> 
> Best,
> Alexander
> 
> 
> interest to have NB-IoT included as one of the considered technologies 
> in this IETF's LP-WAN work.
> efficient protocols for low power devices are developed and that 3GPP 
> radio access technologies (such as NB-IoT, EC-GSM-IoT and Cat-M1 
> access) are considered in the LP-WAN discussions.
> than there is for SigFox for example). As was said, NB-IoT is viewed 
> as one of the  significant accesses in the LP-WAN class and I believe 
> such an integral part should be considered as a candidate for any improvements.
> >
> > Best regards,
> > Antti
> >

---

From: "weigengyu" <[email-masked]>
Date: Fri, 3 Jun 2016 17:10:39 +0800

Hi Antti,

> 3GPP links allow user data to be transported both via Control Plane (CP) 
> and User Plane (UP),
> but I don’t think it matters whether CP or UP is used as long as the 
> characteristics of the given link is known.

There is a little difference to convey date over CP and UP.
As in EC-GSM-IoT, delivering over CP offen means to be over SMS, and 
delivering over UP does to be over GPRS.

When delivering over UP, i.e. over GPRS,
the protocol stack would be CoAP/DTLS/UDP/IPv6/6L?/GPRS.
It is almost the same as other constrained networks concerned in IETF CoRE.

But when delivering over CP, i.e. over SMS,
the protocol stack may be  CoAP/DTLS/SMS, or CoAP/DTLS/UDP/SMS.
The current DTLS software need more changing because the existing open 
source software are based the knowledge of IPv6 address and UDP port.
A lot of works to make DTLS be available over SMS have been done in our Lab. 
here.

If 6LPWA WG considers 3GPP links and mobile networks of EC-GSM-IoT,  there 
are problems needed solving.
And especially, for networks without IPv6, it is also a problem to make DTLS 
work.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Antti Ratilainen
Sent: Thursday, June 02, 2016 11:41 PM
To: Pascal Thubert (pthubert) ; Alexander Pelov
Cc: [email-masked]
Subject: Re: [lp-wan] NB IOT joining 6LPWA [was: The compression problem: 
protocol dependant?...]

Hi all,

Thanks for your good responses, I’m pleased to see there is interest to 
adopt 3GPP technologies in this work.
As I mentioned, we would like 3GPP lp-wan techs (NB-IoT, EC-GSM-IoT and 
Cat-M1 access)  to be considered. As the IETF work should be transparent for 
the local link, the characteristics (bandwidth, delays etc.) of those three 
could be combined to have just one set of characteristics to be dealt with.
In these techs both options, IP (IPv4 and IPv6) as well as other protocols 
can be used for user data delivery. The other protocols could be any 
protocols which should be seen as transparent for local link, such suitable 
options could also be discussed/developed in IETF. What we would like to see 
is compression profiles for these links with support to both data delivery 
procedures, IP delivery and generic data delivery (referred to as non-IP in 
3GPP).
3GPP links allow user data to be transported both via Control Plane (CP) and 
User Plane (UP), but I don’t think it matters whether CP or UP is used as 
long as the characteristics of the given link is known.
About the compression technique, RoHC would be good starting point, however 
stateless compression would also be interesting to look into. I believe 3GPP 
would like that  IETF could also consider looking into transport protocols 
which would better support these constrained links and traffic 
characteristics.

Regarding the proposed charter, it could reflect traffic characteristics 
which are implying less data and more seldom e.g. small amount of data sent 
once a day or even once a week. Also the 10 year operation time with a 
single coin-cell battery requirement sounds a bit ambitious for the 
considered technologies.

About 3GPP releases, Release-13 is soon to be closed. If this IETF work 
requires changes in 3GPP protocols, it would need to be in Release-14 the 
earliest, the scope of which has not been agreed on at the present time.

BR,
Antti

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 1. kesäkuuta 2016 16:33
To: Alexander Pelov; Antti Ratilainen
Cc: [email-masked]
Subject: NB IOT joining 6LPWA [was: The compression problem: protocol 
dependant?...]

And reciprocally, Antti,

would you says that the proposed charter is a good start from the LTE-NB1 
point of view?

In particular, I have this feeling that the compression story that we are 
putting in place is the perfect evolution from the RoHC technique to fit 
IOT. Do I have that right?

Cheers,

Pascal

> such an integral part should be considered as a candidate for any 

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Jun 2016 11:08:13 -0500

> In these techs both options, IP (IPv4

You won't get this with IETF.

>and IPv6

This is OK.

Regards,

Behcet
> ) as well as other protocols can be used for user data delivery. The other protocols could be any protocols which should be seen as transparent for local link, such suitable options could also be discussed/developed in IETF. What we would like to see is compression profiles for these links with support to both data delivery procedures, IP delivery and generic data delivery (referred to as non-IP in 3GPP).

---

From: Paul Duffy <[email-masked]>
Date: Fri, 3 Jun 2016 12:23:57 -0400

I agree that IPv4 should not be within the scope of the LPWAN work.

---

From: "weigengyu" <[email-masked]>
Date: Mon, 6 Jun 2016 09:49:45 +0800

Hi,

There is an additional explanations of SMS in NB-IoT.
NB-IoT may include NB-LTE, so SMS in LTE will be a service, that is 
defferent from SMS in GSM.
As LTE is all IP networks, SMS is as an application of IMS (IP Multimedia 
Subsystem).
The protocol stack would be SMS over SIP, and  protocols under SIP are TCP, 
or UDP/IP with RoHC.

It may also be in CP of NB-IoT.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Friday, June 03, 2016 5:10 PM
To: Antti Ratilainen ; Pascal Thubert (pthubert) ; Alexander Pelov
Cc: [email-masked]
Subject: Re: [lp-wan] NB IOT joining 6LPWA [was: The compression problem: 
protocol dependant?...]

Hi Antti,

Regards,

Gengyu WEI
-----原始邮件----- 
From: Antti Ratilainen
Sent: Thursday, June 02, 2016 11:41 PM
To: Pascal Thubert (pthubert) ; Alexander Pelov
Cc: [email-masked]
Subject: Re: [lp-wan] NB IOT joining 6LPWA [was: The compression problem:
protocol dependant?...]

Hi all,

BR,
Antti

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 1. kesäkuuta 2016 16:33
To: Alexander Pelov; Antti Ratilainen
Cc: [email-masked]
Subject: NB IOT joining 6LPWA [was: The compression problem: protocol
dependant?...]

And reciprocally, Antti,

Cheers,

Pascal