In last articles we had an introduction to Wi-Fi network, Channels and started looking into BSS. Refer
Introduction to Wi-Fi
Wi-Fi Channels
Addresses in 802.11, Beacons
Let us start trying to visualize the beacon frame in the Air.
Not only beacons but all the WLAN (Wireless LAN) packets in the air should have the MAC header right at the beginning.
The MAC Header:
In 802.11, A specific header to the protocol was introduced and being used called the 802.11 MAC header. Have a look at the image below. (Click it and keep open in neighboring tab)
 |
| 802.11 MAC Header |
This MAC header is common for all the 802.11 frames.
Version: It is of size two bits, and as of now the value is fixed as 0 (indeed 00 in binary as it is of size two bits).
Type: It is of also size two bits. There are actually three types of frames in 802.11, viz.
(i) Management - 00
(ii) Control -01
(iii) Data - 10
Subtype: For every type of frame lot of subtypes are defined. I will donate a separate article for subtypes. At present we will stop with knowing "Beacon" as a "Management frame (00)" and the subtype value for it is "1000".
Frame Control:
Order: This is to specify whether the "strictly ordering of frames" is used or not. Mostly the strictly ordering of frame service will not be implemented. Only for the LAT protocol, the strict ordering of frames need to be provided (Order Bit will be 1). Beacons (Management and Control frames) follows "No strict Order (0)".
WEP: Wired Equivalent Privacy (WEP) is the first security scheme proposed for 802.11. If the frame is an encrypted frame with WEP, then the bit will be set (1) otherwise it will be cleared (0). For management frames, No encryption mechanism specified, hence for beacons the bit will be 0.
Cisco has it's own proprietary protocol for encrypting Beacons and other management frames. Later IEEE has came up with standardizing the Management frame encryption as 802.11w
More Data: This bit is also mostly for data frames, to indicate whether any more data needs to be received by the receiver (1) or not (0). In case of beacon, it is not followed by any more data, hence this bit will be 0.
Power Management: To indicate whether the device is in power save mode (1) or active mode (0). The beacons are from Infrastructure Devices which will never go to power save. Hence Frames from Infrastructure devices will always have this bit as 0.
Retransmission: To indicate whether this is the first copy of the frame getting transmitted (0) or it is duplicate of previous transmission due to several reasons (1). There are several reasons for the frame getting retransmitted in wireless because the air is more prone to collisions of packets. We will focus shortly on this when we go for distribution functions.
Fragmentation: Usually the bigger frames will be fragmented and transmitted into the air to reduce the probability of getting corrupted. Under that case if the bit is set (1) it indicates, there are more fragments which belongs to the same frame will be transmitted. If the bit is clear (0), then that frame is a complete frame which is not fragmented or it can be a last fragment of the fragmented frame. Management and Control frames will not be fragmented because their size will be less the threshold defined for the fragmentation. Hence beacon has this value as 0.
From Distribution System: If the frame is from the distribution system (Infrastructure Device) then this bit will be set. This bit is not defined for management and control frames ( It clears your thoughts saying why the bit is not set for beacon which is getting transmitted by Infrastructure Device :P !!!)
To Distribution System: Yet another frame defined only for data frames (!!!) to indicate that the frame's Destination is an Infrastructure device.
Duration: There is something called NAV (Network Allocation Vector) which is useful for avoiding collision. For now we will just see what NAV is. NAV is a time unit which needs to be updated in the hardware counter of the wireless device, for which the device needs to wait before trying to compete for the medium. (Oops. Don't worry if you got confused, you will get it cleared when we deal with the Collision Avoidance implementation in wireless!!!).
This Duration will serve another purpose as well. On Power save data packets it will say the AID (Association ID) of the device in power save for which the infrastructure device has buffered packets. (Yeps. We will dig this deeper in power save)
Destination, Source, BSSID: We have seen this in previous article is it not. Just some points to add. Beacons are broadcasted hence destination is broadcast (FF:FF:FF:FF:FF:FF), source and BSSID are same as MAC of Infrastructure device.
The following details are easy to represent in table. Look at the table below (Courtesy Thanks: This table is taken from IEEE spec)
 |
| Address field contents |
DA - Destination Address, SA - Source Address, BSSID - Basic Service Set ID, RA - Receiver Address, TA - Transmitter Address.
The Table is self explanatory. It will say us what is the value of Address 1,2,3 and 4, based on whether it is a frame to DS or frame from DS.
Sequence and Fragment Number: These two parameters are used for fragmentation and reassembling. If the frame is fragmented and transmitted, these are the parameters with which the receiving device arrange the fragments to get a complete frame. These are defined for MSDU and MMPDUs (We will see them clearly as we go ahead) packets.
Sequence number is 12 bit and it will indicate the sequence number of the frames.
Fragment number is 4 bit and it will indicate the fragment number if the frame is fragmented one.
These two are basically counters and their values will be same over retransmission. Of course right, if the frame is fragmented into 4, and take 3rd frame. The third frame is always third frame immaterial how many time it got retransmitted, is it not? Extend the same idea for consequent data frames. Assume there is a data of 13 (lucky number yaar) sequential frames, the 9th frame is always 9th frame no!!!
Indeed Fragmentation is worth an article, we will deal it left and right.
Lot of things to speak about. The digging of beacon is not complete :( Next article will be continuing on beacon frame, then we will switch for pending promise made here, the article on collision to explain NAV, retransmission.
