1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 130322_webex

View History

Minutes Webex 22 March 2013, 6TSCH group

Note: timestamps in PDT.

Present (alphabetically)

  1. Bogdan Pavkovic
  2. Maria Rita Palattella
  3. Pascal Thubert
  4. Qin Wang
  5. Raghuram Sudhaakar
  6. Thomas Watteyne
  7. Tina Tsou
  8. Tom Phinney
  9. Xavi Vilajosana

Recording

Slides

  • 6tsch_use_cases_call03222013.pptx: slides shared during the call and edited live by Pascal

Agenda

  • Summary overview Orlando meeting [10min]
    • overview two meetings
    • 4 drafts presented
    • TODOs:
      • 6tus draft, add ability for a PCE to set hard cells on one side only (text already changed)
      • typos
      • match terminology draft
  • Charter use cases [40min]
    • review the following list
      • Wireless Process Control (main source for us)
        • control loops (requires a global optimization of routes for jitter and 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,
    • validate the list of derived problems to be solved
    • focus on what TSCH is good at: reliability, low-power consumption, traffic engineering
  • Open technical discussions [time permitting]
    • 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

Minutes

  • [08.05] Meeting starts
  • [08.05] Overview IETF 86 Orlando
    • 2 6TSCH information meetings
      • Tuesday: administrative and general information.
        • Adoption of draft-ietf-roll-rpl-industrial-applicability-00 as starting point for 6TSCH requirements
        • Many non-6TSCH people discovered the group.
        • Positive feedback.
      • Wednesday: technical discussion,
        • 4 6TSCH drafts presented
        • 2 non-6TSCH drafts presented
    • all information, including full minutes and slides are at https://bitbucket.org/6tisch/ietf86-orlando/
  • [08.15] Discussion on charter use cases
    • Pascal shares slides from 6tsch_use_cases_call03222013.pptx
    • Goal: discuss the different use cases scenarios

      Below is only a list of the points discussed. Refer to the attached slides for contents.

    • Duocast
      • [Tom] duocast applies only to single hop.
      • [Pascal] Edits slide.
    • Supervisory flows
      • [Pascal] Do we want the flow to be deterministic to a supervisor which sits in the backbone? This implies matching the LLN schedule to some backbone link-layer schedule?
      • [Tom] BB has orders of magnitude more bandwidth than LLN. Will never be constrained. We don't need to have determinism in the BB.
      • [Thomas] We could consider this isssue out-of-scope for 6TSCH.
      • [Pascal] Edits slide.
    • Management topology
      • [Pascal] do we want to separate the management traffic from data traffic to ensure availability?
      • [All] Agreed/
      • [Pascal] Adds open issues: OF and root selection to slide.
    • Alerts
      • [Pascal] Proposal: allow for burst of traffic to generate some on-demand ("on-the-fly") distributed reservation?
      • [Thomas] Potentially complicates things. Why not consider a burty traffic as a problem for the scheduling entity to taken care of.
      • [Pascal] Edits slide.
    • Support for lesser important "background" traffic.
      • [Pascal] Allow for traffic to flow along RPL routes, using soft cell allocation, possibly alongside PCE-allocated hard cells.
      • [Thomas] Agreed since probably relatively easy to do (hard cell have priority over soft cells, if hard cell is installed at same timeslot/channeloffset as soft cell, soft cell needs to move). Yet, this might bring complexity, so let's separate PCE/distributed approaches.
    • Mobility
      • [Pascal] Presents idea from Alfredo, whereby data from a mobile crane would travel over a RPL "half-track" before reaching PCE "half-track".
      • [Thomas] Not is favor of mixing distributed and centralized routing in a track.
      • [Thomas,Tom] What we understood from Alfredo's proposal was to have same cells scheduled at several potential neighbors of the node mounted on the crane.
      • [Tom] Agreed.
      • [Pascal] Agreed.
      • [Pascal] Marks issue as "no goal".
      • [Tom] Mobility case makes sense, e.g. for large container cranes traveling along a track. Two cranes can pick up each side of a large object. One can imagine automated communication (now human operators with radio).
      • [Tom] Second example is pivoting crane.
      • [Pascal] Splits mobile case if "crane" and "mobile" worker.
      • [Tom] Mobile worker does not require deterministic schedules.
    • Large plants
      • [Pascal] Concept of multiple BBRs interconnected by BB to allow nodes from different LLNs to be in same IPv6 prefix. Useful?
      • [Raghuram] In some cases, we want to know exactly where a node is, having the same prefix might remove that information.
      • [Thomas] System can be built so that a network operator can know to which BBR a node is attached, yet all nodes still in same prefix.
      • [Pascal] Edits slide to indicate same prefix not always needed, isolation somtimes wanted.
      • [Thomas] Wants to stress that we also want to support a case where one big LLN with multiple BBRs.
      • [Pascal] Agreed, text encompasses this case.
    • Non-production phases
      • [Pascal] RPL can be needed as backup or for recovery.
      • [Thomas] Very well explained in draft-ietf-roll-rpl-industrial-applicability-00. Agreed.
    • Coexistence
      • [Pascal] Do we need a common management entity which could know about the different schedules of different LLNs (possible covering IEEE802.15.4e TSCH, WHART and ISA1000) to facilitate coexistence?
      • [Thomas] Such fine-grained (at cell level) coexistance management not needed. Several network in same radio space work fine. Coarse-grained can be easily implemented. E.g. blacklisting some frequency on which a single-channel network runs, and which does not support a different network.

        Time's up, we don't go through additional slides.

  • [09.00] What's next?
    • for the coming week:
      • finalize the list of use cases, with slideset as a base, on the ML
      • start working on extra items (per Marc Blanchet's suggestion):
        • what needs to be done in IETF
        • milestones and deliverables.
    • at next meeting: finalize discussion on use cases, and move on to two points above.
  • [09.05] Meeting ends

Updated