From: Seth Forshee <seth.forshee@canonical.com>
To: b.K.il.h.u+tigbuh@gmail.com
Cc: wireless-regdb <wireless-regdb@lists.infradead.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] wireless-regdb: recent FCC report and order allows 5850-5895 immediately
Date: Sun, 6 Dec 2020 22:32:58 -0600 [thread overview]
Message-ID: <X82welCPwyUV8VJw@ubuntu-x1> (raw)
In-Reply-To: <CAPuHQ=EUcsn24EoSP+PGH2H6kPROvauyJN_6RtYLXqVYW=sK-g@mail.gmail.com>
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)
next prev parent reply other threads:[~2020-12-07 4:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 22:40 [PATCH] wireless-regdb: recent FCC report and order allows 5850-5895 immediately bkil
2020-12-04 15:11 ` Seth Forshee
2020-12-05 20:24 ` b.K.il.h.u+tigbuh
2020-12-07 4:32 ` Seth Forshee [this message]
2020-12-07 10:10 ` b.K.il.h.u+tigbuh
2020-12-07 13:54 ` Seth Forshee
2021-06-08 15:47 ` Seth Forshee
2021-06-30 15:17 ` b.K.il.h.u+tigbuh
2021-06-30 16:03 ` [PATCH v2] " bkil
2021-07-06 15:51 ` Seth Forshee
2021-07-08 19:42 ` Seth Forshee
2021-08-09 20:06 ` Johannes Berg
2021-08-11 19:22 ` [wireless-regdb] " Seth Forshee
2021-07-06 15:45 ` [PATCH] " Seth Forshee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X82welCPwyUV8VJw@ubuntu-x1 \
--to=seth.forshee@canonical.com \
--cc=b.K.il.h.u+tigbuh@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=wireless-regdb@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).