linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petko Bordjukov <bordjukov@gmail.com>
To: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"wireless-regdb@lists.infradead.org" 
	<wireless-regdb@lists.infradead.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region
Date: Wed, 16 Jan 2019 12:26:01 +0200	[thread overview]
Message-ID: <CAAgmp6ujgvXAvzB5Y7UcLxosfHCeSaSy5taiJ-jhu2YDk+RVFg@mail.gmail.com> (raw)
In-Reply-To: <cdcde7a4-a2b0-5d4b-83e6-cfbffdfe93d9@quantenna.com>

Hello Igor and Johannes,

From my research around TPC and radar detection in the context of the BG
regulatory domain and respectively ETSI, the relevant regulatory rules are more
specific than both what can currently be expressed in the regdb and what will be
possible to be expressed with your suggested modifications.

For example, in [1] it is stated that for the 5470-5725 MHz band:

  * The maximum allowed transmission power is 1 W e.i.r.p. with a maximum of 50
    mW/MHz spectral density of the average e.i.r.p. for each 1 MHz band.

  * The use of TPC that ensures lowering the average e.i.r.p. of the entire
    system (as I understand it, this means both the AP and STAs) of at least 3
    dbm is required.

  * In case TPC (as I understand it -- that exhibits the parameters above) is
    not used, both the maximum allowed transmission power and maximum spectral
    density of the average e.i.r.p. are lowered by 3 dB.

  * The use of methods for limiting radio interference ensuring at least the
    described in BDS 301 893 (respectively ETSI 301 893) protection
for providing
    coexistance with radio radar systems.

If there is will to extend the regdb format to be able to express accurately and
in their entirety the specifics of the relevant regulations, IMO a wider and
more detailed discussion is in order.

[1] http://www.crc.bg/files/_bg/Spisak_2015.pdf - List of radio equipment that
    uses harmonized within the European Union bands and electronic
    communications terminal equipment (the List)

Best regards,

Petko

On Wed, Jan 16, 2019 at 6:00 AM Igor Mitsyanko
<igor.mitsyanko.os@quantenna.com> wrote:
>
> On 1/15/19 5:45 AM, Johannes Berg wrote:
> >> Question is: does wireless core assumes that each device can do radar
> >> detection in slave modes (eg acting as a STA) and it is enabled by
> >> default? I couldn't find any logic in kernel which would limit 27 dbm
> >> power to 20 for STA devices.
> >
> > No, we shouldn't assume that it can do radar detection by itself ...
> >
> > I guess we should have some code? Or just fix the regdb?
> >
> > johannes
> >
> >
>
> Maybe we have to do both, as there are multiple things to consider:
> - current regdb values are fine for AP mode
> - Tx power values can be 3 dbm higher if TPC is supported. This is
> mentioned in a comment in regdb, but not used anywhere.
> - if STA detects radar, non-occupancy period must start
> - when non-occupancy period elapses, STA must do CAC before returning to
> channel. I guess CAC must be triggered by wpa_supplicant?
>
>
> I'm not sure how to present additional information in regdb while
> preserving backwards compatibility. Maybe we can:
> 1. Have a separate rule marked with NO_RDETECT flag which will advertise
> lower Tx power. Linux wireless core will have to select rule with
> highest Tx power if possible, for better results.
> 2. For TPC 3dbm gain, have a flag TPC_GAIN
> As an example, AW rules will look like:
>
> country AW: DFS-ETSI
>         (2402 - 2482 @ 40), (20)
>         (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3
>         (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3
>         (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3
>         (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3
>
> Linux wireless core will have to update Tx power values when switching
> from AP and STA modes, and somehow notify drivers.
> _______________________________________________
> wireless-regdb mailing list
> wireless-regdb@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wireless-regdb

  reply	other threads:[~2019-01-16 10:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  2:30 Tx power for slave devices in ETSI DFS region Igor Mitsyanko
2019-01-15 13:45 ` Johannes Berg
2019-01-16  3:58   ` Igor Mitsyanko
2019-01-16 10:26     ` Petko Bordjukov [this message]
2019-01-16 12:49       ` [wireless-regdb] " Bjørn Mork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAgmp6ujgvXAvzB5Y7UcLxosfHCeSaSy5taiJ-jhu2YDk+RVFg@mail.gmail.com \
    --to=bordjukov@gmail.com \
    --cc=igor.mitsyanko.os@quantenna.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=wireless-regdb@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).