Subject: Re: [6tsch] Problem Statement

From: Thomas Watteyne <[email-masked]>
Date: Tue, 2 Apr 2013 21:43:38 -0700

Pascal,
Please see inline.
Thomas

On Fri, Mar 29, 2013 at 10:00 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hi :****
>
> ** **
>
> Please find a list I xrefed from the use cases we discussed at the call
> and over the ML; , what did I miss?****
>
> Please fire at will…****
>
> ** **
>
> P1: Optimized Multipath hard tracks****
>
> **•       **From****
>
> **–      **wireless process control; low rate control loops****
>
> **–      **Smart cities; WSN service provider****
>
> **–      **Vehicular; control IHM ****
>
> **•       **Optimized => PCE****
>
> **•       **Allocation may be handled by a tier****
>
> **•       **6TUS must apply the required slots and move existing if needed
>

*[TW]* and move existing *soft cells*. We don't expect colliding
reservations from the PCE, right?

> ****
>
> ** **
>
> P2: Distributed Routing, soft tracks****
>
> < unsure which use cases?>****
>
> **•       **=> RSVP or similar
>

*[TW]* Possible use cases:
- dynamic topologies (e.g. smart parking)
- large network with no single control entity (smart buildings, lighting
applications)

> ****
>
> ** **
>
> P3 : Distributed Routing (best effort)****
>
> **•       ** From****
>
> **–      **Industrial; non production phases****
>
> **–      **Industrial, Smart cities, home; monitoring****
>
> **–      **Commercial; asset tracking****
>
> **–      **Home, Commercial; security****
>
> **•       **Distributed => RPL
>

*[TW]* Pascal, can you detail the difference between P2 and P3?

> ****
>
> ** **
>
> P4: Mobility (best effort)****
>
> **•       **From****
>
> **–      **Industrial; mobile worker****
>
> **–      **Commercial; asset tracking****
>
> **•       **Distributed => RPL****
>
> ** **
>
> P5: Dynamic slot allocation****
>
> **•       **From****
>
> **–      **Industrial; alerts****
>
> **–      **Smart cities; Road/Street control****
>
> **–      **Smart cities; Smart Urban Parking ****
>
> **•       **6TUS must adapt to bursts****
>
> **•       **Need to be faster than transport reaction
>

*[TW]* also discussed over the phone: synchronous detection of same event
by a large group of nodes.

> ****
>
> ** **
>
> P6: Backbone****
>
> **•       **From****
>
> **–      **Industrial; large plant****
>
> **•       **Renumbering is not an option****
>
> **•       **One IPv6 subnet incorp. WSNs and backbone****
>
> **•       **Need to mark the packet for Diffserv****
>
> ** **
>
> P7: Large/Deep Mesh****
>
> **•       **From****
>
> **–      **Smart cities; city lights monitoring****
>
> **–      **Building automation;****
>
> **•       **RPL / distributed****
>
> **•       **Need different PHYs to get range
>

*[TW]* Can you detail the different PHYs?

> ****
>
> ** **
>
> P8: Coexistence with legacy****
>
> **•       **From****
>
> **–      **industrial (ISA100.11a, wiHART…)****
>
> **•       **Maybe achieved well enough by TSCH MAC already****
>
> **•       **May be achieved by channel white/black list****
>
> **•       **No goal: sync various networks and W/B list at the
> granularity of the slot****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

 <https://www.ietf.org/mailman/listinfo/6tsch>

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 2 Apr 2013 22:36:59 -0700

Pascal,

I'd like to add the issue raised by Dominique a couple of days ago:
manageability of an "umbrella" network carrying flows from different
independent entities.

A use case could go as follows. The city of Smallworld has decided to
invest in "smart city" technology, and wants to install a pilot low-power
wireless network to cover a couple of blocks in the city center. The city
sees this as good PR, but does not really know what exact traffic this
network will need to carry. The city really wants the network to be up and
running as soon as possible, and decides to contact SmartCo.

Within a couple of weeks, SmartCo goes out and installs a few hundred relay
nodes on lighting poles and in trees throughout the city center. It
partners with a local air quality company, and installs 5 air quality
sensors, which feed a "live" display in the central square. Each air
quality sensor produces only one data packet per 10min, and so the network
sits idle most of the time.

SmartCo's business model is to run the network, and make revenue by
carrying other people's data. So it sends free development kits to
different companies and universities in the area. Soon, the local garbage
company builds a contraption to monitor the fill level of the garbage cans
in real time, and monitor the state of their new "solar compactor" bins.
Then, the lighting people want to install a node per lighting pole to
receive an alert when a street light fails. Then, the city wants to use the
network to switch the municipal sprinkler system on and off dependent on
the weather. Soon, a dozen flows transition over the initial network of
relays.

Luckily, SmartCo has been smart to install a 6tsch network in the first
place. This gives it a lot of advantages:
- through traffic differentiation, it can guarantee that the lighting data
never overwhelms the network and impacts sprinkler data.
- because of the slotted nature of communication, is knows exactly how
"busy" each node is, and can predict battery lifetime and schedule possible
replacements well ahead of time.
- because of the backbone topology adopted, the garbage company does not
need to change their addressing scheme when a can it moved by a couple of
blocks.
- SmartCo introduces a novel way of billing by showing the customer exactly
how many "mote-months" of battery carrying their data has cost the network,
and bills accordingly. It puts a "bill simulator" online, to let the
customer decide on the trade-off between latency and throughput that works
best for him.
- Before accepting a new customer, SmartCo is able to precisely predict the
impact on its network. Similarly, when a customer leaves (or pauses data
generation), the network adapts and makes this energy available to other
customers.

Thomas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Apr 2013 09:35:20 +0000

Hello Thomas:

Please see inline
P1: Optimized Multipath hard tracks
*       From
-      wireless process control; low rate control loops
-      Smart cities; WSN service provider
-      Vehicular; control IHM
*       Optimized => PCE
*       Allocation may be handled by a tier
*       6TUS must apply the required slots and move existing if needed

[TW] and move existing soft cells. We don't expect colliding reservations from the PCE, right?

[Pascal] agreed

P2: Distributed Routing, soft tracks
< unsure which use cases?>
*       => RSVP or similar

[TW] Possible use cases:
- dynamic topologies (e.g. smart parking)
- large network with no single control entity (smart buildings, lighting applications)

[Pascal] I'm a bit concerned on whether we really need a reservation or can simply do QoS / best effort there.
A reservation is good when you have a repeatable pattern like a phone call or a control loop, that you want to prioritize.
Do you think the use cases above qualify? Do we have other use cases that would look more like that?
Going through this cross ref, it appeared to me that the need for deterministic behavior was tightly associated with the need for optimization and central computation.
If that is mostly so, then the RSVP work can be lower priority for the group.

P3 : Distributed Routing (best effort)
*        From
-      Industrial; non production phases
-      Industrial, Smart cities, home; monitoring
-      Commercial; asset tracking
-      Home, Commercial; security
*       Distributed => RPL

[TW] Pascal, can you detail the difference between P2 and P3?

[Pascal] P2 needs an additional reservation, ala RSVP, some Call Admission Control and Ingress shaping. This is treating a sensor stream as a voice call over IP.
P3 is more classical data. It needs some aggregate bandwidth between nodes and some slot management to accommodate bursts, like a CIR in Frame Relay.
With P3, the access to the transmit queue is ruled by traditional QoS and RED.

P4: Mobility (best effort)
*       From
-      Industrial; mobile worker
-      Commercial; asset tracking
*       Distributed => RPL

P5: Dynamic slot allocation
*       From
-      Industrial; alerts
-      Smart cities; Road/Street control
-      Smart cities; Smart Urban Parking
*       6TUS must adapt to bursts
*       Need to be faster than transport reaction

[TW] also discussed over the phone: synchronous detection of same event by a large group of nodes.

[Pascal] Yes, that was in a very condensed fashion the aim of item 1, alerts.

P6: Backbone
*       From
-      Industrial; large plant
*       Renumbering is not an option
*       One IPv6 subnet incorp. WSNs and backbone
*       Need to mark the packet for Diffserv

P7: Large/Deep Mesh
*       From
-      Smart cities; city lights monitoring
-      Building automation;
*       RPL / distributed
*       Need different PHYs to get range

[TW] Can you detail the different PHYs?

[Pascal] That was an item at the call, I think that bands in the 8-900 MHz where discussed for farther reachability. The question I have with that is whether we expect to maintain some degree of determinism across different PHYs.
This looks like a complex thing to do and a stretch goal at best. Certainly there will be a loss in what can be expected, and usually the least capable will be the main contributor (eg 802.15.4 with an Ethernet backbone).

P8: Coexistence with legacy
*       From
-      industrial (ISA100.11a, wiHART...)
*       Maybe achieved well enough by TSCH MAC already
*       May be achieved by channel white/black list
*       No goal: sync various networks and W/B list at the granularity of the slot

Cheers,

Pascal

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 3 Apr 2013 22:53:57 -0700

Pascal,

Thanks for clearing things up, this makes perfect sense now.

I believe there is a lot of interest and usefulness for P2-type scheduling.
We have been focusing a lot of P1, especially with the previous work on
draft-phinney, but let's not classify P2 as "low priority". I believe P2
makes a lot of sense when in networks with low data rates (i.e. a sparse
schedule) in which case a distributed scheduling will yield lower overall
power consumption. I hope this makes sense.

I believe this list makes a lot of sense, and that we have the right people
and tools to address P1, P2 and P3 types of scheduling. We should be able
to close this list on the call on Friday.

Thomas

On Wed, Apr 3, 2013 at 2:35 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Thomas:****
> Please see inline****
> •       From****
> –      wireless process control; low rate control loops****
>
> –      Smart cities; WSN service provider****
>
> –      Vehicular; control IHM ****
>
> •       Optimized => PCE****
>
> •       Allocation may be handled by a tier****
>
> •       6TUS must apply the required slots and move existing if needed****
>
> ** **
>
> reservations from the PCE, right?****
>
> ** **
>
> *[Pascal] *agreed* *****
>
>  ****
>
>   ****
>
> •       => RSVP or similar****
> *[TW]* Possible use cases:****
>
> - dynamic topologies (e.g. smart parking)****
>
> applications)****
> *[Pascal]* I’m a bit concerned on whether we really need a reservation or
> can simply do QoS / best effort there.****
>
> A reservation is good when you have a repeatable pattern like a phone call
> or a control loop, that you want to prioritize.****
>
> Do you think the use cases above qualify? Do we have other use cases that
> would look more like that? ****
>
> Going through this cross ref, it appeared to me that the need for
> deterministic behavior was tightly associated with the need for
> optimization and central computation.****
>
> If that is mostly so, then the RSVP work can be lower priority for the
> group.****
>
>   ****
>
> •        From****
> –      Industrial; non production phases****
>
> –      Industrial, Smart cities, home; monitoring****
>
> –      Commercial; asset tracking****
>
> –      Home, Commercial; security****
>
> •       Distributed => RPL****
>
>  ** **
>
> *[TW]* Pascal, can you detail the difference between P2 and P3?****
>
>  ****
>
> *[Pascal] *P2 needs an additional reservation, ala RSVP, some Call
> Admission Control and Ingress shaping. This is treating a sensor stream as
> a voice call over IP. ****
>
> P3 is more classical data. It needs some aggregate bandwidth between nodes
> and some slot management to accommodate bursts, like a CIR in Frame Relay.
> ****
>
> With P3, the access to the transmit queue is ruled by traditional QoS and
> RED.  ****
>
>   ****
>
> •       From****
> –      Industrial; mobile worker****
>
> –      Commercial; asset tracking****
>
> •       Distributed => RPL****
>
>  ****
>
> •       From****
> –      Industrial; alerts****
> –      Smart cities; Road/Street control****
>
> –      Smart cities; Smart Urban Parking ****
>
> •       6TUS must adapt to bursts****
>
> •       Need to be faster than transport reaction****
>
>  ** **
>
> by a large group of nodes.****
>
>  ****
>
> *[Pascal] *Yes, that was in a very condensed fashion the aim of item 1,
> alerts.****
>
>   ****
>
> P6: Backbone****
>
> •       From****
>
> –      Industrial; large plant****
>
> •       Renumbering is not an option****
>
> •       One IPv6 subnet incorp. WSNs and backbone****
>
> •       Need to mark the packet for Diffserv****
>
>  ****
>
> P7: Large/Deep Mesh****
>
> •       From****
>
> –      Smart cities; city lights monitoring****
>
> –      Building automation;****
>
> •       RPL / distributed****
>
> •       Need different PHYs to get range****
>
>  ** **
>
> *[TW]* Can you detail the different PHYs?****
>
>  ****
>
> *[Pascal]* That was an item at the call, I think that bands in the 8-900
> MHz where discussed for farther reachability. The question I have with that
> is whether we expect to maintain some degree of determinism across
> different PHYs. ****
>
> This looks like a complex thing to do and a stretch goal at best.
> Certainly there will be a loss in what can be expected, and usually the
> least capable will be the main contributor (eg 802.15.4 with an Ethernet
> backbone).* *****
>
>   ****
>
> •       From****
> –      industrial (ISA100.11a, wiHART…)****
>
> •       Maybe achieved well enough by TSCH MAC already****
>
> •       May be achieved by channel white/black list****
>
> •       No goal: sync various networks and W/B list at the granularity of
> the slot****
>
>  ****
>
> Cheers,****
>
>  ****
>
> Pascal****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 4 Apr 2013 19:36:10 +0000

Pascal,

It seems to me that the use cases identified were based on different sets of criteria.

Some seem to be differentiated based on the entity that is responsible for slot allocation (PCE, distributed etc).
Some other seem to be based on scalability -> for example P7 large, deep mesh.

What was the underlying criteria for the definition of these use cases?
Thks

Robert Assimiti
Nivis
Chief Technology Officer
Office [678]-202-6859
Mobile [404]-578-0205

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, April 04, 2013 1:54 AM
To: IETF 6TSCH
Subject: Re: [6tsch] Problem Statement

Pascal,

I believe there is a lot of interest and usefulness for P2-type scheduling. We have been focusing a lot of P1, especially with the previous work on draft-phinney, but let's not classify P2 as "low priority". I believe P2 makes a lot of sense when in networks with low data rates (i.e. a sparse schedule) in which case a distributed scheduling will yield lower overall power consumption. I hope this makes sense.

I believe this list makes a lot of sense, and that we have the right people and tools to address P1, P2 and P3 types of scheduling. We should be able to close this list on the call on Friday.

Thomas

On Wed, Apr 3, 2013 at 2:35 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas:

Please see inline

[Pascal] agreed

[TW] Possible use cases:

P6: Backbone
*       From

P7: Large/Deep Mesh
*       From

Cheers,

Pascal

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 4 Apr 2013 15:43:56 -0700

Pascal,

I have same feeling as Robert.

I think there are three views involved:
(1) Application view, including industrial process automation, smart city,
parking management,....
(2) Network feature view, including network scale, deterministic
sensitivity, response to mobility, periodical/bursty....
(3) technology view, including centralized/decentralized scheduling and
reservation, PCE, RSVP, traffic engineering,soft/hard cell....

Indeed, the three views are connected with each other closely. But I think
we can put them more systematically.

How do you think?

Qin

> I believe there is a lot of interest and usefulness for P2-type
> scheduling. We have been focusing a lot of P1, especially with the
> previous work on draft-phinney, but let's not classify P2 as "low
> priority". I believe P2 makes a lot of sense when in networks with low
> data rates (i.e. a sparse schedule) in which case a distributed scheduling
> will yield lower overall power consumption. I hope this makes sense.
>
> I believe this list makes a lot of sense, and that we have the right
> people and tools to address P1, P2 and P3 types of scheduling. We should
> be able to close this list on the call on Friday.
>
> Thomas
>
> On Wed, Apr 3, 2013 at 2:35 AM, Pascal Thubert (pthubert)
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hello Thomas:
>
> Please see inline
> or a control loop, that you want to prioritize.
> would look more like that?
> optimization and central computation.
> group.
> [Pascal] P2 needs an additional reservation, ala RSVP, some Call Admission
> Control and Ingress shaping. This is treating a sensor stream as a voice
> call over IP.
> RED.
> [Pascal] That was an item at the call, I think that bands in the 8-900 MHz
> where discussed for farther reachability. The question I have with that is
> whether we expect to maintain some degree of determinism across different
> PHYs.
> backbone).