3rd Generation Partnership Project; Technical Specification Group Radio Access Network; V1.0.

1 (2013-09) Study on next generation Self !pti"i#ing Network $S!N% for Technical Report &TRAN and ' &TRAN; $Release ()%

3GPP TR 37.822

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Or ani!ational Partners and shall not be implemented. This "eport is provided for future development wor# within 3GPP only. The Or ani!ational Partners accept no liability for any use of this $pecification. $pecifications and "eports for implementation of the 3GPP TM system should be obtained via the 3GPP Or ani!ational Partners% Publications Offices.

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

&eywords
LTE, radio

3GPP Postal address 3GPP support office address

650 Route des Lu io!es - "o#$ia %&ti#o!is Va!'o&&e - (R%)*E Te!.+ ,33 - 92 9- -2 00 (a.+ ,33 - 93 65 -7 16

'nternet
$tt#+//000.31##.or1

Copyright Notification (o part may be reproduced e)cept as authori!ed by written permission. The copyri ht and the fore oin restriction e)tend to reproduction in all media.
* +,-3. 3GPP Or ani!ational Partners (/"'0. /T'$. 11$/. 2T$'. TT/. TT1). /ll ri hts reserved. 3MT$4 is a Trade Mar# of 2T$' re istered for the benefit of its members 3GPP4 is a Trade Mar# of 2T$' re istered for the benefit of its Members and of the 3GPP Or ani!ational Partners 5T24 is a Trade Mar# of 2T$' re istered for the benefit of its Members and of the 3GPP Or ani!ational Partners G$M6 and the G$M lo o are re istered and owned by the G$M /ssociation

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

*o&te&ts
1ontents....................................................................................................................................................3 7oreword...................................................................................................................................................8 'ntroduction...............................................................................................................................................8 - $cope......................................................................................................................................................9 + "eferences..............................................................................................................................................9 3 :efinitions and abbreviations.................................................................................................................9
3.- :efinitions..............................................................................................................................................................9 3.+ /bbreviations.........................................................................................................................................................9

8 :escription of addressed problems and solutions...................................................................................9

8.- $O( for 32 types..................................................................................................................................................9 8.-.- Pin ;pon event..................................................................................................................................................< 8.-.+ Mobility $ettin s 1han e interpretation.............................................................................................................< 8.+ $O( for //$;based deployments.........................................................................................................................= 8.+.- 1onnection failures due to cell splittin >mer in ...............................................................................................? 8.3 $O( for pre;"el.-+ small cells..............................................................................................................................? 8.3.- Ta#in the outcome of the ""1 re;establishment into account for M"O..........................................................? 8.3.+ "57 reportin in 5T2 island covera e scenarios...............................................................................................?

9 1onclusions..........................................................................................................................................-, Annex A (informative): Change history......................................................................................11

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

(ore0ord
This Technical "eport has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuin wor# within the T$G and may chan e followin formal T$G approval. $hould the T$G modify the contents of the present document. it will be re;released by the T$G with an identifyin chan e of release date and an increase in version number as follows@ Aersion ).y.! where@ ) the first di it@ - presented to T$G for informationB + presented to T$G for approvalB 3 or reater indicates T$G approved document under chan e control. y the second di it is incremented for all chan es of substance. i.e. technical enhancements. corrections. updates. etc. ! the third di it is incremented when editorial only chan es have been incorporated in the document.

2&trodu tio&
$O( enhancements may be necessary for the interoperability of the e)istin features as well as for the new features and new deployments considered in "el.-+. 'n "el.-- Mobility "obustness Optimisation (M"O) has been enhanced so that identification of the 32 type. for which a failure has occurred may be possible. Other $O( use cases may benefit from similar differentiation in handlin . /ctive antennas allow the creation of multiple vertical and hori!ontal beams ma#in the deployment dynamic. $O( may enhance networ# deployment based on active antennas. 7inally. review of $O( techniCues and verification of any enhancements with re ard to e)istin pre;"el.-+ small cells are part of the study item.

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

" o#e

The present document provides descriptions and possible solutions of use cases and analysis of these solutions. 1onsiderations with re ards to reCuested functionality in scope of other 3GPP roups if any. may be captured in this document as well.

2
; ; ;

Re3ere& es
"eferences are either specific (identified by date of publication. edition number. version number. etc.) or non;specific. 7or a specific reference. subseCuent revisions do not apply. 7or a non;specific reference. the latest version applies. 'n the case of a reference to a 3GPP document (includin a G$M document). a non;specific reference implicitly refers to the latest version of that document in the same Release as the present document. 3GPP T" +-.?,9@ FAocabulary for 3GPP $pecificationsF.

The followin documents contain provisions which. throu h reference in this te)t. constitute provisions of the present document.

D-E

4e3i&itio&s a&d a''re5iatio&s

3.1 4e3i&itio&s
7or the purposes of the present document. the terms and definitions iven in T" +-.?,9 D-E and the followin apply. / term defined in the present document ta#es precedence over the definition of the same term. if any. in T" +-.?,9 D-E.

3.2 %''re5iatio&s
7or the purposes of the present document. the abbreviations iven in T" +-.?,9 D-E and the followin apply. /n abbreviation defined in the present document ta#es precedence over the definition of the same abbreviation. if any. in T" +-.?,9 D-E. $O( $elf;Or ani!in (etwor#

4es ri#tio& o3 addressed #ro'!e6s a&d so!utio&s

-.1 "7) 3or 8E t9#es

/ccordin to current specifications. differentiation of mobility settin s is possible. The objective of the G$O( for 32 typesH tas# should be to evaluate if differentiation of mobility settin s mechanisms can cause interoperability issues and if yes. to evaluate solutions for them. /ny solution should brin sufficient improvements to inter vendor interoperability and it should be robust and future proof. $uch solutions should not unnecessarily limit the fle)ibility available in current systems for assi nin different policies to 32s or 32 roups.

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

-.1.1 Pi&1-#o&1 e5e&t

Problem description: 2nablin wider differentiation of mobility settin may be needed in the system (homo eneous and hetero eneous scenarios). but may create issues. such as pin ;pon s. 2)ample scenarios are presented below (further scenarios are 77$). $cenario -@ Ihen load balancin is used to resolve con estion in the source cell. and the Mobility $ettin s 1han e procedure is used to adapt the handover tri er point to the tar et cell. some 32 cate ories may be subject to pin ;pon dependin on how the 32 cate ory is handled in the tar et cell. / 32 belon in to such 32 cate ory is handed over from the con ested source cell to the tar et cell while located far out in the ed e of the tar et cell. Ihile the e(0 servin the tar et cell is aware that handin over the 32 bac# to the con ested cell within a certain time window is a pin pon event it is 77$ whether the e(0 servin the tar et cell needs additional information for further handover decisions. These decisions are typically based on a trade off between the ris# for failure and pin pon . Solutions: The followin solutions have been identified@ -. $olution without additional information The e)istin information such as load information. measurement confi uration. Jo$ parameters and 32 capabilities can be used to assess the offset used for a handover and li#elihood of connection failure of the served 32. Therefore. current specifications enable an e(0 to have information for avoidin unnecessary handovers bac# to the source cell. +. $olution with additional information but without pre;defined 32 roups. 'n this solution the source e(0 sends an indication in the handover reCuest to the tar et e(0 to ive additional information about each handover. a. $i nal the offset from the a reed handover tri er used for this handover.

b. $i nal a timer to inform the tar et that it should not hand over the 32 bac# to source within the iven time. c. $i nal a roup identity (defined at source as a bit strin ) in the Mobility $ettin 1han e procedureB later. the tar et. if it accepted the new mobility settin s. applies the new settin s to the 32s handed over successfully with the same roup identity si naled in the KO preparations. 3. $olution with pre;defined 32 roups 'n this solution. the roups are defined in the standard. The mobility settin s chan e procedure is e)tended to include ne otiation of the predefined roups. a. The e(0 e)chan e the roup ': in the handover reCuest. b. The roups are based on commonly #nown parameters. li#e 32 capabilities or release or bearer class.

-.1.2 :o'i!it9 "etti&1s *$a&1e i&ter#retatio&

Problem description: The way the Mobility $ettin 1han e procedure is defined allows for very different implementations. also such that may reduce the available ran e for the ne otiation. To depict it. the followin e)ample may be considered@ There are two e(0s. e(0 /. whose vendor considers the procedure as GadvisoryH and relies on its implementation. and e(0 0 where the procedure is considered bindin and where the mobility decisions are made accordin to the a reed mobility settin s. 'f the two e(0s are to ne otiate the mobility settin . the e(0 / may propose rather bi chan es. assumin that if there is a 32 that can not handle such a bi e)tensions. the mobility implementation will hand over the 32 sooner. :espite the fact that the specifications do not mandate to apply the ne otiated handover to all 32s. the e(0 0 may reject such a reCuest because some 32s (e. . le acy 32s) may not be able to handle it. /nd since the standard states that e(0 / should consider the response before e)ecutin the planned chan e. the available ran e for the load balancin may be reduced.

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

Solutions: The problem can be solved in different ways@ -. 1larify that the ne otiation is for the least sensitive 32 (typically le acy 32s). +. 1larify that the ne otiation is for the most sensitive 32s. The clarification can be added as a specification or as an information element in the Mobility $ettin 1han e procedure. /lternatively. the problem may be considered as irrelevant. because the ambi uity was present in the procedure since the "el.?. when it was first specified. Then. the handover tri er points established via Mobility $ettin 1han e procedures should be interpreted as a recommendation that. whenever possible. the ne otiated handover tri er point shall be respected.

-.2 "7) 3or %%"-'ased de#!o96e&ts

The objective of $O( for //$ tas# should be to evaluate whether $O( mechanism could be beneficial to optimi!e inter;operability of //$ operations. /lso. as part of the tas#. an evaluation should be performed of whether e)istin $O( features need to be enhanced to handle the dynamic chan es due to //$ activities. The scenarios assumes hi h traffic demand from hi h density of 32s. The 32s may be concentrated temporarily or permanently in spaceB the //$;based deployment is used to optimise capacity. Three //$ techniCues have been considered@ -) 0eam formin ; ; ; ; ; The solution introduces adaptive or reconfi urable antenna systems. where the covera e of each cell is maintained unchan ed. The same P1' is used in all the cell covera e. These adjustments are considered to be on fast time scale (followin ""M). The control unit may be the base station (implementation based). Problems related to e)istin $O( features or enhancements needed@ none (intra;cell activity)

+) 1ell $hapin ; ; ; ; ; The solution introduces adaptive or reconfi urable antenna systems. where the main covera e of each cell is maintained unchan ed but the cell ed e can be adapted to load demand. The same P1' is used in all the cell covera e. These adjustments are considered to be on medium time scale (every -h or more seldom). The tri er for the chan e may be O/M reconfi uration (e. . based on collected &P's) or the control unit may be the base station (implementation based). Problems related to e)istin $O( features or enhancements needed@ 77$

3) 1ell splittin ; The solution adopts hi her order sectorisation (vertical. hori!ontal or a combination) to selected base stations by chan in an antenna system to include more antenna beams. each coverin a smaller area than before the chan e L however. the main covera e of the combined beams correspond to the main cell covera e before the split. 2ach of the beams broadcasts different P1'. 1ell splittin > mer in procedures is considered on a lon term time scale (every -h or more seldom L few times a day).

; ;

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

The tri er for the chan e may be O/M reconfi uration (e. . based on collected &P's) or. if the cell covera e is not affected and the split is pre;planned. the control unit is the base station (implementation based). 'ndication of the cell splittin may be needed at O/M and nei hbour e(0s. Problems related to e)istin $O( features or enhancements needed@ 77$

/ centrali!ed (in O/M) controlled solution is already possible today. since O/M is able to send any confi uration to the involved e(0s. 't is also capable of monitorin an e)tensive ran e of measurements. Therefore. the solutions for cell splittin operate on a discreet set of confi urations provided from O/M. $cenario descriptions involvin cell splittin should provide answers to the followin Cuestions@ -. $hould cell splittin occur in !ones freely defined by the e(0. or only accordin to O/M preconfi ured eo raphical informationM /nswer@ The cell splittin should occur accordin to O/M preconfi ured eo raphical information. The process of cell splittin should be carried out in a controlled and preconfi ured way. i.e. by selectin splittin confi urations that have been validated in terms of covera e at O/M level. /ccordin to networ# load and users service type and reCuirements in the considered eo raphic areas. O/M can define whether a cell splittin is necessary or not. +. $hould the "/( provide particular information to O/M in order to help confi uration of eo raphical or other information related to cell splittin M /nswer@ 'nformation such as M:T measurement data or statistics can be provided to O/M to help further optimisation of confi uration related to cell splittin . "/( can provide statistics and>or M:T data to O/M. for e)ample. O/M can consider statistics and>or confi ure M:T measurements before or after cell splittin in the concerned !ones. and the statistics and>or M:T measurements data collected from e(0s and 32s may help operators et #nowled e of the real covera e and capacity conditions under the two different antenna confi urations within the concerned eo raphical area. Operators can ma#e further optimisation on the settin of //$ antenna and eo raphical !ones. 3. $hould the cell splittin . once defined by O/M. be permanently activatedM /nswer@ The cell splittin can be activated and mer ed bac#. 'n a situation where the hot spots of traffic demand are consistently localised in space and are present for most of the time. or appear>disappear with a relatively short time period. it would be plausible to permanently adopt the cell splittin confi uration. On the other end. if the traffic hotspots are not consistently localised in space and appear in time with rather lon periods. it may be plausible to allow the mer e bac#. from the splittin confi uration to a mer ed one. 8. $hould the O/M system be able to activate>de;activate the cell splittin (cell mer in )M /nswer@ The O/M system should be able to activate>de;activate the cell splittin >mer in . which allows operators to control the cell splittin >mer in functionality at their needs. 9. $hould the e(0 be able to autonomously activate (the possibly O/M preconfi ured) cell splittin M 'f so which #ind of information is neededM <. $hould the e(0 be able to autonomously de;activate cell splittin (cell mer in )M 'f so which #ind of information is neededM /nswer9><@ The e(0 should be able to activate>de;activate the cell splittin usin splittin confi urations preconfi ured by O/M. 3nder the supervision and validation of O/M (e. . validation that the confi uration is compatible with the nei hborin e(0 status). the e(0 may be able to tri er activation>de;activation of the cell splittin when certain conditions are met. =. $hould intra;freCuency scenarios be consideredM N. $hould inter;freCuency scenarios be consideredM

3GPP

Release ()

3GPP TR 3*+,)) -(+.+( $).(3 ./%

/nswer=>N@ 0oth. intra;freCuency and inter;freCuency scenarios should be considered. which may satisfy different operators demands.

-.2.1 *o&&e tio& 3ai!ures due to e!! s#!itti&1/6er1i&1

Problem description: a) "adio lin# failures in the splittin >mer in cell Once the cell splittin is tri ered. the e(0 controllin the cell to be split may not yet #now e)actly which 32s will be impacted. Therefore. it may not be able to initiate a handover for some 32s accordin ly before the cell splittin action. 2ven thou h such 32s could be identified and assumin that these 32s are in active mode while the cell splittin occurs. it is not uaranteed that a suitable tar et cell for handover is available. 1onseCuently. these 32s may e)perience an "57. 'n addition. some 32s served by the cell for which the P1' is unchan ed before and after a splittin >mer in action. they may also e)perience an "57 if the interruption time due to cell splittin >mer in is too lon (e. .. lon er than the "57 detection related timer T3-,). Moreover. once the cell splittin is tri ered a lar e number of 32s may have to be in handover procedures. Therefore. this solution may result in hi h handover failure cases because of the inter;cell interference in the intra;freCuency deployment. b) 'ncomin handover failure and conseCuent re;establishment failure Kandover preparation may be tri ered by a nei hborin e(0 to the cell to be split>mer ed before the cell splittin >mer in action. Ihen the 32 tries to access the tar et cell. the tar et cell may have chan ed due to cell splittin >mer in . This handover may fail due to unsuccessful access. $oon the 32 attempts to re;establish the connection in the best cell. it would fail due to lac# of re;establishment information for this cell. Solutions:

-.3 "7) 3or #re-Re!.12 s6a!! e!!s

-.3.1 Ta;i&1 t$e out o6e o3 t$e RR* re-esta'!is$6e&t i&to a
Problem description: The 32 is currently only reportin which cell it will attempt to re;establish after a failure in the "57 report. The actual outcome of the re;establishment is currently not available for the M"O analysis. The reported re;establishment cell is used to dia nose the failure by M"O and may lead to a corrective action by M"O. 't is 77$ whether the appropriate corrective actions may differ dependin on the actual outcome of the ""1 re;establishment. Solutions:

ou&t 3or :R7

-.3.2 RL( re#orti&1 i& LTE is!a&d o5era1e s e&arios

Problem description: 'n 5T2 deployments where small 5T2 cells are used to provide capacity in areas with hi h capacity reCuirements. the 5T2 covera e may be limited to islands. 'n the ed e of these islands it is very important to set the correct inter "/T mobility parameters to balance the amount of measurements and avoid call drops. 'nter "/T M"O provides the support for this. but reCuires an O+ connection in order to report the failures. /t the same time. the reportin solution for inter "/T M"O is that the 32 reports when connectin to 5T2 a ain after the failure. 'f the covera e is not mature (islands) the 32 may travel Cuite far before reachin 5T2 covera e a ain. 2nablin these reports would reCuire an e)tensive setup of O+ connections. Solutions:

3GPP

Release ()

(.

3GPP TR 3*+,)) -(+.+( $).(3 ./%

One solution is to use proprietary methods (e. . O/M) to forward the information in the "57 report to the e(0 handlin the last servin cell. /nother solution is to forward the information in the "57 report over $- to the e(0 handlin the last servin cell. 7or this solution. there are two options. The first option is to only support sendin this to an e(0 belon in to the same MM2 pool. The second option is to support sendin this to an e(0 belon in to any MM2 pool. The latter reCuires that the T/' of the last servin 5T2 cell is #nown. 't is 77$ whether it is feasible (pendin a discussion with "/(+) to include the T/' in the "57 report from the 32.

*o& !usio&s

3GPP

Release ()

((

3GPP TR 3*+,)) -(+.+( $).(3 ./%

%&&e. % (i&3or6ati5e)+ *$a&1e $istor9

3hange history
4ate 5G 6 5G 4oc+ Su7ject83o""ent !ld New

2013-02013-02013-02013-05 2013-05

R3<79'is R3<79'is R3<79'is R3<80 R3<80

R3-1307-2 R3-1307-3 R3-1307-6 R3-131162 R3-131092 R3-13109R3-131095 R3-131096 R3-1315-8 R3-131552 R3-131553 R3-131563

2013-05 R3<80 2013-05 R3<80 2013-05 R3<80 2013-08 R3<81 2013-08 R3<81 2013-08 R3<81 2013-08 R3<81

";e!eto& TR a1reed 7'=e ti5e 3or "7) 3or 8E t9#es added 7'=e ti5e 3or "7) 3or %%"-'ased de#!o96e&ts added T0o #ro'!e6 ases added i& >"7) 3or 8E t9#es? added @uestio&s o& er&i&1 e!! s#!itti&1 added i& t$e >"7) 3or %%"-'ased de#!o96e&ts? se tio& *a#a it9 o#ti6isatio& s e&ario added to t$e >"7) 3or %%"'ased de#!o96e&ts? se tio& % s e&ario re!ated to usi&1 o3 t$e resu!t o3 t$e RR* reesta'!is$6e&t i& t$e :R7 added to t$e >"7) 3or #re-Re!.12 s6a!! e!!s? se tio& % s e&ario re!ated to RL( re#orti&1 i& is!a&ds de#!o96e&ts added to t$e >"7) 3or #re-Re!.12 s6a!! e!!s? se tio& %dded so!utio&s 3or t$e #i&1-#o&1 #ro'!e6 %dded a&s0ers to t$e Auestio&s o& e!! s#!itti&1 T$e des ri#tio& o3 t$e %%" te $&iAues !ari3ied a&d 6o5ed to t$e i&trodu tio& to t$e !ause -.2, 'e3ore t$e Auestio&s o& t$e e!! s#!itti&1. % #ro'!e6 s e&ario o& er&i&1 o&ti&uit9 o3 a o&&e tio& i& ase o3 e!! s#!itti&1 added to !ause -.2 3hange history

0.1.0 0.1.0 0.1.0 0.1.0 0.1.0 0.1.0 0.1.0 0.2.0 0.2.0 0.2.0 0.2.0

0.1.0 0.2.0 0.2.0 0.2.0 0.2.0 0.2.0 0.2.0 0.2.0 0.3.0 0.3.0 0.3.0 0.3.0

4ate

TSG 6 TSG 4oc+

3R

Re9 Su7ject83o""ent

!ld

New

2013-09 61 2013-09

RP-1311-7 B

TR 37.822 is su'6itted 3or i&3or6atio& :** !ea& u#

0.3.0 1.0.0 1.0.0 1.0.1

3GPP