| Message ID | a79286b90cdfdee3a83397008c0f7b6d67bc7f69.1607035229.git.b.K.il.h.u+tigbuh@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | wireless-regdb: recent FCC report and order allows 5850-5895 immediately | expand |
On Thu, Dec 03, 2020 at 11:40:30PM +0100, bkil wrote: > The new band is called U-NII-4. The report states in paragraph 203 that the order is effective 60 days from publication in the Federal Register, and it looks like they haven't even been published in the Federal Register yet. We will need to wait for the rules to go into effect before applying any updates. > 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 think it should be sufficient to set the bandwidth of both 5730-5850 and 5850-5895 to 160 MHz with AUTO-BW. The kernel will see the AUTO-BW flags and calculate a combined rule where 160 MHz is allowed, and for the original rules any bandwidth exceeding the available bandwidth of the rule will be disallowed. > 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. I believe we have an additional requirement from § 15.407 (a)(3)(v): In the 5.850-5.895 GHz band, client devices must operate under the control of an indoor access point. In all cases, an exception exists for transmitting brief messages to an access point when attempting to join its network after detecting a signal that confirms that an access point is operating on a particular channel. This sounds like a requirement for passive scanning, if so the range should also have the NO-IR flag. Thanks, Seth > > 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..e6dd063 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 @ 80), (30), AUTO-BW > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW > # 60g band > # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf > # channels 1-6 EIRP=40dBm(43dBm peak)
Thanks for double checking. Honestly, I've only spent a few hours skimming through the document and haven't read it through all the way. Agreed that both bandwidths should probably be upped to 160. Considering § 15.407 (a)(3)(v): shouldn't the flag `PTMP-ONLY` already signal this infrastructure-mode only restriction? I think sending a probe request frame before connecting may be considered a "brief message", and NO-IR would even disallow that. Also, if we added NO-IR, wouldn't that close the band for AP's running Linux as well? Other than deciding the above questions, should we get back to finishing this patch after publication sometime next year? There may be a chance for it to change until then. On Fri, Dec 4, 2020 at 4:11 PM Seth Forshee <seth.forshee@canonical.com> wrote: > > On Thu, Dec 03, 2020 at 11:40:30PM +0100, bkil wrote: > > The new band is called U-NII-4. > > The report states in paragraph 203 that the order is effective 60 days > from publication in the Federal Register, and it looks like they haven't > even been published in the Federal Register yet. We will need to wait > for the rules to go into effect before applying any updates. > > > 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 think it should be sufficient to set the bandwidth of both 5730-5850 > and 5850-5895 to 160 MHz with AUTO-BW. The kernel will see the AUTO-BW > flags and calculate a combined rule where 160 MHz is allowed, and for > the original rules any bandwidth exceeding the available bandwidth of > the rule will be disallowed. > > > 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. > > I believe we have an additional requirement from § 15.407 (a)(3)(v): > > In the 5.850-5.895 GHz band, client devices must operate under the > control of an indoor access point. In all cases, an exception exists > for transmitting brief messages to an access point when attempting to > join its network after detecting a signal that confirms that an access > point is operating on a particular channel. > > This sounds like a requirement for passive scanning, if so the range > should also have the NO-IR flag. > > Thanks, > Seth > > > > > 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..e6dd063 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 @ 80), (30), AUTO-BW > > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW > > # 60g band > > # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf > > # channels 1-6 EIRP=40dBm(43dBm peak)
On Sat, Dec 05, 2020 at 09:24:03PM +0100, b.K.il.h.u+tigbuh@gmail.com wrote: > Thanks for double checking. Honestly, I've only spent a few hours > skimming through the document and haven't read it through all the way. > > Agreed that both bandwidths should probably be upped to 160. > > Considering § 15.407 (a)(3)(v): shouldn't the flag `PTMP-ONLY` > already signal this infrastructure-mode only restriction? I think > sending a probe request frame before connecting may be considered a > "brief message", and NO-IR would even disallow that. Also, if we added > NO-IR, wouldn't that close the band for AP's running Linux as well? But it's a brief message "after detecting a signal that confirms that an access point is operating on a particular channel." I think that implies a passive scan, then sending an association request only after seeing a beacon from the AP on the channel. I could be wrong though; my memory on the 802.11 protocol is rusty and out of date. Thanks, Seth > > Other than deciding the above questions, should we get back to > finishing this patch after publication sometime next year? There may > be a chance for it to change until then. > > On Fri, Dec 4, 2020 at 4:11 PM Seth Forshee <seth.forshee@canonical.com> wrote: > > > > On Thu, Dec 03, 2020 at 11:40:30PM +0100, bkil wrote: > > > The new band is called U-NII-4. > > > > The report states in paragraph 203 that the order is effective 60 days > > from publication in the Federal Register, and it looks like they haven't > > even been published in the Federal Register yet. We will need to wait > > for the rules to go into effect before applying any updates. > > > > > 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 think it should be sufficient to set the bandwidth of both 5730-5850 > > and 5850-5895 to 160 MHz with AUTO-BW. The kernel will see the AUTO-BW > > flags and calculate a combined rule where 160 MHz is allowed, and for > > the original rules any bandwidth exceeding the available bandwidth of > > the rule will be disallowed. > > > > > 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. > > > > I believe we have an additional requirement from § 15.407 (a)(3)(v): > > > > In the 5.850-5.895 GHz band, client devices must operate under the > > control of an indoor access point. In all cases, an exception exists > > for transmitting brief messages to an access point when attempting to > > join its network after detecting a signal that confirms that an access > > point is operating on a particular channel. > > > > This sounds like a requirement for passive scanning, if so the range > > should also have the NO-IR flag. > > > > Thanks, > > Seth > > > > > > > > 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..e6dd063 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 @ 80), (30), AUTO-BW > > > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > > > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > > > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW > > > # 60g band > > > # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf > > > # channels 1-6 EIRP=40dBm(43dBm peak)
Indeed your logic seems reasonable regarding passive scanning. However, I'm only looking at it from a wireless-regdb perspective: this seems to be the first NO-IR directive in the database other than for the "world" domain, and I thought that NO-IR is more of a thing that would apply for client devices having no clue where they are, but wouldn't adding NO_IR here keep hostapd from enabling an AP on such a channel? Here's some documentation on this: https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules#beacon_hints I see that passive-scan and no-ibss flags had been consolidated in this commit: https://patchwork.kernel.org/project/linux-wireless/patch/1382376158-25586-2-git-send-email-mcgrof@do-not-panic.com/ This is a use case that might see a benefit in splitting the two again. But isn't that what PTMP-ONLY is for? Although, they mention at one place that PTMP-ONLY isn't quite being used in the code as of now. Some more mentions: https://medium.com/@renaudcerrato/how-to-build-your-own-wireless-router-from-scratch-part-3-d54eecce157f https://www.spinics.net/lists/linux-wireless/msg124066.html On Mon, Dec 7, 2020 at 5:33 AM Seth Forshee <seth.forshee@canonical.com> wrote: > > On Sat, Dec 05, 2020 at 09:24:03PM +0100, b.K.il.h.u+tigbuh@gmail.com wrote: > > Thanks for double checking. Honestly, I've only spent a few hours > > skimming through the document and haven't read it through all the way. > > > > Agreed that both bandwidths should probably be upped to 160. > > > > Considering § 15.407 (a)(3)(v): shouldn't the flag `PTMP-ONLY` > > already signal this infrastructure-mode only restriction? I think > > sending a probe request frame before connecting may be considered a > > "brief message", and NO-IR would even disallow that. Also, if we added > > NO-IR, wouldn't that close the band for AP's running Linux as well? > > But it's a brief message "after detecting a signal that confirms that an > access point is operating on a particular channel." I think that implies > a passive scan, then sending an association request only after seeing a > beacon from the AP on the channel. I could be wrong though; my memory on > the 802.11 protocol is rusty and out of date. > > Thanks, > Seth > > > > > Other than deciding the above questions, should we get back to > > finishing this patch after publication sometime next year? There may > > be a chance for it to change until then. > > > > On Fri, Dec 4, 2020 at 4:11 PM Seth Forshee <seth.forshee@canonical.com> wrote: > > > > > > On Thu, Dec 03, 2020 at 11:40:30PM +0100, bkil wrote: > > > > The new band is called U-NII-4. > > > > > > The report states in paragraph 203 that the order is effective 60 days > > > from publication in the Federal Register, and it looks like they haven't > > > even been published in the Federal Register yet. We will need to wait > > > for the rules to go into effect before applying any updates. > > > > > > > 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 think it should be sufficient to set the bandwidth of both 5730-5850 > > > and 5850-5895 to 160 MHz with AUTO-BW. The kernel will see the AUTO-BW > > > flags and calculate a combined rule where 160 MHz is allowed, and for > > > the original rules any bandwidth exceeding the available bandwidth of > > > the rule will be disallowed. > > > > > > > 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. > > > > > > I believe we have an additional requirement from § 15.407 (a)(3)(v): > > > > > > In the 5.850-5.895 GHz band, client devices must operate under the > > > control of an indoor access point. In all cases, an exception exists > > > for transmitting brief messages to an access point when attempting to > > > join its network after detecting a signal that confirms that an access > > > point is operating on a particular channel. > > > > > > This sounds like a requirement for passive scanning, if so the range > > > should also have the NO-IR flag. > > > > > > Thanks, > > > Seth > > > > > > > > > > > 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..e6dd063 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 @ 80), (30), AUTO-BW > > > > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > > > > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > > > > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW > > > > # 60g band > > > > # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf > > > > # channels 1-6 EIRP=40dBm(43dBm peak)
On Mon, Dec 07, 2020 at 11:10:41AM +0100, b.K.il.h.u+tigbuh@gmail.com wrote: > Indeed your logic seems reasonable regarding passive scanning. > However, I'm only looking at it from a wireless-regdb perspective: > this seems to be the first NO-IR directive in the database other than > for the "world" domain, and I thought that NO-IR is more of a thing > that would apply for client devices having no clue where they are, but > wouldn't adding NO_IR here keep hostapd from enabling an AP on such a > channel? Here's some documentation on this: > > https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules#beacon_hints > > I see that passive-scan and no-ibss flags had been consolidated in this commit: > > https://patchwork.kernel.org/project/linux-wireless/patch/1382376158-25586-2-git-send-email-mcgrof@do-not-panic.com/ > > This is a use case that might see a benefit in splitting the two > again. But isn't that what PTMP-ONLY is for? Although, they mention at > one place that PTMP-ONLY isn't quite being used in the code as of now. I'm not sure how hostapd treats NO-IR, but even ibss seems likely to be off limits given the wording as it is still a point-to-point mode. NO-IR is the only thing which restricts active scanning or ibss in the kernel. If it also restricts AP mode in hostapd, then we currently have no flag to enforce passive scanning without also restricting AP mode. And yes, PTMP-ONLY is essentially unused in the kernel so it likely has no real impact. Thanks, Seth > > Some more mentions: > https://medium.com/@renaudcerrato/how-to-build-your-own-wireless-router-from-scratch-part-3-d54eecce157f > https://www.spinics.net/lists/linux-wireless/msg124066.html > > On Mon, Dec 7, 2020 at 5:33 AM Seth Forshee <seth.forshee@canonical.com> wrote: > > > > On Sat, Dec 05, 2020 at 09:24:03PM +0100, b.K.il.h.u+tigbuh@gmail.com wrote: > > > Thanks for double checking. Honestly, I've only spent a few hours > > > skimming through the document and haven't read it through all the way. > > > > > > Agreed that both bandwidths should probably be upped to 160. > > > > > > Considering § 15.407 (a)(3)(v): shouldn't the flag `PTMP-ONLY` > > > already signal this infrastructure-mode only restriction? I think > > > sending a probe request frame before connecting may be considered a > > > "brief message", and NO-IR would even disallow that. Also, if we added > > > NO-IR, wouldn't that close the band for AP's running Linux as well? > > > > But it's a brief message "after detecting a signal that confirms that an > > access point is operating on a particular channel." I think that implies > > a passive scan, then sending an association request only after seeing a > > beacon from the AP on the channel. I could be wrong though; my memory on > > the 802.11 protocol is rusty and out of date. > > > > Thanks, > > Seth > > > > > > > > Other than deciding the above questions, should we get back to > > > finishing this patch after publication sometime next year? There may > > > be a chance for it to change until then. > > > > > > On Fri, Dec 4, 2020 at 4:11 PM Seth Forshee <seth.forshee@canonical.com> wrote: > > > > > > > > On Thu, Dec 03, 2020 at 11:40:30PM +0100, bkil wrote: > > > > > The new band is called U-NII-4. > > > > > > > > The report states in paragraph 203 that the order is effective 60 days > > > > from publication in the Federal Register, and it looks like they haven't > > > > even been published in the Federal Register yet. We will need to wait > > > > for the rules to go into effect before applying any updates. > > > > > > > > > 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 think it should be sufficient to set the bandwidth of both 5730-5850 > > > > and 5850-5895 to 160 MHz with AUTO-BW. The kernel will see the AUTO-BW > > > > flags and calculate a combined rule where 160 MHz is allowed, and for > > > > the original rules any bandwidth exceeding the available bandwidth of > > > > the rule will be disallowed. > > > > > > > > > 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. > > > > > > > > I believe we have an additional requirement from § 15.407 (a)(3)(v): > > > > > > > > In the 5.850-5.895 GHz band, client devices must operate under the > > > > control of an indoor access point. In all cases, an exception exists > > > > for transmitting brief messages to an access point when attempting to > > > > join its network after detecting a signal that confirms that an access > > > > point is operating on a particular channel. > > > > > > > > This sounds like a requirement for passive scanning, if so the range > > > > should also have the NO-IR flag. > > > > > > > > Thanks, > > > > Seth > > > > > > > > > > > > > > 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..e6dd063 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 @ 80), (30), AUTO-BW > > > > > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > > > > > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > > > > > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW > > > > > # 60g band > > > > > # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf > > > > > # channels 1-6 EIRP=40dBm(43dBm peak)
On Thu, Dec 03, 2020 at 11:40:30PM +0100, 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> I'm not sure why this was delayed, but it looks like it has finally gone into effect as of June 2: https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band We discussed some of the details before. I'm reading over it again to refresh my memory, so let's revisit the changes I think are required, below. > --- > db.txt | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/db.txt b/db.txt > index c71a03a..e6dd063 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 @ 80), (30), AUTO-BW > + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 > + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients > + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW I think we concluded previously that both 5730-5850 and 5850-5895 should have a max bandwidth of 160 MHz to permit use of 160 MHz across these channels. We also discussed using NO-IR for 5850-5895. The regulations forbid active scans, and PMTP-ONLY does not prevent them. NO-IR appears to be the only option which conforms to this restriction, though that will also block running an AP in this range. I also read the max EIRP for clients as 30 dBm without any TPC requirement. Did I overlook something which limits the EIRP to 27 dBm? Thanks, Seth
> On Tue, Jun 8, 2021 at 5:47 PM Seth Forshee <seth.forshee@canonical.com> wrote: > I think we concluded previously that both 5730-5850 and 5850-5895 should > have a max bandwidth of 160 MHz to permit use of 160 MHz across these > channels. > Yes. > We also discussed using NO-IR for 5850-5895. The regulations forbid > active scans, and PMTP-ONLY does not prevent them. NO-IR appears to be > the only option which conforms to this restriction, though that will > also block running an AP in this range. > So we would not be able to operate an OpenWrt or other Linux-based AP, while other vendors would be allowed to do this? How is this acceptable? How does this help in liberating the band? > I also read the max EIRP for clients as 30 dBm without any TPC > requirement. Did I overlook something which limits the EIRP to 27 dBm? > The 27 dBm EIRP is needed for 20 MHz operation due to spectral density requirements. Is my information correct that regdb has no notion of specifying a separate limit for spectral density? (If it did, we might be able to double the EIRP for 2.4GHz of 10MHz channels) I have summarized the reasoning in a comment of the original patch, but let me cite it here then (copied from the more recent link you have now given): > "(iii) For client devices operating under the control of an indoor access point in the 5.850-5.895 GHz band, the maximum power spectral density must not exceed 14 dBm e.i.r.p. in any 1-megahertz band, and the maximum e.i.r.p. over the frequency band of operation must not exceed 30 dBm." > "the Commission limited indoor access point EIRP spectral density to 20 dBm/MHz with a maximum EIRP of 36 dBm over the bandwidth of operation (e.g., 33 dBm/20 MHz and 36 dBm/40 MHz)" > "To keep the potential for causing harmful interference low, the Commission required client devices to operate under the control of an access point, and limited client device's power spectral density and maximum transmit power to 6 dB below the power permitted for the access point."
I've been on vacation; sorry for the delay. On Wed, Jun 30, 2021 at 05:17:37PM +0200, b.K.il.h.u+tigbuh@gmail.com wrote: > > On Tue, Jun 8, 2021 at 5:47 PM Seth Forshee <seth.forshee@canonical.com> wrote: > > I think we concluded previously that both 5730-5850 and 5850-5895 should > > have a max bandwidth of 160 MHz to permit use of 160 MHz across these > > channels. > > > > Yes. > > > We also discussed using NO-IR for 5850-5895. The regulations forbid > > active scans, and PMTP-ONLY does not prevent them. NO-IR appears to be > > the only option which conforms to this restriction, though that will > > also block running an AP in this range. > > > > So we would not be able to operate an OpenWrt or other Linux-based AP, > while other vendors would be allowed to do this? How is this > acceptable? How does this help in liberating the band? We're allowing clients which use the rules in the db to connect to APs in the band. We may be able to get APs supported later on by getting changes to break up passive-scan and no-IR. But with what we have to work with right now, and based on my interpretation of the rules, I think this is the best we can do currently. > > I also read the max EIRP for clients as 30 dBm without any TPC > > requirement. Did I overlook something which limits the EIRP to 27 dBm? > > > > The 27 dBm EIRP is needed for 20 MHz operation due to spectral density > requirements. Is my information correct that regdb has no notion of > specifying a separate limit for spectral density? (If it did, we might > be able to double the EIRP for 2.4GHz of 10MHz channels) > > I have summarized the reasoning in a comment of the original patch, > but let me cite it here then (copied from the more recent link you > have now given): > > > "(iii) For client devices operating under the control of an indoor access point in the 5.850-5.895 GHz band, the maximum power spectral density must not exceed 14 dBm e.i.r.p. in any 1-megahertz band, and the maximum e.i.r.p. over the frequency band of operation must not exceed 30 dBm." > > "the Commission limited indoor access point EIRP spectral density to 20 dBm/MHz with a maximum EIRP of 36 dBm over the bandwidth of operation (e.g., 33 dBm/20 MHz and 36 dBm/40 MHz)" > > "To keep the potential for causing harmful interference low, the Commission required client devices to operate under the control of an access point, and limited client device's power spectral density and maximum transmit power to 6 dB below the power permitted for the access point." Ah, thanks, I had forgotten about this. Seth
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..e6dd063 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 @ 80), (30), AUTO-BW + # https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 + # max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients + (5850 - 5895 @ 40), (27), NO-OUTDOOR, PTMP-ONLY, AUTO-BW # 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(-)