Subject: [6tsch] focussing on charter: use cases

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Mar 2013 19:08:32 +0000

Dear ML:

The activity that we generate on the mailing list is a good indication we will be very successful as a WG. First thing first, though, we need to create the WG and need to focus a little bit on the necessary steps to get there.

We need to put together a rough charter, and convince an AD, probably Adrian from Routing Area or Ted from Internet Area, that we have real problems to solve and that we, as a group, can provide valuable answers. The ADs agendas are very full all the time, but certainly peaks around the meeting times. So we have about 2 week in front of us to prepare a solid case.

So I suggest we step back a minute from the details of time frames and priorities and spend some energy on the use cases, the problems we are solving, and the work we have to do to get there. I notice a cool discussion on mobility and the particular case of a crane, well that's a use case. We already had centralized deterministic (hard slot) routes for command and control, distributed deterministic (soft slots) and non deterministic QoS based flows. Do we have others cases?
Cheers,

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 20 Mar 2013 22:15:56 -0700

Pascal, all,

Absolutely agreed. I believe we have started exploring quite a bit, enough
to have a clear understanding of what we can achieve with this technology
as a WG. So let's spend some time on use cases and building a good case to
convince an AD.

We could start by listing what TSCH is "good at", and what makes it
different from other solutions. I see the following:
- reliability: 5 9's of end-to-end reliability are commonplace.
- low-power: aggressive radio duty cycling of the mote's radio yields much
longer lifetime in battery-powered devices.
- traffic engineering: the clear identification of resources allows for
flow independence and QoS.

Of course, from those points, industrial applications immediately come to
mind. Yet, we could take use cases from other areas. We could for example
take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of
the points Xavi and Alfredo made).

- industrial automation. A 6TSCH network can allow for high reliability,
and deterministic behavior. Link over-provisioning can efficiently combat
the unreliable nature of wireless and provide a robust communication.
- building automation. A 6TSCH network can serve as an "umbrella" network
for a large number of sensing points in the building. These sensing points
can be owned and operated by different entities (e.g. HVAC and lighting).
The 6TSCH network allows for the different traffic flows to stay
independent from one another.
- because of a 6TSCH node is deeply duty cycle, remote sensing application
(e.g. agricultural applications) can rely on energy harvesting as power
source.
- A smart urban parking application can benefit from the reliabilty of
 6TSCH network since, even though the vehicle detection sensor may be
static, the constant movement of cars around the sensing points can cause
the wireless environment to quickly change.

Thomas

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear ML:****
>
> ** **
>
> The activity that we generate on the mailing list is a good indication we
> will be very successful as a WG. First thing first, though, we need to
> create the WG and need to focus a little bit on the necessary steps to get
> there.****
>
> ** **
>
> We need to put together a rough charter, and convince an AD, probably
> Adrian from Routing Area or Ted from Internet Area, that we have real
> problems to solve and that we, as a group, can provide valuable answers.
> The ADs agendas are very full all the time, but certainly peaks around the
> meeting times. So we have about 2 week in front of us to prepare a solid
> case.****
>
> ** **
>
> So I suggest we step back a minute from the details of time frames and
> priorities and spend some energy on the use cases, the problems we are
> solving, and the work we have to do to get there. I notice a cool
> discussion on mobility and the particular case of a crane, well that’s a
> use case. We already had centralized deterministic (hard slot) routes for
> command and control, distributed deterministic (soft slots) and non
> deterministic QoS based flows. Do we have others cases?****
>
> ****
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 21 Mar 2013 07:52:03 -0700

Pascal and Thomas,

I agree it is very important to specify the use cases which 6tus will
support. Here is some comments and suggestions.

(1) Regarding to industry automation, I think it may be better to describe
Process Automation and Factory Automation separately.

(2) Other potential use cases:
   - Health care
   - Asset tracking and monitoring
   - Location based service

Qin

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 21 Mar 2013 11:28:02 -0400

Le 2013-03-21 à 01:15, Thomas Watteyne <[email-masked]> a écrit :

> Pascal, all,
> 
> Absolutely agreed. I believe we have started exploring quite a bit, enough to have a clear understanding of what we can achieve with this technology as a WG. So let's spend some time on use cases and building a good case to convince an AD.

A proposed charter should have at least the following:
a) problem statement/use cases
b) what needs to be done in IETF
c) some milestones

b) is as important as a) for an AD  (and c) too).

Marc.

> 
> We could start by listing what TSCH is "good at", and what makes it different from other solutions. I see the following:
> - low-power: aggressive radio duty cycling of the mote's radio yields much longer lifetime in battery-powered devices.
> - traffic engineering: the clear identification of resources allows for flow independence and QoS.
> 
> Of course, from those points, industrial applications immediately come to mind. Yet, we could take use cases from other areas. We could for example take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo made).
> 
> - industrial automation. A 6TSCH network can allow for high reliability, and deterministic behavior. Link over-provisioning can efficiently combat the unreliable nature of wireless and provide a robust communication. 
> - building automation. A 6TSCH network can serve as an "umbrella" network for a large number of sensing points in the building. These sensing points can be owned and operated by different entities (e.g. HVAC and lighting). The 6TSCH network allows for the different traffic flows to stay independent from one another.
> - because of a 6TSCH node is deeply duty cycle, remote sensing application (e.g. agricultural applications) can rely on energy harvesting as power source.
> - A smart urban parking application can benefit from the reliabilty of  6TSCH network since, even though the vehicle detection sensor may be static, the constant movement of cars around the sensing points can cause the wireless environment to quickly change.
> 
> Thomas
> 
> On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Dear ML:
> 
>  
> 
> So I suggest we step back a minute from the details of time frames and priorities and spend some energy on the use cases, the problems we are solving, and the work we have to do to get there. I notice a cool discussion on mobility and the particular case of a crane, well that’s a use case. We already had centralized deterministic (hard slot) routes for command and control, distributed deterministic (soft slots) and non deterministic QoS based flows. Do we have others cases?
> 
> 
> Cheers,
> 
>  
> 
> Pascal
> 
>  
> 
>  
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Mar 2013 15:52:50 +0000

I agree Qin.

Factory automation is out of scope. We can refer to Tom's analysis to show that.
And yes, Process control is the source of most of our use case, again per Tom's draft in ROLL.

I think we can find a number of use cases that leverage the capabilities that Thomas pointed out in *-automation (apart from factory: )) , whether it is open or closed loop.
- building automation. We can replace a number of existing proprietary technologies with 6TSCH to control the building energy spending.
- vehicular automation. We can save copper for most of the man to machine interfaces, which translates in both lower price and lower gas consumption.
- commercial automation. As you suggest, we can do asset tracking operations on the move, report temperature of freezers.

For health care, I'd agree but we have to be very cautious in what we claim. There is so much regulation around that we cannot commit that the technology is good enough to replace a wire which is sometimes imposed by law, actually. 

Basically, I'd say that 6TSCH can play many places where people expected zigbee but did not find it reliable enough. 

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 21 mars 2013 15:52
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tsch] focussing on charter: use cases

Pascal and Thomas,

I agree it is very important to specify the use cases which 6tus will support. Here is some comments and suggestions.

(1) Regarding to industry automation, I think it may be better to describe Process Automation and Factory Automation separately.

Qin

> Pascal, all,
>
> Absolutely agreed. I believe we have started exploring quite a bit, 
> enough to have a clear understanding of what we can achieve with this 
> technology as a WG. So let's spend some time on use cases and building 
> a good case to convince an AD.
>
> - low-power: aggressive radio duty cycling of the mote's radio yields 
> much longer lifetime in battery-powered devices.
> Of course, from those points, industrial applications immediately come 
> to mind. Yet, we could take use cases from other areas. We could for 
> example take the ROLL requirement drafts as a skeleton (I'm 
> paraphrasing some of the points Xavi and Alfredo made).
>
> - industrial automation. A 6TSCH network can allow for high 
> reliability, and deterministic behavior. Link over-provisioning can 
> efficiently combat the unreliable nature of wireless and provide a robust communication.
> - building automation. A 6TSCH network can serve as an "umbrella" 
> network for a large number of sensing points in the building. These 
> sensing points can be owned and operated by different entities (e.g. HVAC and lighting).
> - because of a 6TSCH node is deeply duty cycle, remote sensing 
> application (e.g. agricultural applications) can rely on energy 
> harvesting as power source.
> static, the constant movement of cars around the sensing points can 
> cause the wireless environment to quickly change.
>
> Thomas
>
>> The activity that we generate on the mailing list is a good 
>> indication we will be very successful as a WG. First thing first, 
>> though, we need to create the WG and need to focus a little bit on 
>> the necessary steps to get
>> there.****
>>
>> ** **
>>
>> The ADs agendas are very full all the time, but certainly peaks 
>> around the meeting times. So we have about 2 week in front of us to 
>> prepare a solid
>> case.****
>>
>> ** **
>>
>> So I suggest we step back a minute from the details of time frames 
>> and priorities and spend some energy on the use cases, the problems 
>> we are solving, and the work we have to do to get there. I notice a 
>> cool discussion on mobility and the particular case of a crane, well 
>> that’s a use case. We already had centralized deterministic (hard 
>> slot) routes for command and control, distributed deterministic (soft 
>> slots) and non deterministic QoS based flows. Do we have others 
>> cases?****
>>
>> ****
>>
>> Cheers,****
>>
>> ** **
>>
>> Pascal****
>>
>> ** **
>>
>> ** **
>>

---

From: <[email-masked]>
Date: Sat, 23 Mar 2013 15:13:54 +0000

Hello Thomas, all,

Regarding your point
- because of a 6TSCH node is deeply duty cycle, remote sensing application (e.g. agricultural applications) can rely on energy harvesting as power source.
I still need to be convinced that 6tsch allows for a lower power consumption than preamble sampling on very low traffic. Therefore I don't think we should say
"6tsch is lower power therefore makes possible new applications therefore we should standardize 6tsch". This is overly simplistic.
Other arguments that were stated, such as determinism, which is mandated by industry automation, is a much better seller.

To add another one, as I stated in an earlier phone conference, I believe TSCH is of interest to build mutualized sensor networks that can support several end customers or services. This is because one can allocate bandwidth to each supported service independently of the others (under some limits). This can be modeled beforehand, a decision can be made to admit the new customer/service or not, and the network can be managed to allocate temporary extra resources to maintain QoS while a technician is sent to the field to investigate such things as node failure or severe interference. Granted, several node resources such as energy and memory are still shared between customers/services but TSCH allows to model and manage these much better than other wireless link layers.
Such a mutualized managed network is much more likely to be profitable and makes a better use of spectrum than independent, overlaid networks fighting for the same wireless medium.
To a company intending to deploy, operate and manage a sensor network infrastructure, TSCH is good starting point.

Comments?

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : jeudi 21 mars 2013 06:16
À : [email-masked]
Objet : Re: [6tsch] focussing on charter: use cases

Pascal, all,

Thomas

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear ML:

Pascal

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 25 Mar 2013 09:32:36 -0700

Dominique,

Thanks for your comments. We certainly do not want to be overly simplistic.
When identifying use cases, I believe we should focus on what makes TSCH
different, and articulate the use cases around those. As you point out,
traffic differentiation is certainly very high on that list.

An immediate use case is that of an entity operating an "umbrella" network
on which different types of traffic flow, possibly coming from customers of
this entity. When a new customer asks to be granted access to the network,
the network operator can predict with pretty good granularity the the
impact this new traffic on the remaining bandwidth of the network, and on
the power consumption of individual motes, which allows the operator to
grant/deny, and probably charge differently.

Does this use case match what you were thinking?

Thomas

On Sat, Mar 23, 2013 at 8:13 AM, <[email-masked]> wrote:

>  Hello Thomas, all,****
> Regarding your point****
> source.****
> I still need to be convinced that 6tsch allows for a lower power
> consumption than preamble sampling on very low traffic. Therefore I don’t
> think we should say****
>
> “6tsch is lower power therefore makes possible new applications therefore
> we should standardize 6tsch”. This is overly simplistic.****
>
> Other arguments that were stated, such as determinism, which is mandated
> by industry automation, is a much better seller.****
>
> ** **
>
> To add another one, as I stated in an earlier phone conference, I believe
> TSCH is of interest to build mutualized sensor networks that can support
> several end customers or services. This is because one can allocate
> bandwidth to each supported service independently of the others (under some
> limits). This can be modeled beforehand, a decision can be made to admit
> the new customer/service or not, and the network can be managed to allocate
> temporary extra resources to maintain QoS while a technician is sent to the
> field to investigate such things as node failure or severe interference.
> Granted, several node resources such as energy and memory are still shared
> between customers/services but TSCH allows to model and manage these much
> better than other wireless link layers.****
>
> Such a mutualized managed network is much more likely to be profitable and
> makes a better use of spectrum than independent, overlaid networks fighting
> for the same wireless medium.****
>
> To a company intending to deploy, operate and manage a sensor network
> infrastructure, TSCH is good starting point.****
>
> ** **
>
> Comments?****
>
> ** **
>
> Dominique****
>
> ** **
>
> *De :* [email-masked] [mailto:[email-masked]] *De la part
> de* Thomas Watteyne
> *Envoyé :* jeudi 21 mars 2013 06:16
> *À :* [email-masked]
> *Objet :* Re: [6tsch] focussing on charter: use cases****
>
> ** **
>
> Pascal, all,****
>
> ** **
>
> convince an AD.****
> different from other solutions. I see the following:****
>
> - reliability: 5 9's of end-to-end reliability are commonplace.****
>
> longer lifetime in battery-powered devices.****
>
> flow independence and QoS.****
>
> ** **
>
> the points Xavi and Alfredo made). ****
>
> ** **
>
> the unreliable nature of wireless and provide a robust communication. ****
>
> independent from one another.****
>
> source.****
> the wireless environment to quickly change.****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Dear ML:****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 16:36:18 +0000

Hi Thomas,

This is exactly what I had in mind, thanks!

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : lundi 25 mars 2013 17:33
À : [email-masked]
Objet : Re: [6tsch] focussing on charter: use cases

Dominique,

Thanks for your comments. We certainly do not want to be overly simplistic. When identifying use cases, I believe we should focus on what makes TSCH different, and articulate the use cases around those. As you point out, traffic differentiation is certainly very high on that list.

An immediate use case is that of an entity operating an "umbrella" network on which different types of traffic flow, possibly coming from customers of this entity. When a new customer asks to be granted access to the network, the network operator can predict with pretty good granularity the the impact this new traffic on the remaining bandwidth of the network, and on the power consumption of individual motes, which allows the operator to grant/deny, and probably charge differently.

Thomas

On Sat, Mar 23, 2013 at 8:13 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas, all,

Regarding your point

Comments?

Dominique

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Thomas Watteyne
Envoyé : jeudi 21 mars 2013 06:16
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [6tsch] focussing on charter: use cases

Pascal, all,

Thomas

Pascal

Thank you.