DCF- Distributed Coordination Function : Non-QoS WLAN
HCF with EDCA – Hybrid Coordination Function : QoS WLAN
EDCA- Enhanced Distributed Channel Access
PCF – Point Coordination Function (not implemented practically)

Physical Carrier Sense: Layer 1 – Clear Channel Assessment (CCA)
– ED (Energy Detection)
– CS (Carrier Sense or Preamble detection)
Virtual Carrier Sense  : Layer 2 – Network Allocation Vector (NAV) – Duration value set in each frame’s MAC header where other stations set their NAV to this if the sense medium is busy.

These are the steps a station go through prior to transmit a frame to the wireless medium
1. STAs use a physical carrier sense (Clear Channel Assessment—CCA) to determine if the wireless medium is busy.
2. STAs use virtual carrier sense (Network Allocation Vector—NAV) to detect if the medium is busy. When the virtual timer (NAV) reaches zero, STAs may proceed.
3. If conditions 1 and 2 are met, STAs wait the necessary IFS interval, as prescribed by the protocol.
4. If conditions 1 and 2 are met through the duration of condition 3, STAs generate a random backoff number in accordance with the range of allowed values.
5. STAs begin decrementing the backoff timer by one for every slot time duration that the wireless medium is idle.
6. After decrementing the backoff value to zero, with an idle medium, a STA may transmit the allotted frame exchange, in accordance with the parameters of the obtained transmission opportunity (TXOP).
7. If another STA transmits before Step 6 is completed, STAs observe steps 1, 2, 3, and 5 until the backoff timer is equal to zero.
8. After a successful transmission, repeat as needed. Below diagram show the flow of the above steps (source : 802.11 Arbitration CWNP white paper)

Inter Frame Spaces
After each frame transmission 802.11 protocol require an idle period on the medium called Inter Frame Space (IFS). The length of the IFS is depend on previous frame type, following frame type, access category, coordination function in use & PHY type as well. The purpose of an IFS is both to provide a buffer between frames to avoid interference as well as to add control and to prioritize frame transmissions.

SIFS (Shortest Inter Frame Space)
SIFS are used within all of the different coordination functions. For 802.11-2007, SIFS is the shortest of the IFSs and is used prior to ACK and CTS frames as well as the second or subsequent MPDUs of a fragment burst. However, with 802.11n, a shorter IFS (RIFS) was introduced.

SIFS for 802.11b/g/n (2.4 GHz) = 10μS
SIFS for 802.11a/n/ac (5 GHz)  = 16μS

RIFS (Reduced Inter Frame Space)
RIFS were introduced with 802.11n to improve efficiency for transmissions to the same receiver in which a SIFS-separated response is not required, such as a transmission burst (CFB-Contention Free Burst)

RIFS = 2μS

802.11n standard use RIFS & Block Acknowledgement (mandatory in 802.11n). RIFS is used only when Block ACK is enabled. When Block ACK are used, data frames of a CFB may send consecutively without interruption by ACK. At the end of CFB, Tx Station will simply send BAR (BlockACKRequest) & receiving a single Block Acknowledgement (BA).

Below shows the use of RIFS during a 802.11n frame transmission. (page 260 CWAP study guide). Note that AIFS used initially as of QoS Data frames.

DIFS (Distributed Inter Frame Space)
When a STA desires to transmit a data frame (MPDU) or management frame (MMPDU) for the first time within a DCF network, the duration of a DIFS must be observed after the previous frame’s completion. The duration of a DIFS is longer than both the SIFS and PIFS.

DIFS = SIFS + 2x SlotTime

SlotTime for 802.11a/n/ac (5 GHz) = 9μS
SlotTime for 802.11g/n (2.4 GHz – HT or ERP) = 9μS  with short preamble
SlotTime for 802.11g/n (2.4 GHz – HT or ERP) = 20μS with long preamble
SlotTime for 802.11b/g/n (2.4 GHz – DSS ) = 20μS

EIFS (Extended Inter Frame Space)
The EIFS value is used by STAs that have received a frame that contained errors. By using this longer IFS, the transmitting station will have enough time to recognize that the frame was not received properly before the receiving station commences transmission. If, during the EIFS duration, the STA receives a frame correctly (regardless of intended recipient), it will resume using DIFS or AIFS, as appropriate

EIFS (in DCF)  = SIFS + DIFS + ACK_Tx_Time

EIFS 802.11b/g/n devices using DSS = 364μS
EIFS 802.11g/n devices using OFDM = 160μS
EIFS 802.11a/n devices (5GHz)         = 160μS

EIFS (in EDCA)  = SIFS + AIFS[AC] + ACK_Tx_Time

Below diagram show the arbitration process after receipt of  a corrupted frame, where all other stations (except the transmitter) wait for EIFS.

Near/Far Problem: Due to side effect of EIFS, stations near to AP could cause problem to stations at Far(hence called Near/Far problem). When data send between AP & near by stations, they can use high data rates where far stations cannot be demodulate & interpret as corrupted frame. So far stations stay quiet for EIFS, while the near station will be allowed to use DIFS or AIFS. The use of DIFS will give nearby station higher priority & get more opportunity to transmit while far station remain quiet.

PIFS (PCF Inter Frame Spaces)
PIFS are used by STAs during the contention-free period (CFP) in PCF mode. Because PCF has not been implemented in 802.11 devices, you will not see PIFS used for this purpose. In order to gain priority over other STAs during contention, the AP can transmit a Channel Switch Announcement (802.11h) frame after observing a PIFS

PIFS = SIFS + SlotTime

Below chart summarize SIFS,DIFS,PIFS & SlotTime values described earlier.

AIFS (Arbitration Inter Frame Space)
The AIFS shall be used by QoS STAs to transmit all data frames (MPDUs), all management frames (MMPDUs), and the following control frames: PS-Poll, RTS, CTS (when not transmitted as a response to the RTS), BlockAckReq, and BlockAck (when not transmitted as a response to the BlockAckReq).

The number of slot times used in the AIFS is called the Arbitration Inter Frame Space Number (AIFSN). 802.11e specifies 4 access categories (AV_VO : Voice, AC_VI : Video, AC_BE : Best Effort & AC_BK : Background). Voice & Video category use 2 slottimes by default. Best Effort category use 3 slottimes where as Background traffic use 7 slottimes by default.

Below is the formula to calcluate AIFS for  a given Access Category (AC)

AIFS[AC] = AIFSN[AC] × SlotTime + SIFSTime

Contention Window/Backoff Timer
After a STA has observed an idle wireless medium with carrier sense (CS) for the appropriate IFS interval (DIFS, EIFS, or AIFS). To contend for medium access after the IFS, each station selects a backoff value called random backoff period and is selected at random by the STA from a window of possible values called a contention window (CW)  calculated using the below formula where x is a value increments with each failed frame.

CW = 2^x -1

For DSS based networks x starts at 5 which resulting CW of 31, for OFDM based networks, x starts at 4 which result in a CW of 15. In both DSS & OFDM x values stops incrementing at 10 which  result CW of 1023. Below table summarize these values for DCF network.

In EDCA medium access (QoS stations & AP), each AC has a CW_min & CW_max. These default values are derived from the following formula.

For example, in OFDM aCWmin is 15. This result CWmin for AC_VO =3 {[(15+1)/4] – 1} & CWmax for AC_VO=7 {[(15+1)/2]-1}. In the same way CWmin for AC_VI=7 {[(15+1)/2] -1} & CWmax for AC_VI=15. For AC_BE & AC_BK those values are 15 & 1023 respectively.

For an initial attempt at a frame transmission, the CW is the aCWmin value.For each attempted retransmission, the CW is increased exponentially until the CW reaches the aCWmax. In this case, the CW remains at the aCWmax until a successful frame sequence is performed or the number of attempted retransmissions reaches the max retry count. Below diagram shows this concept

TXOP- Transmit Opportunity
EDCA introduce this TXOP which is a time period where one device, called TXOP holder has unfettered acccess to the channel for data transmission. The data frame transmissions within  a TXOP are called a “contention free burst -CFB” During a TXOP, only the data that makes up a CFB and the ACK for that data may access the channel.

802.11e standard defines default TXOP limit value for each AC, but values can be configured on AP. TXOP limit are set in intervals of 32µs (microseconds). Default TXOP is 47 for AC_VO (47×32=1504µs) for OFDM. It is 94 for AC_VI (94×32=3008µs) . Note that for AC_BE & AC_BK always TXOP set to 0, in other words those traffic category always has to send one frame at at time (no CFB).

Here is the default settings (AIFSN, CW_min, CW_max, x value, TXOP, AIFS) of those four access categories.

Here is a beacon frame of a 802.11a radio where you can see those default settings as well.

As explained these EDCA value can be configurable on AP. Here is on my Cisco WLC (3850) I have changed the default setting to optimized Voice & Video. “wmm-default” is the default setting in this WLC.

3850-1(config)#ap dot11 5ghz shutdown 
3850-1(config)#ap dot11 5ghz edca-parameters ?
  custom-voice           Enable Custom Voice parameters for 802.11a
  optimized-video-voice  Enable combined video-voice-optimized parameters for 802.11a
  optimized-voice        Enable non-spectralink voice-optimized parameters for 802.11a
  svp-voice              Enable SpectraLink Voice Priority (SVP) parameters for 802.11a
  wmm-default            Enable WMM default parameters for 802.11a
3850-1(config)#ap dot11 5ghz edca-parameters optimized-video-voice 
3850-1(config)#no ap dot11 5ghz shutdown

3850-1#show ap dot11 5ghz network | in EDCA
EDCA profile type check : optimized-video-voice 

Once you change this, you can see AP advertising these values on WMM parameters & you can see values change to give priority for Voice & Video.

Here is a beacon frame capture showing those modified values.

Reference
1. CWAP Official Study Guide – Chapter 7
2. 802.11 Arbitration – CWNP White Paper

There are 15 different types of Data Frames defined in IEEE 802.11-2007 standard. Data frames with a value of 1 in the QoS subfield of the Subtype field (Bit7) are collectively referred to as QoS data frames. Each of these data subtypes contains QoS in their names, and this frame format is distinguished by the presence of a QoS Control field in the MAC header.

A QoS STA always uses QoS data frames for data transmissions to other QoS STAs. A QoS STA uses frames with the QoS subfield of the Subtype field set to 0 for data transmissions to non-QoS STAs. A non-QoS STA always uses frames with the QoS subfield of the Subtype field set to 0 (Bit7) for data transmissions to other STAs.

All STAs use frames with the QoS subfield of the Subtype field set to 0 (Bit7) for broadcast data frames unless a transmitting STA knows that all STAs in a BSS have QoS capability, in which case the transmitting STAs use QoS data frames.

Below table summarize all Data Frame types. Each bit of the Subtype field indicate different type of Data frames (eg Bit7=1 QoS , Bit6=1 Null frame, Bit5=1 CF-Poll  & Bit4=1 CF-ACK)

In wireshark you can filter all Data frame using below filter (Type =2)

wlan.fc.type == 2

Data:
In Non-QoS  Data frames there is no QoS control field present in the MAC header. Below shows a simple data frame which you can filter using below ( Type 2 , subtype 0). In this frame To DS & From DS field set to 1 & therefore used 4 addresses field in MAC header (Typically all other scenarios, 3 addresses field use in MAC header)

wlan.fc.type_subtype == 0x0020

Data + CF-ACK :

wlan.fc.type_subtype == 0x0021

Data + CF-Poll :

wlan.fc.type_subtype == 0x0022

Data + CF-Ack + CF-Poll :

wlan.fc.type_subtype == 0x0023

Null Data :
Here is a Null (no data frame). In this case this frame is used to indicate client is going to Power Save mode sending this to AP by the client ( Note that Power Mgmt bit set to 1 in Frame Control)

wlan.fc.type_subtype == 0x0024

CF-ACK (no data):

wlan.fc.type_subtype == 0x0025

CF-Poll (no data):

wlan.fc.type_subtype == 0x0026

CF-ACK + CF-Poll (no data) :

wlan.fc.type_subtype == 0x0027

QoS Data:
Here is a QoS Data frame Where subtype is 8. Note that QoS control field in the MAC header.

wlan.fc.type_subtype == 0x0028

QoS Data + CF-Poll:

wlan.fc.type_subtype == 0x002a

QoS Data + CF-ACK + CF-Poll:

wlan.fc.type_subtype == 0x002b

QoS Null Data :

wlan.fc.type_subtype == 0x002c

Rerved Data Frame:

wlan.fc.type_subtype == 0x002d

QoS Data + CF-Poll (no data):

wlan.fc.type_subtype == 0x002e

QoS CF-ACK + CF-Poll (no data):

wlan.fc.type_subtype == 0x002f

References
1. CWAP Official Study Guide – Chapter 6

Related Posts

1. 802.11 Management Frame Types
2. 802.11 Control Frame Types

A wireless radio can perform one of the 4 activities. Power consumed by each activity increases in the given order ( 1-4).

1. Asleep
2. Idle & awake
3. Receiving
4. Transmitting

There are 3 methods of power management used in 802.11
1. 802.11 Power Management
2. Unscheduled Automatic Power Save Delivery (U-APSD) from 802.11e amendment
3. Power Save Multi-Poll (PSMP) from 802.11n amendment.

In any of the above method basic power management structure summarized into 4 steps
1. Before a STA goes into the doze state, it sends a frame, usually null data frame, to the AP indicating that power management is enabled.
2. Once STA indicate, that it is in Power Save mode, the AP begins to buffer all frames destined to that station.
3. When the station goes into awake state, it sends a frame to the AP in order to begin the data retrieval process.
4. When AP has finished sending all buffered data to the station, the station goes back into the doze state.

Every 802.11 power management method begin when the STA associates to the BSS. When AP send “Association Response” frame to the STA, an Association Identifier (AID) value present in the AID fixed parameter field (16 bit) as shown below. AID is presence in Association Response or Reassoication Response frames.

STA is allowed to go to “doze” state after the AP has been notified that station is about to enter power save mode. STA will use null data frame with Power Management bit set to 1  as shown below.

Stations will wake up from doze state for one of the 3 reason
1. if station has a frame to send
2. based on STA internal timing mechanism.

Traffic Indication Map (TIM)
TIM is an information element & it has below structure.

Element ID (1 byte) : Value 5 indicate it is a TIM
Length       (1 byte) : Length of the info carrying fields (DTIM count, DTIM Period, Bitmap Control, Partial Virtual Bitmap)
DTIM Count (1 byte) : Incremental beacon frames until the next DTIM.
DTIM Period (1 byte) : number of beacon frames between DTIM beacon.
Bitmap Control (1 byte) : to indicate multicast/broadcast are buffered at the AP & use as space save (bitmap offset)
Partial Virtual Bitmap(1-251 byte) : Series of flags indicating whether each associated STAT has unicast frames buffered at the AP. Each bit in this filed corresponds to a AID of a STA.

Here is a TIM information element in a beacon frame. Note that DTIM period is 3 in the below, which mean every 3 beacon one DTIM will be advertised. DTIM count is 2 indicating in 2 beacon time there will be a DTIM

In bitmap control field, first bit set to 1 that indicate buffered traffic at AP is broadcast or multicast. Remaining 7 bits used as Bitmap Offset, which may have any value  between 0 to 127 used as a space saver. For an example, if there is no buffered traffic to AID1-70 then all those values are 0 in Partial Virtual Bitmap section. To save some space, you can use Bitmap offset value to indicate how many bytes are Zero in Partial Virtual Bitmap (PVB). Let’s say Bitmap Offset is N, then 2xN bytes are zero in PVB. In hour case N=4 where 8 bytes (or 64 bits) can be zero & those 64 bits can be skipped by setting Bitmap Offset value to 4.

Delivery Traffic Indication Message (DTIM)
DTIM beacon is identical in structure to the ordinary beacon. The only difference is tha the content of the TIM IE will give information about broadcast/multicast traffic that is buffered at the AP, in addition to  the typical information about buffered unicast frames that is always present in the TIM.

Below shows a DTIM beacon where DTIM count set to 0. If broadcast/multicast traffic buffered at the AP the first bit of Bitmap Control set to 1, otherwise 0 (which is the case in this DTIM)

802.11 Power Management:
In legacy (802.11 standard) power management is uese,  the STA never sends a frame with power management flag set to 0. It is always set to 1 (figure 8.6) & then AP send a buffered frame. In this method, when station return to “doze”mode STA does not notify the AP, & AP has to always buffered frame intend to that STA.

When Power Save Poll ( PS-Poll) frames are used in 802.11 power management, then STA has to send a PS-Poll control frame to request AP to send a buffered unicast frame. In that frame if AP set “more data” bit to 1 the STA understand AP has more data to send & therefor remain in awake state & send another PS-Poll frame to get next frame.802.11 power management has two major limitations
1. Additional overhad added to wireless channel (decrease throughput)
2. STA must spend too much time in Transmitting state.

802.11e U-APSD :
This is introduced in 802.11e amendment & part of WMM-Power Save certification as well.

In this method, a STA typically sends a null data frame in order to  retrieve buffered unicast frame from AP. Power Mgmt bit set to 0 in this frame (indicated STA in Active mode). Note that in this method, AP will send ALL buffered unicast frames to that STA.

When STA goes into Power Save mode, it has to send another null data frame with power management bit set to 1.

802.11n Power Management :
1. PSMP – Power Save Multi-Poll
This is a power management method that builds on schedulded automatic power save delivery (S-APSD) for network that use HCF Controlled Channel Access (HCCA)

2. SMSP-  Spatial Multiplexing Power Save
SMSP involves STA reducing the number of data streams used during spatial multiplexing. SMSP will temporarily disabling spatial multiplexing to conserve battery life.

IBSS Power Management
In IBSS (ad hoc network) there is no AP to send TIM or DTIM. So if a STA goes into power save mode multiple other STAs has to buffer its data for specific STA. So in IBSS, Announcement Traffic Indication Message (ATIM) is use for power management. It is a management frame with no frame body. When a STA receives ATIM, that formally dozing station must begin the process of retrieving buffered frame from the stations that transmitted the ATIM.

References:
1. CWAP Official Study Guide – Chapter 8

802.11 Physical (PHY) layer is divided into two sublayers
1. PLCP (Physical Layer Convergence Procedure) sublayer
2. PMD (Physical Medium Dependent) sublayer

The PLCP prepare the frame for transmission by taking the frame from the MAC sublayer & creating PLCP Protocol Data Unit (PPDU). PMD sublayer then modulates and transmits the data as bits. When the MAC Protocol Data Unit (MPDU) is handed down to the physical layer it is then referred to as PLCP Service Data Unit (PSDU). Note that PSDU & MPDU is refer to the same as it is depend on from which sublayer perspective you looking ( PSDU from PHY sublayer & MPDU from MAC sublayer)

When PLCP receives PSDU, it then prepares the PSDU to be transmitted & creates PPDU. The PLCP adds a preamble and PHY header to the PSDU. Below diagram shows the upper layer information moving between the Data-Link & Physical layer.(Page 39 – CWAP Official Study Guide)

PLCP Protocol Data Unit (PPDU)
The PPDU consist of 3 parts.
1. PLCP Preamble
2. PLCP Header
3. PSDU

When the PLCP layer receives the PSDU from the MAC layer, the appropriate PLCP Preamble & PLCP Header are added to the PSDU to create PPDU. When transmitting data, the Tx STA alerts the Rx STA of transmission by sending PLCP Preamble at the beginning of transmission. IEEE 8021.11-2007 define 3 different preambles
1. Long PLCP Preamble
2. Short PLCP Preamble
3. OFDM PLCP Preamble

802.11n amendment further defines 3 additional preambles in 3 different PPDU.
1. non-HT legacy PPDU
2. HT-mixed PPDU
3. HT-Greenfield PPDU

Long PLCP Preamble.

Short Preamble PPDU.

Comparison between Long PPDU & Short PPDU is as shown below

OFDM PLCP Preamble.
– Also known as OFDM training structure
– consist of 10 short symbols (t1-t10) & 2 long symbols (T1-T2).
– GI2 is long guard interval.
– Following the PLCP preamble SIGNAL & DATA field each with GI preceding them.
– total training length is 16μS
– short OFDM training symbol consist of 12 subcarriers.
– long OFDM training symbol consists of 53 subcarriers.

PLCP Header
Long & Short PLCP Header contain following 4 files
1. Signal (8bits) – indicate which modulation method will be used for PSDU/MPDU.
2. Service (8bits) – 5 out of 8 bits are used
Bit 3 to indication modulation method (0 – CCK: Complementary Code Keying, 1- PBCC: Packet Binary Convolution Code)
Bit 2 to indicate Transmit Frequency & Symbol clock dreived from same clock.
Bit 5-7 to resolve data length field ambiguities for ERP-PBCC-11 to ERP-PBCC-33
Bit 7 also used to supplement Lenght field for CCK 11Mpbs.
3. Length (16 bits) – Indicate number of microseconds (μS) that are required to transmit the PSDU.
4. CRC (16bits) – Provide Protection for other 3 fields (signal, service & length)Lo

In OFDM transmission, SIGNAL field is 24 bits long.
– First 4 bits (0-3) indicate the data rate (6,9,12,18,24,36,48,54).
– Next bit (bit 4) is reserved for future use
– Next 12 bits (bit 5-16) make up the PLCP Length field which indicate number of bytes in the PSDU.
– Bit 17 will be parity bit for 0-16 bits.
– Last 6 bits (bit 18-23) make up the SIGNAL TAIL with all 6 bits set to 0.

802.11n PPDU
Non-HT PPDU
– Consist of preamble that uses short & long training symbols (10 STF & 2 LTF).
– Support for non-HT legacy format is mandatory for 802.11n radios.
– non-HT transmit only in 20MHz channels.(same format used by 802.11a & 802.11g

HT-Mixed PPDU
– Preamble contain the non-HT short & long training symbol that can be decoded by legacy 802.11a (clause 17) or 802.11g (clause 19)
-Rest of the HT-mixed preamble & header cannot be decoded by legacy clients.
– Tranmission can occur both 20MHz & 40MHz.
– When 40MHz channel is used all broadcast traffic must be sent on legacy 20MHz (for legacy clients)

HT-greenfield PPDU
– Preamble not compatible with legacy clients.

References
1. CWAP Official Study Guide – Chapter 2

2.4GHz (2.4000 GHz to 2.4835 GHz)

- 802.11 (FHSS clause 14 or DSS clause 15 radios)
– 802.11b (HR-DSSS clause 18 radios)
– 802.11g (ERP  clause 19 radios)
– 802.11n (HT clause 20 radios)

In addition to being used by wireless networking equipment, 2.4GHz ISM band is also used by microwave oven, cordless phones, baby monitors, wireless video camera & other devices.According to 802.11 standard legacy DSSS channels had to have at least 30MHz of spacing between center frequencies to be considered non-overlapping. So CH1, CH6 & CH11 were considered as overlapping as they separated by 25MHz.

Under HR-DSSS (802.11b) which states channels need a minimum of 25MHz of separation between center frequencies to be considered non-overlapping. So in 802.11b CH1, CH6 & CH11 are non-overlapping.

ERP-DSSS & ERP-OFDM (802.11g) also require 25MHz separation. So under 802.11g CH1 , CH6 & CH11 considered to be non-overlapping.

Transmit Spectrum Mask (DSSS & HR-DSSS)
– first side band frequency (-11MHz to -22MHz  & +11MHz to +22MHz from center) must be at least 30dB less than the main frequency.
– any additional sideband carrier frequencies (-22MHz  & + 22MHz from center frequency) must be at least 50dB less than the main frequency.

Below shows the level of interference at particular level of signal reception level. It is important to separate AP,so that interference from sideband frequencies does not occur.

5 GHz (Unlicensed National Information Infrastructure – UNII bands)
– 802.11a defined 3 UNII bands 100MHz wide each & 4 CH in each UNII band.
1. UNII-1 (5.150-5.250 GHz)
2. UNII-2 (5.250-5.350 GHz)
3. UNII-3 (5.725-5.825 GHz)

-802.11h (DFS & TPC) adds UNII-2 Extended 255MHz wide (additional 11 CH)
4. UNII-2 Extended (5.470 -5.725 GHz)

- The centers of the outermost channels must be 30MHz from the band’s edge in the UNII-1 & UNII-2 & must be 20MHz in the UNII-3 band.
–  There are 4 non-overlapping channel in above 3 UNII bands with 20MHz separation between center frequencies.
– Centre frequency of each channel (eg 36,40,…100, ..161,165) can be calculated as (5000+5x N_CH) in MHz. Eg CH100 center frequency is 5.500 (5000+5×100)

- IEEE does not specifically define a channel width for 5GHz, however the spectral mask of an OFDM channel is approximately 20MHz.
– Clause 17 OFDM, required only 20MHz of separation between the center frequencies to be considered as non-overlapping (hence all 23 CH are non overlapping)

Adjacent Channel
– Any channel with non-overlapping frequencies for DSS & HR-DSSS PHYs.
– First channel with a non-overlapping frequency space for ERP & OFDM.

When you are troubleshooting wireless client connectivity issues there is a one command you always need to use. “debug client <client_mac_address>” output will tells you what’s going on. To identify the issues, you have to know how this output looks like when it is working. So in this post we will have a look on this debug output for an open authentication SSID & in a different post we will look at similar output for WPA2-PSK & 802.1X-EAP authentication in used.

In Open Auth SSID connection steps are as follows.

1. Open System Authentication (Request)
2. Open System Authentication (Response)
3. Association Request
4. Association Response
5. Client send DHCP Discovery
6. Client receive DHCP Offer
7. Client send DHCP Request
8. Client receive DHCP ACK

In this post I have taken wireless packet capture to compare it with the debug output. But once you are familiar with the process you should be able to identify any abnormalities just look at the debug output.

Here is the Open System Authentication frame exchange between client & AP. Note that first authentication frame sent by client (with auth seq#1) & then AP respond with second authentication frame with (auth seq#2 & status code=0 successful).

Once Open System Authentication completes client send the Association Request frame to the AP. Here is the Association Request frame where client specify the SSID to join & other capabilities like data rates, power capability,etc

Here is my “debug client 04:f7:e4:ea:5b:66” output from my WLC related to the above steps. I am using WLC code 8.0.100.0 & if you are using other codes output may be different depend on the code capability. You will see the AP name, BSSID, details where the client send Association Request frame.

Client state is moved from “START(0)” to “AUTHCHECK(2)” to “L2AUTHCOMPLETE(4)“

12:42:25.393: 04:f7:e4:ea:5b:66 Processing assoc-req station:04:f7:e4:ea:5b:66 AP:1c:6a:7a:bc:4d:60-01 thread:150e53e0
12:42:25.393: 04:f7:e4:ea:5b:66 Adding mobile on LWAPP AP 1c:6a:7a:bc:4d:60(1) 
12:42:25.393: 04:f7:e4:ea:5b:66 Association received from mobile on BSSID 1c:6a:7a:bc:4d:5d AP TEST-AP
12:42:25.393: 04:f7:e4:ea:5b:66 Global 200 Clients are allowed to AP radio
12:42:25.394: 04:f7:e4:ea:5b:66 Max Client Trap Threshold: 0  cur: 1
12:42:25.394: 04:f7:e4:ea:5b:66 Rf profile 600 Clients are allowed to AP wlan
12:42:25.394: 04:f7:e4:ea:5b:66 override for default ap group, marking intgrp NULL
12:42:25.394: 04:f7:e4:ea:5b:66 Applying Interface policy on Mobile, role Unassociated. Ms NAC State 0 Quarantine Vlan 0 Access Vlan 0
12:42:25.394: 04:f7:e4:ea:5b:66 Re-applying interface policy for client 
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2385)
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2406)
12:42:25.394: 04:f7:e4:ea:5b:66 apfApplyWlanPolicy: Apply WLAN Policy over PMIPv6 Client Mobility Type
12:42:25.394: 04:f7:e4:ea:5b:66 In processSsidIE:5680 setting Central switched to TRUE
12:42:25.394: 04:f7:e4:ea:5b:66 In processSsidIE:5683 apVapId = 2 and Split Acl Id = 65535
12:42:25.394: 04:f7:e4:ea:5b:66 Applying site-specific Local Bridging override for station 04:f7:e4:ea:5b:66 - vapId 19, site 'LTU-APG1', interface 'vlan1422'
12:42:25.394: 04:f7:e4:ea:5b:66 Applying Local Bridging Interface Policy for station 04:f7:e4:ea:5b:66 - vlan 1422, interface id 13, interface 'vlan1422'
12:42:25.394: 04:f7:e4:ea:5b:66 override from ap group, removing intf group from mscb
12:42:25.394: 04:f7:e4:ea:5b:66 Applying site-specific override for station 04:f7:e4:ea:5b:66 - vapId 19, site 'LTU-APG1', interface 'vlan1422'
12:42:25.394: 04:f7:e4:ea:5b:66 Applying Interface policy on Mobile, role Unassociated. Ms NAC State 2 Quarantine Vlan 0 Access Vlan 1422
12:42:25.394: 04:f7:e4:ea:5b:66 Re-applying interface policy for client 
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2385)
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2406)
12:42:25.394: 04:f7:e4:ea:5b:66 processSsidIE  statusCode is 0 and status is 0 
12:42:25.394: 04:f7:e4:ea:5b:66 processSsidIE  ssid_done_flag is 0 finish_flag is 0
12:42:25.394: 04:f7:e4:ea:5b:66 STA - rates (4): 176 72 96 108 0 0 0 0 0 0 0 0 0 0 0 0
12:42:25.394: 04:f7:e4:ea:5b:66 suppRates  statusCode is 0 and gotSuppRatesElement is 1 
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Initializing policy
12:42:25.394: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state START (0)
12:42:25.395: 04:f7:e4:ea:5b:66 0.0.0.0 AUTHCHECK (2) Change state to L2AUTHCOMPLETE (4) last state AUTHCHECK (2)
12:42:25.395: 04:f7:e4:ea:5b:66 Not Using WMM Compliance code qosCap 00

Then AP will send Association Response to the client with status code 0 (successful) Once client associated to the network they move onto “DHCP_REQD (7)” state. Note that AP will give AID (Association ID) to each client uniquely identify them within the cell. In my client got AID of 2.

Here is the WLC debug output where you can see the Association Response frame send to client.

12:42:25.395: 04:f7:e4:ea:5b:66 Sending 11w Flag 0 for Client 04:F7:E4:EA:5B:66 
12:42:25.395: 04:f7:e4:ea:5b:66 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP 1c:6a:7a:bc:4d:60 vapId 19 apVapId 2 flex-acl-name: 
12:42:25.395: 04:f7:e4:ea:5b:66 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state L2AUTHCOMPLETE (4)
12:42:25.395: 04:f7:e4:ea:5b:66 apfMsAssoStateInc
12:42:25.395: 04:f7:e4:ea:5b:66 apfPemAddUser2 (apf_policy.c:352) Changing state for mobile 04:f7:e4:ea:5b:66 on AP 1c:6a:7a:bc:4d:60 from Idle to Associated
12:42:25.395: 04:f7:e4:ea:5b:66 apfPemAddUser2:session timeout forstation 04:f7:e4:ea:5b:66 - Session Tout 0, apfMsTimeOut '0' and sessionTimerRunning flag is  0 
12:42:25.395: 04:f7:e4:ea:5b:66 Stopping deletion of Mobile Station: (callerId: 48)
12:42:25.395: 04:f7:e4:ea:5b:66 Func: apfPemAddUser2, Ms Timeout = 0, Session Timeout = 0
12:42:25.395: 04:f7:e4:ea:5b:66 Sending assoc-resp with status 0 station:04:f7:e4:ea:5b:66 AP:1c:6a:7a:bc:4d:60-01 on apVapId 2
12:42:25.395: 04:f7:e4:ea:5b:66 Sending Assoc Response to station on BSSID 1c:6a:7a:bc:4d:6e (status 0) ApVapId 2 Slot 1
12:42:25.395: 04:f7:e4:ea:5b:66 apfProcessAssocReq (apf_80211.c:9452) Changing state for mobile 04:f7:e4:ea:5b:66 on AP 1c:6a:7a:bc:4d:60 from Associated to Associated

Once Association complted you would see the client try to get an IP address. In 802.1X/EAP you would see EAP Authentication process & 4-Way handshake prior to this. But in this case we use no 802.1X authentication & once client completes Open System Authentication/Association they move to this.

Here is the DHCP Discovery message coming from client. This is destined to L2 broadcast address (ff:ff:ff:ff:ff:ff) with client MAC address used as Client Identifier.

Here is the debug output section related to it. If WLC proxy enabled, then WLC will use its dynamic interface (in my case vlan 1422) assigned to WLAN to relay this Discovery msg to DHCP server. This is how DHCP server get to know which subnet IP to be allocated to this client.

12:42:30.290: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP DISCOVER (1)
12:42:30.290: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 1
12:42:30.290: 04:f7:e4:ea:5b:66 DHCP   xid: 0x6dc433f2 (1841574898), secs: 0, flags: 0
12:42:30.290: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
12:42:30.290: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
12:42:30.291: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
12:42:30.291: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
12:42:30.291: 04:f7:e4:ea:5b:66 DHCP selecting relay 2 - control block settings:
                        dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
12:42:30.291: 04:f7:e4:ea:5b:66 DHCP selected relay 2 - x.x.x.200 (local address x.x.x8.120, gateway x.x.x8.125, VLAN 1422, port 1)
12:42:30.291: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP DISCOVER (1)

Once WLC hear from WLC (DHCP Offer) then it will pass that to the client. Note that WLC use its virtual address as source IP when passing it to client (DHCP proxy). This will provide the offered IP detail & other DHCP option to client.

Here is the  WLC debug output show these frame exchange. In my case x.x.x8.67 IP offered by DHCP server to the client.

12:42:31.294: 04:f7:e4:ea:5b:66 DHCP setting server from OFFER (server x.x.x.100, yiaddr x.x.x8.67)
12:42:31.294: 04:f7:e4:ea:5b:66 DHCP sending REPLY to STA (len 418, port 1, vlan 1600)
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP OFFER (2)
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   xid: 0x6dc433f2 (1841574898), secs: 0, flags: 0
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: x.x.x8.67
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
12:42:31.295: 04:f7:e4:ea:5b:66 DHCP   server id: 192.0.2.1  rcvd server id: x.x.x.100
12:42:32.432: 04:f7:e4:ea:5b:66 DHCP received op BOOTREQUEST (1) (len 308,vlan 1600, port 1, encap 0xec03)
12:42:32.432: 04:f7:e4:ea:5b:66 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
12:42:32.432: 04:f7:e4:ea:5b:66 DHCP selecting relay 1 - control block settings:
                        dhcpServer: x.x.x.100, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
12:42:32.432: 04:f7:e4:ea:5b:66 DHCP mscbVapLocalAddr=x.x.x8.120 mscbVapLocalNetMask= 255.255.255.128 mscbdhcpRelay=x.x.x8.120
12:42:32.432: 04:f7:e4:ea:5b:66 DHCP selected relay 1 - x.x.x.100 (local address x.x.x8.120, gateway x.x.x8.125, VLAN 1422, port 1)

Then client will send the DHCP Request frame. As you can see it is destined to L2 broadcast (ff:ff:ff:ff:ff:ff) requesting previously offered IP from the DHCP server.

Here is the debug output related to this.

 12:42:32.432: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP REQUEST (3)
 12:42:32.432: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 1
 12:42:32.432: 04:f7:e4:ea:5b:66 DHCP   xid: 0x6dc433f2 (1841574898), secs: 2, flags: 0
 12:42:32.432: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP   requested ip: x.x.x8.67
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP   server id: x.x.x.100  rcvd server id: 192.0.2.1
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP selecting relay 2 - control block settings:
 dhcpServer: x.x.x.100, dhcpNetmask: 0.0.0.0,
 dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
 12:42:32.433: 04:f7:e4:ea:5b:66 DHCP selected relay 2 - NONE
 12:42:32.434: 04:f7:e4:ea:5b:66 DHCP received op BOOTREPLY (2) (len 308,vlan 1422, port 1, encap 0xec00)

Finally DHCP server will send DHCP ACK frame to client confirming  successful address allocation. Again WLC will proxy this & use its virtual IP address (192.0.2.1) as the source IP of this packet.

Here is the debug output related to this. As you can see DHCP_REQD(7) state move to “RUN” state which is the final & operational state of a working wireless client.

 12:42:32.435: 04:f7:e4:ea:5b:66 DHCP setting server from ACK (mscb=0x45e778c0 ip=0x83ac1c43)(server x.x.x.100, yiaddr x.x.x8.67)
 12:42:32.435: 04:f7:e4:ea:5b:66 apfMsRunStateInc
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 DHCP_REQD (7) Change state to RUN (20) last state DHCP_REQD (7)
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Reached PLUMBFASTPATH: from line 7148
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Replacing Fast Path rule
 type = Airespace AP Client
 on AP 1c:6a:7a:bc:4d:60, slot 1, interface = 1, QOS = 2
 IPv4 ACL ID = 255, IPv6 ACL ID
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Fast Path rule (contd...) 802.1P = 6, DSCP = 0, TokenID = 15206, IntfId = 13  Local Bridging Vlan = 1422, Local Bridging intf id = 13
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0
 12:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 012:42:32.435: 04:f7:e4:ea:5b:66 x.x.x8.67 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255)
 12:42:32.435: 04:f7:e4:ea:5b:66 Assigning Address x.x.x8.67 to mobile
 12:42:32.435: 04:f7:e4:ea:5b:66 DHCP success event for client. Clearing dhcp failure count for interface vlan1422.
 12:42:32.435: 04:f7:e4:ea:5b:66 DHCP sending REPLY to STA (len 418, port 1, vlan 1600)
 12:42:32.436: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP ACK (5)

Note that I have excluded the mobility messages just to make it simple. Once you familiar with above steps you can go into mobility related details where when a client associate to a WLC, first it will announce to rest of the WLCs in the mobility group to see whether this client previously associated to any other controllers.

 Related Posts

1. WLC Client Debug – Part 2 (PSK)
2. WLC Client Debug – Part 3 (802.1X)

WiFi Spectrum Analyzer considerations
– Frequency
– Form factor
– Price
– Hardware Platform
– Resolution
– Supporting Software
– WiFi integration

Free Space Path Loss(FSPL)
FSPL isthe loss of signal energy caused by the natural broadening of the waves, often referred to as beam divergence.

If distance(d) in miles between antenna, ferequency (f) in MHz then FSPL in dB.

FSPL=36.6 + 20log (f) + 20log(d)

If distance(d) in kilometers between antenna, frequency (f) in MHz then FSPL in dB

FSPL=32.4 + 20log (f) + 20log(d)

Received Signal Strength Indicator (RSSI)
RSSI is a metric that is specified by measuring the amount of energy associated with the bits received via wireless NIC.

Noise Floor
Noise floor is the ambient or background level of radio energy on  the specific channel you are analyzing. For wireless NIC to report noise,it has to receive data bits, without that NIC will report as noise variable of zero.

Signal to Noise Ratio (SNR)
SNR can be presented as a dB value or as the difference between the RSSI(signal) and the noise floor(noise). Better the SNR is better the performance.Receive Sensitivity
Receive Sensitivity refers to the power level of an RF signal required to be successfully received by the receiver radio.

Wired & Wireless NIC
Wireless NIC must use its antenna and encoding filter to keep out all unwanted RF signals and thus unwanted bits as well. Also wireless NIC will use some of the specific information gleaned from the RF to bit transition process to actually add information to the wireless frame.

This additional information is added at the receiving station and is in addition to the bits send from the source. This added information called Radiotap Header. Below shows a Radiotap header information of a received beacon frame by a wifi sniffer NIC. All these information is reference to Rx station & not reference to Tx STA.

RF signal can represent in either time domain or frequency domain. Once you do Fast Fourier Transformation (FFT) for a time domain signal you can get the Frequency domain signal. In RF, mostly Frequency Domain representation is more useful. Hear are some different views available in a spectrum analyzer.

Real Time FFT
Frequency represent in horizontal axis and the energy in dBm defined in vertical axis

Spectrogram Graph (Waterfall plot)
This use the same data from Real Time FFT, but with the addition of time dimension. In this view vertical axis shows the historical data. In this case energy in dB values represent in colors (Blue to RED to represent weaker to stronger energy).

Spectrum Density
Horizontal axis represent frequency & vertical axis represent energy in dBm with brightness of color being determined by how many times that specific bit of information has been captured.

Duty Cycle
This view displays the percentage of time the ambient RF signal is higher than the noise floor or other predefined signal threshold. In this veiw you can see whether a device is constantly using a frequency (100% duty cycle on a particular channel mean it is not usable & caused by sort of jammers)

WiFi integration
When spectrum analyzer has WiFi integration capability, it can combined those views. WiFi NIC can scan other channels & report that information to give a overall view on a particular band.

Here are some RF signatures of particular devices. (Note that all images taken from the CWAP official study guide & George’s my80211.com)

1. Frequency Hopping Portable 2.4GHz telephone

Here is a Real Time FFT view Here is a same with all different views (FFT, Duty Cycle, Spetrogram)

2. Frequency Hopping Portable 5GHz telephone

3. Bluetooth Discovery
In discovery mode bluetooth device use pseduorandom frequency selection resulting frequency hopping on the entire 2.4GHz band. Due to fixed pseudorandom sequence all those energy peaks occur at regular interval leaving dots are line up in spectrogram view.

4. Bluetooth device in operating mode.
In this mode fully random distribution of hotspots (as no fixed psedurandom) in spectrogram view.

5. Real-time FFT of Logitec Analog mouse
It has a narrow signal that drop off quickly.

6. Real-time FFT of narrow-band jammer

Duty Cycle of narrow-band jammer

7. Real-time FFT of 2.4GHz wide band jammer

8. Real-time FFT of Analog Video Camera

9. Microwave Oven

References
1. CWAP Official Study Guide – Chapter 11

In this post we will see how to utilize “debug clinet x.x.x.x” output to understand the process a wireless client go through get connected to WPA2-PSK configured wireless network. Here is the basic topology used in this post

Compare to Open Authentication (see WLC Client Debug – Part 1 post for detail) you would see the 4-Way handshake process takes place to derive the encryption keys prior to go through the DHCP process. Here is the summary steps you should see in this WPA2-PSK client association process.

1. Open System Authentication (Request initiate by client)
2. Open system Authentication (Response by AP)
3. Association Request (sent by client)
4. Association Response (send by AP)
5. 4-Way Handshake – EAPoL Key Exchange Message 1
6. 4-Way Handshake – EAPoL Key Exchange Message 2
7. 4-Way Handshake – EAPoL Key Exchange Message 3
8. 4-Way Handshake – EAPoL Key Exchange Message 4
9. DHCP Discover (send by client to L2 broadcast)
10. DHCP Offer (send by DHCP server)
11. DHCP Reqeust (send by client to L2 broadcast)
12. DHCP ACK (send by DHCP server to client)

Once you issue the  “debug client x.x.x.x” CLI command you would see it give the output detailing what’s happening. If you understand this debug, then it is easy to identify issues come across.

(5508-1) > debug client 04:f7:e4:ea:5b:66
*apfMsConnTask_5: Oct 17 09:20:02.901: 04:f7:e4:ea:5b:66 Processing assoc-req station:04:f7:e4:ea:5b:66 AP:1c:6a:7a:bc:4d:60-01 thread:150e53e0
*apfMsConnTask_5: Oct 17 09:20:02.901: 04:f7:e4:ea:5b:66 Adding mobile on LWAPP AP 1c:6a:7a:bc:4d:60(1) 
*apfMsConnTask_5: Oct 17 09:20:02.901: 04:f7:e4:ea:5b:66 Association received from mobile on BSSID 1c:6a:7a:bc:4d:5c AP TEST-AP

For the simplicity I have stripped “*apfMsConnTask_5: Oct 17” from the above debug output. (Full output attached at the end of the post). As you can see client state move from START(0) -> AUTHCHECK (2) -> 802.1X_REQD (3) during this open authentication phase.

09:20:02.901: 04:f7:e4:ea:5b:66 Processing assoc-req station:04:f7:e4:ea:5b:66 AP:1c:6a:7a:bc:4d:60-01 thread:150e53e0
09:20:02.901: 04:f7:e4:ea:5b:66 Adding mobile on LWAPP AP 1c:6a:7a:bc:4d:60(1) 
09:20:02.901: 04:f7:e4:ea:5b:66 Association received from mobile on BSSID 1c:6a:7a:bc:4d:5c AP TEST-AP
09:20:02.901: 04:f7:e4:ea:5b:66 Global 200 Clients are allowed to AP radio
09:20:02.901: 04:f7:e4:ea:5b:66 Max Client Trap Threshold: 0  cur: 0
09:20:02.901: 04:f7:e4:ea:5b:66 Rf profile 600 Clients are allowed to AP wlan
09:20:02.901: 04:f7:e4:ea:5b:66 override for default ap group, marking intgrp NULL
09:20:02.901: 04:f7:e4:ea:5b:66 Applying Interface policy on Mobile, role Unassociated. Ms NAC State 0 Quarantine Vlan 0 Access Vlan 0
09:20:02.901: 04:f7:e4:ea:5b:66 Re-applying interface policy for client 
09:20:02.901: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2385)
09:20:02.901: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2406)
09:20:02.901: 04:f7:e4:ea:5b:66 apfApplyWlanPolicy: Apply WLAN Policy over PMIPv6 Client Mobility Type
09:20:02.901: 04:f7:e4:ea:5b:66 In processSsidIE:5680 setting Central switched to TRUE
09:20:02.901: 04:f7:e4:ea:5b:66 In processSsidIE:5683 apVapId = 1 and Split Acl Id = 65535
09:20:02.901: 04:f7:e4:ea:5b:66 Applying site-specific Local Bridging override for station 04:f7:e4:ea:5b:66 - vapId 20, site 'LTU-APG1', interface 'vlan1422'
09:20:02.901: 04:f7:e4:ea:5b:66 Applying Local Bridging Interface Policy for station 04:f7:e4:ea:5b:66 - vlan 1422, interface id 13, interface 'vlan1422'
09:20:02.902: 04:f7:e4:ea:5b:66 override from ap group, removing intf group from mscb
09:20:02.902: 04:f7:e4:ea:5b:66 Applying site-specific override for station 04:f7:e4:ea:5b:66 - vapId 20, site 'LTU-APG1', interface 'vlan1422'
09:20:02.902: 04:f7:e4:ea:5b:66 Applying Interface policy on Mobile, role Unassociated. Ms NAC State 2 Quarantine Vlan 0 Access Vlan 1422
09:20:02.902: 04:f7:e4:ea:5b:66 Re-applying interface policy for client 
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2385)
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2406)
09:20:02.902: 04:f7:e4:ea:5b:66 processSsidIE  statusCode is 0 and status is 0 
09:20:02.902: 04:f7:e4:ea:5b:66 processSsidIE  ssid_done_flag is 0 finish_flag is 0
09:20:02.902: 04:f7:e4:ea:5b:66 STA - rates (4): 176 72 96 108 0 0 0 0 0 0 0 0 0 0 0 0
09:20:02.902: 04:f7:e4:ea:5b:66 suppRates  statusCode is 0 and gotSuppRatesElement is 1 
09:20:02.902: RSNIE in Assoc. Req.: (20)
09:20:02.902:      [0000] 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
09:20:02.902:      [0016] ac 02 0c 00
09:20:02.902: 04:f7:e4:ea:5b:66 Processing RSN IE type 48, length 20 for mobile 04:f7:e4:ea:5b:66
09:20:02.902: 04:f7:e4:ea:5b:66 Received 802.11i PSK key management suite, enabling Authentication
09:20:02.902: 04:f7:e4:ea:5b:66 RSN Capabilities:  12
09:20:02.902: 04:f7:e4:ea:5b:66 apfValidateDot11iCapabilities:1122 Received RSNIE with Capabilities with STA MFPC: 0, STA MFPR:0, & AP MFPC:0MFPR:0
09:20:02.902: 04:f7:e4:ea:5b:66 Marking Mobile as non-11w Capable 
09:20:02.902: 04:f7:e4:ea:5b:66 apfValidateDot11wGroupMgmtCipher:1552, Received NULL 11w Group Mgmt Cipher Suite for STA, hence returning
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Initializing policy
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state START (0)
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 AUTHCHECK (2) Change state to 8021X_REQD (3) last state AUTHCHECK (2)
09:20:02.902: 04:f7:e4:ea:5b:66 Encryption policy is set to 0x80000001
09:20:02.902: 04:f7:e4:ea:5b:66 Not Using WMM Compliance code qosCap 00
09:20:02.902: 04:f7:e4:ea:5b:66 Sending 11w Flag 0 for Client 04:F7:E4:EA:5B:66 
09:20:02.902: 04:f7:e4:ea:5b:66 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP 1c:6a:7a:bc:4d:60 vapId 20 apVapId 1 flex-acl-name: 
09:20:02.903: 04:f7:e4:ea:5b:66 apfMsAssoStateInc
09:20:02.903: 04:f7:e4:ea:5b:66 apfMsWepPskStateInc
09:20:02.903: 04:f7:e4:ea:5b:66 apfPemAddUser2 (apf_policy.c:352) Changing state for mobile 04:f7:e4:ea:5b:66 on AP 1c:6a:7a:bc:4d:60 from Idle to Associated
09:20:02.903: 04:f7:e4:ea:5b:66 apfPemAddUser2:session timeout forstation 04:f7:e4:ea:5b:66 - Session Tout 0, apfMsTimeOut '0' and sessionTimerRunning flag is  0 
09:20:02.903: 04:f7:e4:ea:5b:66 Stopping deletion of Mobile Station: (callerId: 48)
09:20:02.903: 04:f7:e4:ea:5b:66 Func: apfPemAddUser2, Ms Timeout = 0, Session Timeout = 0
09:20:02.903: 04:f7:e4:ea:5b:66 Sending assoc-resp with status 0 station:04:f7:e4:ea:5b:66 AP:1c:6a:7a:bc:4d:60-01 on apVapId 1
09:20:02.903: 04:f7:e4:ea:5b:66 Sending Assoc Response to station on BSSID 1c:6a:7a:bc:4d:6f (status 0) ApVapId 1 Slot 1
09:20:02.903: 04:f7:e4:ea:5b:66 apfProcessAssocReq (apf_80211.c:9452) Changing state for mobile 04:f7:e4:ea:5b:66 on AP 1c:6a:7a:bc:4d:60 from Associated to Associated
09:20:02.905: 04:f7:e4:ea:5b:66 Got action frame from this client.

Here is the initial 4 frames (Auth Req, Auth Res, Assoc Req, Assoc Res) in frame capture.

Here is the Authentication response sent by AP. Note that status code 0 for successful open system authentication.Here is the client association request specifying the CCMP (00-0F-AC-04) listed as encryption cipher & PSK (00-0F-AC-02) listed as Auth cipher in RSN IE.

Here is the association response from AP confirming successful association (status code 0) where AID is allocated.Once Open System Authentication & association Phase is completed it will move onto 4-Way handsahke process. In PSK method, Pairwise Master Key (PMK) is derived from the PSK (Preshared Key) which used to derive PTK used to encrypt the traffic. These debug messages you will see like this.

*Dot1x_NW_MsgTask_6: Oct 17 09:20:02.905: 04:f7:e4:ea:5b:66 reauth_sm state transition 0 ---> 1 for mobile 04:f7:e4:ea:5b:66 at 1x_reauth_sm.c:47
*Dot1x_NW_MsgTask_6: Oct 17 09:20:02.905: 04:f7:e4:ea:5b:66 Creating a PKC PMKID Cache entry for station 04:f7:e4:ea:5b:66 (RSN 2)
*Dot1x_NW_MsgTask_6: Oct 17 09:20:02.905: 04:f7:e4:ea:5b:66 Resetting MSCB PMK Cache Entry 0 for station 04:f7:e4:ea:5b:66

Again for the simplicity I have stripped “*Dot1x_NW_MsgTask_6: Oct 17 ” from the below.  As you can see in the debug messages AP will start the 4-way  handshaking by sending message 1 to the client. Also it create PMKID (14 d6 77 1e 1b eb f2 54 89 91 4d 2f 5f 90 ad c3) for this association & include it in message 1. This message include Authenticator Nonce (A Nonce) which require by client to derive PTK.

*spamApTask7: Oct 17 09:20:02.905: 04:f7:e4:ea:5b:66 Sent 1x initiate message to multi thread task for mobile 04:f7:e4:ea:5b:66
09:20:02.905: 04:f7:e4:ea:5b:66 reauth_sm state transition 0 ---> 1 for mobile 04:f7:e4:ea:5b:66 at 1x_reauth_sm.c:47
09:20:02.905: 04:f7:e4:ea:5b:66 Creating a PKC PMKID Cache entry for station 04:f7:e4:ea:5b:66 (RSN 2)
09:20:02.905: 04:f7:e4:ea:5b:66 Resetting MSCB PMK Cache Entry 0 for station 04:f7:e4:ea:5b:66
09:20:02.905: 04:f7:e4:ea:5b:66 Setting active key cache index 8 ---> 8
09:20:02.905: 04:f7:e4:ea:5b:66 Setting active key cache index 8 ---> 0
09:20:02.905: 04:f7:e4:ea:5b:66 Adding BSSID 1c:6a:7a:bc:4d:6f to PMKID cache at index 0 for station 04:f7:e4:ea:5b:66
09:20:02.905: New PMKID: (16)
09:20:02.905:      [0000] 14 d6 77 1e 1b eb f2 54 89 91 4d 2f 5f 90 ad c3
09:20:02.905: 04:f7:e4:ea:5b:66 Initiating RSN PSK to mobile 04:f7:e4:ea:5b:66
09:20:02.905: 04:f7:e4:ea:5b:66 EAP-PARAM Debug - eap-params for Wlan-Id :20 is disabled - applying Global eap timers and retries
09:20:02.905: 04:f7:e4:ea:5b:66 Disable re-auth, use PMK lifetime.
09:20:02.905: 04:f7:e4:ea:5b:66 dot1x - moving mobile 04:f7:e4:ea:5b:66 into Force Auth state
09:20:02.906: 04:f7:e4:ea:5b:66 Skipping EAP-Success to mobile 04:f7:e4:ea:5b:66
09:20:02.906: 04:f7:e4:ea:5b:66 Found an cache entry for BSSID 1c:6a:7a:bc:4d:6f in PMKID cache at index 0 of station 04:f7:e4:ea:5b:66
09:20:02.906: 04:f7:e4:ea:5b:66 Found an cache entry for BSSID 1c:6a:7a:bc:4d:6f in PMKID cache at index 0 of station 04:f7:e4:ea:5b:66
09:20:02.906: Including PMKID in M1  (16)
09:20:02.906:      [0000] 14 d6 77 1e 1b eb f2 54 89 91 4d 2f 5f 90 ad c3
09:20:02.906: 04:f7:e4:ea:5b:66 Starting key exchange to mobile 04:f7:e4:ea:5b:66, data packets will be dropped
09:20:02.906: 04:f7:e4:ea:5b:66 Sending EAPOL-Key Message to mobile 04:f7:e4:ea:5b:66
state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

Here is the frame capture of M1. As you can see those ANonce & PMKID in there. Also note that AP send it as UP value 7 which is highest priority that can set.

Then client will respond with message 2 (M2).  By this time client already derive the PTK (using PMK, Anonce, Snonnce, Authenticator add, Supplicant address) & encrypt the M2 using PTK.

09:20:02.906: 04:f7:e4:ea:5b:66 Allocating EAP Pkt for retransmission to mobile 04:f7:e4:ea:5b:66
09:20:02.909: 04:f7:e4:ea:5b:66 Received EAPOL-Key from mobile 04:f7:e4:ea:5b:66
09:20:02.909: 04:f7:e4:ea:5b:66 Received EAPOL-key in PTK_START state (message 2) from mobile 04:f7:e4:ea:5b:66
09:20:02.909: 04:f7:e4:ea:5b:66 Dumping RSNIE received in Association request:
09:20:02.909: 00000000: 30 14 01 00 00 0f ac 04  01 00 00 0f ac 04 01 00  0...............
09:20:02.909: 00000010: 00 0f ac 02 0c 00                                 ......
09:20:02.909: 04:f7:e4:ea:5b:66 Dumping RSNIE received in EAPOL M2 :
09:20:02.909: 00000000: 01 00 00 0f ac 04 01 00  00 0f ac 04 01 00 00 0f  ................
09:20:02.909: 00000010: ac 02 0c 00                                       ....
09:20:02.909: 04:f7:e4:ea:5b:66 Stopping retransmission timer for mobile 04:f7:e4:ea:5b:66

Here is the M2 frame capture. Note that since my client is not set any UP value on this (so default 0). Also you see MIC in use & S-Nonce send to AP to compute PTK. Also M2 include the RSN-IE indicate client capability (Auth & Encryp ciphers)

Then AP/WLC derive the the GTK & send it to client using M3. This key is used for broadcast/multicast traffic encryption. By this time since AP derived the PTK it will encrypt this using PTK & using MIC.

09:20:02.909: 04:f7:e4:ea:5b:66 Sending EAPOL-Key Message to mobile 04:f7:e4:ea:5b:66
state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
09:20:02.909: 04:f7:e4:ea:5b:66 Reusing allocated memory for  EAP Pkt for retransmission to mobile 04:f7:e4:ea:5b:66

Here is the M3 frame capture. Note that  key data encrypted & MIC in used. Also install bit set to 1 to inform client to install these GTK.

Finally client send M4 to complete the 4-Way Handshake process. Then client state on the WLC move from 802.1X_REQD(3) to L2AUTHCOMPLETE(4)

09:20:02.912: 04:f7:e4:ea:5b:66 Received EAPOL-Key from mobile 04:f7:e4:ea:5b:66
09:20:02.912: 04:f7:e4:ea:5b:66 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 04:f7:e4:ea:5b:66
09:20:02.912: 04:f7:e4:ea:5b:66 Stopping retransmission timer for mobile 04:f7:e4:ea:5b:66
09:20:02.912: 04:f7:e4:ea:5b:66 Freeing EAP Retransmit Bufer for mobile 04:f7:e4:ea:5b:66
09:20:02.912: 04:f7:e4:ea:5b:66 apfMs1xStateInc
09:20:02.912: 04:f7:e4:ea:5b:66 0.0.0.0 8021X_REQD (3) Change state to L2AUTHCOMPLETE (4) last state 8021X_REQD (3)
09:20:02.912: 04:f7:e4:ea:5b:66 Mobility query, PEM State: L2AUTHCOMPLETE
09:20:02.912: mm_exec_mobAgent_fsm:597 currState:Init, event:MM_MAFSM_EV_FULL_AUTH, caller mmMaRxAssocReq:6613
09:20:02.912: 04:f7:e4:ea:5b:66 OUthdr length is 74 
09:20:02.912: 04:f7:e4:ea:5b:66 mmBuildMsgVlanIdPayload: rc1 = 0,no vlan group. intfName = vlan1422 Vlanid = 0 
*mcListen: Oct 17 09:20:02.912: 04:f7:e4:ea:5b:66 MC:Mobile announce received from internal MA, will fwd this to peer MC,Xid 63508, Retry#0.
*mcListen: Oct 17 09:20:02.913: Mobile announce from MA and Client entry not found, groupcasted to peer MC's
09:20:02.913: 04:f7:e4:ea:5b:66 Not Using WMM Compliance code qosCap 00
09:20:02.913: 04:f7:e4:ea:5b:66 Sending 11w Flag 0 for Client 04:F7:E4:EA:5B:66 
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP 1c:6a:7a:bc:4d:60 vapId 20 apVapId 1 flex-acl-name: 

Here is the M4 frame capture.Once 4 way handshake completes you will see DHCP related debug messages coming during client trying to get the IP. You will see these messages start with “*DHCP Socket Task: Oct 17 ” but stripped it for simplicity.  You can see the mobility messages (starging with *mmMaListen:) in this debug with respect to this client MAC.

09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state L2AUTHCOMPLETE (4)
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 6486, Adding TMP rule
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 1c:6a:7a:bc:4d:60, slot 1, interface = 1, QOS = 2
  IPv4 ACL ID = 255, IPv
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 6, DSCP = 0, TokenID = 15206, IntfId = 13  Local Bridging Vlan = 1422, Local Bridging intf id = 13
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
09:20:02.913: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
09:20:02.914: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
09:20:02.914: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255)
*pemReceiveTask: Oct 17 09:20:02.914: 04:f7:e4:ea:5b:66 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
09:20:04.163: 04:f7:e4:ea:5b:66 DHCP received op BOOTREQUEST (1) (len 308,vlan 1600, port 1, encap 0xec03)
09:20:04.163: 04:f7:e4:ea:5b:66 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
09:20:04.163: 04:f7:e4:ea:5b:66 DHCP dropping packet due to ongoing mobility handshake exchange, (siaddr 0.0.0.0,  mobility state = 'apfMsMmQueryRequested'

*mmMaListen: Oct 17 09:20:04.861: Entering maMCAnnounceMipResendTimeoutNotify
*mmMaListen: Oct 17 09:20:04.862: 04:f7:e4:ea:5b:66 Mobility packet retry: Peer IP: 0.0.0.0, Anchor IP: 0.0.0.0
*mmMaListen: Oct 17 09:20:04.862: Leaving maMCAnnounceMipResendTimeoutNotify
*mcListen: Oct 17 09:20:04.862: 04:f7:e4:ea:5b:66 MC:Mobile announce received from internal MA, will fwd this to peer MC,Xid 63508, Retry#2.
*mcListen: Oct 17 09:20:04.862: Mobile announce from MA and Client entry not found, groupcasted to peer MC's
*mmMaListen: Oct 17 09:20:05.862: Entering maMCAnnounceMipResendTimeoutNotify
*mmMaListen: Oct 17 09:20:05.862: Executing the state machine in maMCAnnounceMipResendTimeoutNotify
*mmMaListen: Oct 17 09:20:05.862: mm_exec_mobAgent_fsm:597 currState:Init_Wait_Announce_Response, event:MM_MAFSM_EV_MA_NAK_FROM_MC_OR_MAX_RETX_TIMEOUT, caller maMCAnnounceMipResendTimeoutNotify:5876
*mmMaListen: Oct 17 09:20:05.862: Entering mmMA_TxHdoffComplete2MC 
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) mobility role update request from Unassociated to Local
  Peer = 0.0.0.0, Old Anchor = 0.0.0.0, New Anchor = 10.160.33.1
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 6102, Adding TMP rule
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Replacing Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 1c:6a:7a:bc:4d:60, slot 1, interface = 1, QOS = 2
  IPv4 ACL ID = 255, 
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 6, DSCP = 0, TokenID = 15206, IntfId = 13  Local Bridging Vlan = 1422, Local Bridging intf id = 13
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0 
*mmMaListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255)
*mmMaListen: Oct 17 09:20:05.862: Entering mmBuildMsgHandoffComplete
*mmMaListen: Oct 17 09:20:05.862: Leaving mmBuildMsgHandoffComplete
*mmMaListen: Oct 17 09:20:05.862: Leaving mmMA_TxHdoffComplete2MC
*mcListen: Oct 17 09:20:05.862: Found tunnel id 0 for 10.160.33.1
*mmMaListen: Oct 17 09:20:05.862: Leaving maMCAnnounceMipResendTimeoutNotify
*mcListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 Handoff Complete msg for Client(Ip: 0.0.0.0 roam-type: None)Sender(Ip: 10.160.33.1 Type: 1) Anchor(Ip: 0.0.0.0  MC : 0.0.0.0)Foreign(Ip : 0.0.0.0 MC : 0.0.0.0)
*pemReceiveTask: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*mcListen: Oct 17 09:20:05.862: 04:f7:e4:ea:5b:66 Created a new Client Entry for  04:F7:E4:EA:5B:66 
*pemReceiveTask: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 Sent an XID frame
*mcListen: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 Handoff Complete Ack Done sent to IP: 10.160.33.1
*mcListen: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 Handoff complete from MA,client->clientState is 0, anchorMcIp is 0,oldForeignMcIp is 0  
*mcListen: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 DROPPING mcFwdHandOff as anchorMcIp is 0.0.0.0
*mcListen: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 Could not forward handoff complete to MO
*mcListen: Oct 17 09:20:05.863: 04:f7:e4:ea:5b:66 MC: Changing client state from Init to Local
*mmMaListen: Oct 17 09:20:05.863: mm_exec_mobAgent_fsm:597 currState:Local, event:MM_MAFSM_EV_HDOFF_COMPL_ACK, caller mmProcessInMsg:1332
*mmMaListen: Oct 17 09:20:05.863: Entering mmMA_Tun2Peer

Then client go through DORA (Discovery, Offer, Reqeuest & ACK) process to get the IP. Most of the time clients requesting previously associated wireless network IP, so most of the case you will see a NACK initially for that request.You can see in my case client sending a DHCP Request for x.x.y4.58 IP which is NACK by DHCP as that IP is not what WLC configured for this SSID.

Here is the debug related to this. You can see client move from DHCP_REQD(7) to RUN(20) which is the final operational status you should see.

09:20:06.263: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP REQUEST (3)
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 2
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   xid: 0x7071adbc (1886498236), secs: 4, flags: 0
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP   requested ip: x.x.y4.58
09:20:06.264: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
09:20:06.265: 04:f7:e4:ea:5b:66 DHCP received op BOOTREPLY (2) (len 308,vlan 1422, port 1, encap 0xec00)
09:20:06.265: 04:f7:e4:ea:5b:66 DHCP sending REPLY to STA (len 418, port 1, vlan 1600)
09:20:06.265: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP NAK (6)

09:20:06.409: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP DISCOVER (1)
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 1
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP   xid: 0x7071adbd (1886498237), secs: 0, flags: 0
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP selecting relay 2 - control block settings:
                        dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP selected relay 2 - x.x.x6.200 (local address x.x.x8.120, gateway x.x.x8.125, VLAN 1422, port 1)
09:20:06.409: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP DISCOVER (1)
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 2
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP   xid: 0x7071adbd (1886498237), secs: 0, flags: 0
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
09:20:06.410: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP received op BOOTREPLY (2) (len 308,vlan 1422, port 1, encap 0xec00)
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP setting server from OFFER (server x.x.x6.100, yiaddr x.x.x8.67)
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP sending REPLY to STA (len 418, port 1, vlan 1600)
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP OFFER (2)
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   xid: 0x7071adbd (1886498237), secs: 0, flags: 0
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: x.x.x8.67
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
09:20:07.413: 04:f7:e4:ea:5b:66 DHCP   server id: 192.0.2.1  rcvd server id: x.x.x6.100
*apfLbsTask: Oct 17 09:20:07.862: 04:f7:e4:ea:5b:66 Copy AP LOCP - mode:0 slotId:137, apMac 0x1c:6a:7a:bc:4d:60
*apfLbsTask: Oct 17 09:20:07.862: 04:f7:e4:ea:5b:66 Copy WLAN LOCP EssIndex:20 aid:1 ssid: ABC-PSK
*apfLbsTask: Oct 17 09:20:07.862: 04:f7:e4:ea:5b:66 Copy Security LOCP ecypher:0x0 ptype:0x2, p:0x1, eaptype:0x6 w:0x1 aalg:0x0, PMState:  DHCP_REQD
*apfLbsTask: Oct 17 09:20:07.862: 04:f7:e4:ea:5b:66 Copy 802.11 LOCP a:0x0 b:0x0 c:0x0 d:0x0 e:0x0  protocol1:0x0 protocol2:0x7 statuscode 0, reasoncode 99, status 3
*apfLbsTask: Oct 17 09:20:07.862: 04:f7:e4:ea:5b:66 Copy MobilityData LOCP status:1, anchorip:0x0
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP received op BOOTREQUEST (1) (len 308,vlan 1600, port 1, encap 0xec03)
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP selecting relay 1 - control block settings:
                        dhcpServer: x.x.x6.100, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP mscbVapLocalAddr=x.x.x8.120 mscbVapLocalNetMask= 255.255.255.128 mscbdhcpRelay=x.x.x8.120
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP selected relay 1 - x.x.x6.100 (local address x.x.x8.120, gateway x.x.x8.125, VLAN 1422, port 1)
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP transmitting DHCP REQUEST (3)
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 1
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   xid: 0x7071adbd (1886498237), secs: 2, flags: 0
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   chaddr: 04:f7:e4:ea:5b:66
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   siaddr: 0.0.0.0,  giaddr: x.x.x8.120
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   requested ip: x.x.x8.67
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP   server id: x.x.x6.100  rcvd server id: 192.0.2.1
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP sending REQUEST to x.x.x8.125 (len 350, port 1, vlan 1422)
09:20:08.514: 04:f7:e4:ea:5b:66 DHCP selecting relay 2 - control block settings:
                        dhcpServer: x.x.x6.100, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: x.x.x8.120  VLAN: 1422
09:20:08.515: 04:f7:e4:ea:5b:66 DHCP selected relay 2 - NONE
09:20:08.517: 04:f7:e4:ea:5b:66 DHCP received op BOOTREPLY (2) (len 308,vlan 1422, port 1, encap 0xec00)
09:20:08.517: 04:f7:e4:ea:5b:66 DHCP setting server from ACK (mscb=0x45e90d90 ip=0x83ac1c43)(server x.x.x6.100, yiaddr x.x.x8.67)
09:20:08.517: 04:f7:e4:ea:5b:66 apfMsRunStateInc
09:20:08.517: 04:f7:e4:ea:5b:66 x.x.x8.67 DHCP_REQD (7) Change state to RUN (20) last state DHCP_REQD (7)

From the frame captures you won’t be able to see the data as everything is encrypted using PTK & GTK (unicast & broadcast/multicast frames respectively). So if you really want to see the capture detail you have to decrypt (Using wireshark you can decrypt WPA2-PSK frames). Using that method I have identified the frame number related to those DHCP packet flow.

Here is the frame 2290 capture view which is DHCP Discover sent by client to L2 broadcast address. All frame body is encrypted (note that MAC header frame control field indicated this by setting protected frame to 1)

Here is the rest of DHCP frames (Offer, Request & ACK) in frame capture view. One interesting thing I noticed is Cisco AP set UP value 3 for the Best Effort by default (0 & 3 used for AC_BE. most of the casese vendors set it to 0 by default)

Reference
1. WLC-PSK-debug (debug client 04:f7:e4:ea:5b:66 complete output)

Related Posts

1. WLC Client Debug – Part 1 (Open Authentication)
2. WLC Client Debug-  Part 3 (802.1X)

802.11n-2009 (HT-Clasue 20) amendment was ratified on September 2009, essentially a list of enhancement to improve the performance & throughput of 802.11a/g standards.

PHY Layer enhancements
1. Spatial Multiplexing (SM) – Tx multiple radio signal stream at the same time.
2. Transmit Beamforming (TxBF) – allow transmitter using multiple antenna to focus the Tx in the best direction of a receiver (Rx)
3. Space Time Block Coding (STBC) – Improve the reliability of data transfer by transmitting different copy of the data stream from different antenna.
4. Antenna Selection (ASEL) – increase signal diversity by dynamically
5. Low Density Parity Check (LDPC) -
6. Channel Bonding -
7. Maximal Radio Combining (MRC) -
8. Use of MIMO (Multiple Input & Multiple Ouput) technology.

MAC layer enhancements
1. Frame Aggregation
2. Block Acknowledgement
3. Power Save Multi-Poll (PSMP)
4. Reverse Direction (RD) Protocol
5. Reduces Inter Frame Spacing (RIFS)

MIMO
– Require the use of multiple radios & antennas called “radio chains”.
– Transmitting multiple streams of data with spatial multiplexing for high throughput
– make use of multipath
– TxBF can be used in MIMO system to steer beams & provide greater range & throughput.

Radio Chains
– conventional radio transmit & receive using RF signals by using single-input single-output (SISO)
– MIMO consist of multiple radio chains
– MIMO system is characterized by the number of transmitters & receivers.
eg 2×3 MIMO would consist of 3 radio chains with 2 transmitters & 3 receivers.
3×3 MIMO would consist of 3 radio chains with 3 transmitters & 3 receivers.

HT Channels
1. 20MHz non-HT & HT Channels
– 802.11a/g, each 20MHz OFDM channel contain 64 subcarriers
– each subcarrier 312.5KHz wide.
– First 6 & last 5 subcarriers are null because they act as guard band for the channel
– center subcarrier is also null & called the direct conversational(DC) subcarrier.
– This leaves 52 subcarriers (64-12).
– Out of 52, 48 transmit data while 4 are used as pilot tones for dynamic calibration between Tx & Rx.
– OFDM use convolution coding & forward error correction.

- HT clause 20 also use OFDM technology & have the capability of using either 20MHz or 40MHz channel.
– 20MHz channels  used by HT radio use extra 4 carriers to carry data with small guard interval.
– so HT channel can carry a little more data than non-HT OFDM channel.
– HT 20MHz OFDM channel has 56 subcarriers.
– 52 of them carry data while 4 subcarriers used as pilot tones.

2. 40 MHz Channels

- 40MHz HT channel use 114 subcarriers
– 108 subcarriers transmit data & 6 subcarriers are used as pilot tones
– each 40MHz channels used by HT radios are essentially 2x 20MHz bonded together.
– One 20MHz channel termed as “Primary” & the other 20MHz termed as “Secondary”
– Primary & Secondary 20MHz should be adjacent 20MHz channels.

- Primary field indicate the primary channel
– A postive or negative offset indicates whether the secondary channel is one channel above or one channel below the primary channel.
– standard 20MHz HT channel reserves some freqency at the top and bottom of the channel to avoid interference with adjacent channel.
– when two 20MHz are bonded together, there is no need to reserve this bandwidth at bottom of the higher CH & at the top of the lower CH.
– therefore an HT 40MHz spectral space add two more subcarriers, given total of 114 subcarriers instead of 112.

MCS – Modulation & Coding Scheme.
– non-HT OFDM(802.11a/g) defines data rates 6, 9,12,18,24,36,48,54 Mbps
– HT data rates defined based on different factors, modulation, number of spatial streams, channel size & guard interval.
– 77 modulation coding schemes eixst for both 20MHz & 40 MHz channels.- 8 mandatory MCS for 20MHz HT channels as shown below.

Below table shows the data rates when using 4 spatial streams (max no of SS defines in 802.11n standard)

Below table shows the MCS for a 40MHz channel using one spatial stream.

Below table show the MCS for a 40MHz channel using 4 spatial stream.

Full index of MCS Rates -MCS Index – 802.11n and 802.11ac ( courtesy of @keithRParsons – Wireless LAN Professional )

HT PHY
There are 3 different preamble use in 802.11n
1. non-HT Legacy
– use of short & long training symbols (L-STF, L-LTF) used for synchronization
– OFDM symbol consist of 12 bits
– header contain the signal field, which indicates the time needed to transmit the payload of non-HT PPDU (which is MPDU)
– support of non-HT legacy format is mandatory in 802.11n radios.
– non-HT format effectively is the same format used by legacy 802.11a or 802.11g

2. HT Mixed
–  include non-HT short & long training symbols along with L-SIG that can be decoded by legacy 802.11a/g radios.
-non-802.11n receivers will not be able to read rest of the frame, but length field in  the legacy section allow them to know how long the medium is going to be busy.
– HT mixed format is also considered mandatory & transmission can occur in both 20MHz and 40MHz channel.
– When 40MHz in use, all broadcast traffic must be sent on a legacy 20MHz channel.

3. HT Greenfield
– This preamble is not compatible with legacy 802.11a/g radios.
– it can use both 20MHz or 40 MHz channels.

Below diagram show the 3 different PHY types used in 802.11n

WiFi Certified 802.11n
– All wifi certified 802.11n devices must support WMM (QoS) & WPA2 security mechanism|
– AP should support two spatial streams (mandatory)
– Client devices are only required to Tx & Rx at least one spatial stream.
– A-MSDU & A-MPDU in receive mode is mandatory
– Block Acknowledgement is mandatory.
– Several other optional features added in the standard.

References
1. CWAP Official Study Guide – Chapter 10

Related Posts

1. CWAP – HT Control Field
2. CWAP – HT Capabilities Information Element
3. CWAP – HT Operations Information Element.

802.11n introduces 4 new information elements which can be seen in 802.11n (HT) beacon frames.

HT STAs declare themselves as HT STA by transmission of HT Capabilities Element in Beacon, Probe Request, Probe Response, Association Request, Association Response, Reassociation Request & Reassociation Response frames. Below diagram shows the format of HT Capabilities Information Element.(page 383- CWAP Official Study Guide)

Here is a Beacon frame capture shows these filed of HT capabilities IE.

1. Element ID (1 byte)
This is 45 for this information element.

2. Length (1 byte)
Length field value is 26 indicating 26 bytes follows the content of this information element.

3. HT Capabilities Info (2 bytes)
Below diagram shows the format of this field.(page 384 – CWAP Study Guide)Here is a frame capture showing these fields.LDPC Coding Capability- Indicating Low Density Parity Check usage.
Supported Channel Width- 0 for only 20MHz, 1 for both 20MHz & 40MHz support.
SM Power Save – to indicate STA SM Power Save capability. Here are the possbile values & their interpretation.HT Greenfield – When set to 1 STA is capable of receiving HT Greenfield PPDU.
Short GI for 20MHz – STA capability to receive frames with a short GI in 20MHz
Short GI for 40MHz – STA capability to receive frames with a short GI in 40MHz
TX STBC – STA capability of transmitting PPDU using STBC (Space Time Block Coding)
RX STBC- STA capability of receiving PPDU using STBC (Space Time Block Coding)
HT Delayed BlockAck- indicate STA support of Delayed BlockAckMaximum A-MSDU Length – Aggregate MSDU frame, 0=3839 bytes, 1 =7935 bytes
DSSS/CCK Mode in 40MHz -PSMP support -
Forty MHz Intolerant – 1=prohibit use fo 40MHz channel in 2.4GHz
L-SIG TXOP – 1 to indicate support for Legacy-Signal (L-SIG) protection mechan

4. A-MPDU Parameters (1 byte)
Below diagram shows the format of A-MPDU parameter field of the HT Capabilities IE.

Maximum A-MPDU Length Exponent
Used by STA during association to define maximum A-MPDU length that the STA can receive. The value of this sub-field is an interger between 0-3 from which length in bytes calculated using below formula.

2^(13 + Maximum A-MPDU Length Exponent) – 1

So if value 0=8191 (8K),  1=16383 (16K), 2=32767 (32K) & 3=65535 (64K)

Minimum MPDU Start Spacing
Specifies the minimum amount of time that must elapse between starting the transmission of one MPDU & starting to transmit the next one. Following values shows the encoding for this sub-field.(in the above capture it show value of 6 indicate 8 microseconds)

0 = no restriction
1 = 1/4 μs
2 = 1/2 μs
3 = 1 μs
4 = 2 μs
5 = 4 μs
6 = 8 μs
7 = 16 μs

3rd sub-field of A-MPDU parameter is reserved.

5. Supported MCS set (16 bytes)
Below figure shows the frame format of the “Supported MCS Set” sub-field.Here is a frame capture shows these sub-fields

RX MCS Bitmask- has one bit for each 77 (0-76) MCSs. Above shows it support MCS0-23.
RX Highest Supported Rate – Define the highest data rate that STA support, however a STA is not required to provide that infor & may set to 0.TX Supported MCS set -
TX & RX MCS set -
TX Max Spatial Stream Supported -
TX Unequal Modulation -

6. HT Extended Capabilities (2 bytes)

Here is a frame capture.

7. Tx Beamforming Capabilities-TxBF (4 bytes)

Here is the frame capture shows these sub-fields.8. ASEL Capabilities (1 byte)

Here is those filed in the captured beacon.
Reference
1. CWAP Official Study Guide – Chapter 10

Related Post

1. CWAP – Introduction to 802.11n
2. CWAP – HT Control Field
3. CWAP – HT Operations Information Element

The 802.11n amendment add a 4 byte HT control field to the 802.11 MAC header. With this HT Control field max MAC header length increased to 36 bytes.

HT Control Field is always present in a Control Wrapper frame and is present in QoS Data and management frames as determined by the order bit of the Frame Control Field. The only Control Frame subtype for which HT Control field present is the Control Wrapper frame. A control frame  that is described as + HTC (eg RTS+HTC, BlockAckReq+HTC, PS-Poll+HTC) implies the use of Control Wrapper frame to carry the control frame. Below show the frame format of a Control WrapperHere is RTS+HTC frame captureHere is a BlockAckReq+HTC frame capture.Here is a PS-Poll+HTC frame capture.If it is a QoS Data frame or management frame, if HT Control Field is present then Order bit of the Frame Control field set to 1 (usually this bit used to indicate strict order processing on 802.11 frames, but with 802.11e QoS this bit is reused for indicate presence of HT control field).

Below shows the frame format of HT Control Field.

1. Link Adaptation Control (16 bits)

Link Adaptation Control subfield is having following frame format.TRQ-Training Request
Set to 1 to request the responder to transmit a sounding PPDU.
Set to 0 to indicate that the responder is not requested to transmit a sounding
PPDU.

Sounding PPDU are used in beamforming to perform over-the-air calibration of STA’s radios and as a feedback mechanism allowing STA to estimate the channel in order to calculate a steering matrix

MAI – MCS Request (MRQ) or ASEL Indicator
Set to 14 (indicating ASELI) to indicate that the MFB/ASELC subfield is
interpreted as ASELC. Otherwise, the MAI subfield is interpreted as MCS Request (MRQ), which is used for link adaptation to dynamically select the best MCS.

MFSI – MCS Feedback Sequence Identifier
A MCS Feedback (MFB) frame is sent in response to a MCS Request. The MFSI  is MFB frame is set to the value of MCS request field from the frame that contain the request.

MFB/ASELC – MCS feedback and Antenna SELection Command
When ASEL indicator is present, the MFB/ASELC subfield interpreted as ASELC subfield. Otherwise it is interpreted as MFB subfield. A value of 127 indicates that no feedback is present

2. Calibration Position (2 bits)
The Calibration Sequence subfield identifies an instance of the calibration procedure. The subfield is included in each frame within a calibration procedure, and its value is unchanged for frames within the same calibration procedure

Set to 0 indicates this is not a calibration frame.
Set to 1 indicates calibration start.
Set to 2 indicates sounding response.
Set to 3 indicates sounding complete.

3. Calibration Sequence (2 bits)
The field is included in each frame within the calibration procedure and its value is unchanged for the frame exchanges during one calibration procedure

4. CSI/Steering (2 bits)
The CSI/Steering subfield of the HT Control field indicates the type of feedback as shown below.

0 – No feedback required
1 – CSI
2 – Noncompressed beamforming
3 – Compressed beamforming

5. NDP Announcement (1 bit)
The Null Data Packet (NDP) Announcement subfield of the HT Control field indicates that an NDP will be transmitted after the frame. It is set to 1 to indicate that an NDP will follow; otherwise, it is set to 0.

NDP are used to send sounding PPDU when no other data needs to be transmitted. If a frame transmitted that require an immediate response and also has the TRQ=1 (request for sounding PPDU) then receiver can either transmit the MPDU response withing a sounding PPDU or send the response MPDU with the NDP Announcement bit set to 1,indicating that NDP will be transmitted following the current PPDU.

6. AC Constraint (1 bit)
The AC Constraint subfield of the HT Control field indicates whether the mapped AC of an RD data frame is constrained to a single AC.

0- The response to a reverse direction grant (RDG) may contain data frames from any TID
1- The response to an RDG may contain data frames only from the same AC as the last data frame received from the RD initiator

7. RDG/ More PPDU (1 bit)
When using Reverse Direction (RD) Protocol, a STA haivng obtained a TXOP, may grant other STAs the opportunity to transmit the data back within the same TXOP, without requiring the responding STA to contend for the medium before transmission. RD Protocol define two roles

RD Initiator – STA that has contended for and obtained the TXOP
RD responder – RD initiator will give the RD responder permission to transmit, by sending Reverse Direction Grant (RDG).

RD initiator  will set the RDG/More PPDU subfield to 1, indicating it is a RDG. The duration ID withing RDG is set to  the length of the TXOP remaining.

The RDG/More PPDU subfield of the HT Control field is interpreted differently depending on whether it is transmitted by an RD initiator or an RD responder, as defined in the below (ref IEEE 802.11-2012)

Here is a Control Wrapper frame capture shown the fields discussed in  the above.

References
1. CWAP Official Study Guide – Chapter 10

Related Posts

1. CWAP – Introduction to 802.11n
2. CWAP – HT Capabilities Information Element
3. CWAP – HT Operations Information Element

I originally started my blog as a place to keep my CCIEW study notes. Since then I started blogging about the things I am learning in wifi space (though it is not related to CCIEW exam). Since I passed my CCIEW lab exam in Aug 2013, I have done lots of posts mainly focusing CWNP certifications. So if you are new to my blog it is very hard to find all blog posts related to CCIEW exam in a logical order.

So in this post I will list down all the related posts I have written related to CCIEW exam (I could not believe, there are 160+ posts :shock: ). I tried to map my post to the CCIEW_Lab_v2_Blueprint,  so you can  follow them easily. I used section 0 to any post related to planning/preparation work for lab exam. Note that all posts done using the software version specified in CCIEWv2.0 blueprint (WLC 7.0.116.0, ACS5.2)

0.0 CCIE Journey Planning
– Started my 2nd CCIE Journey…. It is CCIE-Wireless!
– Organizing Technotes & Config Examples
– Written Exam Strategy !!!!
- How much do you need to read for cciew ?
- My Home Lab – I am getting there…
– CAPWAP Packet Analysis using wireshark
– “show archive config differences” is your Friend
– Do you know enough about CCIEW v2.0
– Save Time with “Alias”
– How to Configure CME ?
– CCIE Wireless Remote Racks
– Inspiring Triple CCIE Success Story
– Learning CLI in Quick Time
– What Did I learn from my 1st Attempt
– 20th Aug – My Lucky Day
– How to Become a CCIE Wireless …
- My winning Strategy

1.0 Configure & Troubleshoot L2/L 3 Infrastructure to Support WLANs (10%)
1.1 Configure and troubleshoot wired infrastructure to support WLANs
1.1.a VLANs
1.1.b VTP
1.1.c STP
– STP Root Port Selection 
– Configuring Root Guard & Loop Guard
– Configuring BPDU Guard & Filtering
– Configuring STP in 12.2 SXI
– Configuring STP – Portfast in 12.2 SXI
1.1.d EtherChannel
1.1.e HSRP
– Configuring HSRP
1.1.f VSS
1.2 Configure and troubleshoot network connectivity for various devices
– VoIP Phone – Switchport Config
1.3 Configure and troubleshoot PoE for APs
1.4 Configure and troubleshoot QoS on the switching infrastructure
– 3750/3560/2960 Wired QoS
– Best Practice QoS Config ?
1.5 Configure and troubleshoot multicast on the switching infrastructure
– Multicast Deployment Types
– Multicast Address Allocation
– IGMP Basics
– Test Yourself- Basic Multicast
– PIM-SM Static RP Configurations
– PIM-SM Auto-RP configurations
– PIM-SM BSR configurations
– MSDP with Anycast RP
1.6 Configure and troubleshoot basic IPv4 connectivity
1.7 Configure and troubleshoot basic IPv6 connectivity
– IPv6 Basics
– Configuring IPv6 Routing
1.8 Configure and troubleshoot wired security
1.9 Implement client to connect and authenticate to SSIDs

2.0 Configure and Troubleshoot Infrastructure Application Services (10%)
2.1 Configure and troubleshoot DNS, DHCP, NTP, syslog, and SNMP
– Understanding DHCP
- IOS DHCP Add. Reservation
– Hex to String Conversion
– Understanding DHCP Snooping 
– Understanding DHCP Option 82
– WLC – DHCP Option 82 Configuration Example
– Syslog & Msg Log in WLC
– Suppress a Syslog Msg
– WLC Login Banner
– NTP Basics
– Configuring SNMP on WLC
2.2 Configure and troubleshoot AAA server infrastructure
– AAA Basics – Part 1
– Configuring TACACS on WLC
– WLC Admin Access via TACACS
- Configuring RADIUS on WLC
2.2.a Client authentication
2.2.b Management authentication
2.2.c Basic PKI for dot1x and WebAuth

3.0 Configure and Troubleshoot an Autonomous Deployment Model (12%)
3.1 Configure and control management access
3.2 Configure and troubleshoot network services
3.3 Configure and troubleshoot different modes and roles
3.3.a Root
– Autonomous AP with External RADIUS
3.3.b WGB
– WorkGroup Bridge – WGB Configurations
– WGB with PSK
– WGB Config Example
– WGB with CAPWAP
– WGB with EAP-FAST
- Reliable Multicast with WGB
– WGB – Roaming – Part 1
– IOS AP-WGB with Multiple VLAN
– Unified AP-WGB with Multiple VLAN
3.3.c Bridge
– Autonomous AP – Wireless Bridges
– Autonomous AP – Repeater
3.4 Configure and troubleshoot SSID and MBSSID
– Multiple SSID Config on Autonomous AP
3.5 Configure and troubleshoot security
– Configuring Authentication in AAP
– Autonomous AP with LEAP Security
– Autonomous AP as Local Radius Server
– Autonomous AP with WPA-PSK Security
– Autonomous AP with WEP Security
3.6 Configure and troubleshoot radio settings
– Packet Retries & Max-Retries
– Autonomous AP- Client ARP Caching
– Autonomous AP- Configuring Filters
3.7 Configure and troubleshoot IGMP snooping
3.8 Configure and troubleshoot QoS
– Autonomous AP – QoS
– A Wireless Bridge with QoS
– AAP QoS – A Closer Look
3.9 Configure and troubleshoot WDS (L2)
3.10 Upgrade Autonomous to Unified
– Lightweight to Autonomous (vice versa) Conversion…
– AP Conversion using MODE Button

4.0 Configure and Troubleshoot a Unified Deployment Model (40%)
4.1 Configure and control management access
– Backup & Restore WLC configs
– WLC Discovery via Broadcast
– AP Registration
4.2 Configure and troubleshoot network services
4.3 Configure and troubleshoot interface settings
– Configuring Dynamic Interfaces on WLC
4.4 Configure and troubleshoot a unified AP
– Troubleshooting Wireless LAN
- Deubug EAP Client Authentication
– WLC Client Debug – Part 1
– WLC Client Debug – Part 2
– WLC Client Debug – Part 3
4.4.c Office extend
– Configuring OEAP
– How does OEAP work ?
4.4.d AP modes
4.4.e AP authentication and authorization
4.4.f High availability
– AP Failover
4.4.g Logging
4.4.h Local and global configuration
– Configuring TCP MSS on WLC
4.5 Configure and troubleshoot AP groups
– Configuring AP Groups
4.6 Configure and troubleshoot WLANs
– WLAN Config via CLI – Part 1
– WLAN Config via CLI – Part 2
– WLAN Config via CLI – Part 3
– WLAN Config via CLI – Part 4
– WLAN Config via CLI – Part 5
– WLAN Config via CLI – Part 6
4.6.a Client exclusion
4.6.b Load balancing
4.6.c Band select
4.6.d Passive clients
– Passive Clients
4.6.e DHCP policies
4.6.f Multicast VLAN
– Understanding “VLAN Select” Feature
4.6.g Radio policies
4.7 Configure and troubleshoot H-REAP
- HREAP Modes of Operation
– HREAP with RADIUS
4.8 Configure and troubleshoot radio settings
– Configuring AP Retransmission Interval
– Probe Request Forwarding
4.8.h Cisco CleanAir
– Event Driven RRM
4.9 Implement RRM and Auto RF
4.9.a Country selection
-Configuring Country Codes on WLC
4.9.b CHD, DCA, and TPC
– RF Power Terminology
– RRM Basics
– Configuring RRM
– Configuring TPC
– Configuring Coverage Hole Detection (CHD)
– Configuring DCA
- Configuring ClientLink
4.9.c RF groups
4.9.d Profiles
4.10 Implement local DHCP services for clients
4.11 Configure and troubleshoot security settings
– EAP Overview
– Configuring EAP-TLS on WLC
– PEAP & EAP-FAST with ACS 5.2
4.11.b AAA (WLC to RADIUS or LDAP)
– ACS 5.2 Compatible Browsers
- How to Patch ACS ?
– Called & Calling Station ID
– AAA Override with ACS5.2
4.11.c Local EAP authentication (against local user list and external LDAP)
– Configuring Local EAP on WLC
4.11.d Peer-to-peer blocking
4.11.e L3 security policies (WebAuth and passthrough)
– WLC – Web Authentication
4.11.f WPS settings (IDS)
4.11.g ACL (interface, CPU, and WLAN)
– WLC – Access Control List (ACL)
– WLC ACL via CLI
4.11.h NAC
4.11.i MFP
– Configuring MFP
4.12 Configure and troubleshoot mobility
– Wireless Mobility Basics
– L2 Inter Controller Roaming
– L3 Inter Controller Roaming
– Auto-Anchor Mobility
– Auto-Anchor Foreign Mapping
– Static IP Clients Mobility
– Mobility Ping Tests
– Configuring Mobility on WLC
– Mobility Config via CLI
4.14 Configure and troubleshoot wired and wireless guests
– Wired Guest Access
– Wired Guest Config via CLI

4.15 Configure and troubleshoot multicast
4.16 Configure and troubleshoot QoS
– Understanding Wireless QoS – Part 1
– Understanding Wireless QoS – Part 2
– Understanding Wireless QoS – Part 3
– Understanding Wireless QoS – Part 4
– Understanding Wireless QoS – Part 5
– Who do you trust ? (DSCP or CoS)
- WMM & QoS Profile
– QoS for H-REAP
– Wireless QoS Tech Note
4.17 Configure and troubleshoot mesh

5.0 Configure and Troubleshoot WCS (10%)
5.1 Configure and troubleshoot management access
5.2 Configure and troubleshoot NTP
5.3 Perform basic operations
5.4 Perform maintenance operations
5.5 Security management
– Rogue Classification
5.6 RF management
5.7 Implement MSE
– Mobility Service Engine (MSE)

.
6.0 Configure and Troubleshoot WLAN Services (18%)
6.1 Voice for autonomous deployments
6.2 Voice for unified deployments
– 7925 Deployment Guidelines Summary
- WLC Config for VoWLAN
– 7 Guidelines for Better VoWLAN
– 7925G – Power Management
– Understanding TSPEC
6.3 Video
– Wireless Multicast is not working – Why ?
– Understanding “VideoStream” feature
– Media Stream Config via CLI

You can select these notes from the menu appear in my blog home page as shown below.

Duration/ID field is 2 bytes(16bits) long field in the 802.11 MAC header.

Here is the 16 bit of Duration/ID fieldIn 802.11, Duration/ID field can be used for 3 different reason
1. Virtual Carrier Sense – This is the main purpose which used to reset the NAV timer of the other stations
2. Legacy Power Management – PS Poll frames use this field as an association identifer (AID)
3. Contention-free Period – This field is used as an indicator that a point coordination function (PCF) process has begun.

Virtual Carrier Sense
– Virtual Carrier Sense use a timer mechanism known as the NAV (Network Allocation Vector)
– When listening STA hears a frame transmission by other STA, the listening STA will set its NAV timer to the value appear in transmitted frame.
– listening STA then will use the NAV as a count down timer, knowing that RF medium will be busy until it reach 0.
– When a client transmit a unicast frame, Duration/ID field use bit 0-14 (value 0 – 32767)
– Duration/ID value represent time in μS (microseconds) that is required to transmit the ACK + one SIFS interval.
– Duration values are always about frame transmission that are to follow.
– The client who transmit a frame will calculate how long it will take to receive an ACK frame & include that in the duration field.
– The ACK frame follows the transmitted frame having duration value of 0.

Below shows a frame capture of a unicast frame & ACK followed by the transmission. As you can see duration value of 44 μS (time for a ACK+SIFS) for tx frame & ACK having 0 μS value.

When this type of frame is transmitting in the RF all other receiving STA set their NAV to 44 μS

- NAV is not updated when the receiver address (RA) is the same as receiving station’s MAC address.
– Duration value of the Tx STA does not reset the trasmitter’s NAV timer (as it cannot hear its own tx)
– Transmitter NAV will be zero after transmitting

PS-Poll in Legacy Power Management
– When a STA associate to an AP each STA will get a unique AID (Association Identifier)
– If AP buffering  data for a station in power save mode, when AP transmit its next beacon, the AID of station will be seen in TIM (Traffic Indicator Map)
– TIM field is a list of all stations that have undelivered unicast data buffered on the AP (DTIM is used for multicast buffered data)
– Client will send a PS-Poll frame to request that AP sends the unicast buffered frame to the STA.
– In PS-Poll frame Duration/ID field use as an identifier (AID) &  not being used for duration or resetting NAV timers.
– When it use in PS-Poll frame, tow Most Significant Bits (MSB) set to 1 & AID value use rest of the 14 LSB(Least Significant Bits).
– But allowable value for AID is 1 – 2007.

Below shows a PS-Poll frame capture that shows the AID value (3 in my case) instead of Duration value.Contention-free period in PCF
– When duration field used in PCF, it used a fixed value of 32768 (bit 15 is 1 & all other bits set to 0)
– In all frames transmitted in Contention-free Period (CFP) have duration value of 32768.
– In HCF (Hybrid Coordination Function) Channel Access (HCCA) that require to use CFP.
– None of the vendors not implemented HCCA

Below table summarize the  duration ID field contents & highlighted the 3 main scenarios explained above (source page 90-91 CWAP study guide)

Reference
1. CWAP Official Study Guide – Chapter 3

Related Posts

1. MAC Header : Frame Control
2. MAC Header : Addresses
3. MAC Header : QoS Control
4. MAC Header : Sequence Control

RTS (Request to Send) & CTS (Clear to Send) frames are used to enhance the virtual carrier sense process.  It is possible for a client station to be able to communicate with a AP, but not able to hear or be heard by any of the other client stations. This will lead to possible collisions when a station transmits.

RTS/CTS is a mechanism that performs NAV distribution & helps to prevent collisions from occurring. So when RTS/CTS is enabled on a STA, every time STA want to transmit a frame, it must perform RTS/CTS exchange prior to  the normal data transmission. I have used below topology to see the RTS/CTS behavior.

If you capture wireless frames on CH149, you will see something similar to below & you can clearly see the STA send RTS & then wait for CTS prior to any data transmission.Here is the frame format of a RTS farme. It is 20 byte in length. Frame type is “Control or value 1” & subtype is “RTS or value 11“. Duration value of RTS frame include the time needed for the subsequent frames in the transmit operation to be transmitted.Here is the RTS frame capture. Note that it is 20 byte long Control Frame with subtype 11 (ie RTS). TA is the iPhone5 mac address (04:F7:E4:EA:5B:66) where as RA is the BSSID(1C:6A:7A:BC:4D:6E). Duration set to 124 μS which is the estimated time require to transmit the data frame which includes time for CTS & ACK as well (includes SIFS as well)

When the RTS received by the AP, it will respond with CTS after SIFS & if the medium is idle, to indicate client that he can transmit the data frame. When a STA in the BSS could not hear the original RTS, they may hear the CTS & then adjust their NAV to the duration set in CTS frame. Here is the frame format of a CTS frame.

CTS is a 14 byte long control frame. Subtype is 12 in this case. It simply get the TA of the RTS frame & set it to RA. Duration of the CTS frame is the duration field of RTS, adjusted by subtraction of aSIFS & time required to transmit the CTS frame.

Here is the frame capture of CTS frame. In this case duration is set to 80μS ( 124-44, indicate CTS frame require 44μS ). RA set to iPhoe5 mac address.

Once client get the CTS, he will transmit the Data frame. In this frame duration set to time required to ACK + aSIFS. In my case it is a DNS frame destined to a DNS server in wired side. Destination MAC address is the gateway MAC of the wireless client (Cisco HSRP address 00:00:0C:07:AC:8E in my case).nHere is the data frame captured.

Here is the Acknowledgement frame send to the client (iPhone5) to confirming the data frame received by AP. ACK is 14 byte long frame & duration always set to 0.

Below diagram (figure 9.4 IEEE-802.11-2012 std )summarize the RTS/CTS frame exchange & how each of them duration value is calculated.

RTS duration = SIFS + CTS + SIFS + Data + SIFS + ACK
CTS duration = SIFS + Data + SIFS + ACK

If a data frame is a fragmented MSDU or MMPDU then the Duration/ID field of a data and ACK frames specifies the total duration of the next fragment and acknowledgment as shown below.

In 802.11n where BlockAck is used, a client can send multiple frames before that block of data frames get BlockAck as shown below.

In this case RTS & CTS frame set its duration value to accommodate time required for all these frames.CTS-to-Self
CTS-to-Self is simply another method of performing NAV distribution & that use only CTS frames. It is used strictly as protection mechanism for mixed mode environment. The CTS-to-self NAV distribution mechanism is lower in network overhead cost than is the RTS/CTS NAV distribution mechanism, but CTS-to-self is less robust against hidden nodes and collisions than RTS/CTS. CTS-to-Self duration value is calculated as shown below (page 194- CWAP study guide).

STAs employing a NAV distribution mechanism should choose a mechanism such as CTS-to-self or RTS/CTS that is appropriate for the given network conditions. If errors occur when employing the CTS-to-self mechanism, STAs should switch to a more robust mechanism.

Reference
1. CWAP Official Study Guide – Chapter 5

Related Posts

1. 802.11 Control Frame Types

Discovering the network by scanning all possible channels & listening to beacons is not considered to be very efficient (passive scanning). To enhance this discovery process, stations often use what is called active scanning.

In Active scanning, stations still go through each channel in turn, but instead of passively listening to the signals on that frequency, station send a Probe Request management frame asking what network is available on that channel.

Probe Request are sent to the broadcast DA address (ff:ff:ff:ff:ff:ff). Once a Probe sent, STA starts a ProbeTimer countdown & wait for answers. At the end of the timer, STA process the answer it has received. If no answers received, STA moves to next channel & repeats the discovery process.

STA sending Probe Request may specify the SSID they looking (called directed probe request). Then only IBSS STA or AP support that SSID will answer. The SSID value can also be set to 0 (ie SSID field is present, but empty). This is called Wildcard SSID or Null Probe Request.

Here is a frame capture of a client association to a BSS. Highlighted the Probe Request/Response frames.

Below shows the detail of Probe Request frame sent by the client which is a management type with subtype value of 4. As you can see client is sending it 6Mbps (lowest supported rate by the client). Address fields are set like below
Address Field-1 = Receiver Address (= Destination Address) ff:ff:ff:ff:ff:ff
Address Fiedl-2 = Transmitter Address (=Source Address) 84:38:38:58:63:D5
Address Field-3 = BSSID ff:ff:ff:ff:ff:ff

SSID field set to “OPEN” indicating it is a directed probe request. It list all supported rates, HT capabilities, Extended Capabilities, VHT Capabilities & other vendor specific attributes of the client.

Here is the full list of information fields that can be in a Probe Request (source IEEE 802.11-2012). Note that VHT capability element added to this list in 802.11-2013 (802.11ac) amendment.Here is the Probe Response. As you can see it send 24Mbps (as AP does not support any rates below that) which is lowest common rate supported by both STA & AP. DA field is set to the STA mac from which the probe request was sent. It has lots of other fields to describe the BSS & it is very similar to a Beacon frame fields. But there are 3 noticable differences between Probe Response & Beacon

1. The beacon frame contain a TIM, the probe response does not
2. The beacon frame contain a QoS Capability information Element
3. The probe response contain the Requested Information elements that may have been requested by the probing station.

Here is the complete list of field that can be in the frame body of a Probe Response frame. (source IEEE 802.11-2012)Once Probe Response received by the STA, it should send an  ACK frame to the AP. This frame sent on lowest common rate which is 24Mbps in my case.

Below shows the frame capture of same client sending null probe request & receiving probe responses from all BSSID operating in that channel. (In my case two BSSID responds)

Here is the Probe request detail in this case. Note that SSID field set to 0 & sent in in lowest rate supported by client which is 6Mbps in this case.

Here is the Probe Response came from BSSID (88:38:61:99:1A:AF) which is advertising SSID named “OPEN“Here is the Probe Response came from BSSID(88:38:61:99:1A:AE) which is advertising SSID named “MRN-EAP“References
1. CWAP Official Study Guide – Chapter 4
2. IEEE 802.11-2012 Standard

Related Posts

1. 802.11 Mgmt Frame Types
2. 802.11 Mgmt : Beacon
3. 802.11 Mgmt : Association Req/Res
4. 802.11 Mgmt : Authentication Frame
5. 802.11 Deauthentication & Disassociation
6. 802.11 Mgmt : Information Elements
7. 802.11 Mgmt : Action Frames
8. 802.11 Mgmt : Spectrum & TPC
9. 802.11 Mgmt : Admission Control

When 802.11 authentication (not the RSN-WPA/WPA2 authentication) completes, a STA move to Association phase to the BSS. The purpose of this exchange is to join the cell & obtain an Association Identifier (AID). Below shows a typical client association where you can see Association Request & Association Response followed by 802.11 Authentication frames (request & response)

Association Request frame is having following frame format (CWAP Study Guide- Page 136)

Listen Interval:
The Listen Interval field is used to indicate to the AP how often a STA in power save mode wakes to listen to Beacon management frames. It is expressed in units of beacon interval. The value 0 might be used by a STA that never enters power save mode. An AP may use the Listen Interval information in determining the lifetime of frames that it buffers for a STA.

Below table summarize the information contain in a Association Request frame. (source IEEE 802.11-2012)

In 802.11-2013 (802.11ac) amendment below two additional fields added to above list.Here is the Association Request frame capture. Note that its type is “management” or value 0 with subtype value of 0 (Association Request). Listen Interval listed as 10. As you can see it listed the SSID trying to associate, supported data rate, Power capability, Supported Channels, HT & VHT capabilities.

AP send an ACK for the Association Request frame sent by STA

After acknowledging reception of the Association Request frame, the AP examine each field of the request & verify they all match its own 802.11 parameters. If there is a mismatch, AP decides whether this difference is a blocking factor (to the association).If the differences is not blocking, the AP take note of those differences & grant access to the cell, indicating own parameters in the Association Response frame. If the difference is blocking AP reject the association (status code =1). Here is the  frame format of Association Response frame. (page 139- CWAP Study Guide)

Here is the Association Response capture in the given frame exchange. Note that status code 0 (successful) & AID of 4 allocated for this client.

This Association Response will ACK by the STA.Here is the information contain in Association Response frame (source IEEE 802.11-2012).802.11ac amendment added following field onto Association Response frame.

References
1. CWAP Official Study Guide – Chapter 4
2. IEEE 802.11-2012
3.

Related Posts

1. 802.11 Mgmt Frame Types
2. 802.11 Mgmt : Beacon
3. 802.11 Mgmt : Probe Req/Res
4. 802.11 Mgmt : Authentication Frame
5. 802.11 Deauthentication & Disassociation
6. 802.11 Mgmt : Information Elements
7. 802.11 Mgmt : Action Frames
8. 802.11 Mgmt : Spectrum & TPC
9. 802.11 Mgmt : Admission Control

Reassociation Request frame sent only by a STA to an AP & used when the STA already associated to the ESS & want to associate to another AP connecting to the same ESS. This frame can also be used if the STA left the cell for a short duration & want to rejoin the cell again.

We will use the below topology to look into Reassociation Request/Response frames detail. In this post we will not discuss 802.11r process in detail & refer this post  if you require more on that.

If you capture wireless frames on CH149, you should see the Reassociation Request & Response frame exchange as shown below.

Frame format of a Reassociation Request frame is shown below.

When STA move from LAP2 to 3702-2 AP cell area, you will  noticed STA roamed to 3702-2 AP. To initiate this process STA will send a  Reassociation Request frame to the 3702-2.

Here is the Reassociation Request send by iPhone5. It is a management frame with subtype 2. Note that it will ist the Current AP Address (LAP2- B8:38:61:99:1A:AE) STA is associated to.  STA can be associated to ONE AP at any given time where as it can be authenticated to multiple AP. Note that FTE & MDIE information element is there because BSS is configured for 802.11r FT.

Here is the list of information contain in the frame body of a Reassociation Request frame (source IEEE 802.11-2012)

Once AP received the Reassociation Request will acknowledge that by sending an ACK.

Then AP will respond with Reassociation Response frame. It is a management frame with subtype 3. Depend on the information provided in Reassociation Request, AP may or may not be allow STA to join. In given scenario status code=0 implies a successful reassociation & AID is given for the client (AID=1 in my case).

Here is the complete list of information that can be in the frame body of Reassociation Response frame. (source IEEE 802.11-2012)

Finally client STA will send an ACK for the Reassociation Response frame.

References
1. CWAP Official Study Guide – Chapter 4
2. IEEE 802.11-2012 Standard

Related Posts

1. 802.11 Mgmt Frame Types
2. 802.11 Mgmt : Beacon
3. 802.11 Mgmt : Association Request/Response
4. 802.11 Mgmt : Probe Req/Response
5. 802.11 Mgmt : Authentication Frame
6. 802.11 Deauthentication & Disassociation
7. 802.11 Mgmt : Action Frames
8. 802.11 Mgmt : Spectrum & TPC
9. 802.11 Mgmt : Admission Control

The Channel Switch Announcement element is used by an AP in a BSS, a STA in an IBSS, or a mesh STA in an MBSS to advertise when it is changing to a new channel and the channel number of the new channel. The format of the Channel Switch Announcement element is shown below (source IEEE 802.11-2012)Length : set to 3 bytes
Channel Switch Mode :
Indicates any restrictions on transmission until a channel switch. An AP in a
BSS or a STA in an IBSS sets the Channel Switch Mode field to either 0 or 1 on transmission. In an MBSS,the Channel Switch Mode Field is reserved
New Channel Number: set to the number of the channel to which the STA is moving.
Channel Switch Count: for nonmesh STAs, this  field either is set to the number of TBTTs until the STA sending the Channel Switch Announcement element switches to the new channel or is set to 0. A value of 1 indicates that the switch occurs immediately before the next TBTT. A value of 0 indicates that the switch occurs at any time after the frame containing the element is transmitted.

This Channel Switch Announcement element present in beacons & probe responses. Channel Switch Announcement element also associated with an action frame (spectrum management type or category type =0) that can be sent by the AP between beacons to announce the channel switch.

Here is the frame format of Action Frame that contain the Channel Switch Announcement field.

Here are some important points about Channel Switch Announcement in a BSS.

• An AP shall inform associated STAs that the AP is moving to a new channel and maintain the association by advertising the switch using Channel Switch Announcement elements in Beacon frames, Probe Response frames, and Channel Switch Announcement frames until the intended channel switch time.
• The AP may force STAs in the BSS to stop transmissions until the channel switch takes place by setting the Channel Switch Mode field in the Channel Switch Announcement element to 1.
• The channel switch should be scheduled so that all STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Channel Switch Announcement element before the switch.
• The AP may send the Channel Switch Announcement frame in a BSS without performing a backoff, after determining the WM is idle for one PIFS period.
• A STA that receives a Channel Switch Announcement element may choose not to perform the specified switch, but to take alternative action. For example, it may choose to move to a different BSS.
• A STA in a BSS that is not the AP shall not transmit the Channel Switch Announcement element

References
1. CWAP Official Study Guide – Chapter 4
2. IEEE 802.11-2012 Standard

Related Post

1. 802.11 Mgmt : Action Frames

The Block Ack mechanism improves channel efficiency by aggregating several acknowledgments into one frame. There are two types of Block Ack mechanisms, immediate and delayed. Immediate Block Ack is suitable for high-bandwidth, low-latency traffic while the delayed Block Ack is suitable for applications that tolerate moderate latency.

The Block Ack mechanism is initialized by an exchange of ADDBA Request/Response frames. After initialization, blocks of QoS data frames may be transmitted from the originator to the recipient. A block may be started within a polled TXOP or by winning EDCA contention. The MPDUs within the block of frames are acknowledged by a BlockAck frame, which is requested by a BlockAckReq frame.

Below diagram (source IEEE 802.11-2012) shows message sequence chart for the setup, data and Block Ack transfer, and the teardown of the Block Ack mechanism.

Setup
Tx STA (originator) first check whether the intended recipient STA is capable of participating in BlockAck mechanism by discovering and examining its Delayed Block Ack and Immediate Block Ack capability bits. If the intended recipient STA is capable of participating, the originator sends an ADDBA Request frame indicating the TID for which the Block Ack is being set up.

The recipient STA shall respond by an ADDBA Response frame. The recipient STA has the option of accepting or rejecting the request. When the recipient STA accepts, then a Block Ack agreement exists between the originator and recipient.

Data & BlockAck
Originator may transmit a block of QoS data frames separated by SIFS period, with the total number of frames not exceeding the Buffer Size subfield value in the associated ADDBA Response frame and subject to any additional duration limitations based on the channel access mechanism. Each of the frames shall have the Ack Policy subfield in the QoS Control field set to Block Ack.

The originator requests acknowledgment of outstanding QoS data frames by sending a Basic BlockAckReq frame. The recipient shall maintain a Block Ack record for the block.

Below shows the BlockAck sequence when using delayed block ack policy

Teardown
When the originator has no data to send and the final Block Ack exchange has completed, it shall signal the end of its use of the Block Ack mechanism by sending the DELBA frame to its recipient. There is no management response frame from the recipient. The recipient of the DELBA frame shall release all resources allocated for the Block Ack transfer.

The Block Ack agreement may be torn down if there are no BlockAck, BlockAckReq, or QoS data frames (sent under Block Ack policy) for the Block Ack’s TID received from the peer within a duration of Block Ack timeout value.

Here is a frame capture shown this BlockAck frame exchange.Here is the Add Block Ack Request (ADDBA Request) frame detail (frame 284). It is an management action frame (action category 3 & action code 0). You can find these frame using following wireshark display filter.

(wlan_mgt.fixed.category_code == 3)&&(wlan_mgt.fixed.action_code == 0)

Dialog Token
The Dialog Token field is set to a nonzero value chosen by the STA.

Block Ack Parameter
The Block Ack Parameter Set field is used in ADDBA frames to signal the parameters for setting up a Block Ack. The length of the Block Ack Parameter Set field is 2 bytes. The Block Ack Parameter Set field is shown in below.

A-MSDU Supported: determines whether an A-MSDU may be carried in a QoS data MPDU sent under this Block Ack agreement. When equal to 1, use of A-MSDU is permitted. When equal to 0, use of A-MSDU is not permitted.
Block Ack Policy:  set to 1 for immediate Block Ack and 0 for delayed Block Ack.
TID:  contains the value of the TC or TS for which the BlockAck is being requested.
Buffer Size: indicates the number of buffers available for this particular TID.When the AMSDU Supported field is equal to 0 as indicated by the STA transmitting the Block Ack Parameter Set field, each buffer is capable of holding a number of octets equal to the maximum size of an MSDU. A-MSDU Supported field is equal to 1 as indicated by the STA, each buffer is capable of holding a number of octets equal to the maximum size of an A-MSDU that is supported by the STA.

Block Ack Timeout
The Block Ack Timeout Value field (2 byte) is used in the ADDBA Request and Response frames to indicate the timeout value for Block Ack.

Here is the ADDBA Response frame detail. It is Management Action frame (Category 3 & action code 1). Status code 0 mean it is ADDBA request accepted by recipient STA.  Dialog Token value is copied from the ADDBA Request frame.

(wlan_mgt.fixed.category_code == 3)&&(wlan_mgt.fixed.action_code == 1)

ADDBA Response frame has following fields

Once Originator send block of frames it is requesting recipient to acknowledge them. This request is done by sending a BlockAck Request frame which is a control frame.Here is the frame format of this BlockAck Request frame.

For BlockAckReq frames sent under Delayed and HT-Delayed agreements, the BAR Ack Policy subfield of the BAR Control field has the meaning shown in Table 8-15. For BlockAckReq frames sent under other types of agreement, the BAR Ack Policy subfield is reserved.Here is the BlockAck frame sent by the recipient STA.

For BlockAck frames sent under Delayed and HT-Delayed agreements, the BA Ack Policy subfield of the BA Control field has the meaning shown in Table 8-17. For BlockAck frames sent under other types of agreement, the BA Ack Policy subfield is reserved. The DELBA frame is sent by either the originator of the traffic or the recipient to terminate the Block Ack participation. The Action field of a DELBA frame format contains the information shown below.References
1. IEEE 802.11-2012 Standard
2. CWAP Official Study Guide – Chapter 5

There is lot of excitement (read this) about Cisco is leading the way to come up with a new standard  to deliver more than 1Gbps data rate using existing cat5e/6 cabling. NBaseT alliance (started by Cisco, Aquantia, Freescale and Xilinx) formulated to achieve below common goals.

• Promote collaboration and dialogue for developing technology to enable speeds greater than 1Gbps on existing Category 5e and Category 6 cabling infrastructure.
• Work in conjunction with standards bodies to standardize speeds greater than 1Gbps on existing Category 5e and Category 6 cabling infrastructure.

As you already aware, this is required to bring 802.11ac wave-2 product where it will deliver upto 6.8Gbps data rate. Customers who has already deployed cabling infrastructure cannot get max benefit, unless there is a way to deliver more than 1Gbps in their existing cabling.

So what does this mean to Cisco customers ? There will be a new Access Layer switch products will come into market that support this NBaseT (2.5G/5G over cat5e/6). So if your access layer switches are due to replace, then you have to think twice now. Go with 1Gbps switches or buy this NBaseT switches, I would wait for NBaseT :smile:

I saw Peter Jones (@petergjones) chairing this alliance by looking at his twitter profile.

“Principal Engineer@Cisco in Catalyst Switching (3850, ConvergedAccess, UADP, etc), NBASE-T alliance chair, 802.1/802.3 geek“

He is the founder of ASIC used for UADP (Unified Access Data Plane) used in 3850/3650 Unified Access switch platforms (also in 5760 & Sup8e as well). Here is a Ciscolive presentation to learn about this new ASIC & UAPD architecture

This leads me to think these Unified Access switch platforms (next hardware version) will be leading the way support for this NBaseT in your access layer.

How many of you using 3850/3650 switches on you access layer today ? If you are not, time will come soon to decide.