ETSI TR 125 999 V7.1.0 (2008-04)

Universal Mobile Telecommunications System (UMTS); High Speed Packet Access (HSPA) evolution; Frequency Division Duplex (FDD) (3GPP TR 25.999 version 7.1.0 Release 7)

RTR/TSGR-0225999v710

General Information

• Status: Published
• Publication Date: 22-Apr-2008
• Technical Committee: 3GPP RAN 2 - Radio layer 2 specification and Radio layer 3 RR specification
• Current Stage: 12 - Completion
• Due Date: 08-Apr-2008
• Completion Date: 23-Apr-2008

Standards Content (Sample)

Technical Report
Universal Mobile Telecommunications System (UMTS);
High Speed Packet Access (HSPA) evolution;
Frequency Division Duplex (FDD)
(3GPP TR 25.999 version 7.1.0 Release 7)

3GPP TR 25.999 version 7.1.0 Release 7 1 ETSI TR 125 999 V7.1.0 (2008-04)

Reference
RTR/TSGR-0225999v710
Keywords
UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 2 ETSI TR 125 999 V7.1.0 (2008-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 3 ETSI TR 125 999 V7.1.0 (2008-04)
Contents
Intellectual Property Rights.2
Foreword.2
Foreword.5
1 Scope.6
2 References.6
3 Definitions, symbols and abbreviations .6
3.1 Definitions.6
3.2 Abbreviations.6
4 Introduction .7
5 Objectives.7
6 Constraints and requirements .8
6.1 Constraints.8
6.2 Requirements.8
6.2.1 Requirements for the UTRAN architecture .8
6.2.2 Requirements for the UTRA.9
7 Technical Proposals and Assessment.9
7.1 Architectural solutions.11
7.1.1 Current Release 6 Architecture - Alt 1.11
7.1.2 Iu with enhanced SRNC separate from the enhanced collapsed CRNC/DRNC/Node B – Alt 2.12
7.1.2.1 General description.12
7.1.2.2 User Plane.13
7.1.2.3 Control Plane (Radio part) .13
7.1.2.4 Control Plane (Interface part).14
7.1.2.5 Support of legacy UE.14
7.1.2.6 Support of legacy networks.15
7.1.2.7 Additional Information.16
7.1.2.8 Open issues.17
7.1.3 PS User Plane /Control Plane split, CP functions in RNC, direct UP tunnel PS CN – Node B – Alt 3.18
7.1.3.1 General description.18
7.1.3.2 Protocol architecture.19
7.1.3.3 Control plane.19
7.1.3.4 Support of legacy UEs .20
7.1.3.5 Interworking with legacy architecture.20
7.1.4 Iu with RNC U-Plane & C-Plane functions in Node-B – Alt 4 .20
7.1.4.1 User plane.21
7.1.4.2 Control plane.22
7.1.4.3 Support of legacy UEs .22
7.1.4.4 CS Service in stand-alone scenario .22
7.1.4.4.1 CS CN domain interworking with Gs interface deployed: .22
7.1.4.4.2 CS CN domain interworking without deployed Gs interface: .23
7.1.4.5 Interworking with legacy architecture.24
7.1.4.6 Paging.24
7.1.4.7 Soft Handover for Signalling Radio Bearers:.24
7.1.4.8 CS Service in Carrier Sharing scenario.25
7.1.4.8.1 Evaluation Table.25
7.1.4.8.2 Relocation to Legacy RNC (Iur-based solution) .26
7.1.4.9 Iu with RNC U-Plane & C-Plane functions in Node-B: Iu CS support permutations comparison .30
7.1.4.10 Load Balancing between the Legacy and HSPA+ Network.31
7.1.4.11 Security and ciphering.31
7.1.4.12 Open Issues.31
7.1.5 S1 interface architecture, i.e. SAE architecture with RLC (no-ciphering) & RRC in Node B .31
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 4 ETSI TR 125 999 V7.1.0 (2008-04)
7.1.5.1 Non-soft handover approach.31
7.1.5.1.1 Description of the architecture (from figure 7.1.5-1) .32
7.1.5.2 Soft handover approach.33
7.1.5.3 Support of legacy UEs .33
7.1.6 Evolved HSPA (Collapsed Architecture) with SHO – Considerations with connectivity to evolved
CN.34
7.1.6.1 General.34
7.1.6.2 Collapsed Architecture with connectivity to the evolved CN Approach.34
7.1.6.3 Pictorial Representation of Collapsed Architecture Approach.34
7.1.6.4 Description of architecture.35
7.1.6.5 Open issues.36
7.1.7 Enhanced SRNS relocation procedure.37
7.1.7.1 Network-controlled Mobility.37
7.1.7.2 UE-controlled Mobility.39
7.1.7.3 Open issues.40
7.2 Interworking with legacy UTRAN nodes.40
7.2.1 Collapsing legacy SRNC and CRNC into Node B .40
7.2.2 Collapsing only legacy CRNC into Node B .41
7.2.3 Not collapsing any of the legacy CS network into the Node B.42
7.3 Support of UL Macro Diversity Combining.44
7.3.1 Flat evolved UTRAN architectures .44
7.4 RNC ID Extension.46
7.4.1 Solution for RNC-ID Extension.46
7.4.2 Specification Impact .47
7.4.3 Rules for Configuration .47
7.4.4 Configuration Example.51
7.5 Layer 2 Enhancements .52
7.5.1 Flexible RLC PDU sizes and MAC-hs segmentation .52
7.5.1.1 General description.52
7.5.1.2 Layer 2 without ARQ sub-layer.52
7.5.1.3 Layer 2 with new ARQ sub-layer .52
7.6 UL Enhancements.53
7.6.1 Enhancement for RoT control for VoIP.53
7.7 Radio Related Enhancements .53
7.7.1 Multiple Input / Multiple Output (MIMO) .53
7.7.2 Continuous Connectivity for Packet Data Users (CPC).54
7.7.3 Downlink Higher Order Modulation using 64 QAM for HSDPA .54
7.7.4 Uplink Higher Order Modulation using 16 QAM for HSUPA.55
7.7.5 Improved Layer-2 Support for High Data rates .55
7.7.6 Enhanced Cell FACH .56
7.7.7 Interference Cancellation (Further improved minimum performance requirements for
UMTS/HSDPA UE) .56
7.8 MBMS.57
8 Conclusions and Recommendations.57
8.1 Independence Between Radio Features and HSPA Architecture Evolution.57
8.2 IP Multicast for MBMS User Plane .58
8.3 Carrier sharing scenario for architecture alternative Iu with RNC U-Plane & C-Plane functions in Node-
B .58
Annex A: Change history .59
History .60

ETSI
3GPP TR 25.999 version 7.1.0 Release 7 5 ETSI TR 125 999 V7.1.0 (2008-04)
Foreword
rd
This Technical Report has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 6 ETSI TR 125 999 V7.1.0 (2008-04)
1 Scope
The present document has been produced in the scope of the study item on "HSPA Evolution" [2]. The objective of the
study item is to develop a framework for the evolution of the FDD mode of the 3GPP HSPA WCDMA-based radio-
access technology beyond Release 7.
The present document lists the constraints for the FDD HSPA Evolution beyond release 7 and an assessment of
technical proposals and their respective, achievable performance and complexity.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or non-
specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TD RP-060217: "Work Item Description on Scope of future FDD HSPA Evolution".
Suppote Team note: Reference [2] is not legitimate.
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
HSPA: In the present document, the acronym HSPA (High Speed Packet Access) is used to qualify the FDD mode
features HSDPA (High Speed Downlink Packet Access) and Enhanced Uplink as defined in the Release 7 version of the
3GPP Specifications.
Backward Compatibility: In the present document, Backward Compatibility means the ability of an HSPA
infrastructure to simultaneously allocate radio resources on one single carrier to post-release 7 terminals and terminals
compliant with previous releases of the 3GPP specifications without performances degradation for either type of
terminal. It is understood that in that case the performance enhancements targeted in this document would only apply to
post-release 7 terminals and that the full potential of system performance enhancements would only be achievable if all
terminals operating simultaneously on a single carrier were post-release 7 terminals.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
CAPEX Capital expenditure
CS Circuit Switched
DRX Discontinuous Reception
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 7 ETSI TR 125 999 V7.1.0 (2008-04)
HSPA High Speed Packet Access
LTE: Long Term Evolution
MIMO Multiple Input Multiple Output
NAS Non Access Stratum
OPEX Operational expenditure
QoS Quality of Service
PS Packet Switched
TCP Transmission Control Protocol
UE User Equipment
4 Introduction
The Study Item Description on "HSPA Evolution" [2] was approved by the 3GPP TSG RAN #31 plenary meeting in
March 2006.
The importance of on-going and future efforts to enhance the capabilities and performance of HSPA-based radio
networks is widely recognised by 3GPP operators. HSPA networks will form an integral part of future 3G systems and
as they evolve, should provide a smooth migration path towards LTE. HSPA operators are just as interested in the
potential performance and cost savings which may be achieved through HSPA Evolution as they are in the future LTE
system.
Critical elements of such evolution should include reduced latency, higher user data rates, improved system capacity
and coverage and reduced cost for the operator while maintaining the highest possible level of backward compatibility.
5 Objectives
Beyond Release 7, the following elements should be considered as guiding principles for HSPA Evolution:
1. HSPA Spectrum Efficiency, Peak Data Rate and Latency should continue to evolve favourably. The tradeoffs
necessary to achieve performance comparable to LTE in 5 MHz should be analyzed;
2. HSPA and its evolution should facilitate the joint technology operation with LTE and offer a smooth migration
path towards LTE (Long Term Evolution). The possibility to adopt common elements or a common functional
split with LTE and the possibility to re-use the evolved Core Network defined as part of the System Architecture
Evolution (SAE) study should be analyzed as well;
3. Evolved HSPA should be able to operate as a packet-only network based on utilization of the high speed data
channels only (HS-DSCH, E-DCH and associated channels);
4. HSPA Evolution shall be backward compatible in the sense that legacy terminals (R99-DCH and HSPA mobiles)
shall be able to share the same carrier with terminals implementing the latest features of the HSPA Evolution
track without any performance degradation;
5. Ideally, existing infrastructure should only need a simple upgrade to support the features defined as part of the
HSPA Evolution.
Thus, the study should focus on improving the system performances for services delivered through the PS-domain
including voice and multimedia conversational services.
In relation to this study item, TSG-RAN should establish a reference performance set for HSPA release 7. Rather than
relying on new simulation results, it is recommended that this performance set is derived from on-going activities
related to the performance evaluation of new enhancements like HSDPA MIMO or LTE. This reference performance
set should be used to set the absolute performance targets for HSPA Evolution and to evaluate the potential
improvements provided by solutions proposed in the scope of the study.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 8 ETSI TR 125 999 V7.1.0 (2008-04)
6 Constraints and requirements
NOTE: This chapter will capture text on the constraints for HSPA evolution including on legacy issues, backward
compatibility, architecture, impact on LTE, Node B and UTRA, software and hardware upgrades,
complexity issues, acceptable impacts on UE's, protocol reuse/requirements, signalling and physical
channel limitations, etc.
6.1 Constraints
a) HSPA Evolution should be capable of being implemented through a re-use of the release 7 RAN architecture.
However, proposals to modify the RAN architecture should also be considered within the scope of HSPA
Evolution, provided full interworking to a legacy release 7 architecture is supported.
b) The RAN-CN functional split can be reviewed providing that it results in significant performance and/or
improvements and facilitate the migration towards LTE/SAE without significant complexity increase.
c) Evolved HSPA should have a minimum impact on Node Bs, to allow for simple upgrades; Reuse of the existing
Node B hardware by HSPA Evolution is essential. This does not preclude hardware upgrades to support
additional functionality (e.g. to increase processing power, RNC functionality, etc.).
d) Evolved HSPA protocol architecture shall have minimum impact on UEs especially in terms of complexity, to
allow for easy introduction.
e) R99-DCH and legacy HSPA UEs shall be able to share the same carrier with terminals implementing the latest
features of the HSPA Evolution without any performance degradation.
f) Intra- and inter-system mobility performance shall be no worse than R7.
6.2 Requirements
6.2.1 Requirements for the UTRAN architecture
a) Should provide a low complexity, low cost and smooth migration of HSPA towards evolved UMTS (SAE/LTE).
b) Should reduce user plane latency to legacy (R5,6 & 7) & beyond R7 terminals.
c) Should reduce control plane latency to beyond R7 terminals and, if low complexity cost effective means can be
found, also to legacy terminals.
d) Simplification and reduction of the number of nodes should be considered.
e) Connection of evolved HSPA RAN to SAE CN (UP &/or CP) should be considered.
f) Should consider mobility between non 3GPP access systems and evolved HSPA.
g) Should consider IW with CS domain to support legacy CS services.
h) Should consider proposals to lower backhaul costs.
i) Indicative achievable performance values - see table 6.2.1-I.
Table 6.2.1-I: Indicative view on the achievable performance
Release 6 Description of
HSPA Evolution
Performance Item
Measurement
Target
Anticipated
PING measured once
Round Trip Delay
PDP Context is
(PING) <50 ms
<100 ms
established and Device is
& UP Latency
in CELL_DCH
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 9 ETSI TR 125 999 V7.1.0 (2008-04)
Cold start. Measured
from the RRC
Connection Request sent
by a Terminal previously
Packet Call Set Up <500 ms
May exceed
in PMM_Idle to the
1000 ms
completion of the PDP
Context Establishment
Procedure
Time needed to transition
the UE from a Dormant
state like CELL_PCH or
CP Latency URA_PCH to
<100 ms
May exceed
Dormant to Active CELL_DCH (Active with
1000 ms
a RAB/RB set Up) with
or without having to (re-)
establish a PDP Context
Note: The values in this table are indicative views of how much HSPA could be improved at the time of starting the
study. These values are for information only.
6.2.2 Requirements for the UTRA
a) Changes that deliver higher spectrum efficiency should be considered, within the constraints specified in the
clause 8.
b) Should reduce user plane latency to legacy (R5,6 & 7) & beyond R7 terminals.
c) Should reduce control plane latency to beyond R7 terminals and, if low complexity cost effective means can be
found, also to legacy terminals.
d) Should consider how to provide efficient QoS support for all traffic classes preferably in a manner that is
backwards compatible with legacy terminals.
e) Should consider changes that, where it makes sense, deliver benefits to legacy terminals as well as beyond R7
terminals.
f) Any changes to the terminal should maximally build on the extensive developments and testing efforts of R5, 6
& 7.
7 Technical Proposals and Assessment
The table 7 outlines the agreed metrics which should be used to describe/evaluate/compare each of the different
architecture alternatives.
Table 7: HSPA Architecture Evaluation Matrix
Target Alt1: Alt 2: Alt 3: Alt 4:
Current architecture CRNC in NodeB Iu UP in NodeB RNC in NodeB
Security No Impacts No Impacts For the CP - No Impact. S3 Findings:
For the UP, S3 Findings:
- Additional Physical
Security
- Additional Physical
Security OR
OR
- Additional Platform
Security
- Additional Platform
Security OR
- Combination of both
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 10 ETSI TR 125 999 V7.1.0 (2008-04)
required
OR
- OR Combination of
both required
Reduce U Plane Latency No Change Reduction expected in DL Reduction expected where Reduction expected where
AND if Outer ARQ in MDC is not in use (UP MDC is not in use (UP radio
NodeB (pending RAN2 radio protocols protocols terminating in the
decision) terminating in the NodeB) NodeB)
No Change No Change No Change Reduction expected (CP
Reduce C Plane Latency
(RRC Setup) radio protocols terminating

in the NodeB)
Specification Impact No Change Medium Major FFS – See Note 6
Impact upon CN Node(s) No Change Changes to Relocation Signalling increase due to Signalling increase due to
Procedures mobility foreseen. mobility foreseen.
Performance in handling Performance in handling
greater number of Iu greater number of Iu
(without OTS) or Iu/& Gn (without OTS) or Iu/& Gn
(with OTS) instances (with OTS) instances
Impact upon RAN No Change NodeB assumes CRNC NodeB assumes RNC UP NodeB assumes all RNC
functionality. functionality. functionality.
No change to legacy New interface between Impacts upon legacy RNC
RNC. SRNC & NodeB (Iur interface number and
additional processing).
Iub handling removed
Interworking with No Impact No Impact upon UE. No impact upon UE.
Legacy UEs
No Impact upon routing of No impact upon UE. CS Services require routing
(includes CS Domain CS Services. to legacy SRNC.
CS Services require
handling)
routing to legacy SRNC.
Efficiency of MDC As Today As Today Possible, MDC occurs in Possible (MDC occurs in
Support NodeB and CP Signalling NodeB) but efficiency
required to SRNC. depends upon transport
network topology and
But efficiency depends
transport technology.
upon transport network
topology and transport
technology.
Scalability As Today As Today UP processing scales UP processing scales
independently (Direct independently (Direct
NodeB CN NodeB CN connection)
connection) with transport with transport network
network capacity. capacity.
As Today As Today MDC Combining in MDC Combining in NodeB
Last Mile Bandwidth
Usage (due to eHSPA NodeB (for UL) will (for UL) will bring an
Arch) bring an increase in Last increase in Last Mile
Mile Bandwidth Bandwidth (depending upon
(depending upon Network Network Topology)
Topology).
New interface towards
SRNC will imply
additional traffic on last
mile.
As Today As Today More frequent SRNS More frequent SRNS
Interruption time / User
experience. Relocations expected. Relocations expected.
Increased CS call setup
delay expected.
User Throughput As Today Decreased RTT (DL) Decreased RTT leads to Decreased RTT leads to
Increase (as a function leads to increased User increased User increased User throughput.
of RTT) throughput. throughput.
RRM support As Today Single cell RRM as today. As Today Single cell RRM as today.
Multi-cell (inter NodeB) Multi-cell (inter NodeB)
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 11 ETSI TR 125 999 V7.1.0 (2008-04)
RRM not supported in a RRM not supported in a
centralised node. centralised node.
Number of CP & UP 2 Nodes (CP UP) 2 Nodes (CP UP) 2 Nodes (1 CP, 1CPUP) 1 Nodes (CP UP)
Nodes
(DRNC not considered,
CS Services not
considered)
NOTES:
1. Reduce C Plane Latency refers to RRC Setup.
2. Number of CP and UP Nodes does not consider DRNC situation or CS services.
3. At the time of writing, inclusion of a metric which describes the ease or otherwise of incorporating L1 L2
improvements against 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 L1 L2 improvements
from other WGs be forthcoming.
7.1 Architectural solutions
7.1.1 Current Release 6 Architecture - Alt 1
The UTRAN consists of a set of Radio Network Subsystems connected to the Core Network through the Iu.
A RNS consists of a Radio Network Controller one or more Node Bs and optionally one SAS. A Node B is connected
to the RNC through the Iub interface.
The RNC is responsible for the Handover decisions that require signalling to the UE.
A RNC may include a combining/splitting function to support combination/splitting of information streams
Inside the UTRAN, the RNCs of the Radio Network Subsystems can be interconnected together through the Iur. Iu(s)
and Iur are logical interfaces. Iur can be conveyed over direct physical connection between RNCs or virtual networks
using any suitable transport network.
The UTRAN architecture is shown in figure 7.1.1-1.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 12 ETSI TR 125 999 V7.1.0 (2008-04)

Core Network
Iu Iu
RNS
RNS
UTRAN
Iur
RNC RNC
Iub
Iub Iub
Iub
Node B Node B Node B
Node B
Figure 7.1.1-1: UTRAN Architecture
[Figure 4, TS25.401 Rel-6]
7.1.2 Iu with enhanced SRNC separate from the enhanced collapsed
CRNC/DRNC/Node B – Alt 2
7.1.2.1 General description
The main objective of the HSPA evolution is to improve further the latency and the bit rate with limited and controlled
hardware and software impacts (1). Another important aspect is to benefit from these improvements as soon as today
and in particular independently of the availability of the SAE core (2).
In the architecture figured out below, the RAN-CN functional split is thus kept to readily reuse the proven Iu interface
with no additional delay, testing efforts and painful interoperability issues.(2)
Besides, only the functions which effectively contribute to the reduction of the latency and the increase of bit rate have
been moved from the RNC down to the nodeB in order to minimize the hardware and software impacts.(1). These are in
particular:
- an RNC RLC mirror function is placed in nodeB to improve the latency induced by repetitions for both the user
plane and the control plane,
- the scheduling of all common resources is moved to the nodeB (enhanced scheduler) where they benefit from the
HARQ function. The centralized scheduling of common resources in the nodeB also leads to power management
optimizations and corresponding gains in bit rate.
- Other enhancements already identified within the R7 study items (signalling enhancements, Continuous Packet
Connectivity, delay optimisation for procedures,…)
Moreover, these changes also result in the possible move of the CRNC and DRNC functions into the nodeB which can
lead to a simplified architecture as presented in the figure 7.1.2.1-1.
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 13 ETSI TR 125 999 V7.1.0 (2008-04)

Iu-PS
CN
SGSN
SRNC
Node_B/CRNC/DRNC
GGSN
Iu-CS
UTRAN
MSC
(HSPA access)
Node_B/CRNC/DRNC
Figure 7.1.2.1-1: Iu with enhanced SRNC separate from the enhanced collapsed CRNC/DRNC/Node B
In figure 7.1.2.1-1, the Iu-PS UP in solid green takes the same path as the Iu-PS CP in dashed red.
Besides, when the core network implements the one-tunnel approach, the architecture can be further simplified into
figure 7.1.2.1-2: where the Iu-PS UP in solid green takes another path than the Iu-PS CP in dashed red:

SGSN
CN
SRNC
Node_B/CRNC/DRNC Iu-PS
GGSN
Iu-CS
UTRAN
MSC
(HSPA access)
Node_B/CRNC/DRNC
Figure 7.1.2.1-2: Iu with enhanced SRNC separate from the enhanced collapsed CRNC/DRNC/Node B (Simplified)
7.1.2.2 User Plane
Uplink Macro Diversity
The UL MDC stays in the RNC. This allows to benefit from the gains of cell edge throughput for both intra- and inter-
Node B while not increasing the last mile traffic compared to solutions where this function would be placed in the
NodeB.
Ciphering
Ciphering is still performed in the RNC. In particular the user plane traffic is ciphered in a node above the edge RAN
node as strongly recommended by SA3 to avoid security vulnerabilities or extra cost to overcome them. At the same
time, it avoids the impact and associated cost of moving this function to another node (e.g. a CN node).
Header Compression
Header compression is still located in the RNC which avoids the impact and associated cost of moving this function into
another node.
7.1.2.3 Control Plane (Radio part)
RRC:
The RRC stays in the RNC with the associated functions of connection and mobility control and measurement report
co-localized for maximum efficiency.
MAC:
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 14 ETSI TR 125 999 V7.1.0 (2008-04)
Only dedicated channels remain scheduled in the RNC. Common channels scheduling is done in the NodeB in order to
get the same latency benefit as obtained for HSDPA due to HARQ repetitions. Moreover, their centralized management
will result in gains in terms of power and bit rate due to possible scheduler optimisations/anticipations.
RLC:
The RLC remains in the RNC as an anchor point for the mobility. This avoids the frequent context transfers during
inter-nodeB relocations and their associated delay.
A second mirror RLC is used in the nodeB which can also further improve the latency of signalling messages.
7.1.2.4 Control Plane (Interface part)
By keeping the RNC this architecture minimizes the impact on UTRAN interfaces compared to others: it is foreseen no
RANAP change on Iu, limited changes on NBAP, RNSAP (due to move of some functions). Some simplifications can
also be expected due to the collapsed CRNC/DRNC/NodeB.
7.1.2.5 Support of legacy UE
The support of legacy UE by a R8 NodeB is assumed via the carrier sharing requirement quoted above. Assuming the
R8 NodeB has got the CRNC function as per [1], the R8 nodeB will share the resources between R8 UEs and legacy
UEs in the cell. This is handled by the CRNC* function located in the nodeB in the drawing below.
Therefore it should be possible that the benefits obtained with CRNC* functions managed by the R8 NodeB are also
leveraged for legacy UEs when they connect to both evolved R8 NodeB and R8 RNC.

Legacy CN
Iu-PS/IU-CS
Iu-PS/IU-CS
eHSPA RNC
Iur
SRNC*/SRNC
Legacy UTRAN
CRNC
Iur
Iur*
Iub
CRNC*
Node B* / NodeB Rel’7 Node
B
eHSPA Node B
Uu
W-CDMA
Rel’99
Rel’99
UE
UE
Rel’8
Rel’8
UE
UE
Figure 7.1.2.5 -1: Support of Legacy UE
ETSI
3GPP TR 25.999 version 7.1.0 Release 7 15 ETSI TR 125 999 V7.1.0 (2008-04)
For backwards compatibility reasons, the RNC R8 also handles the legacy UE as follows:
The R8 RNC is a RNC* i.e. it has the RNC function of R6 with enhancements. These enhancements are optional
features which may not apply to legacy UE at call set up. Therefore, when a legacy UE connects to the R8 RNC via a
R8 NodeB, the R8 RNC can behave as R6 SRNC and the interface between the R8 NodeB and the R8 RNC for this
legacy UE is Iur-like in this case.
Conversely, if the legacy UE connects to the R8 RNC via a legacy R6 NodeB, the R8 RNC will behave as a full R6
RNC i.e. R6 SRNC and R6 CRNC. This interface between the R8 RNC and the R6 NodeB is then a usual Iub. This
scenario is further detailed in the next section.
Iu interface
The legacy UEs are then connected to the legacy network via Iu-PS or Iu-CS interface depending on the nature of the
call, since these interfaces are basically supported by the solution
7.1.2.6 Support of legacy networks
Support of legacy NodeB and SRNC
The support of legacy UTRAN is assumed to be related to the deployment scenario wrt how far R8 NodeBs and R8
RNCs have been deployed in the network. In particular it is assumed that it should be possible to connect a R8 NodeB
to an existing legacy RNC and conversely, it should be possible to deploy a R8 RNC even if not all the pertaining
nodeBs are R8 NodeB.
The CRNC function is located in the NodeB, therefore when a R8 UE connects to both a R8 NodeB and R8 SRNC, the
interface is normally Iur*.
On the contrary, when a R8 UE connects via a R6 nodeB to a R6 RNC, the interface is Iub.
This is reflected in the following table:
Table 7.1.2.6-1 : R8/R6 Connectivity
NodeB/RNC R8 RNC R6 RNC
R8 NodeB Iur* (full upgrade) Iub (partial upgrade)
R6 NodeB Iub (partial upgrade) Iub (today)
R6 DRNC Iur (partial upgrade) Iur (today)

There are two possible mixed deployment scenarios reflected in table 7.1.2.6-1:
The first mixed scenario is considered to correspond to transient phases i.e. due to phase of deployment consideration, a
R8 NodeB happens to be connected to R6 RNC (in that case it should have only one parent). The R8 nodeB is supposed
to behave in that case as a R6 NodeB and therefore the interface is Iub also.
The second mixed scenario is a R6 NodeB connected to a R8 RNC. This second scenario also leads to an Iub interface.
Support of legacy DRNC
In another deployment scenario, the R8 RNC may need to communicate with a legacy RNC used as DRNC during
mobility (see the drawing below). In this scenario, the R8 RNC is used as a R6 RNC exhibiting a legacy Iur interface.
Support of legacy CN
The support of legacy CN is assumed by the evolved R8 RNC itself which basically reuses the Iu-PS and Iu-CS
interfaces (see [1]).
Figure 7.1.2.6-1 summarizes all scenarios of full or partial upgrades.

ETSI
3GPP TR 25.999 version 7.1.0 Release 7 16 ETSI TR 125 999 V7.1.0 (2008-04)
EvolvedEvolved HSPAHSPA partial upgrade --
EvolvedEvolved HSPAHSPA full upgrade -- --
SGSN MSC
SGSN MSC
Iu- Iu-CS
Iu- Iu-CS PS
PS Iur
EvolvedEvolved HSPA HSPA
RNRNCC
Node
RNC
B
””LegacLegacyy ””
EvolvedEvolved HSPA HSPA
UTRANUTRAN
Node
RNC
Iur* Iub Iub Iub
B
Iur*
EvolvedEvolved HSPA
NodeB NodeB
EvolvedEvolved H
...