802.11n adhoc broadcast data rate slowdown

[Richard Thompson]

ns-3 version 3.25

I have a simulation that transmits data from a source to a sink at regular intervals.

    source --> sink

Using 802.11n, it iterates through guard intervals and MCS and measures the throughput.

----------------------------------------------------------------------
When I specify an address on line 95,

    UdpClientHelper myClient (wifiNodeInterface.GetAddress (1), 9999);

the throughput looks like as it should:

    MCS value        short GI        Throughput
    0                            0            3.4888 Mbit/s
    0                            1            3.8688 Mbit/s
    1                            0            6.7688 Mbit/s
    1                            1            7.4872 Mbit/s
    2                            0            9.7136 Mbit/s
    2                            1            10.6192 Mbit/s
    3                            0            12.3392 Mbit/s
    3                            1            13.54 Mbit/s
    4                            0            17.0992 Mbit/s
    4                            1            18.512 Mbit/s
    5                            0            21.1232 Mbit/s
    5                            1            22.6816 Mbit/s
    6                            0            23.0064 Mbit/s
    6                            1            24.6104 Mbit/s
    7                            0            24.5368 Mbit/s
    7                            1            26.2704 Mbit/s


--------------------------------------------------------------------
When I do not specify an address but use broadcast address on line 95,

    UdpClientHelper myClient (Ipv4Address::GetBroadcast(), 9999);

the throughput drops:

    MCS value        short GI        Throughput
    0                            0            1.6952 Mbit/s
    0                            1            1.7752 Mbit/s
    1                            0            2.172 Mbit/s
    1                            1            2.2648 Mbit/s
    2                            0            2.3768 Mbit/s
    2                            1            2.4528 Mbit/s
    3                            0            2.5264 Mbit/s
    3                            1            2.5992 Mbit/s
    4                            0            2.6736 Mbit/s
    4                            1            2.7192 Mbit/s
    5                            0            2.7704 Mbit/s
    5                            1            2.7944 Mbit/s
    6                            0            2.8248 Mbit/s
    6                            1            2.7968 Mbit/s
    7                            0            2.7816 Mbit/s
    7                            1            2.8264 Mbit/s

--------------------------------------------------------------------

Why are the data rates throttled in broadcast?  The sent traffic is EXACTLY the same.

Could it be that it reverts to the lowest possible data rate in broadcast?  If so, then why do the data rates change at all?

I thought this might be a problem with the UdpClientHelper, but found the same results when I used Sockets (I can upload that code too if it would help).

Thanks for any help or suggestions!

[Tommaso Pecorella]

On Tuesday, September 6, 2016 at 2:06:05 AM UTC+2, Richard Thompson wrote:

....

Why are the data rates throttled in broadcast?  The sent traffic is EXACTLY the same.

Could it be that it reverts to the lowest possible data rate in broadcast?  If so, then why do the data rates change at all?

Hi,

the analysis is correct. You just forgot that this is the standard behaviour (meaning, the standard states that this is the right thing to do).

The rationale is this: if you send a broadcast, you don't know if all the receivers in range support the data rate you'll use. As a consequence, you'll use the lowest one.

Moreover, the lowest the data rate, the larger the broadcast range (without touching the Tx power). It's a SNR thing.

Cheers,

T.

 

[Richard Thompson]

Thanks for the reply.

I don't think my analysis is correct on further review for the following reasons:

1. If it were correct, the throughput would be exactly or nearly the same.  There is a clear increase in the throughput.

2. On line 21, when the packet size is changed from 100 to 1000, I get the following output when broadcasting:

MCS value        short GI        Throughput

0                            0               5.072 Mbit/s
0                            1               5.536 Mbit/s
1                            0               8.64 Mbit/s
1                            1               9.376 Mbit/s
2                            0               11.384 Mbit/s
2                            1               12.136 Mbit/s
3                            0               13.296 Mbit/s
3                            1               14.376 Mbit/s
4                            0               16.504 Mbit/s
4                            1               17.4 Mbit/s
5                            0               18.6 Mbit/s
5                            1               19.48 Mbit/s
6                            0               19.648 Mbit/s
6                            1               20.152 Mbit/s
7                            0               20.32 Mbit/s
7                            1               21.032 Mbit/s


Clearly it is not using MCS0, in fact it appears that the 'correct' MCS is being used.

I think something else is going on.

I appreciate your help very much.

[Tommaso Pecorella]

You're totally right (and i was wrong). However I'm too sleepy right now to find the reason. I bet it's in the standard tho. Most probably in the preamble size (it would explain a lot of things, even the 100/1000 bytes difference).

Cheers,

T.

[Richard Thompson]

Ok,  I think you are right that it does have something to do with the preamble size.  As you are most undoubtedly aware, According to the standard, the shortest preamble on 802.11n is achieved by using greenfield mode.

According to ns-3 documentation, this is achieved by placing the command:

          phy.Set ("GreenfieldEnabled", BooleanValue(true));

I insert this instruction on line 31 but when I run it, no packets are received.  It does not matter if they are sent broadcast or not.  No packets are received.

I'm thinking it might have something to do with it being in ad-hoc mode.  Is it possible that greenfield mode does not work in ad-hoc mode?

If this is true, shouldn't ns-3 generate an error?

Thanks for your help and time.

[Tommaso Pecorella]

Hi,

no idea. Please check with ns-3-dev and (in case) poke the Wi-Fi maintainer.

If Greenfield doesn't work in ad-hoc, then yes, there should be a warning.

Cheers,

T.

[Richard Thompson]

Ok, sounds good.  For those who stumble upon this with a similar problem,  I found it has nothing to do with adhoc mode.

I changed line 94 of the example:

https://www.nsnam.org/doxygen/ht-wifi-network_8cc.html

to read

phy.Set ("GreenfieldEnabled", BooleanValue(true));

as suggested in the tutorial file found at

https://www.nsnam.org/docs/models/html/wifi-user.html

Even though it is not in adhoc mode, throughput is zero.  It seems that greenfield mode just doesn't work.

[Sebastien Deronne]

Patch is available at https://www.nsnam.org/bugzilla/show_bug.cgi?id=2511

[Richard Thompson]

Patch fixes the greenfield problem!  Thankyou!

Unfortunately, it did not solve the other problem of the slowdown when in broadcast :(  Its got to be something different besides greenfield mode.  I will keep looking and post back to here if I find a solution.

[Richard Thompson]

To test it further, I set up tracing  to see where the additional delay is occurring.

In broadcast mode, it appears the transmitter waits about 100 microseconds between sending packets.
In non-broadcast mode, there is no delay.

Does anybody know why there would be a delay between packets for broadcast?  I cannot find anything in the 802.11n standard to indicate that this would be the case.

[Richard Thompson]

I further implemented the scenario using 802.11ac and the same problem exists!