Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy wrote: > Dear Luis; > Thank you for the introduction in the wireless-regdb mailing-list. > > On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: >> Rostislav, can you provide documentation references which would >> clarify >> the stance on 802.11p and restrictions for only allowing OCB mode? > > If I may cite the 802.11-2012 standard: > -- 1st Quote > 4.3.11 STA transmission of data frames outside the context of a BSS > > Communication of data frames when dot11OCBActivated is true might take > place in a frequency band that is dedicated for its use, and such a band > might require licensing depending on the regulatory domain. A STA for > which dot11OCBActivated is true initially transmits and receives on a > channel known in advance, either through regulatory designation or some > other out-of-band communication. > -- End of quote OK the spec does not rule out communication on that special band for regular operation as such that special band is mentioned in the context of OCB communication, but it does say that the frequency range may be licensed. As it stands the public wireless-regdb only covers unlicensed frequency ranges, but it obviously can support licensed frequency ranges, just that the distribution mechanism and integration of the wireless-regdb files then would have to be done separately through separate distributors -- ie, not upstream. If the OCB bands are unlicensed then we can surely add them to wireless-regdb, however it remains unclear if those bands are unlicensed if we can use them for regular non OCB communication. Follow this logic to move forward then: * Poke folks to see if the US band for OCB is licensed or unlicensed * Poke folks to see if the EU band for OCB is licensed or unlicensed * If the bands are licensed then the wireless-regdb changes that would be needed imply that a wireless-regdb needs to be provided to whatever customer by whomever is licensing that entity for usage of that band, that is, we upstream can be removed from the equation of the distribution. The upstream kernel however would require a flag for frequency ranges for OCB frequency ranges. Although the regulatory classes specify a few for the US and EU, this can likely change. I forget if the regulatory class can be interpreted through IEs, if so and if the specification is going to remain static I can envision the ability to hard code the OCB frequency ranges upstream but you'd then need to parse these things. * If the bands are *not licensed* there is one corner case that I still think should be reviewed by regulatory folks: having an OCB frequency range unlicensed under the current reading of the specification of 802.11-2012 means that 802.11 devices *can* use them for OCB, however if OCB is not enabled on the device it seems to be that OCB bands can be used for non OCB communication. Furthermore 4.3.11 seems to be saying that it is only optional to use a dedicated frequency for OCB, OCB can happen on other frequency ranges. > -- 2nd Quote > Annex E (normative) Country elements and operating classes > E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) > ... > STAs shall have dot11OCBActivated set to true. So all STAs in the US wil have OCB activated? I fail to understand how Annex E should be read in the context of operating classes. > E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) > STAs shall have dot11OCBActivated set to true. Ditto. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy lis...@gmail.com wrote: Dear Luis; Thank you for the introduction in the wireless-regdb mailing-list. On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: Rostislav, can you provide documentation references which would clarify the stance on 802.11p and restrictions for only allowing OCB mode? If I may cite the 802.11-2012 standard: -- 1st Quote 4.3.11 STA transmission of data frames outside the context of a BSS Communication of data frames when dot11OCBActivated is true might take place in a frequency band that is dedicated for its use, and such a band might require licensing depending on the regulatory domain. A STA for which dot11OCBActivated is true initially transmits and receives on a channel known in advance, either through regulatory designation or some other out-of-band communication. -- End of quote OK the spec does not rule out communication on that special band for regular operation as such that special band is mentioned in the context of OCB communication, but it does say that the frequency range may be licensed. As it stands the public wireless-regdb only covers unlicensed frequency ranges, but it obviously can support licensed frequency ranges, just that the distribution mechanism and integration of the wireless-regdb files then would have to be done separately through separate distributors -- ie, not upstream. If the OCB bands are unlicensed then we can surely add them to wireless-regdb, however it remains unclear if those bands are unlicensed if we can use them for regular non OCB communication. Follow this logic to move forward then: * Poke folks to see if the US band for OCB is licensed or unlicensed * Poke folks to see if the EU band for OCB is licensed or unlicensed * If the bands are licensed then the wireless-regdb changes that would be needed imply that a wireless-regdb needs to be provided to whatever customer by whomever is licensing that entity for usage of that band, that is, we upstream can be removed from the equation of the distribution. The upstream kernel however would require a flag for frequency ranges for OCB frequency ranges. Although the regulatory classes specify a few for the US and EU, this can likely change. I forget if the regulatory class can be interpreted through IEs, if so and if the specification is going to remain static I can envision the ability to hard code the OCB frequency ranges upstream but you'd then need to parse these things. * If the bands are *not licensed* there is one corner case that I still think should be reviewed by regulatory folks: having an OCB frequency range unlicensed under the current reading of the specification of 802.11-2012 means that 802.11 devices *can* use them for OCB, however if OCB is not enabled on the device it seems to be that OCB bands can be used for non OCB communication. Furthermore 4.3.11 seems to be saying that it is only optional to use a dedicated frequency for OCB, OCB can happen on other frequency ranges. -- 2nd Quote Annex E (normative) Country elements and operating classes E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) ... STAs shall have dot11OCBActivated set to true. So all STAs in the US wil have OCB activated? I fail to understand how Annex E should be read in the context of operating classes. E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) STAs shall have dot11OCBActivated set to true. Ditto. Luis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
Dear Luis; Thank you for the introduction in the wireless-regdb mailing-list. On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: > Rostislav, can you provide documentation references which would > clarify > the stance on 802.11p and restrictions for only allowing OCB mode? If I may cite the 802.11-2012 standard: -- 1st Quote 4.3.11 STA transmission of data frames outside the context of a BSS Communication of data frames when dot11OCBActivated is true might take place in a frequency band that is dedicated for its use, and such a band might require licensing depending on the regulatory domain. A STA for which dot11OCBActivated is true initially transmits and receives on a channel known in advance, either through regulatory designation or some other out-of-band communication. -- End of quote -- 2nd Quote Annex E (normative) Country elements and operating classes E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) ... STAs shall have dot11OCBActivated set to true. E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) STAs shall have dot11OCBActivated set to true. -- end of quote Regards; Rostislav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
Dear Luis; Thank you for the introduction in the wireless-regdb mailing-list. On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: Rostislav, can you provide documentation references which would clarify the stance on 802.11p and restrictions for only allowing OCB mode? If I may cite the 802.11-2012 standard: -- 1st Quote 4.3.11 STA transmission of data frames outside the context of a BSS Communication of data frames when dot11OCBActivated is true might take place in a frequency band that is dedicated for its use, and such a band might require licensing depending on the regulatory domain. A STA for which dot11OCBActivated is true initially transmits and receives on a channel known in advance, either through regulatory designation or some other out-of-band communication. -- End of quote -- 2nd Quote Annex E (normative) Country elements and operating classes E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) ... STAs shall have dot11OCBActivated set to true. E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) STAs shall have dot11OCBActivated set to true. -- end of quote Regards; Rostislav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Tue, Jun 03, 2014 at 10:01:33PM +0200, Johannes Berg wrote: > On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: > > IEEE 802.11p operates in its own 5.9GHz band. When there will > > be a record for the 5.9GHz band in the regulatory daemon, > > it must be limited to the OCB mode only -- using the newly > > added flags. > > Is this really a *regulatory* limitation? Rather than a limitation > elsewhere, e.g. the spec? Our engaged and capable *real* regulatory folks in the community are: * Liraz Perelmooter * Michael Green Additionally we have the wireless-regdb mailing list [0] which we should Cc for inquiries and verification on things like this. We hope for their participation as they are our real experts who grind away at the specs. Rostislav, can you provide documentation references which would clarify the stance on 802.11p and restrictions for only allowing OCB mode? Also your patches seem to refer to the 802.11p ammendment work to 802.11, but it is now merged as of IEEE 802.11-2012 as per Jouni's last update to us on the standards work [1]. As per Jouni's slides 802.11p-2010 made it as an ammendment into 802.11-2012 and this work is rerrred to as "Wireless Access for the Vehicular Environent". It would be *useful* if you'd refer to the IEEE 802.11-2012 standard then and document as part of your patches the exact sections and references that about Wireless Access for the Vehicular Environment. For reference to others this comes in as a full patch series by Rostislav to add some form of "802.11p" support using OCB (Outside the Context of BSS) mode. This mode of operation allows devices to send frames not connected to a BSS. The patch in question above is for the regulatory flag that is being proposed to be added, the full series of the other patches can be seen on the mailing list archive [2]. Rostislav clarifies that when OCB mode is used all the STAs communicate with each other without the need for a coordinator. The 5.9 GHz band is being clarified to be used for 802.11p, the patch series also is specifying that when 5.9 GHz is enabled only OCB mode of operation is allowed on that band. No references are made to the specific 802.11 ammendment / IEEE 802.11 sections or more importantly it is not being made clear if the OCB mode is something that differs depending on regulatory bodies at this point. Since 802.11p was designed for cars in mind I suspect regulatory bodies likely do want proper rules followed, but its unclear what countries that follow either IEEE 802.11 or the ISO equivalent want OCB mode of operation and if they also have the same restrictions of only allowing 5.9 GHz operation only for OCB. I can also imagine for example of regulatory bodies that may want to allow 5.9 GHz for non OCB mode, specially if they need the spectrum. One particular use case which provides a compromise could be for example to have APs/P2P GOs look for OCB communication and if its detected to disallow it. Not like I would recommend this given that it would then introduce crazy regulatory compliance silliness such as seen with DFS and that pushed crazy implementation and designs, but -- its certainly possible. So is this an IEEE compliance thing or regulatory thing? If its a generally accepted IEEE compliance thing for 802.11-2012 then I don't see why we don't just hard code this restriction on cfg80211 for the band. That after all would be the much more saner thing to do than all the silly mess of discrepencies betwen regulatory bodies. After all cfg80211 is for 802.11, and if we follow the specs and if its mentioned clearly there I see no resason why not to hard code this. If folks want to override this (I envision university environments doing research on this) the patch can add a Kconfig option that depends on CONFIG_CFG80211_CERTIFICATION_ONUS which will make the check permissive on 5.9 GHz instead of fully enforced. [0] http://lists.infradead.org/mailman/listinfo/wireless-regdb [1] http://wireless.kernel.org/en/developers/Summits/Barcelona-2012?action=AttachFile=view=ieee80211-barcelona-2012.pdf [2] http://comments.gmane.org/gmane.linux.kernel.wireless.general/121022 Luis pgpLsPrwepIgr.pgp Description: PGP signature
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: > IEEE 802.11p operates in its own 5.9GHz band. When there will > be a record for the 5.9GHz band in the regulatory daemon, > it must be limited to the OCB mode only -- using the newly > added flags. Is this really a *regulatory* limitation? Rather than a limitation elsewhere, e.g. the spec? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: IEEE 802.11p operates in its own 5.9GHz band. When there will be a record for the 5.9GHz band in the regulatory daemon, it must be limited to the OCB mode only -- using the newly added flags. Is this really a *regulatory* limitation? Rather than a limitation elsewhere, e.g. the spec? johannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
On Tue, Jun 03, 2014 at 10:01:33PM +0200, Johannes Berg wrote: On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: IEEE 802.11p operates in its own 5.9GHz band. When there will be a record for the 5.9GHz band in the regulatory daemon, it must be limited to the OCB mode only -- using the newly added flags. Is this really a *regulatory* limitation? Rather than a limitation elsewhere, e.g. the spec? Our engaged and capable *real* regulatory folks in the community are: * Liraz Perelmooter liraz.perelmoo...@intel.com * Michael Green gr...@qti.qualcomm.com Additionally we have the wireless-regdb mailing list [0] which we should Cc for inquiries and verification on things like this. We hope for their participation as they are our real experts who grind away at the specs. Rostislav, can you provide documentation references which would clarify the stance on 802.11p and restrictions for only allowing OCB mode? Also your patches seem to refer to the 802.11p ammendment work to 802.11, but it is now merged as of IEEE 802.11-2012 as per Jouni's last update to us on the standards work [1]. As per Jouni's slides 802.11p-2010 made it as an ammendment into 802.11-2012 and this work is rerrred to as Wireless Access for the Vehicular Environent. It would be *useful* if you'd refer to the IEEE 802.11-2012 standard then and document as part of your patches the exact sections and references that about Wireless Access for the Vehicular Environment. For reference to others this comes in as a full patch series by Rostislav to add some form of 802.11p support using OCB (Outside the Context of BSS) mode. This mode of operation allows devices to send frames not connected to a BSS. The patch in question above is for the regulatory flag that is being proposed to be added, the full series of the other patches can be seen on the mailing list archive [2]. Rostislav clarifies that when OCB mode is used all the STAs communicate with each other without the need for a coordinator. The 5.9 GHz band is being clarified to be used for 802.11p, the patch series also is specifying that when 5.9 GHz is enabled only OCB mode of operation is allowed on that band. No references are made to the specific 802.11 ammendment / IEEE 802.11 sections or more importantly it is not being made clear if the OCB mode is something that differs depending on regulatory bodies at this point. Since 802.11p was designed for cars in mind I suspect regulatory bodies likely do want proper rules followed, but its unclear what countries that follow either IEEE 802.11 or the ISO equivalent want OCB mode of operation and if they also have the same restrictions of only allowing 5.9 GHz operation only for OCB. I can also imagine for example of regulatory bodies that may want to allow 5.9 GHz for non OCB mode, specially if they need the spectrum. One particular use case which provides a compromise could be for example to have APs/P2P GOs look for OCB communication and if its detected to disallow it. Not like I would recommend this given that it would then introduce crazy regulatory compliance silliness such as seen with DFS and that pushed crazy implementation and designs, but -- its certainly possible. So is this an IEEE compliance thing or regulatory thing? If its a generally accepted IEEE compliance thing for 802.11-2012 then I don't see why we don't just hard code this restriction on cfg80211 for the band. That after all would be the much more saner thing to do than all the silly mess of discrepencies betwen regulatory bodies. After all cfg80211 is for 802.11, and if we follow the specs and if its mentioned clearly there I see no resason why not to hard code this. If folks want to override this (I envision university environments doing research on this) the patch can add a Kconfig option that depends on CONFIG_CFG80211_CERTIFICATION_ONUS which will make the check permissive on 5.9 GHz instead of fully enforced. [0] http://lists.infradead.org/mailman/listinfo/wireless-regdb [1] http://wireless.kernel.org/en/developers/Summits/Barcelona-2012?action=AttachFiledo=viewtarget=ieee80211-barcelona-2012.pdf [2] http://comments.gmane.org/gmane.linux.kernel.wireless.general/121022 Luis pgpLsPrwepIgr.pgp Description: PGP signature
