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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 20 Apr 2006 11:57:45 -0700

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

---

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

HI,

Interesting info Bob. Given what you say below, I would suggest
that the best action is to disable the radio and inform the
AC of the event. The AC can then use it's big picture knowledge
to configure an appropriate channel (and power level and other
attributes of the WTPs that it controls).

Your info brings up a question.
That is, what are the certication requirements between ACs and WTPs
for an AC to configure the RF attributes of a WTP?

Thanks again for being on top of the regulatory issues.

Regards,
/david t. perkins

---

From: Puneet <[email-masked]>
Date: Fri, 21 Apr 2006 02:43:16 -0700

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