1. Proposal for Diagnostics and Troubleshooting
Month Year
November 2005
November 2005
Proposal for Diagnostics and Troubleshooting
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Emily Qi et al
Emily Qi et al

2. Month Year
November 2005
November 2005
Abstract
This document contains an outline of the normative text proposal for Diagnostics and Troubleshooting (doc#: 11-05/1070r1) in support of Diagnostics and Troubleshooting objective in accordance with REQ2070.
Emily Qi et al
Emily Qi et al

3. Agenda Design Goals Alerts Event Logs Diagnostic Channel
Month Year
November 2005
November 2005
Agenda
Design Goals
Alerts
Event Logs
Diagnostic Channel
Work-in-Progress
Emily Qi et al
Emily Qi et al

4. November 2005
Design Goals
Define an extensible framework to improve wireless network Diagnostics and Troubleshooting
Define a protocol to allow STAs to report alerts when a certain failure occurs or performance degrades
Define a protocol to allow STAs to report event log data
Define a mechanism to allow STAs to request the execution of diagnostics and report diagnostic results
Emily Qi et al

5. Introduction to Alerts
Month Year
November 2005
November 2005
Introduction to Alerts
Alert will get triggered in certain problem or failure scenarios and help the network to diagnose the problems and gain management attention
Proposed Alerts
Transition Alert
shall be sent by a STA when the STA has been roaming from one AP to another for a certain number of times during the specified time duration.
may indicate an unstable network or a weak coverage area.
RSNA Failure Alert
shall be sent by a STA when any one or more of the RSNA failure counters exceeds the specified threshold
may be used by the network to detect attackers or diagnose encryption problems at an early stage.
Blacklisted BSS Alert
shall be sent by a STA to report “bad” BSSs or “barred” BSSs that the STA cannot (re)associate with.
may be used for the network to diagnose these blacklisted BSSs to decide whether these blacklisted APs shall be excluded in the Neighbour Report.
Emily Qi et al
Emily Qi et al

6. Proposed Alert Request/Report Frames
November 2005
Proposed Alert Request/Report Frames
Action Frames – Class 3
Alert Request provides a means for a STA to set up the expectation or the triggers for another STA to send an Alert Report
An Alert Report shall be sent to the requesting STA when the trigger condition is met. Once an alert is reported, the counters should be reset.
Multiple Alert Reports may be sent once the trigger condition is set in the Alert Request frame
Alert Request frame body format:
Category
Action
Alert Request elements
Octets: 1
variables
Alert Report frame body format:
Category
Action
Alert Report elements
Octets: 1
variables
Emily Qi et al

7. Proposed Alert Request element
November 2005
Proposed Alert Request element
Alert Request element contains the triggers for an alert to be reported when STA gets triggered in certain problems or failure scenarios.
Element ID
Length
Alert Mode
Frequent Transition
Threshold (optional)
RSNA Failure
Threshold
(optional)
Octets: 1 2
Alert Request element format B0 B1 B3
B15
Frequent Transition
RSNA Failure
Blacklisted BSS
Reserved
Bits: 1 14
Alert mode field
Emily Qi et al

8. Proposed Alert Report elements
Month Year
November 2005
November 2005
Proposed Alert Report elements
Alert Report element
Element ID
Length
Alert Type
Alert Report
Octets: 1
variable
Alert Reports
Transition Alert Report
Transition count, Time duration, etc.
RSNA Failure Alert Report
dot11RSNAStatsTKIPICVErrors,
dot11RSNAstatsTKIPRemoteMICFailures
dot11RSNAstatsTKIPLocalMICFailures
dot11RSNAMgmtStatsCCMPDecryptErrors
dot11RSNAMgmtStatsCCMPReplays, etc.
Blacklisted BSS Alert Report
BSSID list
Emily Qi et al
Emily Qi et al

9. Introduction to Event Log
Month Year
November 2005
November 2005
Introduction to Event Log
Provides a means and a protocol to exchange the logged events or traces to enable network real-time diagnostics
A STA can report all of the traces or only a subset of all the traces
If any of the Filtering Condition bits are set in the Event Log Request, the Event Log Report shall only include the logged events that meet the specified filtering condition.
Proposed Event Logs
Transition Event Log
RSNA Event Log
Direct Link Event Log
Syslog Event Log
Emily Qi et al
Emily Qi et al

10. Proposed Event Log Request/Report Frames
November 2005
Proposed Event Log Request/Report Frames
Action Frame – Class 3
An STA receiving an Event Log Request shall respond with an Event Log Report Frame containing, respectively, one or more Event Log Report elements
Event Log Request frame format:
Category
Action
Dialog Token
Event Log Request Elements
Octets: 1
variable
Event Log Report frame format:
Category
Action
Dialog Token
Event Log Report Elements
Octets: 1
Variables
Emily Qi et al

11. Proposed Event Log Request elements
November 2005
Proposed Event Log Request elements
Event Log Request element format
Element ID
Length
Event Log Token
Event Log Type
Filtering Reporting Condition
Octets: 1
variable
Filtering Reporting Condition field format for Transition Event Log (example)
Filter Condition
Filter Target BSSID
Filter Source BSSID
Transition Time Threshold
Octets: 1 6 2
Filter Condition field for Transition Event Log (example) B0 B1 B2 B3 B4 B5 B7
Target BSSID
Source BSSID
Transition
Time
Failed
Successful
Reserved
Bits: 1 5
Emily Qi et al

12. Proposed Event Log Report elements
November 2005
Proposed Event Log Report elements
Event Log Report element format
Element ID
Length
Event Log Token
Event Log Type
Event Log Report
Octets: 1
variable
Event Log Report
Transition Event Log Report
Source BSSID, Target BSSID, Transition Time, Transition Reason, Transition Result
RSNA Event Log Report
Target BSSID, RSN IE, i Auth Type, RSNA Result
Direct Link Event Log Report
Peer STA Address, Connection Time
Syslog Report
Emily Qi et al

13. Introduction to “Diagnostics Channel”
Month Year
November 2005
November 2005
Introduction to “Diagnostics Channel”
A mechanism that automates the troubleshooting of client problems communicating with the WLAN
Triggered by a client having connection difficulties
The STA and AP will proceed through a defined set of tests and responses in an attempt to identify the cause of the communication difficulties experienced by the STA
May also be utilized by an AP to diagnose a STA that is associated with a “service” WLAN
Emily Qi et al
Emily Qi et al

14. Proposed Diagnostics and Tests
Month Year
November 2005
November 2005
Proposed Diagnostics and Tests
Client Report
exchanging client information
Authentication
determines that the client is able to perform an authentication properly with a designated WLAN
(Re) Association
determines that the client is able to associate properly with a designated WLAN
802.1X Authentication
determines that the client is able to properly complete an 802.1X authentication with a designated WLAN.
Emily Qi et al
Emily Qi et al

15. Proposed Diagnostic Request/Report Frames
November 2005
Proposed Diagnostic Request/Report Frames
Action frame – Class 3
To initiate the test or report, the AP shall send a Diagnostic Request frame to the client. All parameters required to complete the report or test are included in the Diagnostic Request element.
Upon receipt of the Diagnostic Request frame, the STA shall report a STA information, or cause the normal protocol stack to perform the corresponding test using the requested parameters
Diagnostic Request frame format:
Category
Action
Dialog Token
Diagnostic Request Elements
Octets: 1
variable
Diagnostic Report Frame format:
Category
Action
Dialog Token
Diagnostic Report Elements
Octets: 1
variable
Emily Qi et al

16. Proposed Diagnostic Request elements
November 2005
Proposed Diagnostic Request elements
Diagnostic Request elements
Element ID
Length
Diagnostic
Token
Request Type
Request
Octets: 1
variable
Diagnostic Request
Client Report Request: Client Report Group Type
Authentication: AP Descriptor and Profile ID
(Re) Association: AP Descriptor and Profile ID
802.1X Authentication: AP Descriptor, 802.1X parameters, 802.1X credentials, and Profile ID
Emily Qi et al

17. Proposed Diagnostic Report elements
November 2005
Proposed Diagnostic Report elements
Diagnostic Report elements
Element ID
Length
Diagnostic
Token
Report Type
Status
Report
Octets: 1
variables
Diagnostic Status: successful, fail, refused, and incapable
Diagnostic Report
Client Report: Manufacturer Information contents, Operating Parameters contents, Capabilities contents, etc.
Authentication Report: AP Descriptor and Status code
(Re) Association Report: AP Descriptor and Status code
802.1X Authentication Report: AP Descriptor and Status code
Emily Qi et al

18. Month Year
November 2005
November 2005
Work-in-Progress
The following elements for diagnostics and tests will be defined:
Antenna Type
Antenna Gain
Radio Channels
TX Power Levels
Data Rates
Encryption Type
Authentication Type
EAP Method
Power Save Mode
Status Code
Manufacturer OUI
Manufacturer ID String
Manufacturer Model String
Manufacturer Serial Number String
Radio Type
Firmware Version
MAC Address
Emily Qi et al
Emily Qi et al

19. November 2005
Feedback?
Emily Qi et al