1 / 18

A Framework for RRM

A Framework for RRM. Simon Black, Mika Kasslin, Hasse Sinivaara (Nokia) simon.black@qosine.co.uk, mika.kasslin@nokia.com, hasse.sinivaara@nokia.com TGk January 2003. RRM Objectives. RRM is about obtaining information and delivering it to the appropriate place

brandi
Télécharger la présentation

A Framework for RRM

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. A Framework for RRM Simon Black, Mika Kasslin,Hasse Sinivaara (Nokia) simon.black@qosine.co.uk, mika.kasslin@nokia.com, hasse.sinivaara@nokia.com TGk January 2003 Black/Kasslin/Sinivaara, Nokia

  2. RRM Objectives • RRM is about obtaining information and delivering it to the appropriate place • Improved observation of AP and client performance and environment to facilitate • Improved WLAN client performance though better network management • Optimization of the overall system capacity – particularly in dense BSS environments • Refinement of system installation/deployment – are new APs required? Are existing APs badly sited? • Improved diagnosis of network management problems – audit trails, system alerts • Managed link quality for QoS provision • A flexible framework that can be adapted for new services • Enhancing information provided to WLAN clients to: • Improve the AP selection process both when joining and when roaming • Provide assisted handover support • Information for assisted, or possibly autonomous network configuration during installation and expansion Black/Kasslin/Sinivaara, Nokia

  3. RRM Requirements 1Capabilities, Measurements & Statistics • It should be possible to identify an RRM capable AP, or STA • It should be possible for a management entity to request that an Access Point make appropriate measurements to determine the radio environment • prior to MLME-START.request being issued • while operating • STAs should have the ability to make and report measurements on the radio environment • autonomously • when requested via the AP • It should be possible for a Network Management Entity to obtain configuration and statistics information • extend AP MIB for per-STA statistics and not global MAC statistics as already discussed in RRM SG/TGk • it should be possible to generate management alerts for certain conditions Black/Kasslin/Sinivaara, Nokia

  4. RRM Requirements 2Improved BSS information • Information should be available to STAs to assist in making association decisions that result in • good service characteristics for the individual STA without affecting those experienced by other STAs in the ESS • efficient usage of the available resources. • likely to be particularly important if applications with Quality-of-Service (QoS) requirements are being supported • e.g. the provision of BSS load information Black/Kasslin/Sinivaara, Nokia

  5. RRM Requirements 3Information to Streamline Roaming • Information should be available to STAs that assists in streamlining the roaming process • Overall objective to improve the user experience at handover through the provision of additional radio resource and system information • Transmitted by the AP • Information regarding other APs in the ESS (neighbourhood or co-located BSSs) and possibly the boundary of an ESS • This is just provision of information – the decision of when to scan for and join a given BSS is unchanged as an STA decision Black/Kasslin/Sinivaara, Nokia

  6. Six RRM Scenarios • AP MIB Related Configuration, Control, and Statistics • AP Measurements • Distribution of RRM Information to STAs • STA Statistics Gathering • RRM Commanded STA Actions • STA Autonomous Action Black/Kasslin/Sinivaara, Nokia

  7. RRM Scenario A: AP MIB Related Configuration, Control, and Statistics DS Interface AccessPoint MIB Data Network Management Station Remote Management Remote RRM Algorithms Configuration{data}Control {data}MIB request APME RRM Algorithms AP MIB Black/Kasslin/Sinivaara, Nokia

  8. RRM Scenario B: AP Measurements Radio Interface DS Interface AccessPoint Measurements Measurement{data} Network Management Station Remote Management Remote RRM Algorithms Measure request APME RRM Algorithms AP MIB Black/Kasslin/Sinivaara, Nokia

  9. Scenario C: Distribution of RRM Information to STAs Radio Interface AccessPoint Info Request RRM Information{data] Station Station AP MIB Station Black/Kasslin/Sinivaara, Nokia

  10. RRM Scenario D: STA Statistics Gathering Radio Interface DS Interface AccessPoint Station Network Management Station MIB Data MIB Data Remote Management Remote RRM Algorithms MIB MIB request MIB request Black/Kasslin/Sinivaara, Nokia

  11. RRM Scenario E: RRM Commanded STA Actions Radio Interface DS Interface AccessPoint Action Response Action Response Network Management Station Remote Management SME RRM Algorithms Remote RRM Algorithms Action request Action request AP MIB APME RRM Algorithms Black/Kasslin/Sinivaara, Nokia

  12. RRM Scenario F: STA Autonomous Action Radio Interface DS Interface AccessPoint Network Management Station Information Information Remote Management SME RRM Algorithms [Action] Remote RRM Algorithms AP MIB APME RRM Algorithms Black/Kasslin/Sinivaara, Nokia

  13. Scope of RRM • In practice the protocol elements that are specified will be MAC and PHY extensions • most likely MLME and PLME services • The standard should deal with protocol and not decision-making or algorithms • for example a set of measurements may be defined but not any specific rule as to when these measurements should be made, or how the results should be used • Effectively the standard should provide a tool-kit for RRM Black/Kasslin/Sinivaara, Nokia

  14. IEEE802.11h Layer Model SME Channel Switch Decision Measurement Policy Policy MREQUEST& MREPORT CHANNEL SWITCH MEASURE MLME Measurement Protocol Measurement Frames Channel Switch Timing Protocol MAC Timing MLMEFrames PLME Black/Kasslin/Sinivaara, Nokia

  15. Possible RRM Layer Management Model Higher Layer Protocols APME Measurement Policy Policy MIBGET/SET MREQUEST& MREPORT TPC MEASURE MLME TPC Measurement Protocol Measurement Frames MIB MACTiming Protocol BeaconProcess MLMEFrames BeaconFrames Measure TPC PLME MIB Black/Kasslin/Sinivaara, Nokia

  16. Example Measurement MSC AP STA MLME APME MLME SME Decision to request measurement from peer STA MLME-MREQUEST.req MEASUREMENT REQUEST FRAME MLME-MREQUEST.ind MLME-MREQUEST.cfm Decision to accept measurement request from peer STA MLME-MEASURE.req MeasurementProcess MLME-MEASURE.cfm Compile Measurement Report MLME-MREPORT.req MLME-MREPORT.ind MEASUREMENT REPORT FRAME MLME-MREPORT.cfm Measurement Request Completed Black/Kasslin/Sinivaara, Nokia

  17. RRM Protocol Elements • Add a bit to the Capability Information fixed field to indicate RRM capability • Use the Action management frame type as defined in the IEEE802.11h draft • define a new Action category value defined for RRM • Extension of the AP MAC MIB • enhance for per-STA link statistics • Use the measurement request and measurement report elements and protocol as defined in the IEEE802.11h draft • Define measurements to meet the requirements • RSSI, retry statistics, CCA busy fraction, noise floor, observed BSSs, non-IEEE802.11 signals • Consider cross-band measurements • Define a BSS load element • Review the QBSS load element in the IEEE802.11e draft as a starting point • Define an ESS Information element • potential neighbour BSSs • indicate the boundary of the ESS Black/Kasslin/Sinivaara, Nokia

  18. A Framework for RRM Simon Black, Mika Kasslin,Hasse Sinivaara (Nokia) simon.black@qosine.co.uk, mika.kasslin@nokia.com, hasse.sinivaara@nokia.com TGk January 2003 Black/Kasslin/Sinivaara, Nokia

More Related