Hi Luis,
Thanks for the review. Will need some more time to look at your suggestions below :)
Regards,
Ilan.
>
> On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@xxxxxxxxx> wrote:
> > From: David Spinadel <david.spinadel@xxxxxxxxx>
> >
> > The FCC are clarifying some soft configuration requirements, which
> > among other includes the following:
> >
> > 1. Concurrent GO operation, where devices may support WFD in
> > bands where an authorized master (for example with DFS and
> > DFS and radar detection capability in the UNII band) is operating.
>
> 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.
> 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).
> 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.
>
> Note that we have already these on regdb.h from CRDA:
>
>
> /*
> * The Linux map defined in <linux/uapi/nl80211.h> enum
> nl80211_reg_rule_flags */ enum reg_rule_flags {
> RRF_NO_OFDM = 1<<0, /* OFDM modulation not allowed */
> RRF_NO_CCK = 1<<1, /* CCK modulation not allowed */
> RRF_NO_INDOOR = 1<<2, /* indoor operation not allowed */
> RRF_NO_OUTDOOR = 1<<3, /* outdoor operation not allowed */
> RRF_DFS = 1<<4, /* DFS support is required to be
> * used */
> RRF_PTP_ONLY = 1<<5, /* this is only for Point To Point
> * links */
> RRF_PTMP_ONLY = 1<<6, /* this is only for Point To Multi
> * Point links */
> RRF_PASSIVE_SCAN = 1<<7, /* passive scan is required */
> RRF_NO_IBSS = 1<<8, /* IBSS is not allowed */
> };
>
> Historically we don't distinguish then a type of 802.11 device that initiates
> radiation except for the NO_IBSS rule, but that rule can be treated more as
> legacy given that the intent and motivation behind that was that some ODMs
> simply preferred an interpretation of regulatory rules and we *currently* don't
> use that in much places other than custom regulatory domains defined in the
> kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could
> potentially have been used but to this day we haven't found a use case for it
> given that typical 802.11 devices are PTMP.
>
> I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if
> we can figure out a way to make this more generic. At this point for example I
> think a more appropriate flag is in place:
>
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 ...)
> * NO_IR - cannot initiate radiation
>
> And this could in turn end up replacing most use cases of NO_IBSS and
> PASSIVE_SCAN givne that both of these imply we cannot initiate radiation
> unless specific things are done. I wonder if we can fold the GO flag into this and
> perhaps rename the NO_IBSS flag to the GO one.
>
> Also note that we should keep the flags in sync with the uapi nl80211 change.
> Please review these suggestions and let me know what you think.
>
Sure. Will need to take a deeper look at this.
> > 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.
>
> > - 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?
Yes. We have plans to incorporate more logic to hostap (currently into wpa_supplicant for P2P use cases).
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
