Subject: [Capwap] suggestion for the section 4.4 and 11.9 of draft 02

From: young <[email-masked]>
Date: Tue, 01 Aug 2006 11:01:41 +0530

Hi, Pat Calhoun

I think that section 4.4 should add more common parameter to make CAPWAP
having more strength to adapt to any wireless

technology.

I have the following suggestion for section 4.4 and 11.9 of draft 02.

1) 4.4.38.  WTP Radio Information

 As the section should be work for any wireless implement, I suggest the
following value

 should be moved to 802.11 binding. The value should be defined by wireless
technology binding.

      1 - 802.11b:  An IEEE 802.11b radio.

      2 - 802.11a:  An IEEE 802.11a radio.

      4 - 802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n radio.

2) 11.9.18.  IEEE 802.11 Tx Power

I think it could be moved to the section 4.4, as channel and Tx power are
common parameters for RF management.

3)  Add "WTP radio channel"

As per 2), we could define a TLV to report current channel (AP to AC) or to
configure channel (AC to AP).

Now,. 11.9.12.  IEEE 802.11 OFDM Control and 11.9.5.  IEEE 802.11 Direct
Sequence Control

has channel configuration information. 

But I think that a specific TLV for it is better. By this way, 4.4 will
provide

more common parameter for any wireless technology.

     0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    Radio ID   |    Reserved   |        Current Channel       |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4) 11.9.24.  IEEE 802.11 WTP Radio Fail Alarm Indications

I think it could be moved to the section 4.4, it could be a common event for
any wireless technology.

5) 11.9.1.  IEEE 802.11 Add WLAN

How about we rename "WLAN" as wireless service? By this way, we could
achieve abstract while make it work

for most wireless technology.

If it is ok, we could define "add wireless service, delete wireless service,
update wireless service" in the section 4.4.

Any wireless technology could add its specific parameter in the binding
section.

6) 11.9.22.  IEEE 802.11 WTP Quality of Service

As per 5), I think we could define "WTP Quality of Service"in the section
4.4.

Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality
of Service".

While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of
Service.

Regard

Richard

Huawei-3com

_________________________________________________________________
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: Mon, 28 Aug 2006 09:04:54 -0700

Richard, all,

I have opened Issue # 204, "More general wireless support" to track this.

Dorothy Stanley

On 7/31/06, young <[email-masked]> wrote:
> 1) *4.4.38.  WTP Radio Information*
>
>  should be moved to 802.11 binding. The value should be defined by
> wireless technology binding.
>
> 2) *11.9.18.  IEEE 802.11 Tx Power*
>
> As per 2), we could define a TLV to report current channel (AP to AC) or
> to configure channel (AC to AP).
>
> Now,. *11.9.12.  IEEE 802.11 OFDM Control* and *11.9.5.  **IEEE 802.11Direct Sequence Control
> *
>
> 4) *11.9.24.  IEEE 802.11 WTP Radio Fail Alarm Indications*
>
> I think it could be moved to the section 4.4, it could be a common event
> for any wireless technology.
>
>
>
> 5) *11.9.1.  IEEE 802.11 Add WLAN*
>
> If it is ok, we could define "add wireless service, delete wireless
> service, update wireless service" in the section 4.4.
>
> 6) *11.9.22.  IEEE 802.11 WTP Quality of Service*
>
> As per 5), I think we could define "*WTP Quality of Service*"in the
> section 4.4.
>
> Radio ID, Tag Packets and Queue Depth could be defined in the "*WTP
> Quality of Service*".
>
> While CWMin and so on could be defined in the *IEEE 802.11 WTP Quality of
> Service.*
>
>
>
> Regard
>
>
>
> Richard
>
> Huawei-3com
>
>
>
>
>