3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Packet Access (HSPA

e!olution; V7.1.0 (2008-03) "re#uenc$ %i!ision %uple& ("%% Technical Report (Release '

3GPP TR 25.999

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 "pecification 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 reports for implementation of the 3GPP TM system should be obtained via the 3GPP Or ani!ational Partners$ Publications Offices.

Release '

( ,'*-*. ((--'/.( 3GPP TR ()*+++

%eywords
&MT"' radio

3GPP Postal address 3GPP support office address

()* +oute des ,ucioles - "ophia .ntipolis /albonne - 0+.123 Tel.4 533 6 78 76 68 ** 0a94 533 6 73 () 6: ;(

<nternet
http4==www.3 pp.or

Copyright Notification 1o part may be reproduced e9cept as authori!ed by written permission. The copyri ht and the fore oin restriction e9tend to reproduction in all media.
> 8**?' 3GPP Or ani!ational Partners (.+<@' .T<"' 22".' 3T"<' TT.' TT2). .ll ri hts reserved.

3GPP

Release '

3 ,'*-*. ((--'/.( 3GPP TR ()*+++

2ontents
2ontents....................................................................................................................................................3 0oreword...................................................................................................................................................) ; "cope......................................................................................................................................................( 8 +eferences..............................................................................................................................................( 3 Aefinitions' symbols and abbreviations..................................................................................................(
3.; Aefinitions..............................................................................................................................................................( 3.8 .bbreviations.........................................................................................................................................................(

6 <ntroduction............................................................................................................................................: ) Objectives..............................................................................................................................................: ( 2onstraints and reBuirements.................................................................................................................?

(.; 2onstraints..............................................................................................................................................................? (.8 +eBuirements..........................................................................................................................................................? (.8.; +eBuirements for the &T+.1 architecture........................................................................................................? (.8.8 +eBuirements for the &T+................................................................................................................................7

: Technical Proposals and .ssessment.....................................................................................................7

:.; .rchitectural solutions.........................................................................................................................................;; :.;.; 2urrent +elease ( .rchitecture - .lt ;..............................................................................................................;; :.;.8 <u with enhanced "+12 separate from the enhanced collapsed 2+12=A+12=1ode @ C .lt 8.....................;8 :.;.8.; General description........................................................................................................................................;8 :.;.8.8 &ser Plane......................................................................................................................................................;3 :.;.8.3 2ontrol Plane (+adio part).............................................................................................................................;3 :.;.8.6 2ontrol Plane (<nterface part).........................................................................................................................;3 :.;.8.) "upport of le acy &3....................................................................................................................................;6 :.;.8.( "upport of le acy networ#s............................................................................................................................;) :.;.8.: .dditional <nformation...................................................................................................................................;( :.;.8.? Open issues.....................................................................................................................................................;: :.;.3 P" &ser Plane =2ontrol Plane split' 2P functions in +12' direct &P tunnel P" 21 C 1ode @ C .lt 3...........;? :.;.3.; General description........................................................................................................................................;? :.;.3.8 Protocol architecture......................................................................................................................................;7 :.;.3.3 2ontrol plane..................................................................................................................................................;7 :.;.3.6 "upport of le acy &3s...................................................................................................................................8* :.;.3.) <nterwor#in with le acy architecture...........................................................................................................8* :.;.6 <u with +12 &-Plane D 2-Plane functions in 1ode-@ C .lt 6.......................................................................8* :.;.6.; &ser plane.......................................................................................................................................................8; &plin# Macro Aiversity.............................................................................................................................................8; 2arrier sharin deployment scenario.........................................................................................................................88 2arrier sharin deployment scenario.........................................................................................................................88 :.;.6.8 2ontrol plane..................................................................................................................................................88 "tand-alone deployment scenario..............................................................................................................................88 2arrier sharin deployment scenario.........................................................................................................................88 :.;.6.3 "upport of le acy &3s...................................................................................................................................88 :.;.6.6 2" "ervice in stand-alone scenario................................................................................................................88 :.;.6.6.; 2" 21 domain interwor#in with Gs interface deployed4.........................................................................88 :.;.6.6.8 2" 21 domain interwor#in without deployed Gs interface4....................................................................83 :.;.6.) <nterwor#in with le acy architecture...........................................................................................................86 :.;.6.( Pa in 86 :.;.6.: "oft Eandover for "i nallin +adio @earers4................................................................................................86 @ac#ward compatibhility from 3GPP +elease )........................................................................................................8) :.;.6.? 2" "ervice in 2arrier "harin scenario..........................................................................................................8) :.;.6.?.; 3valuation Table.........................................................................................................................................8) :.;.6.?.8 +elocation to ,e acy +12 (<ur-based solution).........................................................................................8( 39ample of &3 <nvolved +elocation.........................................................................................................................8(

3GPP

Release '

0 ,'*-*. ((--'/.( 3GPP TR ()*+++

"pecification 2han es................................................................................................................................................8? 39ample of &3 1ot <nvolved +elocation..................................................................................................................8? "pecification 2han es4...............................................................................................................................................3* :.;.6.7 <u with +12 &-Plane D 2-Plane functions in 1ode-@4 <u 2" support permutations comparison...............3* :.;.6.;* ,oad @alancin between the ,e acy and E"P.5 1etwor#........................................................................3; :.;.6.;; "ecurity and cipherin ..................................................................................................................................3; :.;.6.;8 Open <ssues..................................................................................................................................................3; :.;.) "; interface architecture' i.e. ".3 architecture with +,2 (no-cipherin ) D ++2 in 1ode @.......................................................................................................3; :.;.).; 1on-soft handover approach..........................................................................................................................3; :.;.).;.; Aescription of the architecture (from fi ure :.;.)-;)..................................................................................38 :.;.).8 "oft handover approach..................................................................................................................................33 :.;.).3 "upport of le acy &3s...................................................................................................................................33 :.;.( 3volved E"P. (2ollapsed .rchitecture) with "EO C 2onsiderations with connectivity to evolved 21.......36 :.;.(.; General 36 :.;.(.8 2ollapsed .rchitecture with connectivity to the evolved 21 .pproach ......................................................36 :.;.(.3 Pictorial +epresentation of 2ollapsed .rchitecture .pproach......................................................................36 :.;.(.6 Aescription of architecture.............................................................................................................................3) :.;.(.) Open issues.....................................................................................................................................................3( :.;.: 3nhanced "+1" relocation procedure.............................................................................................................3: :.;.:.; 1etwor#-controlled Mobility.........................................................................................................................3: :.;.:.8 &3-controlled Mobility..................................................................................................................................37 :.;.:.3 Open issues.....................................................................................................................................................6* :.8 <nterwor#in with le acy &T+.1 nodes............................................................................................................6* :.8.; 2ollapsin le acy "+12 and 2+12 into 1ode @...........................................................................................6* :.8.8 2ollapsin only le acy 2+12 into 1ode @.....................................................................................................6; :.8.3 1ot collapsin any of the le acy 2" networ# into the 1ode @........................................................................68 :.3 "upport of &, Macro Aiversity 2ombinin ........................................................................................................66 :.3.; 0lat evolved &T+.1 architectures...................................................................................................................66 :.6 +12 <A 39tension...............................................................................................................................................6( :.6.; "olution for +12-<A 39tension.......................................................................................................................6( :.6.8 "pecification <mpact.........................................................................................................................................6: :.6.3 +ules for 2onfi uration.....................................................................................................................................6: :.6.6 2onfi uration 39ample....................................................................................................................................); :.) ,ayer 8 3nhancements.........................................................................................................................................)8 :.).; 0le9ible +,2 PA& si!es and M.2-hs se mentation ......................................................................................)8 :.).;.; General description........................................................................................................................................)8 :.).;.8 ,ayer 8 without .+F sub-layer.....................................................................................................................)8 :.).;.3 ,ayer 8 with new .+F sub-layer..................................................................................................................)3 :.( &, 3nhancements................................................................................................................................................)3 :.(.; 3nhancement for +oT control for /o<P............................................................................................................)3 :.: +adio +elated 3nhancements...............................................................................................................................)3 :.:.; Multiple <nput = Multiple Output (M<MO)........................................................................................................)6 :.:.8 2ontinuous 2onnectivity for Pac#et Aata &sers (2P2)...................................................................................)6 :.:.3 Aownlin# Ei her Order Modulation usin (6 F.M for E"AP.....................................................................)6 :.:.6 &plin# Ei her Order Modulation usin ;( F.M for E"&P..........................................................................)) :.:.) <mproved ,ayer-8 "upport for Ei h Aata rates................................................................................................)) :.:.( 3nhanced 2ell 0.2E........................................................................................................................................)( :.:.: <nterference 2ancellation (0urther improved minimum performance reBuirements for &MT"=E"AP. &3) .............................................................................................................................................................)( :.? M@M"..................................................................................................................................................................):

? 2onclusions and +ecommendations.....................................................................................................):

?.; <ndependence @etween +adio 0eatures and E"P. .rchitecture 3volution........................................................): ?.8 <P Multicast for M@M" &ser Plane.....................................................................................................................)? ?.3 2arrier sharin scenario for architecture alternative <u with +12 &-Plane D 2-Plane functions in 1ode-@.....)?

Annex A: Change history.............................................................................................................59

3GPP

Release '

) ,'*-*. ((--'/.( 3GPP TR ()*+++

Foreword
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 follows4 /ersion 9.y.! where4 9 the first di it4 ; presented to T"G for informationG 8 presented to T"G for approvalG 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.

3GPP

Release '

1 ,'*-*. ((--'/.( 3GPP TR ()*+++

Scope

The present document has been produced in the scope of the study item on HE"P. 3volutionH I8J. The objective of the study item is to develop a framewor# for the evolution of the 0AA mode of the 3GPP E"P. K2AM.-based radioaccess technolo y beyond +elease :. The present document lists the constraints for the 0AA E"P. 3volution beyond release : and an assessment of technical proposals and their respective' achievable performance and comple9ity.

References
+eferences are either specific (identified by date of publication' edition number' version number' etc.) or nonspecific. 0or a specific reference' subseBuent revisions do not apply. 0or 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. I;J I8J 3GPP T+ 8;.7*)4 H/ocabulary for 3GPP "pecificationsH. 3GPP TA +P-*(*8;:4 HKor# <tem Aescription on "cope of future 0AA E"P. 3volutionH.

The followin documents contain provisions which' throu h reference in this te9t' constitute provisions of the present document.

"uppote Team note4 +eference I8J is not le itimate.

Def n ! ons" s#$%o&s 'nd '%%re( '! ons

3.1 Def n ! ons

0or the purposes of the present document' the terms and definitions iven in T+ 8;.7*) I;J and the followin apply. . term defined in the present document ta#es precedence over the definition of the same term' if any' in T+ 8;.7*) I;J. HSPA: <n the present document' the acronym HSPA (Ei h "peed Pac#et .ccess) is used to Bualify the 0AA mode features E"AP. (Ei h "peed Aownlin# Pac#et .ccess) and 3nhanced &plin# as defined in the +elease : version of the 3GPP "pecifications. Backward Compatibility: <n the present document' Backward Compatibility means the ability of an E"P. infrastructure to simultaneously allocate radio resources on one sin le carrier to post-release : terminals and terminals compliant with previous releases of the 3GPP specifications without performances de radation for either type of terminal. <t is understood that in that case the performance enhancements tar eted in this document would only apply to post-release : terminals and that the full potential of system performance enhancements would only be achievable if all terminals operatin simultaneously on a sin le carrier were post-release : terminals.

3.2 )%%re( '! ons

0or the purposes of the present document' the abbreviations iven in T+ 8;.7*) I;J 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+ 8;.7*) I;J. 2.P3L 2" A+L 2apital e9penditure 2ircuit "witched Aiscontinuous +eception

3GPP

Release '

' ,'*-*. ((--'/.( 3GPP TR ()*+++

E"P. ,T34 M<MO 1." OP3L Fo" P" T2P &3

Ei h "peed Pac#et .ccess ,on Term 3volution Multiple <nput Multiple Output 1on .ccess "tratum Operational e9penditure Fuality of "ervice Pac#et "witched Transmission 2ontrol Protocol &ser 3Buipment

+n!rod,c! on

The "tudy <tem Aescription on HE"P. 3volutionH I8J was approved by the 3GPP T"G +.1 M3; plenary meetin in March 8**(. The importance of on- oin and future efforts to enhance the capabilities and performance of E"P.-based radio networ#s is widely reco nised by 3GPP operators. E"P. networ#s will form an inte ral part of future 3G systems and as they evolve' should provide a smooth mi ration path towards ,T3. E"P. operators are just as interested in the potential performance and cost savin s which may be achieved throu h E"P. 3volution as they are in the future ,T3 system. 2ritical elements of such evolution should include reduced latency' hi her user data rates' improved system capacity and covera e and reduced cost for the operator while maintainin the hi hest possible level of bac#ward compatibility.

-%.ec! (es
;. E"P. "pectrum 3fficiency' Pea# Aata +ate and ,atency should continue to evolve favourably. The tradeoffs necessary to achieve performance comparable to ,T3 in ) ME! should be analy!edG 8. E"P. and its evolution should facilitate the joint technolo y operation with ,T3 and offer a smooth mi ration path towards ,T3 (,on Term 3volution). The possibility to adopt common elements or a common functional split with ,T3 and the possibility to re-use the evolved 2ore 1etwor# defined as part of the "ystem .rchitecture 3volution (".3) study should be analy!ed as wellG 3. 3volved E"P. should be able to operate as a pac#et-only networ# based on utili!ation of the hi h speed data channels only (E"-A"2E' 3-A2E and associated channels)G 6. E"P. 3volution shall be bac#ward compatible in the sense that le acy terminals (+77-A2E and E"P. mobiles) shall be able to share the same carrier with terminals implementin the latest features of the E"P. 3volution trac# without any performance de radationG ). <deally' e9istin infrastructure should only need a simple up rade to support the features defined as part of the E"P. 3volution.

@eyond +elease :' the followin elements should be considered as uidin principles for E"P. 3volution4

Thus' the study should focus on improvin the system performances for services delivered throu h the P"-domain includin voice and multimedia conversational services. <n relation to this study item' T"G-+.1 should establish a reference performance set for E"P. release :. +ather than relyin on new simulation results' it is recommended that this performance set is derived from on- oin activities related to the performance evaluation of new enhancements li#e E"AP. M<MO or ,T3. This reference performance set should be used to set the absolute performance tar ets for E"P. 3volution and to evaluate the potential improvements provided by solutions proposed in the scope of the study.

3GPP

Release '

2 ,'*-*. ((--'/.( 3GPP TR ()*+++

/
1OT34

0ons!r' n!s 'nd re1, re$en!s

This chapter will capture te9t on the constraints for E"P. evolution includin on le acy issues' bac#ward compatibility' architecture' impact on ,T3' 1ode @ and &T+.' software and hardware up rades' comple9ity issues' acceptable impacts on &3$s' protocol reuse=reBuirements' si nallin and physical channel limitations' etc.

/.1 0ons!r' n!s

a) E"P. 3volution should be capable of bein implemented throu h a re-use of the release : +.1 architecture. Eowever' proposals to modify the +.1 architecture should also be considered within the scope of E"P. 3volution' provided full interwor#in to a le acy release : architecture is supported. b) The +.1-21 functional split can be reviewed providin that it results in si nificant performance and=or improvements and facilitate the mi ration towards ,T3=".3 without si nificant comple9ity increase. c) 3volved E"P. should have a minimum impact on 1ode @s' to allow for simple up radesG +euse of the e9istin 1ode @ hardware by E"P. 3volution is essential. This does not preclude hardware up rades to support additional functionality (e. . to increase processin power' +12 functionality' etc.). d) 3volved E"P. protocol architecture shall have minimum impact on &3s especially in terms of comple9ity' to allow for easy introduction. e) +77-A2E and le acy E"P. &3s shall be able to share the same carrier with terminals implementin the latest features of the E"P. 3volution without any performance de radation. f) <ntra- and inter-system mobility performance shall be no worse than +:.

/.2 Re1, re$en!s

/.2.1 Re1, re$en!s for !2e 3TR)4 'rc2 !ec!,re
a) "hould provide a low comple9ity' low cost and smooth mi ration of E"P. towards evolved &MT" (".3=,T3). b) "hould reduce user plane latency to le acy (+)'( D :) D beyond +: terminals. c) "hould reduce control plane latency to beyond +: terminals and' if low comple9ity cost effective means can be found' also to le acy terminals. d) "implification and reduction of the number of nodes should be considered. e) 2onnection of evolved E"P. +.1 to ".3 21 (&P D=or 2P) should be considered. f) "hould consider mobility between non 3GPP access systems and evolved E"P.. ) "hould consider <K with 2" domain to support le acy 2" services. h) "hould consider proposals to lower bac#haul costs. i) <ndicative achievable performance values - see table (.8.;-<. Table (.8.;-<4 <ndicative view on the achievable performance Per ormance !tem Round Trip Delay (PING) & UP Latency +elease ( .nticipated HSPA "#ol$tion %arget Aescription of Measurement P<1G measured once PAP 2onte9t is established and Aevice is in 23,,NA2E

&'(( ms

&5( ms

3GPP

Release '

+ ,'*-*. ((--'/.( 3GPP TR ()*+++

Packet Call et Up

)ay exceed '((( ms

&5(( ms

2old start. Measured from the ++2 2onnection +eBuest sent by a Terminal previously in PMMN<dle to the completion of the PAP 2onte9t 3stablishment Procedure Time needed to transition the &3 from a Aormant state li#e 23,,NP2E or &+.NP2E to 23,,NA2E (.ctive with a +.@=+@ set &p) with or without havin to (re-) establish a PAP 2onte9t

CP Latency Dormant to !cti"e

)ay exceed '((( ms

&'(( ms

Note# The "alues in this ta$le are indicati"e "ie%s o& ho% much ' P! could $e impro"ed at the time o& startin( the study) These "alues are &or in&ormation only)

/.2.2 Re1, re$en!s for !2e 3TR)

a) 2han es that deliver hi her spectrum efficiency should be considered' within the constraints specified in the clause ?. b) "hould reduce user plane latency to le acy (+)'( D :) D beyond +: terminals. c) "hould reduce control plane latency to beyond +: terminals and' if low comple9ity cost effective means can be found' also to le acy terminals. d) "hould consider how to provide efficient Fo" support for all traffic classes preferably Oin a manner that is bac#wards compatible with le acy terminals. e) "hould consider chan es that' where it ma#es sense' deliver benefits to le acy terminals as well as beyond +: terminals. f) .ny chan es to the terminal should ma9imally build on the e9tensive developments and testin efforts of +)' ( D :.

Tec2n c'& Propos'&s 'nd )ssess$en!

The table : outlines the a reed metrics which should be used to describe=evaluate=compare each of the different architecture alternatives. Table :4 E"P. .rchitecture 3valuation Matri9
%arget Alt': C$rrent architect$re Sec$rity 1o <mpacts Alt *: C+,C in ,odeB 1o <mpacts Alt -: !$ .P in ,odeB 0or the 2P - 1o <mpact. 0or the &P' "3 0indin s4 O+ O+ .dditional Platform "ecurity .dditional Physical "ecurity Alt /: +,C in ,odeB "3 0indin s4 O+ O+ 2ombination of both .dditional Platform "ecurity .dditional Physical "ecurity

3GPP

Release '

.- ,'*-*. ((--'/.( 3GPP TR ()*+++

O+ 2ombination of both reBuired reBuired

+ed$ce . Plane 0atency

1o 2han e

+eduction e9pected in A, .1A if Outer .+F in 1ode@ (pendin +.18 decision) 1o 2han e

+eduction e9pected where MA2 is not in use (&P radio protocols terminatin in the 1ode@) 1o 2han e

+eduction e9pected where MA2 is not in use (&P radio protocols terminatin in the 1ode@) +eduction e9pected (2P radio protocols terminatin in the 1ode@) 00" C "ee 1ote (

+ed$ce C Plane 0atency (RRC Setup) Speci ication !mpact

1o 2han e

1o 2han e

Medium

Major

!mpact $pon C, ,ode1s2

1o 2han e

2han es to +elocation Procedures

"i nallin increase due to mobility foreseen.

"i nallin increase due to mobility foreseen.

Performance in handlin Performance in handlin reater number of <u reater number of <u (without OT") or <u=D Gn (without OT") or <u=D Gn (with OT") instances (with OT") instances !mpact $pon +A, 1o 2han e 1ode@ assumes 2+12 functionality. 1ode@ assumes +12 &P functionality. 1ode@ assumes all +12 functionality. <mpacts upon le acy +12 (<ur interface number and additional processin ). <ub handlin removed !nterworking with 0egacy ."s 1incl$des CS 3omain handling2 " iciency o )3C S$pport .s Today 1o <mpact 1o <mpact upon &3. 1o <mpact upon routin of 2" "ervices. 1o impact upon &3. 2" "ervices reBuire routin to le acy "+12. Possible' MA2 occurs in 1ode@ and 2P "i nallin reBuired to "+12. @ut efficiency depends upon transport networ# topolo y and transport technolo y. Scalability .s Today .s Today &P processin scales independently (Airect 1ode@ 21 connection) with transport networ# capacity. MA2 2ombinin in 1ode@ (for &,) will brin an increase in ,ast Mile @andwidth (dependin upon 1etwor# Topolo y). 1ew interface towards "+12 will imply additional traffic on last mile. !nterr$ption time 4 .ser experience. .s Today .s Today More freBuent "+1" +elocations e9pected. More freBuent "+1" +elocations e9pected. <ncreased 2" call setup delay e9pected. .ser %hro$ghp$t !ncrease 1as a $nction o +%%2 ++) s$pport .s Today Aecreased +TT (A,) leads to increased &ser throu hput. "in le cell ++M as today. Multi-cell (inter 1ode@) ++M not supported in a centralised node. Aecreased +TT leads to increased &ser throu hput. .s Today Aecreased +TT leads to increased &ser throu hput. "in le cell ++M as today. Multi-cell (inter 1ode@) ++M not supported in a centralised node. 1o impact upon &3. 2" "ervices reBuire routin to le acy "+12.

1o chan e to le acy +12. 1ew interface between "+12 D 1ode@

.s Today

Possible (MA2 occurs in 1ode@) but efficiency depends upon transport networ# topolo y and transport technolo y.

&P processin scales independently (Airect 1ode@ 21 connection) with transport networ# capacity. MA2 2ombinin in 1ode@ (for &,) will brin an increase in ,ast Mile @andwidth (dependin upon 1etwor# Topolo y)

0ast )ile Bandwidth .sage 1d$e to eHSPA Arch2

.s Today

.s Today

.s Today

3GPP

Release '
,$mber o CP 5 .P ,odes 1DRNC not considered, CS Services not considered2 8 1odes (2P &P)

.. ,'*-*. ((--'/.( 3GPP TR ()*+++

8 1odes (2P &P) 8 1odes (; 2P' ;2P&P) ; 1odes (2P &P)

1OT3"4 ;. 8. 3. Reduce C Plane Latency refers to ++2 "etup. Num$er o& CP and UP Nodes does not consider A+12 situation or 2" services. .t the time of writin ' inclusion of a metric which describes the ease or otherwise of incorporatin ,; ,8 improvements a ainst each architecture option is not included due to any such improvements not specified or described as yet. This does not prevent inclusion of such a metric in the future should any ,; ,8 improvements from other KGs be forthcomin .

7.1 )rc2 !ec!,r'& so&,! ons

7.1.1 0,rren! Re&e'se / )rc2 !ec!,re - )&! 1
The &T+.1 consists of a set of +adio 1etwor# "ubsystems connected to the 2ore 1etwor# throu h the <u. . +1" consists of a +adio 1etwor# 2ontroller one or more 1ode @s and optionally one ".". . 1ode @ is connected to the +12 throu h the <ub interface. The +12 is responsible for the Eandover decisions that reBuire si nallin to the &3. . +12 may include a combinin =splittin function to support combination=splittin of information streams <nside the &T+.1' the +12s of the +adio 1etwor# "ubsystems can be interconnected to ether throu h the <ur. <u(s) and <ur are lo ical interfaces. <ur can be conveyed over direct physical connection between +12s or virtual networ#s usin any suitable transport networ#. The &T+.1 architecture is shown in fi ure :.;.;-;.

2ore 1etwor# <u <u +1" +12 <ub 1ode @ <ub 1ode @ <ur +12 <ub 1ode @ <ub 1ode @

.%+A,

+1"

3GPP

Release '

.( ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.;-;4 &T+.1 .rchitecture I0i ure 6' T"8).6*; +el-(J

7.1.2 +, w !2 en2'nced SR40 sep'r'!e fro$ !2e en2'nced co&&'psed 0R405DR4054ode 6 7 )&! 2
7.1.2.1 Gener'& descr p! on

The main objective of the E"P. evolution is to improve further the latency and the bit rate with limited and controlled hardware and software impacts (;). .nother important aspect is to benefit from these improvements as soon as today and in particular independently of the availability of the ".3 core (8). <n the architecture fi ured out below' the +.1-21 functional split is thus #ept to readily reuse the proven <u interface with no additional delay' testin efforts and painful interoperability issues.(8) @esides' only the functions which effectively contribute to the reduction of the latency and the increase of bit rate have been moved from the +12 down to the node@ in order to minimi!e the hardware and software impacts.(;). These are in particular4 an +12 +,2 mirror function is placed in node@ to improve the latency induced by repetitions for both the user plane and the control plane' the schedulin of all common resources is moved to the node@ (enhanced scheduler) where they benefit from the E.+F function. The centrali!ed schedulin of common resources in the node@ also leads to power mana ement optimi!ations and correspondin ains in bit rate. Other enhancements already identified within the +: study items (si nallin enhancements' 2ontinuous Pac#et 2onnectivity' delay optimisation for procedures'P)

Moreover' these chan es also result in the possible move of the 2+12 and A+12 functions into the node@ which can lead to a simplified architecture as presented in the fi ure :.;.8.;-;.

0i ure :.;.8.;-;4 <u with enhanced "+12 separate from the enhanced collapsed 2+12=A+12=1ode @ <n fi ure :.;.8.;-;' the <u-P" &P in solid reen ta#es the same path as the <u-P" 2P in dashed red. @esides' when the core networ# implements the one-tunnel approach' the architecture can be further simplified into fi ure :.;.8.;-84 where the <u-P" &P in solid reen ta#es another path than the <u-P" 2P in dashed red4

3GPP

Release '

.3 ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.8.;-84 <u with enhanced "+12 separate from the enhanced collapsed 2+12=A+12=1ode @ ("implified)

7.1.2.2

3ser P&'ne

.plink )acro 3i#ersity The &, MA2 stays in the +12. This allows to benefit from the ains of cell ed e throu hput for both intra- and inter1ode @ while not increasin the last mile traffic compared to solutions where this function would be placed in the 1ode@. Ciphering 2ipherin is still performed in the +12. <n particular the user plane traffic is ciphered in a node above the ed e +.1 node as stron ly recommended by ".3 to avoid security vulnerabilities or e9tra cost to overcome them. .t the same time' it avoids the impact and associated cost of movin this function to another node (e. . a 21 node). Header Compression Eeader compression is still located in the +12 which avoids the impact and associated cost of movin this function into another node.

7.1.2.3
++C:

0on!ro& P&'ne (R'd o p'r!)

The ++2 stays in the +12 with the associated functions of connection and mobility control and measurement report co-locali!ed for ma9imum efficiency. )AC: Only dedicated channels remain scheduled in the +12. 2ommon channels schedulin is done in the 1ode@ in order to et the same latency benefit as obtained for E"AP. due to E.+F repetitions. Moreover' their centrali!ed mana ement will result in ains in terms of power and bit rate due to possible scheduler optimisations=anticipations. +0C: The +,2 remains in the +12 as an anchor point for the mobility. This avoids the freBuent conte9t transfers durin inter-node@ relocations and their associated delay. . second mirror +,2 is used in the node@ which can also further improve the latency of si nallin messa es.

7.1.2.*

0on!ro& P&'ne (+n!erf'ce p'r!)

@y #eepin the +12 this architecture minimi!es the impact on &T+.1 interfaces compared to others4 it is foreseen no +.1.P chan e on <u' limited chan es on 1@.P' +1".P (due to move of some functions). "ome simplifications can also be e9pected due to the collapsed 2+12=A+12=1ode@.

3GPP

Release '

.0 ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.2.5

S,ppor! of &e8'c# 39

The support of le acy &3 by a +? 1ode@ is assumed via the carrier sharin reBuirement Buoted above. .ssumin the +? 1ode@ has ot the 2+12 function as per I;J' the +? node@ will share the resources between +? &3s and le acy &3s in the cell. This is handled by the 2+12Q function located in the node@ in the drawin below. Therefore it should be possible that the benefits obtained with 2+12Q functions mana ed by the +? 1ode@ are also levera ed for le acy &3s when they connect to both evolved +? 1ode@ and +? +12.

3egac$ 5N
+,-PS5+3-0S

e<SP) R40

+,-PS5+3-0S

SR40;5SR40
0R40

+,r

3egac$ 4TRAN

<urQ

+,r +,% Re&:7 4ode 6

0R40; 4ode 6; 5 4ode6

e<SP) 4ode 6
3, =-0D>) Re&:99 39

Re&:8 39

Re&:99 39

Re&:8 39

0i ure :.;.8.) -;4 "upport of ,e acy &3 0or bac#wards compatibility reasons' the +12 +? also handles the le acy &3 as follows4 The +? +12 is a +12Q i.e. it has the +12 function of +( with enhancements. These enhancements are optional features which may not apply to le acy &3 at call set up. Therefore' when a le acy &3 connects to the +? +12 via a +? 1ode@' the +? +12 can behave as +( "+12 and the interface between the +? 1ode@ and the +? +12 for this le acy &3 is <ur-li#e in this case. 2onversely' if the le acy &3 connects to the +? +12 via a le acy +( 1ode@' the +? +12 will behave as a full +( +12 i.e. +( "+12 and +( 2+12. This interface between the +? +12 and the +( 1ode@ is then a usual <ub. This scenario is further detailed in the ne9t section. !$ inter ace The le acy &3s are then connected to the le acy networ# via <u-P" or <u-2" interface dependin on the nature of the call' since these interfaces are basically supported by the solution

3GPP

Release '

.) ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.2./

S,ppor! of &e8'c# ne!wor?s

S$pport o legacy ,odeB and S+,C The support of le acy &T+.1 is assumed to be related to the deployment scenario wrt how far +? 1ode@s and +? +12s have been deployed in the networ#. <n particular it is assumed that it should be possible to connect a +? 1ode@ to an e9istin le acy +12 and conversely' it should be possible to deploy a +? +12 even if not all the pertainin node@s are +? 1ode@. The 2+12 function is located in the 1ode@' therefore when a +? &3 connects to both a +? 1ode@ and +? "+12' the interface is normally <urQ. On the contrary' when a +? &3 connects via a +( node@ to a +( +12' the interface is <ub. This is reflected in the followin table4 Table :.;.8.(-; 4 +?=+( 2onnectivity
Node67RN5 R8 4ode6 R/ 4ode6 R/ DR40 R2 RN5 +,r; (f,&& ,p8r'de) +,% (p'r! '& ,p8r'de) +,r (p'r! '& ,p8r'de) R1 RN5 +,% (p'r! '& ,p8r'de) +,% (!od'#) +,r (!od'#)

There are two possible mi9ed deployment scenarios reflected in table :.;.8.(-;4 The first mi9ed scenario is considered to correspond to transient phases i.e. due to phase of deployment consideration' a +? 1ode@ happens to be connected to +( +12 (in that case it should have only one parent). The +? node@ is supposed to behave in that case as a +( 1ode@ and therefore the interface is <ub also. The second mi9ed scenario is a +( 1ode@ connected to a +? +12. This second scenario also leads to an <ub interface. S$pport o legacy 3+,C <n another deployment scenario' the +? +12 may need to communicate with a le acy +12 used as A+12 durin mobility (see the drawin below). <n this scenario' the +? +12 is used as a +( +12 e9hibitin a le acy <ur interface. S$pport o legacy C, The support of le acy 21 is assumed by the evolved +? +12 itself which basically reuses the <u-P" and <u-2" interfaces (see I;J). 0i ure :.;.8.(-; summari!es all scenarios of full or partial up rades.

3GPP

Release '

.1 ,'*-*. ((--'/.( 3GPP TR ()*+++

9(o&(ed <SP) <SP)-p'r! '& ,p8r'de SGS4 >S0
+,-0S

9(o&(ed <SP) <SP)-f,&& ,p8r'de -

SGS4
+,-PS 9(o&(ed<SP) 4ode6 +12

>S0
+,-PS +,-0S +,r

R40
9(o&(ed<SP) 4ode6 +12 +,r;

+,r;

+,%

+,%

+,%

@Ae8'c# @ 3TR)4

9(o&(ed<SP) 4ode6

4ode6

4ode6

9(o&(ed 9(o&(ed<SP) 4ode6

4ode6 4ode6

0i ure :.;.8.(-;4 "upport of ,e acy 1etwor#s

7.1.2.7

)dd ! on'& +nfor$'! on

<n the evolved E"P. nodes' the unchan ed layers are in red' the Hto be modifiedH layers have been hi hli hted in pin# color. .s can be seen from the pin# color' the main differences are of four #inds4 all the common resources are mana ed by an enhanced scheduler located in the node@ to ether with a 2+12 function which centralises the allocation of resources (codes' power)' an outer .+F A, repetition loop (lower +,2 part) is placed into the node@ to reduce +TT' the +12 +,2 buffer part is #ept in sync with this outer .+F to help for seamless inter-node@ handoff' the layer ; is possibly enhanced with the features M<MO and 2P2.

@esides' the uplin# macro-diversity is #ept to not de rade the covera e in the uplin# in particular for conversational calls' the security (respectively the compression) is #ept in a node above the ed e +.1 node to avoid vulnerability (respectively inefficient inter-node@ relocations). 0i ure :.;.8.:-; also includes in one drawin several variants that could be studied by +.18 hi hli hted in blue color4 The mu9 function stays above in the +12' The mu9 function is inte rated in the 1ode@ within the Mac-hs' The mu9 function is also mirrored in the 1ode@ below the new repetition layer.

<n particular' with this latter option' dependin on the precise modification brou ht to +,2 (details to be studied by +.18)' the le acy &3s could also benefit from the +TT enhancements in addition to the enhancements brou ht by the common resource mana ement.

3GPP

Release '

.' ,'*-*. ((--'/.( 3GPP TR ()*+++

3egac$ 5N

+,-PS5+,-0S

e<SP) R40

>e's,re$en!s >o% & !# dec s ons +P

RR0

PD0P

0o$press on Se8$en!'! on >o% & !# 'nc2or 3A repe! ! ons 0 p2er n8 3A reorder n8 3A >'crod(ers !#

RA0 3A5RA0 DA >'c-d; >'c-es >D0 3A

8u&9

+,r-& ?e

e<SP) 4ode 6
RA0 DA DA repe! ! ons 8u&9 0o$$on reso,rce $'n'8e$en! (en2'nced sc2ed,&er" 0R40) >+>0P0

>'c-d; >'c-e >'c-c5s252s5$

A'#er 1

3, =-0D>)

Re&:8 39

0i ure :.;.8.:-;4 ,ocation of layers and functions used by a release ? mobile

7.1.2.8

-pen ss,es

The followin points need to be chec#ed4 networ# interface protocol impact4 e. . impact on <ur +1".P in order to be used over the <ur-li#e interface' radio termination protocol impact (reBuires further study)4 e. . Mac-dQ' Mac-c' +,2' buffer synchroni!ation between the outer .+F in the eE"P. 1ode@ (mirror +,2 A,) and the +12 A, +,2 (reBuires further study)

3GPP

Release '

.2 ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.3 PS 3ser P&'ne 50on!ro& P&'ne sp& !" 0P f,nc! ons n R40" d rec! 3P !,nne& PS 04 7 4ode 6 7 )&! 3
7.1.3.1 Gener'& descr p! on

The current &T+.1 architecture' inherited from GP+"' is not optimised for very pervasive broadband pac#et services. <n fact in this architecture the presence of an +12 in the &ser Plane path plays as a bottlenec# for the traffic throu hput. This is due to two different but lin#ed factors4 limitations iven by switchin and routin capacity of an +12. limitations iven by +,2=M.2 and <ub 0ramin Protocol termination in the +12.

. possible solution to those limitations is allowin &ser Plane and 2ontrol Plane to scale separately and terminatin the &ser Plane protocols in the 1ode @s. That is introducin a $flat$ architecture for the &P part. .s a conseBuence' the 1ode @ will have a direct <P broadband connection to the Pac#et 2ore. Moreover latency and delay on the user plane will improve since radio protocols and retransmission will be terminated in the 1ode @' similar to what has been decided for ,T3. .t the same time' other important aspects such as mobility' efficient coordination between different layer (pico=micro=macro covera e)' reuse of le acy investments should not be overloo#ed. This can be achieved by reusin the +12 functions for the 2ontrol Plane. 0i ure :.;.3-; shows the resultin architecture' in which interconnection with 21 is achieved by the open <u interface4

;u/ ps 5P RN5 ;u/ ps 4P Node:6

SGS N

5N

GGSN

4TRAN (HSPA access

0i ure :.;.3-;4 E"P. 3volved .rchitecture The red dotted lines represent 2P' the reen solid lines represent &P. Aar# and li ht reen lines are introduce to consider the case of deployment of OT". 3ither OT" is not deployed and the li ht reen line will be always used' or it is deployed and both paths can be used accordin to OT path mana ement features. The further evolution towards ".3 is #ept in mind from the very be innin and can be pursued in a later phase collapsin 2P in the 1ode @ and introducin the "; interface and functional split. <n summary' the described solution is characterised by the followin peculiarities4 1ode @s are allowed to have a direct <P broadband connection towards the Pac#et 2ore. &P is on a flat architecture' allowin delay optimisation' scalability and bottlenec# avoidance. &ser Plane C 2ontrol Plane separation and a central 2P entity (+12-2P) allowin 4

better inter-cell coordination in different deployment scenarios (femto=pico' micro=macro and mi9ed). simpler 1ode @s than collapsin in them the whole +12 functionalities. +euse of le acy +124 2P can be easily up raded. <t is in line with the evolutionary step towards ".3.

3GPP

Release '

.+ ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.3.2
.ser plane

Pro!oco& 'rc2 !ec!,re

0i ure :.;.3-8 shows the &ser Plane protocol stac# for the P" domain4

IP GTP - U PDCP RLC MAC PHY PDCP RLC MAC PHY UDP IP L2 L1 Iu PS

IP GTP - U UDP IP L2 L1

UE
0i ure :.;.3-84 Protocol "tac# for &ser Plane .plink )acro 3i#ersity

Node B

PS Core

The support of this functionality has to based on the $"ervin 1ode @$ concept. The evaluation of impacts of this option is reported in subclause :.;.). Ciphering 2ipherin is performed in the 1ode @. .ccordin to ".3 evaluation this approach is feasible with the proper measures for additional security. Header Compression Eeader compression is located in the 1ode @.

7.1.3.3

0on!ro& p&'ne

<n principle the 2ontrol Plane stac# is supposed to be the same as in +elease (' with ++2 in +12 and 1@.P as .pplication Part to 1ode @s. Aue to the separation between &P and 2P entities' at least two alternatives can be foreseen for the control plane &u interface stac# realisation4 +@ (bearin ++2 and 1.") are terminated in the +12 and sent over the <ub with the le acy 0rame Protocols' as for +elease (. Multiple9in of "+@ and user plane +@ is performed in the 1ode @. "+@s are terminated in the 1ode @. ++2 (and 1." messa es) are encapsulated and sent over the <ub usin a eneric (i.e. not radio specific) <P protocol. "olution 8 allows for a uniBue termination of +,2=M.2 in the 1ode@ (both for &P and 2P +@). "olution ; reuse the current functional allocation for the control plane and imply a duplication of +,2=M.2 functionalities in +12 and 1ode@. Eowever +,2=M.2 functions are already implemented in the +12 and may be reused for 2P only. Moreover it allows the support so that this solution has to be preferred.

3GPP

Release '

(- ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.3.*

S,ppor! of &e8'c# 39s

1o or minimum impacts are foreseen on terminals. The same protocol stac# can be used.

7.1.3.5

+n!erwor? n8 w !2 &e8'c# 'rc2 !ec!,re

<nterwor#in with le acy architecture is provided at +12 level.

7.1.* +, w !2 R40 3-P&'ne B 0-P&'ne f,nc! ons n 4ode-6 7 )&! *

3volved E"P. architecture - stand-alone deployment scenario - is a solution for a flat radio access architecture of &T+.1 networ#. <n this architecture the +12 functions are in the 1ode@' which in the present document is named as evolved E"P. 1ode@. 3volved E"P. system enables to use 3GPP +elease ) and later +eleases of air interface with no modifications for E"P. traffic. The intended use scenario for E"P. capable terminals is to utilise E"P. both in uplin# (3-A2E) and in downlin# (E"-A"2E). 0i ure:.;.6-; illustrates evolved E"P. architecture.
Iu-C S (C -Plane)

Evolved HSPA NodeB

Iur Iu-PS (C -Plane)

C SC N SGSN

Gn UP with direct tunnel Gn UP without direct tunnel Gn (U-Plane) Gn (C -Plane)

SGSN

Evolved HSPA NodeB

Gn (U-Plane)

GGSN

0i ure :.;.6-;43volved Ei h "peed Pac#et .ccess architecture The evolved E"P. 1ode@ has <u-P" interface towards pac#et switched 21. <u-P" user plane is terminated either in "G"1 or in case of one tunnel approach (+el-:) in GG"1. 3volved stand-alone E"P. is desi ned with full mobility support' includin handovers within the system. <ntra-system handover in evolved E"P. is e9ecuted between cells' which belon to different evolved E"P. 1ode@s (inter-1ode@ handover). Eandover towards other 3G networ#s is standard servin +12 relocation. The communication between evolved E"P. 1ode@s ta#es place over <ur interface. 0i ure :.;.6-8 describes the two deployment scenarios for the solution presented in this section' one with a stand-alone 3volved E"P. &T+.1 and the other with the carrier sharin with Hle acyH &T+.1.
Evolved HSPA - stand - alone Evolved HSPA - w ith carrier sharin% GGSN GGSN SGSN C SC N
C ontrol plane IuPS Iu

SGSN C SC N
C ontrol plane IuPS Iu Iu

C ontrol plane IuC Iu S User plane Iu! Gn (" one tunnel" )

User plane Iu! Gn (" one tunnel" )

#NC " $e%ac& " U'#AN

C ontrol plane IuC Iu S

Evolved HSPA NodeB

Iur

Evolved HSPA NodeB

Iur

NodeB

NodeB

0i ure :.;.6-84 &-Plane D 2-Plane functions located in 1ode-@ 3volved E"P. architecture is a solution for a flat radio access architecture of &T+.1 networ#. <n the solution all or part of +12 functions are in the 1ode@' which in the present document is named as evolved E"P. 1ode@.

3GPP

Release '

(. ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.6-3 describes the two deployment scenarios' one with a stand-alone 3volved E"P. &T+.1 and the other with the carrier sharin with Hle acyH &T+.1. The lower 3volved E"P. 1ode@ does not support carrier sharin . The upper 3volved E"P. 1ode@ supports carrier sharin in addition to basic evolved E"P. operation.

NodeB

Iu(

#NC

Iu-C S Gs

Iur eHSPA NodeB Iu-PS C GnU Iu-PS C Iu-C SC SGSN Iu-C SC C SGSN SC N

GnU

GGSN GnC

C arrier C arriersharin% sharin%

Iur eHSPA NodeB

0i ure :.;.6-34 "tand alone operation and carrier sharin in the same networ# 0i ure :.;.6-3 shows architecture with One tunnel solution. Eowever' one tunnel solution is not mandatoryG it is possible to route the user plane (<u-P") also via "G"1. The use of <u interface ensures that the system can utilise the e9istin core networ#. <nteroperability with le acy architecture or 8G is also ensured. .dditionally' it is possible to use <ur interface between +12 and 3volved E"P. 1ode@ as the latter has full +12 functionality. <n summary' the described solution is characterised by the followin features4 3volved 1ode @s have a direct <P broadband connection towards the Pac#et 2ore for P" traffic. . flat +.1 architecture' allowin delay optimisation and scalability without capacity bottlenec#s.

+12 is not needed at all for pure P" carrier' i.e. in stand-alone deployment. +12 is used to implement 2" support and therefore 2" core is not chan ed at all in carrier sharin deployment. "tand-alone scenario reBuires minimal chan es or no chan es for the current specifications and networ# elements4

- +12 <A in T" 8).6;3 ran e e9tension in +.1.P etc' if very lar e evolved E"P. networ#s are deployed (refer to :.6). - Optionally' new E,+ parameter HP" only networ# allowedH' if operator offers true P"-only E"P. access (without 2" service enablin handover)' then HP" only networ# allowedH parameter in E,+ could be useful for roamin cases. T" 88.*;;' 86.**?' 83.*(*' 8;.;*;' 83.;88. 2arrier sharin scenario reBuires chan es for <ur interface' the reBuired chan es to specification are 00".

7.1.*.1

3ser p&'ne

&ser Plane protocol stac# for E"P. traffic is <u-P" (GTP-&=&AP=<P). <n case of one tunnel approach the &ser plane is directly between evolved E"P. 1ode@ and GG"1. <n carrier sharin case' non-E"P. traffic oes to +12 on <ur. 3p& n? >'cro D (ers !# Stand6alone deployment scenario

3GPP

Release '

(( ,'*-*. ((--'/.( 3GPP TR ()*+++

0lat architecture is optimi!ed for intra 1ode @ uplin# MA2 for user plane. <n case of inter-1ode@ MA2' it is possible to apply a $"ervin 1ode @$ C $Arift 1ode @$ scenario. <n the flat architecture' the operator needs investi ate' whether to use MA2 or not. 0or e9ample' 1ode@ with ood sensitivity can lead to situation where lin# bud et is downlin# limited and MA2 is not needed at all. 0'rr er s2'r n8 dep&o#$en! scen'r o MA2 can be used for non E"P. traffic served by the +12. Header Compression Stand6alone deployment scenario Eeader compression for 3volved E"P. is located in the evolved E"P. 1ode @. <t is possible to implement header compression for GTP-& and have separate header compression for radio interface in 1ode@. 0'rr er s2'r n8 dep&o#$en! scen'r o +12 can implement E2 for non E"P. traffic.

7.1.*.2

0on!ro& p&'ne

S!'nd-'&one dep&o#$en! scen'r o +12 functionality and protocols are in 1ode@. 39istin +77 +.1 - 21 functional split is maintained. 3volved E"P. 1ode@s communicate with each other via <ur interface. <nterface towards the 2ore 1etwor# is <u-P". <f needed' the evolved E"P. +.1 communicates towards Hle acyH &T+.1 via <ur interface. This communication may not be always needed' e. . in case the evolved E"P. +.1 has its own carrier. 0'rr er s2'r n8 dep&o#$en! scen'r o 3volved E"P. 1ode@ interfaces an +12 via <ur for shared carrier (2"' non-E"P. traffic). The needed chan es on <ur for carrier sharin are 00".

7.1.*.3

S,ppor! of &e8'c# 39s

,e acy &3 is supported' no chan es reBuired in it.

7.1.*.*

0S Ser( ce n s!'nd-'&one scen'r o

3volved E"P. system focuses on P" services. Aue to the P" optimi!ed architecture in the stand-alone scenario' the E"P. &3 should be served in the evolved E"P. when it reBuests a P" service only' and in the le acy architecture (K2AM. or G"M) when it reBuests a 2" service. The oal is to have4 ;) +easonably small delays for 2" call setup (user e9perience).

Minimum 2" functionality in the evolved E"P. networ# (P" optimisation' cost benefits). 0ull support of E"P. terminals (fast deployment of E"P. technolo y). The provision of 2" "ervices i.e' 2" pa in ' reBuire the Gs interface or the <u 2" 2P interface. Eowever' as Gs interface is considered as not commonly implemented in the current networ#s' it cannot be assumed that Gs interface e9ists.

7.1.*.*.1

0S 04 do$' n n!erwor? n8 w !2 Gs n!erf'ce dep&o#edC

)obile originated call

3GPP

Release '

(3 ,'*-*. ((--'/.( 3GPP TR ()*+++

+12 functionality in 1ode@ tri ers <ntersystem (to 8G) or inter freBuency EO towards le acy networ# architecture with full 2" support in the call establishment. Aetails of the procedure 00". &3 uses le acy networ# architecture for 2" and 2"5P" traffic.

)obile terminated CS call "G"1 connects to M"2=/,+ via Gs interface. /,+ can initiate 2" call via Gs interface. +12 functionality in 1ode@ tri ers <ntersystem (to 8G) or inter freBuency EO towards le acy networ# architecture with full 2" support in the call establishment. Aetails of the procedure 00".

Aue to the 2" call setup delay' without further optimi!ation of the current relocation procedure' this solution is not applicable.

7.1.*.*.2

0S 04 do$' n n!erwor? n8 w !2o,! dep&o#ed Gs n!erf'ceC

)obile originated call P" only +.1 tri ers <ntersystem (to 8G) or inter freBuency EO towards le acy networ# architecture with full 2" support in the call establishment. &3 uses le acy networ# architecture for 2" and 2"5P" traffic )obile terminated CS call P" only +.1 connects to M"2=/,+ via <u-cs si nallin interface' hence M"2=/,+ is able to tri er cs pa in ' continuation li#e for Mobile ori inated call. 0i ure :.;.6-6 shows the 2" enablin EO in case P" only +.1 supports <u-2" si nallin in dedicated carrier scenario.

3GPP

Release '

(0 ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.6-642" service enablin EO with <u-2" si nallin support +12 functionality notices from ++24 <nitial Airect transfer that the &3 is startin a 2" call' which tri ers the setup of a si nallin connection towards the 2" 21 domain' conveyin the +.1.P4 <nitialN&3 messa e). M"2 ac#nowled es "22P connection by sendin the 2onnection 2onfirmation "22P messa e. 0rom M"2 point of view +elocation can be started ri ht after it confirmed the <u-cs si nallin connection setup. The call setup si nallin proceeds in parallel with the +elocation procedure (1OT34 whole ,3 messa e seBuence is not shown in fi ure :.;.6-6 for readability reasons' e. . .&TE31T<2.T<O1 messa es are not shown). Aurin the relocation preparation phase' M"2 can e9chan e the call setup messa es with &3 in parallel or buffer the call setup messa es. "o before +elocation command call setup communication to &3 oes throu h source +12 and after +elocation complete throu h tar et +12. Mobile terminated calls can be handled in similar way4 "ervin +12 relocation procedure can be started at the same time (after 2onnection 2onfirmation messa e). @ased on the study above' it can be concluded that the interwor#in of this architecture with 2" domain can be achieved only if 2" si nallin connection is available unless further optimi!ation is performed in the Gs-deployed case for the relocation procedure.

7.1.*.5

+n!erwor? n8 w !2 &e8'c# 'rc2 !ec!,re

<nterwor#in with le acy architecture is provided on +12 level' either via <ur or via <u Stand6alone deployment scenario <t is possible to use <ur or use only Eard Eandover' so le acy +12 does not need to support hi h number of <ur interfaces

7.1.*./

P'8 n8

<n 2ellNP2E state pa in can be constrained to only one cell. "ervin 3volved E"P. 1ode@ can find &3 with pa in . <n 2ellNP2E servin 3volved 1ode@ acts li#e "+12 towards core networ#. <f &3 is in a cell under other 3volved E"P. 1ode @' then the servin 3volved E"P. 1ode @ must send +1".P pa in towards the other 3volved E"P. 1ode @. <n &+.NP2E state' servin 3volved 1ode@ acts li#e "+12 towards the core networ#. <f there are more than one 3volved E"P. 1ode@s in the &+.' then servin 3volved E"P. 1ode@ must send +1".P pa in towards other 3volved E"P. 1ode@.

7.1.*.7

Sof! <'ndo(er for S 8n'&& n8 R'd o 6e'rersC

.s the physical control channel (AP22E) is maintained in the cells within the active set' as is in macrodiversity case in eneral (recall the use of uplin# combinin bein transparent to the &3)' the uplin# and downlin# ,; synchroni!ation is e9istin and the actual (hard) handover can be made fast for user plane data. <f desired' for "+@ the actual macrodiversity combinin can be applied (&,' A, or both direction' recall that in +elease ) "+@ has to be mapped on A2E both in uplin# and downlin#) as the resultin transport overhead is only mar inal. To enable MA2 for "+@' not only the <ur control plane but also the user plane remains between the evolved E"P. 1ode@s. Once the full <ur is supported between the evolved E"P. 1ode@s' it is possible to use it also for anchorin of the "ervin 1ode@ functionality. Bene its o so t hando#er $sage in inter6,odeB hando#er 0rom radio interface (&3) point of view intra-system evolved E"P. handover is a standard 3GPP E"P. handover. 3volved E"P. specific chan es are mostly due to servin evolved E"P. 1ode@ relocation. The specific use of macrodiversity relates to soft handover state. <n case of evolved E"P.' the inter-1ode@ handover proceeds in 8 phases4 ;) 1ew radio lin#s may be added at least for si nalin radio bearers (A2E) and also for uplin# user plane bearers (&, A2E) to operate in soft handover mode. They provide more reliable si nalin over A2E' in-advance uplin# synchroni!ation on the tar et E"P. 1ode@ (Arift) and macrodiversity ain in uplin#. 2ontrol and macro diversity combinin point stays still in the source E"P. 1ode@ ("ervin ).

3GPP

Release '

() ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.6-)4 Aata flow in soft handover state in evolved E"P. system before inter- evolved E"P. 1ode@ handover Eard handover for E"-A"2E carryin A, traffic is e9ecuted whenever the new cell becomes more favourable than the e9istin one. Khen the servin E"-A"2E cell chan e is tri ered from one 1ode@ to another' the servin 1ode@ is relocated accordin ly. Aurin relocation' processes are terminated in the source evolved E"P. 1ode@ and initiated in the tar et 1ode@' and reconfi uration is activated in &u accordin to 3GPP "+1" relocation procedure. &plin# synchroni!ation at tar et 1ode@ is the pre-condition for downlin# hard handover (phase 8). "ynchroni!ed uplin# in advance to the actual EEO minimi!es the interruption caused by the handover for the downlin# data path. Macrodiversity for (downlin#) si nalin radio bearer increases the reliability of the handover related si nalin on phase 8' which in turn ensures minimal interruption in downlin# data flow durin the handover phase. .l orithms and parameters for addin and releasin prepared radio lin#s and selectin servin 1ode@ are similar to conventional 3GPP soft handover and servin E"-A"2E cell selection' respectively. .lso the power control behavior wor#s as such' when &, macrodiversity is supported. It is ** i& the e+istin( RNC relocation procedure needs to $e modi&ied &or the &lat ' P! architecture. 6'c?w'rd co$p'! %2 & !# fro$ 3GPP Re&e'se 5 The stand-alone scenario of the 3volved E"P. supports +el-) terminals which have E"AP. capability. Aownlin# data traffic shall always use E"AP.' thus the handover for the downlin# data traffic is always a hard handover. 0or +el-) terminals the uplin# data traffic uses A2E. Transport optimi!ed macrodiversity should be applied in handover !one. Aownlin# si nalin radio bearer uses either 0.2E or whenever feasible A2E' and macrodiversity shall be applied with A2E in handover !one. &plin# si nalin radio bearer uses either +.2E or whenever feasible A2E. Macrodiversity is applied with A2E in handover !one. <f transport optimi!ed macrodiversity is implemented for &, radio bearer' it is then applicable also for si nalin radio bearer.

7.1.*.8

0S Ser( ce n 0'rr er S2'r n8 scen'r o

<n an <u P" only implementation of .rchitecture M6' two solutions were identified as the interface used to interwor# the evolved E"P. 1ode @ and le acy +12 to enable carrier sharin 4 <ub-based solution <ur-based solution.

7.1.*.8.1

9('&,'! on T'%&e

The followin table attempts to capture the Pros and 2ons of the utilisation of the aforementioned interwor#in interfaces (<ub and <ur) in the shared carrier scenario when implementin an <u P" only flat architecture4

3GPP

Release ' "unctionalit$ D-pennessD 0onnec! ( !# Tr'ns$ ss on

(1 ,'*-*. ((--'/.( 3GPP TR ()*+++ ;ur ) pro(en open n!erf'ce. S2eer n,$%ers of po!en! '& +,r n!erf'ces !o %e $'n'8ed for !2e n,$ero,s e<SP) 4ode6s co,&d %e pro%&e$'! c 0e&& Reso,rces s ' 0R40 respons % & !# 63T SR40 (&e8'c# R40) re1, res ?now&ed8e '%o,! ce&& nfo 7 !2 s w && %e c'rr ed ( ' %'c?2',&. Ter$ n'! on of P0<" F)0<" R)0< '&re'd# def ned 's !er$ n'! n8 n 0R40. +n!erconnec! n8 n ' s2'red c'rr er $p&e$en!'! on !2e e<SP) 4ode6 s '&w'#s !2e 0R40 'nd so no 'dd ! on'& $'n'8e$en! s re1, red 2ere. ;u< 4o! ' ,n (ers'&&# pro(en open n!erf'ceE. 4o! foreseen !o %e 'n ss,e. 4o $ore ss,es !2'n !od'# foreseen.

0o$$on 02'nne& >'n'8e$en!

S#nc2ron s'! on 4o! 'pp& c'%&e (w !2 respec! !o 00< >'n'8e$en!5>, &! p&eF n8) RR> SR40 DR40 re&'! ons2 p '&re'd# s!'nd'rd sed. RR> &o'd s 8n'&& n8 2's %een '(' &'%&e s nce R*. 0e&& 0R40 s !2e D$'s!erD of ce&& >'n'8e$en! $'n'8e$en!. T2 s re$' ns ,nc2'n8ed f e<SP) 4ode6 %eco$es DR40. Power 0on!ro& >ec2'n s$s spec f ed n R4S)P RR0 >ess'8e 4o c2'n8e. <'nd& n8 P'8 n8 0o-rd n'! on 4o! foreseen !o %e ' pro%&e$. = && re1, re e !2er Gs n!erf'ce or +,-cs (s 8n'&& n8 p'r! on&#) n!erf'ce.

Ter$ n'! on of P0<" F)0<" R)0< '! 0R40 $e'ns co$$on c2'nne&s for so$e 39s !er$ n'!es '! !2e &e8'c# R40" o!2ers '! !2e e<SP) 4ode6. T2ese wo,&d 2'(e !o %e $,&! p&eFed so$e2ow for s,%se1,en! 2'nd& n8 o(er !2e ' r. >'n'8e$en!5>,&! p&eF n8 of 0o$$on 02'nne&s re1, res s#nc2ron sed 2'nd& n8.

+! s no! c&e'r '! '&& 2ow RR> oper'!es n !2 s scen'r o 7 s!'! c '&&oc'! on of reso,rcesG <ow does D0R40D ?now w2'! reso,rces 're '&re'd# n ,se %# e<SP) 4ode6G 0e&& >'n'8e$en!C s !2e s'$e nfor$'! on $'n'8ed n !wo p&'ces .e. %o!2 !2e e<SP) 4ode6 )4D &e8'c# R40G 4o! eFpec!ed !o %r n8 '%o,! 'dd ! on'& ss,es. RR0 >ess'8es >)H %e re1, red !o %e enc'ps,&'!ed w !2 n 46)P $ess'8es 'nd sen! !o SR40 (for 0S ser( ces). =2ere ' 39 con!ro&&ed %# !2e &e8'c# R40 'nd n 09AAIP0< or 3R)IP0< s!'!e" !2e pro%&e$s of 2'nd& n8 co$$on c2'nne&s '! !2e e<SP) 4ode6 occ,rs. -ne so&,! on s !2e non-,s'8e of 0e&&IP0< or 3R)IP0< for '&& 39s ,nder !2'! &e8'c# R40 .e. !2ose %e#ond !2e e<SP) 4ode6J

7.1.*.8.2

Re&oc'! on !o Ae8'c# R40 (+,r-%'sed so&,! on)

There are two types of relocation' &3 <nvolved +elocation and &3 not <nvolved +elocation' that were identified as candidates for enablin 2" enablin EO in case of carrier sharin . The details of both relocations are 00". 9F'$p&e of 39 +n(o&(ed Re&oc'! on 39ample of si nalin flow for the &3 involved relocation to le acy +12 from the eE"P. 1ode @ is fi ure :.;.6-(.

3GPP

Release '

(' ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.6-(4 "i nallin 0low for &3 <nvolved +elocation eE"P. 1ode @ notices from <nitial Airect transfer that &3 is startin 2" call (or from establishment cause in ++2 2onnection +eBuest' ref. fi ure :.;.6-() . <nitial Airect Transfer tri ers the establishment of "22P connection (2onnection +eBuest) towards M"2. This "22P 2+ messa e contains H<nitialN&3H +.1.P messa e (,3 messa e is inside <nitialN&3 messa e). M"2 ac#nowled es "22P connection by sendin the 2onnection 2onfirmation "22P messa e. The eE"P. 1ode @ creates the &3 conte9t for the &3 by allocatin A-+1T< and sends the M"2 and "G"1 +elocation +eBuired with this A-+1T<. 1OT34 The inclusion of this A-+1T< in the messa e reBuires impact to specification.

The le acy +12 receives +elocation +eBuest with the A-+1T< and e9ecutes +1".P +, "etup procedure by sendin +, "etup +eBuest messa e with the A-+1T< which identifies the &3 in the A+12=eE"P. 1ode @. The le acy +12 is allowed to set different parameter values from the received values in ++2 2ontainer to +, "etup +eBuest messa e (e. . due to non-capability of some small features' case the eE"P. 1ode @ confi ure the "08 for the 3-A2E of the &3 but the le acy +12 does not support the "08). The 1ode @ reserves the new +, resources based on the reBuest.

3GPP

Release '

(2 ,'*-*. ((--'/.( 3GPP TR ()*+++

.fter the reception of the +elocation 2ommand which contains ++24 Physical 2hannel +econfi uration +eBuest informs the new &-+1T< and new physical channel parameters etc to &3' the eE"P. 1ode @ sends &3 the Physical 2hannel +econfi uration +eBuest and if it does not receive 0ailure messa e from &3' the eE"P. and &3 e9ecutes intra-freBuency EEO (usin new physical layer parameters in received +, "etup +eBuest) when the time in the activation time is elapsed. +1".P +, +econfi uration procedure for establishin Transport 2hannel for 2" +.@ over <ur is tri ered after the reception of +.@ .ssi nment +eBuest messa e establishes 2" +.@. Spec f c'! on 02'n8es There is only one chan e identified in the specification for enablin the relocation. 2han e the presence of d-+1T< in "ource +12 to Tar et +12 Transport 2ontainer in +.1.P4 +3,O2.T<O1 +3F&<+3A=+3,O2.T<O1 +3F&3"T messa es from conditional to optional for allowin source +12 to include the d-+1T< in case of &3 involved relocation in addition to &3 not involved relocation.

This chan e does not enerate ."1.; chan e since the presence of the d-+1T< has been defined in current +.1.P. 9F'$p&e of 39 4o! +n(o&(ed Re&oc'! on <n &3 1ot <nvolved +elocation in current spec' the Tar et +12 has already had some information on physical layer parameters confi ured for &3' e. . 2ode information for &, and A, AP2E confi ured for the &3 so that some parameters for +, confi ured by "ource +12 do not need to be transferred to Tar et +12 by ++2 2ontainer. Eowever in the relocation enablin carrier sharin ' some additional physical layer parameters need to be transferred to the tar et +12(le acy +12) since the +12 does not have any information on the parameters confi ured for &3 and the +12 shall continue to use physical layer parameter confi ured by eE"P. 1ode @ durin relocation. 39ample of si nalin flow for the &3 not involved relocation to le acy +12 from the eE"P. 1ode @ is fi ure :.;.6-:.

3GPP

Release '

(+ ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.6-:4 "i nallin 0low for &3 1ot <nvolved +elocation eE"P. 1ode@ tri ers "+1" relocation usin information from <nitial Airect Transfer by creatin &3 2onte9t for a &3. The +elocation +eBuired messa e includes the Tar et 2ell <A and ++2 2ontainer includes e9tra information for physical layer parameter confi ured by eE"P..(e. . &, AP2E <nformation) in addition to A-+1T<. 1OT3 ;4 The inclusion of this Tar et 2ell <A and in the messa e and inclusion of physical layer parameter in ++2 2ontainer("+1" +3,O2.T<O1 <10O) reBuire impact to specification.

3GPP

Release '

3- ,'*-*. ((--'/.( 3GPP TR ()*+++

The le acy +12 receives +elocation +eBuest with the parameters and e9ecute +1".P +, "etup procedure by settin received parameters in ++2 2ontainer into the +eBuest messa e. "ince the parameters confi ured for +, and Transport 2hannel are unchan ed' the eE"P. 1ode @ replies +, "etup +esponse without any modification to the +, resource for the &3. .fter a reception of +elocation 2ommit from the eE"P. 1ode @' the le acy +12 sends &3 ++24 &T+.1 Mobility <nformation informs the &3 the new &-+1T<. 1OT3 84 Parameters for Physical=Transport 2hannel are unchan ed so this ++2 messa e is the most appropriate. +1".P +, +econfi uration procedure for establishin Transport 2hannel for 2" +.@ is tri ered after the reception of +.@ .ssi nment +eBuest messa e establishes 2" +.@. Spec f c'! on 02'n8esC There are the followin chan es identified in the specification for enablin the relocation4 2han e the presence of Tar et 2ell <A in "ource +12 to Tar et +12 Transport 2ontainer in +.1.P4 +3,O2.T<O1 +3F&<+3A=+3,O2.T<O1 +3F&3"T messa es from conditional to optional for ma#in source +12 to include the 2-<A in +, "etup +eBuest messa e in case of &3 not involved relocation in addition to &3 not involved relocation.

This chan e does not enerate ."1.; chan e since the presence of the Tar et 2ell <A has been defined in current +.1.P4 <nclusion of Physical ,ayer parameter into ++24 "+1" +3,O2.T<O1 <10O. The new parameters should be introduced in the <3 would be4

Ma9imum allowed &, TL power. &plin# AP2E info. 3-A2E info. Aownlin# E"-PA"2E <nformation. Aownlin# information common for all radio lin#s. Aownlin# information for each radio lin#. Aetails on the specification impact is 00".

7.1.*.9

+, w !2 R40 3-P&'ne B 0-P&'ne f,nc! ons n 4ode-6C +, 0S s,ppor! per$,!'! ons co$p'r son
!$ PS 5 !$ CS S$pported The 2" core needs to support much hi her number of <u-cs lin#s for the numerous eE"P. 1ode@s' which could be problematic. eE"P. 1ode@ will need to support <u-cs &P. !$ PS only +A, 1i.e. no !$6cs2 1o need to care of the 2" core connectivity !$ PS8 and !$6cs Signalling only The 2" core needs to support much hi her number of <u-cs lin#s for the numerous eE"P. 1ode@s' which could be problematic. The &ser Plane of <u-cs is not used. Transmission for <u-cs si nallin not foreseen to be a problem. +elies on the addition of <ur for &P. Ma#es pa in Buic# and easy without a reBuirement

7$nctionality 2onnectivity

Transmission

1o need to care of the 2" core transmission capability

Pa in 2o-Ordination

Ma#es pa in Buic# and easy without a reBuirement

Gs interface is needed to support pa in co-

3GPP

Release '

3. ,'*-*. ((--'/.( 3GPP TR ()*+++

7$nctionality

!$ PS 5 !$ CS S$pported for a Gs interface.

!$ PS only +A, 1i.e. no !$6cs2 ordination. 2" 3nablin EO will be relatively slow as &3 has to re-select a 2" cell and to start ++2 connection. Only +.1 functionality for P" service is needed

!$ PS8 and !$6cs Signalling only for a Gs interface. 2" 3nablin EO will be fast as <nitial Airect Transfer will be processed in parallel. Only +.1 functionality for P" service is needed.

2" 3nablin EO

1o need of 2" 3nablin EO.

1eeded &P 0unctionality

+.1 functionality both for P" as well as for 2" service is needed

7.1.*.10

Ao'd 6'&'nc n8 %e!ween !2e Ae8'c# 'nd <SP)K 4e!wor?

Principle ;4 .ccordin to Operator$s policy' load balancin should be considered amon E"P.5 and le acy networ#' where demandin P" only services should be provided throu h E"P.5 net-wor# with hi h priority. Principle 84 . hysteresis mechanism may be used for the P" only service to be switched bac# to E"P.5 networ# as a result of load balancin .

7.1.*.11

Sec,r !# 'nd c p2er n8

The wor# is in pro ress in ".3.

7.1.*.12

-pen +ss,es

".3 need to provide feedbac# on whether cipherin can be enerated in the 1ode @.

7.1.5 S1 n!erf'ce 'rc2 !ec!,re" .e. S)9 'rc2 !ec!,re w !2 RA0 (no-c p2er n8) B RR0 n 4ode 6
1OT34 Te9t from +3-*(;8*:.

7.1.5.1

4on-sof! 2'ndo(er 'ppro'c2

The major difference between the "; and <u functional split stems from the different termination points for the encryption streams. This in turn leads to the positionin of the ".3=,T3 header compression C the eBuivalent of the &T+.1 PA2P - in the MM3=&P3. The rationale behind the placement of these functions was because it was a reed to collapse some of the more delay-dependent +12 functionality into the 1ode @ for the ,T3 system in order to improve system performance' and there were concerns from ".3 in puttin security in the e1ode @. <f the collapsin of the architecture is introduced into +elease ?' then in a mi ratory approach for E"P.' it could be feasible to re-use some of the benefits of the &P3 functions in the same way as used for ,T3=".3. .n architecture that enables the mi ration of &MT" to the ".3 architecture is shown in fi ure :.;.)-;.

3GPP

Release '

3( ,'*-*. ((--'/.( 3GPP TR ()*+++

88=74P=

Gn

3egac$ 4TRAN and 5N

S1-& ?e +,%" +,r" or +, (T6D)

Re&:8 SR40
Re&:8 DR4050R40 Re&:8 4ode 6

+,%

e<SP) 4ode 6
Re&:7 4ode 6

3, =-0D>) +n!r'-3TR)4 2'ndo(er Re&:99 39

Re&:99 39 Re&:8 39

Re&:8 39

+n!er-SR405SGS4 2'ndo(er (s'$e 's AT9-3>TS 2'ndo(er)

0i ure :.;.)-;4 Possible composite &T+. architecture to support release ? and pre-release ? &MT" mobiles

7.1.5.1.1

Descr p! on of !2e 'rc2 !ec!,re (fro$ f 8,re 7.1.5-1)

The followin concepts are introduced in this architecture4 The +12 functionality for Hrelease ? &MT" mobilesH is placed within the @T" site. "; should be able to operate in a Hfle9H manner and hence provide Hreliability and redundancyH above the @T" site. Movement of the "+12 into the @T" site and the adoption of "; si nallin mechanisms should permit the H".3=,T3 styleH fast idle to active transition. .s a conseBuence' the &+.s used by +el$? &3s may be constrained to one @T" site. ,e acy &3 connections lin#ed bac# to le acy 21=&T+.1 even when connected to eE"P. 1ode @. Eandover of a release ? &3 from a release ? HeE"P. 1ode @H to a le acy node @ is the same as an ,T3 to le acy node @ handover. M@M" can be probably handled in the same way as ,T3 for the +elease ? &3s.

To permit this architecture' the followin user plane protocol stac# (0i ure :.;.6-8) could be used.

3GPP

Release '

33 ,'*-*. ((--'/.( 3GPP TR ()*+++

<e'der-0o$p5 9ncr#p! on

<e'der0o$p5 encr#p! on PD0P (<0 off)5 RA0 (encr#p! offG)5 >)05 =-0D>)

PD0P(<0 off5 RA0 (w !2 encr#p! on offG)5 >)05 =-0D>)

3,

S)9-& ?e ,ser p&'ne

S1-& ?e

S)9-& ?e ,ser p&'ne

39 (Re&:8)
0i ure :.;.)-84 &ser plane

e<SP) 4ode 6

3P9

Kith this stac#' the ".3 encryption=PA2P=header compression is used between the &3 and the MM3=&P3. The e9istin &MT" encryption and header compression are never switched on (the e9istin &MT" si nallin seems to contain this capability) (alternatively' e. . if it is simpler' they can be switched on in a Hdouble encryption mannerH). There would be a need for some seBuence number mappin here so that the &3 could maintain synchronisation of the cipherin . Eowever' this anyway needs to be solved for ,T3 in the same way. This stac# has some impact on the &3 C however it has some similarities to G"M=GP+" mobiles where the G+P" stac# is implemented on top of disabled G"M layer ; encryption. &3 manufacturers have already been reBuested to provide uidance on this in I9J. The correspondin control plane protocol stac# is shown in fi ure :.;.)-3.

Sess on >8$!5 >o% & !# >8$!

4)S s 8n'&& n8

Sess on >8$!5 >o% & !# >8$! S)9-& ?e con!ro& p&'ne

RR05 RA05 >)05 =-0D>)

3,

RR05 RA05 >)05 =-0D>)

S)9-& ?e con!ro& p&'ne

S1-& ?e

39 (Re&:8)
0i ure :.;.)-34 2ontrol plane

e<SP) 4ode 6

>>9

<n this control plane protocol stac#' the ++2 messa es are inte rity protected but not encrypted (unless Hdouble encryptionH for the user plane is used (meanin that the +,2 layer in the eE"P. 1ode @ also has encryption activated)).

7.1.5.2
/oid.

Sof! 2'ndo(er 'ppro'c2

7.1.5.3

S,ppor! of &e8'c# 39s

"ee subclause :.8.;=:.8.8=:.8.3.

3GPP

Release '

30 ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1./ 9(o&(ed <SP) (0o&&'psed )rc2 !ec!,re) w !2 S<- 7 0ons der'! ons w !2 connec! ( !# !o e(o&(ed 04
7.1./.1 Gener'&

3volved E"P. with "EO may result in the study of a number of architectures C only the 2ollapsed .rchitecture with connectivity to the evolved 21 approach is considered here. Khilst the Hnon-soft handoverH for eE"P. will undoubtedly reduce comple9ity C it remains to be seen the impact upon performance - the Hsoft handoverH approach in the collapsed architecture approach will certainly reBuire si nificant chan es in e. . ++2-+,2 functional split for uplin# &P traffic would have to be loo#ed at closely C in addition to connectivity to the 21.

7.1./.2

0o&&'psed )rc2 !ec!,re w !2 connec! ( !# !o !2e e(o&(ed 04 )ppro'c2

+eduction in call setup times' non-hierarchical networ#s are but two reasons for the Hcollapsed architectureH approach.

7.1./.3

P c!or '& Represen!'! on of 0o&&'psed )rc2 !ec!,re )ppro'c2

88=74P=
8%5 5o><iner (inc SRN5 4P

S1-& ?e K o!2er +,r FP +,r 0P +,r FP

eSR40 c-p&'ne Dr f! e<SP) 4ode 6 eDR405e0R40 e<SP) 4ode 6 eDR405e0R40 e<SP) 4ode 6 Ser( n8 e<SP) 4ode 6

3, =-0D>)

e<SP) 39

0i ure :.;.(-;4 2ollapsed .rchitectural concept with soft handover

3GPP

Release '

3) ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1./.*

Descr p! on of 'rc2 !ec!,re

.ll of the followin concepts are introduced in the architecture outlined above. The 2+12 and the radio protocol control plane "+12 functionality for HeEP". &MT" mobilesH are placed within the @T" site4 2ollapsin the whole "+12 would mean that there would be a new outer .+F above the layer that is doin the macro-diversity combinin between 1ode @s. +eBuirin +,2 to sit on top of MA2 - to handle any necessary retransmissions - enables the maintenance of the closed-loop approach to +,2 .c#nowled ed Mode' whilst still allowin to provide feedbac# to the 1ode @ on the reBuired "<+ tar ets. One approach to solve this is to split the +,2 entities between the +,2 transportin the ++2 si nallin radio bearers' and the +,2 transportin the radio bearers for user data. <t may even be possible to split the +,2 control channel and +,2 data channel onto different lo ical channels (this should be verified). ++2 and (at least +,2 for the ++2 "i nallin radio bearers) in servin eE"P. 1ode @. This means that the ++2 part of call setup time can be minimised based on its location. <t also means that ++2 does 1OT et the benefit of soft handover. Eowever it is li#ely that the capacity reduction because of this could be small. +,2 user plane and M.2-es (combiner) placed in &P3. This allows not havin to relay user plane bac# down to the servin eE"P. 1ode @ (and thus increasin +,2 +TT)' hence allowin +,2 round-trip time to be maintained as in +elease :.

1OT3 ;4 it is 00" as to whether the +,2 downlin# .M entity can be placed in the servin 1ode @ allowin faster +TT for A, data. This would reBuire a hi her power offset for the &, +,2 control channel' as it is essential that +,2 performance does not et de raded. This should be discussed further by +.18. <ur control plane (i.e. +1".P) connected transparently between servin eE"P. 1ode @ and non-servin eE"P. 1ode @. This is indicated in G+331 in fi ure :.;.(-;.

This is needed for admission=con estion control and radio lin# mana ement. <ur user plane (i.e. 0rame Protocol (0P)) connection between &P3 and servin eE"P. 1ode @' and respectively &P3 and non-servin eE"P. 1ode @. This is indicated in @,&3 in fi ure :.;.(-;.

- <t is li#ely that much of the e9istin protocol stac# could be re-used from the eE"P. 1ode @ point of view. Eowever some indication of the end +,2 PA& error rate would need to be provided bac# to the eE"P. 1ode @ such that ++2 can update the uplin# "<+ tar et. 1OT3 84 <f the MA2 were not part of the MA2' there would need to be another interface to allow connectivity between MA2 and &P3. This would also reBuire the MM3-eE"P. 1ode @ and MA2-eE"P. 1ode @ control si nallin to be separated. ";-li#e interface between MM3=&P3 and servin eE"P. 1ode @. This is indicated in +3A in fi ure :.;.(-;.

- This interface would need to be &PA.T3A to ensure that the functional split between ++2 and +,2 is wellspecified. This would mean that when soft handover is initiated between eE"P. 1ode @$s' the "+12 would need to inform the &P3 to establish a new user plane connection to the diversity eE"P. 1ode @. .lso the M.2-es confi uration would need to be a reed between &P3 and eE"P. 1ode @ "oft handover cannot be performed for eE"P. &3s between eE"P. 1ode @ and +elease : 1ode @.

3GPP

Release '

31 ,'*-*. ((--'/.( 3GPP TR ()*+++

<e'der-0o$p5 9ncr#p! on

<e'der0o$p5 encr#p! on
3ser p&'ne >)0-e5 =-0D>) 3ser p&'ne PD0P (<0 off)5 RA0 (encr#p! offG)5 >)0-d5>)0es

PD0P(<0 off5 RA0 (w !2 encr#p! on offG)5 >)05 =-0D>)

3,

0n!r& P&'ne RR05RA05 >)05 =-0D>)

S1-& ?e

T4A

T4A

(e<SP)) 39

e<SP) 4ode 6

3P9

0i ure :.;.(-84 &ser plane for soft handover concept M.2-es' M.2-d' and +,2 for user plane radio bearers are added to the &P3.

0i ure :.;.(-34 2ontrol plane for soft handover concept from servin eE"P. 1ode @ perspective More si nallin is e9pected between MM3=&P3 and e"P. 1ode @ to handle the interaction between +,2 in the &P3 and ++2 in the servin eE"P. 1ode @.

7.1./.5

-pen ss,es

+.18 to verify if there are any impacts in separatin +,2 for the user plane and +,2 for the control plane (++2) into two separate nodes (i.e. is any communication reBuired between the two +,2 entitiesR). &pdatin "<+tar et in drift eE"P. 1ode @ may need to be done via <ur control plane' and this may reBuire some chan es to +1".P.

3GPP

Release '

3' ,'*-*. ((--'/.( 3GPP TR ()*+++

7.1.7 9n2'nced SR4S re&oc'! on proced,re

This section proposes enhancements to the "+1" relocation procedure both in case of networ#-controlled mobility (i.e. Eandover procedure) and &3-controlled mobility (i.e. 2ell &pdate procedure). The proposed enhancements can help reduce both handover delay and processin load at the 21. This is especially useful when considerin the flat &T+.1 architecture option which will e9tensively use the "+1" relocation procedure to handle inter-1ode @5 mobility. The procedure does not reBuire chan es on the air interface' and therefore is bac#ward compatible with the le acy &3s. .lso' the approach adopted is similar to the approach used in ,T3 to handle inter-e1@ mobility. This will probably allow some 21 reutili!ation between ,T3 and EP".5.

7.1.7.1

4e!wor?-con!ro&&ed >o% & !#

0i ure :.;.:-; shows the si nalin flow for the enhanced "+1" relocation procedure when this is performed in combination with hard handover. <n particular the followin steps apply4 ;) @ased on measurement reports from the &3 (and possibly some other ++M specific information)' the source 1ode @5 decides to handover the &3 to a cell controlled by the tar et 1ode @5. 8) The source 1ode @5 issues a +elocation +eBuest to the tar et 1ode @5 passin the necessary information (conte9t transfer) to prepare the EO at the tar et side. .fter performin .dmission 2ontrol' the tar et 1ode @5 confi ures the reBuired resources. 3) The +elocation +esponse messa e is sent to the source 1ode @5 with the necessary information for the &3 to reconfi ure the radio path towards the tar et 1ode @5. 6) The PES"<2., 2E.113, +32O10<G&+.T<O1 messa e is sent by the source 1ode @5 with the information to access the cell in the tar et 1ode @5. .) The source 1ode @5 can start forwardin GTP-PA&s of the different +.@s to the tar et 1ode @5' dependin on their Fo" Profile. )) Physical layer synchroni!ation and radio lin# establishment are performed with the tar et cell in the tar et 1ode @5. () The &3 sends a PES"<2., 2E.113, +32O10<G&+.T<O1 2OMP,3T3 messa e to the tar et cell in the tar et 1ode @5. :) The tar et 1ode @5 sends a +elocation 2omplete messa e to the 21 with a reBuest to establish the different +.@s between tar et 1ode @5 and 21. ?) The 21 responds with a +elocation 2omplete .c#nowled e messa e and starts to forward the data in the new path. 7) The tar et 1ode @5 finally initiates the release of the resources in the source 1ode @5.

3GPP

Release '

32 ,'*-*. ((--'/.( 3GPP TR ()*+++

39

S-4ode 6K

T-4ode 6K

04

1. >e's,re$en! Repor!

2. Re&oc'! on Re1,es!K

3. Re&oc'! on ResponseK

*. P<H 0< Reconf. ). Forw'rd GTP-3 PD3s

5. P<H S#nc2 5 R'd o A n? 9s!'%& s2$en!

/. P<H 0< Reconf. 0o$p&e!e

7. Re&oc'! on 0o$p&e!eK

8. Re&oc'! on 0o$p&e!e )0LK

9. Re&e'se Reso,rceK

0i ure :.;.:-;4 "i nalin flow for enhanced "+1" relocation with hard handover <n fi ure :.;.:-8 the enhanced procedure is directly compared a ainst the current "+1" relocation with hard handover as defined in I6J. <t is pretty clear from the picture that the enhanced procedure can achieve4 +educed handover delay. +educed processin load at the 21.

3GPP

Release '

3+ ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.;.:-84 2urrent vs 3nhanced "+1" relocation with hard handover

7.1.7.2

39-con!ro&&ed >o% & !#

0i ure :.;.:-3 shows the si nalin flows for the enhanced "+1" relocation procedure in case of &3 controlled mobility' i.e. when the relocation procedure is performed in combination with the 2ell &pdate procedure. This case is handled usin the same principles covered in the normal handover procedure. The only differences are the followin 4 The &3 accesses the tar et 1ode @5 with the 2ell &pdate messa e. The &-+1T< in the messa e indicates the previous servin 1ode @5. The &3 conte9t is fetched by the tar et 1ode @5. The source 1ode @5 is addressed by the &-+1T< included in the 2ell &pdate messa e. The tar et 1ode @5 transmits the reconfi uration parameters in the form of 2ell &pdate 2onfirm messa e.

3GPP

Release '

0- ,'*-*. ((--'/.( 3GPP TR ()*+++

39

S-4ode 6K

T-4ode 6K

04

1. 0e&& 3pd'!e (3-R4T+)

2. Re&oc'! on Re1,es!K

3. Re&oc'! on ResponseK

*. 0e&& 3pd'!e 0onf r$

). Forw'rd GTP-3 PD3s

5. P<H S#nc2 5 R'd o A n? 9s!'%& s2$en!

/. P<H 0< Reconf. 0o$p&e!e

7. Re&oc'! on 0o$p&e!eK

8. Re&oc'! on 0o$p&e!e )0LK

9. Re&e'se Reso,rceK

0i ure :.;.:-34 "i nalin flow for enhanced "+1" relocation with &3 controlled mobility

7.1.7.3

-pen ss,es

The followin points need to be discussed when considerin the enhanced "+1" relocation4 <nterwor#in with le acy 21. Eandlin of 1." messa es and 21-initiated <u procedures (e. . <u release) durin relocations. .ssessment of performance ains.

7.2 +n!erwor? n8 w !2 &e8'c# 3TR)4 nodes

7.2.1 0o&&'ps n8 &e8'c# SR40 'nd 0R40 n!o 4ode 6
<n this option' the "+12 and the 2+12 are both collapsed into the eE"P. 1ode @. This means that for the le acy &T+.1' the <u-2" is connected directly to the eE"P. 1ode @.

3GPP

Release '

0. ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.8.;-;4 ,e acy "+12 and 2+12 collapsed into eE"P. 1ode @ Mobility between eE"P. 1ode @s and between eE"P. 1ode @ and le acy 1ode @ would mean either4 - The <ur is needed to handle mobility of at least the 2" connected (and optionally le acy P") &3s. Aue to the "+12 bein in the eE"P. 1ode @' this would mean that <ur is routed via the last mile lin#s bac# to the tar et node (le acy +12 in this case' but also tar et eE"P. 1ode @). This could mean additional transport costs on the servin 1ode @ Hlast mileH lin#. - .n "+1" +elocation is needed for every inter-1ode @ handover for the 2" (and optionally le acy P") connected &3s. <t has been claimed in the past that there could be interruptions to 2" voice with this mechanism. <f this is true then it does not seem desirable to reBuire this to be performed very often' as it may de rade the Buality of the voice service. <t is Buestionable as to whether we want to modify the le acy M"2s (and optionally "G"1s) to allow more <u-2" lin#s to be connected. <t may not be desirable to have .TM connectivity to the HeE"P.H 1ode @. This would mean that the security for the 2" connected &3s is in the eE"P. 1ode @' which a ain needs to be discussed with ".3.

7.2.2 0o&&'ps n8 on&# &e8'c# 0R40 n!o 4ode 6

<n this option' the <u-2" would still be connected to the le acy "+12' but the le acy "+12 has <ur connectivity to the eE"P. 1ode @.

3GPP

Release '

0( ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.8.8-;4 Only le acy 2+12 collapsed into eE"P. 1ode @ This would rely on <ur connectivity to each eE"P. 1ode @. Eence at least all 2"-connected (and optionally le acy P" connected) &3s beneath an eE"P. 1ode @ would reBuire an <ur connection directly from call setup4 There would be some chan es needed here to the 3GPP specifications to allow call setup to be performed immediately via <ur' but it is anticipated that this chan e is only needed to the A+12 functionality (hence only chan in the eE"P. 1ode @ in the collapsed architecture). Khilst the problem of dimensionin the M"2 is ta#en away' there may be some issues with the number of drift +12 connections that the "+12 is dimensioned for. Eowever <P connectivity to eE"P. 1ode @ may ma#e this less of an issue. 1etwor# Mana ement would probably be more of an issue in a multi-vendor environment' as there are problems today in that valuable cell information related to the &3 conte9t that is located in the "+12 (call handlin parameters) cannot be acBuired via multi-vendor <ur. Eence this may cause some issues for operators' and may need to be solved if this architecture was considered desirable. 0or inter-eE"P. 1ode @ mobility' <ur could be e9tended to the tar et 1ode @' as in mobility to a between two drift +12s today. This procedure may allow a more seamless mobility. .lternatively' the "+1" +elocation procedure would need to be updated to allow it to be performed to a tar et node that is not the current drift +12. "ecurity for the 2" (and optionally le acy P") users does not need to be performed in the eE"P. 1ode @' and because the "+12 only has &3 conte9ts' it may be more scalable.

7.2.3 4o! co&&'ps n8 'n# of !2e &e8'c# 0S ne!wor? n!o !2e 4ode 6
<n this option' neither the "+12 nor 2+12 for the le acy 2" (and optionally le acy P") &3s are collapsed into the eE"P. 1ode @. This has the benefit of no chan es to <ur or <u-2" dimensionin or specifications' and it is li#ely that 1K mana ement handlin would be simpler to envisa e with the e9istin ".) models.

3GPP

Release '

03 ,'*-*. ((--'/.( 3GPP TR ()*+++

<n case 1ode @ contains both evolved "+12=2+12 functions of the evolved architecture (fi ure :.;.6-3)' resource conte9ts would be split between le acy 2+12 and eE"P. 1ode @. Eence admission control would happen in two locations for the HsameH cell. There would probably need to be some modifications to the <ub to enable this to be handled' and it should be studied as to whether the ali nment of cell resource handlin can be performed effectively without reBuirin lar e amounts of si nallin to be passed across the <ub.

0i ure :.8.3-;4 1on-collapsed le acy +12 - eE"P. control plane in the 1ode @ <n case eE"P. 2ontrol Plane functions are #ept in the le acy +12 (fi ure :.;.3-8)' <ub should not reBuire any specific modification since admission control would entirely stay in +12 as in current +elease (.

3GPP

Release '

00 ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.8.3-84 1on-collapsed le acy +12 - eE"P. control plane in the le acy +12

7.3 S,ppor! of 3A >'cro D (ers !# 0o$% n n8

7.3.1 F&'! e(o&(ed 3TR)4 'rc2 !ec!,res
0lat evolved &T+.1 architectures (fi ures :.;.8.3 and :.;.6) are able to support &, Macro Aiversity 2ombinin (MA2)' by locatin this functionality in the 1ode @. <n this scenario are defined a servin 1ode @ and one (or more) drift 1ode @(s)' where the servin 1ode @ performs the combinin of &, data flows. .n <ur interface is needed between 1ode @s to convey data flows to the servin 1ode @. The node @ is then connected with an <u interface to the core networ# correspondin entity. Aetails of the procedures and lo ical interfaces in the &ser and 2ontrol Plane are 00". 0i ure :.3-; describes the related lo ical architecture' when two 1ode @s are involved.
FGS4

co$% ned f&ow

+, +,r

46
co$% n n8

46

39

0i ure :.3.;-;4 &, MA2 lo ical architecture (two 1ode @s involved) .n issue related to this solution is that it may cause an increase in latency and in traffic load in the access transport networ#. <ncreased latency is due to the need for the servin 1ode @ to receive drift 1ode @(s) flowsG increased traffic load may be due to the presence over one or more lin#s' dependin on the access transport networ# architecture' of drift 1ode @(s) flow(s) and of the combined flow. 0i ure :.3.;-8 shows a very basic e9ample of transport networ# deployment to better clarify this aspect. 0or comparison purposes also the correspondin +12 based architecture is shown on the left with a similar transport networ# deployment.
FGS4
co$% n n8 co$% n n8

FGS4
co$% ned f&ow

R40

0o$% ned f&ow

2'

2%

3. 0o$% ned f&ow

Ro,!er5Sw !c2
2

Ro,!er5Sw !c2
1' 1%
3C co$% ned f&ow

46

46

co$% n n8

46

46

39 39

39

0i ure :.3.;-84 &P paths in &, MA2 at 1ode @ in a basic transport networ# architecture The analysis of these issues lead to the conclusion that w.r.t. latency' a flat evolved &T+.1 architecture as depicted in fi ure :.3.;-3 may result in similar performance as in the traditional architecture when the &, MA2 is used.

3GPP

Release '

0) ,'*-*. ((--'/.( 3GPP TR ()*+++

2oncernin traffic load' similar performance can only be achieved provided that the affected last mile is properly dimensioned for hi her traffic load. <n terms of optimal use of the transport resources' it has to be considered that the real impacts on transport networ# dimensionin and additional latency' actually depend on deployed transport networ# architecture and related technolo ies. <n this perspective' if E"P. evolution is tar eted to support hi h bit-rate and capacity future scenarios' networ# dimensionin and topolo y could be evaluated accordin ly' by means of hi h performance technolo y and distributed transport architectures' accordin to Operators$ deployment strate ies. .s further evaluation criterion it has to be considered that the usa e of &, MA2 depends on deployment scenarios accordin to the Operator$s strate ies. "ome of these scenarios mi ht reBuire a limited usa e of &, MA2 (e. . pico and=or indoor covera e)' and then the potential impact of the abovementioned issues would be further limited. "ome improvement methods based on e9chan e of inband info between 1ode@s may also be considered and introduced to decrease the traffic load for &, MA2 in "ervin 1ode @. (+3-*(;76() The followin procedure is an e9ample of such an improvement to reduce the latency and traffic load. ;) <f 2+2 chec# is correct in the servin 1ode @' the servin 1ode @ sends its pac#ets directly to 9G"1 and MA2 procedures endG <f 2+2 chec# is wron ' the servin 1ode @ sends notifications to the drift 1ode @s in the active set and MA2 procedures continue.

.fter receivin the notification' those drift 1ode @s' which have the ri ht 2+2 chec#' send their pac#ets to the servin 1ode @. The servin 1ode @ selects one of the correctly received pac#ets and sends it to 9G"1. <n fi ure :.3.;-3' it illustrates the above procedures in the scenario with one servin 1ode @ and one drift 1ode @. 1oted that in flat evolved E"P. architectures' <ur interfaces are remained between 1ode @s.

0i ure:.3.;-34 &, MA2 in 3volved E"P. .rchitecture <n the above procedures' only when 2+2 chec# in the servin 1ode @ is wron ' those drift 1ode @s which et the correct pac#ets will forward data to the servin 1ode @. Otherwise there is no additional latency and traffic load occurred between 1ode @s due to MA2. 2onsiderin that for most of the time the servin 1ode @ has the best channel Buality' it is hi hly possible that the servin 1ode @ ets the correct 2+2 chec# and no further action is needed for MA2. 3ven in the occasional case that the servin 1ode @ receives the wron pac#ets' the latency and traffic load between 1ode @s are still comparable to the traditional way. The few bits overhead on the notification messa e is worthwhile for a si nificant reduction of the overall latency and traffic load between 1ode @s.

3GPP

Release '

01 ,'*-*. ((--'/.( 3GPP TR ()*+++

1OT34 1OT34 1OT34

<t is 00" what is the impact of the increase of the standard deviation of the latency in the networ#. "imulations need to be performed durin related studies. The impact of this scheme on 2P processin needs further studies. "ome simulation for verification is needed.

7.* R40 +D 9F!ens on

The problem of insufficient +12 <A number space was identified and it was a reed to e9tend the ran e of the +12 <A. .s a solution for the e9tension of the number space' it was a reed to increase the bit len th of the +12-<A from ;8bits to ;(bits by introducin a new <A with ;(bits-len th ' and to introduce an ,+tended RNC ID <3 into the relevant specifications. Khile the ma9imum number of +12s within one P,M1 in the current specification is 6*7(' the introduction of the new <3 allows a ma9imum of ())3( (6*7(4le acy +12 <A 5 (;66*4 e9tended +12-<A) +12s to be deployed in one P,M1 in the future.

7.*.1 So&,! on for R40-+D 9F!ens on

The 39tended +12-<A is only introduced into the networ# internal si nallin specifications' e. . +.1.P between +12 and 21 and does not reBuire any chan es to the ++2 protocol so that le acy &3s can operate in an +1" which is confi ured to use an e9tended +12 <A. This is possible by partitionin the 38bits of the &-+1T< in a different manner in +1" which is confi ured to use the e9tended +12-<A. Thus some bits of the "-+1T< (8*bits) part of the &-+1T< are used to e9tend the "+12-<A part in the +1" usin the e9tended +12-<A. Therefore' the e9tension for the "+12-<A in the networ# is not visible for the &3. .s specified today' the &3 always treats the 38 bit to ether as &-+1T<.

0i ure :.6.;-;4 <nterpretation of &-+1T< in &3 side and +.1 side is confi ured to use the e9tended +12 <A .s the same lo ic is applied for 2ell <dentity' 6M"@ of the ;(bit 2-<A are used as an e9tension of +12-<A. Thus under the +12 usin the e9tended +12-<A' the bits available for the 2-<A are reduced to ;8bits (6*7().

0i ure :.6.;-84 <nterpretation of 2ell identity (T &2-<A) in &3 side and +.1 side is confi ured to use the e9tended +12 <A

3GPP

Release '

0' ,'*-*. ((--'/.( 3GPP TR ()*+++

The number of &3s and cells in one +1" usin the e9tended +12-<A are different from the one usin the current +12 <A as shown in the table below since the 6bits used for the "-+1T< and 2ell <A are used as part of e9tended +12-<A in the +1".
T2e n,$%er of 39s n R4S T2e n,$%er of 39s for +n!er-R)T <'! once n R4S T2e n,$%er of ce&&s n R4S 5urrent RN5/;% 1 0*8 57/ 1 02* /5 53/ =&tended RN5/;% /5 53/ /* * 09/

7.*.2 Spec f c'! on +$p'c!

The followin is the list for reBuired chan es for introducin the +12-<A 39tension scheme. %S*5.--': .ddition of te9t for referrin to +.13 specification in semantics description in &-+1T<.

%S*5./'-: <ntroduction of an ,+tended RNC-ID <3 into Messa e=<3 Groups which contain the RNC-ID <3.

%S*5./*-: <ntroduction of ,+tended RNC-ID <3 into Messa e=<3 Groups which contain +12-<A.

%S*5./--: <ntroduction of ,+tended RNC-ID <3 into UC-ID <3 which contains +12-<A.

%S*5./5-: <ntroduction of ,+tended RNC-ID <3 into UC-ID <3 which contains +12-<A.

%S/9.((9: <ntroduction of 39tended &T+.1 +12-<A into Messa e=<3 Groups.

%S/9.('9 <ntroduction of 39tended &T+.1 +12-<A into Messa e=<3 Groups.

7.*.3 R,&es for 0onf 8,r'! on

There are some limitations for confi urin networ# when the e9tended +12-<A scheme is used. The networ# confi uration shall follow all four rules as stated below to ether. "xplanation o terms 0egacy +,C 5 C,4 +12=21 do not comprehend=support the e9tended +12-<A <3="cheme' e. . Pre-+el: +12=21. .pgraded +,C 5 C,4 +12=21 comprehend=support the e9tended +12-<A <3="cheme and can distin uish which +12-<A scheme are used in the received messa e or sendin messa e based on the stored confi uration data. +$le'2: <n case relocation needs to be supported to=from an +12 usin the e9tended +12-<A' it is recommended to connect the source and tar et +12s to the same up raded 21 to reduce the number of up raded 21. <n case 21 cannot be up raded' it is recommended to use le acy +12-<A under that 21. (39ample in fi ure :.6.3-;) +$le*2: 1ot confi ure the <ur interface connection between le acy +12 and up raded +12 usin the e9tended +12-<A.

3GPP

Release '

02 ,'*-*. ((--'/.( 3GPP TR ()*+++

+$le-2: <n case +12s with le acy +12-<A and +12s with e9tended +12-<A co-e9ist in the networ#' confi ure the le acy +12-<A so that le acy +12-<A will not be the same as the ;8 bit of M"@ of any of e9tended +12-<A to which the le acy +12 may have <ur connection. ("ee the fi ure :.6.3-3 and :.6.3-6) +$le/2: <n case a &+. spanned over multiple +12s with e9tended +12-<A and the +12s have different capability on E"A"2E reception in &+.NP2E state' the +12s capable of E"-A"2E reception in &+.NP2E state shall not have the same ;8bit M"@ in their e9tended +12-<A compared to the +12s not capable of E"-A"2E reception in &+.NP2E. ("ee fi ures :.6.6-) and :.6.3-() 3epiction o Con ig$ration +$les
04 M 1 04 M 2

?nl$ 5N @ . needs to <e upgraded to understand .1<it RN5/ ; %

; ) 3 8

R)4 1 'nd * w !2 12-% ! R40-+D

PS on&# R)4 2 'nd 3 w !2 1/-% ! R40-+D

0i ure :.6.3-;4 2onfi uration e9ample for +ule ; and 8

3GPP

Release '
04 M 1

0+ ,'*-*. ((--'/.( 3GPP TR ()*+++

04 M 2

; ) 3 8

5N @ . and 5N @ ( need to <e upgraded to understand .1<it RN5/; %

R)4 1 'nd * w !2 12-% ! R40-+ D

PS on&# R)4 2 'nd 3 w !2 1/-% ! R40-+D

0i ure :.6.3-84 2onfi uration e9ample for +ule ; and 8.

0i ure :.6.3-34 Problematic confi ulation e9ample (does not follow +ule3)

3GPP

Release '

)- ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.6.3-64 2onfi uration e9ample for +ule3

0i ure :.6.3-)

Problematic confi ulation e9ample (does not follow +ule6)

3GPP

Release '

). ,'*-*. ((--'/.( 3GPP TR ()*+++

7ig$re :./.-6;

Con ig$ration example or +$le/

7.*.* 0onf 8,r'! on 9F'$p&e

The +12 <A confi uration e9ample below is followin the rules listed in :.6.3-; and showin the confi uration in fi ure :.6.3-8 in a lar e scale.
R40I) --6 (3p8r'ded !o Re&7)
% +, ,r +
46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) e46 (f2) --A0 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) e463 (f2) --53 46 (f1) 46 (f1) 46 (f1) 46 (f1) e46 (f2) --50 46 (f1) e46 (f2) --5( 46 (f1) 46 (f1) e46 (f2) --5. 46 (f1) 46 (f1) e46 (f2) --A3 46 (f1) e46 (f2) --A( 46 (f1) e46 (f2) --A. 46 (f1) 46 (f1)

46 (f1) 46 (f1) 46 (f1) 46 (f1) e46 (f2) 00)5

-(er&'# ce&&
+ ,%

4on--(er&'# ce&&

R4SI)

46 (f1) 46 (f1)

+,r

+,%
+,%

R40I6 -.6 (3p8r'ded)

R4SI6

46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) 46 (f1) e46 (f2) --60 46 (f1) 46 (f1) e463 (f2) --63 46 (f1) e46 (f2) --6( 46 (f1) 46 (f1) e46 (f2) --6. 46 (f1) 46 (f1)

R4SI0
+,r

R40I0 --A (3p8r'ded)

+,%

3GPP

+, %
46 (f1)

Release '

)( ,'*-*. ((--'/.( 3GPP TR ()*+++

0i ure :.6.6-;4 /alid +12 <A 2onfi uration 39ample

7.5 A'#er 2 9n2'nce$en!s

7.5.1 F&eF %&e RA0 PD3 s Nes 'nd >)0-2s se8$en!'! on
7.5.1.1 Gener'& descr p! on

E"P. 3volution is tar etin both hi her bit rates and spectrum efficiency. Eowever' the current &T+. ,ayer 8 architecture is not optimised for bit rates hi her than ;6Mbps (M<MO and potential other technolo ies li#e (6F.M provides data rates beyond ;6Mbps). The problem stems from that .M +,2 uses a fi9ed +,2 PA& si!e. <n order to avoid +,2 window stallin the +,2 PA& si!e needs to be increased which leads to e9cessive paddin and covera e issues. This ri idity in the ,ayer 8 protocol means that both lin# adaptation and cell covera e will be sub-optimal when hi her bit rate schemes are bein considered. The current ,ayer 8 overhead of fi9ed +,2 "A& se mentation and M.2-hs layer paddin also poses a problem for the E"P. 3volved system efficiency. . solution to reach hi h data rates and reduce protocol overhead and paddin is to apply fle9ible +,2 PA& si!es in downlin#. The support of fle9ible +,2 si!es could also be made available for the &,. "imilarly to the downlin#' this will lead to performance improvement in the support for hi her data rates' reduced protocol overhead and paddin in the uplin#. 3nhancement of the ,ayer 8 protocol in the conte9t of E"P. evolution will consider the followin points4 +0C: The +,2 .M protocol is evolved into supportin fle9ible PA& si!es. )AC: The M.2-hs protocol is evolved into supportin +,2 PA& se mentation. The support for the +,2 PA& se mentation in M.2-e and M.2-es protocols is 00". These two principles also mean that the M.2 and +,2 headers desi ned for the current operation of ,ayer 8 will have some overhead that could be optimised. 0or +,2' the concatenation function currently creates the need for the ,en th <ndicator field which creates : or ;) bits overhead dependin on PA& si!e. 0or PA& si!es reater than ;8( octets the ;) bit is mandated and all PA&s use same ,< len th. . M.2-hs capable of se mentin =concatenatin +,2 PA&s would ma#e the +,2 ,< information redundant. Therefore' the removal of +,2 concatenation is considered. <n addition' the usa e of the 2=T field in the M.2 header is only strictly necessary for the mappin of a radio bearer to A2E. .lthou h it is used for E"-A"2E' it was removed in +el-( for 3-A2E. To avoid reBuirin that the M.2-hs se mentation supports se mentation (and concatenation in receiver) of octect ali ned "A&s and non octet ali ned "A&s dependin on the confi uration the removal of the 2=T M.2-d header field is considered. The multiple9in of multiple lo ical channels into one M.2-hs PA& and multiple PA&s of different si!es from the same lo ical channel would be identified on the M.2-hs header. @eyond these basic principles' there are some possibilities of how the ,ayer 8 could wor#' and these can be divided into two roups as described in the sub-clauses below.

7.5.1.2

A'#er 2 w !2o,! )RO s,%-&'#er

The M.2-hs se mentation provides enou h ranularity for the lin# adaptation and cell covera e. +esidual errors of E.+F protocol are recovered at the +,2 level as today. The +,2 .M relies on havin a ma9imum si!e confi ured and operates with variable octet ali ned si!es (i.e. all payload si!es between one octet and the confi ured ma9imum are possible). The ma9imum si!e is confi ured as a tradeoff between overhead of potential +,2 PA& retransmissions and +,2 PA& headers per +,2 "A&. Optionally' a reportin from the 1ode @ to the +12 would allow some adaptability of the ma9imum confi ured si!e.

3GPP

Release '

)3 ,'*-*. ((--'/.( 3GPP TR ()*+++

7.5.1.3

A'#er 2 w !2 new )RO s,%-&'#er

The M.2-hs se mentation provides enou h ranularity for the lin# adaptation and cell covera e. Eowever' in this option the E.+F failures are recovered by a .+F sub-layer located in 1ode @. The +,2 .M relies on havin a ma9imum si!e confi ured and operates with variable octet ali ned si!es (i.e. all payload si!es between one octet and the confi ured ma9imum are possible). The ma9imum si!e is ali ned to the +,2 "A& si!e. The +,2 +TT can be increased. There are two options for the .+F sub-layer4 The M.2-hs in the &3 upon detectin a E.+F failure can reBuest the retransmission of a M.2-hs PA& of a specific T"1. The 1ode @ stores transmitted M.2-hs PA&s for a iven time' until the &3 no lon er reBuests that T"1. The +,2 is split between the 1ode @ and +12 such that the lower +,2 can provide faster retransmissions of missed +,2 PA&s' and the upper +,2 will avoid data loss durin mobility. "ome synchroni!ation of these two +,2 entities would be reBuired and the interpretation of the +,2 "tatus PA&s sent by the receiver is 00".

7./ 3A 9n2'nce$en!s
7./.1 9n2'nce$en! for RoT con!ro& for Vo+P
The +el-( 3-A2E that offers ++2 based control of non-scheduled traffic by the ++2 based E.+F process reservation mechanism. Eowever' the si nallin overhead and latency of the ++2 si nallin method is not suitable for +oT control. 0ast E.+F processes activation and deactivation is available for scheduled traffic' but the ,; si nallin overhead and delay associated with the schedulin reBuest and schedulin rant procedure is also inefficient for /o<P services. There are two options for enhancement of non-scheduled operation with improved control of transmission time instants4 Ti ht control of transmission time instants with enhanced ,; si nallin . ,oose control of transmission time instants with a &3 rule based approach.

@oth options may utili!e enhanced ++2 si nallin for setup and reconfi uration. Potential improvements of +oT control will be studied ta#in the application of 2ontinuous Pac#et 2onnectivity (2P2) solutions as a baseline. The wor#in of both options shown above with the 2ontinuous Pac#et 2onnectivity schemes is 00".

7.7 R'd o Re&'!ed 9n2'nce$en!s

1OT34 TAO2 +eferences need to be added for these items. E"P. 3volution consists of si9 radio related enhancements' which include4 ;) Multiple <nput = Multiple Output (M<MO).

2ontinuous 2onnectivity for Pac#et Aata &sers (2P2). Aownlin# Ei her Order Modulation usin (6F.M for E"AP.. &plin# Ei her Order Modulation usin ;(F.M for E"&P.. <mproved ,ayer-8 "upport for Ei h Aata rates. 3nhanced 2ell 0.2E.

3GPP

Release '

)0 ,'*-*. ((--'/.( 3GPP TR ()*+++

7.7.1 >,&! p&e +np,! 5 >,&! p&e -,!p,! (>+>-)

The purpose of M<MO is to improve system capacity and spectral efficiency by increasin the data throu hput in the downlin# within the e9istin )ME! carrier. This will be achieved by means of deployin multiple antennas at both &3 and 1ode-@ side. The technical objective is the inte ration of M<MO functionality in &T+.' to improve capacity and spectral efficiency. The wor# tas#s include the support for both 0AA and TAA. <n those cases where differences between 0AA and TAA are identified' they should be considered as separate wor# tas#s. The followin are associated with this feature4 M<MO Physical ,ayer. M<MO ,ayer 8 and 3 Protocol .spects. M<MO &T+.1 <ub Protocol .spects. M<MO +0 +adio Transmission= +eception' "ystem Performance +eBuirements and 2onformance Testin . <mproved ,8 support for hi h data rates.

7.7.2 0on! n,o,s 0onnec! ( !# for P'c?e! D'!' 3sers (0P0)

Pac#et-oriented features li#e E"AP. and 3-A2E in K2AM.=&MT" systems will promote the subscribers$ desire for continuous connectivity' where the user stays connected over a lon time span with only occasional active periods of data transmission' and avoidin freBuent connection termination and re-establishment with its inherent overhead and delay. This is the perceived mode a subscriber is used to in fi9ed broadband networ#s (e. . A",) and a precondition to attract users from fi9ed broadband networ#s. To support a hi h number of E"AP. users in the code limited downlin# the feature 0-AP2E was introduced in +3,-(. <n the uplin#' the limitin factor for supportin a similarly hi h number of 3-A2E users is the noise rise. 0or such a hi h number of users in the cell it can be assumed that many users are not transmittin any user data for some time (e. . for readin durin web browsin or in between pac#ets for periodic pac#et transmission such as /o<P).The correspondin overhead in the noise rise caused by maintained control channels will si nificantly limit the number of users that can be efficiently supported. .s completely releasin dedicated channels durin periods of temporary traffic inactivity would cause considerable delays for reestablishin data transmission and a correspondin bad user perception' this K< is intended to reduce the impact of control channels while maintainin the A2E state and allowin a much faster reactivation for temporarily inactive users. The objective of this wor# item is to reduce the overhead of physical control channels or related si nalin messa es of pac#et data users for both real-time (e. . /o<P) and non real-time services' e. . for users which have temporarily no data transmission in either uplin# or downlin#. Pac#et data users as considered in this wor# item are usin only E"A"2E=3-A2E channels without &, APA2E and A, AP2E. 0ocus will be on the uplin#' but reduction of overhead in downlin# can be considered as well. The aim is to si nificantly increase the number of pac#et data users in the &MT" 0AA system that can be #ept efficiently in 23,,NA2E state over a lon er time period and that can restart transmission after a period of temporary inactivity with a much shorter delay (U)*ms) than would be necessary for reestablishment of a new connection. Mobility aspects should be ta#en into account and mobility performance not be de raded. ,in#ed wor# items include4 a) Aelay optimisation for procedures applicable to 2" and P" 2onnections.

7.7.3 Down& n? < 82er -rder >od,&'! on ,s n8 /* O)> for <SDP)

The use of (6F.M in the downlin# is an attractive complement to multi-antenna techniBues (M<MO) in the downlin#' e. . in scenarios where deployment of M<MO is not possible. The feasibility of (6F.M for E"AP. has been studied as part of the study item H0uture "cope of 0AA E"P. 3volutionH and si nificant ains were observed by the provision of (6F.M in scenarios (cells with isolation) where users can benefit in terms of increased throu hput from favourable radio conditions such as in well tuned outdoor systems or indoor system solutions. The objective of this wor# item is to specify the support of (6F.M as a downlin# modulation scheme for E"AP. in 0AA' and this includes4 a) "pecification of ,; aspects of (6F.M.

"pecification of ,8=,3 aspects of (6F.M. "pecification of <ub=<ur support for (6F.M.

3GPP

Release '

)) ,'*-*. ((--'/.( 3GPP TR ()*+++

"pecification of @" and &3 reBuirements for (6F.M for an a reed set of radio conditions=environments. +eBuirement set point to ta#e the @T" impairments into account.

This wor# item will define the (6F.M operation for the Type <<=<<< &3s. "ome provisions may ta#e place in the si nallin structures for the (6.M operation with M<MO. The followin are associated with this feature4 a) <mproved ,8 support for hi h data rates.

7.7.* 3p& n? < 82er -rder >od,&'! on ,s n8 1/ O)> for <S3P)

Kith the introduction on multi-antenna techniBues (M<MO) or (6F.M in the downlin#' hi her data rates can be provided for users in favourable conditions. To match the increased downlin# throu hput' the introduction of ;(F.M in the uplin# is an attractive addition to the enhanced uplin# concept' providin the users also with increased uplin# data rates. The feasibility of hi her order modulation for E"&P. has been studied as part of the study item H0uture "cope of 0AA E"P. 3volutionH and si nificant ains in terms of increased throu hput were observed by the provision of ;(F.M in scenarios (cells with isolation) where users can benefit from favourable radio conditions such as in well tuned outdoor systems or indoor system solutions. The objective of this wor# item is to specify the support of ;(F.M as a uplin# modulation scheme for E"&P. in 0AA' this includes4 a) "pecification of ,; aspects of ;(F.M' includin applicable combinations of ain factors.

"pecification of ,8=,3 aspects of ;(F.M. "pecification of <ub=<ur support for ;(F.M. "pecification of @" and &3 reBuirements for an a reed set of radio conditions=environments for ;(F.M. "pecification of +adio +esource Mana ement reBuirements. @" reBuirements to be done with more advanced receivers' i.e. more advanced than +.%3.

7.7.5 +$pro(ed A'#er-2 S,ppor! for < 82 D'!' r'!es

The introduction of M<MO will si nificantly increase the data rates of the E"AP.' and various other improvements' such as hi her order modulation tar eted for E"P. evolution will further increase the A, data rates. <t is #nown from the wor# on E"AP. that the +,2 pea# data rate is limited by the +,2 PA& si!e' the +TT and the +,2 window si!e. 0or reasonable +,2 PA& si!es' such as 38* or (6* bit' the +,2 protocol can not sustain the current pea# data rate of the physical layer in E"-A"2E. 0or increased data rates achieved by M<MO and other improvements' it is li#ely that the limitations of the +,2 are even more pronounced' leadin to a situation' in which the +,2 protocol is the bottlenec# of the system. Therefore' in T+ 8).777 it is proposed to introduce support for fle9ible +,2 PA& si!es and M.2 se mentation in downlin# in order to reach hi h data rates and reduce protocol overhead and paddin . .s it is clear that chan es to the lin# layer protocols are needed already with the introduction of the M<MO' it would be beneficial to adopt future proof solutions that are envisioned to incorporate already in +elease : all necessary chan es to support hi h data rates in the lin# layer protocols. <n order to facilitate easy deployment of the enhanced protocols' as well as bac#ward compatibility' the methods to enhance transition between old and new PA& formats should be evaluated. The objective of this wor# item is to provide necessary modifications to +el-: specifications to4 a) .llow lin# layer support for hi h data rates in downlin# by4

<ntroducin support for fle9ible +,2 PA& si!es. <ntroducin M.2-hs multiple9in . <ntroducin M.2-hs se mentation. Provide a sin le ,8 protocol evolution for all performance enhancements. 3valuate the necessity to support M.2-d multiple9in and +,2 concatenation. .llow smooth transition between old and new protocol formats. The lin# layer support for hi h data rates in the uplin# may be provided in a separate wor# item in a later phase.

3GPP

Release '

)1 ,'*-*. ((--'/.( 3GPP TR ()*+++

The followin are associated with this feature4 a) M<MO' (6F.M for E"AP. (0AA).

7.7./ 9n2'nced 0e&& F)0<

<n a modern telecommunication networ# such as &MT"' the aim of the operator is to offer hi h Buality of service to users. The Fuality of "ervice is the collective effect of service performances' which determine the de ree of satisfaction of a user of a service. &nder the eneral headin of Buality of e9perience (Fo3) one of the more noticeable points faced by the user is the apparent delay in set up or channel allocation times for different connections includin response times of different P" data connections. .s analysed in T+ 8).?;)' the setup delays on P" and also 2" domain can be si nificantly reduced by usin E"P. for "+@s. Therefore' the wor# for this K< should be to reduce latencies of &T+.1 and should concentrate on' how the E"P. resources can be activated for the &3 in most efficient manner. <n addition' wor# should consider how the data rates available in 23,,N0.2E can be increased to reduce si nallin latencies as well as address the cases where the usa e of 23,,NA2E state is not preferred by the networ#. This could be due to hi h interest on Halways onH type services li#e Po2' Push email and /P1 connections' which introduce freBuent but small pac#ets to be transmitted between &3 and server. 0urthermore' the 23,,N0.2E may become capacity bottlenec# when 23,,NA2E capacity is increased by wor# done in 2ontinuous Pac#et 2onnectivity K<. <n li ht of continuous pro ress to pac#et optimised radio to ether with 1ode @ based schedulin ' the use of E"AP. in 23,,N0.2E state should be investi ated to obtain smaller si nallin delays and hi her bit rate in 23,,N0.2E state. The objectives of this wor# item is to provide necessary modifications to +el: specifications improvin the 23,,N0.2E state by4 a) <ncrease the available pea# rate for &3s in 23,,N0.2E state' e. . by utilisin E"AP. in 23,,N0.2E state.

+educe the latency of user and control plane in the 23,,N0.2E' 23,,NP2E and &+.NP2E state by hi her data pea# rate. +educe state transition delay from 23,,N0.2E' 23,,NP2E and &+.NP2E state to 23,,NA2E state. .llow lower &3 power consumption in 23,,N0.2E state by discontinuous reception. <n addition' the wor# should uarantee that followin objectives are met4 a) b) c) <mprovements to address the delay reBuirements defined in 8).?;)' section ) are ac#nowled ed durin technical desi n. &3 possibilities to perform necessary <nter 0reBuency and +.T measurement. The comple9ity and bac#ward compatibility are considered.

<n addition' this wor# should consider the enhancements provided by 2ontinuous Pac#et 2onnectivity (2P2)' to achieve best suited solutions in the areas they may overlap.

7.7.7 +n!erference 0'nce&&'! on (F,r!2er $pro(ed $ n $,$ perfor$'nce re1, re$en!s for 3>TS5<SDP) 39)
. study item (see note) for further improved minimum performance reBuirements for &MT"=E"AP. &3 (0AA) was approved at the 3GPP +.1 M3* meetin . Kor# has been on oin in +.16 since that time to assess the feasibility of both one-branch and two-branch interference cancellation=miti ation receivers. These receivers attempt to cancel the interference that arises from users operatin outside the servin cell. This type of interference is also referred to as $other cell$ interference. <n past lin# level evaluations' this type of interference has been modelled as .KG1' and as such can not be cancelled. The study item has developed models for this interference in terms of the number of interferin 1ode @s to consider' and their powers relative to the total other cell interference power' the latter ratios referred to as Aominant <nterferer Proportion (A<P) ratios. A<P ratios have been defined based on three criteriaG median values of the correspondin cumulative density functions' wei hted avera e throu hput ain' and field data. 1OT34 "ee +P-*):(6' H0urther <mproved Performance +eBuirements for &MT"=E"AP. &3H.

3GPP

Release '

)' ,'*-*. ((--'/.( 3GPP TR ()*+++

<nterference aware receivers' referred to as Type 8i and Type 3i' were defined for Type 8 and Type 3 receivers' respectively. E"AP. throu hput ains for the Type 3i receiver were found to be si nificant for A<P ratios based on the wei hted avera e throu hput ain and field data at low eometries. 0or e9ample' the ains for the A<P ratios based on the wei hted avera e ran ed from a factor of ;.8 to 8.*) for FP"% E-"3T( P@3' and from ;.8 to 3.*8 for /.3* for networ# eometries of -3 and * d@. "ystem level studies indicated that a Type 3i receiver provided si nificant ains in covera e ran in from 8*-))V dependin upon the channel and user location. <n addition' the Type 3i receiver is based upon #nown and mature si nal processin techniBues' and thus' the comple9ity is minimi!ed. Kith two-branch' eBuali!er-based receivers already available in today$s mar#etplace' it appears Buite doable to develop a two-branch eBuali!er with interference cancellation=miti ation capabilities. Given the above' it is our conclusion that two-branch interference cancellation receivers are feasible for E"AP.' and that we can now be in to transition this portion of the study item effort to a wor# item. To pro ress this effort alon ' we recommend the use of the type 3i receiver as the reference receiver for definin the new specification values that will be included in T" 8).;*;.

7.8 >6>S
<n implementin the +( feature M@M" over .rchitecture 8' a number of issues have been identified4 )B)S .ser Plane !ss$es: The establishment of M@M" <u &ser Plane to in eE"P. 1ode@s will increase load on the transport lin#s that handle the le acy <u interface. Therefore an efficient method of M@M" user pac#et delivery is reBuired. <t is unclear if synchronised delivery of M@M" data via PTM for the purposes of soft-combinin C a ain in the inter-1ode@ soft-combinin case C is possible in an .rchitecture 8 deployment. <t should be verified that if <P Multicast were employed as the method of M@M" user data delivery that this is sufficient to ensure radio layer synchronisation in the inter-1ode@ soft combinin scenario. )B)S Control Plane !ss$es: &sin .rchitecture 8' co-ordination of dynamic soft combinin provision on an HinterH-1ode@ level seems only to be possible if MT2E confi uration and schedulin is confi ured in a static fashion (i.e. always PTM) across all 1ode @s. 1ew procedures mi ht be needed to enable this full dynamic provision of soft combinin at inter-1ode@ level. 1ote that whilst soft combinin between cells is not essential for M@M" to wor#' it is seen as beneficial for radio efficiency reasons and thus dynamic M22E D MT2E confi uration updates in nei hbourin 1ode @s would be reBuired. 1ote however' co-ordination and provision of soft combinin area on an HintraH-1ode@ level remains possible usin .rchitecture 8.

0onc&,s ons 'nd Reco$$end'! ons

0our .rchitectural variants have been assessed' the outcome is captured Table : and resulted in introducin protocol support for a deployment scenario (H.lt.6H in Table :) where +12 functionality is mer ed with the 1ode@. "ome functions for this scenario' were a reed to be introduced for +elease : durin the study item phase under T3<:. <n addition the followin more detailed a reements were reached.

8.1 +ndependence 6e!ween R'd o Fe'!,res 'nd <SP) )rc2 !ec!,re 9(o&,! on
The potential E"P. .rchitecture evolution will be defined independently from enhancements in the E"P. radio interface (both layer ; and radio protocols). Thus' the traditional &T+.1 interfaces (<u' <ur and <ub) shall be enhanced in order to support the features included in the evolved E"P. radio interface. Eowever this does not preclude the

3GPP

Release '

)2 ,'*-*. ((--'/.( 3GPP TR ()*+++

possibility to introduce new features in the E"P. radio interface' in case they are beneficial mainly to one of the architectures.

8.2 +P >,&! c's! for >6>S 3ser P&'ne

Kith respect to any .rchitecture 8 implementation' it is recommended that to overcome the establishment of many M@M" <u &ser Plane to many more H+12sH i.e. the eE"P. 1ode@s' <P Multicast is implemented for reasons of transport delivery efficiencies. 0urthermore it is recommended that the ori inatin point in the distribution of content via <P Multicast be the GG"1.

8.3 0'rr er s2'r n8 scen'r o for 'rc2 !ec!,re '&!ern'! (e +, w !2 R40 3-P&'ne B 0-P&'ne f,nc! ons n 4ode-6
+e ardin the carrier sharin scenario' the followin a reements were made4 eE"P. +.1 interfaces the le acy &T+.1 via <ur interface in stead of via <ub to support the le acy 2" service in the architecture with +12 in 1ode@.

3GPP

Release '

)+ ,'*-*. ((--'/.( 3GPP TR ()*+++

)nneF )C 02'n8e 2 s!or#

Change history
3ate %S< = %S< 3oc. C+ +e# S$b>ect4Comment ?ld ,ew

8**(-*( 8**(-*( 8**(-*7 8**(-*7 8**(-;* 8**(-;; 8**:-*3 8**:-) 8**:-*7 8**:-*7 8**:-*7 8**:-;8 8**?-*3

+.1M38 +P-*(*87(

+.1M33

"#eleton /ersion - revised s#eleton - te9t proposal included as a reed in +P-*(*87: - te9t proposals included as a reed in +.13M)34 +3-*(;3;(' +3-*(;68(' +3-*(;68:' presentation to +.1M33 (as version *.3.*. "ame content as version *.*.3) editorials4 section numberin and styles accordin to draftin rules applied. Aocument moved up to +evision ;.*.*' additional chan es made to section 7 <ncorporated chan es from 0ebruary 8**: +.1 KG meetin sG /ersion ;.;.* presented at +.1 M3) and update to ;.8.* durin the meetin Presented for approval to Plenary Presented for approval to Plenary &pdate of the conclusion section @rou ht under chan e control - no technical chan e 3ditorial improvements <ntroduction of new 2onfi uration +ule for 39tended +12 <A "cheme

*.*.; *.*.8 *.*.3 *.3.* *.3.; ;.*.* ;.8.* 8.;.* 8.3.* 8.6.* :.*.* :.*.;

*.*.; *.*.8 *.*.3 *.3.* *.3.; ;.*.* ;.8.* 8.*.* 8.8.* 8.6.* :.*.* :.*.; :.;.*

+.1M36 +P-*(*LL +.1M3) +P-*:*86( +.1M3( +.1M3: +.1M3: +.1M3: +.1 M37 +P-*:*3;7 +P-*:*((( +P-*:*:(; +P-*?*;;( ***; ;

3GPP