1 / 11

RRM Requirements for Public WLAN Service Provider

RRM Requirements for Public WLAN Service Provider. Byoung-Jo “J” Kim AT&T Labs-Research. Outline. The Needs of Public WLAN Service Provider Summary of What we achieved so far. Caveats with Scenarios. Scenarios are hard to get right. Even which scenario is important

dfitzmaurice
Download Presentation

RRM Requirements for Public WLAN Service Provider

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RRM Requirements forPublic WLAN Service Provider Byoung-Jo “J” Kim AT&T Labs-Research Byoung-Jo “J” Kim

  2. Outline • The Needs of Public WLAN Service Provider • Summary of What we achieved so far Byoung-Jo “J” Kim

  3. Caveats with Scenarios • Scenarios are hard to get right. Even which scenario is important • A lot of parameters are common • Sometimes, scenarios are created with what is available in mind • New unexpected scenarios or applications will happen, utilizing RRM “toolkits” • Our architectural choices are limited • Even if a critical scenario demands a new approach, it may be outside of the scope of 11k, and 802. • Address clear needs that can be done in a reasonable time to be useful • consider more advanced features more carefully w.r.t. standardization feasibility: Controversial? Out of Scope? Implementation difficulty? Byoung-Jo “J” Kim

  4. General Characteristics ofPublic WLAN service • Many far-flung locations with small to large number of APs • Variety of Backhaul arrangements: DSL, Cable, T1, ATM, IP, Frame, Fixed Wireless, which may dictate user throughput • Managed at a few large NOCs • Installers with little knowledge on WLAN beyond general directives • No or little local support • User supports and truck-rolls are costly to the business model • Uncontrolled interference environments: 802.11 and non-802.11 • Due to security, only SNMP read may be enabled: Action triggered via SNMP write may be impractical • Remotely, Remotely, Automate, Automate, Automate Byoung-Jo “J” Kim

  5. Features needed w.r.t. RRM • Automatic frequency and power adjustment during AP installation and operation • Instantaneous values need to be aggregated in some way • presence of all .11 AP’s and STAs in the relevant band • RSSI per STA in absolute scale • A signal quality measure per STA, like 03/100r1 • non-802.11 energy, and noise power when CCA is negative • Rates in use: current and averaged over window? or histogram? • Per STA counters: retry, drops, frames, checksum errors • Anything else? Byoung-Jo “J” Kim

  6. Features (continued) • Performance auto-tune and alarms • info on the situation • Interference from other 802.11 systems? Non-802.11 sources? • Nearby BSSs eating up bandwidth • Large part of CCA negative is due to who? • Automatic remedies: by adjusting Power, Frequency, Fragmentation, retry limits, etc.. • Outside of 11k, but what would you need to know if these are our tools for remedies? • Performance Alarms • A significant portion of the users are in poor channel quality • Overall high retries and drops Byoung-Jo “J” Kim

  7. Features (continued) • Remote diagnosis and user support • Among many things that can go wrong in user devices, radio link condition is one • Is the user too far, interference, mis-configured…. • Is there any radio related parameter that has not been covered? • Notifications of significant events (association, authentication, etc, etc., some are available) • QoS related monitoring • Control of Client parameters (as in “out of scope of 11k”) is not an immediate requirement Byoung-Jo “J” Kim

  8. General Agreement so far(in the context of Public WLAN) • Architecture following 11h as outlined in 080r0 • Per-STA self-measured MIB variables, available at APs, for some Passively observable parameters • Initial thoughts in 11-02-676r0-RRM-SG • Requires standard changes only in MIB. No new frame types, actions, etc. • AP Manufactures need to update their firmware • May increase memory requirement, but most already have enough • RSSI, retry counters, CCA fractions, lost packet counters, a signal quality measure, a load measure, etc. Byoung-Jo “J” Kim

  9. Continued • Several Extensions of 11h frames to include a more measurements • Initial suggestions in 11-03-029r0-K • Beacon Report, Extended CCA report, RSSI histogram, Frame report Byoung-Jo “J” Kim

  10. Continued • How to get passively observed parameters from STAs to APs is not clear • What are the parameters? Anything more than 029r0? • If not, no concern. • Map some MIB to parameter variables? (dynamic tables?) and use 11h-like frames to transfer • Leave it to SNMP? • Treat some of them like action requests in 11h? • Start recording the following. Return results when requested • Not much different from simple requests if the result can be put in a simple format Byoung-Jo “J” Kim

  11. More to Consider(Critical issues in Red) • A new signal quality measure. Across PHY and Rate? • Yes we need one, but exactly what • Refined RSSI definition • Refined measure of loading. Across PHY/Rate? • How to aggregate/trend instantaneous parameters • Average, windowing, histogram, parameter specific • How higher layers trigger measurement Actions and Other Interactions (as recommended practice, SNMP for APs) • Neighborhood/Boundary report and other service info dissemination • Some form of Roaming support within 802.11, across PHY, across 3G • Security Implications • Anything else? Byoung-Jo “J” Kim

More Related