Capwap Mailing List: RE: 802.11d / 802.11h support

[Bob O'Hara (boohara) (boohara]

On the issue of radar detection, the proposal to have the WTP inform the AC, then have the AC make the decision about channel change will probably run into either regulatory problems or cost of certification problems, or both.  Because radar detection is a regulatory issue, it must be tested to certify a device to operate in a band requiring radar avoidance.  If the WTP defers to the AC for some part of the radar avoidance operation, certification will require that both the WTP and AC be certified as a system.

 

Given that the goal of CAPWAP is to promote multi-vendor interoperability between WTP and AC, system certification to meet radar avoidance regulatory requirements will result in one or more of the following outcomes:

1. WTPs will have to maintain a list of ACs for which they are certified to operate and meet radar avoidance requirements.

2. WTPs will have to be certified with every AC.

3. WTP certification will be extraordinarily costly.

4. Multi-vendor interoperability will be impaired.

 

I would recommend that the WTP, alone make the decision, then inform the AC when it has changed channels.

 -Bob
 

 

---

From: Puneet [mailto:pb.ietf [at] gmail.com]
Sent: Thursday, April 20, 2006 10:17 AM
To: Partha Narasimhan
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] 802.11d / 802.11h support

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 <partha [at] arubanetworks.com> wrote:

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:

> Hi Puneet,
>
> This is assigned to a new issue, 104.
>
> All- comments, discussion please.
>
> Thanks,
>
> Dorothy Stanley
>
>
> On 4/14/06, Puneet < pb.ietf [at] gmail.com> 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.
>
>
>       _________________________________________________________________
>       To unsubscribe or modify your subscription options, please visit:
>       http://lists.frascone.com/mailman/listinfo/capwap <http://lists.frascone.com/mailman/listinfo/capwap >
>
>       Archives: http://lists.frascone.com/pipermail/capwap
>
>
>
>
>