Triggered Measurements as a framework for 11v Diagnostic Alerts November 2005 doc.: IEEE 802.11-05/1077r0 November 2005 Triggered Measurements as a framework for 11v Diagnostic Alerts Date: 2005-11-06 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>. Simon Black et al, Nokia Simon Black et al, Nokia

November 2005 doc.: IEEE 802.11-05/1077r0 November 2005 Abstract 11v has an objective (in 05/0827) to support ‘reactive diagnostics’ or alerts as described in 05/0905 ‘TGv should provide a mechanism to allow STAs to report alerts when a failure occurs or performance degrades’ 11k/D3.0 describes a QoS triggered measurements mechanism that could form the basis of a management diagnostics alert solution for 11v Simon Black et al, Nokia Simon Black et al, Nokia

Contents of this Summary Presentation November 2005 Contents of this Summary Presentation Some background on 11k triggered measurement An overview of the proposal Normative text in 05/1076) Two proposed triggered diagnostics Multiradio STA performance reporting Multicast performance reporting Simon Black et al, Nokia

Triggered QoS Measurement November 2005 Triggered QoS Measurement A reporting mode based on the QoS Metrics measurement in 11k Overview in 05/0294r1 Normative text in 1k D3.0 from 05/0512r2 and 05/1005r0 A few slides from 05/0294r1 … Simon Black et al, Nokia

QoS Measurements - Observations November 2005 QoS Measurements - Observations QoS metrics measurement is not invasive in normal operation Does not involve measurement on a non-serving channel Measurement data is particularly useful when there is something to report For example, a QSTA experiences lengthening transmission delay, or multiple transmission failures Repeated measurements may successfully report this, but Will also report when conditions are fine – wasting bandwidth and QAP processing May miss periods of difficulty if measurement is not continuous Autonomous measurements might help, but The QAP has no control over what the QSTA reports so can’t rely on receiving useful data Simon Black et al, Nokia

Triggered Measurements November 2005 Triggered Measurements What is needed is a QoS measurement scheme that Runs continuously at a QSTA – regardless of measurement requests of other types Only reports when needed Reports before things get too bad The QAP has control over and can rely on The QoS metrics measurement provides the right report content All that is needed is a triggering mechanism with parameters controlled by the QAP Simon Black et al, Nokia

Triggered QoS Measurement Overview November 2005 Triggered QoS Measurement Overview QAP enables triggered measurement and sets up trigger conditions in measurement request Autonomous measurements disabled by default Set up on a per traffic stream as a triggered autonomous measurement QSTA may refuse to accept triggered measurement by using the refused bit in a measurement report QSTA sends measurement report if trigger conditions are met Measurement Report is a QoS Metrics Report for the traffic stream – exactly as for a requested measurement QAP has control of the measurement and therefore can effectively use the data Measurement disabled by QAP sending a measurement request turning off the measurement, or Stream is deleted (e.g. QSTA disassociates) Simon Black et al, Nokia

11k Triggered Measurements/11v Management Alerts November 2005 11k Triggered Measurements/11v Management Alerts There is a great deal of similarity between 11k’s triggered measurements and the concept of diagnostic alerts proposed for 11v In fact 11k’s QoS triggered measurements could be seen as a diagnostic alert for QoS operation Could the protocol be extended to cover other areas of interest, i.e. to form a framework for 11v management alerts? Simon Black et al, Nokia

Proposal Overview Normative text proposal in 05/1076r0 November 2005 Proposal Overview Normative text proposal in 05/1076r0 Proposal in three parts Extension of the 11k triggered measurements protocol as a framework for triggered diagnostic alerts Multiradio STA performance reporting as an example of a new management diagnostic using the framework Multicast performance reporting as a second example (related to the enhanced multicast power-save proposal in 05/1074 and 05/1075) Simon Black et al, Nokia

Triggered Measurement based Alert Framework November 2005 Triggered Measurement based Alert Framework STA that’s interested in receiving alerts uses measurement request element specifying trigger conditions for the alert and with enable and report bits set A trigger condition could be a threshold or event based trigger When the trigger condition is met a report is issued that can contain relevant diagnostic data (e.g. relevant statistics) Measurement Request Element Measurement Mode Enable = 1, Report = 1 Trigger Conditions Measurement Report Element Measurement Report ID, Length. Mode Relevant Diagnostic Data Simon Black et al, Nokia

Multi-radio STA performance example November 2005 Multi-radio STA performance example 11v also has a requirement related to multi-radio devices. ‘TGv shall provide a mechanism for notification of performance degradation due to cooperation issues in multi-radio devices’ This was originally presented as an enhancement to 11k link measurement, but it would be possible to define this to work as a triggered alert Simon Black et al, Nokia

November 2005 Multiradio Use Cases Internet access (web browsing, email, …) with WLAN and simultaneous voice call with cellular Local content access via WLAN and cellular for corporate/other access During IEEE meeting WLAN access to meeting documents and simultaneously GPRS connection (with VPN) to corporate emails Content down/upload to/from handheld terminal using WLAN and simultaneous voice call with cellular Images & video clips Audio (mp3) Storage capacity in new handheld terminals is measured in Gbytes Simon Black et al, Nokia

Multi-radio coordination example November 2005 Multi-radio coordination example Define a new measurement type for ‘Multiradio STA performance’ Measurement report contents as previously proposed in the additions to link measurement Define a new measurement request type This can be used to request the information at any time Define level and periodic trigger conditions for the new measurement and allow it to be used within the triggered measurement protocol When the trigger conditions are met the measurement report is issued as an alert Simon Black et al, Nokia

Multicast Performance Reporting November 2005 Multicast Performance Reporting A second proposed diagnostic using the triggered diagnostics framework Setup using Multicast Diagnostic Request Multicast address and trigger condition specified in the request Can be set for Broadcast traffic as well Single trigger condition currently defined Timeout report generated if no multicast frames received during specified time interval Diagnostic report can be requested too Returns a total multicast frame count for a specified multicast address Simon Black et al, Nokia

Advantages of this approach November 2005 Advantages of this approach Flexible framework that builds upon an existing mechanism Allows relevant metrics to be returned with alert for additional diagnostic information Alerts can be enabled and configured by the STA that is interested in receiving the notification Diagnostic data can be obtained on request (rather than as the result of an alert) if desired Simon Black et al, Nokia

November 2005 References 05/1076 Framework for 11v Diagnostic Alerts Normative (Black et al) 05/0827r3 TGv Objectives, (Qi) 05/0905r0 Diagnostics & Troubleshooting (Qi/Canpolat) 05/1074r0 Broadcast and Multicast Enhancements Normative (Jokela et al) 05/1075r0 Broadcast and Multicast Enhancements Overview (Jokela et al) Simon Black et al, Nokia