Neighbor List Update & Coverage Hole Detection in SON IEEE Presentation Submission Template (Rev. 9) Document Number: IEEE C802.16m-08/1382r1 Date Submitted: Source: Roberto Albanese, Zexian Nokia Shashikant Maheshwari, Yousuf Saifullah, Haihong Nokia Siemens Networks Venue: Re: SON; in response to the TGm Call for Contributions and Comments m-08/040 for Session 58 Base Contribution: This is the base contribution. Purpose: To be discussed and adopted by TGm for the m SDD Notice: This document does not represent the agreed views of the IEEE 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 Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and. Further information is located at and.

Background IEEE m 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 Reporting) –IEEE m 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.