[Battlemesh] FCC Contacts about Wifi Regulations

Paul Gardner-Stephen paul at servalproject.org
Fri Aug 5 07:24:45 UTC 2016


Hello,

On Fri, Aug 5, 2016 at 3:42 PM, Jonathan Morton <chromatix99 at gmail.com>
wrote:

> > We need to be able to have Mesh Extenders imported into practically any
> country at short notice, e.g., if we succeed in having the Red
> Cross/Crescent movement adopt them.
> >
> > Where it gets complicated is if we have the <insert random small
> pacific, african, european, south american, middle-eastern or other country
> here> regulator and customs people want a rapid assurance that the devices
> cannot be operated except on some band (which they might authorise for us
> at short notice to meet a humanitarian need).
>
> “Complicated” isn’t the word.  “Fundamentally incompatible requirements”
> is.
>
> On the one hand, you need to be able to “rapidly reconfigure” your
> hardware for a different frequency band, at short notice, from generic
> stock, and without making actual hardware changes.
>
> On the other hand, you anticipate needing to be able to show that the
> preceding action *cannot* be done to these same devices once deployed in
> the field.
>
> You have a big problem here.  Something has to give.
>

Agreed in general.


>
> As a related problem, consumer-grade APs are already easy to physically
> transport between Europe, America and Asia.  I’ve literally done that
> myself on occasion while visiting; I have a habit of bringing a reasonably
> complete computing environment with me wherever I go.
>
> But my European AP is not FCC-compliant, because it is trivially capable
> of transmitting on frequencies that are not permitted in the USA (eg.
> 2.4GHz channels 12 & 13).  What’s more, it cannot be made FCC-compliant,
> even temporarily, because the firmware is locked down so that I can only
> select from European regulatory domains.  I suspect there’s a jumper
> somewhere enforcing this.
>
> I think the correct solution is as follows:
>
> 1: Allow software-level reconfiguration of the radios.  Make it as easy as
> possible to select the correct regulatory domain, using geolocation if
> practical.  Before selling/deploying hardware, set it up correctly for its
> intended region, or for a failsafe composite region which is compliant in
> all of the most common domains.
>

Unfortunately we know from the TP-LINK case just now, that the FCC doesn't
like this, and experience from RC and others, is that the staff on the
border during disasters also get cagey about any purely software option.


>
> 2: Make the end-user liable for the emissions of his hardware, if he has
> explicitly set an incorrect regulatory domain or made hardware
> modifications (eg. to increase its power output).  Place a prominent
> notice, as Juliusz suggested, informing the end-user of this
> responsibility.


> This solves both problems: freedom and flexibility is retained, and the
> FCC still has a way to enforce the regulations (with boots on the ground).
>

Except that they will instead enforce (as will many other national
regulators) by declining approval to import/use.  We know stories from RC
national societies where it has taken weeks to get vital communications
components in because the people at the border didn't feel comfortable --
and this is a key point: If we can straight-faced say that this hardware
(ME + cable) can only operate on the approved band(s) for that country,
then they will wave it through. If not, it will get held up for weeks.

This is why I have gone for the minimum hardware restraint, that is by
design, able to be easily bypassed by the people who need to do so.  Also,
the value of being able to configure the device for a region simply by
supplying the correct lead should not be underestimated, because it removes
a significant training/deployment complication.

I should also add, that the power cables for countries that don't get upset
if there is only software configuration preventing use of other bands, that
we can wire those cables to allow 3rd party firmware -- that is, we can
minimise the hardware interlock to exactly only those places that need it,
and it can be left to software in all other jurisdictions.

That is, with the power cable approach, we can simply give devices to
people, they turn them on, and they are automatically operating in the
correct regional settings.  This is not possible with the software
approach.  Can you think of a solution to this ease of deployment problem
with the purely software approach?  Similarly, can you think of a solution
to overstrained border personnel using only software (and the related
problem of regulatory approval)?

Paul.


>
>  - Jonathan Morton
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160805/be02024c/attachment.htm>


More information about the Battlemesh mailing list