[riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
mail at daniel-krebs.net
Mon May 11 15:53:53 CEST 2015
> 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
You're right that it's good idea to have some adaption layer on top of
the device drivers that enables usage of hardware MAC mechanism s while
providing a software approach for transceiver that don't support this.
The question here is if it's possible to meet the tight timings. Need to
> 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.
I'm going to need a Linux-bridge, too. The packets my MAC protocol will
send will also be 802.15.4-2006(?) compatible, but the channel access
scheme will be different. So at least sniffing should be no problem. In
the end I hope to be able to use my RIOT implementation on native for
this bridge, but didn't look into further.
> BTW: Is this also publicly availble somewhere?
I did a quick search and wasn't able to find it publicly :(
> 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.
That's right. But at least multi-hop networks have some implications on
the MAC scheme. Just wanted to state that this is not my first priority,
because I don't want to deal with this for now.
> 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.
Sure. That's why I started familiarizing with RIOT by implementing the
RTT peripheral for the samr21-xpro. The RTC, at least on this board,
might be the only peripheral that can run in every power mode and wake
up the MCU.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel