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
pgpw7BPSADwc9.pgp
Description: PGP signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
