[riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

Jonas Remmert j.remmert at phytec.de
Mon May 11 15:38:18 CEST 2015


Hi Daniel,

>
> 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 [2] 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 [2] 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 [2] 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 [3] 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 [4] 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
>
> [1] https://github.com/rousselk/RIOT/commits/s-cosens
> [2] https://github.com/RIOT-OS/RIOT/pull/2467
BTW: Is this also publicly availble somewhere? [2]
> [3] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4539479
> [4] 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 
upper layers.
>  * 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
> https://lists.riot-os.org/mailman/listinfo/devel


More information about the devel mailing list