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
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 <[email protected]> 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
>
On Thu, 2024-01-04 at 10:07 +0100, [email protected] 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
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 <[email protected]> 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 <[email protected]> wrote:
> >
> > On Thu, 2024-01-04 at 10:07 +0100, [email protected] 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
>
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 <[email protected]> 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 <[email protected]> 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, [email protected] 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).
On Thu, Jan 4, 2024 at 12:02 PM <[email protected]> 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.