Neighbor List Update & Coverage Hole Detection in SON
IEEE 802.16 Presentation Submission Template (Rev. 9)
Document Number:
IEEE C802.16m-08/1382r1
Date Submitted:
2008-11-02
Source:
Roberto Albanese, Zexian Li
Nokia
Shashikant Maheshwari, Yousuf Saifullah, Haihong Zheng
Nokia Siemens Networks
E-mail:
roberto.albanese@nokia.com
E-mail:
shashi.maheshwari@nsn.com
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.