Subject: RE: [Capwap] WTP statistics reports

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 23 Apr 2006 20:47:29 +0300

How many of these statistics are capwap specific? 

Dan

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Saturday, April 22, 2006 12:32 AM
> To: capwap
> Subject: [Capwap] WTP statistics reports
> 
> We've been discussing what statistics the WTP should provide 
> to the AC, and I promised to follow up after talking with 
> folks I work with. Sorry it took me longer than expected - 
> here's what we've come up with so far.
> 
> There are 802.11 (binding-specific) stats, and these should 
> probably be segregated from general stats which apply 
> regardless of radio type. However, I do think it's 
> appropriate to assume that there will always be radios, 
> regardless of the binding type. With that in mind, here's a 
> list of stats the AC might want to collect, with suggested 
> values in some cases:
> 
> WTP Stats:
> ---------
> - # reboots (total)
>   - # AC initiated reboots
>   - # reboots due to link failure
>   - # reboots due to SW failure
>   - # reboots due to HW failure
>   - # reboots due to other reasons
>   - # reboots due to unknown reasons
> 
> - last reboot cause  (suggested values below)
>   *0 - not supported
>   *1 - AC initiated
>   *2 - link failure
>   *3 - SW failure
>   *4 - HW failure
>   *5 - Other
>   *all 0xfffs - unknown
> 
> (note: "not supported" could collapse into "unknown ")
> 
> - uptime (how long has WTP been running)
> 
> --------------
> Radio stats:
> --------------
> 
> - # resets
>   - # resets caused by SW failure
>   - # resets caused by HW failure
>   - # resets caused by other reasons
>   - # resets caused by unknown reasons
> 
> - last reset cause (suggested values below)
>   *0 - not supported
>   *1 - SW failure
>   *2 - HW failure
>   *3 - Other
>   *all 0xffs - Unknown
> 
> (note: "not supported" could collapse into "unknown ")
> 
> (these next 6 may be 802.11-specific)
> - # channel changes
> - # band changes
> - # radar detects
> - # radar channel changes
> - current noise floor
> - current 11g protection status
> 
> (this one seems to generally apply to radios)
> - # config updates
> 
> ---------------------------------------------------------
> WLAN stats (is wlan an 802.11-specific concept?)
> ---------------------------------------------------------
> 
> TX stats:
> --------
> - current max tx power
> - available tx buffers
> - # frames received for transmission over this WLAN
> - # data frames received
> - # mgmt frames received
> - # multicast received
> - # frames successfully transmitted
>   - # data frames transmitted
>   - # mgmt frames transmitted
> - # rts sent
> - # cts sent
> - # beacons transmitted
> - # probe responses transmitted
> - # multicast transmitted
> - # frames dropped
>   - # frames dropped due to excessive retries
>   - # frames dropped due to buffer unavailability
>   - # frames dropped due to listern interval timeouts
>   - # multicast frames dropped
>   - # data frames dropped
>   - # mgmt frames dropped
> - # retries
> - # multiple retries
> - # fragments
> 
> RX stats:
> --------
> - rssi of the most recent frame
> - # frames received
> - # good frames received
> - # multicast received
> - # data frames received
> - # mgmt frames received
> - # probe requests received
> - # rts received
> - # cts received
> - # ps-poll received
> - # bad frames received
> - # CRC errors
> - # PHY errors
> - # decryption errors
> - # unknown errors
> - # duplicate frames
> - # fragments
> 
> --------------------------------------------------------------
> ---------
> 
> In addition to reporting these, there must be an ability to 
> reset  counters, and it might be desirable to set different 
> reporting intervals for different types of stats. For 
> example, there's not much point in reporting reboot 
> statistics every 5 minutes (if the WTP is worth anything). 
> Once those've been reported once, it may not make sense to 
> report them again unless there's a reboot.
> 
> We probably also need some concept of a 'last-reset' time or 
> reference time to denote when stats collection started (sort 
> of like stats-uptime).
> 
> Anyway, this is a start....
> 
> Scott
> 
> _________________________________________________________________
> 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

---

From: Scott G Kelly <[email-masked]>
Date: Sun, 23 Apr 2006 11:00:13 -0700

Hi Dan,

> How many of these statistics are capwap specific? 

I'm not sure I understand the question, so before attempting an answer, 
I'll ask for some clarification. Do you mean how many of these are not 
802.11-specific (binding-specific)?

In general, I think any that are not 802.11-specific fall generally 
under capwap, but I agree that we need to clearly delineate. I think of 
any stats that would be present regardless of radio type to be 
capwap-specific. I think we can sort that out easily enough, but I want 
to make sure that's what you mean before attempting anything further.

Scott