Hi Luis, Once again, thanks for the comments :) Regards, Ilan. > >> Is WFD WiFi Display? Is there any strict relationship here to WFD and > >> GO and regulatory or is WFD just a use case example? Are you > >> indicating that the FCC is making special rules for cases in specific > >> bands where GO *can* co-exist with other GO devices ? > > > > WFD is WiFi direct in this context. I do not think that the FCC are making > special rules only for GO specific scenarios but a more general approach where > "compliance may be achieved under the guidance of an authorized master". > The WFD/P2P GO case is only an example. > > OK then I think cullular base station regulatory hints might be another example. > In fact I believe I am looking at the information you might be using as > reference. I am looking at public draft edit for FCC KDB 594280: > > https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=5 > 28122 This is indeed the relevant document. > > The original KDB: > > http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigur > ationControl-RDJS.pdf > > Specifically in the above document, the draft edit, I am looking at page 12. That > actually references WiFi Direct precisely and considers the case that a GO may > need to move out of its channel if its master device its using to configure itself > also switches channels. Given that cellular base station hints could also > technically be used this also would need to be considered for cellular base > stations. But also note on page 14 it states clearly: > > "Mobile Country Codes (MCC) or Mobile Network Codes > (MNC) are not acceptable for programming host compliance" > > So it seems cellular base station hints are simply not allowed by the FCC (unless > specific approval is requested / revised). Even if the FCC allowed for it I believe > an API would need to be provided should cellular base stations have a case > where they may stop operating as well similar to DFS. > > BTW in future iterations of patches I'd appreciate if you can include the above > references to documentation given that we've pulled them up now. > Sure. > >> You annotate that this is somehow related to DFS, are the GO > >> concurrent rules that the FCC is defining only applicable to DFS > >> frequency ranges? If so would it suffice to only use DFS flag ? Or > >> are there other special cases beyond DFS frequency ranges that the FCC is > creating special handling? > >> > > > > DFS was given here as an example. Generally, I think that the changes that > the FCC are making are targeting various scenarios and various RF devices (for > example those defined in part 15 of CFR title 47). > > OK thanks. Things are clear now that I see the document that you might be > referring to. > > >> Apart from the FCC are you aware of special cases handling for other > >> regulatory bodies at this point? > > > > Not that I'm aware of. Adding some more people that might know more. > > Hey folks, anyone? :) > > > > > Actually, this should be a GO only flag, meaning that such relaxation > > should not be valid for soft AP, IBSS or mesh. The intention here is > > limit the extend of the cell, and prevent daisy chain scenarios > > (assume that you allow a soft AP on such a channel and that a client > > associated to it, and then that device can also start a soft AP on the > > channel ....). Anyway, I'll need to have another look at this (might > > be permissible for IBSS ...) > > Based on the documentation I reviewed and your proposal it'd seem to me that > we can distinguish GO on the upper layers and determine if a channel is DFS or > not by just the DFS flag. The next hint you'd need is if the GO got regulatory > information from a master somehow, no? This should also be handled by user space, based on the device type/sub type of the local device directly, or indirectly through other means such a managed interface associating with an AP that it's device type value is 6 etc. > That is I am not seeing a need for a new flag at this point in wireless-regdb, > given also I mentioned another type of case for regulatory hints technically > possible (cellular base station hints but it seems only allowed with exceptional > review by the FCC). > > I take it what you want to enable here is GO operation on DFS channels and use > country IEs to determine if you can use GO, but if you do have GO enabled then > you'd want hooks to not daisy chain, ack? Currently, we do not intend to base the relaxation on the country IE directly, but base it on the fact that if there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master), than the channel used by the managed connection is valid for use (as long as the managed interface is connected to the AP on the channel). > > >> > 2. Indoor operation, where in bands requiring indoor operation, the > >> > device must be programmed to detect indoor operation, or > >> > - Device must be connected to AC Power > >> > >> Does anyone know if the FCC considers "indoor" if we power a device > >> through the car on AC power through a converter ? Are we willing to > >> ignore that corner case? > > > > No. AC power means "mains" and not through portable DC converters (see > slide 12 in > https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= > 528122). It would be up to the user space to identify the device type etc. and > identify if this a truly AC powered AP. > > OK thanks for the clarification. I wonder if we can distinguish between the two > in userspace today. I'm happy to start pegging frequency ranges as indoor-only > on wireless-regdb even if we don't have the userspace APIs to annotate when a > device is indoor or not yet. Patches welcomed then. > Again, we are going to use the device type/sub type as an indication to an AP being AC powered. > >> > - Device must be under the control of a local master that is > >> > acting > >> > >> Interesting, so some APIs would be defined, I take it on hostapd to > >> do the proper callbacks to 'slave' type of devices that depend on the > >> local master(s). I could envision this being implemented on hostapd > >> by expanding the AP interface type and associating 'slave' devices > >> and callbacks for updates on AP device updates (channel changes, and so > on). Is this work being planned? > > Note sure that I follow ... However, we do intend to add this type of support to hostap. > > Yes. We have plans to incorporate more logic to hostap (currently into > wpa_supplicant for P2P use cases). > > Sweet. > > Luis ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
