[riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
j.remmert at phytec.de
Mon May 11 15:38:18 CEST 2015
> I want to use RIOT for a low-power 802.15.4 network project. Having a
> bit familiarized with RIOT and my samr21-xpro boards now I want to
> tackle my next milestone, i.e. I need a MAC protocol that fits my
> requirements (see below).
> As it seems that there are only 2 MAC implementations for now [1,2],
> both not what I'm searching for and also not merged, I decided to try
> this on my own.
Better don´t look at  for now ;). Currently that PR is based on a
deprecated proposal that does not poperly use the netdev interface. I
hope I will have time for an update of this PR this week. Even if that
is not what you are searching for, maybe it could be used to make this a
base of an more advanced MAC layer. The intention of  is to provide
an implementation of CSMA-mechanisms, random backoff-time when the
channel is busy and acknowledge handling. Since this procedure is
different for each driver (Hard-MAC vs. Soft-MAC) this  adaption
MAC-layer will be necessary to avoid re-implementing in each radio-driver.
> Therefore I studied some papers and existing MAC schemes to not
> reinvent the wheel. There is one nice paper  that sums up quite
> nicely the most basic duty-cycling schemes (p. 4ff).
> There are some adaptions and refinements to these protocols which
> might improve the throughput or energy-saving further, but I think
> that these basic schemes already provide a good starting point. Namely
> there is ContikiMAC  that incorporates these improvements.
We also made some research in this field. Since we want to use our
sensor-nodes in combination with Linux, we came to the conclusion that a
MAC layer accordingly to the IEEE 802.15.4 standard will fit most for
us. The biggest benefit is the compatibility to all IEEE 802.15.4
devices. Also a high configurability (e.g. the beacon interval length)
is a feature of this standard. There are some optional mechanisms like
GTS that don´t have to be implemented in the first step. But I agree,
there might be easier duty-cycling MAC-layers. Since the architecture of
the network stack allows to choose different MAC layers there is no
problem of having different ones.
> While I want to start implementing a basic and simple protocol first,
> I wonder if it could be nice for RIOT to have some
> ContikiMAC-compatible MAC layer later.
> I can't promise anything for now on how well this will work in the
> end, but I wanted to inform you about my undertaking and maybe you
> have some thought or pointers that could help me. As there is so much
> change in all over the network stack at the moment, it would be nice
> to know which (for me relevant) parts of the stack I should use that
> are not subject to change shortly.
> I gathered some notes and requirements, please find them below.
> Best regards,
> Daniel Krebs
>  https://github.com/rousselk/RIOT/commits/s-cosens
>  https://github.com/RIOT-OS/RIOT/pull/2467
BTW: Is this also publicly availble somewhere? 
>  http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4539479
>  http://dunkels.com/adam/dunkels11contikimac.pdf
> Requirements for MAC-layer
> # Requirements
> * Mesh topology => no single-point-of-failure
> * Low energy consumption
> * Relatively small single-hop network (~10 nodes)
> * New nodes can join and leave the network
> * No need to comply with IEEE 802.15.4 MAC schemes
> * No need for hard realtime
> * Should be reasonibly simple to implement
> # Ideas / Questions
> * Do we need broadcasting?
> * Add multi-hop / routing later? Is this even reasonable?
As I understand it, the routing protocol is located on top of any MAC
protocol. The mechanisms of the MAC protocol will be transparent to the
> * Do we really need adaption to traffic load?
> * Find out which APIs to use in RIOT to have a modular MAC protocol
> that might
> work with multiple transceivers
> # Observations
> * Requirements seem to match ContikiMAC, so maybe aim for compatibility?
> # Implementation
> * Duty cycle nodes for energy saving
For the sleeping periods we might have to use a low-power timer (mostly
low speed clock oscillator, 32khz or so), since most 16Mhz oscillators
consume to much energy for long sleeping periods.
> * LPEAS => Implicit synchronization
> * Use 802.15.4 features, so this might only work with 802.15.4 networks
> devel mailing list
> devel at riot-os.org
More information about the devel