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

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

3. 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 , 1W EIRP in (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

4. 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 a’s
McFarland, Atheros Communications

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

6. 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 “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 and for consistency
McFarland, Atheros Communications

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

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

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

10. Issues with Requirements Items 2.x
January 2001
Issues with Requirements Items 2.x
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.
Define a mechanism to allow transmit power information to be communicated in PCF data frames.
Similarly and 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

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

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

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

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

15. Issues with Requirements Items 3.x
January 2001
Issues with Requirements Items 3.x
Define constraints for new channel selection algorithm
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:
Define constraints for new channel selection algorithm that insure all requirements are met, and guarantee stable operation
McFarland, Atheros Communications

16. Issues with Requirements Items 3.x
January 2001
Issues with Requirements Items 3.x
3.4.1 Add channels in the 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 bands with channel centers that match those set forth in ETSI EN “Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive”
McFarland, Atheros Communications

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

18. 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 a and Hiperlan2 devices
Resistance to nefarious attacks or attempts to hog bandwidth
Proper behavior in mixed IBSS & AP environments
McFarland, Atheros Communications

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

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

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