[riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
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 
> describing the interface to the transceiver driver, currently implemented for
> at86rf2xx and XBEE, and the netapi  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 .
> 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  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
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...
Size: 45383 bytes
Desc: not available
More information about the devel