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

Re: [STDS-802-11-REG] 13/444r1 FCC 13-49 comments posted on Mentor



Hi Jeff,

 

On your first point, the intent in the NPRM is not to have database as a supplementary optional method only. It is considered as a “mandatory” method even if it is supplemental.

We also seek comment on whether

requiring the implementation of both DFS and geo-location interference protection mechanisms would be

overly burdensome for equipment manufacturers and whether it is necessary to require both

 

we request comment on whether a geo-location/database requirement should apply only to those devices

or to lower power indoor U-NII devices as well

 

 

Tevfik

 

From: *** Regulatory and Spectrum Allocation Topics *** [mailto:STDS-802-11-REG@xxxxxxxx] On Behalf Of Jens Tingleff
Sent: Tuesday, May 14, 2013 6:44 AM
To: STDS-802-11-REG@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-REG] 13/444r1 FCC 13-49 comments posted on Mentor

 

Eldad, Andrew, all

 

I support Andrew’s point. Not only that, but low power could easily mean too low power to be interesting commercially.

 

Additionally, I do not understand the first part (IV, A, 3) where the authors first acknowledge that the FCC is requesting comments on geolocation database access control as a supplementary mechanism and then states that the authors do not want mandatory database access control.  Three points: firstly, objecting to mandatory database control when the question is on database control as a supplement strikes me as odd. Secondly, geolocation database access control is not a big problem when we’re doing it in TGaf (where, indeed, we’re taking regulatory things out and assuming that they go in “upper layers”- i.e. outside the scope of 802.11). Lastly, some of the objections to database access control are outside the scope of 802.11 (i.e. not only is the objection that we don’t like it, we’re also confidently stating that others would not like it, re the comments regarding complexity/cost of providing a database and the information in it).

 

Recommendation:

 

1)      go with “study of” a low power option.

2)      Soften the language objecting to geolocation database access control. Acknowledge that the technology exists (indeed that 802.11TGaf is nearing completion of its work on this) and that it could be, as the FCC suggests, a supplementary mechanism but not the only one.

 

Best Regards

 

                Jens

 

 

From: *** Regulatory and Spectrum Allocation Topics *** [mailto:STDS-802-11-REG@xxxxxxxx] On Behalf Of Perahia, Eldad
Sent: 14 May 2013 10:49
To: STDS-802-11-REG@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-REG] 13/444r1 FCC 13-49 comments posted on Mentor

 

Hi Andrew,

 

I believe that enabling a simpler implementation of peer-to-peer technology in DFS bands will open up exciting new applications for the Wi-Fi industry, so I disagree with your sentiment of “this is a big mistake”.  However I do agree that a sharing study is necessary and it is reasonable for our NPRM comments to say so.  I propose we adopt the changes that were discussed in the RegSC this evening, as given below.

 

P40 “In addition, we recommend studying the option for a low power mode on DFS channels, meaning, devices that do not support DFS, will be able to operate on DFS channels, with power limitation.  ”

P41 “For that reason, IEEE 802.11 recommends studying a low power mode exemption for DFS.”

 

Regards,

Eldad

 

From: *** Regulatory and Spectrum Allocation Topics *** [mailto:STDS-802-11-REG@xxxxxxxx] On Behalf Of Andrew Myles (amyles)
Sent: Tuesday, May 14, 2013 12:01 AM
To: STDS-802-11-REG@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-REG] 13/444r1 FCC 13-49 comments posted on Mentor

 

I would like to make a comment on  the recommendations in 444 to add a new low power option, allowing soft APs and Wi-Fi Direct devices to operate without supporting DFS if they use low power. I personally believe this is a big mistake. The last thing we should be doing is inflicting a large number of unmanaged rogue APs on the 5GHz band.

 

However, I understand that some members are fans of the possibility of allowing soft APs and Wi-Fi Direct in the 5GHz band. I will not argue against that view because it is not a black and white argument. That said the current recommendations in document are not justified by the document.  Nowhere in the document does it explain how soft APs can operate at low power without DFS without causing interference to radar stakeholders

 

Indeed the current ruling from the FCC (2uW/MHz) suggests that there is no power at which devices could operate without DFS and still satisfy the use cases in Attachment 1. We have not included any evidence to the contrary in this document, and is inappropriate to make a recommendation to allow low power operation without DFS. It is actually disrespectful to the goals of the radar stakeholders.

 

Recommendation 1

 

On pp40, delete,

 

In addition, we recommend adding the option for a low power mode on DFS channels, meaning, devices that do not support DFS, will be able to operate on DFS channels, with power limitation

 

I want to delete it here because there is no need to say the same thing twice (without justification in either case). The issue can better be handled once on pp41.

 

Recommendation 2

 

On pp41, change:

 

For that reason, IEEE 802.11 is recommending a low power mode exemption to DFS

 

To

 

For that reason, IEEE 802.11 is recommending a new study to determine if it is possible to operate low power APs without DFS, while both protecting the radar users and providing sufficiently high power to enable the use cases in Attachment 1. This study should occur as soon as possible but it completion should not stop the implementations of the other recommendations of this response from IEEE 802

 

This better expresses our desires, which are low power operation without DFS if it is possible without unreasonably affecting the interests of other stakeholders

 

Andrew

_______________________________________________________________________________

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

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-REG and then press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

_______________________________________________________________________________

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

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-REG and then press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

_______________________________________________________________________________

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

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-REG and then press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

_______________________________________________________________________________

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

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-REG and then press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________