Proposal for Diagnostics and Troubleshooting Month Year November 2005 November 2005 Proposal for Diagnostics and Troubleshooting Date:2005-11-04 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Emily Qi et al Emily Qi et al

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

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

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

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

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

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

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

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

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

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

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, 802.11i Auth Type, RSNA Result Direct Link Event Log Report Peer STA Address, Connection Time Syslog Report Emily Qi et al

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

Proposed Diagnostics and Tests Month Year November 2005 November 2005 Proposed Diagnostics and Tests Client Report exchanging client information 802.11 Authentication determines that the client is able to perform an 802.11 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

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

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 802.11 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

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. 802.11 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

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

November 2005 Feedback? Emily Qi et al