Bugzilla – Bug 917
TX VECTOR to allow per-packet tx parameters
Last modified: 2015-03-31 13:45:57 EDT
Created attachment 874 [details] Patch solving the bug The transmission power of a wifi node cannot be changed at runtime. Rationale: By looking at YansWifiPhy::GetPowerDbm (devices/wifi/yans-wifi-phy.cc:725 of release 3.8), it seems that one only needs to specify a proper power level in order to change the transmission power. However, GetPowerDbm is called by YansWifiPhy::SendPacket (yans-wifi-phy.cc:513), which is called, in turn, by MacLow::ForwardDown (devices/wifi/mac-low.cc:1128), in which the transmission power level is hard-coded to 0. The offending line is reported hereunder: m_phy->SendPacket (packet, txMode, WIFI_PREAMBLE_LONG, 0); I have a attached a simple patch, which solves such issue by introducing two new functions in the YansWifiPhy class, namely [GS]etTxPowerLevel.
A minor note: the patch is based on the 3.8 release (which is not present in the listbox).
(In reply to comment #1) > A minor note: the patch is based on the 3.8 release (which is not present in > the listbox). Updated.
Hi Christian, sorry for the late reply. I agree there is a problem with the setting of the transmission power, so thanks for your effort in trying to solve it. I think that specifying the power in mac-low.cc upon calling m_phy->SendPacket() makes sense if we want to do per-packet tx power adaptation. However, your patch still uses a fixed tx power attribute that belongs to the phy. So I would propose either of the following: 1) stick with a fixed tx power attribute belonging to the phy. This means applying your patch, but then remove the txpower parameter from YansWifiPhy::SendPacket() and the related code from mac-low.cc 2) introduce as an enhancement the possibility of doing per-packet tx power adaptation. In this case, I think the right way is to handle it by means of WifiRemoteStationManager, similar to the way that WifiMode is selected on a per-packet basis. I mean, adding to WifiRemoteStationManager methods of the type GetXxxxTxPower(), where Xxxx is one of {Data, Rts, Cts, Ack}. If anybody volunteers to do 2), that would be great (though I think it's a big effort, mainly due to the fact that we already have many WifiRemoteStationManager impelmentations, and they all take care of the rate only). Otherwise, I would just go for 1) which is the minimum effort solution to fix this bug.
Nicola, how does this relate to the goal of aligning the phy/mac interface between WifiMac and SpectrumPhy? I see that spectrum devices do not pass a transmit power across the boundary; e.g. HalfDuplexIdealPhy::StartTx (Ptr<Packet> p)
(In reply to comment #4) > Nicola, how does this relate to the goal of aligning the phy/mac interface > between WifiMac and SpectrumPhy? I see that spectrum devices do not pass a > transmit power across the boundary; e.g. > HalfDuplexIdealPhy::StartTx (Ptr<Packet> p) I think that it does not matter: for example, the idea that I had in mind for interfacing SpectrumPhy with WifiMac was to interpose a dedicated implementation of WifiPhy that used the phy/mac interface to talk to SpectrumPhy. This way, the WifiMac/WifiPhy interface does not need to be changed. This makes me think that "phy/mac interface" is a bit of a misnomer, we should rather call it the "phy/* interface" or "generic phy interface". Also, I think it would not be reasonable to align WifiMac/WifiPhy to phy/mac: the former interface is too specialized.
(In reply to comment #5) > (In reply to comment #4) > > Nicola, how does this relate to the goal of aligning the phy/mac interface > > between WifiMac and SpectrumPhy? I see that spectrum devices do not pass a > > transmit power across the boundary; e.g. > > HalfDuplexIdealPhy::StartTx (Ptr<Packet> p) > > I think that it does not matter: for example, the idea that I had in mind for > interfacing SpectrumPhy with WifiMac was to interpose a dedicated > implementation of WifiPhy that used the phy/mac interface to talk to > SpectrumPhy. This way, the WifiMac/WifiPhy interface does not need to be > changed. The issue I see is that if we retain the per-packet transmit power setting, spectrum Phy will need to handle it properly. If the underlying SpectrumPhy models that will be bolted to this convergence layer can handle per-packet txPower settings, then I think it won't matter either way.
Gary pointed out some other background information for this issue. In MadWifi, the HAL interface supports this per-packet tx power adjustment. http://madwifi-project.org/browser/madwifi/branches/madwifi-0.9.4/ath/if_ath.c (line 2420) If we want to keep some alignment with the ath/HAL interface, we may even want to push this power value up the stack even further to the WifiMac layer, such as when it is enqueued to DcaTxop from WifiMac.
(In reply to comment #6) > The issue I see is that if we retain the per-packet transmit power setting, > spectrum Phy will need to handle it properly. If the underlying SpectrumPhy > models that will be bolted to this convergence layer can handle per-packet > txPower settings, then I think it won't matter either way. Even if we stick with the txpower parameter in WifiPhy::SendPacket(), there would be no problem: it could be easily handled by implementing SpectrumWifiPhy::SendPacket() so that it calls SpectrumPhy::SetTxPowerSpectralDensity() before SpectrumPhy::StartTransmission(). I think this approach resembles the division of the PHY into the PLCP and PMD sublayers as specified by the standard - see Figure 15-6 "Transmit PLCP" in IEEE Std. 802.11-2007. (In reply to comment #7) > Gary pointed out some other background information for this issue. In MadWifi, > the HAL interface supports this per-packet tx power adjustment. > > http://madwifi-project.org/browser/madwifi/branches/madwifi-0.9.4/ath/if_ath.c > (line 2420) > > If we want to keep some alignment with the ath/HAL interface, we may even want > to push this power value up the stack even further to the WifiMac layer, such > as when it is enqueued to DcaTxop from WifiMac. I wouldn't do this, it enforces per-MSDU tx power setting, while somebody might be interested in per-MPDU tx power setting. In other words, it's low latency vs high latency power control (using WifiManager terminology). I would be fine if somebody implements a high latency approach only if it does not prevent other people from implementing a low-latency approach.
> I wouldn't do this, it enforces per-MSDU tx power setting, while somebody might > be interested in per-MPDU tx power setting. In other words, it's low latency vs > high latency power control (using WifiManager terminology). I would be fine if > somebody implements a high latency approach only if it does not prevent other > people from implementing a low-latency approach. I don't think per packet tx power setting will impact on MAC latency modeling. The device driver prepares for the tx descriptor for each packet anyway before it gives to NIC HAL. The setting is in the same chunk of memory that is assoicated with the tx frame. It seems to me that this API does not matter with latency in real implementation.
(In reply to comment #9) > I don't think per packet tx power setting will impact on MAC latency modeling. I meant the other way around: the MAC latency model impacts how the per-packet tx power setting works. > The device driver prepares for the tx descriptor for each packet anyway before > it gives to NIC HAL. The setting is in the same chunk of memory that is > assoicated with the tx frame. It seems to me that this API does not matter with > latency in real implementation. This is a high latency API, because the driver cannot modify the TX power between retransmission attempts. See how "high latency" and "low latency" are defined in Mathieu's paper [1] in the context of rate adaptation. [1] Mathieu Lacage, Mohammad Hossein Manshaei, Thierry Turletti "IEEE 802.11 rate adaptation: a practical approach" http://portal.acm.org/citation.cfm?id=1023687
Created attachment 944 [details] simple txPowerLevel attribute fix this is the solution 1) that I mentioned in my first post: - put a (uint) power level attribute in YansWifiPhy - remove the power level setting from the WifiPhy/MacLow interface good points: - simple - makes sense since we don't have any tx power control scheme for now (and I don't think anybody will actually implement it in the foreseeable future). bad points: - power level attr is not really user-friendly, and quantizing the tx power into levels does not make sense if we don't have power control.
Created attachment 945 [details] double TxPower attribute in YansWifiPhy similar to 1), but we use a double TxPower attribute instead. This means we remove all the code related to the linear quantization of the power in YansWifiPhy, which in my opinion does not make much sense (especially if we don't have tx power control) pros: + much more user friendly + code is simpler, easier to read and to maintain cons: - no txpower setting in Phy/Mac interface, if you care about aligning interfaces with the standard and with real devices (note that tx power control could still be implemented by changing the TxPower attribute before transmission)
Created attachment 946 [details] handle TxPowerLevel via WifiManagers, adding dedicated methods This is solution 2) implemented in the least invasive way. (patch is not complete, it lacks all the necessary modifications to mac-low, for instance. I attach it just for completeness) pros: - supports tx power adaptation cons: - I think if people do power adaptation, they'll want to do it jointly with rate adaptation. This patch has separate interfaces for power and rate control, so implementing joint optimization schemes is not straightforward.
Created attachment 947 [details] TxVector patch this patch introduces the concept of TxVector mutuated from the standard. TxVector is a struct which is to be passed to the PHY in order to define the parameters which are to be used for a transmission. See IEEE 802.11-2007 15.2.6 "Transmit PLCP", * and also 15.4.4.2 "PMD_SAP peer-to-peer service primitive parameters". pros: - supports tx power adaptation - implements low latency and high latency correctly - makes it easy to do joint tx power and rate adaptation cons: - very invasive patch
I think we need time to discuss which is the most desirable approach, and to refine the fix for this bug based on the outcome of the discussion. So I propose to defer this bug to the next release cycle.
> > > The device driver prepares for the tx descriptor for each packet anyway before > > it gives to NIC HAL. The setting is in the same chunk of memory that is > > assoicated with the tx frame. It seems to me that this API does not matter with > > latency in real implementation. > > This is a high latency API, because the driver cannot modify the TX power > between retransmission attempts. See how "high latency" and "low latency" are > defined in Mathieu's paper [1] in the context of rate adaptation. > > > [1] Mathieu Lacage, Mohammad Hossein Manshaei, Thierry Turletti > "IEEE 802.11 rate adaptation: a practical approach" > http://portal.acm.org/citation.cfm?id=1023687 Thanks for the paper. It seems to me that high latency systems dominate the market, right?
(In reply to comment #16) > > Thanks for the paper. It seems to me that high latency systems dominate the > market, right? To my knowledge, yes. However, there are experimental devices that are low latency, for example calradio: http://calradio.calit2.net/calradio1.htm
(In reply to comment #0) > The transmission power of a wifi node cannot be changed at runtime. > actually this is not true: you can set a transmission power value X of your choice just by setting both the TxPowerStart and the TxPowerEnd attributes of YansWifiPhy to the same value X. That considered, what is left of this bug is that the current TX power handling needs to be improved. I am marking this bug as enhancement and lowering priority accordingly.
http://mailman.isi.edu/pipermail/ns-developers/2010-August/008309.html http://mailman.isi.edu/pipermail/ns-developers/2010-September/008315.html http://mailman.isi.edu/pipermail/ns-developers/2010-September/008325.html So in the end the preferred approach is to adopt the TX VECTOR.
This was eventually implemented, see src/wifi/model/wifi-tx-vector.h