doc.: IEEE /0841r0 Submission May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 1 Verification of TGai Requirements Date: Authors:

doc.: IEEE /0841r0 Submission May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 2 Abstract This document provides initial discussion points to decide on how to show compliance to TGai Requirements.

doc.: IEEE /0841r0 Submission May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 3 Verification of Requirements vs. System Performance Verification of Requirements –Very abstract, synthetic scenarios –Focus on a single aspect of the system –Represent the best case behaviour that can be expected –Usually do not show interaction between parameters –Define conditions for “being compliant” to a requirement System Performance –More complex evaluation to show interaction between parameters, or to evaluate proposals in scenarios reflecting considered use cases –Ideal (e.g. fixed data rate, free space los LOS channel) and/or more realistic conditions (other channel model, rate adaptation, etc.) Focus of today’s presentation

doc.: IEEE /0841r0 Submission May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 4 ToC Evaluation Methodology Document Introduction – Metrics – –Link Set-Up Time –User Load –Background load System Evaluation –Compliance to System Requirements FC-1 FC-2 –Use-Case-based Performance Evaluation Annex –Channel Models LOS free-space channel –Evaluation Scenarios / Set-Up

doc.: IEEE /0841r0 Submission Verification of FUNCTIONAL Requirements Req (Link Set-Up): Support of link set-up (includes AP detection, network discovery, association and auth., IP-address assignment –Abstract analysis of features showing “existence” of feature Req (Robustness against large number of users) –Experiment to show how well an approach scales with different number of users. –Metric: Link-Set-Up Time (as function of link attempt rate) Direct-proportional, over-proportional, or sub-proportional (?) –Ideal channel (LOS free-space path loss), fixed data rate May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 5

doc.: IEEE /0841r0 Submission Verification of FUNCTIONAL Requirements (2) Req (concurrency in information exchange) –Abstract analysis of features showing “existence” of feature May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 6

doc.: IEEE /0841r0 Submission Verification of PERFORMANCE Requirements Req (Link-Set-Up Time): –Report Link Set-Up Time for Single STA, single AP LOS free-space loss channel, fixed data rate Assumptions / knowledge used to minimize LSU Time (e.g. external knowledge on used channels); Should we define one scenario for “know knowledge at all?” LSU Time shall be < 100ms to for compliance to requirement –Additional performance evaluations for general performance evaluation section: LSU-Time as function of a) link attempt rate, b) background load –Report percentile for LSU-Time < 100ms as a function of parameter –Other values useful ? (e.g. percentile for LSU Time < 5, 10, 20, 50 ms) –Other channel models / rate adaption as options May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 7

doc.: IEEE /0841r0 Submission Verification of PERFORMANCE Requirements (2) Req (support of min. user load) –Metric: Link Set-Up Time as function of link attempt rate –LOS free space channel, fixed data rate –Report 100% percentile of LSU Time for an attempt rate of 100 (note: if not *all* STAs can conduct a link set-up, “infinite” shall be reported; avoid just reporting the maximum of measured LSU Times as this might not show that not all STAs have successfully conducted a LSU). To show compliance, this value has to be a finite value. –Additional performance evaluations for general performance evaluation section: see Req May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 8

doc.: IEEE /0841r0 Submission Verification of PERFORMANCE Requirements (3) Req (robustness against background load) –Metric: Link Set-Up Time as function of background load –Single AP, Single STA to establish a link –Fixed STAs producing background load (need to define traffic profile. What to choose here? UDP-based traffic causing xxx Mbps per STA) –LOS free space channel, fixed data rate –Report 100% percentile of LSU Time for a background load of 50% (note: if not *all* STAs can conduct a link set-up, “infinite” shall be reported; avoid just reporting the maximum of measured LSU Times as this might not show that not all STAs have successfully conducted a LSU). To show compliance, this value has to be a finite value. –Additional performance evaluations for general performance evaluation section: see Req May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 9

doc.: IEEE /0841r0 Submission Verification of CONSTRAINTS Req (Maintaining RNSA’s security level) –The TGai amendment shall assure maintaining RSNA’s security level. Solutions shall demonstrate that they do not degrade the security offered by Robust Security Network Association (RSNA) already defined in Solutions employing security schemes other than RSNA shall demonstrate that they are at least as secure as RSNA –How do we show this? What shall be provided for verification purposes? –It should be in a form that can be used to proof to WG that the requirement is met (to be useful as part of security review). May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 10

doc.: IEEE /0841r0 Submission Verification of CONSTRAINTS (2) Req (Backward compatibility) –Abstract analysis of features showing “existence” of feature –Can be as simple as showing that any STA can at any time fall back to existing link set-up schemes in case a non-TGai STA is involved in the process of establishing a link. May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 11

doc.: IEEE /0841r0 Submission May 2011 Marc Emmelmann, Fraunhofer FOKUSSlide 12 References 11-11/0745r05: TGai Requirements Document 11-11/0238r19: Use Case Reference List for TGai