software layer provides a support framework for drivers that includes
comprehensive regulatory support.
provides mechanisms that enforce
by privileged user applications.
Drivers define a devices capabilities and can
intercept and control regulatory changes requested through
The initial regulatory state, including the channel list, must be
filled in by the driver before calling
The channel list should reflect the set of channels the device is
for use on.
This list may also be requested later through the
method in the
function is provided as a rudimentary fallback for drivers that do not
(or cannot) fill in a proper channel list.
Default regulatory state is supplied such as the regulatory SKU,
ISO country code, location (e.g. indoor, outdoor), and a set of
frequency bands the device is capable of operating on.
populates the channel table in
with a default set of channels and capabilities.
Note this mechanism should be used with care as any mismatch between
the channel list created and the devices capabilities can result
in runtime errors (e.g. a request to operate on a channel the device
does not support).
The SKU and country information are used for generating 802.11h protocol
elements and related operation such as for 802.11d; mis-setup by a
driver is not fatal, only potentially confusing.
Devices that do not have a fixed/default regulatory state can set
the regulatory SKU to
and country code to
and leave proper setup to user applications.
If default settings are known they can be installed and/or an event
can be dispatched to user space using
will do the appropriate setup work at system boot (or device insertion).
The channel table is sorted to optimize lookups using the
This should be done whenever the channel table contents are modified.
function allocates an information element as specified by 802.11h.
Because this is expensive to generate it is cached in
and generated only when regulatory state changes.
Drivers that call
directly should not help with this caching; doing so may confuse the