mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Rostislav Lisovy <lisovy@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Liraz Perelmooter <liraz.perelmooter@intel.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Michal Sojka <sojkam1@fel.cvut.cz>,
	s.sander@nordsys.de, jan-niklas.meier@volkswagen.de,
	Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>,
	"wireless-regdb@lists.infradead.org" 
	<wireless-regdb@lists.infradead.org>,
	Michael Green <green@qti.qualcomm.com>
Subject: Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only
Date: Tue, 10 Jun 2014 14:16:11 -0700	[thread overview]
Message-ID: <CAB=NE6Wi+SLPSuGiGeFpJO4FVHfHpSpsDfsccAi9cPyhmL6NwQ@mail.gmail.com> (raw)
In-Reply-To: <1402323702.11505.18.camel@umadbro>

On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy <lisovy@gmail.com> wrote:
> Dear Luis;
> Thank you for the introduction in the wireless-regdb mailing-list.
>
> On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote:
>> Rostislav, can you provide documentation references which would
>> clarify
>> the stance on 802.11p and restrictions for only allowing  OCB mode?
>
> If I may cite the 802.11-2012 standard:
> -- 1st Quote
> 4.3.11 STA transmission of data frames outside the context of a BSS
>
> Communication of data frames when dot11OCBActivated is true might take
> place in a frequency band that is dedicated for its use, and such a band
> might require licensing depending on the regulatory domain. A STA for
> which dot11OCBActivated is true initially transmits and receives on a
> channel known in advance, either through regulatory designation or some
> other out-of-band communication.
> -- End of quote

OK the spec does not rule out communication on that special band for
regular operation as such that special band is mentioned in the
context of OCB communication, but it does say that the frequency range
may be licensed. As it stands the public wireless-regdb only covers
unlicensed frequency ranges, but it obviously can support licensed
frequency ranges, just that the distribution mechanism and integration
of the wireless-regdb files then would have to be done separately
through separate distributors -- ie, not upstream. If the OCB bands
are unlicensed then we can surely add them to wireless-regdb, however
it remains unclear if those bands are unlicensed if we can use them
for regular non OCB communication.

Follow this logic to move forward then:

  * Poke folks to see if the US band for OCB is licensed or unlicensed
  * Poke folks to see if the EU band for OCB is licensed or unlicensed

  * If the bands are licensed then the wireless-regdb changes that
would be needed imply that a wireless-regdb needs to be provided to
whatever customer by whomever is licensing that entity for usage of
that band, that is, we upstream can be removed from the equation of
the distribution. The upstream kernel however would require a flag for
frequency ranges for OCB frequency ranges. Although the regulatory
classes specify a few for the US and EU, this can likely change. I
forget if the regulatory class can be interpreted through IEs, if so
and if the specification is going to remain static I can envision the
ability to hard code the OCB frequency ranges upstream but you'd then
need to parse these things.

  * If the bands are *not licensed* there is one corner case that I
still think should be reviewed by regulatory folks: having an OCB
frequency range unlicensed under the current reading of the
specification of 802.11-2012 means that 802.11 devices *can* use them
for OCB, however if OCB is not enabled on the device it seems to be
that OCB bands can be used for non OCB communication. Furthermore
4.3.11 seems to be saying that it is only optional to use a dedicated
frequency for OCB, OCB can happen on other frequency ranges.

> -- 2nd Quote
> Annex E (normative) Country elements and operating classes
> E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz)
> ...
> STAs shall have dot11OCBActivated set to true.

So all STAs in the US wil have OCB activated? I fail to understand how
Annex E should be read in the context of operating classes.

> E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz)
> STAs shall have dot11OCBActivated set to true.

Ditto.


  Luis

  reply	other threads:[~2014-06-10 21:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-30 16:56 [RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode Rostislav Lisovy
2014-05-30 16:56 ` [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only Rostislav Lisovy
2014-06-03 20:01   ` Johannes Berg
2014-06-03 22:18     ` Luis R. Rodriguez
2014-06-09 14:21       ` Rostislav Lisovy
2014-06-10 21:16         ` Luis R. Rodriguez [this message]
2014-08-01 14:00           ` Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only) Michal Sojka
2014-09-05 21:52             ` Luis R. Rodriguez
2014-05-30 16:56 ` [RFC 2/4] cfg80211: Add new interface type for OCB mode Rostislav Lisovy
2014-06-03 20:10   ` Johannes Berg
2014-05-30 16:56 ` [RFC 3/4] nl80211: Do not ignore 5/10MHz wide channels in nl80211_send_chandef() Rostislav Lisovy
2014-05-30 16:56 ` [RFC 4/4] mac80211: OCB mode interface configuration Rostislav Lisovy
2014-06-03 20:13   ` Johannes Berg
2014-06-03 20:15 ` [RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode Johannes Berg
2014-06-09 14:09   ` Rostislav Lisovy
2014-06-10 16:43     ` Johannes Berg

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='CAB=NE6Wi+SLPSuGiGeFpJO4FVHfHpSpsDfsccAi9cPyhmL6NwQ@mail.gmail.com' \
    --to=mcgrof@suse.com \
    --cc=green@qti.qualcomm.com \
    --cc=jan-niklas.meier@volkswagen.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=liraz.perelmooter@intel.com \
    --cc=lisovy@gmail.com \
    --cc=rostislav.lisovy@fel.cvut.cz \
    --cc=s.sander@nordsys.de \
    --cc=sojkam1@fel.cvut.cz \
    --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

all inboxes | Powered by JetHome®