[Ns-bugs] [Bug 978] Consolidate Wi-Fi MAC high functionality

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=978





--- Comment #16 from Nicola Baldo <nbaldo at cttc.es>  2010-09-16 07:59:52 EDT ---

Hi Dean,

thank you for your reply. Some further comments below.

(In reply to comment #15)
> Logically, the WAVE architecture does indeed require distinct channel access
> functions for use on the Control and Service Channels, but it is significant
> that simultaneous operation on CCH and SCH does not occur - TDM is used. For
> this reason, I think it quite likely that practical implementations, in order
> to keep costs reasonable, will simple reconfigure the five 802.11-defined
> channel access functions at the same time as the necessary PHY channel switch
> is occurring.

I am not sure this would be good approach, because you would have to flush the
queues whenever you switch from CCH to SCH and vice-versa. 


> Another way to do it would be to use the EDCA queues that WifiMac provides to
> cater for one of the CCH or SCH, and simply instantiate another set of
> EdcaTxopN's in the derived class to cater for the other channel.

Ok this could work in practice.


> Either way, I am arguing that the proposed approach provides well for a
> forthcoming WAVE model.

I agree that it is possible to implement it, but frankly I don't like the way
it would be implemented, it seems to me that this way the WAVE device would be
implemented as an hack over existing code rather than with a clean and readable
design. (more details below)


> I don't think anything in the proposed WifiMac is likely to restrict options in
> a derived class; it is always possible, in principle, to ignore the
> infrastructure that the WifiMac base attempts to provide and go it alone.

Again I agree that it is possible, but I don't like it. For example, you might
end up with a WaveWifiMac which doesn't use at all the EDCA queues defined in
WifiMac, and which instead defines its own queues. I think this is detrimental
to code readability and maintainability.


> That said, I would note that there is only a certain amount of customisation
> one can undertake before we are no longer talking about a "Wi-Fi" (or even,
> IEEE 802.11-based) MAC. I expect that ability to customise is likely to be
> restricted by the logically lower-layer classes (e.g., MacLow, MacTx/RxMiddle,
> WifiPhy and derived classes) before the content of WifiMac causes problems.

I agree! In fact, the exact type and amount of restriction imposed by the
lower-layer classes is defined by the current abstract WifiMac interface. I
think that having such an abstract interface is good since it exactly tells you
how far you can go with customization. The more I think about it, the more I am
convinced that the one and only think I really don't like of your patch is that
you're throwing away that abstract interface. Let me stress that I am still
convinced that the rest of the patch is a very good contribution (code is
better organized, much less duplication, etc.). 

So, can we rescue the abstract WifiMac interface? Here is my proposal:

1) you leave the existing abstract WifiMac class as-is

2) you take the WifiMac class in your patch, rename it to RegularWifiMac (or
CommonWifiMac, or VanillaWifiMac... whatever), and make it inherit from the
abstract WifiMac

3) the rest of your patch stays as-is, you just need to make all the *WifiMac
classes inherit from the new RegularWifiMac instead of WifiMac 

4) Wave implementation could be done by having two RegularWifiMac instances,
one for SCH and one for CCH, contained in a wrapper class WaveWifiMac that
inherits directly from the abstract WifiMac

5) people that want to develop their own MAC can choose between inheriting from
RegularWifiMac (if they plan to reuse a lot of functionality), or inheriting
directly from WifiMac (if they need a highly customized solution).

What do you think?

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.