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

Daniel Krebs mail at daniel-krebs.net
Mon May 11 15:53:53 CEST 2015


Hi Jonas,

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

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 
investigate further.


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

Best regards,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150511/5c2e9004/attachment.html>


More information about the devel mailing list