en:developers:todo-list:regulatory
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
en:developers:todo-list:regulatory [2015/01/26 09:49] 127.0.0.1 external edit |
en:developers:todo-list:regulatory [2015/10/14 17:13] Johannes Berg |
||
|---|---|---|---|
| Line 12: | Line 12: | ||
| The following regulatory ideas are being implemented on the regulatory simulator. References to code where specific changes are being implemented on the regulatory simulator are documented below as well. | The following regulatory ideas are being implemented on the regulatory simulator. References to code where specific changes are being implemented on the regulatory simulator are documented below as well. | ||
| - | |||
| - | |||
| - | ===== Database improvements ===== | ||
| - | |||
| - | Johannes has made a recommendation to design the regulatory database to adhere to the following rules, this was discussed [[http://marc.info/?t=123771257500005&r=1&w=2|this thread]]. In summary, using the notation outlined for [[http://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals|mathematical intervals]]: | ||
| - | |||
| - | |||
| - | <code> 0) for all 1 <= k < n : MAX_k <= MIN_{k+1} | ||
| - | |||
| - | 1) each rule in the regdomain covers the frequency range (MIN_1, MAX_1] | ||
| - | |||
| - | 2) given C = union (over all k = 1 .. n) of (MIN_k, MAX_k] | ||
| - | it must be true that | ||
| - | (CENTER - BW/2, CENTER + BW/2) is a subset of C | ||
| - | |||
| - | 3) it must be true for all 1 <= k <= n: | ||
| - | if CENTER in (MIN_k, MAX_k] : BW <= BW_k | ||
| - | |||
| - | 4) This is easier to formulate algorithmically: | ||
| - | USE_FLAGS = 0 | ||
| - | for k = 1 .. n | ||
| - | if (CENTER - BW/2, CENTER + BW/2) intersects (MIN_k, MAX_k]: | ||
| - | USE_FLAGS |= FLAGS_k</code> | ||
| - | This is indeed a good approach to simplifying the rule interpretation but assumes that regulatory bodies will never supply overlapping regulatory rules that would differ based on output power or bandwidth. If the regulatory code would support overlapping regulatory rules we'd also be able to use the same infrastructure to do dynamic allocation beyond just accounting for what regulatory bodies ask us to support. | ||
| Line 47: | Line 23: | ||
| Its believed we may need to allow for spectral power limits (e.g. 10mW/MHz). If this is true the database may need to be adjusted to account for these. This is relevant for 5/10 MHz channels, where we currently assume 1/4 and 1/2 TX power respectively (i.e. assume a spectral power limit being reached exactly for 20 MHz channels) which doesn't allow using the full power if the spectral power limit isn't exactly that. | Its believed we may need to allow for spectral power limits (e.g. 10mW/MHz). If this is true the database may need to be adjusted to account for these. This is relevant for 5/10 MHz channels, where we currently assume 1/4 and 1/2 TX power respectively (i.e. assume a spectral power limit being reached exactly for 20 MHz channels) which doesn't allow using the full power if the spectral power limit isn't exactly that. | ||
| + | ===== direct database loading ===== | ||
| + | |||
| + | Instead of going through CRDA, we want to load the database directly into the kernel. | ||
| + | Since this means a major change, a [[regdb-file-format|new, extensible, file format]] should be used. | ||
en/developers/todo-list/regulatory.txt ยท Last modified: 2015/10/14 17:13 by Johannes Berg
Page Tools
