1. Proposal for Diagnostic Alerts
March 2006
March 2006
March 2006
Proposal for Diagnostic Alerts
Authors:
Date:
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
Simon Black et al
Simon Black et al

2. March 2006
March 2006
March 2006
Abstract
This document contains an outline of the normative text proposal for Diagnostic Alerts in document 06/0428. It is submitted in support of the Diagnostics and Troubleshooting objective (REQ2070).
Simon Black et al
Simon Black et al

3. March 2006
March 2006
March 2006
History
Based on Part I and Part III of 05/1076r0 (Framework for 11v Diagnostic Alerts) from November 2005
Merged with 05/1070r1 (Diagnostics and Troubleshooting) and 05/1082 (Simple Diagnostics) to form 05/1070r3 (Normative Text Proposal for Diagnostics and Troubleshooting) – presented in Hawaii in January
Basic framework for triggered measurement based diagnostic alerts adopted as part of the 11v framework (06/0167)
Simon Black et al
Simon Black et al

4. Review of Diagnostic Alerts
March 2006
Review of Diagnostic Alerts
A mechanism to allow STAs to send a report when performance degrades or failure occurs.
Based on the Radio Measurement Request and Report structures and triggered measurement protocol defined in .11k
Simon Black et al

5. March 2006
What’s in 06/0428 then?
The three specific diagnostic alerts from the 05/1070r3 proposal – updated to build on the baseline adopted in D0.01
Simon Black et al

6. Proposed Diagnostic Alerts
March 2006
Proposed Diagnostic Alerts
Triggered QoS Metrics (as defined in .11k D3.0)
Triggered STA Statistics (based on the 11k STA Statistics measurement)
Added the triggered reporting mechanism to the 11k STA Statistics measurement
Defined new STA Statistics RSNA Counters and Triggers (based on 05/1124r0)
Multicast Diagnostics (as proposed in Part III of 05/1076r0)
Simon Black et al

7. Triggered STA Statistics
March 2006
Triggered STA Statistics
Simple trigger condition based on a STA statistics counter incrementing by more than a defined threshold within a specified measurement count.
Defined new STA counters group defined based on IEEE802.11i counters
Simon Black et al

8. Multicast Diagnostics
March 2006
Multicast Diagnostics
New Multicast Diagnostics defined as a new measurement type
Setup using a Multicast Diagnostics Request
Multicast address and trigger condition specified in the request
Can be set for Broadcast traffic too
Single trigger condition currently defined
Timeout report generated if no multicast frames to the multicast address are received during a specified time interval
A Multicast Diagnostics Report can be requested too
Returns a total multicast frame count for a specified multicast address
Simon Black et al