Clone wiki

meetings / 130830_webex

Minutes Webex 30 August 2013, 6TiSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Dominique Barthel
  3. Thomas Watteyne

Present (alphabetically)

  1. Alfredo Grieco
  2. Diego Dujovne
  3. Dominique Barthel
  4. Geraldine Texier
  5. Laurent Toutain
  6. Maria Rita Palattella
  7. Oliver Hahm
  8. Pascal Thubert
  9. Patrick Wetterwald
  10. Pieter de Mil
  11. Pouria Zand
  12. Qin Wang
  13. Raghuram Sudhaakar
  14. Tina Tsou
  15. Thomas Watteyne
  16. Xavi Vilajosana
  17. Xavier Lagrange

Recording

Slides

Agenda

  • Administrivia [4min]
    • Agenda bashing
    • Approval minutes
    • Charter submitted
    • IETF MLs down 3pm-12am 08/28
    • Vancouver: Hyatt hotel registration link
    • Logo update
  • Flow Identification [20min]
    • 4 flows?
    • how to trigger a schedule update?
    • confirmation message?
  • Network bootstrapping [20min]
    • Synchronization and neighbor discovery [Pouria]
    • Time parent selection and EB priority [Xavi]
    • Impact of routing loops on synchronization? [Pascal]
  • Fast Join/Synchronization [Alfredo, 10min]
  • AOB [1min]

Minutes

  • [08.04] Meeting starts
  • [08.04] Administrivia
    • Agenda bashing

      No issues raised. Agenda approved.

    • Approval minutes last call.

      No issues raised. Minutes approved.

    • Charter submitted
      • Adopted name 6TiSCH.
      • Charter submitted. No answer yet.
    • Loss of e-mail in all IETF mailing list on Wed 08/28 3pm-12am midnight PDT.

      Action item: [all] verify outbox and resend any email not in the ML archives (http://www.ietf.org/mail-archive/web/6tsch/current/maillist.html)

    • Vancouver:
    • Logo update

      Action item: [Xavi] to redo logo.

  • [08.10] Flow Identification
    • 4 flows?
      • Flow between and ME and nodes and vice-versa
      • ME is the service that manages the schedule.
      • 4 flows:
        • Action
        • Query
          • Not clear what we want to ask for an specific cell.
          • READ.cell: what are the attributes to query? Information about the usage of the cell?
          • Information should be configurable.
        • Report
        • Event
      • [Thomas] Simplification: Report and Query have common elements. For common elements, instead of a query, we could add an action which triggers a report.
      • [Xavi] Do we need to define everything or define basic elements of Query Flow and provide TLV for more specific elements
      • [Pascal] +1. Very common the standards
      • [Thomas] +1. Anybody disagrees?

        No issue raised on the call.

    • how to trigger a schedule update?
      • Event Flow: what do we consider as an event. How to trigger a schedule update?
      • Part of event flow.
      • 5th request flow: enable a transport mechanism to transport the request to the ME.

        Action item: [Pascal] To start a thread on the ML to answer whether we want a 5th flow or not.

    • confirmation message?
      • When a node sends a Requests to the ME, how does it know that it arrived?
      • Options:
        • Do nothing (best effort)
        • Rely on Transport e.g CoAp and Confirmable msg
        • App-Level ACk
        • Use another flow (e.g action flow)
      • [Maria Rita] Let's be cautious not to make things too complicated.

        Action item: [Qin] to continue discussion on the ML.

  • [08.35] Network bootstrapping
    • Synchronization and neighbor discovery
      • Pouria presents his slide with sequence of echanges between layers and nodes.

        Note: slides taken from http://www.ietf.org/mail-archive/web/6tsch/current/msg01156.html.

      • Temporary time parent selected among neighbors heard. Then, when RPL selects the best parent, may change time source to be the RPL parent.
      • [Pascal]
        • is it possible that we have multiple instances of RPL and the management of multiple different RPL instances and time sources might be complicated as some of the time sources might not be in all RPL instances.
        • A node might belong to multiple instances of RPL, you can listen to other parents in different RPL instances.
        • How to signal or enforce that a RPL instance is for synchronization because there is a node with GPS?
        • With multiple instances only one is used for synchronization.
      • [Thomas] What characteristics do we want the the synchronization RPL instance to have?
      • [Pascal] 3rd RPL model: multiple roots, on DODAG. If you want to send data to the roots, you need them to be grounded.
      • [Raghuram] Why couple RPL routing parents with TSCH time source neighbor? Might be a layer violation.
      • [Pascal] only using info opaque information from the other layer
      • [Pascal] We benefit from the loop-free nature of the RPL DAG.
      • [Alfredo] If we have a many neighbor nodes that send the EBs for synchronization, this goes in many different channels, to deal with that we can have some coordination to select the right parent to join. Would that not be on the direction of having a RPL instance for Synchronization?

        Action item: [Thomas]: to start a thread on the ML about that topic.

  • [08.58] Fast Join/Synchronization
    • Ideas about fast join synch on TSCH
    • When a node joins a network, it needs to wait for the EB. During this time, the radio is on and spends energy. Also this can take some time as the CH sequence is not known in advance.
    • After node joins, synchronization is kept with KA, EBs...
    • Average Join Time: depends on many parameters (number of channels, Ch. Avg time between EBs amongst neighbors, etc)
    • Assumptions:
      • one synchronizer node exists.
      • this node is powered with the mains. (no battery powered). Realistic assumption.
      • A node that is synchronized sends EB every M slotframes.
      • See plots in the slides.
      • Issues:
        • How many EBs should the synchronized node send?
        • How to choose the slotframe cell?
        • Detect end of bootstrap phase.
    • [Thomas] this might be useful both for synchronization and for the continuous neighbor discover once all nodes have joined.
    • [Alfredo] Agreed.
  • [09.06] AOB

    No other business is brought up.

  • [09.07] Meeting ends

Updated