http://codereview.appspot.com/91057/diff/1/3
File src/devices/wifi/yans-wifi-phy.cc (right):

http://codereview.appspot.com/91057/diff/1/3#newcode313
Line 313: Simulator::Schedule (m_channelSwitchDelay,
&YansWifiPhy::DoSetChannelId, this, nch);
Good to see that you model the channel switching delay. However, with
this implementation the PHY will be still functional when switching
channel, and also a packet whose transmission will be started just prior
to the execution of the channel switch will still be performed
correctly. In reality, a significant portion of the channel switch time
is due to the oscillator in the RF stage moving to the new frequency.
This will likely disrupt any ongoing TX/RX. I think we should model this
feature, otherwise it does not make sense to model the channel switch
time at all.

http://codereview.appspot.com/91057/diff/1/3#newcode495
Line 495:
It would be good to add also Configure80211gParameters(), which will use
80211a modes but in the 2.4 GHz band.
We might also consider having Configure80211bgParameters(), which would
work in the 2.4 GHz band with both a and b modes.

http://codereview.appspot.com/91057/diff/1/4
File src/devices/wifi/yans-wifi-phy.h (right):

http://codereview.appspot.com/91057/diff/1/4#newcode75
Line 75: *
How do we handle devices which can switch between the 2.4 GHz and the 5
GHz band? Do we need to call Configure80211a/b/g expicitly every time?

http://codereview.appspot.com/91057/diff/1/4#newcode81
Line 81: void SetFrequencyChannel (uint16_t id);
I think the name SetFrequencyChannel() is not very intuitive.
Why not call these "SetChannelNumber()", "GetChannelNumber()" and
"GetChannelFrequencyMHz()"?

Furthermore, I wonder if some of these methods can be moved to
WifiPhy(), so that we can have an interface for handling multiple
channels which is uniform across different WifiPhy impelmentations.

http://codereview.appspot.com/91057/diff/1/4#newcode82
Line 82: /// Return current channel ID, see SetChannelId()
reference to non-existent method SetChannelId()