Notes on NS3 – IEEE 802.11 Wi-Fi Association

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.

IEEE ICC 2012 – Ottawa

Last week I presented a paper at IEEE ICC, and since its been a while since I have posted I thought I put up a bit of a summary about my work. For people who have looked at my site a bit, you might know my research is on Heterogeneous Wireless Networking (making wireless technologies work together seamlessly). The goal of my work is to enable devices with Bluetooth, Wi-Fi, 3G, 4G, LTE and future radios to be able to switch easily between connections or use more than one at a time. There are still many problems which make this impossible right now. For instance, if you are using Skype on a Wi-Fi connection on your phone and you leave a building and switch to the 4G network outside, chance are you will be disconnected from Skype (Seamless Handover is not supported).

Another problem may be a lack of co-ordination between radio access technologies (RATs). For instance, while Bluetooth supports adaptive frequency hopping (AFH) to try to avoid the same channels Wi-Fi is being used on, this may not be enough to ensure interference between the technologies is avoided. What happens when you are in a dense area where Wi-Fi is being used across all channels, or there are many devices? (Apartment buildings, dense cities etc.)

As you may know, lots of wireless research is done using simulation because in many cases it is faster and cheaper. Many simulation tools support interference within a particular technology (ie Wi-Fi nodes interfering with other Wi-Fi nodes) but not many support interference between technologies (ie Wi-Fi nodes interfering with Bluetooth nodes). The paper I presented at ICC tries to understand how much of an impact this makes.

I’ll spare most of the details since they are in the paper, but essentially the findings are that Wi-Fi -> Bluetooth interference causes a drop in around 10-15kbps of the total 50kpbs Bluetooth was able to achieve in our lab setup (About 30% drop).

In the other direction, the interference was mostly insignificant. However, this was expected since the setup used close ranges (Wi-Fi power is much greater than that of Bluetooth).

The future work includes looking at varying distances (It seems like it will be interesting when we use a range that makes the Wi-Fi and Bluetooth powers similar). Eventually the goal is to create an interference model that can be used in simulation. If you want more details – see the attached paper and slides.

icc2012 (slides pptx)
icc20122 (paper pdf)