Bug 1181

Summary:	How to add basic rates to 802.11
Product:	ns-3	Reporter:	Rober <sanzrober>
Component:	wifi	Assignee:	Nicola Baldo <nicola>
Status:	RESOLVED FIXED
Severity:	normal	CC:	deanarm, nikkipui, ns-bugs, pvnskbs, ruben
Priority:	P5
Version:	pre-release
Hardware:	All
OS:	All
Attachments:	Capture sample with PHY header showing beacons @11Mbps and ACKs @1Mbps

Description Rober 2011-06-06 09:29:10 UTC

Created attachment 1160 [details]
Capture sample with PHY header showing beacons @11Mbps and ACKs @1Mbps

Hi all,

Some days ago, I created a new post on google's ns-3-users about the possibility to add new rates to the basic rate set in 802.11 (exactly, my problem was for 802.11b, I haven't tested for 11a or 11n). That is, for 802.11b, 1 Mbps is the only basic rate, thus control frames like ACKs are limited to be sent at 1 Mbps. Management frames are not under this criteria and they (Beacons, Assoc. Req, etc) are sent at 11 Mbps (in fact, their rate can be adjusted thru attribute "ControlMode" using SetRemoteStationManager, and this does work.

This is the post's url under google's group:
http://groups.google.com/group/ns-3-users/browse_thread/thread/28dbd8cfe1db95f4#

The point is that ns-3 takes as basic rate only 1 Mbps. I can check
it in beacons parameter (in pcap capture), it marks just 1.0 with the (B):

   ----- Supported rates: 1.0(B) 2.0 5.5 11.0  [Mbit/sec]

But in real life, some cards use higher rates (including 11 Mbps) as basic rates. You can see ACKs at 2, 5.5 or 11 Mbps in real tests. So, I need to set these higher rates for ACKs in my simulations, but I can't use "AddBasicMode" to add more basic rates because it fails as it isn't an Attribute in ns3::WifiRemoteStationManager.

Summarizing, I'd like to know if there is some bug for ControlMode that doesn't affect ACK frames or there is any obscure way to add new basic rates.

Thank you very much for the support.

Rober

Comment 1 Dean Armstrong 2011-07-04 16:14:12 UTC

This is how I have modified the basic rate set (where apDev is a NetDeviceContainer containing (as the first device) a Wi-Fi AP)...

// Add the DSSS/CCK rates as the basic rates of our AP
Ptr<WifiRemoteStationManager> apStationManager = DynamicCast<WifiNetDevice>(apDev.Get (0))->GetRemoteStationManager ();
apStationManager->AddBasicMode (WifiMode ("DsssRate1Mbps"));
apStationManager->AddBasicMode (WifiMode ("DsssRate2Mbps"));
apStationManager->AddBasicMode (WifiMode ("DsssRate5_5Mbps"));
apStationManager->AddBasicMode (WifiMode ("DsssRate11Mbps"));

It works, but is a little obscure - I guess one could construct an API to allow this to be modified through the Attributes subsystem.

Does this help you?

Comment 2 Rober 2011-07-05 03:44:32 UTC

(In reply to comment #1)
> This is how I have modified the basic rate set (where apDev is a
> NetDeviceContainer containing (as the first device) a Wi-Fi AP)...
> 
> // Add the DSSS/CCK rates as the basic rates of our AP
> Ptr<WifiRemoteStationManager> apStationManager =
> DynamicCast<WifiNetDevice>(apDev.Get (0))->GetRemoteStationManager ();
> apStationManager->AddBasicMode (WifiMode ("DsssRate1Mbps"));
> apStationManager->AddBasicMode (WifiMode ("DsssRate2Mbps"));
> apStationManager->AddBasicMode (WifiMode ("DsssRate5_5Mbps"));
> apStationManager->AddBasicMode (WifiMode ("DsssRate11Mbps"));
> 
> It works, but is a little obscure - I guess one could construct an API to allow
> this to be modified through the Attributes subsystem.
> 
> Does this help you?

Yes, it works out! Thanks a lot. Now I can control the rate for ACKs and the rate for data frames in a separate way, just to achieve a behaviour like in real tests with real cards.

But... I also have tried your modification for a IBSS network (i.e. ad hoc mode) but it seems that basic rates can't be modified with the same code (obviously I have changed apDev for staDevs. Maybe you can tell me a way to adapt the BSS modification to the IBSS case.

Thanks again!

Comment 3 Dean Armstrong 2011-07-05 17:21:31 UTC

(In reply to comment #2)
> But... I also have tried your modification for a IBSS network (i.e. ad hoc
> mode) but it seems that basic rates can't be modified with the same code
> (obviously I have changed apDev for staDevs. Maybe you can tell me a way to
> adapt the BSS modification to the IBSS case.

I haven't tried it, but I would have thought it would work if you did it for each STA in the IBSS - i.e., the code I provided could be repeated in a for loop across the STAs in your staDevs. Perhaps something like this...

// Add the DSSS/CCK rates as the basic rates of each STA
for (uint16_t i = 0; i < nStas; i++) {
  Ptr<WifiRemoteStationManager> nodeStationManager =
    DynamicCast<WifiNetDevice>(staDevs.Get (i))->GetRemoteStationManager ();
  nodeStationManager->AddBasicMode (WifiMode ("DsssRate1Mbps"));
  nodeStationManager->AddBasicMode (WifiMode ("DsssRate2Mbps"));
  nodeStationManager->AddBasicMode (WifiMode ("DsssRate5_5Mbps"));
  nodeStationManager->AddBasicMode (WifiMode ("DsssRate11Mbps"));
}

I haven't worked with the ns-3 "IBSS" much though, so I might be off-base.

Comment 4 Rober 2011-07-05 17:43:44 UTC

(In reply to comment #3)
> (In reply to comment #2)
> > But... I also have tried your modification for a IBSS network (i.e. ad hoc
> > mode) but it seems that basic rates can't be modified with the same code
> > (obviously I have changed apDev for staDevs. Maybe you can tell me a way to
> > adapt the BSS modification to the IBSS case.
> 
> I haven't tried it, but I would have thought it would work if you did it for
> each STA in the IBSS - i.e., the code I provided could be repeated in a for
> loop across the STAs in your staDevs. Perhaps something like this...
> 
> // Add the DSSS/CCK rates as the basic rates of each STA
> for (uint16_t i = 0; i < nStas; i++) {
>   Ptr<WifiRemoteStationManager> nodeStationManager =
>     DynamicCast<WifiNetDevice>(staDevs.Get (i))->GetRemoteStationManager ();
>   nodeStationManager->AddBasicMode (WifiMode ("DsssRate1Mbps"));
>   nodeStationManager->AddBasicMode (WifiMode ("DsssRate2Mbps"));
>   nodeStationManager->AddBasicMode (WifiMode ("DsssRate5_5Mbps"));
>   nodeStationManager->AddBasicMode (WifiMode ("DsssRate11Mbps"));
> }
> 
> I haven't worked with the ns-3 "IBSS" much though, so I might be off-base.

Thank you for your soon reply. I've already tried exactly the same code that you suggest for the IBSS case. It compiles ok, but it fails when is executed. I've been doing some tries and the failing line of code is the pointer definition:

Ptr<WifiRemoteStationManager> nodeStationManager =
     DynamicCast<WifiNetDevice>(staDevs.Get (i))->GetRemoteStationManager ();

I must confess that I haven't neither worked win IBSS much, but I guessed it would be applied in the same way as for the BSS mode.

Any help will be welcome.

Thanks!

Comment 5 Dean Armstrong 2011-07-05 17:56:42 UTC

(In reply to comment #4)
> Thank you for your soon reply. I've already tried exactly the same code that
> you suggest for the IBSS case. It compiles ok, but it fails when is executed.
> I've been doing some tries and the failing line of code is the pointer
> definition:
> 
> Ptr<WifiRemoteStationManager> nodeStationManager =
>      DynamicCast<WifiNetDevice>(staDevs.Get (i))->GetRemoteStationManager ();

I've just tried doing what you want to do (modify basic rate set in an ns-3 simulation with AdhocWifiMac devices) using the code I quoted in my previous comment, and it works for me.

You might need to share a bit more of your code (preferably a minimal failing example) for me to be able to help you.

This thread of discussion also leaves me wondering where this bug now stands.

Comment 6 Rober 2011-07-06 03:32:29 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > Thank you for your soon reply. I've already tried exactly the same code that
> > you suggest for the IBSS case. It compiles ok, but it fails when is executed.
> > I've been doing some tries and the failing line of code is the pointer
> > definition:
> > 
> > Ptr<WifiRemoteStationManager> nodeStationManager =
> >      DynamicCast<WifiNetDevice>(staDevs.Get (i))->GetRemoteStationManager ();
> 
> I've just tried doing what you want to do (modify basic rate set in an ns-3
> simulation with AdhocWifiMac devices) using the code I quoted in my previous
> comment, and it works for me.
> 
> You might need to share a bit more of your code (preferably a minimal failing
> example) for me to be able to help you.
> 
> This thread of discussion also leaves me wondering where this bug now stands.

Sorry, you're right. It was my silly fault. I typed "<=" instead of "<" inside the "for" loop, so it overflowed the number of STA's.

So, it also works fine for me, and this bug may be closed.

The only doubt that remains is the actual function of the parameter "ControlMode" like in:

wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
                                "DataMode",StringValue(phyMode),
                                "ControlMode",StringValue("DsssRate5_5Mbps"));

Isn't it supposed that "ControlMode" acts on the rate of control and management frames? But indeed it doesn't. Well, this is just my last thought about all this issue.

Thanks for all!

Comment 7 Dean Armstrong 2011-07-06 06:58:45 UTC

(In reply to comment #6)
> The only doubt that remains is the actual function of the parameter
> "ControlMode" like in:
> 
> wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
>                                 "DataMode",StringValue(phyMode),
>                                 "ControlMode",StringValue("DsssRate5_5Mbps"));
> 
> Isn't it supposed that "ControlMode" acts on the rate of control and management
> frames? But indeed it doesn't.

Despite the attribute naming and the associated comment, as far as I can tell this attribute does not act on anything other than RTS frames.

As you appear to know, the standard is quite clear on the rules for selection of transmission parameters for control response frames (i.e., frames of type control that are sent after SIFS). These rules are built into the implementation of WifiRemoteStationManager and are not overridden/broken in the derived ConstantRateWifiManager.

Nicola - as maintainer, do you think there is any API or documentation that particularly needs updating as a result of the discussion in this bug, or should it be closed as "invalid"?

Comment 8 Ruben Merz 2011-07-06 11:40:48 UTC

(In reply to comment #7)
> (In reply to comment #6)
> > The only doubt that remains is the actual function of the parameter
> > "ControlMode" like in:
> > 
> > wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
> >                                 "DataMode",StringValue(phyMode),
> >                                 "ControlMode",StringValue("DsssRate5_5Mbps"));
> > 
> > Isn't it supposed that "ControlMode" acts on the rate of control and management
> > frames? But indeed it doesn't.
> 
> Despite the attribute naming and the associated comment, as far as I can tell
> this attribute does not act on anything other than RTS frames.
> 
> As you appear to know, the standard is quite clear on the rules for selection
> of transmission parameters for control response frames (i.e., frames of type
> control that are sent after SIFS). These rules are built into the
> implementation of WifiRemoteStationManager and are not overridden/broken in the
> derived ConstantRateWifiManager.
> 
> Nicola - as maintainer, do you think there is any API or documentation that
> particularly needs updating as a result of the discussion in this bug, or
> should it be closed as "invalid"?

Hi Folks,

I don't think this bug should be classified as invalid. While I agree that the standard is quite clear, there is also evidence that several 802.11 drivers (typically atheros drivers) allow you to change the rate of all control packets. So I believe that ns-3 should also support this. Now, I think Dean's recipe could simply be documented on the wiki as a HOWTO.

Comment 9 Rober 2011-07-06 11:47:42 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > The only doubt that remains is the actual function of the parameter
> > > "ControlMode" like in:
> > > 
> > > wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
> > >                                 "DataMode",StringValue(phyMode),
> > >                                 "ControlMode",StringValue("DsssRate5_5Mbps"));
> > > 
> > > Isn't it supposed that "ControlMode" acts on the rate of control and management
> > > frames? But indeed it doesn't.
> > 
> > Despite the attribute naming and the associated comment, as far as I can tell
> > this attribute does not act on anything other than RTS frames.
> > 
> > As you appear to know, the standard is quite clear on the rules for selection
> > of transmission parameters for control response frames (i.e., frames of type
> > control that are sent after SIFS). These rules are built into the
> > implementation of WifiRemoteStationManager and are not overridden/broken in the
> > derived ConstantRateWifiManager.
> > 
> > Nicola - as maintainer, do you think there is any API or documentation that
> > particularly needs updating as a result of the discussion in this bug, or
> > should it be closed as "invalid"?
> 
> Hi Folks,
> 
> I don't think this bug should be classified as invalid. While I agree that the
> standard is quite clear, there is also evidence that several 802.11 drivers
> (typically atheros drivers) allow you to change the rate of all control
> packets. So I believe that ns-3 should also support this. Now, I think Dean's
> recipe could simply be documented on the wiki as a HOWTO.

I fully agree with you, Ruben.

You suppose right, I'm using Atheros chipset cards with Madwifi driver, and these cards always use the highest rates possible to achieve the greatest throughput for the user.

Thus, it's ok for me to move this recipe to the wiki.

Bye

Comment 10 Daniel L. 2013-10-15 09:24:32 UTC

HOWTO created in ns-3 wiki.