Neighbor List Update & Coverage Hole Detection in SON

IEEE 802.16 Presentation Submission Template (Rev. 9) Document Number:

IEEE C802.16m-08/1382r1Date Submitted:

2008-11-02Source:

Roberto Albanese, Zexian Li E-mail: roberto.albanese@nokia.com Nokia

Shashikant Maheshwari, Yousuf Saifullah, Haihong Zheng E-mail: shashi.maheshwari@nsn.comNokia Siemens Networks

Venue: Re: SON; in response to the TGm Call for Contributions and Comments 802.16m-08/040 for Session 58

Base Contribution:This is the base contribution.

Purpose:To be discussed and adopted by TGm for the 802.16m SDD

Notice:This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.

Release:The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that

this contribution may be made public by IEEE 802.16.

Patent Policy:The contributor is familiar with the IEEE-SA Patent Policy and Procedures:

<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

Background

• IEEE 802.16m system will support self organizing mechanisms including:– self configuration;– self optimization.

• Measurement and reporting play key roles in self organized network. And from SRD (Section 6.4.1 Reporting)– IEEE 802.16m shall enable advanced RRM by enabling the collection

of reliable statistics over different timescales, including system (e.g. dropped call statistics, BS loading condition, channel occupancy), user (e.g. terminal capabilities, mobility statistics, and battery life), flow, packet, etc.

Neighbor Lists

• Dynamic changing of neighbor BSs is a key feature of SON. Neighbor Lists need to be dynamically updated (which neighbor BS shall be inserted or deleted in the list).

• Typically the MS determines which cells are in adjacent area based on the Neighbor List sent by BS.

• There’s a trade-off in the size of the Neighbor Lists– too many neighbors in the list: unnecessary measurements/reports

Increased overhead– too few neighbors in the list: cells that are good candidates for

handovers may be missed Degraded performance

Motivation for network centric approach in SON

• Self-configuration and self-optimization of Neighbor Lists update in SON can be complex and resource consuming.

• Allowing MS to do continuous or “blind” search for potential Neighbors, can– consume too much MS power;– degrade the performance of measurements for cells already belonging

to the Neighbor Lists, since resources are wasted for unnecessary measurements.

• Is there an efficient way to have Neighbor Lists dynamically updated?

• Is there a way to minimize the unnecessary measurement reports for MS?

Network-centric Neighbor List update

• BS coordinates MSs to generate reports when and where the network has not yet been configured or optimized properly. Different ways of requesting MS to start measurement and reporting, e.g.

– allowing periodic measurements by MSs;– sending broadcast request for measurements, when BS has insufficient data for a certain region;– sending requests in a fair way among MSs;– limiting the amount of MS measurements based on MS’s status.

• Requests from BS include a flag indication in order to distinguish between low and high priority measurements.

• BS will send different requests according to MS traffic conditions. BS will request:– serving frequency measurements during MS’s high traffic rate periods;– non-serving frequency measurements during MS’s low traffic rate periods (e.g. inter-RAT neighbor

cell measurements).

• MS can decide to delay or even decline sending unnecessary reports to BS especially in critical situations (e.g. low battery level, no changes with respect to previous measurement requests, etc.)

– MS notifies BS in case the requested measurements will be delayed or can not be completed in a predefined interval, so that BS may decide to reallocate the request to another MS.

Measurement/report optimization

• Example parameters in MS measurement reports are signal quality of a given neighbor cell, BSID on a given frequency, position of MS if GPS or other positioning functionality is supported, etc.

• In addition to signal quality, BSID, MS position, BS also collects information such as

– MS battery status; – report history of a particular MS.

• BS exploits such information in order to decide the subset of MSs that needs to perform measurements and produce reports.

• Based on the information available at BS, BS can– reduce the frequency of measurements to MSs with low battery or high power

consumption;– fairly distribute among MSs the measurement requests;– increase the interval between two consecutive measurement requests for those MSs that

did not change their position.

• The detailed algorithm is left for implementation.

Coverage hole detection - Motivation

• Among different self optimization topics, radio network coverage hole detection is a desired feature for reducing operator expenditure

• Improper cell planning could lead to coverage holes• The traditional way for detecting the coverage hole is by

doing drive test and manual network configuration. • Currently there is no mechanism for automatic detection of

coverage hole• As the 16m network will operate more in the self organizing

fashion, i.e., self-configured after power up, and self optimized later on, the possibility of increasing coverage holes will get higher.

Coverage hole detection

• A simple mechanism is suggested for the automatic coverage hole detection with the help of MS measurement

• When an MS regains radio connection after loosing it, the MS sends a failure report

• The failure report carries the BS ID of the last attached BS.

• The report may contain some other information– Timestamp for the last lost connection

– GPS location of the MS

Coverage hole detection

• The algorithm for processing these reports is for implementation

• For example– The SON function detects a coverage hole after processing the failure

report from a number of MSs in the same vicinity

– The SON function may use the location information of the MSs reporting the failure report

Proposed SDD text (1/2)18 Support for Self Organization

18.x Network-centric Neighbor Scanning

SON can provide network-centric mechanisms for Neighbor List update and MS measurement optimization.

BS can coordinate MSs to generate reports, especially when and where the network has not yet been configured or optimized properly. BS can requests for serving frequency measurements and/or non-serving frequency measurements (e.g. inter-RAT neighbor cell measurements) based on MS traffic conditions. Moreover, BS can request low and high priority measurements.

MS can decide to delay or even decline sending unnecessary reports to BS. In this case MS notifies BS that the report can not be completed in a predefined interval.

Reports to BS may carry information on signal strength, BSID and some additional information, e. g. MS position, battery status and report history for a certain MS. BS can exploit such information in order to select a subset of MSs to perform measurements and produce reports.

Proposed SDD Text (2/2)

18.x Coverage Hole Detection

The SON function should provide radio network coverage hole detection mechanism.

When an MS regains radio connection after loosing it, the MS sends a failure report to the BS. The report carries the BS ID of the last attached BS. The report may contain some other information, e.g. timestamp for the last lost connection, and MS GPS location. The SON function in the network processes the failure reports for determining a coverage hole.