Bug 1065

Summary:	Include signal strength in PCAP trace of transmitted frames
Product:	ns-3	Reporter:	Dean Armstrong <deanarm>
Component:	wifi	Assignee:	Nicola Baldo <nicola>
Status:	RESOLVED INVALID
Severity:	enhancement	CC:	deanarm, ns-bugs
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All

Description Dean Armstrong 2011-02-28 06:27:57 UTC

The PromiscSnifferRx and PromiscSnifferTx trace sources on WifiPhy
objects allow generation of PCAP (with Radiotap header) traces as form
of simulation output. While the former includes signal and noise level
indications in the radiotap header associated with each traced frame,
the latter does not.

I'd like to argue that having the transmit trace include a signal
strength - specifically, the transmit power level - would be a useful
thing to do. I'd then point out that if we do this then we can save a
bit of duplicated code because we don't need both of the otherwise
identical PcapSniffRxEvent() and PcapSniffTxEvent() in
yans-wifi-helper.cc.

The change I'm proposing can be seen as changeset 6817:3c98f50788d5 in
http://code.nsnam.org/deanarm/ns-3-dev-wifi-spectrum

I'd appreciate comments on the proposed approach.

Comment 1 Nicola Baldo 2011-03-01 11:54:30 UTC

The current behavior was intended to model real devices, in particular the madwifi driver. At the time of development, the behavior of madwifi was that signal and noise were reported only for received frames, not for transmitted frames.

I don't know if the behavior I described is still the case now, either for madwifi or for other drivers. 

In general, I am reluctant to change the format of the radiotap/prism output in a manner that differs from what real devices do. This is because I think that the  most important use case for having radiotap/prism headers is to allow the reuse of pcap processing tools between ns-3 and testbeds.

Of course, I'll be happy to discuss eventual arguments in favor of the proposed change.

Comment 2 Nicola Baldo 2011-04-03 14:02:30 UTC

Since there have been no further comments over the last month, I am marking this bug as invalid. Feel free to reopen it if you think that further discussion is needed.