6tus Layer Specification

Document Type Expired Internet-Draft (individual)
Authors Qin Wang  , Xavier Vilajosana  , Thomas Watteyne 
Last updated 2013-11-24 (latest revision 2013-05-23)
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A time slot in that schedule corresponds to an atomic link-layer resource, and can be allocated to any pair of neighbors in the network. This allows the schedule to be built to tightly match each node's bandwidth, latency and energy constraints, while ensuring collision-free communication. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of the standard's scope. Routing layers such as the IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to route multipoint-to-point traffic (from devices inside the LLN towards a central control point) and point-to-multipoint traffic (from the central control point to the devices inside the LLN). Network layer overlays cannot be optimized and adapted to take advantage of the cell-based topology created by the underlying TSCH MAC layer as a missing set of functionalities need to be defined. This document describes the 6tus layer and the main commands it provides to upper network layers such as RPL or GMPLS. The set of functionalities includes feedback metrics from cell states so network layers can take routing decisions, TSCH configuration and control procedures, and the support for centralized and decentralized scheduling policies.


Qin Wang (wangqin@ies.ustb.edu.cn)
Xavier Vilajosana (xvilajosana@uoc.edu)
Thomas Watteyne (twatteyne@linear.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)