Go back –> TODO list

Regulatory TODO

Regulatory code is maintained on the Linux kernel but a revamp of new ideas is being considered on a userspace regulatory simulator. The userspace regulatory simulator is designed to help us create / modify / simulate software changes easily but at the same time exist as a template for anyone to use the same software in any other software environment given that the license of the code is permissively licensed.

Port to any other Operating System
Use in firmware if needed

You can find the regulatory simulator here:

https://github.com/mcgrof/regsim

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 this thread. In summary, using the notation outlined for mathematical intervals:

 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

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.

TPC

TPC is something we have considered adding but at least as per our latest review no one seems to have come up with reasons to support this.

Spectral power limits

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.