Bugzilla – Bug 1971
802.11n at 2.4 GHz should include a signal extension duration
Last modified: 2014-10-29 21:20:00 EDT
Created attachment 1870 [details] Patch Similarly to 802.11g, 802.11n standard specifies that a packet should be followed by a period of no transmission of 6 µs (= signal extension) when working at 2.4 GHz. To do so, it is required to check the working frequency in WifiPhy. You can find the proposed patch in attachment.
Sebastien, when I test this patch (after applying patches for 1968 and 1970), I get the following error; can you look into it? In file included from ../src/wifi/model/wifi-phy.cc:21:0: ../src/wifi/model/wifi-phy.h: In static member function ‘static double ns3::WifiPhy::GetPayloadDurationMicroSeconds(uint32_t, ns3::WifiTxVector)’: ../src/wifi/model/wifi-phy.h:1164:10: error: invalid use of member ‘ns3::WifiPhy::m_channelStartingFrequency’ in static member function double m_channelStartingFrequency; //!< Standard-dependent center frequency of 0-th channel in MHz ^ ../src/wifi/model/wifi-phy.cc:423:13: error: from this location if (m_channelStartingFrequency>=2400 && m_channelStartingFrequency<=2500) ^ In file included from ../src/wifi/model/wifi-phy.cc:21:0: ../src/wifi/model/wifi-phy.h:1164:10: error: invalid use of member ‘ns3::WifiPhy::m_channelStartingFrequency’ in static member function double m_channelStartingFrequency; //!< Standard-dependent center frequency of 0-th channel in MHz ^ ../src/wifi/model/wifi-phy.cc:423:49: error: from this location if (m_channelStartingFrequency>=2400 && m_channelStartingFrequency<=2500) ^
OK Tom, I'll look at that this weekend. I'll post a new patch based on the upgraded ns-3-dev repo.
Tom, there are two solutions to solve this problem: 1. We no more use static functions for CalculateTxDuration and for GetPayloadDurationMicroSeconds (defined in WifiPhy.h) 2. We add an argument in CalculateTxDuration and for GetPayloadDurationMicroSeconds to indicate the operating frequency. In my initial code, I used the first solution (that I accidentally forgot to include in the patch, which explains the obtained error). But I think the second solution is maybe more appropriate. What is your opinion?
(In reply to sebastien.deronne from comment #3) > Tom, there are two solutions to solve this problem: > > 1. We no more use static functions for CalculateTxDuration and for > GetPayloadDurationMicroSeconds (defined in WifiPhy.h) > > 2. We add an argument in CalculateTxDuration and for > GetPayloadDurationMicroSeconds to indicate the operating frequency. > > In my initial code, I used the first solution (that I accidentally forgot to > include in the patch, which explains the obtained error). But I think the > second solution is maybe more appropriate. > > What is your opinion? It seems to me that the second solution is more in keeping with the overall design to avoid private members in the base class (other than trace sources).
Created attachment 1909 [details] patch v2
Tom, I attached the new patch which addresses this issue using the second solution.
(In reply to sebastien.deronne from comment #6) > Tom, I attached the new patch which addresses this issue using the second > solution. Looks fine to me; I'll reschedule applying this to next week to give opportunity for others to comment on the API change that cuts across modules.
I pushed the v2 patch in changeset 11041:f353014f08e9 with a couple of changes: - added a bit of doxygen for new parameters - the test devices-wifi-tx-duration was extended to cover the new signal durations