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

Wiki

Clone wiki

meetings / 130906_webex

View History

Minutes Webex 6 September 2013, 6TiSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

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

Present (alphabetically)

  1. Cedric Adjh
  2. Diego Dujovne
  3. Dominique Barthel
  4. Geraldine Texier
  5. Maria Rita Palattella
  6. Pascal Thubert
  7. Patrick Wetterwald
  8. Pouria Zand
  9. Qin Wang
  10. Raghuram Sudhaakar
  11. Thomas Watteyne
  12. Tom Phinney
  13. Xavi Vilajosana

Recording

Slides

Action items

  • Pascal to add description of flows to architecture draft.
  • Raghuram and Xavi to prepare overview slides of the CoAP. To be presented at call in 1-2 weeks.
  • Pascal to add Track and Cells to the list of items for a node to report to the PCE using report flow, on the ML.
  • Pouria to identify the equivalent information sent by a WirelessHART and ISA100.11a node to the manager.
  • Thomas to contact IEEE802.15.4e authors about EB priority and whether the step for EB priority MUST be +1 or can be something else, e.g +Step_Of_Rank from RPL.
  • All to ask about RPL OF0 presentation by Pascal on ML.

Agenda

  • Approval minutes & agenda bashing [3min]
    • charter update
  • Flow identification [40min]
    • 5 flows? Identify the tiers (ME in device, PCE, NME)
    • CoAP mechanisms we could reuse
    • Discussion commands and information exchanged in flows (report)
  • Using RPL in minimal 6TiSCH case [15min]
    • Rank, Join Priority and flow label
    • RPL and OF0
    • Impact of routing loops on synchronization
  • AOB [2min]

Minutes

  • [08.05] Meeting starts

    Recording starts

  • [08.06] Approval minutes & agenda bashing [3min]
    • approval minutes last minutes

      No concerns raised. Minutes approved.

    • approval agenda

      No concerns raised. Agenda approved.

    • charter update
      • Submitted to IESG Thursday on 9/5/13
      • Talk by Thomas about 6TiSCH activity at senZations'13
  • [08.10] Flow identification [40min]
    • 5 flows? Identify the tiers (ME in device, PCE, NME)
      • Request Flow: Internet to PCE or Mesh to PCE
      • Action Flow: PCE --> Mesh
      • Report Flow: Mesh--> PCE
      • Event Flow: Node notifies to the PCE
      • Query Flow: PCE asks a node
      • Acknowledgements of flows:
      • Leave the ACKs to the transport mechanism. For example, CoAP provides the optional mechanism of confirmable messages.
      • [Qin] ACK from transport layer is part of the confirmation. Not all of the confirmation. We use ACK from transport layer if it can be used. If we need additional confirmation, this can be added from the applications layer.
      • [Thomas] 2 aspects:
        • ACK is to confirm that the message has been received.
        • Application-level response us used to provide a response payload, e.g track confirmation, etc.
      • ACKs are optional on the transport layer.
      • Next steps: add to architecture draft?
        • High level overview of the flows go to the architecture.
        • [Maria Rita] Full details about the bits-and-bytes should go to the flows description draft.
        • [Qin] Question about the picture: it is more focused to the centralized case. In a distributed case the flows do not work.
        • [Pascal] The current charter does not address 6top to 6top.
        • [Xavi] We can map decentralized flows to centralized in very brief discussion on the ML to see if there is some immediate mapping.
      • Volunteer to add description of flows to architecture draft?

        Action item: Pascal to add description of flows to architecture draft.

    • CoAP mechanisms we could reuse
      • CoAP provides mechanisms we could take advantage of.
        • Resources
        • methods (GET/PUT/PUSH)
        • confirmable messages
      • Volunteers to prepare an overview of the CoAP in 1-2 weeks?

        Action item: Raghuram and Xavi to prepare overview slides of the CoAP. To be presented at call in 1-2 weeks.

    • Discussion commands and information exchanged in flows (report)
      • Sent by the node to the PCE.
      • Gives information about how the node is doing.
      • Go through the proposed fields on the ML after some discussion:
        • For each neighbor: ID, RSSI, LQI, Counters, Bundle information, statistics about the link.
        • Queue information
        • Time source parents.
        • Not clear yet as to how to get at all these metrics.
      • How the PCE can configure the mote to relay only some of this information, what the PCE wants to know and when. Ongoing discussion on the ML.
      • [Pascal] Bundle allocation is not redundant as when we use RPL-based allocation the bundle is built dynamically.
      • [Pascal] Tracks and cell information. Ask for devices to report about a particular track.
      • [Pascal] Monitor cells that are not being used to know if they are good.

        Action item: Pascal to add Track and Cells to the list of items for a node to report to the PCE using report flow, on the ML.

      • [Diego] It would be interesting to get the average RSSI/LQI per channel instead of the average amongst all. Requires node to keep per-channel measurements of RSSI/LQI.
      • [Thomas] Important to think about the mechanism to allow a subset of this information to be configured.
      • Volunteers to identify the equivalent information sent by a WirelessHART and ISA100.11a node to the manager?

        Action item: Pouria to identify the equivalent information sent by a WirelessHART and ISA100.11a node to the manager.

      • "Timeslot Management Methods and Formats" draft: Let's wait 1-2 weeks before starting a skeleton.
  • [08.51] Using RPL in minimal 6TiSCH case [15min]
    • Rank, Join Priority and flow label
      • Network bootstrap and synchronization.
      • A joining node listens for EBs. Keeps listening until it hears multiple. Based on EBs, picks best temporary parent neighbor.
      • Keeps synchronized to this temporary parent until it gets RPL DIOs. Once it acquires a RPL rank, starts sending EBs. RPL rank used as EB join priority.
      • The node keeps silent until it has a rank and selected preferrred parent.
      • [Qin] RPL rank as join priority, is a field of 15.4e, every 15.4e implementation will implement that part, 6top will override this field. Breaks 15.4e?

        Action item: Thomas to contact IEEE802.15.4e authors about EB priority and whether the step for EB priority MUST be +1 or can be something else, e.g +Step_Of_Rank from RPL. Note: by lack of time, we will skip last slides.

    • RPL and OF0 [Pascal]
      • Zero OF, uses basic information from RPL
      • Increments the rank at each hop independently of a very detailed metric.
      • Linear categories of rank between 1 or 9.
      • How do we compute the step if we are using ETX. --> use a linear approach.

        Action item: All to ask about RPL OF0 presentation by Pascal on ML.

  • [09.11] AOB

    No other business raised.

  • [09.12] Meeting ends

Updated