Subject: [Capwap] The index of capwapBaseRadioEventsStatsEntry

From: young <[email-masked]>
Date: Wed, 23 Dec 2009 11:46:00 +0800

Hi, Bert:

In fact, the current Index of capwapBaseRadioEventsStatsEntry is correct but
not easy to understand.
The reason is:
I tried to avoid redefining the new object in the
CapwapBaseRadioEventsStatsEntry.
So I reused the capwapBaseWirelessBindingRadioId which comes from
capwapBaseWirelessBindingEntry.
It caused the logic become difficult to understand, Since the 
capwapBaseWirelessBindingEntry talks about configuration (Binding
relationship) while here (capwapBaseRadioEventsStatsEntry) talk about the
statistic data
of a running AP (identified by capwapBaseWtpCurrId).

I think the simple way is to define a new Radio Id object in the 
capwapBaseRadioEventsStatsEntry.

The change would be:
capwapBaseRadioEventsStatsEntry  OBJECT-TYPE
    SYNTAX      CapwapBaseRadioEventsStatsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display the statistic data of
         events happened on a specific radio of a WTP."
    INDEX { capwapBaseWtpCurrId, capwapBaseRadioEventsWtpRadioId }
    ::= { capwapBaseRadioEventsStatsTable 1 }

CapwapBaseRadioEventsStatsEntry ::= SEQUENCE {
      capwapBaseRadioEventsWtpRadioId         CapwapBaseRadioIdTC,
capwapBaseRadioEventsStatsResetCount            Counter32,
      capwapBaseRadioEventsStatsSwFailCount           Counter32,
      capwapBaseRadioEventsStatsHwFailCount           Counter32,
      capwapBaseRadioEventsStatsOtherFailCount        Counter32,
      capwapBaseRadioEventsStatsUnknownFailCount      Counter32,
      capwapBaseRadioEventsStatsConfigUpdateCount     Counter32,
      capwapBaseRadioEventsStatsChannelChangeCount    Counter32,
      capwapBaseRadioEventsStatsBandChangeCount       Counter32,
      capwapBaseRadioEventsStatsCurrentNoiseFloor     Integer32,
      capwapBaseRadioEventsStatsDecryptErrorCount     Counter32,
      capwapBaseRadioEventsStatsLastFailType          INTEGER
    }
see: I add a new Radio Id object.
capwapBaseRadioEventsWtpRadioId OBJECT-TYPE
    SYNTAX      CapwapBaseRadioIdTC
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the identifier of a PHY radio on a WTP, which
         is required to be unique on a WTP.
         For example, WTP A and WTP B use a same value of
         capwapBaseRadioEventsWtpRadioId for their first radio."
    REFERENCE
        "Section 4.3. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseStationEntry 1}

I think it is better to add more explain in the description of the 
CapwapBaseRadioEventsStatsEntry:
To get all radios' event statistic on a specific WTP (identified by the
capwapBaseWtpCurrId), it needs a query operation SHOULD run from radio ID 1
to radio ID 31 till there is no data returned. The radio ID here corresponds
To the object capwapBaseRadioEventsWtpRadioId. 
If the previous MIB operations such as query on the
CapwapBaseWirelessBindingTable know the exact value of each radio ID, the
Query operation on the capwapBaseRadioEventsStatsTable could use that value
of Radio IDs.

Regards
Richard

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

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

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 23 Dec 2009 09:14:01 +0100

> Query operation on the capwapBaseRadioEventsStatsTable could use that value
It looks like this may indeed work.
And it will get drid of the :inconsistent indexing" warning from SMICng.

Bert