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

Oleg Hahm oliver.hahm at inria.fr
Tue May 12 09:48:06 CEST 2015


Hi Daniel!

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

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.

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

One downside of ContikiMAC is that is not standardized, but that's not
necessarily a problem in many use cases. I think the protocol is quite widely
deployed and familiar to most people working with WSNs, so I guess it would be
really nice to have a compatible implementation.

A similar scheme to ContikiMAC was implemented in RIOT, but only for the
CC110x transceiver and not adapted to the new interfaces [0].

> 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.
 
>  * No need to comply with IEEE 802.15.4 MAC schemes

Can you elaborate on this point?

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

>  * Add multi-hop / routing later? Is this even reasonable?

That's independent from the MAC layer. Can you elaborate on this?

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

>  * Find out which APIs to use in RIOT to have a modular MAC protocol that
> might work with multiple transceivers

See above, netdev should be your friend.
 
> # Observations
> 
>  * Requirements seem to match ContikiMAC, so maybe aim for compatibility?

That would be awesome.

>  * LPEAS => Implicit synchronization

I wonder if you really want to go for synchronization for a simple contention
based protocol. Don't underestimate this challenge.

>  * Use 802.15.4 features, so this might only work with 802.15.4 networks

I think you should make the requirements on the transceiver somewhere
explicit.

Cheers,
Oleg

[0] https://github.com/RIOT-OS/RIOT/tree/master/drivers/cc110x_legacy_csma
[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netdev.h
[2] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netapi.h
[3] http://riot-os.org/files/nstf-overview.pdf
-- 
printk("VFS: Busy inodes after unmount. "
        "Self-destruct in 5 seconds.  Have a nice day...\n");
        linux-2.3.99-pre8/fs/super.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150512/f28eadf2/attachment.sig>


More information about the devel mailing list