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

[Bob O'Hara (boohara) (boohara]

Puneet,

 

As you point out, the regulatory requirements change with the band of operation and with time.  Whatever we build into the protocol, the WTP and its vendor will always be responsible to behave properly, according to the regulations currently in force.

 -Bob
 

 

---

From: Puneet [mailto:pb.ietf [at] gmail.com]
Sent: Friday, April 21, 2006 2:43 AM
To: Bob O'Hara (boohara)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] 802.11d / 802.11h support

For the channel move the WTP can probably handle things on its own 
(detect radar, hop to a new channel and inform the AC before and after it 
changes channels), but 802.11h also requires "testing channel for radar before 
using it". Given a channel and power level from an AC, how does the WTP decide 
if it needs to carry out a test or not?

From what I understand the 
DFS/TPC requirements (& consequently the need to test channels before use) 
change both per-band as well as with time in different regulatory domains. Would 
the WTP have to track all those regulatory requirements on its own? If so, how 
is this information updated? I would think it would be updated by the AC, either 
by downloading a new image to the WTP, or as part of configuration, again 
bringing the AC into this...

thanks,
Puneet

On 4/20/06, Bob O'Hara (boohara) <boohara [at] cisco.com> wrote:

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
>
>
>
>
>

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

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