Subject: [6tsch] Agenda for the call March 22nd, 2013

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Mar 2013 16:55:47 +0000

Dear all:

The focus for tomorrow will be to agree on use cases and derive a problem statement. Please keep in mind that the call will be recorded and the record published.

We already have a list that we can review:

- Wireless Process Control (main source for us)
   * control loops (requires a global optimization of routes for jitter an latency - thus computed by a PCE  -, flow (over) provisioning, duocast, with static multipath hard slot allocation.
   * control loop plan B (requires self-healing -thus distributed- routing,)
   * supervisory flows (requires determinism up to the backbone
   * management (requires a separate topology - a RPL instance - that does not break)
   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
   * monitoring of lots of lesser importance stuff like corrosion (requires low cost scalability - this distributed routing )
   * cranes that are mobile within a range (requires dynamicity on the last hop(s) whre the mobility happens and may be deterministic up to that point)
   * large plants (requires thousands of devices- thus a backbone - within a subnet - to avoid renumbering)
   * non-production episodes (requires fast and autonomic behavior - again distributed routing)
   * coexistence with legacy devices (requires a common management above)

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic in the road)
    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes

- building automation.

  * requires redundancy as RF degrades when there are changes on the environment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain range.

- 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.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, ...

Please bring your own thoughts so we can converge at the call : )

As an appetizer, we can start with

  *   summary overview Orlando meeting (10 minutes)

     *   agendas two meetings
     *   4 drafts presented
     *   TODO: 6tus, add ability for a PCE to set hard cells on one side only (text already changed)
     *   TODO: typos
     *   TODO: terminology

Then the entrée (40 minutes)

  *   charter use cases:

     *   review the list above
     *   validate the list of derived problems to be solved
     *   focus on what TSCH is good at: reliability, low-power consumption, traffic engineering

for dessert

  *   open technical discussions

     *   synchronization between BBRs

        *   summarize and discuss proposal

     *   slotframes, cells and priorities

        *   summarize and discuss proposal

     *   interaction between RPL and PCE

        *   summarize current state of the discussion

Please let us know if you wish to add / amend stuff in the above : )

Cheers,

Pascal

PS, call info is as always:

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus

-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked]<mailto:[email-masked]>
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0

http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 21 Mar 2013 17:09:15 +0000

Pascal,
thanks for the great list about use cases that you have already prepared.

Here are some extra thoughts, that are in line with what we have already in the list!
Use Cases: Domotic & Home Automation/ Monitoring & Security
- Energy and water use: energy and water supply consumption monitoring to obtain advice on how to save cost and resources.
- Intrusion Detection Systems: Detection of window and door openings and violations to prevent intruders.

Looking forward to tomorrow meeting.

Best Regards,
Maria Rita
________________________________
From: [email-masked] [[email-masked]] on behalf of Pascal Thubert (pthubert) [[email-masked]]
Sent: Thursday, March 21, 2013 5:55 PM
To: Thomas Watteyne; [email-masked]
Subject: [6tsch] Agenda for the call March 22nd, 2013

Dear all:

- Wireless Process Control (main source for us)
   * control loops (requires a global optimization of routes for jitter an latency – thus computed by a PCE  -, flow (over) provisioning, duocast, with static multipath hard slot allocation.
   * control loop plan B (requires self-healing -thus distributed- routing,)
   * supervisory flows (requires determinism up to the backbone
   * management (requires a separate topology – a RPL instance - that does not break)
   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
   * monitoring of lots of lesser importance stuff like corrosion (requires low cost scalability – this distributed routing )
   * cranes that are mobile within a range (requires dynamicity on the last hop(s) whre the mobility happens and may be deterministic up to that point)
   * large plants (requires thousands of devices– thus a backbone – within a subnet – to avoid renumbering)
   * non-production episodes (requires fast and autonomic behavior – again distributed routing)
   * coexistence with legacy devices (requires a common management above)

- building automation.

- vehicular automation.

- commercial automation.

  *  monitoring e.g. temperature of freezers, intrusion sensors, …

     *   agendas two meetings
     *   4 drafts presented

  *   charter use cases:

     *   review the list above

for dessert

Cheers,

Pascal

Topic: 6TSCH Weekly

You can contact me at:

http://www.webex.com

---

From: Bogdan Pavković <[email-masked]>
Date: Fri, 22 Mar 2013 00:17:50 +0100

Dear all,

I would also like to hop on this standardization train (to re-use the 
example with Boris).
Since Thomas introduced me to the activities of 6TSCH, I got exited 
about the possibility to work on this thematic.

I do not have a prior active standardization experience, but I would 
like to learn more.
Nevertheless, I am familiar with RPL and 802.15.4 (e).
In fact, for my thesis I was considering the scientific and practical 
challenges related to cohabitation of 802.15.4 and RPL.

I already had a chance to catch up on the abundant discussion on the 
mailing list,
and I will join you for tomorrow's call (menu).

Best regards,

Bogdan Pavković

https://sites.google.com/site/bogdanpavkovicpersonal/
http://drakkar.imag.fr/bogdan

phone: +381 62 184 2 898
Skype: pavkovic_bogdan

On 3/21/13 5:55 PM, Pascal Thubert (pthubert) wrote:
>
> Dear all:
>
> The focus for tomorrow will be to agree on use cases and derive a 
> problem statement. Please keep in mind that the call will be recorded 
> and the record published.
>
>    * control loops (requires a global optimization of routes for 
> jitter an latency – thus computed by a PCE  -, flow (over) 
> provisioning, duocast, with static multipath hard slot allocation.
>
>    * monitoring of lots of lesser importance stuff like corrosion 
> (requires low cost scalability – this distributed routing )
>
>    * cranes that are mobile within a range (requires dynamicity on the 
> last hop(s) whre the mobility happens and may be deterministic up to 
> that point)
>
>     *smart urban parking (requires redundancy of routes an 
> over-provision as RF degrades with cars on top of the sensors)
>
>   * requires redundancy as RF degrades when there are changes on the 
> environment, doors, moving metallic apparel, etc..)
>
>    * We can save copper for most of the man to machine interfaces, 
> which translates in both lower price and lower gas consumption.
>
> - commercial automation.
>
>       o agendas two meetings
>       o 4 drafts presented
>       o TODO: 6tus, add ability for a PCE to set hard cells on one
>         side only (text already changed)
>       o TODO: typos
>       o TODO: terminology
>
>       o review the list above
>       o validate the list of derived problems to be solved
>       o focus on what TSCH is good at: reliability, low-power
>         consumption, traffic engineering
>
> for dessert
>
>       o synchronization between BBRs
>
>           + summarize and discuss proposal
>
>       o slotframes, cells and priorities
>
>           + summarize and discuss proposal
>
>       o interaction between RPL and PCE
>
>           + summarize current state of the discussion
>
> **
>
> 1. Go to 
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0 
>
> The affected toll free numbers are: (866) 432-9903 for the San 
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>
> [email-masked] <mailto:[email-masked]>
> 33-49-723 2634
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows 
> audio and any documents and other materials exchanged or viewed during 
> the session to be recorded. By joining this session, you automatically 
> consent to such recordings. If you do not consent to the recording, 
> discuss your concerns with the meeting host prior to the start of the 
> recording or do not join the session. Please note that any such 
> recordings may be subject to discovery in the event of litigation.
>
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

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

Hello Pascal, Wavi, Thomas, all,

Sorry I won't be able to attend the call, on the road again.
Some comments, though:
  *(road,street) traffic control (requires increase of bw as more traffic in the road)
Why does traffic control require more bandwidth as traffic increases? Aren't we reporting data such as number of cars as opposed to each passing car one by one?
    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)
How is this a highlight of TSCH?

   * city lights monitoring. Requires marge scale meshes
Again, this doesn't say why TSCH is required or better than anything else, hence is not a selling point.
Xavi, I think you were the one to put these scenarios forward, in another email thead. Can you please comment?
Thanks

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Pascal Thubert (pthubert)
Envoyé : jeudi 21 mars 2013 17:56
À : Thomas Watteyne; [email-masked]
Objet : [6tsch] Agenda for the call March 22nd, 2013

Dear all:

- building automation.

- vehicular automation.

- commercial automation.

     *   agendas two meetings
     *   4 drafts presented

  *   charter use cases:

     *   review the list above

for dessert

Cheers,

Pascal

Topic: 6TSCH Weekly

You can contact me at:

http://www.webex.com

_________________________________________________________________________________________________________________________

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: Xavier Vilajosana <[email-masked]>
Date: Sat, 23 Mar 2013 08:32:08 -0700

see inline

On 23/03/13 08:08, [email-masked] wrote:
> Why does traffic control require more bandwidth as traffic increases? 
> Aren't we reporting data such as number of cars as opposed to each 
> passing car one by one?
>
traffic control not only counts cars, the most advanced systems classify 
cars according to the number of axes and even type of car. Note that 
some operators are paid according to the type of car (truck, 
motorbike,car). This requires in some systems to send more information 
which is send at each reading. There are several companies that do that 
and use TSCH networks.
> How is this a highlight of TSCH?
Well, the first thing is that one of the companies with more smart 
parkings installed uses TSCH networks. 6tsch can over-provision 
bandwidth on different tracks, the tracks are not defined by 6tus but 
6tus deals with provisioning more bandwidth if the QoS is not meet. I 
guess also that 6tus may detect that if over-provisioning on a track up 
to a certain limit (eg required is 6cells, 6tus overprovisions 60cells 
because there is a high packet drop and 6 is not met although 60cells 
are given), the RPL should be told about that no?
>    * city lights monitoring. Requires marge scale meshes

I haven't proposed them but I can figure out that this scenarios might 
benefit from TSCH if the density of the deployments is high enough and 
the sampling rate requirement is significant.
> Xavi, I think you were the one to put these scenarios forward, in 
> another email thead. Can you please comment?
>
> Thanks
>
> Dominique
>
> *De :[email-masked] [mailto:[email-masked]] *De la 
> part de* Pascal Thubert (pthubert)
> *Envoyé :* jeudi 21 mars 2013 17:56
> *À :* Thomas Watteyne; [email-masked]
> *Objet :* [6tsch] Agenda for the call March 22nd, 2013
>
> Dear all:
>
> jitter an latency -- thus computed by a PCE  -, flow (over) 
>    * management (requires a separate topology -- a RPL instance - that 
> does not break)
>
> (requires low cost scalability -- this distributed routing )
>
>    * large plants (requires thousands of devices-- thus a backbone -- 
> within a subnet -- to avoid renumbering)
>
>    * non-production episodes (requires fast and autonomic behavior -- 
> again distributed routing)
>