Notes on NS3 – IEEE 802.11 Wi-Fi Association

  • Posted May 9, 2013. Last modified May 9, 2013 by

For some of my research I have been delving into the details on how exactly station devices in an IEEE 802.11 network associate with an access point. As far as I understand from the standard station nodes have two possibilities.

1. Active
In this case the station nodes send out probe requests to see if any access points respond during a timeout period

2. Passive
In this case the station nodes just sit and listen over a timeout period to see if any aps send out beacons.

In either case, according to the standard, the station node is supposed to rank the APs according to received signal strength (RSS). While this is recognized as a bad method for various reasons – it is a simple and quick way to select an AP.

In NS3 (3.16), as far as I can tell, there is no measure of RSS. The station node simply associates with the first AP that it receives either a probe response or beacon from (depending on active or passive). Usually this ends up being the closest AP to the user station because it has the lowest propagation delay due to the lower distance. However, depending on when the stations start up, a farther station is sometimes selected – at least initially until enough beacons are missed that an AP disassociation occurs, and the process starts over with the closer AP being selected.

In NS 3.16, the code which controls AP association is located in src/wifi/model/sta-wifi-mac.cc.

Looking at the code details, and confirming with some extra logging I added – a Wi-Fi station when starting, broadcasts a probe request (in active probing mode). It then waits for a probe response.

If you look in the “StaWifiMac::Receive (Ptr packet, const WifiMacHeader *hdr)” function, you can see that immediately when it receives one of these responses, it sends an association request to the AP. This is one place where changes must occur if one wishes to make a smarter decision for selecting an AP. In my case, instead of immediately sending an association request, I record the probe response and continue to wait for more until the probe timeout occurs.

If you look at “StaWifiMac::ProbeRequestTimeout (void)” you can see this is where you can now implement the association decision. After the timeout has occured, we now have a list of all of the received probe packets and can make the decision and associate like before.

Leave a Reply

Your email address will not be published. Required fields are marked *