[Ns-developers] tag rework for next release

Timo Bingmann timo.bingmann at student.kit.edu
Thu Mar 26 05:26:29 PDT 2009


On Thursday 26 March 2009 13:01:11 Nicola Baldo wrote:
> Hi,
> 
> 
> >> Are the new "packet tags" suitable for handling PHY layer metadata? I am 
> >> thinking of all the parameters which are currently passed as parameters 
> >> to WifiPhy::SendPacket(). Can we put those parameters in a packet tag 
> >> instead?
> > 
> > You could, but really, I can't see why you would do this. How would
> > hiding all the parameters be an improvement over making them explicit ?
> > 
> 
> I am trying to develop a technology-independent channel. Passing 
> explicitly to the channel parameters such as WifiMode and WifiPreamble 
> make the channel technology-specific, and I think that the channel has 
> no real reason to be technology-specific. Only the PHY needs that 
> information, that's why I like the idea of not letting it mess up the 
> API between Channel and PHY.
> 
> By the way, if we had a PHY header as per the 802.11 standard, then we 
> wouldn't need to pass WifiMode and WifiPreamble explicitly.
> 
> Nicola

Hello guys,

I've had similar thoughts before:
virtual void SendPacket (Ptr<const Packet> packet, WifiMode mode, enum WifiPreamble preamble, uint8_t txPowerLevel) = 0;

just doesnt look right, because it is very 802.11 specific, and ugly at best. This writing out of parameters continues further in the WifiPhy interfaces:
  typedef Callback<void,Ptr<Packet>, double, WifiMode, enum WifiPreamble> SyncOkCallback;
And culminates in
YansWifiPhy::StartReceivePacket (Ptr<Packet> packet, double rxPowerDbm, WifiMode txMode, enum WifiPreamble preamble)

First observation: WifiPhy is (supposed to be) independent of a PHY, but the SendPacket is not. I believe we need an abstract class
class WifiPhySendParameters {};
class YansWifiPhySendParameters : public WifiPhySendParameters { WifiMode mode; int powerLevel; };

virtual void SendPacket (Ptr<const Packet> packet, const WifiPhySendParameters& params) = 0;

However that would lead to a dynamic_cast<> somewhere.
The alternative is to use a packet Tag similar to the SendParameters above. However I guess the non-Tag is better, because  only the MAC layer should set the parameters, and not upper layer.

A related issue is then how to pass "WifiPhyReceiveParameters" back upwards to MacLow and company. I have experimented in my wifiex repository with a "WifiPhyTag", which contains all send and receive parameters a packet gets as it travels through the PHY. It could also be used to specify SendParameters as above.

Base idea was to derive WifiPhyTag for different PHYs and each can add data specific to it's calculations.
However I myself have some doubts as to whether this structure actually deserves to be a Tag, and not just a simple refcounted object passed between functions.

Big highlight of the WifiPhyTag is the simple signature of trace callbacks:
PhyRxOkTrace (std::string context, Ptr<const Packet> packet, Ptr<const WifiPhyTag> phytag)
{
  std::cout << "snr: " << phytag.GetRxSnrDb() << "dB, phytag={" << *phytag << "};\n";
}

Changeset of WifiPhyTag is 
http://code.nsnam.org/timob/ns-3-wifiex/rev/90cc8f2ed1e8
However reading WifiPhy.h is easier.
http://code.nsnam.org/timob/ns-3-wifiex/file/90cc8f2ed1e8/src/devices/wifi/wifi-phy.h

So any ideas on these interfacing issues?

Greetings
Timo


More information about the Ns-developers mailing list