Month 1998July 2000 doc.: IEEE 802.11-98/xxx January 2001 Discussion of TGh Requirements (00/369) and Comparison Criteria (00/421) Documents Bill McFarland, billm@atheros.com Atheros Communications McFarland, Atheros Communications John Doe, His Company

General Requirements (1.x) January 2001 General Requirements (1.x) 1.2 Was empty. Thought experiment: use it to require compliance with the ETSI document “Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive” What is importance of this ETSI document in European regulations? Does this allow a way around the ERC statement requiring Hiperlan2? If it is critical/useful, should we elevate it to same importance as ERC ruling? What are technical implications? (my interpretation follows) McFarland, Atheros Communications

Implications of including ETSI Essential Reqs January 2001 Implications of including ETSI Essential Reqs Items that are no more specific than given in the ERC recommendation: Total number of channels to be used 200mW EIRP in 5150-5350, 1W EIRP in 5470-5725 (average) DFS to provide avoidance of interference (particularly from radar), uniform loading across 330MHz or 255MHz TPC in up and downlink? to mitigate 3dB on average in Satellite footprint McFarland, Atheros Communications

Implications of including ETSI Essential Reqs January 2001 Implications of including ETSI Essential Reqs Items in ETSI more specific than ERC, but probably NOT an issue: ETSI defines the actual carrier center frequencies Center frequencies within +/-20ppm Transmit spectral mask that appears? to be identical to 802.11a’s McFarland, Atheros Communications

Implications of including ETSI Essential Reqs January 2001 Implications of including ETSI Essential Reqs Items in ETSI more specific than ERC, but MAY be an issue: Out of band emission limits Are these different than standard CEPT rules? Receive spurious limits Do these limits apply within the Hiperlan band? Specifics about the the test mechanisms to confirm conformance (in sections 5 and 6 of of the ETSI document) 2ms packet repetition rate Exact controlled and consistent duty cycle of Tx during tests McFarland, Atheros Communications

Suggested Change to Requirements 1.2 January 2001 Suggested Change to Requirements 1.2 1.2 A device implementing TGh functionality shall meet the requirements listed in sections 1 through 4 of ETSI EN 020002-2 “Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive” Also need to add the ETSI EN sections 1 through 4 reference to 2.1.1 and 3.1.1 for consistency McFarland, Atheros Communications

Issues with Requirements Item 1.3 January 2001 Issues with Requirements Item 1.3 1.3 No functionality specified by TGh shall cause an existing IEEE 802.11 MAC and IEEE802.11a PHY mechanisms to become non-conformant My general concern is over the use of reserved, vendor proprietary, or undefined bits to carry the extra information What are general 802.11 rules of the road? Is there likely to be trouble with PHY layer bits? What about MAC layer bits? What will be the resolution mechanism if a conflict arises? McFarland, Atheros Communications

Issues with Requirements 1.X January 2001 Issues with Requirements 1.X In general, should functional requirements be enumerated for IBSS vs. AP, and DCF vs. PCF? Suggestion: Add to General requirements 1.6 All requirements listed in this document are to be met by ad-hoc BSSs and infrastructure BSSs, during DCF as well as PCF operation, unless specifically indicated otherwise in the requirement. McFarland, Atheros Communications

Issues with Requirements Items 2.x January 2001 Issues with Requirements Items 2.x 2.2.1 A Protocol mechanism shall be defined to allow an Access Point, or members of and IBSS to communicate a per-BSS transmit power level for use by all members of the BSS 2.2.1 presumes support of a specific solution for TPC (uniform reduced Tx power for a BSS). Some solutions (such as open loop power control) might work without supporting this requirement Suggest changing 2.2.1 to: 2.2.1 Protocol mechanisms shall be defined to allow transmit power control to be implemented that meets the requirements in this document. McFarland, Atheros Communications

Issues with Requirements Items 2.x January 2001 Issues with Requirements Items 2.x 2.3.1.1 Define a new management information element to indicate BSS transmit power level. Modify the definition of Beacon and Probe Response Management Frames to include the BSS transmit power level information element. 2.3.1.2 Define a mechanism to allow transmit power information to be communicated in PCF data frames. Similarly 2.3.1.1 and 2.3.1.2 seem to assume particular methods. In the context of a requirements document should these be changed to simply indicate that all required frame definitions and MAC protocol elements be provided? McFarland, Atheros Communications

Issues with Requirements Items 2.x January 2001 Issues with Requirements Items 2.x Suggested change: Merge 2.3.1.1 and 2.3.1.2 into: 2.3.1 Define new information elements within existing frames, and new management frames as required to support transmit power control. McFarland, Atheros Communications

Issues with Requirements Items 3.x January 2001 Issues with Requirements Items 3.x In general, when definition of mechanisms is required, does this indicate that the mechanisms must be implemented in all devices? 3.2.3 Mechanisms shall be defined to allow an AP to request an STA to report the state of a given channel 3.2.3 Is this really necessary? Might a solution in which the STAs do this independently be acceptable? How does this work in an ad-hoc BSS? McFarland, Atheros Communications

Issues with Requirements Items 3.x January 2001 Issues with Requirements Items 3.x Suggested modification to 3.2.3: 3.2.3 Mechanisms shall be defined to insure sufficient channel state assessment and communication of channel state such that a decision to change channels can be made. McFarland, Atheros Communications

Issues with Requirements Items 3.x January 2001 Issues with Requirements Items 3.x 3.2.5 Mechanisms shall be defined to allow an STA to measure the state of any specified channel while associated without loss of unicast data 3.2.5 How is loss of unicast data defined? If it just doesn’t ACK is that considered lost? Does this requirement hold for IBSS as well as AP based operation? Suggested clarification? McFarland, Atheros Communications

Issues with Requirements Items 3.x January 2001 Issues with Requirements Items 3.x 3.3.2.1 Define constraints for new channel selection algorithm 3.3.2.1 make clear that the constraints for the new channel selection algorithm will insure all requirements are met, and that the STABILITY of the network is guaranteed. Suggested change: 3.3.2.1 Define constraints for new channel selection algorithm that insure all requirements are met, and guarantee stable operation McFarland, Atheros Communications

Issues with Requirements Items 3.x January 2001 Issues with Requirements Items 3.x 3.4.1 Add channels in the 5470-5725 bands 3.4.1 should these be constrained to the channel centers already defined for Hiperlan2? Suggested change: 3.4.1 Add channels in the 5470-5725 bands with channel centers that match those set forth in ETSI EN 020002-2 “Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive” McFarland, Atheros Communications

Modifications to the Comparison Criteria document (00/421) January 2001 Modifications to the Comparison Criteria document (00/421) McFarland, Atheros Communications

Suggested Additions to Criteria Document January 2001 Suggested Additions to Criteria Document Robustness: Stability High latency High gain (move or don’t) Interacting loops (TPC and DFS) Error recovery Robustness to measurement errors Coexistence with legacy 802.11a and Hiperlan2 devices Resistance to nefarious attacks or attempts to hog bandwidth Proper behavior in mixed IBSS & AP environments McFarland, Atheros Communications

Suggested Additions to Criteria Document January 2001 Suggested Additions to Criteria Document Benefits beyond meeting regulatory requirements Potential power dissipation savings due to TPC Capacity improvements in environments in which the BSSs are “coordinated” (manually or automatically) Potential operational improvements in uncoordinated environments (e.g. with non TGh BSSs) I recommend we decide beforehand how much emphasis we will place on enhance performance, and how we will compare the performance of various schemes McFarland, Atheros Communications

Suggested Additions to Criteria Document January 2001 Suggested Additions to Criteria Document Effect (if any) on other MAC functionality Power saving Probing and Association Roaming and handoff Security QoS McFarland, Atheros Communications

January 2001 To Simulate or Not Difficulty of defining a set of simulations that spans the huge range of potential scenarios Need to model interference that is not well understood, at least by us, such as radar Anytime simulations are required the time to reach conclusion is much longer Some simulation may be required anyway to insure stability and reasonable operation Options: No simulations required Proposers define the simulations they believe are appropriate TGh defines a set of simulations that are required McFarland, Atheros Communications