| Message ID | 10ffaa74a0779b7c7047de70cb1db7dfb0000022.1625068999.git.b.K.il.h.u+tigbuh@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | [v2] wireless-regdb: recent FCC report and order allows 5850-5895 immediately | expand |
On Wed, Jun 30, 2021 at 06:03:20PM +0200, bkil wrote: > The new band is called U-NII-4. > > The report recommends combining it with 5725-5895 to allow 160 MHz > bandwidth, but that's technically not that easy with regdb due to the > differing restrictions of the two parts. Marking the line for U-NII-3 > NO-OUTDOOR and PTMP-ONLY along with extending its range would be a > possible workaround, but this needs to be discussed. > > I don't see a requirement for TPC, hence reducing EIRP by 3dB is not > needed. I've marked it 33dBm (minus 6dB for clients) to cope with 20MHz, > but the band can support higher power, though the logic is complicated. > > The upper subband (5895-5925 MHz) of the new band is reserved for ITS. > > "We limit unlicensed use to indoor operations in recognition of the > potential that ITS licensees may currently be operating" > > "We also proposed that U-NII-4 devices be permitted to operate at the same > power levels as U-NII-3 devices." > > "For the U-NII-4 band, indoor access point EIRP will be limited to > 33 dBm/20 MHz and 36 dBm/40 MHz. When combined with U-NII-3 band spectrum, > indoor access point EIRP can scale to 36 dBm for 80 and 160 megahertz > channels." > > "Client devices would be limited to power levels 6 dB below the power > limits for access points." > > "the First Report and Order prohibit U-NII-4 client-to-client > communications to protect co-channel incumbent ITS" > > Signed-off-by: bkil <b.K.il.h.u+tigbuh@gmail.com> Applied, thanks!
On Wed, Jun 30, 2021 at 06:03:20PM +0200, bkil wrote: > The new band is called U-NII-4. > > The report recommends combining it with 5725-5895 to allow 160 MHz > bandwidth, but that's technically not that easy with regdb due to the > differing restrictions of the two parts. Marking the line for U-NII-3 > NO-OUTDOOR and PTMP-ONLY along with extending its range would be a > possible workaround, but this needs to be discussed. > > I don't see a requirement for TPC, hence reducing EIRP by 3dB is not > needed. I've marked it 33dBm (minus 6dB for clients) to cope with 20MHz, > but the band can support higher power, though the logic is complicated. > > The upper subband (5895-5925 MHz) of the new band is reserved for ITS. > > "We limit unlicensed use to indoor operations in recognition of the > potential that ITS licensees may currently be operating" > > "We also proposed that U-NII-4 devices be permitted to operate at the same > power levels as U-NII-3 devices." > > "For the U-NII-4 band, indoor access point EIRP will be limited to > 33 dBm/20 MHz and 36 dBm/40 MHz. When combined with U-NII-3 band spectrum, > indoor access point EIRP can scale to 36 dBm for 80 and 160 megahertz > channels." > > "Client devices would be limited to power levels 6 dB below the power > limits for access points." > > "the First Report and Order prohibit U-NII-4 client-to-client > communications to protect co-channel incumbent ITS" > > Signed-off-by: bkil <b.K.il.h.u+tigbuh@gmail.com> > --- > db.txt | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/db.txt b/db.txt > index c71a03a..ae6ea31 100644 > --- a/db.txt > +++ b/db.txt > @@ -1587,7 +1587,10 @@ country US: DFS-FCC > # requirements, we can extend the range by 5 MHz to make the kernel > # happy and be able to use channel 144. > (5470 - 5730 @ 160), (23), DFS > - (5730 - 5850 @ 80), (30) > + (5730 - 5850 @ 160), (30), AUTO-BW > + # https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > + (5850 - 5895 @ 160), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW, NO-IR I discovered a couple of problems here. The first is that it seems I forgot to test build this patch before I pushed it. The PTMP-ONLY flag isn't allowed by db2fw.py. This was done by Johannes for reasons which aren't explained, so maybe he can shed some light on it. The flag doesn't appear to be used by the kernel or hostapd, so maybe it was deprecated long ago. Anyway, I've pushed a change to remove this flag. The second problem is more serious. I thought that we could allow 160 MHz bandwidth across two AUTO-BW ranges too small for this bandwidth, but it turns out that the kernel rejects any rules with a bandwidth greater than the frequency range of the rule. I'm not sure what we can do about this. Even if the kernel were changed to support allowing greater bandwidths across combined ranges, we're going to have a backwards compatibility problem with older kernels. Seth
Hi, Uh, sorry for the delay. > > The first is that it seems I forgot to test build this patch before I > pushed it. The PTMP-ONLY flag isn't allowed by db2fw.py. This was done > by Johannes for reasons which aren't explained, so maybe he can shed > some light on it. The flag doesn't appear to be used by the kernel or > hostapd, so maybe it was deprecated long ago. Anyway, I've pushed a > change to remove this flag. I don't remember, but quite likely we decided it was just not something we could implement properly or so, and never supported it? Sorry. Clearly the kernel does nothing at all with NL80211_RRF_PTMP_ONLY. > The second problem is more serious. I thought that we could allow 160 > MHz bandwidth across two AUTO-BW ranges too small for this bandwidth, > but it turns out that the kernel rejects any rules with a bandwidth > greater than the frequency range of the rule. I'm not sure what we can > do about this. Even if the kernel were changed to support allowing > greater bandwidths across combined ranges, we're going to have a > backwards compatibility problem with older kernels. OTOH, doesn't AUTO-BW basically ignore the max bandwidth for a given range anyway, seeing the code in reg_get_max_bandwidth_from_range()? So just keeping it at 80 with AUTO-BW would still result in 160 being usable? I think? johannes
On Mon, Aug 09, 2021 at 10:06:31PM +0200, Johannes Berg wrote: > Hi, > > Uh, sorry for the delay. > > > > The first is that it seems I forgot to test build this patch before I > > pushed it. The PTMP-ONLY flag isn't allowed by db2fw.py. This was done > > by Johannes for reasons which aren't explained, so maybe he can shed > > some light on it. The flag doesn't appear to be used by the kernel or > > hostapd, so maybe it was deprecated long ago. Anyway, I've pushed a > > change to remove this flag. > > I don't remember, but quite likely we decided it was just not something > we could implement properly or so, and never supported it? Sorry. > > Clearly the kernel does nothing at all with NL80211_RRF_PTMP_ONLY. > > > The second problem is more serious. I thought that we could allow 160 > > MHz bandwidth across two AUTO-BW ranges too small for this bandwidth, > > but it turns out that the kernel rejects any rules with a bandwidth > > greater than the frequency range of the rule. I'm not sure what we can > > do about this. Even if the kernel were changed to support allowing > > greater bandwidths across combined ranges, we're going to have a > > backwards compatibility problem with older kernels. > > OTOH, doesn't AUTO-BW basically ignore the max bandwidth for a given > range anyway, seeing the code in reg_get_max_bandwidth_from_range()? So > just keeping it at 80 with AUTO-BW would still result in 160 being > usable? I think? Yeah, I think you're right. So I guess the changes we ended up with should allow 160 Mz across these ranges. Thanks, Seth
diff --git a/db.txt b/db.txt index c71a03a..ae6ea31 100644 --- a/db.txt +++ b/db.txt @@ -1587,7 +1587,10 @@ country US: DFS-FCC # requirements, we can extend the range by 5 MHz to make the kernel # happy and be able to use channel 144. (5470 - 5730 @ 160), (23), DFS - (5730 - 5850 @ 80), (30) + (5730 - 5850 @ 160), (30), AUTO-BW + # https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients + (5850 - 5895 @ 160), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW, NO-IR # 60g band # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf # channels 1-6 EIRP=40dBm(43dBm peak)
The new band is called U-NII-4. The report recommends combining it with 5725-5895 to allow 160 MHz bandwidth, but that's technically not that easy with regdb due to the differing restrictions of the two parts. Marking the line for U-NII-3 NO-OUTDOOR and PTMP-ONLY along with extending its range would be a possible workaround, but this needs to be discussed. I don't see a requirement for TPC, hence reducing EIRP by 3dB is not needed. I've marked it 33dBm (minus 6dB for clients) to cope with 20MHz, but the band can support higher power, though the logic is complicated. The upper subband (5895-5925 MHz) of the new band is reserved for ITS. "We limit unlicensed use to indoor operations in recognition of the potential that ITS licensees may currently be operating" "We also proposed that U-NII-4 devices be permitted to operate at the same power levels as U-NII-3 devices." "For the U-NII-4 band, indoor access point EIRP will be limited to 33 dBm/20 MHz and 36 dBm/40 MHz. When combined with U-NII-3 band spectrum, indoor access point EIRP can scale to 36 dBm for 80 and 160 megahertz channels." "Client devices would be limited to power levels 6 dB below the power limits for access points." "the First Report and Order prohibit U-NII-4 client-to-client communications to protect co-channel incumbent ITS" Signed-off-by: bkil <b.K.il.h.u+tigbuh@gmail.com> --- db.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)