Subject: RE: [Capwap] 802.11d / 802.11h support

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 21 Apr 2006 10:54:16 -0700

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:[email-masked]] 
Sent: Friday, April 21, 2006 2:43 AM
To: Bob O'Hara (boohara)
Cc: [email-masked]
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) <[email-masked]> 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:[email-masked]] 
	Sent: Thursday, April 20, 2006 10:17 AM
	To: Partha Narasimhan
	Cc: [email-masked]
	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 <[email-masked]> 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 < [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.
_________________________________________________________________
		>       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 

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

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