Subject: [Capwap] 802.11d / 802.11h support

From: Puneet <[email-masked]>
Date: Fri, 14 Apr 2006 00:28:21 -0700

1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this
element is fixed at 8 bytes, but if there are multiple, disjoint bands that
are supported in the regulatory domain does the AC use multiple such
elements? It might be cleaner to make the length of this element variable,
and allow multiple triplets <first_channel,num_channel,max_power) to be
added one after the other. (like the Country-Information element in 802.11d)

2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything
on its own or is the channel switching etc controlled by the AC? In either
case there might be a need for message elements with which the WTP to report
the detection of radar to the AC.

Thanks,
Puneet.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 18 Apr 2006 19:13:43 -0700

Hi Puneet,

This is assigned to a new issue, 104.

All- comments, discussion please.

Thanks,

Dorothy Stanley

On 4/14/06, Puneet <[email-masked]> wrote:
>
> 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of
> this element is fixed at 8 bytes, but if there are multiple, disjoint bands
> that are supported in the regulatory domain does the AC use multiple such

---

From: Partha Narasimhan <[email-masked]>
Date: Tue, 18 Apr 2006 20:25:39 -0700 (PDT)

For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need 
to re-define something that is already defined in 802.11? This is probably 
true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a 
corresponding 802.11 definition. There is code that exists to parse 802.11 
IEs elsewhere in the WTP, so we get code reuse too. :-)

For #2, my vote would be for the WTP to switch channels on detecting radar 
and notify the AC of the radar detect and the resulting channel change 
events. This keeps it simple and WTPs have the ability to detect radar 
already.

Thanks
partha

On Tue, 18 Apr 2006, Dorothy Stanley wrote:

> 	1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets <first_channel,num_channel,max_power) to be added one after the other. (like the Country-Information element in 802.11d)
>
> 	2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC.
>
> 	Thanks,
> 	Puneet.
>
>
> 	http://lists.frascone.com/mailman/listinfo/capwap <http://lists.frascone.com/mailman/listinfo/capwap>
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 18 Apr 2006 22:43:12 -0700 (PDT)

HI,

For #2, I believe that a WTP should only report the detection
or radar, and let the AC switch channels (and make
any other configuration changes). Otherwise, you may end
up with a nonstable RF environment.

Regards,
/david t. perkins

---

From: Partha Narasimhan <[email-masked]>
Date: Wed, 19 Apr 2006 22:56:19 -0700 (PDT)

David

Could you please explain how you think we may end up with an "nonstable RF 
environment"?

There is more to supporting 11h than merely changing channels on detecting 
radar. The "AP" has to maintain state on every channel that it detected 
radar on for a certain period of time following the radar event. There are 
also strict time constraints on how soon one has to get off the channel 
following the detection of radar. Your proposal would split this state 
between the two entities. We need to work at modifying the CAPWAP state 
machine and/or messages to ensure the two are in sync.

My vote is still for the simpler mechanism of letting the WTP manage radar 
detection and the subsequent channel change.

Thanks
partha

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 20 Apr 2006 08:13:53 -0700 (PDT)

HI,

There are 3 cases that I know of that affect channel (power
and other configurations assignments related to the 
RF environment). These include:
  1) assignments to other WTPs controlled by the
     AC (or in future CAPWAP versions - cooperating
     ACs). WTPs in a "WiFi cloud" must have coordinated
     configuration assignments so that they do not
     interfer with each other and provide an acceptable
     (and ideally, optimal) RF environment for the
     STAs that communicate with the WTPs. The AC(s)
     have the "big picture" about the RF environment
     using data from the WTPs, possibly RF monitors,
     and possibly input from the "WiFi cloud" designer.
  2) assignments to RF devices (APs and WTPs) controlled
     by neighbors. In many environments, "WiFi clouds"
     managed by different organizations have overlaps.
     To allow peaceful coexistance, the organizations
     must create "power and channel sharing agreements".
     In configuring WTPs controlled by AC(s), such
     agreements would be called "configuration
     setting  pollicies". These need to be factored
     into the process when the AC(s) determine
     the configuration assignments for the
     WTPs in a "WiFi cloud".
  3) RF interference by nonWiFi devices and by
     rogues.

An individual WTP does not "know" the big picture
and if it changes it's configuration assignments
without coordination by the AC, then it's changes
could interfer with other WTPs (which if they changed
could affect other WTPs, etc), or could violate
policy (such as use a channel reserved for a neighbor),
or result in degraded operation (using configuration
assignements that result in RF interference). 

Regards,
/david t. perkins

---

From: Puneet <[email-masked]>
Date: Thu, 20 Apr 2006 10:17:25 -0700

Partha,

for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE
is what will finally go out in the beacons/probe-responses. No need for the
WTP to have to translate and construct that IE.

for #2 it might be simpler if the WTP reports radar to the AC, and the AC
makes the decision about what channel to jump to. As David also mentions,
the channel to move to might be determined by policy or by some
channel-selection logic on the AC which takes into account neighbouring
channels etc. A 'future' channel can either be provided to the WTP at
configuration time (if the timing constraints seem so tight), or as soon as
it reports radar.

Thanks,
Puneet

On 4/18/06, Partha Narasimhan <[email-masked]> wrote:
> >       1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The
> length of this element is fixed at 8 bytes, but if there are multiple,
> disjoint bands that are supported in the regulatory domain does the AC use
> multiple such elements? It might be cleaner to make the length of this
> element variable, and allow multiple triplets
> <first_channel,num_channel,max_power) to be added one after the other. (like
> the Country-Information element in 802.11d)
> >
> >       2. How does CAPWAP plan to support 802.11h? Does the WTP handle
> everything on its own or is the channel switching etc controlled by the AC?
> In either case there might be a need for message elements with which the WTP
> to report the detection of radar to the AC.
> >
> >       Thanks,
> >       Puneet.
> >
> >
> >       http://lists.frascone.com/mailman/listinfo/capwap <
> http://lists.frascone.com/mailman/listinfo/capwap>
> >