Transmission time in vehicular scenario (802.11p)

110 views
Skip to first unread message

Alejandro Jimenez

unread,
Aug 27, 2015, 4:00:25 AM8/27/15
to ns-3-users
Dear experts,

This might be a fundamental question and not a programming one. I am using the simple 802.11p example to test different transmission rates. OfdmRate6MbpsBW10MHz is the default one and I used a SeqTsHeader to record the transmission time of a single packet. I am attaching the testing file.

The received packet size is 988 bytes long so I was expecting 988x8/6Mbps = 1.3173 ms as transmission time. Instead I am getting roughly 2.8888 ms.

As I said, perhaps I am not setting up a parameter correctly or it might be that I am not understanding this wireless technology correctly.

Thank you in advance for the comments.

Alejandro.
wave-simple-80211p.cc

Konstantinos

unread,
Aug 27, 2015, 4:10:56 AM8/27/15
to ns-3-users
Hi,

You are not sending 988bytes. You are sending 1000+UDP+IP+MAC+LLC header. Your application payload is 988+12 for the SeqTs header.
In addition, you have not accounted the backoff time. Even though you only have one node transmitting, there will be a minimum backof DIFS time.

You can check the PCAP files that recorded the complete packet after backoff, to see more information regarding the headers and also the timings since you only work with small number of packets/nodes.

Alejandro Jimenez

unread,
Aug 27, 2015, 4:21:22 AM8/27/15
to ns-3-users
As always: thank you for your reply and for sharing the knowledge.

Alejandro Jimenez

unread,
Nov 20, 2015, 11:41:06 AM11/20/15
to ns-3-users
Dear Konstantinos,

Sorry for going back to this post but some doubts arose at this point of my research.

You explained me that the end-to-end delay that I obtained is based on the headers attached to my packet. I did some further checks with the PCAP files (attached) as you suggested and found that the headers add in total 148 bytes, so my complete frame should be 1000 bytes (payload) + 148 bytes (headers). From that, I deduce that the transmission time of a frame would be: (1148 * 8) / (6 * 1024 * 1024) = 1.45897 ms

This is still very small compared to the measured TX time via NS3: 2.88802 ms

On the other hand, I looked into the state timers of YansWifiPhy with the following line and I obtained the same value 2.888 ms for TX time.

Config::ConnectWithoutContext ("/NodeList/0/DeviceList/*/$ns3::WifiNetDevice/Phy/$ns3::YansWifiPhy/State/State",MakeCallback (&StateCallback));

I am still trying to figure out why the TX time is so large if I have analyzed all the headers involved. You mentioned that the backoff times could influence this behaviour.

Thank you in advance for any comment on this. I am attaching an updated file.

Regards,

Alejandro.






On Thursday, August 27, 2015 at 10:10:56 AM UTC+2, Konstantinos wrote:
wave-simple-80211p-2-0.pcap
wave-simple-80211p_2.cc

Konstantinos

unread,
Nov 20, 2015, 12:07:29 PM11/20/15
to ns-3-users
The PHY trace source that you monitor and those reported in the PCAP since they are obtained from the PHY, take into account the "random" backoff time. 
However, in your calculation, you do not consider that. 

Alejandro Jimenez

unread,
Nov 21, 2015, 4:47:57 AM11/21/15
to ns-3-...@googlegroups.com
Thanks Konstantinos.

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/1sIoQtrUVO4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages