Protocol

There are a couple of different mode of WLAN operation. Following is the protocol sequence for the case we commonly use where we have an AP(Access Point) and the Device(client PC or Smart phone WLAN) gets connected to the access point.

The page follows one device from the moment it finds an AP to the moment it exchanges user data. The first section walks through scanning, authentication, association and the 4-way handshake, using a real capture. The second section looks at the timing of one data exchange, with and without fragmentation. The last section shows how a device in power save mode still receives the data that arrives for it while it sleeps.

Overall Procedure

The AP is periodically transmitting (broadcasting) a special signal called Beacon signal saying "I am here.. I am here .. I am capable of this and that .. etc)". Basically this Beacon is like MIB/SIB + Physical Layer Sync channel in mobile communication (e.g, WCDMA/LTE etc). AP broadcast this Beacon several times per seconds. Beacon transmission interval is contained in one of Beacon information fields. (See Beacon data field)

When you turn on WLAN on your PC or Smart phone, the device first detect and decode this beacon signal and establish physical synchronization.

After the physical Sync get established, the device and WLAN network goes through the authentication process and then association process which is similar concept to the registration process in mobile phone communication.

Speaking of scanning, there are two types of scanning. One is called Passive Scan and the other one is called Active Scan. As shown below, in Passive Scan the device scans and detect Beacon signal from AP and establish the sync based on the Beacon signal. In Active Scan mode, device broadcast Probe Request to all the APs (or any specific AP), if there is any AP that detect the probe request, it sends Probe Response to the device.

In the diagram above, the two boxes at the top are the two ways to find an AP. In Passive Scan, the device only listens for Beacon frames. In Active Scan, the device sends a Probe Request, and the AP answers with a Probe Response. The Authentication box shows the four-frame challenge exchange of Shared Key authentication, which belongs to the old WEP security. The capture further down shows a different case. Its Authentication step has only two frames, and the Authentication Algorithm field in them reads Open System. With WPA and WPA2, authentication is Open System, and the real security check happens later in the EAPOL 4-way handshake.

Once they went through Authentication and Association process, now the device can send and receive user data. Here comes a tricky issues for packet transaction especially when a party tries to transmit something. WLAN does not have concept of dedicated channel (e.g, as in UMTS mobile communication) and it does not have any well designed physical/MAC layer scheduing for each separate user. Basically they are allowed to transmit anytime they like, but in reality a device cannot transmit any time. If it transmit some data while another device is sending data, the data may get lost in the air or it would cause the data for other device get lost since the transmission from the two device would interfer each other. We need some special technique to prevent this problem happening. In Wired LAN, we use a techniq called CSMA/CD and in WLAN we use another technique called CSMA/CA. For the details of these technique, i will write a separate section.. but the goal/purpose of the technique is to make it sure that a device transmit the data when no other device is transmitting anything.

The trace log shown here came from Aircrack-NG Tutorial: WPA Packet Capture Explained. In general, Step (1)~(7) is common to most of WLAN attach process, but the steps after this would be different depending on the security option you set on the device and access point. (Refer to ePDG protocol sequence if you want to see an examples that is different from the step (8) and later)

The capture above has 14 rows, and the number on the right of each row is the step number used below. Rows 1 to 7 are management frames with 802.11 in the Protocol column. Rows 8 to 11, highlighted in green, are EAPOL frames. Rows 12 to 14 are Data frames.

Rows 1 to 3 : the Beacon from the AP, then the Probe Request from the device and the Probe Response from the AP. The Beacon and the Probe Request go to Broadcast, and the Probe Response goes to the device only.
Rows 4 and 5 : two Authentication frames, one in each direction. Step 4 shows Authentication Algorithm Open System and Authentication SEQ 0x0001.
Rows 6 and 7 : the Association Request from the device and the Association Response from the AP. After row 7, the device is associated with the AP.
Rows 8 to 11 : the 4-way handshake that derives the encryption keys. Wireshark labels rows 10 and 11 as "Key" and "Message 2 of 4". By their order and direction, they are messages 3 and 4 of the handshake. Step 8 shows Key Descriptor Version 1, RC4 Cipher with HMAC-MD5 MIC, which means WPA with TKIP.
Rows 12 to 14 : encrypted Data frames. Step 12 shows TKIP parameters in the frame, so the data uses the keys from the handshake.

The techniqu that WLAN is using to transmit data without interfering other's is as shown below. The concept is simple. a device (let's call this a source device) send a short signal called RTS to another device (let's call this a destination device). If destination device successfully got the RTS, it is supposed to send CTS. If the source device successfully detect/decode the CTS, it transmit the main data. if the data is successfully recieved/decoded by the destication device, the destination device send 'ACK'. When RTS/CTS is used, this process repeats for each packet transmission. RTS/CTS is optional, and many devices use it only for frames longer than a configured RTS threshold. Without it, the exchange is only Data and ACK.

Data Transmission in Detail

Once the initial connection setup is completed by the procedure that is explained in previous section, usually the procedure for user data flow starts. In this section, I will go over how the user data flow goes on.

First case is where a chunk of user data is transmitted in single transmission as illustrated below.

More detailed process of this data tranmission in terms of timing can be illustrated as shown below.

i) Source transmit the short RTS burst which carries source, destination and duration of following transaction.
ii) All other devices around the source may receive the RTS burst. They are all checking if the RTS is for itself or not.
iii) If it is for itself and the medium is free, the destination device transmit the CTS which also carries the duration of following transaction.
iv) Now all the other device (the neighbouring device other than 'Destination' device) also knows that the medium will be occupied for a certain time from now, they would set their NAV(Network Allocation Vector) accordingly so that it would not try sensing and try to transmit anything during that period.

The G1 and G3 gaps in the diagram above have fixed lengths, and the lengths depend on the PHY. For the OFDM PHY in the 5 GHz band, SIFS is 16 us and one slot is 9 us. DIFS is SIFS + 2 x slot, so it is 16 + 2 x 9 = 34 us. For 802.11b in the 2.4 GHz band, SIFS is 10 us and one slot is 20 us, so DIFS is 10 + 2 x 20 = 50 us. SIFS is always the shortest gap. This is why CTS, Data and ACK in one exchange always get the medium before a new device, which must wait at least DIFS.

The two NAV bars also have different lengths, and the reason is in the Duration field. The RTS is sent first, so its Duration covers CTS, Data, ACK and three SIFS gaps. The CTS Duration is the RTS Duration minus one SIFS and the CTS itself. Both bars therefore end at the same point, at the end of the ACK.

SIFS protects an exchange that has already started : a responder waits only SIFS, while every new transmission waits DIFS and a random backoff.
The NAV is virtual carrier sense : a device that hears only the CTS still sets its NAV, so it stays quiet even when it cannot hear the source.
RTS/CTS costs airtime : two extra frames and two extra SIFS gaps are added to every exchange, so it pays off mainly for long frames.

When data packets are larger than the fragmentation threshold configured on the device or when the network conditions are such that sending smaller packets is more reliable.Fragmentation in Wi-Fi networks happens. In case of Fragmented Frame, the sequence goes as follows :

i) Source (Src) Initiates Transmission:

The source device begins by sending a Request to Send (RTS) frame, which includes the source, destination, and the duration of the transmission.

ii) Destination (Dest) Responds:

If the medium is free, the destination device responds with a Clear to Send (CTS) frame, which also contains the duration of the transaction, indicating that it is ready to receive the data.

iii) Fragmented Data Transmission:

The source then sends the first fragment of the data (Frag 0).
After the destination device successfully receives Frag 0, it sends an acknowledgment (ACK 0).

iv) Continued Data Exchange:

This process continues with the source sending the next fragment (Frag 1), followed by another acknowledgment from the destination (ACK 1).
The sequence repeats for all subsequent fragments (e.g., Frag 2 followed by ACK 2, and so on) until the entire message is transmitted.

v)Other Devices Set NAV:

Other devices in the network (labeled as "Other") listen to these exchanges and set their Network Allocation Vector (NAV) for the duration indicated in the RTS and CTS frames.
The NAV informs these other devices not to attempt transmission and to wait for the medium to become free.

vi) Contention Window and Backoff:

If any device wants to access the medium, it must wait for a Distributed Inter Frame Space (DIFS) and then proceed to a contention window.
During the contention window, each device waits for a random backoff time before attempting to transmit. This helps prevent collisions by randomizing transmission attempts.

NOTE : What SIFS (labeled as G1) is for ?

It is a short inter frame space that usually happens in some situation as below.

Large Packets (G1 Consideration):

When dealing with large packets that exceed the fragmentation threshold, the network must fragment these packets. Between the transmission of each fragment and its corresponding acknowledgment (ACK), the devices observe a short wait time known as a Short Interframe Space (SIFS), labeled as G1 in the diagram. This is the shortest wait time and ensures rapid exchange of frames related to the same data transmission.

Poor Network Conditions (G1 Application):

In difficult network conditions, such as interference or low signal quality, sending smaller fragments becomes necessary. After sending a fragment, the sending device waits for the duration of G1 (SIFS) before expecting an ACK. If the ACK is received, the next fragment can be sent. This short wait time defined by G1 is crucial for maintaining a quick and orderly flow of the fragmented transmission, allowing for immediate response from the receiving device.

NOTE : When Fragmentation happens ?

Fragmentation in Wi-Fi networks happens when data packets are larger than the fragmentation threshold configured on the device or when the network conditions are such that sending smaller packets is more reliable. The decision to fragment is typically made by the device's network stack, which takes into account the current network conditions, the capabilities and settings of the network devices, and the size of the data being sent.

Large Packets:

If a data packet is larger than the fragmentation threshold, which is the largest frame size the device sends without fragmenting it, the packet needs to be broken down into smaller fragments.

Poor Network Conditions:

In an environment with a lot of interference, high error rates, or low signal strength, larger packets are more likely to be corrupted. It is often more reliable to send smaller fragments because they have a higher chance of being received correctly.

Distance Between Devices:

The further the distance between the communicating devices, the higher the likelihood of signal degradation. Smaller packets can be more successfully transmitted over longer distances without error.

Regulatory Requirements:

Some regulatory bodies may set specific limits on the duration of transmission to ensure fair medium sharing. In such cases, large packets might be fragmented to comply with these "airtime fairness" regulations.

Retry Strategy:

With fragmentation, if a single fragment is lost or corrupted, only that fragment needs to be retransmitted, not the entire packet. This can reduce the amount of data that needs to be resent and can be more efficient in terms of network bandwidth usage.

Dynamic Fragmentation:

Some protocols dynamically adjust the packet size based on current transmission acknowledgments (ACKs). If packets are frequently not acknowledged, indicating a high loss rate, the protocol might choose to fragment subsequent packets to improve reliability.

Sleeping Mode and Data Transmission

The sequence diagram shown bellow illustrate how a Wi-Fi-enabled device (Station) in power-saving mode communicates with an Access Point (AP) to receive data. This process ensures that devices on a Wi-Fi network can conserve power by sleeping and only waking when necessary to receive data.

Here’s a step-by-step explanation of what’s happening:

In Sleeping Mode: The device is in a low-power state, commonly known as sleeping mode, to conserve battery.
Data Arrived for the Device: While the device is asleep, data intended for it arrives at the AP.
Buffered in AP: Since the device is in sleeping mode, the AP holds onto (buffers) the data instead of immediately sending it.
Beacon: The AP regularly sends out beacon frames, which are like lighthouses for Wi-Fi, signaling its presence. These beacons contain a TIM (Traffic Indication Map), which has a bit set if there's data buffered for specific devices.
Wake up/detect Beacon: The device periodically wakes up to listen for these beacon frames. When it detects a beacon with a TIM indicating there is data for it, it knows it needs to take action to receive this data.
PS Poll: The device sends a Power-Save Poll (PS-Poll) frame to the AP to request the delivery of the buffered data. This is a signal to the AP that the device is awake and ready to receive the data.
Data: Upon receiving the PS-Poll frame from the device, the AP sends the buffered data to the device.
ACK: After the device successfully receives the data, it sends an acknowledgment (ACK) back to the AP, confirming that the data was received.

The device does not need to wake for every Beacon. The Beacon interval is counted in TU, where 1 TU = 1.024 ms, and the common value of 100 TU gives one Beacon every 102.4 ms. A device that wakes for every third Beacon, for example, listens once every 307.2 ms. The TIM tells the device whether data is waiting, so the device can go back to sleep at once when its bit is not set. In the diagram above, the AP sends three Beacons with the TIM bit set before the device wakes up. The data waits in the AP buffer for that whole time.

The AP carries the cost of power save : it buffers the data and signals it in the TIM, so the device can sleep between Beacons.
Power save adds delay : buffered data waits until the device wakes, reads the TIM and sends a PS-Poll.

Reference :

[1] IEEE 802.11 - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications