IEEE802.15.4e in a Nutshell
The IEEE802.15.4e working group was created in 2008 to redesign the MAC protocol defined in IEEE802.15.4-2006. Through time synchronization and channel hopping, it enables high reliability while maintaining very low duty cycles. IEEE802.15.4e is only a MAC protocol change, which does require any changes to the hardware.
IEEE802.15.4e
Time Synchronized Channel Hopping (TSCH) is a part of IEEE802.15.4e draft standard since 2010. The concept is very simple: synchronize the motes for energy efficiency, channel hop for reliability. This is not a new concept as it is used in Bluetooth, ISA100.11a or WirelessHART.
Slotframe Structure
Motes synchronize on a slotframe structure. A slotframe is a group of slots which repeat over time. Each mote follows a schedule which tells it what to do in each slot. In a given slot, a mote can either transmit, receive, or sleep. In a sleeping slot, the mote does not turn on its radio. For each active slots, the schedule indicates with which neighbor to transmit or receive, and on which channel offset.
A single slot is long enough for the transmitter to send a maximum length packet, and for the receiver to send back an acknowledgment indicating good reception. While the duration of a slot is implement-specific, 10ms is commonplace.
When an upper layer generates a packet, it sends it to the MAC layer which stores the packet in a transmit queue. At each transmission slot, the MAC layer checks whether it has a packet in its queue destined to the neighbor associated with that slot. If not, it goes back to sleep without turning its radio on. Otherwise, and if this packet exists, this layer transmits the packet and waits for the ACK. When an ACK is received, it removes the packet from the queue. Otherwise, it keeps the packet in the queue for future re-transmission. A number of retransmissions is kept for every packet to avoid staleness.
At each reception slot, a mote turns on its radio right before the time it expects to receive the packet. If it receives a packet destined for it, it sends and acknowledgment, turns off its radio, and forwards the packet to the upper layer for processing. If it does not receive anything after some timeout, it returns to sleep. This means that either the transmitter had nothing to say, or that the packet got lost do to interference or fading.
Scheduling
IEEE802.15.4e defines how the MAC layer "executes" a schedule; it does not specify how such as schedule is built. A schedule needs to be built carefully so that, when mote A has a transmit slot to mote B, B is actually listening for packets from A. Similarly, if A is no longer a neighbor of B (e.g. it moved or switched off), B should not be listening anymore for packets from A.
There are two ways usually to go about scheduling: hardcode it or create some sort of algorithm to generate it automatically. One possibility for hardcoded schedules could be a single shared slot for example. In the case when the schedule is generated by some algorithm, the routine can either be built centrally by a central network "manager", or done in a distributed way.
Status
IEEE802.15.4e is still a draft standard. While the technical work is mostly done, it has to be adopted before being released to the public. This means that changes may need to be made to the OpenWSN implementation once the standard is out. This document is compiled with our "best guess" at what the final standard will contain. We do not expect the core implementation to have any big changes, mostly just the order of bits in headers.
More information
