[STDS-802-11-REG] Notes from May 14 PM2 and revised May 13 PM3 document

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

802.11 REG SC May 14, 2013

• Assign a recording secretary

• Administrative items

– Required notices

• Introduction

• Approve meeting and teleconference minutes

• The regulatory summaries

• Action items and issues

• The NPRM FCC 13-22 response

• Coexistence with ITS / DSRC

• Adjourn

Chair called the meeting to order at 16:03 HST

• Peter Ecclesine (Cisco Systems) is appointed recording secretary

• 11-13/456r0 is agenda for this session

• Agenda approved unanimously

• Chair read administrative items (slides 4-6)

Email from Ed Reuss "The IEEE 802.11 Working Group recommends". All agree to Ed Reuss change

Email from Tevfik Yucek

I would like to have the following paragraph added to Page 41 of 13-444 just before “B. UNII-1 Proposed revisions” section.

With some changes to the original text:

Furthermore, IEEE 802.11 working group is asking to clarify that FCC allows in the rules the following behavior by a Master device: A Master is allowed to perform the channel availability check on multiple channels during device power up per existing Part 15 test methods to ensure that no radar is operating. In this way a list of “available channels” may be formed and retained by the Master as long as it is powered up, and those channels are subject to the Channel Closing Transmission Time

limit. The Master would be allowed to immediately commence operation on any available channel during operation and immediately commence in-service-monitoring. No new CAC would be required immediately before commencing operation on an available channel or switching to another channel in the list of “available channels”. All other existing channel closing and non-occupancy rules remain in force. In summary, the Master can operate in one or more of the “available channels” and change its operating channel, without repeating a new CAC before commencing operation on another available channel. This behavior is recognized in DFS conformance rules in other regions.

All agree with the changes as noted above.

Email from Vinko Erceg

stringent set of emissions characteristics – together with actions already taken to reduce the ability of users to configure systems, are sufficient to address the issues raised by the TDWR examples. Unlike a “greenfield” band such as TV white spaces, the 5 GHz band has been in use to varying degrees for two decades. Imposing any database, much less a database that fully interacts with devices in the field, significantly alters equipment design, ~~significantly~~ raises cost, increases complexity, raises questions about database maintenance, and introduces ~~tremendous~~ significant uncertainty to an industry that today is delivering a wireless broadband access platform that by some measures accounts for over half of all IP traffic in the United States.[1] This is a far different proposition than when a device ecosystem is new, and there are no consumer expectations in terms of quality and price points yet built around it. For example, implementing a database requires numerous issues to be solved - issues about who pays for it, the cost of implementing software in the master devices to talk to the database, who is responsible for ensuring the system works, which equipment should be subject to it, how the federal users will interact with it, particularly if their activities are not ones that they wish to share with third parties, and how to design a system that works when a consumer plugs in an access point. These are difficult issues that could take years to sort out, and if technical and certification rules have already addressed the interference cases, then solving for a database solution becomes a needless exercise.

All agree with the changes from Vinko as noted.

Email from Vijay Auluck

I propose to replace the following language on page 22 in 444r1:

From:

IEEE 802.11 agrees. If software or firmware is modified or reconfigured by someone other than the authorized manufacturer, the code should be written to cause device to disable or block out or notch the DFS bands.

To:

IEEE 802.11 agrees that manufacturers should ensure that reconfiguring firmware or software which affects regulatory compliance, by someone other than the manufacturer or authorized by the manufacturer, is made very difficult.

All agree with the change from Vijay as noted.

== received email from Dick Roy / John Kenney ==

"In the view of 802.11, protection of primary DSRC users is the new problem to be resolved in this proceeding. As the transportation industry has evolved its vision of ITS, the underlying DSRC technology has been evolving. The candidate DSRC technology is the 802.11p amendment which has been incorporated into IEEE 802.11-2012, a technology that is part of the 802.11 family and largely compatible therewith. The current membership of 802.11 includes many engineers from companies that participated in and supported the development of the 802.11p amendment as well as supporting developments in the other 802.11 working groups. Clearly, much of the industry is actively supporting both commercial 802.11 as well as DSRC technologies. While 802.11 appreciates that the FCC has created rules especially targeted to DSRC and its primary goal of providing for safety of life and property in the transportation sector, we strongly prefer a set of FCC rules that will allow both sets of technologies to coexist and to flourish. As the Notice states, DSRC is itself an evolving technology designed to improve safety in situations involving mobile elements of the transportation sector. In particular, the Notice states that V2V and V2I DSRC communications can save lives and that these implementations need secure, dependable wireless communications with low latency to perform their intended function. 802.11 appreciates and notes that DSRC transmitters onboard vehicles are licensed by rule, and are therefore primary, and that infrastructure transmissions are licensed by the FCC and also have primary status in the band. 802.11 understands the question posed by this proceeding to be whether mechanisms can be put in place that will allow U-NII devices to operate in spectrum shared with DSRC devices without causing harmful interference to DSRC operations.

Based on past experience in advising the FCC on sharing technologies, 802.11 is of the view that the cycle of written comments and reply comments will not resolve whether a sharing case exists, much less whether a particular sharing mechanism can be proven to work to the satisfaction of stakeholders.[1] Sharing is technically complex, and those designing sharing technologies need to deeply understand what is being asked of the technology.

It is important to note that the DSRC standards (IEEE 802.11 and IEEE 1609.x) were not designed with sharing of the DSRC band with commercial 802.11 products in mind. Nevertheless, there is some reason to think that a sharing concept can be created and tested. As noted previously, there are companies in the 802.11 community, including silicon vendors, who would like both technologies to succeed, and have interest in offering solutions for the implementation of DSRC in the automotive and personal device market. Because the two technologies are part of a common standards family, and DSRC technology is based on an amendment to the base IEEE 802.11 specification, both commercial 802.11 and DSRC have a common base. Since both are IEEE 802.11 based technologies, we believe that there is a way forward to address the concerns of the ITS community about potential interference to their system from commercial 802.11 devices.

802.11 therefore recommends that stakeholders from both the ITS community and the 802.11 community hold a series of meetings to exchange information on respective requirements, discuss possible mitigation solutions prepared by the technical experts from 802.11 and ITS communities, and come to an agreement on a mutually acceptable solution for testing/implementation. The follow-on step may involve development and testing of prototypes in a DRSC test bed to ensure the solution works not just in the lab, but in situ, and that it is acceptable for full implementation. If brought to fruition, then industry participants would need to work closely with FCC and other government agencies to update rules and procedures where appropriate, and to develop certification rules that unlicensed devices will use to gain FCC approval, including potentially additional tests to ensure the certification rules operate as intended. In summary, 802.11 recognizes its role in standardizing appropriate aspects of whatever solution is developed by all the stakeholders in the ITS community including 802.11 itself, and we recommend that the above outlined process be initiated at the earliest possible time."

== end of Dick Roy /John Kenney email ==

Rollup comments will be applied to create 444r2, with Dick Roy / John Kenney email inserted after the rollup comments on this section of 444

[1] See Cisco Visual Networking Index (June 2012), estimating that after 2016, the majority of all IP traffic will originate or terminate on Wi-Fi. www.cisco/go/vni

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.