From wens at kernel.org  Wed Jan  3 21:58:35 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Thu, 4 Jan 2024 13:58:35 +0800
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
Message-ID: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>

Hi folks,

I wanted to clarify the current state of things.

As far as I know the kernel doesn't have facilities to support TPC or
transmit power control, nor does the wireless-regdb database. And so
in the database we would either omit rules that require TPC, or include
alternative rules (as specified by local regulations) not requiring TPC.
Am I right?

This came up recently with regulatory changes for Singapore and Armenia.

For Singapore [1], the 5.250 ? 5.350 GHz range has provisions that allow
usage without TPC at a lower power, but the 5.470 ? 5.725 GHz does not.

For Armenia [2], the updated text (translated by Google Translate) as I
read it requires TPC for all 5 GHz channels.


Thanks
ChenYu

[1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
[2] https://www.arlis.am/DocumentView.aspx?DocID=181829


From b.K.il.h.u+tigbuh at gmail.com  Thu Jan  4 01:07:51 2024
From: b.K.il.h.u+tigbuh at gmail.com (b.K.il.h.u+tigbuh at gmail.com)
Date: Thu, 4 Jan 2024 10:07:51 +0100
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
Message-ID: <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>

You can find a wording in most such regulations that if TPC is not
supported, the maximal TX power must be reduced by 3 dBmW. Hence in
all such cases, the entries in db.txt contain 3 less than the maximum.

If, on the other hand, you know of a country that specifies that
devices lacking TPC may not use the band at all, all such band entries
must be omitted (commented out along with a URL).

On Thu, Jan 4, 2024 at 6:59?AM Chen-Yu Tsai <wens at kernel.org> wrote:
>
> Hi folks,
>
> I wanted to clarify the current state of things.
>
> As far as I know the kernel doesn't have facilities to support TPC or
> transmit power control, nor does the wireless-regdb database. And so
> in the database we would either omit rules that require TPC, or include
> alternative rules (as specified by local regulations) not requiring TPC.
> Am I right?
>
> This came up recently with regulatory changes for Singapore and Armenia.
>
> For Singapore [1], the 5.250 ? 5.350 GHz range has provisions that allow
> usage without TPC at a lower power, but the 5.470 ? 5.725 GHz does not.
>
> For Armenia [2], the updated text (translated by Google Translate) as I
> read it requires TPC for all 5 GHz channels.
>
>
> Thanks
> ChenYu
>
> [1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
> [2] https://www.arlis.am/DocumentView.aspx?DocID=181829
>


From johannes at sipsolutions.net  Thu Jan  4 01:42:30 2024
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 04 Jan 2024 10:42:30 +0100
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
	 <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>
Message-ID: <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net>

On Thu, 2024-01-04 at 10:07 +0100, b.K.il.h.u+tigbuh at gmail.com wrote:
> You can find a wording in most such regulations that if TPC is not
> supported, the maximal TX power must be reduced by 3 dBmW. Hence in
> all such cases, the entries in db.txt contain 3 less than the maximum.
> 
> If, on the other hand, you know of a country that specifies that
> devices lacking TPC may not use the band at all, all such band entries
> must be omitted (commented out along with a URL).

Yeah, that's how we (currently) handle things.

I'm not even sure what the requirements would be for "TPC" to be
implemented, tbh.

> > As far as I know the kernel doesn't have facilities to support TPC or
> > transmit power control,?

Right. I have, however, heard the interpretation that the fact that we
have - even if nobody uses it - the "iw set txpower" command means that
we *do* have TPC ... Not really sure what to make of that though.

> > nor does the wireless-regdb database.

Correct. With the new regdb format we could add something that would
enable these ranges in the kernel only with some additional
requirements, but
  (a) we don't implement that now, and
  (b) I don't know what the requirements would actually be, e.g. would
      it be enough that the driver promises it implements "TPC" in some
      way? Or even the manual setting?

> > And so
> > in the database we would either omit rules that require TPC, or include
> > alternative rules (as specified by local regulations) not requiring TPC.
> > Am I right?

Right.

johannes


From b.K.il.h.u+tigbuh at gmail.com  Thu Jan  4 02:01:16 2024
From: b.K.il.h.u+tigbuh at gmail.com (b.K.il.h.u+tigbuh at gmail.com)
Date: Thu, 4 Jan 2024 11:01:16 +0100
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
 <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com> <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net>
Message-ID: <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com>

Ideally, TPC should be a fully automatic mechanism that reduces
transmit power between the two points to as low of a level as possible
while delivering the same quality of service. The purpose is to reduce
the excess headroom in each link. I.e., if you could still link with
65Mb/s towards a given direction using 14dBmW, you should not transmit
with 20dBmW.

Some only set the AP TX power globally (i.e., same towards all of its
connected clients at the moment) to tackle the hidden/exposed node
problem, but again must do this adaptively and change this constantly
without human intervention. There exist multiple advanced algorithms
for this, some proprietary tuned for corporate deployment.

Actually, if we accepted automatically retuning tx power with iw based
on actual link stats of momentarily connected clients every 60s with
cron, this could be added to OpenWrt pretty easily.

> Class A devices control their transmit power within ?3 dB and class B devices control their power within ?9 dB.

- https://www.litepoint.com/blog/wi-fi-6-ofdma/
- https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_RRM_White_Paper/tpc.html

On Thu, Jan 4, 2024 at 10:42?AM Johannes Berg <johannes at sipsolutions.net> wrote:
>
> On Thu, 2024-01-04 at 10:07 +0100, b.K.il.h.u+tigbuh at gmail.com wrote:
> > You can find a wording in most such regulations that if TPC is not
> > supported, the maximal TX power must be reduced by 3 dBmW. Hence in
> > all such cases, the entries in db.txt contain 3 less than the maximum.
> >
> > If, on the other hand, you know of a country that specifies that
> > devices lacking TPC may not use the band at all, all such band entries
> > must be omitted (commented out along with a URL).
>
> Yeah, that's how we (currently) handle things.
>
> I'm not even sure what the requirements would be for "TPC" to be
> implemented, tbh.
>
> > > As far as I know the kernel doesn't have facilities to support TPC or
> > > transmit power control,
>
> Right. I have, however, heard the interpretation that the fact that we
> have - even if nobody uses it - the "iw set txpower" command means that
> we *do* have TPC ... Not really sure what to make of that though.
>
> > > nor does the wireless-regdb database.
>
> Correct. With the new regdb format we could add something that would
> enable these ranges in the kernel only with some additional
> requirements, but
>   (a) we don't implement that now, and
>   (b) I don't know what the requirements would actually be, e.g. would
>       it be enough that the driver promises it implements "TPC" in some
>       way? Or even the manual setting?
>
> > > And so
> > > in the database we would either omit rules that require TPC, or include
> > > alternative rules (as specified by local regulations) not requiring TPC.
> > > Am I right?
>
> Right.
>
> johannes


From me at ndoo.sg  Thu Jan 11 19:05:29 2024
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 12 Jan 2024 11:05:29 +0800
Subject: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules
 for Singapore (SG) for September 2023
In-Reply-To: <CAGb2v65uD9TQuMzrMo8JoWEMp8WbVrKAf92tn17tA98GXdPWZQ@mail.gmail.com>
References: <20230903102022.11186-1-me@ndoo.sg> <CAGb2v65uD9TQuMzrMo8JoWEMp8WbVrKAf92tn17tA98GXdPWZQ@mail.gmail.com>
Message-ID: <CA+yTfBBUymdYxiO2wFUzVvDX6+nkq9mhx-MWEEi4jEw3WqGgcg@mail.gmail.com>

Hi there Chen-Yu,

On Fri, Dec 22, 2023 at 12:35?PM Chen-Yu Tsai <wens at kernel.org> wrote:
>
> On Sun, Sep 3, 2023 at 9:25?PM Andrew Yong <me at ndoo.sg> wrote:
> >
> >  - Update regulatory rules for September 2023 IMDA TS SRD [1]
> >  - Enable 5945 - 6425 MHz (Wi-Fi 6E) band per legislation
> >  - Switch units from dBm to mW to match values listed in legislation
> >  - Allow AUTO-BW between 5470 - 5850 MHz to permit additional 160 MHz BW options
> >
> > [1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
>
> Thanks for the patch!
>
> > Signed-off-by: Andrew Yong <me at ndoo.sg>
> > ---
> >  db.txt | 34 ++++++++++++++++++----------------
> >  1 file changed, 18 insertions(+), 16 deletions(-)
> >
> > diff --git a/db.txt b/db.txt
> > index fdc2c13..cbe1a88 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -1584,25 +1584,27 @@ country SE: DFS-ETSI
> >         # 60 GHz band channels 1-4 (ETSI EN 302 567)
> >         (57000 - 66000 @ 2160), (40)
> >
> > -# https://www.imda.gov.sg/-/media/Imda/Files/Regulation-Licensing-and-Consultations/ICT-Standards/Telecommunication-Standards/Radio-Comms/IMDATSSRD.pdf
> > -# IMDA TS SRD, Issue 1 Revision 1, April 2019, subsequently "IMDA TS SRD"
> > -# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 (25); ANSI C63.10-2013 and FCC Part 15 Section 15.247 or EN 300 328
> > -# 5150 - 5350 MHz: IMDA TS SRD, Table 1 (29); FCC Part 15 Section 15.407 (1) 5.15-5.25 GHz (2) 5.25-5.35 GHz; EN 301 893
> > -# 5470 - 5725 MHz: IMDA TS SRD, Table 1 (30); FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893
> > -# 5725 - 5850 MHz: IMDA TS SRD, Table 1 (27); FCC Part 15 Section 15.247; FCC Part 15 Section 15.407 (3) 5.725-5.85 GHz
> > -# 57000 - 66000 MHz: IMDA TS SRD, Table 1 (31); ETSI EN 302 567
> > -# Note: 27dBm for 5470-5725MHz bands is 3dBm reduction per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893 as referenced by IMDA TS SRD
> > +# https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
> > +# IMDA TS SRD, Issue 1 Revision 3, Sep 2023, subsequently "IMDA TS SRD"
> > +# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 Sub-band 32e
> > +# 5150 - 5350 MHz: IMDA TS SRD, Table 1 Sub-band 33a
> > +# 5470 - 5725 MHz: IMDA TS SRD, Table 1 Sub-band 34
> > +# 5725 - 5850 MHz: IMDA TS SRD, Table 1 Sub-band 35
> > +# 5945 - 6425 MHz: IMDA TS SRD, Table 1 Sub-band 45b
> > +# 57000 - 66000 MHz: IMDA TS SRD, Table 1 Sub-band 40
> > +# Note: 500mW for 5470-5725MHz bands per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz as referenced by IMDA TS SRD
> >  #  AU and BG regulatory domains use the same interpretation of cited FCC and ETSI standards
> > -# Note: The transmit power for 5250-5350MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (29)
> > -# Note: The transmit power for 5470-5725MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (30)
> > +# Note: The transmit power for 5250-5350MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD, Table 1 Sub-band 33a
> > +# Note: The transmit power for 5470-5725MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 Sub-band 34
>
> "... raised by 100 mW ..." given the new units?

Ack, will amend in v2.

>
> Also, such a provision is not given for 5470-5725MHz in the spec. My
> interpretation of the text is that a "reference" is referencing other
> regulations for "reference" when designing the local rules, not that it
> allows following those references directly, unless explicitly noted.

>From the parallel discussion at [1], it sounds like this has been the
interpretation used for multiple regdomains, e.g. AU.

IMHO, it would be outside of the scope of this patch which implements
changes since the last Singapore regulation release. I would prefer a
separate patch to comment out 5470-5725MHz, which can later be
reverted/uncommented once a decision is reached.

Though my opinion would be that a separate patchset that universally
addresses all the interpreted/grey-area TPC offsets, would be more
appropriate, once that decision is reached.

Anyway, I'll defer to your decision as the maintainer; I'll keep this
band in my patchv2 meanwhile and do a v3 if I'm not in time for your
decision.

>
> >  country SG: DFS-FCC
> > -       (2400 - 2483.5 @ 40), (23)
> > -       (5150 - 5250 @ 80), (23), AUTO-BW
> > -       (5250 - 5350 @ 80), (20), DFS, AUTO-BW
> > -       (5470 - 5725 @ 160), (27), DFS
> > -       (5725 - 5850 @ 80), (30)
> > -       (57000 - 66000 @ 2160), (40)
> > +       (2400 - 2483.5 @ 40), (200 mW)
> > +       (5150 - 5250 @ 80), (200 mW), AUTO-BW
> > +       (5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW
> > +       (5470 - 5725 @ 160), (500 mW), DFS, AUTO-BW
>
> This needs more justification. Unlike for the 5.15 ~ 5.35 GHz range,
> the standard does _not_ give an option without TPC for this band.
>
> > +       (5725 - 5850 @ 80), (1000 mW), AUTO-BW

As above.

>
> Instead of AUTO-BW here, can you follow the examples from TW and US of
> expanding the previous band by 5 MHz? That should cover the 160 MHz
> channel.

Ack, will amend in v2.

Thanks for reviewing.
Andrew

[1] https://lists.infradead.org/pipermail/wireless-regdb/2024-January/001490.html

>
>
> ChenYu
>
> > +       (5945 - 6425 @ 320), (250 mW), NO-OUTDOOR
> > +       (57000 - 66000 @ 2160), (10000 mW)
> >
> >  # SI as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
> >  # and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
> > --
> > 2.41.0
> >
> >
> > _______________________________________________
> > wireless-regdb mailing list
> > wireless-regdb at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb


From me at ndoo.sg  Thu Jan 11 19:28:29 2024
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 12 Jan 2024 11:28:29 +0800
Subject: [PATCH v2] wireless-regdb: Update regulatory rules for Singapore (SG)
Message-ID: <20240112033321.23052-2-me@ndoo.sg>

Changes since v1:
  - Update comment about raising Tx power upon TPC implementation to specify mW values
  - Extend (5470 - 5725 @ 160) band to adjacent 5730 MHz to enable Ch 144 similar to US & TW regdomain, instead of using AUTO-BW


From wens at kernel.org  Thu Jan 11 19:37:12 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Fri, 12 Jan 2024 11:37:12 +0800
Subject: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules
 for Singapore (SG) for September 2023
In-Reply-To: <CA+yTfBBUymdYxiO2wFUzVvDX6+nkq9mhx-MWEEi4jEw3WqGgcg@mail.gmail.com>
References: <20230903102022.11186-1-me@ndoo.sg> <CAGb2v65uD9TQuMzrMo8JoWEMp8WbVrKAf92tn17tA98GXdPWZQ@mail.gmail.com>
 <CA+yTfBBUymdYxiO2wFUzVvDX6+nkq9mhx-MWEEi4jEw3WqGgcg@mail.gmail.com>
Message-ID: <CAGb2v64Vvy5ONktcMRWf_GtWFFG9_R8+sMvn58YWtxPPts6y7A@mail.gmail.com>

On Fri, Jan 12, 2024 at 11:05?AM Andrew Yong <me at ndoo.sg> wrote:
>
> Hi there Chen-Yu,
>
> On Fri, Dec 22, 2023 at 12:35?PM Chen-Yu Tsai <wens at kernel.org> wrote:
> >
> > On Sun, Sep 3, 2023 at 9:25?PM Andrew Yong <me at ndoo.sg> wrote:
> > >
> > >  - Update regulatory rules for September 2023 IMDA TS SRD [1]
> > >  - Enable 5945 - 6425 MHz (Wi-Fi 6E) band per legislation
> > >  - Switch units from dBm to mW to match values listed in legislation
> > >  - Allow AUTO-BW between 5470 - 5850 MHz to permit additional 160 MHz BW options
> > >
> > > [1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
> >
> > Thanks for the patch!
> >
> > > Signed-off-by: Andrew Yong <me at ndoo.sg>
> > > ---
> > >  db.txt | 34 ++++++++++++++++++----------------
> > >  1 file changed, 18 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/db.txt b/db.txt
> > > index fdc2c13..cbe1a88 100644
> > > --- a/db.txt
> > > +++ b/db.txt
> > > @@ -1584,25 +1584,27 @@ country SE: DFS-ETSI
> > >         # 60 GHz band channels 1-4 (ETSI EN 302 567)
> > >         (57000 - 66000 @ 2160), (40)
> > >
> > > -# https://www.imda.gov.sg/-/media/Imda/Files/Regulation-Licensing-and-Consultations/ICT-Standards/Telecommunication-Standards/Radio-Comms/IMDATSSRD.pdf
> > > -# IMDA TS SRD, Issue 1 Revision 1, April 2019, subsequently "IMDA TS SRD"
> > > -# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 (25); ANSI C63.10-2013 and FCC Part 15 Section 15.247 or EN 300 328
> > > -# 5150 - 5350 MHz: IMDA TS SRD, Table 1 (29); FCC Part 15 Section 15.407 (1) 5.15-5.25 GHz (2) 5.25-5.35 GHz; EN 301 893
> > > -# 5470 - 5725 MHz: IMDA TS SRD, Table 1 (30); FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893
> > > -# 5725 - 5850 MHz: IMDA TS SRD, Table 1 (27); FCC Part 15 Section 15.247; FCC Part 15 Section 15.407 (3) 5.725-5.85 GHz
> > > -# 57000 - 66000 MHz: IMDA TS SRD, Table 1 (31); ETSI EN 302 567
> > > -# Note: 27dBm for 5470-5725MHz bands is 3dBm reduction per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893 as referenced by IMDA TS SRD
> > > +# https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
> > > +# IMDA TS SRD, Issue 1 Revision 3, Sep 2023, subsequently "IMDA TS SRD"
> > > +# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 Sub-band 32e
> > > +# 5150 - 5350 MHz: IMDA TS SRD, Table 1 Sub-band 33a
> > > +# 5470 - 5725 MHz: IMDA TS SRD, Table 1 Sub-band 34
> > > +# 5725 - 5850 MHz: IMDA TS SRD, Table 1 Sub-band 35
> > > +# 5945 - 6425 MHz: IMDA TS SRD, Table 1 Sub-band 45b
> > > +# 57000 - 66000 MHz: IMDA TS SRD, Table 1 Sub-band 40
> > > +# Note: 500mW for 5470-5725MHz bands per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz as referenced by IMDA TS SRD
> > >  #  AU and BG regulatory domains use the same interpretation of cited FCC and ETSI standards
> > > -# Note: The transmit power for 5250-5350MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (29)
> > > -# Note: The transmit power for 5470-5725MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (30)
> > > +# Note: The transmit power for 5250-5350MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD, Table 1 Sub-band 33a
> > > +# Note: The transmit power for 5470-5725MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 Sub-band 34
> >
> > "... raised by 100 mW ..." given the new units?
>
> Ack, will amend in v2.
>
> >
> > Also, such a provision is not given for 5470-5725MHz in the spec. My
> > interpretation of the text is that a "reference" is referencing other
> > regulations for "reference" when designing the local rules, not that it
> > allows following those references directly, unless explicitly noted.
>
> From the parallel discussion at [1], it sounds like this has been the
> interpretation used for multiple regdomains, e.g. AU.

For AU, their text explicitly states (for 5250-5350 MHz for example):

    If the maximum EIRP is greater than 100 mW, the transmitter must
    use Transmit Power Control (TPC).

So the rule in our database limits it to 100 mW. It also has a clear
comment stating how high the limit can be raised to if TPC were
implemented.

> IMHO, it would be outside of the scope of this patch which implements
> changes since the last Singapore regulation release. I would prefer a
> separate patch to comment out 5470-5725MHz, which can later be
> reverted/uncommented once a decision is reached.

Yes, that sounds reasonable. Could you send a patch to comment the
band out then? FWIW the Wikipedia writers [1] seem to agree with
my understanding, even though it seems to be based on an older
version.

> Though my opinion would be that a separate patchset that universally
> addresses all the interpreted/grey-area TPC offsets, would be more
> appropriate, once that decision is reached.

That would depend on someone having the time to audit the whole database,
going through all the regulations of all the regions, many of them only
available in the native language. It's a huge task to say the least.

I think it would only happen region by region as they get updated, and
I have references to look at.

> Anyway, I'll defer to your decision as the maintainer; I'll keep this
> band in my patchv2 meanwhile and do a v3 if I'm not in time for your
> decision.

So, please send v2 with the tweaks I asked for, minus removing the
5470-5725 MHz band. And then send another patch for disabling said
band with a comment saying that TPC is required.

> >
> > >  country SG: DFS-FCC
> > > -       (2400 - 2483.5 @ 40), (23)
> > > -       (5150 - 5250 @ 80), (23), AUTO-BW
> > > -       (5250 - 5350 @ 80), (20), DFS, AUTO-BW
> > > -       (5470 - 5725 @ 160), (27), DFS
> > > -       (5725 - 5850 @ 80), (30)
> > > -       (57000 - 66000 @ 2160), (40)
> > > +       (2400 - 2483.5 @ 40), (200 mW)
> > > +       (5150 - 5250 @ 80), (200 mW), AUTO-BW
> > > +       (5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW
> > > +       (5470 - 5725 @ 160), (500 mW), DFS, AUTO-BW
> >
> > This needs more justification. Unlike for the 5.15 ~ 5.35 GHz range,
> > the standard does _not_ give an option without TPC for this band.
> >
> > > +       (5725 - 5850 @ 80), (1000 mW), AUTO-BW
>
> As above.
>
> >
> > Instead of AUTO-BW here, can you follow the examples from TW and US of
> > expanding the previous band by 5 MHz? That should cover the 160 MHz
> > channel.
>
> Ack, will amend in v2.
>
> Thanks for reviewing.
> Andrew

Thank you for the effort!
ChenYu

[1] https://en.wikipedia.org/wiki/List_of_WLAN_channels#Singapore


> [1] https://lists.infradead.org/pipermail/wireless-regdb/2024-January/001490.html
>
> >
> >
> > ChenYu
> >
> > > +       (5945 - 6425 @ 320), (250 mW), NO-OUTDOOR
> > > +       (57000 - 66000 @ 2160), (10000 mW)
> > >
> > >  # SI as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
> > >  # and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
> > > --
> > > 2.41.0
> > >
> > >
> > > _______________________________________________
> > > wireless-regdb mailing list
> > > wireless-regdb at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/wireless-regdb


From me at ndoo.sg  Thu Jan 11 19:40:43 2024
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 12 Jan 2024 11:40:43 +0800
Subject: No subject
Message-ID: <20240112034311.23677-2-me@ndoo.sg>

Changes since v1:
  - In comments relating to TPC, provide absolute mW values alongside relative dBm increase
  - Extend (5470 - 5725 @ 160) band to adjacent 5730 MHz to enable Ch 144 similar to US & TW regdomain as opposed to AUTO-BW in patch v1



From me at ndoo.sg  Thu Jan 11 19:40:44 2024
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 12 Jan 2024 11:40:44 +0800
Subject: [PATCH v2] wireless-regdb: Update regulatory rules for Singapore (SG) for September 2023
In-Reply-To: <20240112034311.23677-2-me@ndoo.sg>
References: <20240112034311.23677-2-me@ndoo.sg>
Message-ID: <20240112034311.23677-3-me@ndoo.sg>

 - Update regulatory rules for September 2023 IMDA TS SRD [1]:
   - Enable 5945 - 6425 MHz (Wi-Fi 6E) band per legislation
 - Switch units from dBm to mW to match values listed in legislation
 - Extend (5470 - 5725 @ 160) band to adjacent 5730 MHz to enable Ch 144 similar to US & TW regdomain

[1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf

Signed-off-by: Andrew Yong <me at ndoo.sg>
---
 db.txt | 38 ++++++++++++++++++++++----------------
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/db.txt b/db.txt
index 01e7338..15b439d 100644
--- a/db.txt
+++ b/db.txt
@@ -1586,25 +1586,31 @@ country SE: DFS-ETSI
 	# 60 GHz band channels 1-4 (ETSI EN 302 567)
 	(57000 - 66000 @ 2160), (40)
 
-# https://www.imda.gov.sg/-/media/Imda/Files/Regulation-Licensing-and-Consultations/ICT-Standards/Telecommunication-Standards/Radio-Comms/IMDATSSRD.pdf
-# IMDA TS SRD, Issue 1 Revision 1, April 2019, subsequently "IMDA TS SRD"
-# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 (25); ANSI C63.10-2013 and FCC Part 15 Section 15.247 or EN 300 328
-# 5150 - 5350 MHz: IMDA TS SRD, Table 1 (29); FCC Part 15 Section 15.407 (1) 5.15-5.25 GHz (2) 5.25-5.35 GHz; EN 301 893
-# 5470 - 5725 MHz: IMDA TS SRD, Table 1 (30); FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893
-# 5725 - 5850 MHz: IMDA TS SRD, Table 1 (27); FCC Part 15 Section 15.247; FCC Part 15 Section 15.407 (3) 5.725-5.85 GHz
-# 57000 - 66000 MHz: IMDA TS SRD, Table 1 (31); ETSI EN 302 567
-# Note: 27dBm for 5470-5725MHz bands is 3dBm reduction per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz; EN 301 893 as referenced by IMDA TS SRD
+# https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
+# IMDA TS SRD, Issue 1 Revision 3, Sep 2023, subsequently "IMDA TS SRD"
+# 2400 - 2483.5 MHz: IMDA TS SRD, Table 1 Sub-band 32e
+# 5150 - 5350 MHz: IMDA TS SRD, Table 1 Sub-band 33a
+# 5470 - 5725 MHz: IMDA TS SRD, Table 1 Sub-band 34
+# 5725 - 5850 MHz: IMDA TS SRD, Table 1 Sub-band 35
+# 5945 - 6425 MHz: IMDA TS SRD, Table 1 Sub-band 45b
+# 57000 - 66000 MHz: IMDA TS SRD, Table 1 Sub-band 40
+# Note: 500mW for 5470-5725MHz bands per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz as referenced by IMDA TS SRD
 #  AU and BG regulatory domains use the same interpretation of cited FCC and ETSI standards
-# Note: The transmit power for 5250-5350MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (29)
-# Note: The transmit power for 5470-5725MHz bands can be raised by 3dBm when TPC is implemented: IMDA TS SRD Table 1 (30)
+# Note: The transmit power for 5250-5350MHz bands can be raised (by 3dBm) to 200mW when TPC is implemented: IMDA TS SRD, Table 1 Sub-band 33a
+# Note: The transmit power for 5470-5725MHz bands can be raised (by 3dBm) to 1000mW when TPC is implemented: IMDA TS SRD Table 1 Sub-band 34
 
 country SG: DFS-FCC
-	(2400 - 2483.5 @ 40), (23)
-	(5150 - 5250 @ 80), (23), AUTO-BW
-	(5250 - 5350 @ 80), (20), DFS, AUTO-BW
-	(5470 - 5725 @ 160), (27), DFS
-	(5725 - 5850 @ 80), (30)
-	(57000 - 66000 @ 2160), (40)
+	(2400 - 2483.5 @ 40), (200 mW)
+	(5150 - 5250 @ 80), (200 mW), AUTO-BW
+	(5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW
+        # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
+        # Since 5725 ~ 5730 MHz belongs to the next range which has looser
+        # requirements, we can extend the range by 5 MHz to make the kernel
+        # happy and be able to use channel 144.
+	(5470 - 5730 @ 160), (500 mW), DFS
+	(5725 - 5850 @ 80), (1000 mW)
+	(5945 - 6425 @ 320), (250 mW), NO-OUTDOOR
+	(57000 - 66000 @ 2160), (10000 mW)
 
 # SI as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
 # and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
-- 
2.43.0



From wens at kernel.org  Thu Jan 11 19:43:50 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Fri, 12 Jan 2024 11:43:50 +0800
Subject: [PATCH v2] wireless-regdb: Update regulatory rules for Singapore (SG)
In-Reply-To: <20240112033321.23052-2-me@ndoo.sg>
References: <20240112033321.23052-2-me@ndoo.sg>
Message-ID: <CAGb2v647wp1fUEkY22ma+ni+kLxeWSezamsGEPUEfedUGJBOAQ@mail.gmail.com>

Hi,

On Fri, Jan 12, 2024 at 11:35?AM Andrew Yong <me at ndoo.sg> wrote:
>
> Changes since v1:
>   - Update comment about raising Tx power upon TPC implementation to specify mW values
>   - Extend (5470 - 5725 @ 160) band to adjacent 5730 MHz to enable Ch 144 similar to US & TW regdomain, instead of using AUTO-BW

I think we're missing the actual patch? Can you resend?

ChenYu


From me at ndoo.sg  Thu Jan 11 20:02:17 2024
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 12 Jan 2024 12:02:17 +0800
Subject: [PATCH] wireless-regdb: Update and disable 5470-5730MHz band according to TPC requirement for Singapore (SG)
Message-ID: <20240112040217.24356-1-me@ndoo.sg>

  - Use original regulation Tx power of 1000mW with TPC for 5470-5730MHz band instead of -3dBm offset without TPC
  - Comment out 5470 - 5730 band to disable it since TPC is not implemented

Signed-off-by: Andrew Yong <me at ndoo.sg>
---
 db.txt | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/db.txt b/db.txt
index 15b439d..ed76600 100644
--- a/db.txt
+++ b/db.txt
@@ -1594,10 +1594,7 @@ country SE: DFS-ETSI
 # 5725 - 5850 MHz: IMDA TS SRD, Table 1 Sub-band 35
 # 5945 - 6425 MHz: IMDA TS SRD, Table 1 Sub-band 45b
 # 57000 - 66000 MHz: IMDA TS SRD, Table 1 Sub-band 40
-# Note: 500mW for 5470-5725MHz bands per FCC Part 15 Section 15.407 (2) 5.47-5.725 GHz as referenced by IMDA TS SRD
-#  AU and BG regulatory domains use the same interpretation of cited FCC and ETSI standards
 # Note: The transmit power for 5250-5350MHz bands can be raised (by 3dBm) to 200mW when TPC is implemented: IMDA TS SRD, Table 1 Sub-band 33a
-# Note: The transmit power for 5470-5725MHz bands can be raised (by 3dBm) to 1000mW when TPC is implemented: IMDA TS SRD Table 1 Sub-band 34
 
 country SG: DFS-FCC
 	(2400 - 2483.5 @ 40), (200 mW)
@@ -1607,7 +1604,8 @@ country SG: DFS-FCC
         # Since 5725 ~ 5730 MHz belongs to the next range which has looser
         # requirements, we can extend the range by 5 MHz to make the kernel
         # happy and be able to use channel 144.
-	(5470 - 5730 @ 160), (500 mW), DFS
+	# 5470 - 5730 requires (unimplemented) TPC per legislation
+        #(5470 - 5730 @ 160), (1000 mW), DFS
 	(5725 - 5850 @ 80), (1000 mW)
 	(5945 - 6425 @ 320), (250 mW), NO-OUTDOOR
 	(57000 - 66000 @ 2160), (10000 mW)
-- 
2.43.0



From wens at kernel.org  Sun Jan 14 19:14:31 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 15 Jan 2024 11:14:31 +0800
Subject: [PATCH v2] wireless-regdb: Update regulatory rules for
 Singapore (SG) for September 2023
In-Reply-To: <20240112034311.23677-3-me@ndoo.sg>
References: <20240112034311.23677-2-me@ndoo.sg>
 <20240112034311.23677-3-me@ndoo.sg>
Message-ID: <170528847198.770636.10523925169343032062.b4-ty@kernel.org>


On Fri, 12 Jan 2024 11:40:44 +0800, Andrew Yong wrote:
>  - Update regulatory rules for September 2023 IMDA TS SRD [1]:
>    - Enable 5945 - 6425 MHz (Wi-Fi 6E) band per legislation
>  - Switch units from dBm to mW to match values listed in legislation
>  - Extend (5470 - 5725 @ 160) band to adjacent 5730 MHz to enable Ch 144 similar to US & TW regdomain
> 
> [1] https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf
> 
> [...]

Applied, thanks!

[1/1] wireless-regdb: Update regulatory rules for Singapore (SG) for September 2023
      commit: bd69898e6f400bee1bf7863f2c65341eb7c746a6

Best regards,
-- 
Chen-Yu Tsai <wens at kernel.org>



From wens at kernel.org  Sun Jan 14 19:14:32 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 15 Jan 2024 11:14:32 +0800
Subject: [PATCH] wireless-regdb: Update and disable 5470-5730MHz band
 according to TPC requirement for Singapore (SG)
In-Reply-To: <20240112040217.24356-1-me@ndoo.sg>
References: <20240112040217.24356-1-me@ndoo.sg>
Message-ID: <170528847205.770636.8573617454652565233.b4-ty@kernel.org>


On Fri, 12 Jan 2024 12:02:17 +0800, Andrew Yong wrote:
>   - Use original regulation Tx power of 1000mW with TPC for 5470-5730MHz band instead of -3dBm offset without TPC
>   - Comment out 5470 - 5730 band to disable it since TPC is not implemented
> 
> 

Applied, thanks!

[1/1] wireless-regdb: Update and disable 5470-5730MHz band according to TPC requirement for Singapore (SG)
      commit: d695bf21d1cdf02e64924f452c242f7588469609

Best regards,
-- 
Chen-Yu Tsai <wens at kernel.org>



From ljctuck at avaya.com  Mon Jan 22 18:08:55 2024
From: ljctuck at avaya.com (Tuck, Lawrence J C (Lawrence))
Date: Tue, 23 Jan 2024 02:08:55 +0000
Subject: [PATCH] wireless-regdb: Correct format of AU definitions for
 genregdb.awk
In-Reply-To: <20240112040217.24356-1-me@ndoo.sg>
References: <20240112040217.24356-1-me@ndoo.sg>
Message-ID: <BY5PR15MB478732869CAB0F4914C1E34FB7742@BY5PR15MB4787.namprd15.prod.outlook.com>


In integrating the latest regdb package, I noted that the September '23 updates for AU resulted in the loss of definitions for 2.4GHz and beyond.  The blank lines added in the previous patch cause the termination of the record processing in the genregdb.awk code generator.

I have attached the patch to correct this issue.

Lawrence Tuck (ljctuck at avaya.com)
Avaya LLC

--
diff --git a/db.txt b/db.txt
index fdc2c13..3800ae0 100644
--- a/db.txt
+++ b/db.txt
@@ -134,33 +134,24 @@ country AU: DFS-ETSI
 	# Item 58
 	(915 - 920 @ 4), (1000 mW)
 	(920 - 928 @ 8), (1000 mW)
-
 	# Item 59
 	(2400 - 2483.5 @ 40), (4000 mW)
-
 	# Item 61
 	(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
-
 	# Item 62 (200 mW allowed if TPC is used)
 	(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW, DFS
-
 	# Item 63(a) (1000 mW with TPC)
 	(5470 - 5600 @ 80), (500 mW), DFS
-
 	# Item 63(b) (1000 mW with TPC)
 	# The end is 5725 but we borrow 5 MHz from the following less restrictive band
 	# so we can get an 80 MHz channel.
 	(5650 - 5730 @ 80), (500 mW), DFS
-
 	# Item 60
 	(5730 - 5850 @ 80), (4000 mW), AUTO-BW
-
 	# Item 22
 	(5850 - 5875 @ 20), (25 mW), AUTO-BW
-
 	# Item 63AA (25 mW if outdoors)
 	(5925 - 6425 @ 160), (250 mW), NO-OUTDOOR
-
 	# Item 65
 	(57000 - 71000 @ 2160), (20000 mW), NO-OUTDOOR


From johannes at sipsolutions.net  Mon Jan 22 23:59:54 2024
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 23 Jan 2024 08:59:54 +0100
Subject: [PATCH] wireless-regdb: Correct format of AU definitions for
 genregdb.awk
In-Reply-To: <BY5PR15MB478732869CAB0F4914C1E34FB7742@BY5PR15MB4787.namprd15.prod.outlook.com>
References: <20240112040217.24356-1-me@ndoo.sg>
	 <BY5PR15MB478732869CAB0F4914C1E34FB7742@BY5PR15MB4787.namprd15.prod.outlook.com>
Message-ID: <e5aefc295fbb78bc464be939e50a1b47ca6b2cb4.camel@sipsolutions.net>

Hi,

> in the genregdb.awk code generator.

Bit confused, where is that generator? And why not just fix the issue
there?

johannes


From johannes at sipsolutions.net  Tue Jan 23 00:03:46 2024
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 23 Jan 2024 09:03:46 +0100
Subject: [PATCH] wireless-regdb: Correct format of AU definitions for
 genregdb.awk
In-Reply-To: <e5aefc295fbb78bc464be939e50a1b47ca6b2cb4.camel@sipsolutions.net>
References: <20240112040217.24356-1-me@ndoo.sg>
	 <BY5PR15MB478732869CAB0F4914C1E34FB7742@BY5PR15MB4787.namprd15.prod.outlook.com>
	 <e5aefc295fbb78bc464be939e50a1b47ca6b2cb4.camel@sipsolutions.net>
Message-ID: <daa219cf533d7ccf09bd8991ac174086b908a860.camel@sipsolutions.net>

On Tue, 2024-01-23 at 08:59 +0100, Johannes Berg wrote:
> Hi,
> 
> > in the genregdb.awk code generator.
> 
> Bit confused, where is that generator? And why not just fix the issue
> there?

Oh, you're thinking of the *ancient* kernel thing? That got removed in
kernel 4.15, and even the old 4.14 longterm is now EOL...

I'd say we don't really need to support that upstream this many years
later.

johannes


From bordjukov at gmail.com  Fri Jan 26 02:46:23 2024
From: bordjukov at gmail.com (Petko Bordjukov)
Date: Fri, 26 Jan 2024 12:46:23 +0200
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
 <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>
 <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net> <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com>
Message-ID: <CAAgmp6vdK-bMJCnXUqhPPADRcd3sJXeFvuSOt5_7HCSV2dVKEQ@mail.gmail.com>

Hi,

The only project I've heard of that implements such functionality is
https://github.com/thuehn/Minstrel-Blues.

On Thu, Jan 4, 2024 at 12:02?PM <b.K.il.h.u+tigbuh at gmail.com> wrote:
>
> Ideally, TPC should be a fully automatic mechanism that reduces
> transmit power between the two points to as low of a level as possible
> while delivering the same quality of service. The purpose is to reduce
> the excess headroom in each link. I.e., if you could still link with
> 65Mb/s towards a given direction using 14dBmW, you should not transmit
> with 20dBmW.
>
> Some only set the AP TX power globally (i.e., same towards all of its
> connected clients at the moment) to tackle the hidden/exposed node
> problem, but again must do this adaptively and change this constantly
> without human intervention. There exist multiple advanced algorithms
> for this, some proprietary tuned for corporate deployment.
>
> Actually, if we accepted automatically retuning tx power with iw based
> on actual link stats of momentarily connected clients every 60s with
> cron, this could be added to OpenWrt pretty easily.
>
> > Class A devices control their transmit power within ?3 dB and class B devices control their power within ?9 dB.
>
> - https://www.litepoint.com/blog/wi-fi-6-ofdma/
> - https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_RRM_White_Paper/tpc.html
>
> On Thu, Jan 4, 2024 at 10:42?AM Johannes Berg <johannes at sipsolutions.net> wrote:
> >
> > On Thu, 2024-01-04 at 10:07 +0100, b.K.il.h.u+tigbuh at gmail.com wrote:
> > > You can find a wording in most such regulations that if TPC is not
> > > supported, the maximal TX power must be reduced by 3 dBmW. Hence in
> > > all such cases, the entries in db.txt contain 3 less than the maximum.
> > >
> > > If, on the other hand, you know of a country that specifies that
> > > devices lacking TPC may not use the band at all, all such band entries
> > > must be omitted (commented out along with a URL).
> >
> > Yeah, that's how we (currently) handle things.
> >
> > I'm not even sure what the requirements would be for "TPC" to be
> > implemented, tbh.
> >
> > > > As far as I know the kernel doesn't have facilities to support TPC or
> > > > transmit power control,
> >
> > Right. I have, however, heard the interpretation that the fact that we
> > have - even if nobody uses it - the "iw set txpower" command means that
> > we *do* have TPC ... Not really sure what to make of that though.
> >
> > > > nor does the wireless-regdb database.
> >
> > Correct. With the new regdb format we could add something that would
> > enable these ranges in the kernel only with some additional
> > requirements, but
> >   (a) we don't implement that now, and
> >   (b) I don't know what the requirements would actually be, e.g. would
> >       it be enough that the driver promises it implements "TPC" in some
> >       way? Or even the manual setting?
> >
> > > > And so
> > > > in the database we would either omit rules that require TPC, or include
> > > > alternative rules (as specified by local regulations) not requiring TPC.
> > > > Am I right?
> >
> > Right.
> >
> > johannes
>


From b.K.il.h.u+tigbuh at gmail.com  Fri Jan 26 03:36:58 2024
From: b.K.il.h.u+tigbuh at gmail.com (b.K.il.h.u+tigbuh at gmail.com)
Date: Fri, 26 Jan 2024 12:36:58 +0100
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <CAAgmp6vdK-bMJCnXUqhPPADRcd3sJXeFvuSOt5_7HCSV2dVKEQ@mail.gmail.com>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
 <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>
 <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net>
 <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com> <CAAgmp6vdK-bMJCnXUqhPPADRcd3sJXeFvuSOt5_7HCSV2dVKEQ@mail.gmail.com>
Message-ID: <CAPuHQ=F5QXXaELZLApK7WiveXSDoUeH-YEHM4RrZy6qLkibS8Q@mail.gmail.com>

Yes, I've read their research when it was published and I view it as
influential results. Their approach jointly optimizes transmit rate
and power for each and every frame (i.e., for each link and each
direction every time).

However, we are talking about much lower hanging fruit if all you want
is an attic mounted access point that tries not to interfere too much
with the neighbors while still dealing with blind spots within the
house. I still think that the periodic global adjustment method also
used by Cisco should be legal and very easy to implement on OpenWrt.

On Fri, Jan 26, 2024 at 11:46?AM Petko Bordjukov <bordjukov at gmail.com> wrote:
>
> Hi,
>
> The only project I've heard of that implements such functionality is
> https://github.com/thuehn/Minstrel-Blues.
>
> On Thu, Jan 4, 2024 at 12:02?PM <b.K.il.h.u+tigbuh at gmail.com> wrote:
> >
> > Ideally, TPC should be a fully automatic mechanism that reduces
> > transmit power between the two points to as low of a level as possible
> > while delivering the same quality of service. The purpose is to reduce
> > the excess headroom in each link. I.e., if you could still link with
> > 65Mb/s towards a given direction using 14dBmW, you should not transmit
> > with 20dBmW.
> >
> > Some only set the AP TX power globally (i.e., same towards all of its
> > connected clients at the moment) to tackle the hidden/exposed node
> > problem, but again must do this adaptively and change this constantly
> > without human intervention. There exist multiple advanced algorithms
> > for this, some proprietary tuned for corporate deployment.
> >
> > Actually, if we accepted automatically retuning tx power with iw based
> > on actual link stats of momentarily connected clients every 60s with
> > cron, this could be added to OpenWrt pretty easily.
> >
> > > Class A devices control their transmit power within ?3 dB and class B devices control their power within ?9 dB.
> >
> > - https://www.litepoint.com/blog/wi-fi-6-ofdma/
> > - https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_RRM_White_Paper/tpc.html
> >
> > > On Thu, 2024-01-04 at 10:07 +0100, b.K.il.h.u+tigbuh at gmail.com wrote:
> > > > You can find a wording in most such regulations that if TPC is not
> > > > supported, the maximal TX power must be reduced by 3 dBmW. Hence in
> > > > all such cases, the entries in db.txt contain 3 less than the maximum.
> > > >
> > > > If, on the other hand, you know of a country that specifies that
> > > > devices lacking TPC may not use the band at all, all such band entries
> > > > must be omitted (commented out along with a URL).


From bordjukov at gmail.com  Fri Jan 26 05:21:33 2024
From: bordjukov at gmail.com (Petko Bordjukov)
Date: Fri, 26 Jan 2024 15:21:33 +0200
Subject: WiF Transmit Power Control (TPC) Regulatory Requirements?
In-Reply-To: <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com>
References: <CAGb2v66xVLqr+tUSD_6uzguGXtj04WfbpT0z9M28r8z-g62Z=A@mail.gmail.com>
 <CAPuHQ=GSuKW5=T0GXXCq7Pf9jw=zcEnms-fEJey68QUWH1ishQ@mail.gmail.com>
 <a5123274d5a8d80d554ffb786e25bef72d45f69b.camel@sipsolutions.net> <CAPuHQ=HSJNXx_ukS4G=+AsM=qp2yMA4mKD=NHDpq+BoMMLSv+Q@mail.gmail.com>
Message-ID: <CAAgmp6t_emZ1GSnh56JuO9Cp=dJcf13rOCN=KdGMXG10nxBoEA@mail.gmail.com>

On Thu, Jan 4, 2024 at 12:02?PM <b.K.il.h.u+tigbuh at gmail.com> wrote:
>
> Ideally, TPC should be a fully automatic mechanism that reduces
> transmit power between the two points to as low of a level as possible
> while delivering the same quality of service. The purpose is to reduce
> the excess headroom in each link. I.e., if you could still link with
> 65Mb/s towards a given direction using 14dBmW, you should not transmit
> with 20dBmW.

Just to add to that, that for most if not all of the EU it must also
'provide on average, a mitigation factor of at least 3 dB on the
maximum permitted output power of the systems'. I read this (not a
lawyer or radio engineer, so please correct me if I'm wrong) as the
average e.i.r.p. of the entire BSS must at any point in time not
exceed the maximum allowed - 3db. This would include AP->STA, STA->AP,
and STA->STA transmissions.


From ljctuck at avaya.com  Tue Jan 30 07:38:53 2024
From: ljctuck at avaya.com (Tuck, Lawrence J C (Lawrence))
Date: Tue, 30 Jan 2024 15:38:53 +0000
Subject: [External]Re: [PATCH] wireless-regdb: Correct format of AU
 definitions for genregdb.awk
In-Reply-To: <daa219cf533d7ccf09bd8991ac174086b908a860.camel@sipsolutions.net>
References: <20240112040217.24356-1-me@ndoo.sg>
	 <BY5PR15MB478732869CAB0F4914C1E34FB7742@BY5PR15MB4787.namprd15.prod.outlook.com>
	 <e5aefc295fbb78bc464be939e50a1b47ca6b2cb4.camel@sipsolutions.net>
 <daa219cf533d7ccf09bd8991ac174086b908a860.camel@sipsolutions.net>
Message-ID: <BY5PR15MB4787BC7FF959CF6A040235E3B77D2@BY5PR15MB4787.namprd15.prod.outlook.com>


Your point is well taken.  I AM dealing with a legacy embedded product that is pre-4.15.  I agree with your
position and will get my linux support team to look into patching the generator.

Thanks,
   Lawrence

-----Original Message-----
From: Johannes Berg <johannes at sipsolutions.net> 
Sent: Tuesday, January 23, 2024 3:04 AM
To: Tuck, Lawrence J C (Lawrence) <ljctuck at avaya.com>; wireless-regdb at lists.infradead.org
Subject: [External]Re: [PATCH] wireless-regdb: Correct format of AU definitions for genregdb.awk

[External Sender]

On Tue, 2024-01-23 at 08:59 +0100, Johannes Berg wrote:
> Hi,
>
> > in the genregdb.awk code generator.
>
> Bit confused, where is that generator? And why not just fix the issue 
> there?

Oh, you're thinking of the *ancient* kernel thing? That got removed in kernel 4.15, and even the old 4.14 longterm is now EOL...

I'd say we don't really need to support that upstream this many years later.

johannes

From wens at kernel.org  Wed Jan 31 00:17:02 2024
From: wens at kernel.org (Chen-Yu Tsai)
Date: Wed, 31 Jan 2024 16:17:02 +0800
Subject: [ANN] wireless-regdb: master-2024-01-23
Message-ID: <ZboB_mw_abHH2sJj@wens.tw>

A new release of wireless-regdb (master-2024-01-23) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2024.01.23.tar.xz

The short log of changes since the master-2023-09-01 release is below.

Appologies for the late announcement. There were some permission issues
preventing the tarball from being uploaded.

--

Andrew Yong (2):
      wireless-regdb: Update regulatory rules for Singapore (SG) for September 2023
      wireless-regdb: Update and disable 5470-5730MHz band according to TPC requirement for Singapore (SG)

Brian Norris (1):
      wireless-regdb: Makefile: Reproducible signatures

CaffeeLake (1):
      wireless-regdb: Update regulatory rules for Japan (JP) for December 2023

Chen-Yu Tsai (2):
      wireless-regdb: Update keys and maintainer information
      wireless-regdb: update regulatory database based on preceding changes

Jiaxun Yang (1):
      wireless-regdb: Update regulatory rules for China (CN)



