[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

6TSCH                                                 X. Vilajosana, Ed.
Internet-Draft                           Universitat Oberta de Catalunya
Intended status: Informational                                 K. Pister
Expires: January 15, 2014              University of California Berkeley
                                                           July 14, 2013


                      Minimal 6TSCH Configuration
                    draft-vilajosana-6tsch-basic-01

Abstract

   This document describes the minimal set of rules to operate a
   [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  These
   rules can be used during early interoperability testing and
   development, when the centralized and distributed solutions developed
   by the 6TSCH group are not fully implemented yet, or otherwise not
   available.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 15, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Vilajosana & Pister     Expires January 15, 2014                [Page 1]

Internet-Draft                 6tsch-basic                     July 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Basic Schedule  . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Slotframe . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Cell Options  . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Retransmissions . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Time Slot timming . . . . . . . . . . . . . . . . . . . .   5
   3.  Enhanced Beacons Configuration and Content  . . . . . . . . .   6
     3.1.  Sync IE . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  IE Header . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  IE Content  . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Frame and Link IE . . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  IE Header . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.2.  IE Content  . . . . . . . . . . . . . . . . . . . . .   8
   4.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  ACK/NACK Time Correction IE . . . . . . . . . . . . . . .   8
       4.1.1.  IE Header . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.2.  IE Content  . . . . . . . . . . . . . . . . . . . . .   8
   5.  Neighbor information  . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Neighbor Table  . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Time Parent Selection . . . . . . . . . . . . . . . . . .  10
   6.  Queues and Priorities . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     7.3.  External Informative References . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The nodes in a [IEEE802154e] TSCH network follow a communication
   schedule.  The entity (centralized or decentralized) responsible for
   building and maintaining that schedule has very precise control over
   the trade-off between the network's latency, bandwidth, reliability
   and power consumption.  During early interoperability testing and
   development, however, simplicity is often more important than
   efficiency.  The goal of this document is to define the simplest set
   of rules for building a [IEEE802154e] TSCH-compliant network, at the
   necessary price of lesser efficiency.

2.  Basic Schedule






Vilajosana & Pister     Expires January 15, 2014                [Page 2]

Internet-Draft                 6tsch-basic                     July 2013


   In order to form a network, a minimum schedule configuration is
   required so nodes can advertise the presence of the network, and
   allow other nodes to join.

2.1.  Slotframe

   The Slotframe, as defined in [I-D.palattella-6tsch-terminology], is
   an abstraction of the MAC layer that defines a collection of time
   slots of equal length and priority, and which repeats over time.  In
   order to set up a basic TSCH network, nodes need to be synchronized
   with the same slotframe configuration so they can exchange Enhanced
   Beacons (EBs) and data packets.  This document recommends the
   following slotframe configuration.

   Basic configuration

   +------------------------------------+----------------------+
   |           Property                 |       Value          |
   +------------------------------------+----------------------+
   | Number of time slots per Slotframe |        101           |
   +------------------------------------+----------------------+
   | Number of available channels       |         16           |
   +------------------------------------+----------------------+
   | Number of EBs cells                | 1 (slotOffset 0)     |
   +------------------------------------+----------------------+
   | Number of scheduled cells          | 5 (slotOffsets       |
   |                                    | 1,2,3,4,5)           |
   +------------------------------------+----------------------+
   | Number of unscheduled cells        | 95 (from slotOffset  |
   |                                    | 6 to 100)            |
   +------------------------------------+----------------------+
   | Number of MAC retransmissions (max)|         3            |
   +------------------------------------+----------------------+
   | Time Slot duration                 |        15ms          |
   +------------------------------------+----------------------+


   The suggested basic schedule is hard-coded in each node.  The
   slotframe is composed of 101 time slots.  The first slot in the
   slotframe is used to send Enhanced Beacons announcing the presence of
   the network.  These EBs are not acknowledged.  Five cells are
   scheduled for exchanging data packets, as described in Section 2.2.
   These cells are scheduled at slotOffset 1 to 5, and channeOffset 0.
   Per the IEEE802.15.4e TSCH standard, data packets sent on these cells
   to a unicast MAC address are acknowledged by the receiver.  The 95
   remaining cells are unscheduled, i.e., the radio of the nodes remains
   off.




Vilajosana & Pister     Expires January 15, 2014                [Page 3]

Internet-Draft                 6tsch-basic                     July 2013


   Basic schedule overview

                +-----+-----+-----+-----+-----+-----+-----+     +-----+
   chan.Off. 0  | EB  |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF |
                +-----+-----+-----+-----+-----+-----+-----+     +-----+
   chan.Off. 1  |     |     |     |     |     |     |     | ... |     |
                +-----+-----+-----+-----+-----+-----+-----+     +-----+
                  ...
                +-----+-----+-----+-----+-----+-----+-----+     +-----+
   chan.Off. 15 |     |     |     |     |     |     |     | ... |     |
                +-----+-----+-----+-----+-----+-----+-----+     +-----+
                   0     1     2     3     4     5     6          100


2.2.  Cell Options

   Per the [IEEE802154e] TSCH standard, each scheduled cell has a bitmap
   of cell options assigned.  All scheduled cells in the basic schedule
   are configured as Hard cells
   [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top]
   since reallocation is not considered in that simple approach.

   The EB cell is assigned the following bitmap of cell options:

      b0 = Transmit = 1 (set)

      b1 = Receive = 0 (clear)

      b2 = Shared = 0 (clear)

      b3 = Timekeeping = 0 (clear)

      b4 = Hard = 1 (set)

      b5-b7 = Reserved (clear)

   The data cells are assigned the bitmap of cell options below that
   results in "Slotted Aloha" behavior.  Because both the "Transmit" and
   "Receive" bits are set, a node either transmits, if there is a packet
   in its queue, or listens if it has nothing to transmit.  Because the
   "shared" bit is set,in presence of collisions it uses the backoff
   mechanism defined in [IEEE802154e].

      b0 = Transmit = 1 (set)

      b1 = Receive = 1 (set)

      b2 = Shared = 1 (set)



Vilajosana & Pister     Expires January 15, 2014                [Page 4]

Internet-Draft                 6tsch-basic                     July 2013


      b3 = Timekeeping = 0 (clear)

      b4 = Hard = 1 (set)

      b5-b7 = Reserved (clear)

   All remaining cells are unscheduled.  Thus the nodes can keep their
   radio off.  In a memory efficient implementation, scheduled cells
   could be represented by a circular linked list.  Unscheduled cells
   should not occupy any memory.

2.3.  Retransmissions

   The maximum number of MAC-layer retransmissions is set to 3.  For
   packets which require an acknowledgement, if none is received after a
   total of 4 attempts, the transmissions is considered failed at the
   MAC layer, and the upper layer needs to be notified.  Packets sent to
   the broadcast MAC address (including EBs) are not acknowledged and
   therefore not retransmitted.

2.4.  Time Slot timming

   The figure below shows an active timeslot in which a packet is sent
   from the transmitter node (TX) to the receiver node (RX), and a MAC
   acknowledgement is sent back from the RX to the TX node, indicating
   successful reception.  The TsTxOffset duration defines the instant in
   the timeslot when the first byte of the transmitted packet leaves the
   radio of the TX node.  The radio of the RX node is turned on TsLongGT
   /2 before that instant, and listen for at least TsLongGT.  This
   allows for a de-synchronization between the two node of at most
   TsLongGT.  The RX node needs to send the first byte of the MAC
   acknowledgement exactly TsTxAckDelay after the end of the last byte
   of the received packet.  TX's radio has to be turned on TsShortGT/2
   before that time, and keep listening for at least TsShortGT.

   Time slot internal timing diagram















Vilajosana & Pister     Expires January 15, 2014                [Page 5]

Internet-Draft                 6tsch-basic                     July 2013


      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot


   [IEEE802154e] does not define the different durations of a time slot.
   It does allow those durations to be sent in the EBs (through a
   TimeSlot IE), but for simplicity, this document recommends to hard-
   code the different durations to the values listed below.

   Timeslot durations

   +---------------------------------+------------------+
   |  IEEE802.15.4e TSCH parmeter    |     Value        |
   +---------------------------------+------------------+
   | TsTxOffset                      |     4000us       |
   +---------------------------------+------------------+
   | TsLongGT                        |     2600us       |
   +---------------------------------+------------------+
   | TsTxAckDelay                    |     4606us       |
   +---------------------------------+------------------+
   | TsShortGT                       |     1000us       |
   +---------------------------------+------------------+
   | Time Slot duration              |    15000us       |
   +---------------------------------+------------------+


3.  Enhanced Beacons Configuration and Content

   [IEEE802154e] does not define how often or which EBs are sent.  The
   choice of the duration between two EBs needs to take into account
   whether EBs are used as the only mechanism to synchronize devices, or
   whether a Keep-Alive (KA) mechanism is used in parallel.  For a
   simplest TSCH configuration, it is recommended to sent EBs at least
   once every 10s. For additional reference see



Vilajosana & Pister     Expires January 15, 2014                [Page 6]

Internet-Draft                 6tsch-basic                     July 2013


   [I-D.watteyne-6tsch-tsch-lln-context] where different synchronization
   approaches are summarized.

   EBs must be sent with the Beacon IEEE802.15.4 frame type and this
   document recommends that they carry the following Information
   Elements (IEs):

3.1.  Sync IE

   Contains synchronization information such as ASN and join priority.

3.1.1.  IE Header

      Length (b0-b7) = 0x06

      Sub-ID (b8-b14) = 0x1a

      Type (b15) = 0x00 (short)

3.1.2.  IE Content

      ASN Byte 1 (b16-b23)

      ASN Byte 2 (b24-b31)

      ASN Byte 3 (b32-b39)

      ASN Byte 4 (b40-b47)

      ASN Byte 5 (b48-b55)

      Join Priority (b56-b63)

3.2.  Frame and Link IE

   Although the schedule is hard-coded in each node, this document
   recommends to indicate the schedule in each EB through a Frame and
   Link IE.  This enables nodes which implement [IEEE802154e] fully to
   be able to configure their schedule as they join the network, and
   interact with nodes using a hard-coded schedule.

3.2.1.  IE Header

      Length (b0-b7) = variable

      Sub-ID (b8-b14) = 0x1b

      Type (b15) = 0x00 (short)



Vilajosana & Pister     Expires January 15, 2014                [Page 7]

Internet-Draft                 6tsch-basic                     July 2013


3.2.2.  IE Content

      # Slotframes (b16-b23) = 0x01

      Slotframe ID (b24-b31) = 0x01

      Size Slotframe (b32-b47) = 0x65

      # Links (b48-b55) = 0x06

   For each link in the basic schedule:

      Channel Offset (2B) = 0x00

      Slot Number (2B) = from (0x00 to 0x05)

      LinkOption (1B) = as described in Section 2.2

4.  Acknowledgement

   MAC-layer acknowledgement frames are built according to
   [IEEE802154e].  Data frames and command frames sent to a unicast MAC
   destination address request an acknowledgement.  The acknowledgement
   frame is of type ACK (0x10).  Each acknowledgement contains the
   following IE:

4.1.  ACK/NACK Time Correction IE

   The ACK/NACK time correction IE is used to carry the measured
   desynchronization between the sender and the receiver.

4.1.1.  IE Header

      Length (b0-b7) = 0x02

      Sub-ID (b8-b14) = 0x1e

      Type (b15) = 0x00 (short)

4.1.2.  IE Content

      Time Synch Info and ACK status (b16-b31)

   The possible values for the Time Synch Info and ACK status are
   described in the following table:

   ACK status and Time Synch information.




Vilajosana & Pister     Expires January 15, 2014                [Page 8]

Internet-Draft                 6tsch-basic                     July 2013


   +-----------------------------------+------------------+
   |          ACK Status               |     Value        |
   +-----------------------------------+------------------+
   | ACK with positive time correction |  0x0000 - 0x07ff |
   +-----------------------------------+------------------+
   | ACK with negative time correction |  0x0800 - 0x0fff |
   +-----------------------------------+------------------+
   | NACK with positive time correction|  0x8000 - 0x87ff |
   +-----------------------------------+------------------+
   | NACK with negative time correction|  0x8800 - 0x8fff |
   +-----------------------------------+------------------+


5.  Neighbor information

   [IEEE802154e] does not define how and when each node in the network
   keeps information about its neighbors.  This document recommends to
   keep the following information in the neighbor table:

5.1.  Neighbor Table

   The exact format of the neighbor table is implementation-specific,
   but it should at least contain the following information, for each
   neighbor:

      Neighbor statistics:

         number of transmitted packets to that neighbor

         number of transmitted packets that have been acknowledged by
         that neighbor

         number of received packets from that neighbor

         number of received packets that have been acknowledged for that
         neighbor

      Neighbor address.

      ASN when that neighbor was heard for the last time.  This can be
      used to trigger a keep-alive message.

      RPL rank of that neighbor.

      A flag which indicates whether this neighbor is a time source
      neighbor.





Vilajosana & Pister     Expires January 15, 2014                [Page 9]

Internet-Draft                 6tsch-basic                     July 2013


      Connectivity statistics (RSSI, LQI, etc), which can be used to
      determine the quality of the link.

   In addition of that information, each node has to be able to compute
   some RPL objective function (OF) taking into account the neighbor and
   connectivity statistics.  An example RPL objective function is the
   ETX.

5.2.  Time Parent Selection

   Each node selects a time parent amongst its known neighbors.  When a
   node joins a network, it has no routing information yet.  Its
   (possibly temporary) time parent is the node it can hear "best", for
   example based on RSSI measurements of the EBs it received.  After
   having acquired a RPL rank, the RPL routing parents should also be
   IEEE802.15.4e time source neighbors.

   Optionally, a node can choose to use an counter to avoid frequent
   changes in time source neighbor selection.  Based on some thresholds
   (on RSSI for example), if the quality of the link with time parent
   changes over or below the thresholds for a certain number of times
   (e.g., 3), the instability counter is incremented and another time
   parent is selected.

6.  Queues and Priorities

   [IEEE802154e] does not define the use of queues to handle upper layer
   data (either application or control data from upper layers).  This
   document recommends to use a single queue with the following rules:

      When the node is not synchronized to the network, higher layers
      are not able to insert packets into the queue.

      Lower-layer packets have a higher priority that packets received
      from a higher layer.

      IEEE802.15.4 frames of types Beacon and Command have a higher
      priority than IEEE802.15.4 frames of types Data and ACK.

      One entry in the queue is reserved at all times for a IEEE802.15.4
      frames of types Beacon or Command frames.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Vilajosana & Pister     Expires January 15, 2014               [Page 10]

Internet-Draft                 6tsch-basic                     July 2013


   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

7.2.  Informative References

   [I-D.watteyne-6tsch-tsch-lln-context]
              Watteyne, T., Palattella, M., and L. Grieco, "Using
              IEEE802.15.4e TSCH in an LLN context: Overview, Problem
              Statement and Goals", draft-watteyne-6tsch-tsch-lln-
              context-02 (work in progress), May 2013.

   [I-D.thubert-6tsch-architecture]
              Thubert, P., Assimiti, R., and T. Watteyne, "An
              Architecture for IPv6 over Time Slotted Channel Hopping",
              draft-thubert-6tsch-architecture-01 (work in progress),
              April 2013.

   [I-D.palattella-6tsch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over Time Slotted Channel Hopping",
              draft-palattella-6tsch-terminology-00 (work in progress),
              March 2013.

   [I-D.draft-wang-6tsch-6top]
              Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TSCH
              Operation Sublayer (6top). draft-wang-6tsch-6top-00 (work
              in progress) ", July 2013.

   [I-D.ohba-6tsch-security]
              Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
              A. Yegin, "Security Framework and Key Management Protocol
              Requirements for 6TSCH", draft-ohba-6tsch-security-01
              (work in progress), July 2013.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-12 (work in
              progress), March 2013.

   [I-D.phinney-roll-rpl-industrial-applicability]
              Phinney, T., Thubert, P., and R. Assimiti, "RPL
              applicability in industrial networks", draft-phinney-roll-
              rpl-industrial-applicability-02 (work in progress),
              February 2013.





Vilajosana & Pister     Expires January 15, 2014               [Page 11]

Internet-Draft                 6tsch-basic                     July 2013


7.3.  External Informative References

   [IEEE802154e]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendament 1: MAC sublayer", April
              2012.

   [IEEE802154]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications for Low-Rate
              Wireless Personal Area Networks", June 2011.

   [OpenWSN]  , "Berkeley's OpenWSN Project Homepage", ,
              <http://www.openwsn.org/>.

Authors' Addresses

   Xavier Vilajosana (editor)
   Universitat Oberta de Catalunya
   156 Rambla Poblenou
   Barcelona, Catalonia  08018
   Spain

   Phone: +34 (646) 633 681
   Email: xvilajosana@uoc.edu


   Kris Pister
   University of California Berkeley
   490 Cory Hall
   Berkeley, California  94720
   USA

   Email: pister@eecs.berkeley.edu















Vilajosana & Pister     Expires January 15, 2014               [Page 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/