diff mbox

[v3,1/6] cfg80211: Add indoor only and GO concurrent channel attributes

Message ID 1390818118-27261-2-git-send-email-ilan.peer@intel.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Peer, Ilan Jan. 27, 2014, 10:21 a.m. UTC 
From: David Spinadel <david.spinadel@intel.com>

The FCC are clarifying some soft configuration requirements,
which among other include the following:

1. Indoor operation, where a device can use channels requiring indoor
   operation, subject to that it can guarantee indoor operation,
   i.e., the device is connected to AC Power or the device is under
   the control of a local master that is acting as an AP and is
   connected to AC Power.
2. Concurrent GO operation, where devices may instantiate a P2P GO
   while they are under the guidance of an authorized master. For example,
   on a channel on which a BSS is connected to an authorized master, i.e.,
   with DFS and radar detection capability in the UNII band.

See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122

Add support for advertising Indoor-only and GO-Concurrent channel
properties.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
 include/net/cfg80211.h       |   23 +++++++++++++++++++++++
 include/uapi/linux/nl80211.h |    7 +++++++
 net/wireless/nl80211.c       |    6 ++++++
 net/wireless/reg.c           |    2 ++
 4 files changed, 38 insertions(+)

Comments

Luis R. Rodriguez Feb. 18, 2014, 10:49 p.m. UTC | #1 
On Mon, Jan 27, 2014 at 12:21:53PM +0200, Ilan Peer wrote:
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index b1f84b0..dbc5490 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -109,6 +109,27 @@ enum ieee80211_band {
>   *	channel as the control or any of the secondary channels.
>   *	This may be due to the driver or due to regulatory bandwidth
>   *	restrictions.
> + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
> + *	A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be used when
> + *	there is a clear assessment that the device is operating in an indoor
> + *	surroundings, i.e., it is connected to AC power (and not through
> + *	portable DC inverters)

Curious, what are the plans to avoid the situation of portable DC
inverters from being used in this case ? Stating that is in
the documentation alludes that this is possible in userspace.

Is it?

> or is under the control of a master that is
> + *	acting as an AP and is connected to AC power.
> + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
> + *	it's connected concurrently to a BSS on the same channel on 2.4 or
> + *	to a channel in the same UNII band on 5.2.

What do you mean "on 5.2" ? Maybe just "the 5 GHz band" would be better
if this is not UNII specific. If the rule applies to a UNII band then
mentioning the band name nomenclature would make it clearer, ie, UNII-1,
or UNII-2. If this flag could later be used by other 5 GHz UNII bands then
making it in the documentation UNII band agnostic and just using 5 GHz
would suffice, while your handler in code adjusts as regulations change.

> + *	Instantiating a GO on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
> + *	can be done when there is a clear assessment that the device is
> + *	operating under the guidance of an authorized master, i.e., setting up a
> + *	GO while the device is also connected to an AP with DFS and radar
> + *	detection on the UNII band (however, this example does not imply that
> + *	all channels marked with IEEE80211_CHAN_RADAR must also be marked with
> + *	IEEE80211_CHAN_GO_CONCURRENT and vise versa).

Your mentioning of DFS here makes things a bit confusing. We should be
distinguishing between the case of a device beign associated to on a BSS
where the AP is on a DFS channel, and the case where the AP is not on
a DFS channel. Are you saying that if IEEE80211_CHAN_GO_CONCURRENT is
enabled on a channel that also has IEEE80211_CHAN_RADAR that the device
can start GO on the same channel if it *doesn't support DFS itself* if
its associated to a real AP, which presumably supports DFS? If so
consider then a third GO which would associate to the secondary GO,
we now have a link of 3 devices and an inherent delay can be created
letting a master device do things. How do we avoid latency issues
in communication in this type of setup?

If IEEE80211_CHAN_GO_CONCURRENT is meant only for channels that do not
have IEEE80211_CHAN_RADAR that makes it simpler but I think you were
trying to clarify that daisy chaning trust on the root AP is valid.

Please clarify both use cases on the documentation.

> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 91054fd..06440ac 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2304,6 +2304,11 @@ enum nl80211_band_attr {
>   * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
>   *	using this channel as the primary or any of the secondary channels
>   *	isn't possible
> + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
> + *	on this channel in current regulatory domain.
> + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
> + *      channel if it's connected concurrently to a BSS on the same channel on
> + *      2.4 or to a channel in the same UNII band on 5.2.

Same UNII band clarification applies here.

  Luis
Peer, Ilan Feb. 19, 2014, 2:44 p.m. UTC | #2 
Hi Luis,

Thanks for the comments.

Ilan.

> > + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on
> this channel.
> > + *	A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be
> used when
> > + *	there is a clear assessment that the device is operating in an indoor
> > + *	surroundings, i.e., it is connected to AC power (and not through
> > + *	portable DC inverters)
> 
> Curious, what are the plans to avoid the situation of portable DC inverters
> from being used in this case ? Stating that is in the documentation alludes
> that this is possible in userspace.
> 
> Is it?
> 

The motivation here was to allow this in cases that the device is truly an indoor device such as media center etc. I am not aware of plans to avoid such situations. Will take this with our regulatory people.

> > or is under the control of a master that is
> > + *	acting as an AP and is connected to AC power.
> > + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this
> channel if
> > + *	it's connected concurrently to a BSS on the same channel on 2.4 or
> > + *	to a channel in the same UNII band on 5.2.
> 
> What do you mean "on 5.2" ? Maybe just "the 5 GHz band" would be better
> if this is not UNII specific. If the rule applies to a UNII band then mentioning
> the band name nomenclature would make it clearer, ie, UNII-1, or UNII-2. If
> this flag could later be used by other 5 GHz UNII bands then making it in the
> documentation UNII band agnostic and just using 5 GHz would suffice, while
> your handler in code adjusts as regulations change.
> 

As far as I understand the concept of UNII bands, a UNII band is a group of channels/frequencies that share the same regulatory rules. Thus, if we are currently connected to a BSS on a channel in a specific UNII band, we can deduce that operating on all the channels in the same UNII band is allowed as these channels share the same operating rules as the channel we are currently connected to on the BSS interface. I'll rephrase the comment to better express so.

> > + *	Instantiating a GO on a channel marked with
> IEEE80211_CHAN_GO_CONCURRENT
> > + *	can be done when there is a clear assessment that the device is
> > + *	operating under the guidance of an authorized master, i.e., setting
> up a
> > + *	GO while the device is also connected to an AP with DFS and radar
> > + *	detection on the UNII band (however, this example does not imply
> that
> > + *	all channels marked with IEEE80211_CHAN_RADAR must also be
> marked with
> > + *	IEEE80211_CHAN_GO_CONCURRENT and vise versa).
> 
> Your mentioning of DFS here makes things a bit confusing. We should be
> distinguishing between the case of a device beign associated to on a BSS
> where the AP is on a DFS channel, and the case where the AP is not on a DFS
> channel. Are you saying that if IEEE80211_CHAN_GO_CONCURRENT is
> enabled on a channel that also has IEEE80211_CHAN_RADAR that the device
> can start GO on the same channel if it *doesn't support DFS itself* if its
> associated to a real AP, which presumably supports DFS? If so consider then a
> third GO which would associate to the secondary GO, we now have a link of 3
> devices and an inherent delay can be created letting a master device do
> things. How do we avoid latency issues in communication in this type of
> setup?
> 
> If IEEE80211_CHAN_GO_CONCURRENT is meant only for channels that do
> not have IEEE80211_CHAN_RADAR that makes it simpler but I think you were
> trying to clarify that daisy chaning trust on the root AP is valid.
> 
> Please clarify both use cases on the documentation.

Yep this required more clarification: the GO concurrent relaxation is intended for the NO_IR flag and not for the RADAR flag. If RADAR is set then a GO cannot be instantiated. I will clarify this in the documentation.

> 
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h index 91054fd..06440ac 100644
> > --- a/include/uapi/linux/nl80211.h
> > +++ b/include/uapi/linux/nl80211.h
> > @@ -2304,6 +2304,11 @@ enum nl80211_band_attr {
> >   * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not
> 80+80) channel
> >   *	using this channel as the primary or any of the secondary channels
> >   *	isn't possible
> > + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is
> permitted
> > + *	on this channel in current regulatory domain.
> > + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is
> allowed on this
> > + *      channel if it's connected concurrently to a BSS on the same channel
> on
> > + *      2.4 or to a channel in the same UNII band on 5.2.
> 
> Same UNII band clarification applies here.
> 
>   Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b1f84b0..dbc5490 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -109,6 +109,27 @@  enum ieee80211_band {
  *	channel as the control or any of the secondary channels.
  *	This may be due to the driver or due to regulatory bandwidth
  *	restrictions.
+ * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
+ *	A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be used when
+ *	there is a clear assessment that the device is operating in an indoor
+ *	surroundings, i.e., it is connected to AC power (and not through
+ *	portable DC inverters) or is under the control of a master that is
+ *	acting as an AP and is connected to AC power.
+ * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
+ *	it's connected concurrently to a BSS on the same channel on 2.4 or
+ *	to a channel in the same UNII band on 5.2.
+ *	Instantiating a GO on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
+ *	can be done when there is a clear assessment that the device is
+ *	operating under the guidance of an authorized master, i.e., setting up a
+ *	GO while the device is also connected to an AP with DFS and radar
+ *	detection on the UNII band (however, this example does not imply that
+ *	all channels marked with IEEE80211_CHAN_RADAR must also be marked with
+ *	IEEE80211_CHAN_GO_CONCURRENT and vise versa).
+ *
+ *	See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
+ *	for more information on the FCC description of the relaxations allowed
+ *	by IEEE80211_CHAN_INDOOR_ONLY and IEEE80211_CHAN_GO_CONCURRENT.
+ *
  */
 enum ieee80211_channel_flags {
 	IEEE80211_CHAN_DISABLED		= 1<<0,
@@ -120,6 +141,8 @@  enum ieee80211_channel_flags {
 	IEEE80211_CHAN_NO_OFDM		= 1<<6,
 	IEEE80211_CHAN_NO_80MHZ		= 1<<7,
 	IEEE80211_CHAN_NO_160MHZ	= 1<<8,
+	IEEE80211_CHAN_INDOOR_ONLY	= 1<<9,
+	IEEE80211_CHAN_GO_CONCURRENT	= 1<<10,
 };
 
 #define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 91054fd..06440ac 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2304,6 +2304,11 @@  enum nl80211_band_attr {
  * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
  *	using this channel as the primary or any of the secondary channels
  *	isn't possible
+ * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
+ *	on this channel in current regulatory domain.
+ * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
+ *      channel if it's connected concurrently to a BSS on the same channel on
+ *      2.4 or to a channel in the same UNII band on 5.2.
  * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
  *	currently defined
  * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -2322,6 +2327,8 @@  enum nl80211_frequency_attr {
 	NL80211_FREQUENCY_ATTR_NO_HT40_PLUS,
 	NL80211_FREQUENCY_ATTR_NO_80MHZ,
 	NL80211_FREQUENCY_ATTR_NO_160MHZ,
+	NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
+	NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
 
 	/* keep last */
 	__NL80211_FREQUENCY_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d0afd82..3c1587f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -608,6 +608,12 @@  static int nl80211_msg_put_channel(struct sk_buff *msg,
 		if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) &&
 		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ))
 			goto nla_put_failure;
+		if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) &&
+		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY))
+			goto nla_put_failure;
+		if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
+		    nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
+			goto nla_put_failure;
 	}
 
 	if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9b897fc..82e387c 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -776,6 +776,8 @@  static u32 map_regdom_flags(u32 rd_flags)
 		channel_flags |= IEEE80211_CHAN_RADAR;
 	if (rd_flags & NL80211_RRF_NO_OFDM)
 		channel_flags |= IEEE80211_CHAN_NO_OFDM;
+	if (rd_flags & NL80211_RRF_NO_OUTDOOR)
+		channel_flags |= IEEE80211_CHAN_INDOOR_ONLY;
 	return channel_flags;
 }