[ns] Wireless LAN throughput

[Marek Laskowski]

Dave, thanks for the response, I think this is the first time this question 
has been answered so completely.  Perhaps your response should be mailed out 
every day since this question (or a variant) is asked almost daily, sometimes 
twice heha.

-----Original Message-----

Date: Fri, 23 Jan 2004 03:49:14 -0500
From: "David Holmer" <dholmer at jhu.edu>
Subject: RE: [ns] Wireless LAN throughput
To: <ns-users at ISI.EDU>
Cc: 'Chetan Kumar S' <chetan.kumar at wipro.com>
Message-ID: <004301c3e18d$c89a9c80$d164a8c0 at Mercury>
Content-Type: text/plain;       charset="us-ascii"

Chetan S,

Your simulations experimenting with the achievable throughput in NS are
indeed accurate. Many of the reasons for this as have been pointed out
by others already, but I thought I'd post some more complete information
(from some prior work I've done in the area). The effect of lower
efficiency for higher bit rates can be predicted by looking at the
details of 802.11b standard (see calculations below).

A few interesting observations from these calculations can be made. One
is that if you look at the calculations below they agree closely with
your NS2 simulations (and with experiments we have conducted with real
cards). As many people have pointed out, the RTS CTS and ACK control
frames add overhead to the frame transmission (lowering the effective
throughput). However the vast majority of overhead from sending these
frames is because of the physical preamble and header, not the data
contents of these packets. Sending them at a higher rate will not
significantly shorten the amount of time these control frames take. The
preamble must be a fixed length because it is used by the hardware for
bit synchronization. The short preamble option uses a shorter training
sequence and sends the phy header bytes at 2 Mbps (but supporting this
feature requires hardware support). Also the expected contention back
off time of 310 usec on average is a significant factor that reduces the
throughput.

Basically, the end result is that the 802.11b protocol has a large per
packet overhead that is mostly fixed. As a result, higher rates and
smaller packet sizes have drastically reduced efficiency as the relative
time spent on this per-packet overhead can dominate.

David Holmer
www.cnds.jhu.edu/archipelago/



192 usec for phy preamble + phy header (long header mode)

28 bytes mac header

20 bytes IP header

8 bytes UDP header
or
20 bytes TCP header

1500 byte MTU (ethernet friendly) =
1460 byte TCP data
1472 byte UDP data

RTS = 20 bytes
CTS = 14 bytes
ACK = 14 bytes

SIFS = 10 usec
DIFS = 40 usec
Slot = 20 usec
CWmin = 31


Single frame duration (usec) =
DIFS(40) + expected CW(15.5*20) + RTS(352) + SIFS(10) + CTS(304) +
SIFS(10) + DATA( 192 + (28 + data)*8/rate ) + SIFS(10) + ACK( 192 +
112/rate)
= 1100 + expected CW + 8*(28+data)/rate + 112/rate
= 1410 + (56+data)*8/rate

UDP (1472 bytes):
rate  time   speed  int  data  over
11.0   2533  4.649   5   1070  1463
 5.5   3654  3.223   7   2142  1512
 2.0   7578  1.554  14   5888  1690
 1.0  13746  0.857  25  11776  1970

UDP (1000 bytes):
rate  time   speed
11.0   2198  3.640
 5.5   2987  2.678
 2.0   5746  1.392
 1.0  10082  0.793