implement WAVE 1609.4 without some important features

This code is part of Junling Bu's GSoC midterm review.

http://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

This patch is to complete 1609.4-2010 standard based on 802.11p to deal with multiple channels operation for vehicular environment. It would build on the previous patch shown here:

https://codereview.appspot.com/11685043/

The implemented features are 1) provide a NetDevice with special APIs, 2) allow users to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research, 4) provide two simple channel access assignment mechanisms.

Because of time limit of this midterm review, some important features are not finished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not
defined in the standard will need more consideration and tests.

Further study is to 1) verify the correctness of the implementation, 2) implement some examples to study performance and impact of multiple channels operation.

Some high standards like 1609.3 and mobility model for vehicular environment are out of scope.

[Nicola Baldo, 2013-07-29 10:50:04]

A few more comments on this other patchset.

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst
File src/wave/doc/wave.rst (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode282
src/wave/doc/wave.rst:282: NqosWave80211pMacHelper wifi80211pMac =
NqosWaveMacHelper::Default();
I find it misleading that a class type named "NqosWave80211pMacHelper" is used
for a non-WAVE setup. Could you name the class to something more generic?

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode290
src/wave/doc/wave.rst:290: do not support NqosWaveMacHelper because of 1609.4's
requirement for Qos.
so, if WAVE does not support NqosWaveMacHelper, then NqosWaveMacHelper is
clearly misnamed

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device.h
File src/wave/model/wave-net-device.h (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device...
src/wave/model/wave-net-device.h:190: * However WaveNetDevice inherits from
NetDevice instead of  WifiNetDevice
I think no one expected that WaveNetDevice inherited from WifiNetDevice, so it
is ok just to mention that WaveNetDevice and WifiNetDevice are different with
the differences that you mentioned.

I mean, you don't have to excuse yourself for not inheriting from WifiNetDevice
:-)

[Tom Henderson, 2013-07-29 13:06:42]

On 2013/07/29 10:50:04, Nicola Baldo wrote:
> A few more comments on this other patchset.
> 
> https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst
> File src/wave/doc/wave.rst (right):
> 
>
https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode282
> src/wave/doc/wave.rst:282: NqosWave80211pMacHelper wifi80211pMac =
> NqosWaveMacHelper::Default();
> I find it misleading that a class type named "NqosWave80211pMacHelper" is used
> for a non-WAVE setup. Could you name the class to something more generic?
> 
>
https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode290
> src/wave/doc/wave.rst:290: do not support NqosWaveMacHelper because of
1609.4's
> requirement for Qos.
> so, if WAVE does not support NqosWaveMacHelper, then NqosWaveMacHelper is
> clearly misnamed
> 
>
https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device.h
> File src/wave/model/wave-net-device.h (right):
> 
>
https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device...
> src/wave/model/wave-net-device.h:190: * However WaveNetDevice inherits from
> NetDevice instead of  WifiNetDevice
> I think no one expected that WaveNetDevice inherited from WifiNetDevice, so it
> is ok just to mention that WaveNetDevice and WifiNetDevice are different with
> the differences that you mentioned.
> 
> I mean, you don't have to excuse yourself for not inheriting from
WifiNetDevice
> :-)

I think it is an open question (for me) whether to inherit from WifiNetDevice--
by not inheriting, WaveNetDevice has to replicate a lot of code.  The main
difference seems to be supporting multiple OcbWifiMacs on one WifiPhy, does this
require a new net device type, or variations on one or a few helpers to put it
together?

[Junling Bu, 2013-07-30 16:49:10]

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst
File src/wave/doc/wave.rst (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode290
src/wave/doc/wave.rst:290: do not support NqosWaveMacHelper because of 1609.4's
requirement for Qos.
On 2013/07/29 10:50:04, Nicola Baldo wrote:
> so, if WAVE does not support NqosWaveMacHelper, then NqosWaveMacHelper is
> clearly misnamed 
Yes, I want to provide two types of NetDevice, one is only WifiNetDevice object
that support 802.11p, and another is WaveNetDevice object that will support WAVE
architecture. The first can use either qos or nqos, but the second should be qos
because of IEEE 1609.4 needs priority. I know NqosWaveMacHelper is not a
suitable name, but the question is I don't know how to use a better
implementation to meet the requirement. I think changing the name of
NqosWaveMacHelper is still not good. My implementation now is WaveMacHelper base
class, QosWaveMacHelper and NqosWaveMacHelper inherit from the base class, a
802.11p device can use either QosWaveMacHelper or NqosWifiMacHelper because the
parameter of 802.11p device helper is WaveMacHelper, a wave device can only set
QosWaveMacHelper because the parameter of wave device helper is QosWaveMacHelper
and I add comments to remind users that we shall support qos here. So Nicola,
how can I reflector my implementation? 

Another issue you talked in ns-3-reviews is about wave-helper.
Actually I know here are many duplicate codes. The reason is : 1) SetType
(std::string type,...) of WifiMac helpers allow users to set high mac class like
adhoc, but for 802.11p I think we should not allow users to do this, he should
use OcbWifiMac only, 2) still considering flexibility, I am afraid that if we
inherit from wifi helper class, when people use helper, he can easily make
mistake that use WifiMacHelper create a AP mac and add it into WaveHelper, the
only way to prevent is to use RTTI of c++ to check class type. Since as you
suggested, my thought is  1)add virtual to the method of wifi helpers, 2)
refactor the QosWaveMac, NqosWaveMac and WaveMac to inherit from wifi helper
classes, 3) add check in the method to protect user not make mistake. How do you
think?

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device.h
File src/wave/model/wave-net-device.h (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device...
src/wave/model/wave-net-device.h:190: * However WaveNetDevice inherits from
NetDevice instead of  WifiNetDevice
On 2013/07/29 10:50:04, Nicola Baldo wrote:
> I think no one expected that WaveNetDevice inherited from WifiNetDevice, so it
> is ok just to mention that WaveNetDevice and WifiNetDevice are different with
> the differences that you mentioned.
> 
> I mean, you don't have to excuse yourself for not inheriting from
WifiNetDevice
> :-)
I have asked myself many times which is better to inherit from WifiNetDevice or
not. But the answer is hard for me. If inherit from WifiNetDevice, we could
avoid replicating a lot of code, then we should add some method to support
multiple channel operation, overwrite some method that is not suitable, and we
need to overwrite WifiNetDevice::SetMac method to construct some MAC objects (I
don't know how to achieve that, maybe add operate= in WifiMac, but it seems not
a good way), and since people uses this device for WAVE architecture, a device
type that is a NetDevice rather than WifiNetDevice could be more understandable.
So now I prefer to inheriting from NetDevice, off course, maybe I will change to
inherit from WifiNetDevice if it seems more reasonable.