MIBs for RRM Request and Report September 2003 802.11-03-xxxx-00-000k September 2003 MIBs for RRM Request and Report Byoung-Jo “J” Kim AT&T Labs-Research macsbug@research.att.com And your name here Byoung-Jo "J" Kim, AT&T Labs-Research Byoung-Jo "J" Kim, AT&T Research

MIB for RRM Request and Reports in Doc # 03-666-xx-00k September 2003 MIB for RRM Request and Reports in Doc # 03-666-xx-00k Various examples to facilitate starting points for discussions!! Not a final product, but should be close once a particular approach is favored by the TG. Each revision is a variation: higher revisions do not supercede lower ones. May have some minor typos and logically errors Byoung-Jo "J" Kim, AT&T Labs-Research

MIB for RRM Request and Reports in Doc # 03-666-xx-00k September 2003 MIB for RRM Request and Reports in Doc # 03-666-xx-00k Basic Procedure for Setting Requests in MIB Check nextIndex for next index value: 0 means can’t do Create a row and fill in values while RowStatus is “Not-Ready” or “Inactive” Set RowStatus to “Active” when done. Check back the RowStatus and RqstStatus to see if there is an error Actively delete or modify after Setting RowStatus to “Not-Ready”, or Let it age out automatically (aging time specifiable.) Specify period and number of repetition if multiples of the same request are made from a single row periodically. Byoung-Jo "J" Kim, AT&T Labs-Research

September 2003 Some Notes RowStatus = 0 indicates SME will not accept new requests for some reason like memory. Aging time allows SME to delete request rows after some time without relying on SNMP managers to remember to delete. Periodic request can be specified, saving SNMP traffic, but we do not have periodic request over the air. Periodic requests must have repetition number so that they terminate with certainty, even if SNMP managers forget about them. Wanna suggest the maximum number? Byoung-Jo "J" Kim, AT&T Labs-Research

September 2003 Report Table Only Beacon Report has been written as an example, but others should be similar One row of request can generate multiple rows in the report table, thus the need for separate tables Byoung-Jo "J" Kim, AT&T Labs-Research

September 2003 Some Issues MIB is not a high-level flexible data structure, so may not support all features. This attempt is to see if useful functions can be obtained via SNMP MIB Human readable time units are preferred in MIB, but 802.11 has been using PHY/MAC specific Time units. Byoung-Jo "J" Kim, AT&T Labs-Research

September 2003 Variations Please read Notes in each revision: Revisions do not supercede. Just different variations. 03-666-01: What we have in D0.6 for Beacon request/report. Separate table for each request/report type. 03-666-02: Recognizing the difficulty of controlling TSF-based measurement start time, assumes best effort based timing, roughtly based on when a request is sent. 03-666-03: One table for all current types of requests. Can be extended using “AUGMENTS” syntax for future types. 03-666-04: Parrallel bit and thus required simple grouping capability is added to 03. However, grouping in this manner requires searching through the request table, since rows in a group are not gauranteed to have consequetive indices, if multiple SNMP managers unless SNMPv3. Any alternatives? Byoung-Jo "J" Kim, AT&T Labs-Research

September 2003 Volunteers? To Read it as an implementor and point out ambiguity or corrections: I’m too close to see this. To create tables for other types of request and report To solve some of the remaining issues Byoung-Jo "J" Kim, AT&T Labs-Research

Other potential things for MIB September 2003 Other potential things for MIB Config/Read Site Report Config Channel Map Config Disassociation Imminent New Notifications: association, signal quality triggered notification, etc.. CCA on local interfaces More? Byoung-Jo "J" Kim, AT&T Labs-Research