Problems with wifi and other radios

[aarizaq]

I have run a test with the ideal radio in a network with bmac and 802.11 and the simulation ends in void Ieee80211Mac::handleLowerPacket(cPacket *msg). I am no sure if it is the correct behaviour

The method receive a bmac packet and ends the simulation in auto frame = check_cand_cast<Ieee80211Frame *>(msg);

I have modified the code to this void Ieee80211Mac::handleLowerPacket(cPacket *msg) { auto frame = dynamic_cast<Ieee80211Frame *>(msg); if (frame == nullptr) { delete msg; return; }

At least with the ideal radio I can run now the code

[levy]

I think this should rather be fixed in the radios. There's no reason to pass up a frame to the MAC that is completely unrelated to the given wireless technology.

[aarizaq]

The problem in this case is the ideal radio, with other radio models the bandwidth filters the frames

Real mac implementation can receive frames of other technologies, if they transmit in the same bandwidth, but the mac will discard the frame if they don't recognize the frame, it will be identified like bad format frame, the fields are incorrect and the CRC erroneous due to thy are in incorrect position.

[levy]

I respectuflly disagree for the following reason. In the real world, the 802.11 PHY can only receive a signal if it is a proper 802.11 signal with respect to its physical properties. In order for a PHY to receive a signal, the signal not only has to be in the required bandwidth, but it also has to have the required modulation, scrambling, interleaving, binary structure, and so on. All of these physical properties are used and checked by the PHY model. So even if we use a simplified unit disk radio model, we must make it so that it filters out all other signals. By the time a packet arrives at the MAC layer, it is guatanteed to have all those physical properties. But of course the CRC is indeed checked by the MAC.

In the latest INET version, there's an Ieee80211UnitDiskRadio (a 802.11 variant of the old ideal radio) that should be used with the 802.11 MAC if a unit disk radio is needed. The default UnitDiskRadio is simply not sufficient.

[aarizaq]

Sorry for no express with clarity, I am working with some sensor microcontroller now and mi mind was too focused in the implementation problems that I have suffered.

I was no thinking in 802.11, 802.11 radio should filter the frames that aren't according to the modulation standards and the modulation standard is quite complex that other soruce that is not wifi could use the same modulation. I was thinking in protocols like Bmac and similar that can use transceivers like cc1101. I have suffered some implementations with this type of transceivers and it was necessary to filter the packets received from other sources in the mac layer.

[levy]

Ah, ok, I see. In my first comment, I didn't mean to actually close this bug, because I think INET still doesn't filter the packets right in the PHY layer in all cases. So I would like to reopen this bug, because your original intention, namely mixing different wireless technologies, must be properly supported independently of how detailed the PHY simulation is. For example, the UnitDisk (with BMac) vs Ieee80211UnitDisk (with 802.11 MAC) case I think is not correct.

[aarizaq]

In this case, the solution that I would adopt, because I think that could be the easier to implement, no the most efficient. Is to include a field in the signal with the modulation type and in the radio module a parameter with the list of modulations that the radio will accept, the radio can send the packet to the upper layers if the modulation is in the list or delete if it is not in the list