Re: [RFC] [PATCH 2/3] adds ieee80211_regdomains support
On 10/24/06, Anand Kumria [EMAIL PROTECTED] wrote:
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
ieee80211_regdomains
Breaks down regulatory domains into data structures which allow
drivers to share channel and power contraints based on stack
regulatory domain. This driver adds in-kernel support for common
regulatory domains (such as FCC and ETSI), makes updating the
[snip]
+/* Stack regulatory domain values. Atheros seems to have started this
+ * convention and most hardware vendors followed their example.
+ * Although these are *very* common we allow for a hw-specific
+ * map between stack and device regdomain values. */
+enum stack_regdomain {
+ REGDOMAIN_WORLD = 0x00, /* World compliance, minimum set */
+ REGDOMAIN_FCC = 0x10, /* USA */
+ REGDOMAIN_IC= 0x20, /* Canada */
+ REGDOMAIN_ETSI = 0x30, /* Europe */
+ REGDOMAIN_SPAIN = 0x31, /* Spain */
+ REGDOMAIN_FRANCE= 0x32, /* France */
+ REGDOMAIN_MKK = 0x40, /* Japan */
+};
+
Why not pick either the country name or the organisation within the country
that determines the frequency guidelines?
Ultimately I think this is the way this should work and this is why I
provide a alpha3 country code -- stack regulatory domain map.
Userpace should just let the user pick the country at say,
distribution install time, and the map then used to determine the
regulatory domain. Regulatory domains are what dictate the subband
restrictions and as such these are ultimately what we need in the
stack to decide what goes and what doesn't.
Luis
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/3] adds ieee80211_regdomains support
and adds support for PtMP (Point to MultiPoint) and PtP (Point to Point) type restrictions. What are those restrictions? Similar comments here, why do you build the list at module init time instead of having it static? Also, do we really need all this data in the kernel? johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/3] adds ieee80211_regdomains support
On 10/24/06, Johannes Berg [EMAIL PROTECTED] wrote: and adds support for PtMP (Point to MultiPoint) and PtP (Point to Point) type restrictions. What are those restrictions? I'm glad you asked. Here's a quote from: http://university.cyberarmy.net/kb/tiki-index.php?page=The+Power+of+802.11 In the 2.4Ghz ISM band the FCC stipulates that the creation of PtMP links be subject to the following restrictions: * EIRP must not exceed 4W (36dBm) * IR must not exceed 1W (30dBm) * For every 3dBi of antenna gain after the first 6 free dBi the IR must be decreased by 3dBi (the 1:1 rule) For PtP links that rule is thusly augmented: * IR is limited to 1W (30dBm) * For every 3dBi after the first 6 of antenna gain the IR must be decreased by 1dBi (the 3:1 rule) One thing to notice about the rules for the PtP link is that it does not stipulate a maximum EIRP and significantly reduces the penalty for adding antenna gain. In this situation it would be acceptable to have an IR of 25dBm and with a directional antenna adding 21dBm of gain giving us an EIRP of 46dBm or 40W. This is why it is very important to stay away from the front of highly directional antennae. If you have ever wondered what it would be like to squeeze yourself into a microwave and have it turned on... The restrictions defined in this regulatory module are designed first to tackle PtMP links restrictions but keeps in mind PtP link subband restrictions as well for further advancements. This would ultimately complete regulatory domain support. To support PtP links well though we'd need some further stack enhancements and modifications. Currently I separate PtP and PtMP link restrictions by putting them on separate subband linked list on the regulatory domain. Antenna gain is device specific and for manufacturer's sake and user's hacker's sake we should allow for: 1. Device specific definition of the manufacturer's default antenna gain and... 2. Allow the user to modify this antenna gain in case they modify the antenna. Our due dillegence comes from at least providing built-in regulatory framework and allowing the malleability of the malleable components of such restrictions. If antenna gain is modified we should accordingly modify the device's IR -- notice this requires changes even for PtMP link restrictions as well but support without this was what I was thinking for Phase I of this module. (1) is covered under d80211.h on the ieee80211_conf struct, u8 antenna_max but this is a subband restriction not an entire device restriction. If we want to add this support immediately we can add IR to the subband definition. (2) needs further enhancements on the stack, namely that making IR dynamic based on the device's antenna gain. All this requires a lot of changes. What I'd suggest first is to adopt PtMP link restrictions without supporting dynamic IRs based on antenna gains until Phase II. In Phase II I was hoping we'd tackle this and a userspace daemon through nl80211/cfg80211. d80211 is due to go stable, I was hoping regulatory domains under phase I would be one last addition to it before going stable and Phase II can be the focus for a v2 of a stable d80211. Similar comments here, why do you build the list at module init time instead of having it static? It made the code cleaner, feel free to modify if there are benefits through a static approach. I originally attempted a static array approach here but ran into problems quickly due to the dynamic nature of the data structures required for regulatory domains and was having a headache dealing with all the nasty macros to build this statically. I'd suggest we keep things as is unless we have a complete clear understanding of all requirements of regulatory domains. Regulatory domains are not really well documented and this perhaps is the best break down of them that I've seen so far. Also, do we really need all this data in the kernel? Another great question. At first I actually wanted all this in userspace but after some consideration figured it'd be best to introduce in the kernel instead. Here are some considerations made me change my mindl: 1. Regulatory restrictions affects the PHY's behaviour directly 2. IEEE-802.11D is a standard which all wireless stacks should hopefully and eventually support. It is based on regulatory domains which dictate how the PHY should work. 3. I believe the benefit in speed of having the regulatory restrictions in the kernel outweight the overhead of having this in the kernel 4. Introduction of a userspace daemon to update all regulatory domains seems like a heavy restriction to immediately force every distribution on. Also there is simply no clear World regulatory domain that everyone can live peacefully with. An easier way to introduce regulatory domains would be to have the most popular regulatory domains built-in and slowly support userspace communication to update and manage the regulatory db. So, ultimately userspace should be the
Re: [RFC] [PATCH 2/3] adds ieee80211_regdomains support
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
ieee80211_regdomains
Breaks down regulatory domains into data structures which allow
drivers to share channel and power contraints based on stack
regulatory domain. This driver adds in-kernel support for common
regulatory domains (such as FCC and ETSI), makes updating the
[snip]
+/* Stack regulatory domain values. Atheros seems to have started this
+ * convention and most hardware vendors followed their example.
+ * Although these are *very* common we allow for a hw-specific
+ * map between stack and device regdomain values. */
+enum stack_regdomain {
+ REGDOMAIN_WORLD = 0x00, /* World compliance, minimum set */
+ REGDOMAIN_FCC = 0x10, /* USA */
+ REGDOMAIN_IC= 0x20, /* Canada */
+ REGDOMAIN_ETSI = 0x30, /* Europe */
+ REGDOMAIN_SPAIN = 0x31, /* Spain */
+ REGDOMAIN_FRANCE= 0x32, /* France */
+ REGDOMAIN_MKK = 0x40, /* Japan */
+};
+
Why not pick either the country name or the organisation within the country
that determines the frequency guidelines?
Regards,
Anand
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
