RIOT integration options for Whitefield

Development archive
1

Hello team RIOT,

I m trying to integrate RIOT with a simulation framework called as Whitefield (which i m developing for interop testing) … For details: https://github.com/whitefield-framework/whitefield

I ll use RIOT in native mode. Whitefield will provide for 802.15.4 phy/mac and RIOT will provide for 6lo/ipv6/udp/blah.

As far as possible i wanted to check integration options which do not involve changing RIOT.

For integration i ve thought of foll options:

  1. using tapX interface (but without tapbrX intf) … i.e. RIOT will send packets on tap and whitefield will sniff in promiscous mode on tap and then redirect the packets to the whitefield RF layer … similarly sending pkts to the RIOT node by using raw sockets and then injecting on tap interface. The problem here is that with netdev_tap, 6lo adaptation is not included … I saw an option to use gnrc_zep + gnrc_nomac which could ve enabled 6lo for tap (https://github.com/RIOT-OS/RIOT/wiki/Testing-6LoWPAN-on-Ethernet-based-devices) but seems these two modules are no more part of RIOT.

  2. writing a driver for whitefield in RIOT … This would be a clean/easy solution (and this is what i did for contiki integration) … But this would mean changes to RIOT, and i m not sure if RIOT team would be interested in such PR.

  3. Another option is to use fakelb, which simulates a 802.15.4 phy intf on linux. Thus i assume RIOT 6lo will work on this phy device. Then i go about the same way with integration, the way i planned for tap interface as in 1. Problem here is, fakelb is not available by default, thus there are clumsy (kernel module compilation) setup steps and i m still not sure if this is the right way to go.

Wanted to seek advise from RIOT team regarding which option to use.

Thanks, Rahul

2

Hi Rahul,

Regarding implementation proposal 2: As I don't know anything about Whitefield: what would that implementation look like in detail? In particular: how would RIOT communicate with Whitefield? (Unix) socket/thread messages/other IPC?

Cheers, Ludwig

3

Hi Ludwig,

Communication between whitefield and riot would be using sysv msgq IPC.(Having said that, this layer is loosely coupled and may change in future, if required). Note that these IPC calls are wrapped in a library provided by whitefield.

So if I have to picture it, I would add a driver for whitefield in riot which would essentially be of 802154_type. Would override the recv/send callback in this driver to send /recv the packet over to whitefield. I assume I can override USEMODULES in the specific example app to use this driver and automatically 6lo would come into effect(because driver is of type 802154_type) and I will get 6lo adapted packets in the send callback of this driver.

Just to add more details here about how whitefield operates: whitefield creates a virtual node (which essentially is an instantiation of node in ns3 which provides for realistic RF) for every riot node which runs in its own individual linux process space. Whenever riot calls a send in the 802154_type driver, the packet would be passed on to the virtual node in whitefield. The packet would then be received by one or more of other virtual nodes. The packet will be sent on the IPC Interface and passed on to the appropriate riot node(s) process(es) calling the corresponding 802154_type driver’s recv call, thus completing the packet lifecycle.

The main page of whitefield github repo (https://github.com/whitefield-framework/whitefield) has a block diagram which would give a clear picture.

Also, Writing a driver would give finer control which would help in providing advanced OAM commands.

Regards, Rahul

4

Hi Rahul,

(context for the rest of the list: we talked f2f today about this after lwig @ IETF101)

I agree with Ludwig that option 2 is the best option to implement this. If you looking for a template to implement against netdev, have a look at socket_zep [1] (and ignore what I proposed at our F2F meeting ;-)). I think this can give you a good idea, since it is also an emulated network device, based on IEEE 802.15.4 (though it is lacking some features like channel selection and other radio related options).

Cheers, Martine

[1] https://github.com/RIOT-OS/RIOT/blob/master/cpu/native/socket_zep/socket_zep.c

5

Thank you. I ll look into zep and understand pros and cons with this mode of integration. Thanks for the discussion.

Regards, Rahul