Bugzilla – Bug 843
Most wifi examples change BeaconInterval to unrealistic values
Last modified: 2010-05-18 16:13:56 EDT
I had already argued in some bug report that the _default_ BeaconInterval should be 100ms. That is fixed. However, there seems to be an epidemic of examples (because each new wifi example copies from another wifi example) that modify this default value to 2.5 s: gjc@dark-tower:ns-3-dev$ grep BeaconInterval -r examples/ examples/mpi/third-distributed.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/simple-wifi-frame-aggregation.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/wifi-ap.py: "BeaconInterval", ns3.TimeValue(ns3.Seconds(2.5))) examples/wireless/wifi-wired-bridging.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/wifi-simple-infra.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/wifi-blockack.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/wifi-ap.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/wireless/mixed-wireless.py: "BeaconInterval", ns3.TimeValue(ns3.Seconds(2.5))) examples/wireless/mixed-wireless.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/tap/tap-wifi-dumbbell.cc: "BeaconInterval", TimeValue (Seconds (2.5))); examples/tutorial/third.cc: "BeaconInterval", TimeValue (Seconds (2.5))); Because MaxMissedBeacons is not also modified, the default value of 10 is used. This means that a STA will only notice it is no longer associated with its AP after 10 x 2.5 = 25 seconds. This is just wrong.
It's pedantry, but note that the Beacon Interval is always an integral number of TUs (1024 us) which actually makes 100 ms an invalid value. It would be more correct (and, indeed, representative of the real world) to use 102.4 ms. If the ns-3 Wi-Fi models ever cover the standard-defined Power Management support, then it may be necessary to enforce use of TU multiples for Beacon Intervals.
(In reply to comment #0) > I had already argued in some bug report that the _default_ BeaconInterval > should be 100ms. That is fixed. However, there seems to be an epidemic of > examples (because each new wifi example copies from another wifi example) that > modify this default value to 2.5 s: [...] > Because MaxMissedBeacons is not also modified, the default value of 10 is used. > This means that a STA will only notice it is no longer associated with its AP > after 10 x 2.5 = 25 seconds. This is just wrong. I agree to change this. (In reply to comment #1) > It's pedantry, but note that the Beacon Interval is always an integral number > of TUs (1024 us) which actually makes 100 ms an invalid value. It would be more > correct (and, indeed, representative of the real world) to use 102.4 ms. > > If the ns-3 Wi-Fi models ever cover the standard-defined Power Management > support, then it may be necessary to enforce use of TU multiples for Beacon > Intervals. The current code already implements the conversion to TUs when filling in the Beacon Interval field. That said, I do not agree in changing the BeaconInterval attribute of the various WifiMac implementation: TUs are a rather coarse granularity, and I see no reason to enforce that beacons are transmitted with a finer grained interval for whatever reason. After all, the actual time at which beacons are sent is already subject to variations due to the DCF procedure. So I think the current code is within what allowed by the standard. Of course, if you can find a section in the standard that says otherwise, I'll be happy to reconsider your proposal.
(In reply to comment #2) > The current code already implements the conversion to TUs when filling in the > Beacon Interval field. That said, I do not agree in changing the BeaconInterval > attribute of the various WifiMac implementation: TUs are a rather coarse > granularity, and I see no reason to enforce that beacons are transmitted with a > finer grained interval for whatever reason. After all, the actual time at which > beacons are sent is already subject to variations due to the DCF procedure. So > I think the current code is within what allowed by the standard. Of course, if > you can find a section in the standard that says otherwise, I'll be happy to > reconsider your proposal. Okay, having thought about it more I can that it would be useful to have Beacons queued for transmission with periodicity not a multiple of a TU as the standard requires (e.g., in modelling the effect of such a non-standard-conformant AP on STA power consumption). As such, I agree that the BeaconInterval attribute should remain in the existing format. I don't, however, see a good reason not to ensure that the current Wi-Fi examples are setting the attributes of the AP model in a manner that makes it standard-compliant. The standard is quite clear on the timing of Beacons transmitted by an AP (see Section 11.1.2.1 of IEEE 802.11-2007 - Beacon generation in infrastructure networks): - Beacons are queued for transmission (i.e., first presented to the DCF of the AP) at each Target Beacon Transmit Time (TBTT) ("At each TBTT, the AP shall schedule a Beacon frame as the next frame for transmission according to the medium access rules specified in Clause 9") - The first TBTT occurs when TSF is zero, and thereafter every dot11BeaconPeriod TUs ("Time zero is defined to be a TBTT with the Beacon frame being a DTIM and transmitted at the beginning of a CFP." and "The AP shall define the timing for the entire BSS by transmitting Beacon frames according to the dot11BeaconPeriod attribute within the AP. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart.") A corollary of the above is that the Timestamp field in each Beacon, modulo the beacon period in microseconds (dot11BeaconPeriod * 1024) represents the duration by which that beacon is delayed due to medium access contention, plus the duration between the start of the frame and the first bit of the Timestamp field (dependent only on Beacon transmit data rate).
Created attachment 870 [details] proposed fix Thanks for the pointer to the documentation and for the detailed description. I must admit that I was not aware of the degree of accuracy required by the standard for beacon timing. My understanding is that this accuracy is mostly important for PCF, HCCA and Power Saving, none of which is currently implemented in ns-3, so maybe that's why nobody cared so far. However, I agree it is better to fix it. I am attaching a proposed fix, let me know if you think that it correctly addresses the problem.
(In reply to comment #4) > Created an attachment (id=870) [details] > proposed fix Perhaps it is better to simply remove the modification of BeaconInterval from examples, to let them assume the default value? I don't see the point in showing how to change it, since it is rarely needed to be changed, if at all...
(In reply to comment #4) > I am attaching a proposed fix, let me know if you think that it correctly > addresses the problem. Insomuch as this fix ensures that all code within the Wi-Fi module of ns-3 configures Beacon Periods which are multiples of the TU, I am very happy with it. I tend to concur, however, with Gustavo's suggestion that the examples be left to assume the (sensible, with your proposed change) AP default, except where they specifically care about the Beacon Period (and, currently, I'm not sure there are any that fall into this category). I also can't help but wonder whether the Wi-Fi module should somewhere have defined a function or macro that makes construction of Times as multiple of the IEEE 802.11-defined TU a bit cleaner, e.g., "WifiTimeUnit (100)", instead of "Microseconds (102400)". Regrettably, the TimeUnit type has already been created for something entirely different.
(In reply to comment #6) > Insomuch as this fix ensures that all code within the Wi-Fi module of ns-3 > configures Beacon Periods which are multiples of the TU, I am very happy with > it. > > I tend to concur, however, with Gustavo's suggestion that the examples be left > to assume the (sensible, with your proposed change) AP default, except where > they specifically care about the Beacon Period (and, currently, I'm not sure > there are any that fall into this category). Ok I removed the Beacon parameters from the examples (all were using default values) and pushed the changes. changeset: 6309:8d46400b959e on ns-3-dev changeset: 114:d65f6632511a on ns-3-dev-ref-traces (In reply to comment #6) > I also can't help but wonder whether the Wi-Fi module should somewhere have > defined a function or macro that makes construction of Times as multiple of the > IEEE 802.11-defined TU a bit cleaner, e.g., "WifiTimeUnit (100)", instead of > "Microseconds (102400)". Regrettably, the TimeUnit type has already been > created for something entirely different. I agree that enforcing TUs helps to ensure that the user does the right thing, however it prevents to have a device that exhibits non-standard behavior, as you said in some earlier post. Anyway, I think this bug has been addressed satisfactorily enough, so I am closing it.
(In reply to comment #7) > I agree that enforcing TUs helps to ensure that the user does the right thing, > however it prevents to have a device that exhibits non-standard behavior, as > you said in some earlier post. I wasn't proposing that anything be enforced, but I was wondering out aloud whether it would be useful to supply some syntactic sugar for users who want to specify Times in TUs. The prototype of the function I'm suggesting would be something like this: Time WifiTimeUnits (uint64_t tus); ..., and would allow someone who actually wanted to specify a time(out?) of 39 (for example) TUs as "WifiTimeUnits (39)", rather than "Microseconds (39936)" (horrible) or "Microseconds (39 * 1024)" (still well short of clear). > Anyway, I think this bug has been addressed satisfactorily enough, so I am > closing it. Agreed. Nice work, thank you very much.