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

Joakim Gebart joakim.gebart at eistec.se
Mon May 11 14:52:33 CEST 2015


On Mon, May 11, 2015 at 11:37 AM, Daniel Krebs <mail at daniel-krebs.net> wrote:
> Hello RIOTers,
>
> 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.
>
> 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.
>
> 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.

+1 We use mostly Contiki-based applications presently and it would be
a big improvement if it was possible to get ContikiMAC duty cycling
working in RIOT as well.

>
> 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
> [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

Is this not a requirement of the routing?

>  * 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?

Routing protocols might need it. RPL sends solicitation messages to
ask for routing information.

>  * Add multi-hop / routing later? Is this even reasonable?

Some kind of routing will be necessary for any useful applications, at
least some kind of hardware address to IPv6 address mapping must exist
to fill the neighbor cache. (e.g. RPL, NDP)

>  * 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?

Yes!

>
> # Implementation
>
>  * Duty cycle nodes for energy saving
>  * 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


Best regards,
Joakim


More information about the devel mailing list