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

Daniel Krebs mail at daniel-krebs.net
Tue May 12 14:30:44 CEST 2015

Hi Oleg again,

> There's a third inside the OpenWSN stack using the TSCH (Time Slotted 
> Channel Hopping) as specified in the IEEE 802.15.4e amendment. I'm 
> currently spending some time to see how it could be used separately 
> from the remaining OpenWSN stack, but don't expect any results before 
> next month. 
I'll have a look at it, thanks for the pointer.

>> 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.
> The relevant parts for a MAC layer implementation are probably netdev [1]
> describing the interface to the transceiver driver, currently implemented for
> at86rf2xx and XBEE, and the netapi [2] describing the interface of any layer
> in the network stack, including the MAC protocol. There's also a sketch of the
> new architecture made by Hauke some time ago [3].
> I don't think it's realistic to say that these APIs won't change any more, but
> I guess they should be stable enough to start implementing against them.
Yesterday I had a look at all the APIs and also found [3] som etime ago 
on the mailing-list. This helped a lot, thanks Hauke!
I summarized my findings in a diagram, now attached to this mail. I also 
inlcudes the MAC hardware-feature abstraction that Jonas mentioned 

>>   * No need to comply with IEEE 802.15.4 MAC schemes
> Can you elaborate on this point?
As pointed out in my previous mail, I don't aim for compatibility with 
devices that strictly implement the specification, i.e. need a PAN 
coordinator. Reasons given in the other mail.

>>   * Do we need broadcasting?
> Depends on your use case - for a generic implementation, definitely yes.
> Remember that typical radio devices in this domain are omnidirectional, hence,
> you cannot really distinguish between unicast and broadcast on the physical
> layer.
The probem with duty-cycling is, that packets are not broadcast anymore 
per-se. You (the sender) need to make sure that every node has woken up 
at least one time while you have been sending your packet.

>>   * Add multi-hop / routing later? Is this even reasonable?
> That's independent from the MAC layer. Can you elaborate on this?
When having multi-hop networks, you essentially have nodes outside the 
radio scope of each others. But you also have nodes in between that are 
in the reach of both. This can create a need for scheduling, imagine 
both nodes, that don't see each other, try to communicate at the same 
time with the node in between. But I didn't think this through all the 
way, I just wanted to state that I'm going to ignore this for now.

I really shouldn't have used the term "routing" here :P

>>   * Do we really need adaption to traffic load?
> One of the main issues with contention based MAC protocols is that they are
> heavily affected by the traffic load, so you should at least consider
> different scenarios.
That's right. I can't really estimate my load at the moment apart from 
the fact that I'm not going to stream videos and that it will be more 
than one sensor value per node every 5 minutes :

>   * LPEAS => Implicit synchronization
> I wonder if you really want to go for synchronization for a simple contention
> based protocol. Don't underestimate this challenge.
Did you have a look at the paper that expalins LPEAS? It's a really 
simple synchronization scheme.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAC_Overview.pdf
Type: application/pdf
Size: 45383 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150512/3f31a425/attachment-0001.pdf>

More information about the devel mailing list