The most prominent standard in low-power radio technology is IEEE 802.15.4. It defines both the PHY layer (e.g., the modulation scheme used) and the MAC layer (e.g., in a network, which mote talks when, on which channel). The first revision of the standard was published in 2003, with revisions in 2006 and 2011. Several working groups are currently working on improving the standard in preparation for its next revision. These groups are identified by a letter, e.g. IEEE 802.15.4e .
The IEEE 802.15.4 PHY is a healthy trade-off between energy-efficiency, range, and data rate targeted at building- sized networks. While the current standard defines multiple PHY layers, the most widely used is the one operating in the 2.4 − 2.485 GHz frequency band, a worldwide and unlicensed band. In this band, the IEEE 802.15.4 PHY layer uses Offset-Quadrature Phase-Shift Keying (O-QPSK) modulation with a 2 M bps physical data rate. Internally to the radio, every group of 4 bits of data sent for transmission are encoded as 32 chips (‘physical bits’) by following some simple lookup table. From a user’s perspective, the bitrate appears to be 250 kbps, although internally 8 more chips are sent over a 2 M cps link.
This technique is referred to as Direct Sequence Spread Spectrum (DSSS) and known to yield extra robustness. IEEE 802.15.4 defines 16 frequency channels, located every 5 M Hz between 2.405 GHz and 2.480 GHz. The channels themselves are only 2 M Hz wide, so channel i does not interfere with channel i − 1 or i + 1; channels are said to be orthogonal. The radio can arbitrarily send and receive on any of those channels, and every compliant radio is able to switch channels in no more than 192 us.
When a radio sends a packet, it starts by transmitting a physical preamble for 128 us to allow for the receiver to lock to its signal. It then sends a well-known Start of Frame Delimiter (SFD) to indicate the start of the physical payload. The first byte of the physical payload indicates the length (in bytes) of the payload itself. Its maximum value is 127, which limits the length of a packet to 128 bytes when including the length byte. A radio listening continuously demodulates what it hears. When no other mote is transmitting, it hears white noise and the stream of bits coming out of the demodulator is random. The circuitry in the receiver looks for a physical preamble to ‘lock onto’.
Once locked on, the receiver waits for the SFD, then for the length byte. It then fills a receive buffer with the number of bytes indicated in the length byte, after which it can switch off safely. After successfully receiving a packet, the radio indicate reception to the micro-controller. From a implementer’s point of view, the only requirements are to send packets of at most 128 bytes, and to have the first byte indicate how many bytes follow. Although in a protocol stack the bytes following the length byte comply to different header formats (e.g. MAC, routing, transport), they can be arbitrary as far as the radio is concerned.
The IEEE802.15.4e standard was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE802.15.4-2011 standard. The Timeslotted Channel Hopping (TSCH) mode of IEEE802.15.4e is the object of this page.
TSCH was designed to “allow IEEE802.15.4 devices to support a wide range of industrial applications”. At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. This is very different from the “legacy” IEEE802.15.4 MAC protocol, and is therefore better described as a “redesign”. TSCH does not amend the physical layer; i.e., it can operate on any IEEE802.15.4-compliant hardware.
IEEE802.15.4e can be seen as the latest generation of ultra-lower power and reliable networking solutions for LLNs. RFC5673 discusses industrial applications, and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial environment. Commercial networking solutions are available today in which motes consume 10′s of micro-amps on average with end-to-end packet delivery ratios over 99.999%.
IEEE802.15.4e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 6LoWPAN — RFC6282 –, RPL –RFC6550 — and CoAP — I-D.ietf-core-coap
Bringing industrial-like performance into the LLN stack developed by the 6LoWPAN, ROLL and CORE working groups opens up new application domains for these networks. Sensors deployed in smart cities (see RFC5548) will be able to be installed for years without needing battery replacement. “Umbrella” networks will interconnect smart elements from different entities in smart buildings (see RFC5867). Peel- and-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes (see RFC5826).
While IEEE802154e defines the mechanisms for a TSCH mote to communicate, it does not define the policies to build and maintain the communication schedule, match that schedule to the multi-hop paths maintained by RPL, adapt the resources allocated between neighbor nodes to the data traffic flows, enforce a differentiated treatment for data generated at the application layer and signalling messages needed by 6LoWPAN and RPL to discover neighbors, react to topology changes, self-configure IP addresses, or manage keying material. In other words, IEEE802.15.4e TSCH is designed to allow optimizations and strong customizations, simplifying the merging of TSCH with a protocol stack based on IPv6, 6LoWPAN, and RPL.
The IETF Constrained RESTful Environments (CORE) working group has defined the Constrained Application Protocol (CoAP)(1) which easily translates to HTTP for integration with the web, while meeting specialized requirements such as: multicast support, very low overhead, and simplicity for constrained environments. CoAP has been designed as a generic protocol for LLNs taking into account the features of the underlying architecture. The CORE working group, instead of blindly making a compression of HTTP, defined a subset of the RESTful specification, making it interoperable with HTTP but also specializing it for so constrained environments. The summary of the main features addressed by CoAP are: Constrained web protocol specialized to M2M requirements. Stateless HTTP mapping through the use of proxies or direct mapping of HTTP interfaces to CoAP. UDP transport with application layer reliable unicast and best-effort multicast support. Asynchronous message exchanges. Low header overhead and parsing complexity. URI and Content-type support. Simple proxy and caching capabilities. Optional resource discovery. Observe mechanism for asynchronous notifications. Unlike HTTP, CoAP is an asynchronous request/response protocol over a datagram oriented transport such as UDP. The client/server architecture of HTTP is slightly different in CoAP as endpoints do not assume a so clear role. This is motivated by the nature of the underlying transport, which is asynchronous (i.e., datagram oriented), and both endpoints acting as clients and servers. The architecture of CoAP is divided in two layers, a message layer in charge of reliability and sequencing and a request/response layer in charge of mapping requests to responses and their semantics. As of today, CoAP has been standardized as RFC 7252(2) since June 2014. You can find more information about CoAP and pointers to various implementations (3) https://datatracker.ietf.org/doc/rfc7252/ https://tools.ietf.org/html/rfc7252 http://coap.technology
The Internet is composed of many networks, a number of which are typically traversed by a packet on its way from source to destination. Thus, for each type of link layer technology which the network is based on, there needs to be an “IP-over-X” specification that defines how to transport IP packets. In many cases, to map the services required by the IP layer onto the services provided by the lower layer (i.e, the link layer), the “IP-over-X” specification can amount to a (sub)layer of its own, often called adaptation layer. In the process of shaping the IoT world, in 2007 the IETF IPv6 over Low power WPAN (6LoWPAN) working group started to work on specifications for transmitting IPv6 over IEEE 802.15.4 networks. Typically, Low power WPANs are characterized by: small packet sizes 1 , support for addresses with different lengths, low bandwidth, star and mesh topologies, battery supplied devices, low cost, large number of devices, unknown node positions, high unreliability, and long idle periods during which communications interfaces are turned off to save energy. Given the aforementioned features, it is clear that the adoption of IPv6 on top of a Low power WPAN is not straightforward, but poses strong requirements for optimization of this adaptation layer. For instance, due to the IPv6 default minimum MTU size of 1280 bytes, a no-fragmented IPv6 packet would be too large to fit in an IEEE 802.15.4 frame; moreover, the overhead due to the 40 bytes long IPv6 header would waste the scarce bandwidth available at the PHY layer. For these reasons, the 6LoWPAN working group has devoted huge efforts for defining an effective adaptation layer called 6LowPAN. Further issues encompass the auto-configuration of IPv6 addresses, the compliance with the recommendation on supporting link-layer subnet broadcast in shared networks, the eduction of routing and management overhead, the adoption of lightweight application protocols (or novel data encoding techniques) and the support for security mechanisms (i.e., confidentiality and integrity protection, device bootstrapping, key establishment and management).
RPL is a distance vector routing protocol (defined in RFC6550). It can operate on top of IEEE802.15.4. The routing layer is responsible for relaying packets across multiple hops separating source and destination nodes. It is divided into a forwarding engine, which uses a routing table to decide which neighbor node is the next hop for that packet, and a routing protocol, which populate that routing table. RPL is a routing protocol. RPL is designed for Low Power and Lossy Wireless Networks such as Wireless Sensor Networks. It hence it optimized for collection networks (where nodes periodically report measurements to a small number of collection points) with infrequent communication from the collection point to individual nodes. RPL dubs collection traffic Multi-Point-to-Point (MP2P) and configuration traffic Point-To-Multi-Point (P2MP). RPL does not support Point-To-Point (P2P) traffic well, although workarounds can be used. For MP2P traffic, RPL builds a gradient into the network, grounded at the collection points called Low power and lossy network Border Router (LBR). Each node is assigned a rank such that rank increases as the node is far from the LBR. In RPL, this gradient is called a Destination Oriented Directed Acyclic Graph (DODAG). Forwarding a packet to the LBR roughly consist in picking the neighbor node with the lowest rank. Nodes running RPL exchange signaling information to setup and maintain the DODAG. This information is exchanged as a new type of ICMPv6 message called the RPL Control Message. The 1B code in the ICMPv6 header is used to differentiate between different sub-type. The sub-type used to build the DODAG is called DAG Information Object (DIO). All the nodes in the network regularly issue a DIO which serves as a heartbeat to indicate their rank. The instant at which a node issues a DIO is governed by a Trickle timer which is reset only when an inconsistency arises. This way, when topology is stable, very little DIOs are exchanged. P2MP is enabled in two forms: Storing Mode and Non-Storing mode. In Non-Storing mode, Source routing (according to RFC6554) is used when issuing a message for a specific node in the network, the LBR prepends the sequence of nodes that need to be traversed to get to the destination to the packet. To learn this sequence, each node in the network is asked to transmit a Destination Advertisement Object (DAO) to the LBR (another subtype of the ICMPv6 RPL Control Message) indicating its parents and children. Storing mode uses intermediate tables in certain nodes in the network. Analogously to the behaviour of a Distributed Hash Table (DHT), routes are computed partially to each intermediate node that is able to route within its subnetwork until the destination is reached.