Since I figured out how to configure my eeePC for Wifi tracing with Wireshark, I’ve gained a number of interesting insights which go far beyond what you can read in literature on the topic. Standards are one thing, how they are implemented in devices are quite another sometimes. Here are some results I thought I’d share with you:
As a wireless medium is prone to transmission errors, each frame has to be acknowledged by the receiver. If the frame is not received it is automatically retransmitted. So how do devices do this in practice and how often does it happen? I’ve been able to do some pretty interesting traces with a Siemens Access point and a Nokia N95. The two devices are quite different in their radio characteristics as the antenna in the mobile device is far from ideal, especially if there is a wall separating the two devices as was the case in my test. Also, the behavior on the air interface is quite different, which has nothing to do with the antenna configuration.
The Siemens Access point is quite conservative concerning the use of modulation and coding schemes for a packet. The majority of packets are never sent with the maximum speed of 54 MBit/s, but instead with 36 MBit/s or even less. As a consequence, most packets are received correctly and are immediately acknowledged. In case there is no acknowledgement, the access point immediately reduces the modulation and coding by a step for the retransmission. As a result I haven’t seen many cases in which a frame has not been acknowledged after the second try.
The N95 on the other hand is pretty aggressive concerning modulation and coding scheme. It usually always starts with 54 MBit/s and even uses this setting for the first retry. If the first transmission has failed, the second usually does as well. Only for the third transmission is the modulation and coding scheme lowered to 48 MBit/s, then to 36 MBit/s and finally to 24 MBit/s. For subsequent frames, 36 MBit/s seems to be used for about 500 ms before the N95 Wifi chipset tries to go back to 54 MBit/s.
Also interesting is the repetition time in case no acknowledgment is received. On average, a packet is resent after around 0.5 ms. In case a packet is retransmitted 3 times, the resulting delay is about 2 ms. As a single frame usually carries 20 ms voice data, this time is negligible on the application layer and is far less than the jitter introduced on the way through the public Internet.
If you think three repetitions is a lot, you are right. However, I’ve seen cases in which the frame was transmitted 7 times before it was finally acknowledged. In this case, the backoff algorithm even allowed other stations to send their frame before the device could try all retransmissions. Pretty impressive.
The figure on the left shows how such a trace looks like in practice. Frame 6420 is sent but no acknowledgment is received. It is then resent as frame 6421 and then as 6422, after which an ack. is finally received. 6426, 6427 and 6430 are all the same frame, only acknowledged after the second retry. In between is 6428, a frame from another device together with its acknowledgment, 6429.
So that’s how it works in practice 🙂
I have to say, I’m taking a Cisco wireless class and was doing a little research about wireless transmission and came across this post by accident, but it’s got some great info. I’ve used wireshark before, but never in heavy use, I’ll have to give some of the techniques you mention a try.