Saturday, December 3, 2016

Protection Mechanisms

In a heterogeneous network, clients of different standards (11b, 11g/11a, 11n) may be present. ion should use some protection mechanism to protect its communication. However, these mechanisms have overhead and should be used only when required. Its the responsibility of AP to inform its clients about presence of devices of different standards:

Presence of 11b Clients:

Presence of 11b client/s is indicated by the AP in the "ERP Information Element". If the "Use Protection" bit is set then stations should use the protection mechanism. The AP sets this bit if at least one 802.11b station is associated with BSS. The AP may, but is not required to, also set this bit if it detects the presence of 802.11b stations in a neighboring BSS. 
Note: ERP is synonymous to 11g  and hence non ERP means 11b stations. In the "ERP Information Element" there is another bit "NonERP Present" which is used to indicate (by AP & Stations) the presence of 11b clients).

Hence, any 11g/a or HT client should protect the communication when above mentioned bit is set. The method to protect is RTS/CT or CTS-to-self with a DSSS/CCK format at 11b rates.

Presence of 11g/a Clients:

Indication of associated non-HT stations (11g/a) in the BSS is given by "HT Protection" sub field in the HT Information element.  The AP may set the "OBSS Non-HT STAs Present bit" in the HT Information element if it detects non-HT stations on the primary or secondary channel that are not members of the BSS.
If there are HT stations associated with the AP that are not able to receive Greenfield format PPDUs then the AP will set the Non-Greenfield HT STAs Present bit to 1 in the HT Information element. 

However, HT transmissions are inherently protected against 802.11g and 802.11a (non-HT) stations through the use of the HT mixed format frame. This frame format includes a legacy compatible preamble, which allows non-HT stations to defer correctly for the duration of the frame.

There are few special exceptions:

  • RIFS Bursts: When spacing b/w frames in RIFS then non-HT stations may not defer correctly.  An AP can prevent RIFS from being used in a sequence by any station associated with the BSS by setting the RIFS Mode subfield in the HT Information element to 0. A station may only use RIFS bursting if the RIFS Mode subfield is set to 1. If RIFS bursting is permitted then the station may, but is not required to, protect RIFS sequences if there are legacy stations present (as indicated by "HT Protection" field). Given the overhead associated with protection it is likely that implementations would use SIFS rather than provide protection unless protection was needed for other reasons.
  • Presence of HT Greenfield Stations: The Greenfield format preamble is shorter and thus more efficient than the mixed format 
    preamble. However, the Greenfield format preamble is not compatible with legacy  
    stations and, support being optional, is also not receivable by some HT stations. When the Non-Greenfield HT STAs Present bit is set to 1 or the HT Protection field is set to 3 in the HT Information element then stations associated with the BSS must protect Greenfield format PPDUs.
  • 40 MHz transmission in 20/40 MHz BSS
For these exceptions, following protection mechanisms are available:
  • RTS/CTS:  The initiator begins a TXOP by transmitting a RTS frame, setting the Duration field in the RTS to the expected duration of the TXOP less the duration of the RTS frame itself. The responder sends a CTS frame setting the Duration field to the value seen in the RTS frame less SIFS less the duration of the CTS frame. The CTS frame is transmitted with the same modulation and coding as the RTS frame. Stations that successfully demodulate either the RTS or CTS frame or both frames have their NAV set for the duration of the TXOP and will not transmit during that time.
  • CTS-to-Self: 
    In most networks all stations are able to detect transmissions of all other stations and hidden nodes are rare. For such situations, the CTS-to-Self mechanism offered significantly reduced overhead compared with a full RTS/CTS exchange. At the beginning of a sequence, the initiator sends a CTS frame with the RA field set to 
    its own MAC address and the Duration field set to the expected duration of the sequence less the duration of the CTS frame itself.
Note:  In the case of a 40 MHz HT sequence the RTS/CTS exchange or CTS-to-Self transmission occurs on the primary channel.
  • a non-HT or HT mixed format PPDU soliciting a non-HT response PPDU (Data/ACK sequence):  A sequence that begins with a legacy compatible frame, for example a data frame, and that solicits a response frame, an ACK frame in this example, could be used to set NAV in nearby stations. In the below diagram, the data frame is likely transmitted using a high order MCS, however, the ACK frame is robustly modulated using a non-HT format PPDU and should be widely received. The ACK frame could thus be used to carry the NAV setting for nearby stations.

Q: When a data frame is send at 11n rates with mixed format preamble, will it be decoded successfully by non-HT clients?

Channel Switch Announcement

The 802.11h amendment (Spectrum and Transmit Power Management Enhancements in the 5 GHz band in Europe) introduced amechanism formoving a BSS to a different channel.  A Channel Switch Announcement element and a Channel Switch Announcement frame were defined along with a procedure for performing the channel switch.

However, with 11n 40 MHz channels, the channel switch announcement can be made before chaning channel or channel width. An AP that detects significant traffic from neighboring BSSs on the secondary channel, or significant traffic on the primary channel for that matter, could move the BSS to a channel pair with less traffic and/or narrow the operating channel width. However, the original Channel Switch Announcement element, designed for 20 MHz channels, could not handle the channel pairing used to create 40MHz channels.

To overcome these limitation and maintain backward compatibility, a new Extended Channel Switch Announcement element and Extended Channel Switch Announcement frame are defined. The new element and frame are flexible enough to support the requirements of both task groups. The Extended Channel Switch Announcement element includes a New Regulatory Class field to indicate the regulatory class of the new channel to which the BSS is switching.

The basic procedure for switching channels is as follows. The decision to switch channels is made by the AP and the AP should select a new channel that is supported by all associated stations. The AP informs associated stations that the BSS is moving to a new channel and/or changing operating channel width at some point in the future by including the Extended Channel Switch Announcement element in Beacon frames and Probe Response frames. It may also send out one or more Extended Channel Switch Announcement frames that include the Extended Channel Switch Announcement element.

The AP will attempt to schedule the channel switch so that all stations in the BSS, including stations in power save mode, have an opportunity to receive at least one Extended Channel Switch Announcement element before the switch. A scheduled channel switch occurs just before a target beacon transmission time (TBTT). The Channel Switch Count field indicates the number of TBTTs until the switch, including the TBTT just before which the switch occurs. A value of 1 indicates that the switch occurs just before the next TBTT.

An AP may indicate that the switch is to occur immediately (or anytime in the near future) by setting the Channel Switch Count value to 0. The AP may force stations in the BSS to stop transmissions until the channel switch occurs by setting the Channel Switch Mode field to 1.

Station Scanning Requirements in 2.4 Ghz 20/40 MHz BSS

In a 20/40 MHz BSS, HT stations are required to do scanning for the purpose of informing AP whether AP can continue to operate 20/40 MHz BSS or should dynamically switch it to 20MHz BSS. This scanning is required only for 2.4 GHz band.

Quick overview of  20/40 BSS Coexistence element

This element is present in the 20/40 BSS Coexistence Management frame and may also be present in Beacon, Association Request, Reassociation Request, Association Response, Reassociation response, Probe Request and Probe Response frames.

The Information Request field is used to indicate that a transmitting station is requesting that the recipient respond with a 20/40 BSS Coexistence Management frame.
The Forty MHz Intolerant field, when set to 1, prohibits the receiving BSS from operating a 20/40 MHz BSS.
The 20 MHz BSS Width Request field, when set to 1, prohibits the receiving AP from operating its BSS as a 20/40 MHz BSS.

Note: HT Capabilities IE also contain the Forty Mhz intolerant bit.

There are two ways STA can execute its job:

  • OBSS Scan: This scanning is intensive and is meant to affect the BSS in which client is associated. It is required to be done by active stations only. An AP can influence the scan by passing the OBSS Scan parameters IE to the station. After doing this scan, STA send an uni-cast "20/40 Coexistence Management Frame" with "20 MHz BSS Width Request" filed set to 1 to the AP with which it is associated. This "20/40 Coexistence Management Frame"  can contain 20/40 Intolerant Channel Report element to help the AP to reestablish the BSS. 

  • Affecting all/neighboring 20/40 MHz BSS: In this case, STA at its own wish can decide to affect 20/40 MHz operation by periodically broadcast a 20/40 BSS Coexistence Management frame containing a 20/40 BSS Coexistence element with the Forty MHz Intolerant bit set which indicates to any neighboring BSSs that they may not operate a 20/40 MHz BSS. After receiving this frame, AP switches 20/40 MHz BSS to 20 MHz for a certain time after that it again goes back to 20/40 MHz operation, if periodic broadcast a 20/40 BSS Coexistence Management frame suggest so.
Note: AP can also set "40 MHz Intolerant bit" in its HT capabilities to indicate to other APs for not operating  20/40 MHz BSS.

20/40 MHz BSS Operation

With 11n, three type of devices are possible:
  • 20 MHz Legacy / non-HT devices
  • 20 MHz HT devices
  • 20/40 MHz HT devices capable of 40 MHz operations.

Note: Channel Width capability is indicated using "Supported Channel Width" bit in HT Capabilities Information Element.

A BSS (11n AP) can operate in either of two modes:

  • 20 MHz BSS
  • 20/40 MHz BSS: It uses 20 MHz channels for communication with non-HT & 20 MHz HT and 40 MHz channel for 20/40 MHz HT devices.

However, a BSS can dynamically switch from one mode to another. Mode of BSS is reflected by "Secondary Channel Offset" & "STA Channel Width" in HT Information element. In 20Mhz BSS, both bits are zero and in 20/40 MHz BSS both bits are set to 1. Dynamic switching of mode is typically a requirement in 2.4 GHz band.

Primary Channel & Secondary Channel: 

40 MHz channels in 20/40 MHz BSS are not symmetric. Few frames (such as RTS/CTS, CTS-to-Self for protection, beacons) are limited to primary channel. Due to this, we have following recommendations for the establishment of the BSS:
  • 20 MHz BSS should not be established in the secondary channel of an existing 20/40 MHz BSS. As 40 MHz transmission will not be understandable by the clients of 20 MHz BSS.
  • It is recommended that the AP should not establish a 20/40 MHz BSS where the secondary channel is occupied by a 20 MHz BSS. Once the 20/40 MHz BSS has been established the AP may periodically scan the secondary channel for 20 MHz OBSSs (optional). This recommendation will help to choose secondary channel.
  • Matching Primary & Secondary channels for 20/40 MHz BSS: If an AP chooses to start a 20/40 MHz BSS that occupies the same two channels as an existing 20/40 MHz BSS then it must ensure that the primary and secondary channels of the new BSS match the primary and secondary channels of the existing BSS. This recommendation will help to choose primary channel.

  • AP informs about its primary & secondary channels in the HT Information element not in the HT capabilities as these are operating parameters.
  • Because of the limited bandwidth and overlapping 20 MHz channels, the rules for establishing a 20/40 MHz BSS in the 2.4 GHz band are more restrictive than for the 5 GHz bands

Beacon Transmission:
Beacon is always transmitted in a 20 MHz non-HT format on the primary channel (which is the only channel in the case of 20 MHz operation).
In the case of the 5 GHz bands, a non-HT OFDM format is used since all 802.11 devices using these bands are expected to be backward compatible with 802.11a. In the case of the 2.4 GHz band, a DSSS/CCK format is typically used since most devices are backward compatible with 802.11b. A non-HT OFDM format may be used in the 2.4 GHz band if the AP is only capable of, or only wishes to support, OFDM transmissions.

CCA on Secondary Channel of 20/40 MHz BSS:

Only energy detect is performed on the secondary 20 MHz channel. Full random backoff based on CCA on the secondary channel is not required.

A 20/40 MHz station gains an EDCATXOP for transmission on slot boundaries based on the 20 MHz primary channel CCA. The station shall, however, only transmit a 40 MHz PPDU if the secondary channel has been idle for at least a PIFS interval prior to the expiry of the backoff counter. If the secondary channel has not been idle for a PIFS interval then the station must restart its backoff count by selecting a random number in the same contention window as the previous backoff count.

NAV assertion in a 20/40 MHz BSS
An 20/40 MHz HT station updates its NAV using the Duration/ID field value in any frame received in a 20 MHz PPDU in the primary channel or received in a 40MHz PPDU. NAV is set if the RA of the received frame does not match the MAC address of the receiving station.
A station does not need to set its NAV in response to 20 MHz frames received on the  secondary channel even if it is capable of receiving those frames.

TXOP in a 20/40 MHz BSS

RTS/CTS should be send only on the primary channel.

Overlapping BSS (OBSS) scanning: 

Before an AP establishes a 20/40 MHz BSS it must scan for existing BSSs in the channels in the frequency range affected by the new BSS.

Friday, December 2, 2016

HT Information Element

The HT Information element contains operational parameters and hence dynamically controls the behavior of HT STAs in the BSS. Some fields in the HT Information element change dynamically with changes in the BSS.

To control the operation of stations on a BSS, the AP uses the HT Information element in Beacon, Probe Response, Association Response, and Reassociation Response frames. It is used only by AP not stations.

The AP also provides information on the capabilities of stations that are members of the BSS or, optionally, detected operating in the same channel(s). This enables protection for certain HT sequences a station may use but for which nearby station may not correctly defer.

Key Information provided by HT IE:

  • AP operating Channel & Channel Width allowed for Stations

  • RIFS Mode: Indicates whether or not RIFS is permitted with in the BSS. For example, the association of a legacy station would require the AP prohibit the use of RIFS.
  • MCS values supported by all HT STAs in BSS

  • STBC Parameters
  • HT Protection

  • Others:

  • Non-Greenfield HT STAs Present:This indicates that there are HT stations associated with the BSS or in neighboring BSSs that are unable to receive HT Greenfield format PPDUs. When set, stations must protect HT Greenfield format transmissions.
  • OBSS Non-HT STAs Present: This indicates that there may be non-HT stations present that are not members of the BSS. Astationmay optionally use this to determine if protection is necessary for HT sequences.
  • RIFS Mode: The AP can directly control whether or not RIFS bursting is permitted through the RIFS Mode bit. Stations may only use RIFS bursting when this bit is set to 1.

HT Capabilities Information Element

HT Capabilities information element contains fields that are used to advertise the optional capabilities of the HT station or HT AP. The HT Capabilities element is always present in the Beacon, Association Request, Association Response, Re-association Request, Re-association Response, Probe Request, and Probe Response frames of HT AP & HT stations.

Key Information from HT Capabilities IE:
  • AMPDU Parameters: Through this a HT node indicates its support for A-MPDU especially indicating the number of buffers dedicated to receive A-MPDU. Using this a receiver may also specify a minimum expected duration between MPDUs in an A-MPDU.
  • Supported MCS Set:  It indicates the MCSs supported by the station for transmit and receive.
  • HT Capabilities Info & HT Extended Capabilities: Both (each 16 bits) indicates the support for different HT capabilities of the node. The later was added for the expansion as the former bits were not sufficient. While the former is fully used the later has still many bits reserved for future use.

Key Capabilities indicated by HT Capabilities Info bits:
  • Supported Channel Width: Actual channel in use will be indicated by HT Information element.

  • Support for 11n Power Save Modes:

  • Support for Short GI

  • Enforcing not to do 40MHz transmission (intolerant)

  • Support for  Transmitting / Receiving STBC
  • AMSDU Length Information

Key Capabilities indicated by HT Extended Capabilities bits:

Where does the client indicates the antennas count it supports?

Thursday, December 1, 2016

Understanding QoS Control IE: Contains 802.11e Standard's Features

In this post, we will decode the QoS control IE. As QoS was introduced in 802.11e, this IE is loaded with the functionalities introduced in 802.11e. A quick recap of what was introduced in 802.11e:

  • QoS: Defines 8 priority levels (lower 4 priorities used for EDCA) . Hence, traffic needs to carry this information.
  • UAPSD: Lead to introduction of End-of-Service-Period (EOSP) field. 
  • Block ACK: Lead to introduction of ACK policy field which can take one of the four values:
    • Normal ACK or Implicit BAR
    • No ACK
    • No Explicit Acknowledgement or Scheduled Ack under PSMP
    • Block ACK
  • TXOP / Queue Size related fields
QoS Control field is available in QoS data packets i.e. data packets of QoS subtype. As we can see below, there are 15 type of data frames (source).  Frame exchanges b/w QoS stations will be QoS data frames whereas b/w legacy devices or b/w QoS & legacy device will be non-QoS frames.

Features introduced by 802.11h:
  • DFS
  • UNII-2e band
  • Action frames

Wednesday, July 27, 2016

Ethernet II (DIX) vs 802.3 with LLC vs 802.3 with LLC/SNAP

In wireless header there is no field specified as Ether Type which means when an Ethernet frame is converted to wireless frame then some additional header (SNAP) is required to hold the ether type.

Lets look at different Ethernet frames first: (Cisco Link)

  • Ethernet II or DIX Frames:
    • Most popular
    • Ether Type is used for indicating upper layer protocol.
    • Exists prior to standardization work started by IEEE.
  • IEEE 802.3 Skeleton:
    • Treats ether type as length instead of protocol
    • Just a skeleton (as there is no field to indicate upper layer protocol)
    • Used to hold IEEE standardized Ethernet frames (discussed next).
  • IEEE 802.3 with 802.2 LLC
    • Define 3 bytes LLC header (DSAP, SSAP, Control) taken from HDLC.
    • DSAP & SSAP refers to Destination SAP & Source SAP.
    • DSAP and SSAP are just one byte field and hence not capable to hold upper protocol type (need 2 bytes for that). IEEE introduced SNAP header to remove this limitation. 
  • IEEE 802.3 with 802.2 LLC/SNAP
    • DSAP & SSAP of LLC header are fixed to 0xAA and control field is fixed to 0x03.
    • SNAP header is of 5 bytes (3 bytes for OUI & 2 bytes for specifying protocol)
    • In wireless frame, OUI is 00-00-00.
Note: Ether Type > 1536 (0x600) indicates the Ethernet II frame.

Tuesday, April 19, 2016

4 Way Key Handshake Packet Capture

  • Message 1

After receiving message 1 from AP, Client generates PTK. This PTK (512 bit) is split into five pieces 5 separate session keys. 

    • Key Confirmation Key (KCK) is 128 bits long: Used in key(2/4) to calculate MIC of Key Data (RSN IE).
    • Key Encryption Key (KEK), 128 bits: Used in key(3/4) to encrypt GTK
    • Temporal Key (TK) 128 bits: Used to encrypt data packets.
    • Two shorter keys Rx and Tx used for providing Message Authentication Codes (MACs), both 64 bits long.

Using KCK, station calculates MIC of Key data (RSN IE) and send it to AP (in Message 2) for validation along with its own SNONCE.

  • Message 2

After receiving this message, AP calculates PTK and validates the MIC of key data to validate the correctness of the key with the client. If it matches then the station possesses the key. 

  • Message 3
Now its the turn of AP to validate itself to the station. AP prepares key data (which has GTK along with other information) which is encrypted using KEK and MIC is calculated. Since, station possess the keys it can decrypt key data. 

  • Message 4
Its the confirmation for keys installation. Key data is of zero length.