Standardization Progress of SON in 3GPP
Standardization Progress of SON in 3GPP
Standardization Progress of SON in 3GPP
Fang Jianmin
ZTE Corporation
2010-9-9
Agenda
SON history SON use case SON status and way forward
SON - Motivation
Increasing network dimension (coverage & capacity) Increasing network complexity (GSM, UMTS, LTE, Macro/micro/pico/home, ) More and more human intervention More potential customer complaining More and more Operating Expense (OPEX)
Reduce human intervention Provide stable quality Reduce OPEX Self-Organizing Network (SON) self-configuration self-optimization self-healing
Agenda
SON history SON use case SON status and way forward
Agenda
SON history SON use case SON status and way forward
RO (R9) finished R9 MLB, MRO finished New LTE/UMTS ES SI New UTRAN ANR WI
CCO, ES, IR, Auto. Config. of PCI, MRO, MLB, RO, ANRF, ICIC
2008-12 R8
2009-12 R9
2010-12 R10
The eNB shall select a PCI value randomly from the remaining list of PCIs.
R8 ANRF (1)
Cell A PCI=3 ECGI=17
Cell A Type = LTE Phy-CID= 3 Global-CID =17 2) Report Neighbour Response (Phy-CID, Signal level) Cell B Type = UTRAN Phy-CID=PSC=5 Global-CID =19
3) Report ECGI=19
Inter-RAT/Inter-frequency ANRF
Similar to Intra-LTE eNB instructs UE to look for neighbour cells in the target RATs/frequencies. eNB may need to schedule appropriate idle periods to allow the UE to scan all cells in the target RATs/frequencies
R8 ANRF (2)
R9 MLB (1)
MLB consists of one or more of following functions: Load reporting Load balancing action based on handovers Adapting handover and/or reselection configuration
Load balancing algorithm
O&M
Adapting HO parameters
RAN
R9 MLB (2)
Load information definition for intra-LTE and inter-RAT scenarios
Radio resource usage, HW load indicator, TNL load indicator Capacity value Cell capacity class value (For Inter RAT case)
HO parameters negotiation procedure for intra-LTE scenario Negotiating the change of HO trigger
eNB1
eNB2
R9 MRO (1)
Detect radio link connection failures that occur due to:
Too Late HO, Too Early HO, HO to Wrong Cell
Relative X2 messages
RLF INDICATION HANDOVER REPORT
RLF INDICATION may include UE RLF Report helping to determine the nature of the failure (HO parameter problem, coverage hole, )
UE RLF Reporting is only applied in case that the eNB is prepared to accept the RRC reestablishment attempt
eNB1
eNB2
eNB2
RLF INDICATION
R9 MRO (2)
UE RLF Report relative agreed in TS 36.331 (R2-101856) UE indicates the availability of RLF Report via setting the rlf-InfoAvailable to true in RRCConnectionReestablishmentComplete message Network may request the UE to report the RLF Report via UEInformationRequest message UE reports the RLF Report via the rlf-Report in UEInformationResponse message
R9 RO
PRACH information exchange between eNBs over X2 PRACH Configuration IE
RootSequenceIndex ZeroCorrelationZoneConfiguration HighSpeedFlag PRACH-FrequencyOffset PRACH-ConfigurationIndex
eNB2
eNB2
R9 LTE ES (TEI-9)
Scenario
Inter-eNB, peer to peer only The dormant cell is deployed for capacity enhancement, the dormancy of this cell will not impact the coverage
Solution
Switch off cell: based on eNBs self-decision Activate dormancy cell: performed by neighbor eNB via X2 interface The state of dormancy cell is transferred via ENB CONFIGURATION UPDATE The dormancy cell should be activated before initiating or responding to the X2 Setup procedure New cause value switch off ongoing in HO procedure, aides the receiving eNB in taking subsequent actions, e.g. selecting the target cell for subsequent handovers
R9 UMTS ES (TEI-9)
Requirement
RNC controls NodeB via cell reconfiguration procedure to decrease or increase the PCPICH transmission power gradually
Solution
RNC sends Dormant Mode Indicator (both for FDD and TDD) in CELL RECONFIGURATION REQUEST to the NodeB, indicates the NodeB performing the ES action. Dormant Mode Indicator includes Enter Dormant Mode and Leave Dormant Mode The granularity how the power is gradually decreased/increased is decided by NodeB itself, e.g. period, step, If successful, return RESPONSE; If failure, return FAILURE message to RNC with cause value Requested configuration not supported
R10 SON
Close TR 36.902, open RAN3 internal TR 3.023 for SON MRO Key use case, to be enhanced on top of R9 MLB Key use case, to be enhanced on top of R9 CCO to be coordinated with, in particular MRO and MDT will be conducted in SA5
R10 MRO
UE measurement support in case of unsuccessful re-establishement
Agreement that it is beneficial to extend the RLF report framework to the case where the reestablishment fails and the UE goes to idle The detail information to be expanded in the RLF report needs further confirmation
R10 MLB
Intra-LTE MLB
Working assumption to enhance the Resource Status Reporting by introducing the partial failure
Open issues:
[intra-MLB] Do we want to expand the MLB framework to have the knowledge of neighbors neighbors load information? [inter-MLB] Whether we should add multiple cell reporting capability to the load reporting? [intra-MLB and inter-MLB] Should we extend the load reporting to event trigger based (applicable to both intra and inter-RAT)? [intra-MLB] Is beneficial to exchange information between neighbors to be able to predict the load of a neighbor cells in case of HO of a UE to this cell. If so, what are the relevant parameters needed for this estimation? [intra-MLB] Whether we should expand the MLB framework to HeNBs? (note that most of the scenarios could be automatically addressed depending on the decision on the HeNB mobility discussions) [inter-MLB] Whether we see the need to have a SON-based solution for the iRAT parameter exchange
Inter-RAT ES solutions:
Solution 1: Cell switch on/off via O&M commands (already exist) Solution 2: Cell switch on/off autonomously at the RAN node via local policies downloaded by O&M Solution 3: Cell switch on/off based on signalling across RATs Complementary ES features (FFS, both intra- and inter-RAT) Inter-cell coordination before cell switch off and enabling compensation mode Addition of deactivation indicator in solution 3 above
RAN1 status:
Few metrics were captured, no additional metrics for evaluation were identified Quantitative analysis of benefits and system impacts was not possible in 3GPP for all the studied solutions RAN1 could not come to consensus on recommending way forward on any candidate proposal Proposed that the study item be closed with no recommendations on starting a work item. A new (further) study or an work item based on already discussed solutions is to be started in the future if necessary when further offline discussions are concluded among the contributing companies