Bug 2412

Summary:	align WifiPhy frequency and channel number
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	wifi	Assignee:	sebastien.deronne
Status:	RESOLVED FIXED
Severity:	normal	CC:	ns-bugs
Priority:	P3
Version:	unspecified
Hardware:	All
OS:	All
See Also:	https://www.nsnam.org/bugzilla/show_bug.cgi?id=2270
Bug Depends on:	2452
Bug Blocks:	2400
Attachments:	suggested patch suggested patch revised patch

Description Tom Henderson 2016-05-17 19:59:26 UTC

Problem:  WifiPhy Set/GetFrequency and Set/GetChannelNumber are ill defined.

Frequency is being set to 2407 MHz for the 2.4 GHz band and 5000 MHz for the 5 GHz band, regardless of what channel number is being used.  Frequency is documented as trying to track the channel 'starting' frequency, but it is harder to define this than the center frequency.

Frequency and channel number are both attributes of YansWifiPhy, but they are related.  In general, it is difficult to have two attributes control a single underlying value because of static initialization order issues.

Proposal:
- make ChannelNumber attribute govern the setting of frequency also.
- make Frequency attribute gettable only (disable Set capability on the attribute)
- define Frequency to be the channel center frequency, instead of the starting frequency
- store the mapping of channel number to center frequency internally in some std::map containers

Users are then supposed to set 'ChannelNumber' attribute to change the channel and frequency, and if unset, the setting of the WifiPhyStandard will by default, configure 2.4 GHz Phys onto channel 1, and 5 GHz Phys onto channel 36 (exception:  802.11ac configures onto channel 42 by default)

Out of scope:
- this patch revealed that the mesh module (the MeshHelper) sets the ChannelNumber to invalid values (default 0).  I just patched this to make it workable for now, but more rework of mesh module to make it frequency agile could be the subject of a separate bug

- the static std::maps used to store the map of channel number to frequency could be more cleanly written with C++11 initializer lists; this can be redone once the patch to bug 2270 is merged.

- I started to try to move this code from YansWifiPhy to WifiPhy, but it started to get complicated, so I suggest that it could also be done in a more general refactoring at a later date

Comment 1 Tom Henderson 2016-05-17 20:01:07 UTC

Created attachment 2436 [details]
suggested patch

Comment 2 sebastien.deronne 2016-06-04 06:50:46 UTC

Tom, do you have some updates about the refactoring of your previous patch?

Comment 3 Tom Henderson 2016-06-06 13:10:34 UTC

Created attachment 2463 [details]
suggested patch

improved patch

Comment 4 Tom Henderson 2016-06-06 13:16:58 UTC

I uploaded a better patch for this issue.  The main change is that (center) Frequency and ChannelWidth are now proposed as the attributes that will be really used by the model code, and ChannelNumber and WifiHelper::SetStandard are more like convenience attributes/methods to configure these things.

The basic idea is that ChannelNumber and Frequency are related; by changing one, the other value is changed.  ChannelNumber must be set to a value defined by the standard in effect (e.g. setting channel number to 14 for 802.11ac is not a valid combination).  Users can define their own channel numbers at runtime for later use in their programs.  However, Frequency and ChannelWidth are what ultimately get used by the underlying model.

I've attached a complete patch; the individual commits can be viewed (and commented on, if you prefer) here:

https://github.com/tomhenderson/ns-3-dev-git/commits/ns-3-dev-bug-2412

The first commit is the patch for issue 2270 (which will be committed shortly).  The remaining 8 commits are proposed for ns-3-dev such as laid out in the git repository.

From my perspective, this is ready to merge (test, example, documentation completed) unless any comments are received.

Comment 5 sebastien.deronne 2016-06-06 14:46:02 UTC

I've just quickly looked and I don't have comments so far.

Comment 6 sebastien.deronne 2016-07-12 15:19:43 UTC

Tom to push the patch

Comment 7 Tom Henderson 2016-07-15 20:01:11 UTC

Created attachment 2498 [details]
revised patch

Fixed issue reported by N. Sapoval regarding the fact that the WifiPhyStandard is often set later in the configuration than the ChannelNumber, so some consistency checking must be deferred.  

Also updates RELEASE_NOTES and CHANGES.html.

Current patch depends on patch to bug 2452 (Object::IsInitialized ()).

Comment 8 sebastien.deronne 2016-07-17 15:51:56 UTC

Tom, I did not test, but the patch looks ok.

Comment 9 Tom Henderson 2016-07-21 01:43:38 UTC

pushed in changeset 12215:ffa8e03e95f4