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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
