| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, 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. Regards, From: *** Regulatory and Spectrum Allocation Topics *** [mailto:STDS-802-11-REG@xxxxxxxx]
On Behalf Of Yucek, Tevfik 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 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 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) 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 _______________________________________________________________________________
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 _______________________________________________________________________________ |