-
Thanks for the info Karl, I think this may make a nice graduation assignment.
2009-08-26 08:33:24 UTC in MiXiM
-
Physical Layer Capture (PLC) is a feature present in some 802.11 hardware that enables to receive the stronger signal when two signals collide. This can provide a dramatic improvement to the success of communication because frames lost by the simple definition of collisions can still be received.
Are there plans to incorporate this feature? I know it is present in NS2 and Qualnet.
2009-08-14 08:01:44 UTC in MiXiM
-
Thanks for the reaction! I went back to an unmodified Mac80211. The Gaack in question is the one in the handleLowerMsg() function.
I am expecting it has something to do with some modifications I made to the PHY in Const80211.h to model 802.11p, these include:
const double BITRATES_80211[] = {
3000000,
4500000,
6000000,
9000000,
12000000,
2009-08-10 13:02:55 UTC in MiXiM
-
A workaround is simply putting the assert(!contention->isScheduled()) and the error("Gaack") messages in comments. It works, although I am a bit hesitant to blatantly modify code I do not fully understand. Could it be that the Mac80211 in MiXiM 1.0 is still in a transitional state from MFw to MiXiM, and still a bit beta-ish?.
2009-07-31 12:05:01 UTC in MiXiM
-
I compared the code to Mac80211 in MFw 2.0p3 and noticed an overhaul. Indeed, the PHY changed so it makes sense the channelSense changes (modelled with a channelSenseRequest message called "contention") is changed as well. Although in MFw the suspendContention worked properly.
I cannot find where contention is scheduled, apparently it is scheduled because i get the "Gaack!!" error. I would...
2009-07-31 11:42:22 UTC in MiXiM
-
In Mac80211::handleLowerMsg(cMessage *msg):
if (contention->isScheduled()) {
error("Gaack! I am changing the IFS on an ongoing contention");
}
It seems to me that it should be possible that, while a node is in contention (e.g. counting down its bc) it should be able to receive a message - it will freeze its bc, receive the message and then resume backoff. This line...
2009-07-31 09:48:25 UTC in MiXiM
-
Mac80211.cc calculates the bitlength of the Mac80211pkt as MAC80211_HEADER_LENGTH + PHY_HEADER_LENGTH. This puzzles me, as the first is a value in bits (272 in Const80211.h) and the PHY_HEADER_LENGTH (192 by default) is a value in microseconds...
The header is transmitted at 1Mbit, so one bit takes one us, so I can understand why we can add \mu s to bits. But why is the PHY header length part...
2009-07-29 11:52:08 UTC in MiXiM
