802.11 medium access emulation in wmediumd

251 views
Skip to first unread message

Spyros Vassilaras

unread,
Jun 2, 2021, 10:43:24 AM6/2/21
to mininet-wifi-discuss

Hello and apologies if this has been already discussed in this group:

I am planning to use mininet-wifi to emulate MANETs and compare traditional MANET routing protocols with SDN based approaches. I have noticed that in the ad hoc mode with the interference model, simultaneous transmissions in two links that are far away from each other are not taking place. Digging deeper into wmediumd code, I have discovered that the 802.11 medium access mechanism is simulated in a simplistic way that pre-computes the time a frame would need to get correctly received (including re-transmissions) and assumes that no simultaneous transmissions (even over far away, non-interfering links) can happen.

My questions are:

What is the reason for not having implemented a more realistic 802.11 MAC (with carrier sensing, random backoff times, freezing of the backoff timer when the channel is sensed busy, etc) in wmediumd? Is it due to lack of the resources/time to do this (and if so do you plan to do it in the future)? Or is it because a more realistic protocol emulation would incur a very large computational load, thus negatively impacting the emulation results (due to the real-time emulation model of mininet-wifi)? Or it is just too difficult to correctly implement such a realistic MAC using the event handling libraries that are available in C?

In conclusion, do you think that it is feasible to implement a somehow more realistic MAC (of course some simplifying assumptions will always need to be made) or it is just a waste of time trying to do so?

Ramon Fontes

unread,
Jun 2, 2021, 10:58:02 AM6/2/21
to Spyros Vassilaras, mininet-wifi-discuss
That's a good question. I have no idea why a more realistic wireless medium has been implemented though. However, I just noticed some updates in https://github.com/bcopeland/wmediumd and it seems that some improvements have been made in this regard. What do you think?

Sent from my android

--
You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/24b347c6-9890-4b57-92db-b719bceba834n%40googlegroups.com.

Spyros Vassilaras

unread,
Jun 3, 2021, 3:31:50 AM6/3/21
to Ramon Fontes, mininet-wifi-discuss

Thank you for your prompt reply. 
I am aware of the wmediumd fork in https://github.com/bcopeland/wmediumd 
Note however that:
1) I was not able to use the wmediumd daemon built with this distribution in conjunction with mininet-wifi. When running a mininet-wifi script with this wmediumd executable placed in /usr/bin/ I was getting an error message ending with: 
cls.sock.connect(uds_address)
FileNotFoundError: [Errno: 2] No such file or directory
It seems that the command line arguments for this wmediumd executable are different than the ones in your wmediumd fork, but I was not able to determine the correct way to call it from within mininet-wifi's wmediumConnector.py. Any help with this would be greatly appreciated.
2) Although the code in https://github.com/bcopeland/wmediumd seems to handle events in a better way which provides a basis for developing a more realistic medium access model, the basic philosophy of how medium access is modeled (described in my previous message) remains the same. 
Reply all
Reply to author
Forward
0 new messages