Radio Principle PDF

9300 WCDMA
TMO18246 9300 WCDMA UAO7

R99 Radio Principles
TMO18246 Issue D0 SG DEN I2.0
STUDENT GUIDE
All Rights Reserved © Alcatel-Lucent 2010
All rights reserved © Alcatel-Lucent 2010

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

TMO18246 9300 WCDMA UAO7 R99 Radio Principles - Page 1
Empty page
Switch to notes view!
2 All Rights Reserved © Alcatel-Lucent 2010

9300 WCDMA
TMO18246 9300 WCDMA UAO7 R99 Radio Principles
This page is left blank intentionally

Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2010
9300 WCDMA
All rights reserved © Alcatel-Lucent 2010
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

Blank Page

9300 WCDMA

Course Outline
Section
About This1.Course
UTRAN System Description
4. Topic/Section is Positioned Here
Module 1. TMO18246
Course outline
Technical support for UMTS
Section 2. WCDMA 5. Topic/Section is Positioned Here
Course objectives
Module 1. TMO18246
Section 3. UTRAN
1. Topic/Section Scenario
is Positioned Here 6. Topic/Section is Positioned Here
Xxx Module 1. TMO18246
Xxx
Section 4. MBMS Radio Principles 7. Topic/Section is Positioned Here
Xxx
Module 1. TMO18246
Section 5. Glossary
Module 1. TMO18246

9300 WCDMA

Course Outline [cont.]

9300 WCDMA

Course Objectives
Welcome to TMO18246 9300 WCDMA UAO7 R99 Radio Principles
Upon completion of this course, you should be able to:
Upon completion of this course, you should be able to:

describe WCDMA principles for UMTS
describe mobile system standards evolution
describe UMTS services , new capacity figures and service architecture
draw the UTRAN architecture with the protocol stack
define a Radio Resource in 3G and describe WCDMA principles for UMTS
describe how the user can access to the network and asks for a 3G service
describe UTRAN functions and state protocols.

9300 WCDMA

Course Objectives [cont.]

9300 WCDMA

About this Student Guide

Conventions
Switch used
to notes in this guide
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

9300 WCDMA
If you want further information you can refer to the following:

Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com

About this Student Guide [cont.]

9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?

Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Yes (or No (or

Instructional objectives globally globally Comments
yes) no)
1 To be able to XXX
2
9300 WCDMA

Self-assessment of Objectives [cont.]
Yes (or No (or

Instructional objectives Globally globally Comments
yes) no)

9300 WCDMA
Other comments
Thank you for your answers to this questionnaire


Do not delete this graphic elements in here:
1
Section 1
9300 WCDMA
TMO18246 Edition D0 SG DEN I2.0

Section 1 Pager 1
Blank Page

9300 WCDMA TMO18246 9300 WCDMA UAO7 R99 Radio Principles
Document History
Edition Date Author Remarks
03 2007-06-21 Scholle, Martin Conversion into Alcatel-Lucent template
04 2010-05-05 Nolan, Vincent Update to UA07

Section 1 Pager 2
Objectives
To be able to draw the UTRAN architecture with the

protocol stack (radio and Iu) of each network element
and to define the channels generated by these protocols.


Section 1 Pager 3
Objectives [cont.]


Section 1 Pager 4
Table of Contents
Logical Architecture Common Transport Channels Page

UTRAN Situation & Core Network in Dedicated Transport Channels
1 Logical
3GPP R4 Architecture Mapping Logical / Transport7 Channels
1.1 UTRAN
UTRAN Situation
Logical & Core Network in 3GPP R4 Physical Channels
Architecture 8
1.2 UTRAN
Interfaces Logical Architecture Physical Channel List 9
1.3 Interfaces
Network Element Function Downlink 10
Network1.4 Network Element Function
Protocols Uplink 11
Physical Channels: Structure
2 Network
ProtocolsProtocols in UTRAN 13
2.1 Protocols
Protocol Stack in UTRAN
on the Interfaces UTRAN Radio Protocols 14
2.2 UTRAN
General model Logical Architecture Radio protocol stack 15
2.3 Hybrid
Iub protocols Iub logical architecture Radio Resource Control (RRC) 16
2.4 Native
Iur Protocols IP Iub logical architecture PDCP and BMC Protocols 17
2.5 NodeB synchronisation for all IP Radio Link Control (RLC) 18
Radio Channels
2.6 IP Iur logical architecture Medium Access Control (MAC) 19
Global Situation The Physical Layer
2.7 IP IU-PS
RAB Presentation logical architecture 20
2.8 IP Iu-CS logical architecture Exercises 21
Radio Channels, Protocols & Network
2.9 O&M
Elements flow architecture MAC protocol 22
3 Protocol
Radio Bearers Stacks 23
3.1 Protocols
Logical Channelsin UTRAN 24
3.2 General
Why Transport Channels? model 25
3.3 Iub Protocol
Structure Stacks
of a Transport Channel 26
3.4 I-BTS O&M
Transport Plane Example
Channels: 27
3.5 Iur Protocol
Transport Channels Stacks 28
3.6 Iu-PS Protocol Stacks 29
3.7 Iu-CS Protocol Stacks 30
3.8 IU- CS – RTP/RTCP Protocol 31
1 5 4 Radio Channels All Rights Reserved © Alcatel-Lucent 2010
32
4.1
9300 WCDMA Global
TMO18246 Situation
9300 WCDMA UAO7 R99 Radio Principles 33
4.2 RAB Presentation 34
4.3 Radio Channels, Protocols & Network Elements 35
4.4 Radio Bearers 36
4.5 Logical Channels 37
4.6 Why Transport Channels? 39
4.7 Structure of a Transport Channel 40
4.8 Transport Channels: Example 42
4.9 Transport Channels 43
4.10 Common Transport Channels 44
4.11 Dedicated Transport Channels 47
4.12 Mapping Logical / Transport Channels 48
4.13 Physical Channels 50
4.14 Physical Channel List 51
4.15 Downlink 52
4.16 Uplink 53
4.17 Physical Channels: Structure 54
5 UTRAN Radio Protocols 55
5.1 Radio protocol stack 56
5.2 Radio Resource Control (RRC) 57
5.3 PDCP and BMC Protocols 58
5.4 Radio Link Control (RLC) 59
5.5 Medium Access Control (MAC) 60
5.6 The Physical Layer 61
6 Exercises 62
6.1 MAC protocol 63

Section 1 Pager 5
Table of Contents [cont.]
Page


Section 1 Pager 6
1 Logical Architecture


Section 1 Pager 7
1.1 UTRAN Situation & Core Network in 3GPP R4
Access Network MSC Server Core Network CS Links External Networks

CS-CN PS Links
UTRAN Iu-CS PSTN

MGW GMSC
RNC
HLR IN network
Node B
Backbone
Iu-PS
SGSN
GSM BSC Gb iGGS PDN
N
BSS
PCU
BTS
PS-CN

A Public Land Mobile Network (PLMN) is composed of 2 main parts:

The Access Network (AN) provides the radio interface and radio resource management for mobile
communications toward the Core Network (CN).
The Core network is in charge of User Equipment (UE) Mobility (MM) and Session (SM) management. It
also deals with the external networks for voice call establishment or data session establishment.
The UMTS Terrestrial Radio Access Network (UTRAN) is the UMTS Access Network; it’s composed of
Node Bs and Radio Network Controllers (RNCs).
An ATM switch interfaces the UTRAN and the CN:
• Iu-CS interface for the Circuit Switched Core Network (CSCN).
• Iu-PS interface for the Packet Switched Core Network (PSCN).
The PLMN connects specifically to the Public Switched Telephone Network (PSTN) for voice or to the
Packet Data Network (PDN) for data.
The CN includes the Intelligent Network (IN) for value-added services.
Example of services:
For voice:
• Voice Call Prepaid Service
• SMS service
• Call Waiting

Section 1 Pager 8
1.2 UTRAN Logical Architecture
CS-CN PS-CN
Core Network
Iu-CS Iu-PS
RNC RNC
Iur
Iub Iub
UTRAN
RNS
Node B Node B
Uu Interface
UE
UEs

CN
2 separated domains: Circuit Switched (CS) and Packet Switched (PS) which reuse the
infrastructure of GSM and GPRS respectively.
UTRAN
new radio interface: CDMA
new transmission technology: ATM
CN independent of AN
The specificity of the access network due to mobile system should be transparent to the core
network, which may potentially use any access technique.
Radio specificity of the access network is hidden to the core network.
UE radio mobility is fully controlled by UTRAN.
Some correspondences with GSM:

CN NSS Uu Um
UTRAN BSS Iub A-bis
RNC BSC Iur no equivalent
Node-B BTS Iu-CS A
UE MS Iu-PS Gb

Section 1 Pager 9
1.3 Interfaces
Open Interfaces:
• The function of the Network Elements have been clearly specified by the
3GPP.
• Their internal implementation issues are open for the manufacturer
• All the interfaces have been defined in such a detailed level that the
equipment at the endpoints can be from different manufacturers.
• “Open Interfaces” aim at motivating competition between manufacturers.
Physical implementation of Iu interfaces

•Each Iu Interface may be implemented on any physical connection using
any transport technology, mainly on E1 (cable), STM1 (Optic fiber) and
micro-waves.
•ATM will be provided in the 3GPP R4 release and IP is for the 3GPP R6
1 10 All Rights Reserved © Alcatel-Lucent 2010

A manufacturer can produce only the Node-B (and not the RNC). This is not possible in GSM (A-bis is a
proprietary interface)
The Iur physical connection can go through the CN using common physical links with Iu-CS and Iu-PS.
However there is a direct logical connection between the 2 RNCs: the Iur information is not handled by
the CN.

Section 1 Pager 10
1.4 Network Element Function
RNC RNC
Iub Iur Iub
RNS
Node B Node B
RNC: Radio Network Controller

It is the intelligent part of the UTRAN:
- Radio resource management (code allocation, Power Control, congestion

control, admission control)
- Call management for the users
- Connection to CS and PS Core Network
- Radio mobility management

An RNS (Radio Network Subsystem) contains one RNC (Radio Network Controller) and at least one
Node-B.
The RNC takes a more important place in UTRAN than the BSC in the GSM BSS. Indeed RNC can perform
soft HO, while in GSM there is no connection between BSCs and only hard HO can be applied.

Section 1 Pager 11
1.4 Network Element Function [cont.]
RNC
ATM Transport
Technology
Iub
Node B
Node-B
A Node-B can be considered, as first approximation, like a transcoder
between the data received by antennas and the data in the ATM cell on the
Iub.
- Radio transmission and reception handling

- Involved in the mobility management
- Involved in the power control
An RNS (Radio Network Subsystem) contains one RNC (Radio Network Controller) and at least one
Node-B.
A Node-B is also more complex than the GSM BTS, because it handles softer HO.
Controlling RNC (CRNC): a role an RNC can take with respect to a specific set of Node-Bs (ie those Node-
Bs belonging to the same RNS). There is only one CRNC for any Node-B. The CRNC has the overall control
of the logical resources of its Node-Bs

Section 1 Pager 12
2 Network Protocols


Section 1 Pager 13
2 Network Protocols
2.1 Protocols in UTRAN
The Iu protocols
Used to exchange data (traffic
Core Network and signaling) between RNCs,
Node Bs and the Core Network.
Iu
Iu Protocols
The Radio protocols
RNC RNC Used to process the data sent on
the air and for the signaling
Iur between UTRAN and the UEs
Iub
Radio Protocols NAS Signaling

Signaling between a UE and
Node B the Core Network.
Typically, the Authentification
and the Location
Uu Interface
NAS Signaling
Iu Protocols :
RANAP: Radio Access Network Application Protocol,
RNSAP: Radio Network Sub-system Application Protocol,
NBAP: Node B Application Protocol,
ALCAP is a generic name for the signalling protocols of the Transport Network Control
Plane used to establish/release Data Bearers.
It makes establishment/release of Data Bearers on request of the Application Protocol.
Radio Protocols :
RRC: Radio Resource Control
RLC: Radio Link Control
MAC: Medium Access Control
NAS Signaling :
NAS refers to higher layers (3 to 7). Entities of this part will exchange tele-services and bearer
services

Section 1 Pager 14
2 Network Protocols
2.2 UTRAN Logical Architecture
SAS
CBC
OMC
Iub MSC
Itf-R
Itf-R
ATM NB Itf-B ATM Backbone MGW
ATM Backbone
Itf-B
Iub MGW
Iu-CS
Iur SGSN
Hybrid NB RNC RNC
(SAS)
Iu-PS
GGSN
Iub IP Backbone IP Backbone
IP NB SGSN
Last Mile Iu-BC
MGW
CBC MGW
MSC
UTRAN Core Network

The scope of IP Transport in UTRAN is intended to replace the ATM transport network (AAL2/ATM or AAL5/ATM) by an
IP transport network to reduce the transmission cost.
The radio network layer remains unchanged in the control plane (RANAP, RNSAP, NBAP), except that the transport
layer information provided in NBAP/RNSAP/RANAP is changed, and in the user plane (Iu / Iur / Iub UP Frame
Protocols). ALCAP disappears in the transport network control plane.
After the introduction in UA06 of an hybrid ATM / IP transport on Iub (iBTS only) and a pure IP transport on Iu-PS, it
is added in UA07:
Full IP transport on Iub: the existing ATM interface is removed and all the traffic (User Plane and Control Plane) is
transported over an IP/Ethernet interface
IP transport on Iu-CS: between the RNC and the MSC, and between the RNC and the MGW in NGN architecture
IP transport on Iur: between two RNC
Pure IP transport on Itf-R and Itf-B : the OMC can be connected only to the IP backbone
IP transport on Iu-BC: between the RNC and the CBC
Moreover, a full mixity between ATM and IP transport is supported in UA07:
A mix of ATM Nodes B, Hybrid Nodes B and Full IP Nodes B are supported on the same RNC
A mix of ATM and IP is supported on Iu/Iur : Iu-PS over IP / Iu-CS over ATM or some Iurs over ATM and other Iurs
over IP
A mix of ATM and IP is supported on Iu-CS/Iu-PS in case of Iu-Flex
The OMC can be connected either to the ATM backbone (via an IP over ATM access node) or to the IP backbone,
The O&M flow from RNC to OMC can be “In band” or “Out of Band” (using an Ethernet port of a dedicated card).
Note that the Iu-PC interface is not supported over IP in UA07 as the Standalone AssistedGPS SMLC (SAS) is integrated
in the RNC in UA07 (see FRS 34123). That means that Iu-PC over ATM is still supported on a mix ATM/IP RNC but
integrated SMLC server is needed in case of a Full IP RNC.

Section 1 Pager 15
2 Network Protocols
2.3 Hybrid Iub logical architecture
Ethernet IP Network:
Link Several DSCP
RNC
GE Link
Hybrid BTS IP on VLAN/GE VR
Ethernet STM1 Link

Link
E1/T1 Links
ATM on STM1
ATM Network: OMC
Several ATM VCs
Hybrid BTS
OAM flow on ATM

Signaling flow on ATM
R99 + Common channels + HSPA Streaming User plane on ATM
HSPA Interactive / Background User plane on IP

Hybrid Iub means support of hybrid ATM / IP transport on Iub interface:

ATM being used for control plane (NBAP, ALCAP), Node B O&M and R99 user plane. ATM also carries
HSDPA streaming and SRB on HSPA.
IP being used for HSDPA and HSUPA user plane traffic with interactive/background traffic class.
In UA6, VLANs are introduced in the RNC to separate, at ethernet level, different flows on the same
physical Gigabit Ethernet Port : one VLAN is dedicated to Iub user plane.
In UA07, VLAN is introduced in the iBTS.
QoS differentiation is ensured by DiffServ at IP level and, optionally, by Priority Bits at Ethernet level.
Hybrid Iub is supported only on iBTS (from UA06), equipped with xCCM. Hybrid Iub is NOT supported on
iBTS equipped with iCCM, on oneBTS, on micro / pico Node B.

Section 1 Pager 16
2 Network Protocols
2.4 Native IP Iub logical architecture
PTP server
OMC
FE/GE
Link GE Link
RNC
IP Network:
IP Node DSCP mandatory
VLAN/pbits optional
User Plane
0 or 1 VLAN
Control Plane 0 or 3 VLANs
0 or 1 VLAN
OAM flow 1 or 3 IP adresses
Synchro flow 0 or 1 VLAN

Native IP Iub means support of IP transport only on Iub interface both for Control Plane, User Plane and
Node B O&M flows, ATM is no more used.
The Control Plane consists in NBAP signaling messages only, as ALCAP is not needed any more.
The User Plane consists in different traffic types having different QoS requirements.
The Node B O&M flows may go directly from OMC to Node B.
These different data flows (control, user, O&M) may be separated by using different IP addresses and
also by different VLANs at RNC side and at Node B side.
QoS differentiation is ensured by DiffServ at IP level and, optionally, by Priority Bits at Ethernet level.
At Ethernet level, VLANs can be used to separate different flows (User Plane, Control Plane, O&M flows)
on the same physical Ethernet Port.
For synchronization, the Node B needs an interface with an external PTP server.
.

Section 1 Pager 17
2 Network Protocols
2.5 NodeB synchronisation for all IP
IEEE1588v2 server
Iub clock
Synch
frames
RNC
Node B
IP Transport
Cell site
gateway
GPS
E1 link receiver
for synchro
Node B
Node B

This feature provides support for synchronisation of all IP NodeB inplementation by introducing the
following options:
Packet synchronisation based on IEEE1588v2( External IEEE1588v2 server for synchronization)
or alternative synch method:
GPS synchronisation
E1/T1 synchronisation (not used for traffic – only synchronisation)
Up until UA7.1, a BTS provides only E1/T1 or E3/T3 or STM1/OC-3 connectivity and therefore uses the
corresponding line timing to extract an 8 kHz signal being used for OMA supervision.
In UA07.1 the native IP IuB feature is introduced, which allows the operator to carry all IuB traffic over
Ethernet transport. With the introduction of this feature BTS systems supporting Ethernet backhaul
won’t have E1/T1 or E3/T3 or STM1/OC-3 connectivity and hence no 8 kHz signal can be derived
anymore from the network clock. To recover an 8 kHz signal with sufficient accuracy for OMA
supervision the IEEE 1588v2 Precision Timing Protocol (PTP) is implemented in the BTS to synchronize
to a PTP time server thereby allowing an 8 kHz signal to be generated internal to the BTS.
The 8 kHz clock being generated via an onboard oscillator of +/- 25 ppm frequency accuracy needs
frequency adjustment to get a long-term frequency accuracy with a Maximum Time Interval Error
(MTIE) of ~ 400 ppb @ 4h. As only frequency adjustment is needed the OneBTS supports only a reduced
PTP functionality (e.g. delay measurement of Sync messages is not needed).
Standards
IEEE P1588 D2.2Draft Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems

Section 1 Pager 18
2 Network Protocols
2.6 IP Iur logical architecture
RNC Peer RNC
GE Link GE Link
IP Network
VR
UP CP
Refer to IuB arch.
Control Plane (CP)
UserPlane (UP)
Node B

RNCs may be connected to the ATM backbone or to the IP backbone or to both. However:
On Iu-R, Control and User plane stacks must be both either IP or ATM; i.e. no mix and match of ATM
Control and IP User plane or vice versa.
At IP level, DiffServ is used for QoS differentiation.
At Ethernet level, VLANs can be used to separate different flows (User Plane, Control Plane) on a single
VR associated with a physical Gigabit Ethernet Port.

Section 1 Pager 19
2 Network Protocols
2.7 IP IU-PS logical architecture
1 Iu flex
domain
IP Network:
Several DSCP
SGSN
RNC GGSN
GE Link
IP/VLAN/G
VR GGSN
STM1 Link
IP/ATM SGSN
GGSN
ATM Network:
Several ATM VCs

In UA06, the RNC can be connected to the SGSN through the CN IP backbone and, optionally, it can be
connected to the GGSN using a direct GTP tunnel for the User Plane without any impact on RNC side
nor on configuration since the SGSN is responsible for providing the User Plane address of the GGSN by
Control Plane signaling.
On Iu-PS, a mix of ATM transport and IP transport is supported, even in the same pool in case of Iu
Flexibility configuration, but both Control Plane and User plane stacks must be either IP or ATM, e.g.
no mix and match of ATM Control Plane and IP User plane or vice versa.
Taken into account also the option to have a direct tunnel between RNC and GGSN, the above RNC
connectivity shall be supported.

Section 1 Pager 20
2 Network Protocols
2.8 IP Iu-CS logical architecture
1 Iu flex
domain
IP Network:
Several DSCP MSC
server
RNC
GE Link
MSC
IP/VLAN/GE MGW
VR
STM1 Link
MGW
MSC
ATM Network:
Several ATM VCs

In a mixed ATM / IP UTRAN, each network element may be connected either to the ATM backbone or to
the IP backbone.
RNCs may be connected to the ATM backbone or to the IP backbone or to both.
MSC/MGW may be either connected on the ATM backbone or on the IP backbone, even in the same pool
in case of Iu Flexibility configuration.
On Iu-CS, Control and User plane stacks must be both either IP or ATM, e.g. no mix and match of ATM
Control and IP User plane or vice versa.
Taken into account both NGN and non-NGN configurations in CS Core Network the above RNC
connectivity with CN nodes shall be supported.

Section 1 Pager 21
2 Network Protocols
2.9 O&M flow architecture
RNC RNC
OMC OMC
Eth. Port Eth. Port
STM1 ports of STM1 ports of
STM1 card STM1 card
Ethernet port Ethernet port

of CP card of CP card
Ethernet ports Ethernet ports

of GE card of GE card
Native IP IP Native IP IP
BTS Network BTS Network
Eth. Port Eth. Port
OAM flow (itfr)

OAM flow (itfb)
Teleco flow over IP

The O&M topologies supported with Native IP Node B, i.e. the possible paths for the O&M Node B flow
(itfb) and for the RNC O&M flow (itfr) are different.
The supported topologies are the result of the combinations of the following rules:
1. The telecom flow of a Native IP Node B is always getting in the RNC on an Ethernet port of the
GigaBit Ethernet card.
2. The O&M flow of a Native IP Node B (itfb) can either:
Not go through the RNC.
Get in the RNC on an Ethernet port of the GigaBit Ethernet card.
3. The O&M flow between the RNC and the OMC can either:
Get in the RNC via the Ethernet port of the CP card,
Get in the RNC on an Ethernet port of the GigaBit Ethernet card.
Get in the RNC via a STM1/OC3 port of the STM1/OC3 card (in case of ATM connection).
From OMC-R side a mix of the previous case per RNS is possible.
4. An OMC can be connected to:
an ATM backbone (via a POC) for Itf-r and itf-b;
an IP backbone for Itf-r and itf-b, i.e. the O&M does not go through ATM but by Ethernet,
a mix of the two previous cases per RNS.
The RNC is the bridge from IP/atm/STM1/OC3 to IP/GE ONLY for the O&M itfb flow.
Another transport node can also provide this ATM to IP bridge role.

Section 1 Pager 22
3 Protocol Stacks


Section 1 Pager 23
3 Protocol Stacks
3.1 Protocols in UTRAN
The Iu protocols
Used to exchange data (traffic
Core Network and signaling) between RNCs,
Node Bs and the Core Network.
Iu
Iu Protocols
The Radio protocols
RNC RNC Used to process the data sent on
the air and for the signaling
Iur between UTRAN and the UEs
Iub
Radio Protocols NAS Signaling

Signaling between a UE and
Node B the Core Network.
Typically, the Authentification
and the Location
Uu Interface
NAS Signaling
Iu Protocols :
RANAP: Radio Access Network Application Protocol,
RNSAP: Radio Network Sub-system Application Protocol,
NBAP: Node B Application Protocol,
ALCAP is a generic name for the signalling protocols of the Transport Network Control
Plane used to establish/release Data Bearers.
It makes establishment/release of Data Bearers on request of the Application Protocol.
Radio Protocols :
RRC: Radio Resource Control
RLC: Radio Link Control
MAC: Medium Access Control
NAS Signaling :
NAS refers to higher layers (3 to 7). Entities of this part will exchange tele-services and bearer
services

Section 1 Pager 24
3 Protocol Stacks
3.2 General model
The same general protocol model is applied for all Iu interfaces:
Radio Network Transport User Plane
Control Plane Network
Control Plane
1. What is the
Radio purpose of the
Network Application Data
Layer Protocol Stream(s) separation
between the
Radio Network
Transport Network Transport Network Transport Network Layer and the
User Plane Control Plane User Plane Transport
Network Layer?
ALCAP
2. Why is
Transport Signaling Signaling Data ALCAP
Layer Bearer(s) Bearer(s) Bearer(s) necessary?
Physical Layer


Section 1 Pager 25
3 Protocol Stacks
3.3 Iub Protocol Stacks
Radio Network Transport User Plane

Control Plane Network
Control Plane
Radio Node B
Network Application Part Iub FP
Layer (NBAP)
ALCAP
Q.2630.2
Q.2150.2
Transport SSCF-UNI SSCF-UNI

Layer
SSCOP SCTP SSCOP UDP
AAL5 IP AAL5 AAL2 IP
ATM Data Link Layer ATM ATM Data Link Layer
Physical Layer

For IP transport of the Iub user plane over Ethernet, the 3GPP requirements, in TS 25426, are:
UDP over IP shall be supported as the transport for DCH data streams on Iub
The transport bearer is identified by UDP port number and IP address (source UDP port number,
destination UDP port number, source IP address, destination IP address).
The source IP address and destination IP address exchanged via Radio Network Layer on the Iur/Iub
interface shall use the NSAP structure.
IP Differentiated Services code point marking shall be supported. The mapping between traffic
categories and Diffserv code points shall be configurable by O&M. Traffic categories are
implementation-specific and may be determined from the application parameters.
The bearer identifiers (UDP port number and IP address) are exchanged between RNC and Node B at each
Radio Link Setup via NBAP signaling messages.
The DSCP is determined by the RNC and given to the Node B at each Radio Link Setup via NBAP signaling
messages.
For IP transport of the Iub Control plane over Ethernet, the 3GPP requirements, in TS 25432, are:
SCTP over IP shall be supported as the transport for NBAP signaling bearer on Iub Interface
The checksum method specified in RFC 3309 shall be used instead of the method specified in RFC 2960
Each signaling bearer between the RNC and Node B shall correspond to one single SCTP stream in UL
and one single SCTP stream in DL direction, both streams belonging to the same SCTP association.
IP Differentiated Services code point marking shall be supported. The DiffServ Code Point may be
determined from the application parameters.
A RNC equipped with the SCTP stack option shall initiate the INIT procedure for establishing association
(new in Rel 7)
Multi-homing is not required

Section 1 Pager 26
3 Protocol Stacks
3.4 I-BTS O&M Plane
Any for site Any for site

SEPE FTP Etc. LAN DHCP Radius Etc. LAN RIP V2
TCP UDP ICMP ARP

IP
Ethernet
DHCP port numbers: Well Known UDP Port Numbers 67 (client) 68 (server)
The protocols for Native iBTS IP

The figure above does not intend to describe all the O&M protocols, which are supported for Native IP
iBTS, because the list is open (due to Site Lan support, for example). It intends to list the main O&M
protocols, and also to illustrate that it is not possible to identify an O&M flow, based on the fact that it
is over TCP.

Section 1 Pager 27
3 Protocol Stacks
3.5 Iur Protocol Stacks
Control Plane User Plane

Radio
Network
Layer RNSAP Iu-R Data Stream(s)
Transport Network Transport Network Transport Network

User Plane Control Plane User Plane
Q.2630.2
SCCP
MTP3-3 M3UA Q.2150.1

MTP3-B
SSCF-NNI
Transport SCTP
SSCF-NNI
Network SSCOP UDP
Layer SSCOP AAL2
AAL5 IP IP
AAL5
ATM Ethernet ATM ATM Ethernet
Physical Layer Physical Layer Physical Layer
Unchanged or refused New or modified

For Iur User Plane the transport bearer is identified by the UDP port number and the IP address (source
UDP port number, destination UDP port number, source IP address, destination IP address).
The source and destination IP addresses and the associated UDP port numbers are exchanged via RNSAP
and shall use the NSAP structure.
There may be one or several IP addresses in the RNC. The packet processing function in the RNC sends
packets of a given RAB to the IP address / UDP port which was associated to that particular RAB when
establishing the connection via RNSAP (either by RNC itself or by peer RNC).

Section 1 Pager 28
3 Protocol Stacks
3.6 Iu-PS Protocol Stacks

Radio
Network
Layer RANAP Iu UP Protocol Layer

SCCP
MTP3-B M3UA M3UA GTP-U GTP-U

SSCF-NNI SCTP UDP
Transport SCTP UDP
Network SSCOP IP IP
Layer
AAL5 IP AAL5 IP
ATM Ethernet ATM Ethernet
Physical Layer Physical Layer
Unchanged or refused New or modified Not support

In this release only IPv4 is supported.

The transport bearer is identified by the GTP TEID and the IP address (source GTP TEID, destination GTP
TEID, source IP address, destination IP address).
The IP addresses and GTP TEID are exchanged between RNC and SGSN by using RANAP protocol.
There may be one or several IP addresses in the RNC and in the CN.

Section 1 Pager 29
3 Protocol Stacks
3.7 Iu-CS Protocol Stacks

Radio
Network
Layer RANAP Iu UP Protocol Layer

Q.2630.2
SCCP
MTP3-3 M3UA Q.2150.1

MTP3-B RTP/
SSCF-NNI RTCP
Transport SCTP
SSCF-NNI AAL2
Network SSCOP UDP
Layer SSCOP
AAL5 IP IP
AAL5
ATM Ethernet ATM ATM Ethernet
Physical Layer Physical Layer Physical Layer
Unchanged or refused New or modified

The transport bearer is identified by the UDP port number and the IP address (source UDP port number,
destination UDP port number, source IP address, destination IP address).
The source IP address and destination IP address are exchanged via RANAP and shall use the NSAP
structure.
There may be one or several IP addresses in the RNC and in the CN.

Section 1 Pager 30
3 Protocol Stacks
3.8 IU- CS – RTP/RTCP Protocol
Iu/UP
RTP/RTCP
UDP
IP
Ethernet

RTP (Real time protocol) provides end-to-end network transport functions suitable for applications
transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network
services. The data transport is augmented by a control protocol (RTCP) to allow monitoring
of the data delivery in a manner scalable to large multicast networks, and to provide minimal
control and identification functionality. RTP and RTCP are designed to be independent of the
underlying transport and network layers.
The header structure of RTP includes payload type,sequence number, timestamp and the synchronization
source.
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all
participants in the session, using the same distribution mechanism as the data packets. RTCP performs
four functions:
The primary function is to provide feedback on the quality of the data distribution.This is an integral part
of the RTP's role as a transport protocol and is related to the flow and congestion control functions of
other transport protocols.
RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or
CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted,
receivers require the CNAME to keep track of each participant. Receivers also require the CNAME to
associate multiple data streams from a given participant in a set of related RTP sessions, for example to
synchronize audio and video.
The first two functions require that all participants send RTCP packets, therefore the rate must be
controlled in order for RTP to scale up to a large number of participants.
A fourth, optional function is to convey minimal session control information, for example participant
identification to be displayed in the user interface.the primary function is to provide feedback on the
quality of the data distribution.

Section 1 Pager 31
4 Radio Channels


Section 1 Pager 32
4 Radio Channels
4.1 Global Situation
UE UTRAN SGSN GGSN PDN

“Internet”
Teleservice
UMTS Bearer Service External Bearer

Service
Radio Access Bearer Service CN Bearer
(RAB) Service
Radio Bearer Iu Bearer Backbone

Service Service Bearer Service
Logical
Channel
Transport
Channel
Physical
Channel
Uu Iu

A Radio Bearer is the service provided by a protocol entity (i.e. RLC protocol) for transfer of data
between UE and UTRAN.
Radio bearers are the highest level of bearer services exchanged between UTRAN and UE.
Radio bearers are mapped successively on logical channels, transport channels and physical channels
(Radio Physical Bearer Service on the figure)

Section 1 Pager 33
4 Radio Channels
4.2 RAB Presentation
UMTS Bearers
CN-CS
RAB
RAB
UTRAN UMTS Bearer
UE RAB UMTS Bearer

RAB
UMTS bearer CN-PS
services
Radio Bearers Iu Bearers
RABs (mapped on Radio & Iu Bearers)
“The RAB provides confidential transport of signaling and user

data between UE and CN with the appropriate QoS”.

Example of available RAB in R4

Conversational
AMR 12.2/12.2, 64/64
(CS)
Streaming (CS) 14.4/14.4
Interactive (PS) R2: 64/128, 64/384 64/144, 128/384, 144/384, 32/32, 64/64, 128/128, 144/144
Background
R2: 64/128, 64/384 64/144, 128/384, 144/384, 32/32, 64/64, 128/128, 144/144
(PS)

Section 1 Pager 34
4 Radio Channels
4.3 Radio Channels, Protocols & Network Elements
Control User
Plane Plane
NAS Voice Web SMS Cell
Signaling Browsing Broadcast
RRC …
PDCP BMC
RRC
Sig. Radio
Bearers
MAC
RLC Physical Channels
Control Traffic Transport
Logical Ch. Logical Ch. Channels
MAC Uu Interface
Transport Physical Layer Physical Layer

Channels
…
RNC Node B UE

The radio protocols are responsible for exchanges of signalling and user data between the UE and the
UTRAN over the Uu interface:
User plane protocols

These are the protocols implementing the actual Radio Access Bearer (RAB) service, i.e. carrying
user data through the access stratum.
Control plane protocols

These are the protocols for controlling the radio access bearers and the connection between the
UE and the network from different aspects including requesting the service, controlling different
transmission resources, handover & streamlining etc...
Also a mechanism for transparent transfer of Non Access Stratum (NAS) messages is included.
Some principles:
The Radio Protocols are independent of the applied transport layer technology (ATM in R99): that
may be changed in the future while the Radio Protocols remain intact.
The main part of radio protocols are located in the RNC (and in the UE).
The Node-B is mainly a relay between UE and RNC.

Section 1 Pager 35
4 Radio Channels
4.4 Radio Bearers
Signaling Radio Bearers (SRB)

SRBs can carry:
- layer 3 signaling (e.g. RRC connection establishment)
- NAS signaling (e.g location update)
There can be up to 4 SRBs per RRC connection (one UE has one RRC
connection when connected to the UTRAN).
User Plane Radio Bearers

RABs are mapped on user plane RBs.
One RAB can be divided on RAB sub-flows and each sub-flow is mapped on
one user plane RB.
e.g the AMR codec encodes/decodes speech into/from three sub-flows; each
sub-flow can have its own channel coding.

Please note that RAB (Radio Access Bearer) are only provided in the user plane.
What is a RRC connection?

When the UE needs to exchange any information with the network, it must first establish a
signalling link with the UTRAN: it is made through a procedure with the RRC protocol and it is
called “RRC connection establishment”.
During this procedure the UE will send an initial access request on CCCH to establish a signalling
link which will be carried on a DCCH.
A given UE can have either zero or one RRC connection.

Section 1 Pager 36
4 Radio Channels
4.5 Logical Channels
UTRAN Logical Channels UE

Control Channels (CCH)
Broadcast Control Channel (BCCH)
Paging Control Channel (PCCH)
Common Control Channel (CCCH)
MBMS Control Channel (MCCH)
MBMS Scheduling Channel (MSCH)
Dedicated Control Channel (DCCH)

Traffic Channels (TCH)
Dedicated Traffic Channel (DTCH)
Common Traffic Channel (CTCH)
MBMS Traffic Channel (MTCH)

The logical channels are divided into:
Control channels for the transfer of control plane information
Traffic channels for the transfer of user plane information

Section 1 Pager 37
4 Radio Channels
4.5 Logical Channels [cont.]
UL or DL What type of information?
BCCH System control information

e.g cell identity, uplink interference level
PCCH Paging information
e.g CN originated call when the network does not know the location
cell of the UE
CCCH Control information
e.g initial access (RRC connection request), cell update
DCCH Control information
(but the UE must have an RRC connection)
MCCH Carries control plane information between network and UEs
MSCH Carries transmission schedule between network and UEs
DTCH Traffic information dedicated to one UE e.g speech, fax, web browsing
CTCH Traffic information to all or a group of UEs e.g SMS-Cell Broadcast
MTCH Carries user plane traffic


Section 1 Pager 38
4 Radio Channels
4.6 Why Transport Channels?
Traffic
Time
Time Interval
Transport
Channel
A transport channel offers a flexible pattern to arrange information on any

service-specific rate, delay or coding before mapping it on a physical
channel:
• it provides flexibility in traffic variation
• it enables multiplexing of transport channels on the same physical channel
Transport channels provide an efficient and fast flexibility in radio

resource management.

The transport channels provides a flexible pattern to exchange data between UTRAN and the UE at a
variable bit rate for the multimedia services.
The logical channels are mapped on the transport channels by the MAC protocols.
By this way the data are processed according to the QoS required before sending them to the Node B by
the Iub.

Section 1 Pager 39
4 Radio Channels
4.7 Structure of a Transport Channel
Transport Block: basic Transport Format (TF): it may be changed every TTI. Each
unit exchanged over TF must belong to the Transport Format Set (TFS) of the
transport channels. transport channel
168
168 bits 168 168 168
168 168 168 168

20 ms 20 ms 20 ms 20 ms
Time Transmission
Interval (TTI): periodicity >> The system delivers one Transport Block Set to the
at which a Transport Block physical layer every TTI:
TTI: what is the delivery bit rate of the
Set is transferred by the transport blocks to the physical layer during the first TTI?
physical layer on the radio
interface

A transport channel is defined by a Transport Format (TF) which may change every Time Transmission
Interval (TTI).
The TF is made of a Transport Block Set. The Transport Block size and the number of Transport Block
inside the set are dynamical parameters.
The TTI is a static parameter and is set typically at 10, 20 or 40 ms.
For example,
For a video-call (CS service at 64 kbps)
TTI = 20 ms
TFS = (640* 0,2)
Turbo coding (coding rate=1/3)
16 CRC bits
For a PS 64 kbps service

TTI=20 ms
TFS = (336* 0,1,2,3,4)
Turbo coding (coding rate=1/3)
16 CRC bits

Section 1 Pager 40
4 Radio Channels
4.7 Structure of a Transport Channel [cont.]
Transport Format (TF)

• Semi-static part (can be changed, but long process)
Transmission Time Interval (TTI),
Coding scheme...
• Dynamic part (may be changed easily)
Size of transport block,
Number of transport blocks per TTI
Transport Format Set (TFS)

It is the set of allowed Transport Formats for a transport channel, which is
assigned by RRC protocol entity to MAC protocol entity.
MAC chooses TF among TFS.
MAC may choose another TF every TTI without interchanging with RRC
protocol (fast radio resource control).

What is TTI (Transmission Time Interval)?

it is equal to the periodicity at which a Transport Block Set is transferred by the physical layer on
the radio interface
it is always a multiple of the minimum interleaving period (e.g. 10ms, the length of one Radio
Frame)
MAC delivers one Transport Block Set to the physical layer every TTI.
What does the TFS provide ?

The selection at each TTI of a number of transport block among the allowed list provides the
required flexibility for the variable traffic and allows to manages the priority.

Section 1 Pager 41
4 Radio Channels
4.8 Transport Channels: Example
576 bits
576 576
576 576 576
576 576 576

40 ms
Static Part
TTI ? 1. Complete the table
Coding scheme Turbo coding, coding rate=1/3
CRC 16 bits 2. What is the delivery
bit rate of the transport
Dynamic Part blocks to the physical
Transport Block Size ? layer during the first TTI?
Transport Block Size Set 576*B (B=0,1,2,3,4)
3. How many Transport Format(s)

Format(s) may be chosen for this transport channel?
4. Can you imagine why the transfer has been interrupted during the third TTI?


Section 1 Pager 42
4 Radio Channels
4.9 Transport Channels
UTRAN Transport Channels UE

Common Channels
Broadcast Channel (BCH)
Paging Channel (PCH)
Forward Access Channel (FACH)
Downlink Shared Channel (DSCH)
Random Access Channel (RACH)
Common Packet Channel (CPCH)
Dedicated Channels
Dedicated Channel (DCH)

The transport channels are divided into:
Common channels: they are divided between all or a group of UEs in a cell. They require in-band
identification of the UEs when addressing particular UEs.
Dedicated channels: it is reserved for a single UE only. In-band identification is not necessary, a given UE
is identified by the physical channel (code and frequency in FDD mode)

Section 1 Pager 43
4 Radio Channels
4.10 Common Transport Channels
BCH: Broadcast Channel

A downlink transport channel that is used to carry BCCH. The BCH is always
transmitted with high power over the entire cell with a low fixed bit rate.
>> The BCH is the only transport channel with a single transport format (no
flexibility). Can you explain why?
PCH: Paging Channel

A downlink transport channel that is used to carry PCCH. It is always
transmitted over the entire cell.
>> Is it possible to carry all types of information on the PCH?

BCH
high power to reach all the user and low fixed bit rate so that all terminals can decode the data
rate whatever its ability: only one Transport Format because there is no need for flexibility (fixed
bit rate)
PCH
only two transport channels can NOT carry user information: BCH and PCH.

Section 1 Pager 44
4 Radio Channels
4.10 Common Transport Channels [cont.]
FACH: Forward Access Channel

A downlink transport channel that is used to carry control information. It may also
carry short users packets. The FACH is transmitted over the entire cell or over only a
part of the cell using beam-forming antennas. The FACH uses open loop power
control (slow power control).
>> In which case is it interesting to use beam-

beam-forming antennas? would it also be
relevant to implement this feature for PCH?
RACH: Random Access Channel

An uplink transport channel that is used to carry control information from the mobile
especially at the initial access. It may also carry short user packets. The RACH is
always received from the entire cell and is characterized by a limited size data field, a
collision risk and by the use of open loop power control (slow power control).
>> Why is it interesting to carry short user packets on RACH in spite of limited data
field and collision risk (instead of using a dedicated channel)?

Note: Beam-forming is also called “Inherent addressing of users”: it is the possibility of transmission to a
certain part of the cell.
RACH and FACH are mainly used to carry signalling (e.g at the initial access), but they can also carry
small amounts of data.
When a UE sends information on the RACH, it will receive information on FACH.

Section 1 Pager 45
4 Radio Channels
4.10 Common Transport Channels [cont.]
DSCH: Downlink Shared Channel

A downlink transport channel shared by several UEs to carry dedicated
control or user information. When a UE is using the DSCH, it always has an
associated DCH, which provides power control.
CPCH: Common Packet Channel

An uplink transport channel that is used to carry long user data packets and
control packets. It is a contention based random access channel. It is always
associated with a dedicated channel on the downlink, which provides power
control.
⇒ Transfer of signalling and traffic on a shared basis

DSCH and CCPH seem to be symmetrical, but:
DSCH is on the DL, so that different user data are synchronised with each other (the information
on whether the UE should receive the DSCH or not is conveyed on the associated DCH)
CPCH is on the UL, so that different user data can NOT be synchronised (the mobile phones are not
synchronised). It may cause big problem of collisions!

Section 1 Pager 46
4 Radio Channels
4.11 Dedicated Transport Channels
DCH: Dedicated Channel

A downlink or uplink transport channel that is used to carry user or control
information. It is characterized by features such as fast rate change (on a
frame-by-frame basis), fast power control, use of beam-forming and
support of soft HO.

DCH
It is different from GSM where TCH carries user data (e.g speech frames) and ACCH carries higher
layer signalling (e.g HO commands)
User data and signalling are therefore treated in the same way from the physical layer (although set of
parameters may be different between data and signalling)
wide range of Transport Format Set permits to be very flexible concerning the bit rate, the
interleaving...
Fast Power Control and soft HO are only applied on this transport channel.

Section 1 Pager 47
4 Radio Channels
4.12 Mapping Logical / Transport Channels
Traffic Logical Channels

Control Logical Channels
BCCH PCCH CCCH MSCH MCCH DCCH DTCH CTCH MTCH
BCH PCH RACH FACH DSCH CPCH DCH
Common Transport Channels Dedicated

Transport
Channels


Section 1 Pager 48
4 Radio Channels
4.12 Mapping Logical / Transport Channels [cont.]
Control Logical Channels Traffic Logical Channels
BCCH PCCH CCCH DCCH DTCH CTCH
BCH PCH RACH FACH DSCH CPCH DCH
Common Transport Channels Dedicated

Transport
Channels

According to the slide above and the previous one, we can say state that :
Except BCH and PCH, each type of transport channel can be used for the transfer of either control or
traffic logical channels.

Section 1 Pager 49
4 Radio Channels
4.13 Physical Channels
For the UE point of view, the network is just the physical channels.
There are several kinds of physical channels.
RNC
• Channel associated with transport channel
Transport Iub
Channels • UTRAN Signaling (mobility management)
• Core Network Signaling (authentication)
Node B • User Traffic (voice)

There are common and dedicated channels
• Channels not associated with transport channel, the physical
signaling.
• Cell Search Selection
• System Information Collection
• Connection Request and Paging Surveillance
These channels and resources allowing the UE to share these
channels with other users are the radio resources
We will see later how data from transport channel are processed to be
mapped on the physical channels and how a UE uses these channels.

On a cell, all the physical channels are sent on the same frequency and on the same time.
It is due to the radio technology, the WCDMA, really different than the one used with the GSM.
Here the physical channels are separated by codes. We will see this point on the next chapter.

Section 1 Pager 50
4 Radio Channels
4.14 Physical Channel List
Not associated with transport channels
• CPICH: Common Pilot Channel

• PICH: Page Indicator Channel
• MICH: MBMS Indication Channel
• P-SCH & S-SCH: Primary & Secondary Synchronization Channel
• AICH: Acquisition Indicator Channel
Dedicated Physical Channels, associated with transport channels
• DPDCH: Dedicated Physical Data Channel

• DPCCH: Dedicated Physical Control Channel
Common Physical Channels, associated with transport channels
• P-CCPCH & S-CCPCH: Primary & Secondary Common Control Channel

• PRACH: Physical Random Access Channel
• PDSCH: Physical Downlink Shared Channel
• PCPCH: Physical Common Packet Channel


Section 1 Pager 51
4 Radio Channels
4.15 Downlink
DTCH, DCCH MTCH MSCH, MCCH CCCH, CTCH PCCH BCCH
Logical Ch
Transport Ch
DCH1 DCH2 DSCH FACH PCH BCH
Not implemented
yet in Alactel-Lucent
CCTrCH Solution
Physical Ch
DPDCH
DPDCH and DPCCH + PDSCH S-CCPCH P-CCPCH
multiplexed by time DPCCH
Dedicated Common Physical Ch
Physical Ch
Not associated with

AICH PICH MICH CPICH P-SCH S-SCH
transport channels
MSCH, MCCH, MTCH map to FACH (only in DL)

Some common transport channels are multiplexed on the same physical channels. Like the FACH and the
PCH on the S-CCPCH.
The FACH is a downlink common channel to carry the traffic and the control data.
The PCH is the Paging channel.
By the same principles, several DCH (Dedicated channel) belonging to the same user are mapped
on one physical channel, the DPDCH. The DPCCH is its control channel at the physical level.

Section 1 Pager 52
4 Radio Channels
4.16 Uplink
DTCH, DCCH CCCH
Logical Ch
Transport Ch
DCH1 DCH2 RACH CPCH
CCTrCH
Physical Ch
DPDCH and DPCCH DPDCH PRACH PCPCH

multiplexed by +
modulation DPCCH
Dedicated Physical Ch Common Physical Ch

There are less channels in uplink. For the physical channels, there are the dedicated channels (DPDCH)
and the common channels (PRACH).
The PCPCH is not implemented in the Alactel-Lucent Solution.

Section 1 Pager 53
4 Radio Channels
4.17 Physical Channels: Structure
Radio Frame = 10 ms
15 Time Slots
1 Time slot
= 0.666 ms
….
N bits
(according to the bit rate)
A physical channel is defined by:

•A carrier
• Some codes (see 4.3 and 4.4 part)
• A start and stop instant
Physical channels are sent continuously on the air interface between start and stop instants.

After channel coding each transport block is split into radio frames of 10 ms.
The bit rate may be changed for each frame.
Each radio frame is also split into 15 time slots.
But all time slots belong to the same user (this slot structure has nothing to do with the TDMA structure
in GSM).
All time slots of a same TDMA frame have the same bit rate.
Fast power control may be performed for each time slot (1500 Hz).
The number of chips for one bit M is equivalent to the spreading factor. It can easily be computed with
knowledge of N:
In fact the spreading factor must be equal to 4, 8, 16…256.
Consequently it may be necessary to add some padding bits to match the adequate value of spreading
factor (rate matching).

Section 1 Pager 54
5 UTRAN Radio Protocols


Section 1 Pager 55
5.1 Radio protocol stack
Control plane User plane

Non Access Stratum
Bearers (called
Access Stratum RAB in user plane)
control
Layer 3 RRC
PDCP
PDCP SAP
control
control
Layer 2/PDCP
Layer 2/BMC BMC
control
control
Radio Bearers
Layer 2/RLC RLC RLC

RLC RLC
RLC
RLC RLC RLC
Logical Channels
Layer 2/MAC MAC

Transport Channels
Layer 1 PHY
Physical Channels

The radio protocols are responsible for exchanges of signalling and user data between the UE and the
UTRAN over the Uu interface
The radio protocols are layered into:
the RRC protocol located in RNC* and UE
the RLC protocol located in RNC* and UE
the MAC protocol located in RNC* and UE
the physical layer (on the air interface) located in Node-B and UE
Two additional service-dependent protocols exists in the user plane in the layer 2: PDCP and BMC.
Each layer provides services to upper layers at Service Access Points (SAP) on a peer-to-peer
communication basis. The SAP are marked with circles. A service is defined by a set of service primitives.
Radio Interface Protocol Architecture is described in 3GPP 25.301.
(*except a part of protocol used for BCH which is terminated in Node-B)

Section 1 Pager 56
5.2 Radio Resource Control (RRC)
Call management
Bearers
Radio mobility management
Layer 3
RRC
Measurement control and reporting
control
control
control
control
Radio Bearers Outer loop power control
control
(control plane)
PDCP
BMC
RLC
MAC
PHY
RRC is the brain of the radio interface protocol stack.

RRC is a protocol which belongs to control plane.
The RRC functions are:
Call management
RRC connection establishment/release (initial access)
Radio Bearer establishment/release/reconfiguration (in the control plane and in the user
plane)
Transport and Physical Channels reconfiguration
Radio mobility management
Handover (soft and hard)

Cell and URA update (see “5.UTRAN/ Mobility Management”)
Paging procedure
Measurements control (UTRAN side) and reporting (UE side)
Outer Loop Power Control
Control of radio channel ciphering and deciphering
RRC can control locally the configuration of the lower layers (RLC, MAC...) through Control
SAP. These Control services are not requiring peer-to-peer communication, one or more sub-
layers can be bypassed.
See 3GPP 25.331 RRC protocol (over 500 pages!)

Section 1 Pager 57
5.3 PDCP and BMC Protocols
PDCP (Packet Data Convergence Protocol)

- in the user plane, only for services from the PS domain
- it contains compression methods
In R99 only a header compression method is mentioned (RFC2507).
Why is header compression valuable?
e.g a combined RTP/UDP/IP headers is at least 60 bytes for IPv6, when IP
voice service header can be about 20 bytes or less.
BMC (Broadcast/Multicast Services)

- in the user plane
- to adapt broadcast and multicast services from NAS on the radio interface
In R99 the only service using this protocol is SMS Cell Broadcast Service
(directly taken from GSM).

See 3 GPP 25.323 (PDCP protocol) and 25.324 (BMC protocol)

Section 1 Pager 58
5.4 Radio Link Control (RLC)
Segmentation
Radio Bearers Radio Bearers
(control plane) (user plane) Buffering
Data transfer with 3
Layer 2/ RLC RLC
upper part RLC
RLC RLC configuration modes:
RLC RLC RLC
- Transparent (TM)
Control Traffic
Logical Logical - Unacknowledged (UM)
Channels Channels
- Acknowledged (AM)
Ciphering
RLC provides segmentation and (in AM mode) reliable data transfer.

There is no difference between RLC instances in Control and User planes. There is a single RLC
connection per Radio Bearer.
RLC main functions:
RLC Connection Establishment/Release in 3 configuration modes:

- transparent data transfer (TM): without adding any protocol information
- unacknowledged data transfer (UM): without guaranteeing delivery to the peer entity (but can
detect transmission errors)
acknowledged data transfer (AM): with guaranteeing delivery to the peer entity. The AM mode
provides reliable link (error detection and recovery, in-sequence delivery, duplicate detection,
flow Control, ARQ mechanisms)
ARQ=Automatic Repeat Request (it manages retransmissions)
Transmission/Reception buffer
Segmentation and reassembly (to adjust the radio bearer size to the actual set of transport formats)
Mapping between Radio Bearers and Logical Channels (one to one)
Ciphering for non-transparent RLC data (if not performed in MAC), using the UEA1, Kasumi algorithm
specified in R’99
Encryption is performed in accordance with TS 33.102 (radio interface), 25.413, 25.331(RRC signaling
messages) and supports the settings of integrity with CN (CS-domain/PS-domain)
3GPP 25.322 RLC protocol

Section 1 Pager 59
5.5 Medium Access Control (MAC)
Control Traffic
Logical Logical Basic data transfer
Channels Channels
Multiplexing of logical channels
Layer 2/
lower part MAC Priority handling/Scheduling
(TFC selection)
Transport
Reporting of measurements
Channels
(common and Ciphering
dedicated)
MAC can switch a common channel into a dedicated channel if higher bit rate
is required (on request of L3-level).
MAC can change dynamically Transport Format (bit rate…) of each transport
channel on a frame basis (each 10 ms) without interchanging with L3-level.
MAC provides flexible data transfer.

MAC belongs to control plane and to user plane.
MAC main functions:
Data transfer: MAC provides unacknowledged data transfer without segmentation
Multiplexing of logical channels (possible only if they require the same QoS)
Mapping between Logical Channels and Transport Channels
Selection of appropriate Transport Format for each Transport Channel depending on instantaneous
source rate.
Priority handling/Scheduling according to priorities given by upper layers:

- between data flows of one UE
- between different UEs
Priority handling/Scheduling is done through Transport Format Combination (TFC) selection
Reporting of monitoring to RRC
Ciphering for RLC transparent data (if not performed in RLC)
3GPP 25.321 MAC protocol

Section 1 Pager 60
5.6 The Physical Layer
Common Dedicated
Transport Transport Multiplexing of transport ch.
Channels Channels
Spreading/modulation
Layer 1 Physical layer RF processing
Power control
Common Dedicated
Physical Physical Measurements
Channels Channels
Air Interface
The physical layer provides multiplexing and radio frequency

processing with a CDMA method.

The physical layer belongs to control plane and to user plane.
Physical layer main functions:
Multiplexing/de-multiplexing of transport channels on CCTrCH (Coded Composite Transport

Channel) even if the transport channels require different QoS.
Mapping of CCTrCH on physical channels
Spreading/de-spreading and modulation/demodulation of physical channels
RF processing (3 GPP 25.10x)
Frequency and time (chip, bit, slot, frame) synchronization
Measurements and indication to higher layers (e.g. FER, SIR, interference power, transmit power,
etc.)
Open loop and Inner loop power control
Macro-diversity distribution/combining and soft handover execution
3GPP 25.2xx

Section 1 Pager 61
6 Exercises


Section 1 Pager 62
6 Exercises
6.1 MAC protocol
BCCH MSCH MCCH PCCH BCCH MTCHMTCH CCCH CTCH DCCH DTCH DTCH
MAC
Control
MAC-d
MAC-b MAC-c/sh/m
BCH PCH FACH FACH RACH CPCH DSCH DSCH DCH DCH
Iur or local
Look at this figure and answer the questions on the following pages.
pages.


Section 1 Pager 63
6 Exercises
6.1 MAC protocol [cont.]
1. On which logical/transport channels will be mapped:

system information broadcasting
paging
telephony speech
internet browsing at a high bit rate
internet browsing at a low bit rate
Can you imagine a situation where the UE will use 2 DTCHs (or more) at the
same time?
2. Guess the meaning of “MAC-b” “MAC-c/sh”, MAC-m and “MAC-d”.
3. Why is there one MAC-d entity on the UE side and several MAC-d entities on the
UTRAN side?
4. What is the link between MAC-c/sh and MAC-d for?


Section 1 Pager 64
6 Exercises
6.1 MAC protocol [cont.]
5. What are the 4 main functions of MAC protocol?
6. MAC can multiplex logical channels only if they require the

same QoS: true or false?
7. Which entity is responsible for TFS selection? TF allocation?
8. Will the physical channel configuration be changed

(e.g modification of spreading factor) when MAC selects a
new TF inside TFS?
9. MAC makes measurement reports to RRC: why is it necessary?


Section 1 Pager 65
Evaluation
Objective: To be able to draw the UTRAN

architecture with the protocol stack
(radio and Iu) of each network element and
to define the channels generated by these
protocols.
Thank you for answering

the objectives sheet


Section 1 Pager 66
End of Module


Section 1 Pager 67
2
Section 2
WCDMA for UMTS
9300 WCDMA

Section 2 Pager 1
Blank Page

WCDMA for UMTS
Document History

Section 2 Pager 2
Objectives
To be able to define a Radio Resource in 3G

WCDMA for UMTS

Section 2 Pager 3
Objectives [cont.]

WCDMA for UMTS

Section 2 Pager 4
Table of Contents
Context Scenarios: Soft Handover Page

inter RNC
Historical Scenarios: SRNC Relocation
1 Context
Advantages & Disadvantages 7
Soft Handover & Code Management
1.1 Historical
3GPP Cost & Benefit 8
1.2 Advantages & Disadvantages
Analogy Rake Receiver 9
1.3 3GPP
WCDMA and Restaurant Rake Receiver principle 10
2 Analogy
Spread Spectrum Modulation Rake Receiver and Multi-Service
11
2.1
A CodeWCDMA
as a Shellandagainst
Restaurant
Noise Rake Receiver and soft handover
12
3 Spread
SpectrumSpectrum
spreading Modulation Rake Receiver and Path Diversity
15
3.1 A Code Chain
Transmission as a Shell against Noise Power Control 16
Code & Spreadingspreading
3.2 Spectrum factor Why ? 17
Spreading factor & Data Rate Different kinds of Power Control
3.3 Transmission Chain 18
Spreading Open Loop Power Control
3.4 Codefactor & Error atfactor
& Spreading reception 19
Closed Loop Power Control: Principle
Exercise: Orthogonal Code

3.5 Spreading factor &
WCDMA, Power Density & Processing Gain
Data Rate Closed Loop Power Control: 20
Power Density
3.6 Spreading factor & Error at reception UL Closed Loop PC, in case 21Soft Handover
of
Code Division Multiple Access
3.7 Exercise: Orthogonal Code
One-cell reuse DL Closed Loop PC, in case of 23Soft Handover
3.7 WCDMA,
Multiple access Power Density & Processing Gain Capacity, Coverage & 24
Quality
4 Code
Spreading:Division Multipleand
Channelization Access
Scrambling Links between Coverage, Capacity26 and Quality
4.1 One-cell reuse
Channelization Codes (Spreading Codes) Improvement Ways 27
4.2 Multiple
Scrambling codesaccess Typical Values 28
Soft 4.3Handover
Spreading: Channelization and Scrambling 30
4.4 Channelization Codes (Spreading Codes)
Introduction 31
4.5 Scrambling
Scenarios: codes
Softer Handover 32
5 Soft Handover
Scenarios: Soft Handover 33
5.1 Introduction 34
5.2 Scenarios: Softer Handover 35
5.3
2 5Scenarios: Soft Handover intra All RNC
Rights Reserved © Alcatel-Lucent 2010
36
WCDMA for UMTS
5.4
9300 WCDMA Scenarios:
TMO18246 Soft
9300 WCDMA UAO7 Handover
R99 Radio Principles inter RNC 37
5.5 Scenarios: SRNC Relocation 38
5.6 Soft Handover & Code Management 39
5.7 Cost & Benefit 40
6 Rake Receiver 42
6.1 Rake Receiver principle 43
6.2 Rake Receiver and Multi-Service 45
6.3 Rake Receiver and soft handover 46
6.4 Rake Receiver and Path Diversity 47
7 Power Control 49
7.1 Why ? 50
7.2 Different kinds of Power Control 51
7.3 Open Loop Power Control 52
7.4 Closed Loop Power Control: Principle 53
7.4 Closed Loop Power Control: Power Density 54
7.5 UL Closed Loop PC, in case of Soft Handover 55
7.5 DL Closed Loop PC, in case of Soft Handover 56
8 Capacity, Coverage & Quality 57
8.1 Links between Coverage, Capacity and Quality 58
8.2 Improvement Ways 59
8.3 Typical Values 60

Section 2 Pager 5
Page

WCDMA for UMTS This page is left blank intentionally

Section 2 Pager 6
1 Context

WCDMA for UMTS

Section 2 Pager 7
1 Context
1.1 Historical
Early 70’s
CDMA developed for military field for its great qualities of privacy (low
probability interception, interference rejection)
1996
CDMA commercial launch in the US
This system called IS-95 or cdmaOne was developed by Qualcomm and has
reached 50 million subscribers worldwide
2000
IMT-2000 has selected three CDMA radio interfaces:
- WCDMA (UTRA FDD)
- TD-CDMA (UTRA TDD)
- CDMA 2000
In the following material we will only refer to WCDMA (UTRA FDD)

WCDMA for UMTS
See http://www.cdg.org for IS-95
In CDMA field, we have experience of IS-95
IS-95 vocabulary:
forward channel=downlink
reverse channel=uplink
handoff=handover

Section 2 Pager 8
1 Context
1.2 Advantages & Disadvantages
CDMA is very attractive:
• Better spectrum efficiency than 2G systems
• Suitable for all type of services (circuit, packet) and for multi-services
• Enhanced privacy
• Evolutionary (linked with progress in signal processing field)
BUT:
• Complex system: not easy to configure and to manage
• Unstable in case of congestion

WCDMA for UMTS
Spectrum efficiency : transmission capacity per spectrum unit (bandwidth), i.e kbit/MHz.
This must not be confused with the traffic capacity.
The spectrum efficiency in UMTS is higher than in GSM (25x200kHz carriers in GSM offering 335 kbps**
while a 5 MHz UMTS carrier offers 400 kbps).
If we factor in densification (frequency reuse pattern), the UMTS traffic capacity is dramatically
increased. According to CDMA Development Group:
“Capacity increases by a factor of between 8 to 10 compared to an AMPS
analog system and between 4 to 5 times compared to a GSM system”

Section 2 Pager 9
1 Context
1.3 3GPP
The 3GPP is the organization in charge of the standardization of the

UMTS.
It is made of standardization organization (ETSI in Europe, T1 in USA,
ARIB in Japan or CTWS in China …), member of manufacturers and
operators.
The UMTS frequency allocations are :
2110 2170 2200
FDD MSS
1900 1920 1980 2010 2025
TDD FDD MSS TDD

FDD: Frequency Division Duplex
TDD: Time Division Duplex Uplink Downlink
MSS: Mobile Satellite System

WCDMA for UMTS

Section 2 Pager 10
2 Analogy

WCDMA for UMTS

Section 2 Pager 11
2 Analogy
2.1 WCDMA and Restaurant
WCDMA Restaurant Room

• Cell
Restaurant room Enjoy your Guten
meal ! appetite !
• UE
People at table
Code 1
Ues, like people, send
and receive on the
same time and the
Code 2
same frequency. They
are separeted by:
• Code
Language
Bon Bom
For a table, the conversations of the neighbours appetit ! apetite !
are noise, for a UE it is the same principle:
neighbour conversations are interference

WCDMA for UMTS
The equivalence are:
Restaurant room -> Cell
Table -> UE
Language -> Code
Here the important point is all the UEs send and receive on the same time and on the same frequency.
The WCDMA is really different because with the GSM, the UEs are separated by the time (TS of TDMA)
and the frequency. Here the UEs are separated with codes applied on the signals.
Another important point is for someone the conversation on a neighbour table is considered like noise. It
is the same principle with the WCDMA, for a user the other UEs generates some noises.

Section 2 Pager 12
2 Analogy
2.1 WCDMA and Restaurant [cont.]
Downlink Enjoy your ????

meal !
•Node B
Steward
Interference level in DL
problem:
•If some UE use too much COMO
power ESTAS ?
•If there are too many
users in the cell
???
Impacts:
•Power Control in DL Who have
order this cake
•Control Admission ?
Very important !

WCDMA for UMTS
In downlink,
In the restaurant, the steward want to ask to every table who have order a cake. If some people
speak to loud, the table at the back of the room can’t hear the question. It is the same case, if
there are too many users in the room.
In the cell, it is the same principle. If there are too many Ues on the cell or if some Ues use too
much power, the interference level for a UE far from the Node B is too high to allow the UE
decoding the message.

Section 2 Pager 13
2 Analogy
2.1 WCDMA and Restaurant [cont.]
Es ist
Uplink It is for me
! meine
At the Node B level:
• If a UE, close to the NB,
speak too loud
•If there are too many
users
C’est à la
Problem of interference pomme ?
level too high.
The NB can’t decode any
users anymore.
Impacts:
Who have QUIERO LA
• Power Control in UL order ????
this cake
? TARTA!!
•Admission Control
Very important

WCDMA for UMTS
In Uplink,
In the restaurant, a steward can understand all the conversation if he knows all the languages.
But if on a table, close to him, some one speak to loud the steward can’t understand people on
the other tables. It is the same problem if there are too many people it is too noisy to able to
understand a conversation far from him.
With the WCDMA, there is the same problem. That means if the cell is too load,
the interference level at the Node B is too high to be able to decode the weakest signal.

Section 2 Pager 14
3 Spread Spectrum Modulation

WCDMA for UMTS

Section 2 Pager 15
3.1 A Code as a Shell against Noise
Noise
Spreading Despreading
Radio Channel
Transmitter Receiver
The letter ‘A’ represents the signal to transmit over the radio interface.
At the transmitter the height (ie the power) of ‘A’ is spread, while a color
(i.e a code) is added to ‘A’ to identify the message .
At the receiver ‘A’ can be retrieved with knowledge of the code, even if
the power of the received signal is below the power of noise due to the
radio channel.

WCDMA for UMTS

Section 2 Pager 16
3.2 Spectrum spreading
Interference Level
P P Radio channel
P P ???
f Spreading f f Despreading
f
At the transmitter the signal is multiplied by a code which spreads the

signal over a wide bandwidth while decreasing the power (per unit of
spectrum).
At the receiver it is possible to retrieve the wanted signal by multiplying
the received signal by the same code: you get a peak of correlation,
while the noise level due to the radio channel remains the same, because
this is not correlated with the code.
But the interference level is too high, it is not possible to decode any
message.

WCDMA for UMTS
What is the interference level ?

The interference level is the power received on the UMTS bandwidth used. These interferences are made
of:
the background noise,
the messages of the other users,
the traffic on the neighbouring cells.
Because all the users on a cells use the same bandwidth on the same time, and the users on the other
cells too, the decoding and so the error ratio depend on the interference level.

Section 2 Pager 17
3.3 Transmission Chain
Air Interface
NB-Signal WB-Signal WB-Signal NB-Signal
Data Data
Modulator Demodulator
Code sequence Code Sequence
The narrowband data signal is multiplied bit per bit by a code sequence:
it is known as “chipping”.
The chip rate (fixed) of this code sequence is much higher than the bit
rate of the data signal: it produces a wideband signal, also called spread
signal.
At the receiver the same code sequence in phase should be used to

retrieve the original data signal.

WCDMA for UMTS
Code synchronization between the transmitter and the receiver is crucial for de-spreading the wideband
signal successfully.

Section 2 Pager 18
3.4 Code & Spreading factor
The code is applied on each bit of the user data.

Chip rate fixed at 3.84 Mchip/s
The Spreading Factor, called SF, is the length of this code.
Example: Data to transmit: 1 0 , SF=8.
A chip
1
Spread data
-1
Transmission
1
Code
-1
1
Coded data
-1
Received data, 1
without error -1
Reception
Code applied 1
-1
1
-1

WCDMA for UMTS
What is the spreading factor?

It is the number of chips per bit (=chip rate/bit rate).
The chip rate is linked with the CDMA carrier bandwidth and has a constant value of 3,84 Mcps.
It is quite easy to match the bit rate of the signal with the CDMA chip rate just by choosing the
adequate spreading factor.
The higher the spreading factor, the more redundancy you add in the signal and the lower the
probability of bit error is by transmitting the signal.
It is also traduced by the processing gain (see below).
Code synchronization?
It is difficult to acquire and to maintain the synchronization of the locally generated code signal
and the received signal.
Indeed synchronization has to be kept within a fraction of the chip time.

Section 2 Pager 19
3.5 Spreading factor & Data Rate
The chip rate is fixed, 3.84 Mchip/s. Small SF = High data rate
If the SF is divided by 2, the data rate is multiplied by 2 ! High SF = Small data rate
1
Spread data
-1
Transmission
1
Code
-1
1
Coded data
-1
Received data,
1
without error
-1
Reception
Code applied 1
-1
Received
data 1
-1

WCDMA for UMTS
The Spreading Factor available are 4, 8, 16, 32, 64, 128, 256 in uplink, plus 512 in downlink for signaling
at very low bit rate.

Section 2 Pager 20
3.6 Spreading factor & Error at reception
When an error occurs at the reception, the determination of the bit value is less trivial.
Signal sent on 1
the air -1
Signal received 1
with error -1
SF=8
Code
Decoded data
Zoom on the decoded

The
determination of
1
signal
the bit value is
based on the area
of the received 0
signal.
-1
Here is 6 area
units over 8
WCDMA for UMTS

Section 2 Pager 21
3.6 Spreading factor & Error at reception [cont.]
With a small SF, the signal is more sensitive to errors.

So to have the same error ratio you use more power
To keep in mind
Signal sent on 1
the air -1
If you need a high data rate
(video downloading), you
Signal received 1
with error -1 will use a small SF. You will
SF=4
have more errors on your
Code message. So if you want to
Decoded data keep the same error ratio,
you will use more power to
transmit your message
The
determination of
decoded signal
1
Zoom on the
the bit value is
based on the area
of the received 0
signal.
-1
Here is 2 area
units over 4
WCDMA for UMTS
Another way to understand this relation is with the redundancy.

If the SF is small, 4 for example, the useful bit, 0 or 1, is sent just 4 time. The data rate is high.
If the SF is higher, 64 for example, the useful bit is sent 64 time. The data rate is smaller.
So if an error occurs, it is more significant if the SF is 4 than if the SF is 64.

Section 2 Pager 22
3.7 Exercise: Orthogonal Code
Here, there is a received signal and two orthogonal codes

Could you apply these codes on the received signal and determinate which
code has been used to spread the signal? What could you conclude about the
orthogonality?
1
Received signal
-1
1
Code 1
Code 1
-1
Decoded signal 1
1 -1
Received signal 1
-1
Code 2
Code 2 1
-1
Decoded signal 1
2 -1

WCDMA for UMTS

Section 2 Pager 23
3.7 WCDMA, Power Density & Processing Gain
•RSSI: Received Signal Strength Indicator P

Total received wideband power over 5
RSSI or Io
MHz including thermal noise
•ISCP (No): Interference Signal Code

Power
Eb
Interference on the received signal
SIR
•RSCP (Ec): Received Signal Code Power ISCP or No
Unbiaised measurement on the received
signal on one channelization code PG
RSCP or Ec
• Eb : energy per useful bit
• PG : Processing Gain = Eb-Ec (in dB)

Power Gain after despreading. PG= 10 log (SF) f
Ws
Wss
At Node B reception level

WCDMA for UMTS
RSSI: This is the total received wideband (UTRA carrier RSSI) power over 5Mhz
including thermal noise. It is estimating the uplink interference at the Node B, and by difference with
the thermal noise, the rise due to traffic and external interference.

Section 2 Pager 24
3.7 WCDMA, Power Density & Processing Gain [cont.]
P
SIR: Signal Interference Ratio RSSI or Io
SF .RSCP
SIR =
No Eb
Depending on the service, more or less
errors are allowed. UTRAN computes SIR
the error ratio and then set the SIR
required for the service. ISCP or No
PG
What are the modifications on the RSCP or Ec
diagram if:
•The number of users increases ?
•The SF decreases ? f
Ws
Wss

WCDMA for UMTS

Section 2 Pager 25
4 Code Division Multiple Access

WCDMA for UMTS

Section 2 Pager 26
4.1 One-cell reuse
The area is divided into cells, but the entire

bandwidth is reused in each cell (frequency
reuse of one)
> Inter-cell interference
> Cell orthogonality is achieved by codes
The entire bandwidth is used by each user at the

same time
> Intra-cell interference
> User orthogonality is achieved by codes

WCDMA for UMTS
The rainbows cells mean that the whole bandwidth (5 MHz) is reused in each cell.
In GSM there is also intra-cell interference when there are 2 (or more) TRXs in the same cell. But it is a
small problem (as each TRX runs on a different frequency)
In CDMA intra-cell interference is an important problem.

Section 2 Pager 27
4.2 Multiple access
Spreading 1
Spreading1
Transmitter 1 Radio Channel
Spreading 2 Receiver
The receiver aims at receiving Transmitter 1 only.

Transmitter 2
All the users transmit on the same 5 MHz carrier at the same time and
interfere with each other.
At the receiver the users can be separated by means of (quasi-

)orthogonal codes.

WCDMA for UMTS
Quasi-orthogonal: it is not necessary to have primary colors at the receiver to separate the user. Red and
orange for example can also be distinguished.
Orthogonality between the codes is impossible to maintain after transfer over the radio interface (multi-
path on DL, UEs not synchronized on UL )

Section 2 Pager 28
4.2 Multiple access [cont.]
Spreading 1
Spreading1
Transmitter 1 Radio Channel
Spreading 2 Receiver
The receiver aims at receiving Transmitter 1 only.

Transmitter 2
If a user transmits with a very high power, it will be impossible for the
receiver to decode the wanted signal (despite use of quasi-orthogonal
codes)
CDMA is unstable by nature and requires accurate power control.

WCDMA for UMTS
CDMA is instable by nature:
one user may jam a whole cell by transmitting with too high power
need for accurate and fast power control
too many users in one cell would have the same effect
need for congestion control
A CDMA resource has 2 dimensions: the codes and the power. Obviously the power is the limiting factor ;
the better we can control the power usage, the more capacity (users) we can allocate.

Section 2 Pager 29
4.3 Spreading: Channelization and Scrambling
cch1
air
interface
Modulator
cch 2 cscrambling
cch 3
The channelization code (or spreading code) is signal-specific: the code

length is chosen according to the bit rate of the signal.
The scrambling code is equipment-specific.

WCDMA for UMTS
Spreading consists of two steps:

The channelization code (also called spreading code) transforms every data symbol into a number
of chips, thus increasing the bandwidth of the signal. The narrowband signal is spread into a
wideband signal with a chip rate of 3.84 Mchips/s.
The system must choose the adequate spreading factor to match the bit rate of the
narrowband signal.
The spreading factor is directly linked with the length of the channelization code.
The scrambling code does not affect the signal bandwidth: it is only a chip-by-chip operation.
The scrambling code is cell-specific on the downlink and terminal-specific on the uplink.

Section 2 Pager 30
4.4 Channelization Codes (Spreading Codes)
C ch,4,0 =(1,1,1,1)
C ch,2,0 = (1,1)
C = (1,1,-1,-1)
ch,4,1 The code tree is shared by several
C ch,1,0 = (1) users (usually one code tree per
C ch,4,2 = (1,-1,1,-1) cell)
C ch,2,1 = (1,-1)
C ch,4,3 = (1,-1,-1,1)
SF = 1 SF = 2 SF = 4 SF = 8
The channelization codes are OVSF (Orthogonal Variable Spreading Factor)

codes:
• their length is equal to the spreading factor of the signal: they can
match variable bit rates on a frame-by-frame basis.
• orthogonality enables to separate physical channels:
UL: separation of physical channels from the same terminal
DL: separation of physical channels to different users within one cell

WCDMA for UMTS
What is a channelization code?

OVSF (Orthogonal Variable Spreading Factor)
Length: 4-256 chips according to the spreading factor
(in downlink also 512 chips is possible to match very low bit rate)
Number of codes:
The channelization codes can be defined in a code tree, which is shared by several users.
If one code is used by a physical channel, the codes of underlying branches may not be used.
The number of codes is consequently variable: the minimum is 4 codes of length 4, the maximum
is 256 codes of length 256.
The channelization code (and consequently the spreading factor) may change on a frame-by-
frame basis
How is Code Allocation managed?

The codes within each cell are managed by the RNC.
No need to coordinate code tree resource between different base stations or terminals.
Usually one code tree per cell. If two code trees are used, it is necessary to use the secondary
scrambling code.

Section 2 Pager 31
4.5 Scrambling codes
The scrambling codes provide separation between equipment:

• UL: separation of terminals
No need for code planning (millions of codes!)
There are 224 long and 224 short scrambling codes in uplink
• DL: separation of cells

Need for code planning between cells (but trivial task)
There are only long scrambling codes in downlink
(512 to limit the code identification during cell search procedure)
The long scrambling codes are truncated to the 10 ms frame length.
Only one DL scrambling code should be used within a cell.

Another scrambling code may be introduced in one cell if necessary
(example : shortage of channelization code), but orthogonality between
users will be degraded.

WCDMA for UMTS
In fact, there are two types of scrambling codes:

Long codes:
Gold codes constructed from a position wise modulo 2 sum of 38400 chip segments of two binary
sequences (generated by means of 2 generators polynomials of degree 25)
used with Rake Receiver : the PRACH is constructed from the long scrambling sequences. There
are 8192 PRACH preamble scrambling codes in total, divided into 512 groups of 16 each.
Short codes:
Length : 256 chips
used with advanced multi-user detector
likely to be used later
Refer to Technical Specification 3GPP TS 25.213

Section 2 Pager 32
5 Soft Handover

WCDMA for UMTS

Section 2 Pager 33
5 Soft Handover
5.1 Introduction
Principle: As the UEs are separated by codes, they send and receive data at the
same time and on the same frequency and one frequency is used in a set of adjacent
cells, the soft handover is possible.
A UE is in case of Soft Handover when it is linked to several cells at the same time.
So , in downlink, the UE receives several time the same data and combine them to
increase the quality. In Uplink, a Node B can receive the same message from several
cells and combines them to increase the quality.
Interest: As the quality of the signal is increased after

the reception, it is possible to use less power. That
allows to save the interference level. If this
interference level is too high, it is not possible to
decode the data and the call is drop.
Soft Handover doesn’t exist in GSM, it is not possible because there are
different frequencies in a set of adjacent cells.

WCDMA for UMTS

Section 2 Pager 34
5 Soft Handover
5.2 Scenarios: Softer Handover
Core Network
Iu Iu
Serving RNC Iur
Iubs Iubs

WCDMA for UMTS
Softer HO : the cells with which the mobile is in communication belong to the same Node B

Section 2 Pager 35
5 Soft Handover
5.3 Scenarios: Soft Handover intra RNC
Core Network
Iu Iu
Serving RNC Iur
Iubs Iubs

WCDMA for UMTS
Soft HO intra RNC : the cells with which the mobile is in communication belong to different Node Bs and
same RNC

Section 2 Pager 36
5 Soft Handover
5.4 Scenarios: Soft Handover inter RNC
Core Network
Iu Iu
Serving RNC Iur Drift RNC
Iubs Iubs

WCDMA for UMTS
Soft HO inter RNC : the cells with which the mobile is in communication belong to different Node Bs and
different RNC
Serving RNC (SRNC1): on UL it collects information from the Drift RNC and from its own Node-B and
performs selection of the signal on a best frame quality basis. On DL it duplicates
Iu-information to Drift RNC and to its own Node-B and recombination of the signal is performed
by the UE. There may be only one Serving RNC per UE.
Drift RNC (DRNC2): it performs the routing of information from/to the Serving RNC.
There may be up to 4 Drift RNC(s) per UE.

Section 2 Pager 37
5 Soft Handover
5.5 Scenarios: SRNC Relocation
Core Network
Iu Iu
Serving RNC Iur Drift RNC

Serving RNC
Iubs Iubs

WCDMA for UMTS
SRNC Relocation : the Drift RNC becomes a serving RNC. Se we gain intransmission (no need for Iur for
the communication) and delay

Section 2 Pager 38
5 Soft Handover
5.6 Soft Handover & Code Management
In Downlink,
Core Network • Scrambling Code
One DL SC per Cell
• Channelization Code
Iu
One DL CC per radio link to avoid having the
same code sequence on 2 radio links
Serving RNC
In Uplink,
Iubs • Scrambling Code
UL CC user
UL SC eq One UL SC per UE
• Channelization Code
DL SC cellA DL SC cellB One UL CC per service (per physical
DL CC1 user 1 DL CC2 user 1 channel).
Conclusion:
The UE sends one signal which can be
received by several cells.
Cell A Cell B The UE receives several signals

WCDMA for UMTS

Section 2 Pager 39
5 Soft Handover
5.7 Cost & Benefit
Why do we need soft HO?

Imagine that a UE penetrates from one cell deeply into an adjacent cell:
it may cause near-far effect
hard HO is not a good solution, due to the hysteresis mechanism
Better spatial repartition of the power, so lower interference level
Additional resources due to soft HO:

- Additional rake receiver in Node-B
- Additional Rake Fingers in UE
- Additional transmission links between Node-Bs and RNCs
Soft HO provides Diversity (also called Macro-Diversity), but requires

more network resource.

WCDMA for UMTS

Section 2 Pager 40
5 Soft Handover
5.7 Cost & Benefit [cont.]
Soft Handover execution:

Soft Handover is executed by means of the following procedures
Radio Link Addition (FDD soft-add);
Radio Link Removal (FDD soft-drop);
Combined Radio Link Addition and Removal.
The cell to be added to the active set needs to have information forwarded
by the RNC:
Connection parameters (coding scheme, layer 2 information, …)
UE ID and uplink scrambling code,
Timing information from UE
The UE needs to get the following information
Channelization & scrambling codes to be used
Relative timing information (Timing offset based on CPICH synchro)

WCDMA for UMTS

Section 2 Pager 41
6 Rake Receiver

WCDMA for UMTS

Section 2 Pager 42
6 Rake Receiver
6.1 Rake Receiver principle
In a CDMA system there is a single carrier which contains all user signals.
Decoding of all these signals by one receiver is only a question of signal

processing capacity.
A Rake receiver is capable to decode several signals simultaneously in

the so called “fingers” and to combine them in order to improve the
quality of the signal or to get several services at the same time.
A Rake receiver is implemented in mobile phones and in base stations.
A Rake receiver can provide:

- multi-service (via handling of multiple physical channels that are
carrying the services)
- soft handover
- path diversity

WCDMA for UMTS
“A single carrier”: in fact each operator may use several carriers of 5MHz each (2 in Germany, 3 in
France)
The rake receiver can only be used with signals on the same carrier.

Section 2 Pager 43
6 Rake Receiver
6.1 Rake Receiver principle [cont.]
Delay Adjustment
Multi-code
signal
1st
Finger Delay 1 Data 1
Code Sequence 1
2nd
Finger Delay 2
Code Sequence 2
Data 2
3rd
Finger Delay 3
Code Sequence 2 or 3
The components of the multi-code signal are demodulated in parallel each

in one “finger” of the Rake Receiver.
The outputs of the fingers:

• can provide independent data signals
• can be combined to provide a better data signal(s)

WCDMA for UMTS
Rake fingers are allocated to the peaks at which significant energy arrives. Update rate: tens of ms
Each finger tracks the fast-changing phase and amplitude values due to fast fading and removes them
Rake Receiver resides in both UE and Node-B.
The numbers of fingers for a Rake Receiver is implementation dependant.

Section 2 Pager 44
6 Rake Receiver
6.2 Rake Receiver and Multi-Service
Spreading 1 Despreading 1
Radio Channel
Spreading 2
Despreading 2
Transmitter Multimedia receiver
As a first approach, we can say:

One service, one code! (*)
>> Which codes make it possible to

separate the two signals at the
receiver?
WCDMA for UMTS
* We will see later that it is also possible to multiplex several services on the same code!
Indeed on a dedicated physical channel (which is identified by its spreading code) a user can multiplex
several services as long as the total bit rate of the services does not exceed the bit rate of the physical
channel.
See subchapter 4 UTRAN/ Physical Layer (Transport Channel Multiplexing)

Section 2 Pager 45
6 Rake Receiver
6.3 Rake Receiver and soft handover
Spreading 1
Despreading 1&2
Base station 1 Radio Channel
Spreading 2 Mobile phone
Base Station 2 >> Which codes make it possible to

separate the two signals at the
receiver?
Soft handover is possible, because the two mobile stations use the same
frequency band. The mobile phone need only one transmission chain to
decode both simultaneously.
WCDMA for UMTS

Section 2 Pager 46
6 Rake Receiver
6.4 Rake Receiver and Path Diversity
Natural obstacles (buildings, hills…) cause reflections, diffractions and

scattering and consequently multipath propagation.
The delay dispersion depends on the environment and is typically:
• 1 µs (300 m) in urban areas

• 20 µs (6000 m) in hilly areas
The delay dispersion should be compared with the chip duration 0,26 µs (78 m)
of the CDMA system.
If the delay dispersion is greater than the chip duration, the multipath
components of the signal can be separated by a Rake Receiver.
In this case, CDMA can take advantage of multipath propagation.

WCDMA for UMTS
What is multipath propagation?

The signal travels from transmitter to receiver over different paths, due to reflections,
diffractions or scattering. Consequently the same signal arrives at the receiver with a little
delay.
The chip rate can be considered as the resolution of the CDMA system. It is linked with the 5 MHz
carrier.

Section 2 Pager 47
6 Rake Receiver
6.4 Rake Receiver and Path Diversity [cont.]
Direct path
Reflected path
Dispersion <Chip duration
>> Which codes make it
The Rake Receiver cannot provide path diversity. possible to separate the two
signals at the receiver?
Direct path
Reflected path
Dispersion > Chip duration
The Rake Receiver can provide path diversity to improve the quality of the signal.

WCDMA for UMTS
Multi-path propagation usually reduces the quality of the signal.
But in most cases a Rake Receiver can take advantage of multi-path to improve the quality of the signal.
Indeed the dispersion is often greater than the chip duration.
Note: with IS-95 (cdmaOne), the carrier bandwidth is about 1 MHz and the chip duration is consequently
longer: 1 µs (300 m). Multi-path components can not be separated in urban areas with IS-95.

Section 2 Pager 48
7 Power Control

WCDMA for UMTS

Section 2 Pager 49
7 Power Control
7.1 Why ?
Main Problem : If the interference level is to high, it is not possible to decode the signal.
P
Serving RNC
Eb
SIR
Iub
SIR
ISCP or No
PG
RSCP or Ec
f

WCDMA for UMTS
In UTRA/FDD, the power control is a key functionality : the users using

simultaneously the same frequency band interfere each other.
The transmit power must be dynamically adapted in order to
Enable to reach the quality of service
Compensate fading occurrences
Avoid interfering other users (and thus decreasing the system capacity)
Two main power control algorithms can be distinguished:
Open-loop power control (UL only)
Closed loop power control (UL/DL)

Section 2 Pager 50
7 Power Control
7.2 Different kinds of Power Control
Physical channels:
Channel power fixed and set by the

• Not associated with transport channels operator
(Physical signaling)
• Associated with transport channels

• Dedicated channels Closed & Open Loop power control
• Common channels
Channel power fixed and set by the
operator
Open Loop Power Control

WCDMA for UMTS

Section 2 Pager 51
7 Power Control
7.3 Open Loop Power Control
The Open Loop Power Control is used to set the initial transmit power when:
• The UE requests a RRC Connection,
Based on CPICH measurements
• The UE sends the first dedicated radio frame,
• The Node B sends the first dedicated radio frame. Based on UE measurement reports
Measurement reports
CPICH
• Initial Access
•First dedicated Radio Frame •First dedicated Radio Frame

WCDMA for UMTS
How is Power Control performed ?

Open loop power control:
it consists for the mobile station of making a rough estimate of path loss by means of a
DL beacon signal and adding the interference level of the Node-B and a constant value.
It’s far too inaccurate and only used to provide a coarse initial power setting of the mobile
station at the beginning of a connection

Section 2 Pager 52
7 Power Control
7.4 Closed Loop Power Control: Principle
Closed Loop Power Control
SIR target • SIR Estimation

• Comparison
”Power down” *** between SIRest and
SIRtarget ***
*** ”Power down”
Iub •Generation of a TCP
”Power up” *** command: increase
or decrease
RNC *** ”Power ...”
Error ... On each Time slot !
measurements ***
(1500 Hz)
Outer Closed Loop Inner Closed Loop
The Node-B controls the power of the UE (and vice versa) by performing a SIR estimation (inner loop) and
by generating TPC command for each time slot of the radio frame.
The RNC controls parameters of the SIR estimation (outer loop) and set the initial SIR target, defined by
the operator and modify it according to the error measurement reports.

WCDMA for UMTS
Inner Loop (Fast Loop Power Control)

In UL, the serving cells should estimate signal-to-interference ratio SIRest
of the received uplink DPCH. The serving cells should then generate TPC commands
and transmit the commands once per slot according to the following rule: if SIRest > SIRtarget
then the TPC command to transmit is "0" , while if SIRest < SIRtarget then the TPC
command to transmit is "1".
Upon reception of one or more TPC commands in a slot, the UE shall derive a single
TPC command, TPC_cmd, for each slot, combining multiple TPC commands if more
than one is received in a slot. TPC_cmd values = +1(power up), -1 (power down), 0
The step size DTPC is under the control of the UTRAN (value = 1 dB or 2 dB)
UE shall adjust the transmit power of the uplink DPCCH with a step of DDPCCH (in dB)
which is given by DDPCCH = DTPC × TPC_cmd.
The command rate of 1500Hz is faster than any significant change of path loss.
Outer Loop
The RNC checks the quality of the signal using for example a CRC-based approach
(Cyclic Redundancy Check) and uses this result to adjust SIR target for the inner loop.
The big issue is to meet constantly the required quality: no worse and also no better,
because it would be a waste of capacity.
The required quality may change with the multi-path profile (related to the environment)
and with the UE speed.
The outer loop management is handled by the CRNC because a soft HO may be performed.
Frequency of the outer loop: 10-100 Hz typically
Note: in GSM only slow power control is employed (about 2 Hz)
Section 2 Pager 53
7 Power Control
7.4 Closed Loop Power Control: Power Density
SIR target
Assuming a user using a service. ”Power up”

Iub
It is initial SIR target is 3dB. ”Power ...”
The error ratio required is 0.01 . ...

RNC
Error
measurements
Several error ratio reports are between 0.002
and 0.007
P
How do the SIR target evolve ?

Eb
What is the impact on the user or on the
system if the estimated SIR is too high ? Too SIRTarget SIRest
small ? ISCP or No
RSCP or Ec
f

WCDMA for UMTS

Section 2 Pager 54
7 Power Control
7.5 UL Closed Loop PC, in case of Soft Handover
What is the behavior of the UE in UL in case of

soft handover ?
Iub
• The UE takes in to account all the command
according to the 3GPP
1 2
P(t)=P(t-1) + F(TPC1(t) + TPC2(t))
The function F(TPC(t)) is implemented by the UE

manufacturer. Power down !!! Power up !!!
TPC=-1 TPC=1
F(TPC(t))=min(TCP1(t), …, TPCi(t))
With i= number of involved Node B
???

WCDMA for UMTS

Section 2 Pager 55
7 Power Control
7.5 DL Closed Loop PC, in case of Soft Handover
What is the behaviour of the Node B involed

in the call in DL in case of soft handover ?
• The UE sends the same command for all
the Node B involved.
Iub
Node Bs must transmit data with the same
power for a user
• Due to reception errors their power can
shift themselves Power Power
up up
A mechanism, the DL Power Balancing,
allows to readjust the transmission power of
the Node B. Power up !!!
TPC=1
The SRNC selects the best radio link, and
readjust, step by step, the transmission
power.
P(t) = P(t-1) + Ptpc(t) + Pbal(t)

WCDMA for UMTS

Section 2 Pager 56
8 Capacity, Coverage & Quality

WCDMA for UMTS

Section 2 Pager 57
8 Coverage, Capacity & Quality
8.1 Links between Coverage, Capacity and Quality
Example: Increase the quality in UL

RNC
How to do ? P
• Decrease the error ratio at the Node B level
SIR
• So increase the SIR at the Node B level SIR
Iub
• So the UEs use more power

Node B
f
Impacts !
• Increase the UL Interference level
• So decrease of the cell size
• And decrease the capacity of the cell.

WCDMA for UMTS

Section 2 Pager 58
8.2 Improvement Ways
•AMR speech Codec

it enables to switch to a lower bit rate if the mobile is moving out of the
cell coverage area: it is a trade-off between quality and coverage.
•Multipath diversity
it consists of combining the different paths of a signal (due to reflections,
diffractions or scattering) by using a Rake Receiver.
Multipath diversity is very efficient with W-CDMA.
•Soft(er) handover
the transmission from the mobile is received by two or more base stations.
•Receive antenna diversity
the base station collects the signal on two uncorrelated branches. It can be
obtained by space or polarization diversity.
•Base stations algorithms
e.g. accuracy of SIR estimation in power control process

WCDMA for UMTS
The AMR (Adaptive Multi-rate) speech codec:

offers 8 AMR modes between 4,75 kbps and 12,2 kbps
is capable of switching its bit rate every 20 ms upon command of the RNC
is located in the UE and in the transcoder (which is located in the CN)

Section 2 Pager 59
8.3 Typical Values
Quality: The quality is measured with the Block Error Ratio (BLER). Here some example according
different services.
AMR CS64 PS64 PS128 PS384 DCCH
Target 0.001 0.01 0.001 0.01 0.1 0.01 0.01 0.01 0.01
BLER
Coverage:
• Dense Urban Cell: about 300 meters
• SubUrban Cell: about 1 km
• Rural Cell: 3 km
Capacity:
The main limitation is the interference level due to the WCDMA technology.
But the system is also limited by capacity processing of the Node B and the RNC, by the codes, and by
the transmission capacity.

WCDMA for UMTS
The capacity depends also on:

the radio environment (rural, suburban, indoor)
the terminal speeds
the distribution of the terminals
the load of the cell: trade-off capacity/coverage (breathing cells)
Due to all these parameters, it is harder than in GSM to give a typical value of the capacity of a cell.

Section 2 Pager 60
Evaluation
Objective: To be able to define a Radio

Resource in 3G


WCDMA for UMTS

Section 2 Pager 61
End of Module

WCDMA for UMTS

Section 2 Pager 62
3
Section 3
UTRAN Scenario
9300 WCDMA

Section 3 Pager 1
Blank Page

UTRAN Scenario
Document History

Section 3 Pager 2
Objectives
To be able to build the map of the radio channels

(logical, transport and physical channels) from a
white paper.

UTRAN Scenario

Section 3 Pager 3
Objectives [cont.]

UTRAN Scenario

Section 3 Pager 4
Table of Contents
Page
Introduction to UTRAN Scenarios Mobility Management in Connected
Introductionto UTRAN Scenarios
1 Introduction Mode 7
1.1 Introduction
Radio Channels Mapping 8
Soft HO: Active & Monitoring Set
2 Radio Channels Mapping 11
Downlink Soft HO: Events
2.1 Downlink 12
Uplink
2.2 Uplink Compressed Mode 13
Service
3 Service RequestRequest Hard HO: Events on14other FDD
3.1 System Information
System Information Collection Collection Frequencies 15
3.1.1 P-SCH & S-SCH Hard HO: Events on16other GSM
RRC Connection
3.1.2 CPICH 17
IMSI Attachment
3.1.3 System Information & Location Update
Broadcast Frequencies 18
Paging 3.1.4 Procedure Exercises 20
RAB3.1.5 Radio Channel Mapping: P-CCPCH
Establishment 21
Scenario Description
3.1.6 Cell Selection Principle Downlink 22
Admission
3.2 RRC Connection
Control 23
Radio 3.2.1Bearer
UE Status Establishment Uplink 24
3.2.2 Procedure: RRC Connection Establishment 27
3.2.3 Procedure: RRC Connection: RRC Connection Release 28
3.2.4 How to contact UTRAN: the PRACH 29
3.3 IMSI Attachment & Location Update 31
3.3.1 Principles 32
3.3.2 Procedure: Direct Transfer 33
3.4 Paging 34
3.4.1 Procedure 1: UE in Cell-DCH or Cell-FACH 35
3.4.2 Procedure 2: UE in Idle Mode 36
3 3.4.3
5 Paging: PICH & PCH Radio Channels All Rights Reserved © Alcatel-Lucent 2010
37
UTRAN Scenario
4 RAB
9300 WCDMA Establishment
TMO18246 9300 WCDMA UAO7 R99 Radio Principles 38
4.1 Admission Control 39
4.2 Radio Bearer Establishment 41
4.2.1 Signaling: RAB Establishment 42
4.2.2 Signaling: Radio Link Setup 43
4.2.3 Radio Bearer Mapping 44
4.2.4 Physical Layer Processing 45
4.2.5 Radio Channels 46
4.2.6 Radio Channels: Data Processing 47
4.2.7 Radio Channels: Transport Channel Multiplexing 48
4.2.8 Radio Channels: DPDCH/DPCCH Channels 49
5 Mobility Management in Connected Mode 50
5.1 Soft HO: Active & Monitoring Set 51
5.2 Soft HO: Events 52
5.3 Compressed Mode 53
5.4 Hard HO: Events on other FDD Frequencies 54
5.5 Hard HO: Events on other GSM Frequencies 55
6 Exercises 56
6.1 Scenario Description 57
6.2 Downlink 58
6.3 Uplink 59

Section 3 Pager 5

UTRAN Scenario This page is left blank intentionally

Section 3 Pager 6
1 Introduction to UTRAN Scenarios

UTRAN Scenario

Section 3 Pager 7
1.1 Introduction
CN
Collection of System Information
3. IMSI
RRC Connection
Attachment
IMSI Attachment
Serving RNC Paging
Iub
The UE is switched on !
How can it retrieve network
1. System parameters to request a service?
2. RRC
Information Connection
4. Paging

UTRAN Scenario
On the first part, we are going to see how a UE, after it is just switched on, can be able to request a
service and to answer to a paging message.
So the first step is to retrieve information about the system. Thank to this system information the UE is
able to attach its IMSI and to update its location to the Core Network.
After that the UE can monitor a channel to answer to a paging message or can request itself a service.

Section 3 Pager 8
1.1 Introduction [cont.]
CN
RAB
Admission Control
RAB Establishment
Serving RNC ?
Iub
The UE requests a service.

How and in which conditions are the
resources required setup ?

UTRAN Scenario
When a UE requests a service, the UTRAN must check if it has enough resources to establish new
dedicated channels.
There are after signaling between the UE, the Node B, the RNC and the Core Network to provide to the
UE the transfer of the data at the required QoS.
We will also how the data are mapped on the physical channels.

Section 3 Pager 9
1.1 Introduction [cont.]
CN
A new radio link is added

Hard Handover on another FDD carrier
Serving RNC Inter RAT Handover
Iub The UE uses a service and moves !

How UTRAN can provide the service
despite the mobility ?
BTS BSC

UTRAN Scenario
UTRAN must provide the transfer of the data at the requested QoS to a moving user. So different kinds of
handover have been defined.
The Soft Handover, the UE can be linked to several cells using the same fraquency.
The Hard Handover inter FDD carrier and the interRAT HandOver between the 3G and the 2G network if
the user loses the 3G coverage.

Section 3 Pager 10
2 Radio Channels Mapping

UTRAN Scenario

Section 3 Pager 11
2.1 Downlink
DTCH, DCCH MTCH MSCH, MCCH CCCH, CTCH PCCH BCCH
Logical Ch
Transport Ch
DCH1 DCH2 DSCH FACH PCH BCH
Not implemented
yet in Alactel-Lucent
CCTrCH Solution
Physical Ch
DPDCH
DPDCH and DPCCH + PDSCH S-CCPCH P-CCPCH
multiplexed by time DPCCH
Dedicated Common Physical Ch
Physical Ch
Not associated with

AICH PICH MICH CPICH P-SCH S-SCH
transport channels
MSCH, MCCH, MTCH map to FACH (only in DL)

UTRAN Scenario

Section 3 Pager 12
2.2 Uplink
DTCH, DCCH CCCH
Logical Ch.
Transport Ch.
DCH1 DCH2 RACH CPCH
CCTrCH
Physical Ch.
DPDCH and DPCCH DPDCH + PRACH PCPCH

multiplexed by
DPCCH
modulation
Dedicated Common
Physical Ch. Physical Ch.

UTRAN Scenario

Section 3 Pager 13
3 Service Request

UTRAN Scenario

Section 3 Pager 14
3 Service Request
3.1 System Information Collection
CN
Principles
•The UE synchronize itself at the
slot on the P-SCH
Serving RNC
• UE synchronize itself at the
frame level on the S-SCH and
Iub
retrieve a group of 8 Scrambling
codes.
•The UE test the 8 SC on the
CPICH to find the SC of the cell
???
•The UE decode the BCH channel
to read the system information
•The UE select the best cell

UTRAN Scenario
Just after the switch on, the UE can decode only the P-SCH and S-SCH if it is on a covered area

Section 3 Pager 15
3.1.1 P-SCH & S-SCH
Slot #0 Slot #1 Slot #14
P-SCH acp acp

… acp
S-SCH acs0 acs1 acs14

256 chips
P-CCPCH Radio Frame 10 ms
The SCH is time-multiplexed with the P-CCPCH (which carries the BCH) and consists of 2 sub-channels.
• The Primary SCH (P-SCH) made of always the slot on all the FDD Cells. The UE uses it to acquire the
slot synchronization to a cell.
•The Secondary SCH (S-SCH) contains a sequence of 15 codes which identifies the Code Group of the
Downlink Scrambling Code (DL SC) of the cell. The UE uses it to acquire the frame synchronization to a
cell and to identify the Code Group of the DL SC.

UTRAN Scenario
Cell Search Procedure (also called synchronization procedure)

3GPP TS 25.214 provides an informative description how it is typically done
Step 1: slot synchronization

In all the cell of any PLMN, the P-SCH is made of a unique & same primary code sequence of 256
chips repeated at each Time Slot Occurrence. This is typically done with a single matched filter (or
any similar device) to the primary synchronisation code which is common to all cells. The slot timing
of the cell can be obtained by detecting peaks in the matched filter output.
Step 2: frame synchronization and code-group identification

A S-SCH is made of 15 repetitions of a secondary code sequence of 256 chips (one per Time Slot)
transmitted in perfect synchronization with the P-SCH code sequences. The UTRAN uses 64 distinct
secondary synchronization code sequences (reused in distant cells of the UTRAN). This is done by
correlating the received signal with all possible secondary synchronisation code sequences, and
identifying the maximum correlation value. Since the cyclic shifts of the sequences are unique the
code group as well as the frame synchronisation is determined.
Each secondary code sequence corresponds to a unique group of 8 possible Primary Scrambling
codes
Step 3: (downlink) scrambling code identification

The UE determines the (primary) scrambling code used by the found cell through symbol-by-
symbol correlation over the CPICH (pilot) with all codes within the Code Group identified in
the step 2 (8 possibilities).
Afterwards the P-CCPCH can be detected and the system- and cell specific BCH information
can be read.

Section 3 Pager 16
3.1.2 CPICH
Slot #0 Slot #1 … Slot #14
SF=256 Tslot=2560
Pre-defined symbol sequence chips 20 bits
CPICH (Common Pilot CHannel)

•The pilot carries a pre-defined symbol sequence at a fixed rate.
•It is a reference:
• To aid the channel estimation at the terminal (time or phase reference)
• To perform handover measurements and cell selection/reselection (power reference)
• The UE tests the 8 DL SC of the Group Code. The DL SC which allows to retrieve the pre-define
sequence is the DL SC of the cell.

UTRAN Scenario
The CPICH has the following characteristic

The same channelization code is always used for the CPICH,
The CPICH is scrambled by the primary scrambling code,
There is one and only one CPICH per cell,
The CPICH is broadcast over the entire cell.

Section 3 Pager 17
3.1.3 System Information Broadcast
The broadcast system information:

• May come from CN, RNC or Node-B.
• Contains static parameters (Cell identity, supported PLMN types...) and dynamic
parameters (UL interference level...).
• Is arranged in System Information Blocks (SIB), which group together elements of
the same nature.
Some exemple:
•SIB1: Core Network Information
DL SC, Power Control info
•SIB3: Cell Selection, Access Restriction
LA, RA …
•SIB7: UL Interference
•SIB11: Measurement
CN
UL interference level

UTRAN Scenario
Example of SIB:
MIB: Master Info Block (structure & scheduling of SIBs)

SIB 1: NAS System Information + Timer
SIB 2: URA (not supported) +Timer
SIB 3: Cell Selection/Reselection and Access Restriction
SIB 5: Common channel Information (P-CCPCH, S-CCPCH, RACH) and AICH/PICH
power offset
SIB 7: UL Interference and PRACH parameter SIB 11:Measurements
SIB 18:PLMN Identity of neighboring cells

Section 3 Pager 18
3.1.3 System Information Broadcast [cont.]
The broadcast system information can be carried on BCH which is transmitted permanently over
the entire cell.
The broadcast system information is made of 128 periodic radio frame. So its period is 1280 ms.
There are a Master SIB or MIB and several SIB (System Information Block) organised by domain.
Thanks to this channel, the UE is able to retrieve information allowing the request of a
RRC connection like the Channelization code used on the uplink common channel
MIB SIB3 SIB11
Logical Ch. BCCH

…
Frame #0 Frame #1 Frame #2
SIB5 SIB7 MIB
Transport Ch. BCH … …
Frame #i-1 Frame #i Frame #i+1
SIB11 SIB5 SIB7

Physical Ch. P-CCPCH
…
Frame #125 Frame #126 Frame #127

UTRAN Scenario
Three parameters are used to set the position of each SIB on the cycle.
SIB_POS: it is the position of the SIB on the cycle (#0 for the MIB for instance)
SIB_REP: it is the repetition of the SIB on the cycle (the MIB is repeated several time on the cycle.
SIB_OFF: If one Radio Frame is not enough to send all the data for a SIB, the rest of the SIB can be send
on another radio frame. For example, 2 radio frame after the first one. It is the SIB_OFF.

Section 3 Pager 19
3.1.4 Procedure
UE Node-B RNC CN
System Information
Update Request
NBAP NBAP
Master/Segment Info
Block(s), BCCH
modification time
System Information
Update Response
NBAP NBAP
System Information (BCCH:BCH)
RRC RRC
Master/Segment Info Block(s)

RRC RRC
>> Why does RRC protocol
RRC
RRC terminate at Node-
Node-B for
BCH (not at RNC)?

UTRAN Scenario

Section 3 Pager 20
3.1.5 Radio Channel Mapping: P-CCPCH
256 chips
SCH Payload of 18 bits
Tslot=2560 chips
20 bits
Slot #0 Slot #1 Slot #i Slot #13 Slot #14
The Primary CCPCH carries the BCH, which provides system- and cell-
specific information (e.g set of uplink scrambling codes)
The P-CCPCH is a fixed rate 30 kbps DL physical channel, which provide a
timing reference for all physical channels (directly for DL, indirectly for
UL).
CCPCH is scrambled under the Primary Scrambling code.

UTRAN Scenario
The P-CCPCH is time multiplexed with the SCH which is transmitted during the first 256 chips.
P-CCPCH timing is identical to that of SCH and CPICH (see 3GPP 25.211).
The P-CCPCH contains no layer 1 information.
Even if the PCCPCH is not transmitted during the 256 first chips of each slot (SCH), the scrambling code is
aligned with the PCCPCH frame boundary, i.e the first complex chip of the PCCPCH frame is multiplied
with chip number zero of the scrambling code.
The Secondary CCPCH, which is used to carry FACH and PCH information, is scrambled under the Primary
scrambling code as well.

Section 3 Pager 21
3.1.6 Cell Selection Principle
Now, the UE can read the BCH of one cell.

CN
But this cell is not necessary the best because
the SCH has been chosen randomly.
The UE compares the cells to be camped on the
best one.
RNC
There are 2 criterion:
• QRxLev, from the CPICH RSCP, to estimate the
reception level.
Iub
• Qqual, from the CPICH Ec/No, to estimate the
quality of reception. It takes in account the
interference level.
???
When a UE is not connected, like here, and is
moving, it has to reselect regularly the best cell
for itself. To protect some cells, it is possible to
facilitate or not the selection of one cell.

UTRAN Scenario
Aim : find a suitable cell to be camped on

The Cell selection criterion is defined in 3GPP TS 25.304 as:
Squal>0 with Squal=Qqualmeas - Qqualmin
Srxlev>0 Srxlev= Qrxlevmeas – Qrxlevmin - Pcompensation
Parameters :
Qqualmeas: defines the quality of the cell
Measured CPICH Ec/N0
Qqualmin: defines the threshold for the quality of the cell
Configurable in each cell independently
Range: -24 dB to 0 dB (step 1 dB)
Qrxlevmeas : defines the cell Rx Level value
Measured CPICH RSCP
Qrxlevmin : defines the minimum required RX level of the cell
Configurable in each cell independently
Range: -115 dBm to -25 dBm
Pcompensation:
Parameter to take in account the UE capacity

Section 3 Pager 22
3 Service Request
3.2 RRC Connection
CN
Why?
The UE is switched on and has selected a cell.
The UE is in idle mode.
RNC •UTRAN doesn’t know anything about this UE.
•The UE has neither UTRAN identifier nor
Scrambling and Channelization code.
Iub The UE can’t exchange any data with UTRAN.
To be known by UTRAN and to use dedicated radio

resources, the UE has to be RRC connected.
After, the UE can attach its IMSI or update its
location to the Core Network and can request a
service
RRC Connected

UTRAN Scenario

Section 3 Pager 23
3.2 RRC Connection
3.2.1 UE Status
out of coverage RRC Connection Release

UE UE
UE
in idle mode in connected
detached
mode
Several sub-
status in the
connected
“just after switch on” process mode
RRC Connection Establishment
Including Cell search procedure
Just after the switch on, the UE has to attach its IMSI. Thanks to his procedure the Core Network
knows, the UE is on the network and where it is located at the Location or routing area level.
To attach its IMSI and update its location the UE has to be in connected mode, so it
has to request a RRC Connection

UTRAN Scenario
Just after switch on” process contains:

Cell selection (including cell search procedure)
PLMN selection
Attachment procedure (see “Appendix” for more details)
The UE must enter the connected mode to transmit signalling or traffic data to the network
What is the relationship with the states of the mobile phone in GSM?
The two GSM states, idle mode and connected mode, are similar to idle mode and cell_DCH state in
UMTS.
What is the relationship with the states of the mobile phone in GPRS?
There is no correspondence between GPRS states (idle, standby and ready) and UMTS states.
Indeed there is no notion of connection on GPRS.

Section 3 Pager 24
3.2 RRC Connection
3.2.1 UE Status [cont.]
Cell_DCH state UE in connected

Signalling and traffic data Cell DCH mode
dedicated to the UE (mapped UE
on DCCH and DTCH in idle Cell PCH
respectively) are carried on
DCH transport channel mode Cell FACH
URA PCH
Cell_FACH state
Signalling and traffic data
dedicated to the UE (mapped Cell_DCH ⇒Cell_FACH
on DCCH and DTCH No traffic UL/DL at expiry of timer
respectively) are carried on
RACH (uplink) and FACH
(downlink) transport channels Cell_FACH ⇒Cell_DCH
Traffic volume UL/DL too large

UTRAN Scenario
The initial state of the UE is determined by the DCCH established during RRC connection establishment:
if the DCCH is mapped on a DCH, the UE is in cell_DCH state
if the DCCH is mapped on RACH/FACH, the UE is in cell_FACH state
The UE can move from one state to another during the time of the RRC connection.
Transitions between states are:
based on traffic volume measurements and network load
always triggered by UTRAN signalling
Note: in cell_DCH state, the DSCH transport channel can also be used.

Section 3 Pager 25
3.2 RRC Connection
3.2.1 UE Status [cont.]
Cell_PCH state
No transmission of signalling and
traffic data dedicated to the UE UE in connected
Cell DCH mode
(no DCCH and no DTCH)
UE
But the RRC connection is still
in idle Cell PCH
active (UTRAN keeps RNTI for UE)
and UE location at a cell level. mode Cell FACH
- a DCCH (and possibly a DTCH) can
URA PCH
be reestablished very quickly (this
procedure is initiated by sending a
paging signal PCH) Cell_FACH ⇒Cell_PCH
No traffic UL/DL at expiry of timer 2
URA_PCH state Cell_PCH ⇒ Cell_FACH ⇒URA_PCH
Very similar to cell_PCH state Too many cell reselections
UTRAN keeps the location of the UE at

Cell/URA_PCH ⇒ Cell_FACH
the URA level (set of UMTS cells)
Incoming DL or UL traffic

UTRAN Scenario
URA: UTRAN Registration Area (a small set of cells)
Cell_PCH and URA_PCH states are needed for non real time services to optimise usage of codes and
battery consumption. It would not be efficient to allocate permanently a DCH which would be used a
very low percentage of time (Web application for example)
What is the difference between idle mode, Cell_PCH and URA_PCH states?
In idle mode the location of the UE is not known by the UTRAN, but only by the CN at a Location Area
(LA) or Routing Area (RA) level (LA and RA and sets of cells larger than URA.
The paging message PCH must hence be sent in a LA or in a RA when the UE is in idle mode, whereas it
only needs to be sent in a cell in Cell_PCH state or in an URA when the UE is in URA_PCH state (hence
the paging procedure is much faster).

Section 3 Pager 26
3.2 RRC Connection
3.2.2 Procedure: RRC Connection Establishment
UE Node-B RNC
1. RRC Connection Request (CCCH:RACH)

RRC RRC
Initial UE identity, Establishment cause, Initial UE capability
2. Allocate RNTI, Select Level

1 and Level 2 parameters
(e.g. TFCS, scrambling code)
3. Radio Link Establishment
4. RRC Connection Setup (CCCH:FACH)

RRC RRC
Initial UE identity, RNTI, capability update requirement, TFS, TFCS, frequency, UL
scrambling code, power control info
5. RRC Connection Setup Complete (DCCH:RACH or DCH)

RRC RRC
Integrity information, ciphering information
>> Can the UE send user information (e.g voice call) after completing
completing this stage?

UTRAN Scenario
1. UE initiates set-up of an RRC connection

Initial UE identity: e.g TMSI
Establishment cause: e.g traffic class
2. RNC decides which transport channel to setup (RACH/FACH or DCH) and allocates
RNTI (Radio Network Temporary Identity) and radio resources (e.g TFS, TFCS, scrambling codes) for
this RRC connection.
3. A new radio link must be setup.
This is done via a signalling procedure between RNC and Node-B which is managed by NBAP protocol
(see “Procedure D” for more detail).
4. Logical, transport and physical channel configuration are sent to the UE.
5. RRC Connection Setup Complete message is sent:
on RACH in case of RRC connection on RACH/FACH (cell_FACH state)
on DCH in case of RRC connection on DCH (cell_DCH state)

Section 3 Pager 27
3.2 RRC Connection
3.2.3 Procedure: RRC Connection: RRC Connection Release
UE Node-B Node-B DRNC SRNC CN

(DRNC) (SRNC) 1. Iu Release
Command
RANAP RANAP
Cause
2. Iu Release
Complete
RANAP RANAP
-
3. ALCAP Iu Bearer Release
4. RRC Connection Release (DCCH:DCH )

RRC RRC
Cause
5. RRC Connection Release Complete (DCCH:DCH )

RRC RRC
-
6. Radio Link Deletion

UTRAN Scenario
In this example, the UE is in macro-diversity on two Node-Bs from two different RNCs. Therefore the UE
could only be in cell_DCH state (soft HO is only possible on DCH)
1. The CN initiates the release of RRC connection

2. -
3. SRNC initiates release of Iu Bearer using ALCAP protocol
4. -
5. -
6. SRNC initiates release of radio link (for Node-B of SRNC) using NBAP protocol
7. SRNC requires release of radio link (for Node-B of DRNC) to DRNC using RNSAP protocol
8. DRNC initiates release of radio link (for Node-B of DRNC) using NBAP protocol

Section 3 Pager 28
3.2 RRC Connection
3.2.4 How to contact UTRAN: the PRACH
For the initial access, the UE has to use a common

RNC uplink channel called the PRACH
Every UE use this channel to request a connection. If
2 UEs request on the time there is collision, and
Iub UTRAN receives nothing.
To manage this problem, the UE sends a first

2. Yes Response on the AICH
message called preamble until it receives a response
!
on a downlink channel called AICH.
HELLO!
1. I need
Hello ! a connection After the response on the AICH, the UE sends its
…
message (the request) on the PRACH.
PRACH Request : Pre-amble
Preamble on the
PRACH
3. Here is my request
Preamble on the
PRACH : Message part
PRACH

UTRAN Scenario
PRACH= Physical Random Access Channel

AICH= Acquisition Indicator channel

Section 3 Pager 29
3.2 RRC Connection
3.2.4 How to contact UTRAN: the PRACH [cont.]
The first preamble is sent with the power P.

The UE resends a preamble until it receives a response on the AICH.
At each time, it increases the power of the preamble by the Power Offset parameter (PO)
UTRAN can’t receive its preamble if:
• The power is not enough high
• There is a collision with another user.
In the message part, there is the RRC connection request.
PO DPp,m
Prea
PO Prea mble
mble Message part
P
PRACH channel
Reception of
AICH

UTRAN Scenario

Section 3 Pager 30
3 Service Request
3.3 IMSI Attachment & Location Update
Initial Attachment
MSC/VLR SGSN
HLR
MSC/VLR SGSN
The UE has selected a cell.

RNC It had to declared its identity and its
location (LA & RA) to the Core Network.
Iub So, it requests a RRC connection to send to

the Core Network information about its
situation.
The parameters are mainly the LA, the RA
and its IMSI

UTRAN Scenario
In the selected PLMN, the UE:

selects the best cell according to radio criteria I
initiates attachment procedure on the selected cell
During the attachment procedure (called IMSI attach for CS domain, GPRS attach for PS domain), the UE
indicates its presence to the PLMN for the purpose of using services:
authentication procedure
storage of subscriber data from the HLR in the VLR (or in the SGSN for PS domain)
allocation of the TMSI (P-TMSI for PS domain)
The result of the procedure is notified to the UE:
if successful, the UE can access services
if it fails, the UE can only perform emergency calls
LA=Location Area= Set of cells for the CS CN

RA= Routinf Area= Set of cells for the PS CN

Section 3 Pager 31
3.3.1 Principles
Location Area MSC/VLR SGSN Routing Area

(LA) (RA)
HLR
MSC/VLR SGSN
When camping on a cell, the terminal must register its LA and/or its RA.
When the terminal moves across the network, it must update its LA (RA) which is stored in VLR
(SGSN) in the Core Network.
LA (RA) Update is performed periodically or when entering a new LA (RA).

UTRAN Scenario
LA and RA are managed on an independent way, but a RA must always be included in one LA (and not be
divided into several different LAs).
LA update is performed by the NAS layer MM (Mobility Management) located in UE and in MSC.
RA update is performed by NAS layer GMM (GPRS Mobility Management) located in UE and in SGSN.
In the Core Network, the location information is stored on databases:

HLR (Home Location Register)
It stores the master copy of user’s service profile, which consists of information on allowed
services, forbidden roaming areas,… and which is created when a new user subscribes to the
system.
The HLR also stores the serving system (MSC/VLR and/or SGSN) where the terminal is located.
VLR (Visitor Location Register)

It serves the terminal in its current location for CS services and holds a copy of the visiting
user’s service profile.
It stores the Location Area (LA) where the terminal is located.
SGSN (Serving GPRS Support Node)

It serves the terminal in its current location for PS services and holds a copy of the visiting
user’s service profile.
It stores Routing Area (RA) where the terminal is located.

Section 3 Pager 32
3.3.2 Procedure: Direct Transfer
UE Node-B SRNC CN
1’. Uplink Direct Transfer

(DCCH:RACH or DCH)
RRC RRC
CN node indicator, NAS message
2’. Direct Transfer

RANAP RANAP
CN Domain Indicator,
NAS PDU
1. Direct Transfer
RANAP RANAP
CN Domain Indicator,
2. Downlink Direct Transfer NAS PDU
(DCCH:FACH or DCH)
RRC RRC
NAS message
Use mainly for the IMSI attachment, location update and the authentification between the UE and
the Core Network

UTRAN Scenario
UE must be in cell_FACH or in cell_DCH states.

Section 3 Pager 33
3 Service Request
3.4 Paging
Principle
Core Network
MSC/VLR HLR MSC/VLR Paging message

with the IMSI of the
called UE
Called number
Location Area
RNC RNC RNC
Iub Iub Iub
Some one is calling

me, I request a RRC
connection

UTRAN Scenario
If the UE is in idle mode. UTRAN doesn’t know them and can just forward the paging message coming
from the Core Network to all the cell belonging to the Location ou Routing Area.
The UE monitors periodically a channel to check if it is paged or not.
If the UE is connected the Core Network knows the Serving RNC of the UE and sends the paging message
just to this RNC.
The RNC knows the UE uses the dedicated or common channel to send the paging message.

Section 3 Pager 34
3.4 Paging
3.4.1 Procedure 1: UE in Cell-DCH or Cell-FACH
UE Node-B SRNC CN
1. Paging
RANAP RANAP
CN Domain Indicator, UE
identity, Paging cause
2. Paging Type 2 (DCCH:FACH or DCH)
RRC RRC
In this case the UE is already connected and is using a service (voice call, web-browsing …).
The Core Network knows the situation of the UE and mainly its Serving RNC. The CN
contacts directly the Serving RNC.
The RNC doesn’t use the PCCH and the PCH but the channel used for the UE, dedicated or
common, according to the status of the UE.

UTRAN Scenario
UE is in cell_FACH or in cell_DCH states:

1. CN initiates the paging of a UE to Serving RNC
2. Paging of UE with Paging Type 2 (on DCCH) using the existing RRC connection

Section 3 Pager 35
3.4 Paging
3.4.2 Procedure 2: UE in Idle Mode
UE 1 UE 2 Node-B1 Node-B2 RNC1 RNC2 CN
1. Paging
RANAP RANAP
CN Domain Indicator, UE
identity, Paging cause
1. Paging
RANAP RANAP
Idem
2. Paging Type 1 (PCCH:PCH)

RRC RRC
2. Paging Type1 (PCCH:PCH)

RRC RRC
When the mobile is in idle mode, UTRAN doesn’t know where it is located and the Core Network
knows its location at the LA or RA level. UTRAN uses the PCCH and the PCH radio channels.

UTRAN Scenario
UE is in idle mode:
1. CN initiates the paging of a UE over a LA (RA in PS domain) spanning, for example, two RNCs.
2. Paging of UE with Paging Type 1
LA: Location Area, RA: Routing Area (see subchapter “5.8 Mobility Management”)
A similar procedure applies to UE in cell_PCH or in URA_PCH states.

Section 3 Pager 36
3.4 Paging
3.4.3 Paging: PICH & PCH Radio Channels
PCCH Logical Ch
The UE doesn’t watch the S-CCPCH.
RNC It watches the PICH (Page Indicator
MAC Channel) at regular and defined
In RNC interval and look for its PI, for
Iub Paging Indicator.
PCH Transport Ch The PI is based on the IMSI. Several
UEs can have the same PI.
.. When the UE find its PI on the
Paging
. Physical PICH, it watches the S-CCPCH to
message PI layer check if it is for it and what is the
In Node B cause.
PI
PI Then it requests on RRC connection

to have a RAB.
Physical Ch
S-CCPCH PICH
S-CCPCH PICH

UTRAN Scenario
The period of the cycle is between 4 and 4096 radio frames. That means the UE can monitor the PICH
every X seconds, with X between 40 ms and 40,96 seconds. If the period is too short the UE uses too
much power if the period is 40 s, the delay is really long.
It is a trade-off between the delay and the consumption.
To determine the radio frame number into the cycle and the Paging Indication, the UE uses its IMSI and
others parameters send on the SIB.

Section 3 Pager 37
4 RAB Establishment

UTRAN Scenario

Section 3 Pager 38
4 RAB Establishment
4.1 Admission Control
According to the previous part “WCDMA in UMTS”, if the interference level at the Node B level is
too high, the Node B can’t decode all the signal. The size of the cell decreases. The interferences
are due to several causes:
• The radio environment and the load of the adjacent cells,
• Some users use too much power, the power control manages this problem,
• There are too many users on the cells
UTRAN has to check if there is enough UL radio resource
P
RNC SIR too small to
retrieve the message
Iub Eb
SIR
ISCP = No
PG
RSCP = Ec
f
2 others questions before adding a new user : Is there sufficient DL radio resource and
sufficient processing resources ?

UTRAN Scenario
If the CAC (Call Admission Control) has not been passed,

For CS services, the call can’t be established.
For PS services, the UTRAN may try assigning a RB with a lower bit rate. There are different level of
bit rates than can be used a given requested RAB. The Node B tries to assign first the highest, and
then goes to the lower rates, as long as the RAC rejects the Radio Link Reconfiguration.

Section 3 Pager 39
4 RAB Establishment
4.1 Admission Control [cont.]
Is there sufficient UL Radio Resource -> Rx CAC
If UL interference level + estimated new user contribution < threshold

Then Rx RAC ok
Is there sufficient DL Radio Resource -> Tx CAC
If Total DL Tx Power + estimated new user contribution < threshold

Then Tx RAC ok
Is there sufficient processing resource -> Processing CAC

3 main points are checked:
• the channelization codes
•The Baseband load
•The number of users and radio links
Is there sufficient Iub Bandwidth -> Iub CAC
Iub Bandwidth is checked

UTRAN Scenario
CAC = Call Admission Control

Section 3 Pager 40
4 RAB Establishment
4.2 Radio Bearer Establishment
We have seen how a UE, after the switch on, can collect system information, update its
location, request a RRC Connection and a service, can be paged and how UTRAN allows it to
use services. Now how is established the RAB ?
B RNC B
RA Radio Bearer Iub Iu Bearer RA Core Network
Node B
Signaling
UTRAN
RLC
RLC Mode: Tr., UM or AM and
retransmission parameter for AM
Configured Logical Channel
by
MAC TTI, TFS, TFCS, CRC, FEC, Coding Rate,
RRC
Rate Matching
Transport Channel
Phy. Frequency, Power, Channelization &

Scrambling codes
Physical Channel
UTRAN Scenario
RAC = Radio Access Control

Section 3 Pager 41
4.2.1 Signaling: RAB Establishment
UE Node-B SRNC CN
1. RAB Assignment Request
RANAP RANAP
RAB parameters, User plane
mode, Transport Address, Iu
Transport association
2. ALCAP Iu Data Transport Bearer Setup
3. Radio Link Establishment
4. RB Setup (DCCH:FACH or DCH )

RRC RRC
TFS, TFCS...
5. RB Setup Complete (DCCH:RACH or DCH )
RRC RRC
-
6. RAB Assignment Response
RANAP RANAP
-
The UE is RRC connected and has requested a service.

UTRAN Scenario
Can the UE send user information (e.g voice call) just after Radio Access Bearer establishment?
YES : At the end of this signaling procedure, a RAB has been assigned to the UE to carry user information.
The RAB is mapped on the RB which has been set up. The RB is mapped on DTCH: RACH/FACH or DCH.

Section 3 Pager 42
4.2.2 Signaling: Radio Link Setup
Node-B SRNC
Radio Link Setup Request
NBAP NBAP
Cell id, TFS, TFCS, frequency, UL
scrambling code, power control info
Start RX
ALCAP Iub Data Transport Bearer Setup
Radio Link Setup Response

NBAP NBAP
Signaling link termination, transport layer
addressing info
Downlink synchronisation
Iub-FP Iub-FP
Uplink synchronisation
Iub-FP Iub-FP
Start TX
>> Are NBAP, ALCAP and RRC messages carried on the same transport
transport bearers on Iub?

UTRAN Scenario

This procedure is used in many RRC procedures, e.g RRC connection establishment (Procedure C1), Radio
Bearer Set-up (Procedure F1), soft HO (Procedure G)…
In this procedure:
a radio link is set up by the RNC on the Node-B side using the NBAP protocol
(a similar task is performed on the UE side using RRC protocol, see e.g. procedure C1)
a terrestrial link (AAL2 bearer) is setup on Iub interface using ALCAP protocol

Section 3 Pager 43
4.2.3 Radio Bearer Mapping
We have seen how a UE, after the switch on, can collect system information, update its
location, request a RRC Connection and a service, can be paged and how UTRAN allows it to
use services. Now how are established the RAB ?
B RNC B
RA Radio Bearer Iub Iu Bearer RA Core Network
Node B
UTRAN
RLC
RLC Mode: Tr., UM or AM and
retransmission parameter for AM
Configured Logical Channel
by
MAC TTI, TFS, TFCS, CRC, FEC, Coding Rate,
RRC
Rate Matching
Transport Channel
Phy. Frequency, Power, Channelization &

Scrambling codes
Physical Channel
UTRAN Scenario

Section 3 Pager 44
4.2.4 Physical Layer Processing
Convolutional coding,
Channel Coding Turbo coding
10 ms frame duration
Radio Frame Segmentation 15 time slots
Transport Channel Multiplexing CCtrCH
Physical Channel Mapping DPDCH, DPCCH, PRACH...
Channelization codes
Spreading
Scrambling codes
Layer 1
Modulation QPSK
Physical Channels
spread over 5 MHz bandwidth

UTRAN Scenario
The physical layer belongs to control plane and to user plane.
Physical layer main functions:
Multiplexing/de-multiplexing of transport channels on CCTrCH (Coded Composite Transport

Channel) even if the transport channels require different QoS.
Mapping of CCTrCH on physical channels
Spreading/de-spreading and modulation/demodulation of physical channels
RF processing (3 GPP 25.10x)
Frequency and time (chip, bit, slot, frame) synchronization
Measurements and indication to higher layers (e.g. FER, SIR, interference power, transmit power,
etc.)
Open loop and Inner loop power control
Macro-diversity distribution/combining and soft handover execution

Section 3 Pager 45
4.2.5 Radio Channels
Assuming a UE a video call service. What happens in Uplink ?
CN
RAB :64 kbps
Radio Bearer RLC parameters
Mode : Transparent because it is a real time service
RLC MAC parameters
Logical Ch. CRC = 16 bits, FEC = Turbo Code Coding Rate = 1/3, TTI= 20 ms,
DTCH TFS=(0*640, 2*640 bits)
MAC
Transport Ch. DCH

640 640 640
Physical Layer 640 640 640

TTI
Physical Ch.
DPDCH/DPCCH How many radio frame are necessary to send all this data ?
UE

UTRAN Scenario
The RB 20 (1st column ) corresponds to the Video Call.

Section 3 Pager 46
4.2.6 Radio Channels: Data Processing
Assuming a UE a video call service. What happens in Uplink ?
Transport #1 #2
Blocks
640 bits 16
CRC attachment #1 #2
Tr Bl concatenation (640+16)*2=1312 bits
Turbo coding (1/3) 1312*3=3936 bits

6 Can you deduce the SF ?
Tail Bit Attachment 1312*3=3936 bits
And the value of Nrm ?
1 st interleaving 3942 bits

1971 1971
Radio Frame
#1 #2
Segmentation
Rate matching #1 #2
1971 +Nrm 1971 +Nrm

UTRAN Scenario
First, the 16 CRC bits are added at each transport block.

Then the transport block are concatenated.
The turbo coding consist of adding a lot of redundant bits to be able to detect and correct errors.
Before the interleaving some bits are added. The purpose of the interleaving is to avoid to have big
packet of errors at the reception.
Finally the data are segmented by 2, because the TTI=20 ms and a radio frame is 10 ms.
At the end to fill the radio frame, Nrm bits are added.

Section 3 Pager 47
4.2.7 Radio Channels: Transport Channel Multiplexing
Assuming a UE a video call service and on the same time sends on a e-mail.
How can it be possible to send 2 different services on the same physical channel ?
Several transport channels can be time-coordinated to be multiplexed on a CCTrCH
before mapping on one physical channel
Transport Format MAC

Example:
TFC Selection
TFS (DCH1)={(0*640); (4*640)} DCH2
DCH1
TFS(DCH2)={(1*0); (1*39); (1*42); (1*55); (1*65)}
TrCH Multiplexing
TFCS={(0*640); (1*0)}; {(0*640); (1*39)}; {(0*640); (1*42)}; {(0*640);
(1*55)}; {(0*640); (1*65)}; {(1*640); (1*39)}; {(1*640); (1*42)} CCTrCH
Phy. Ch. Mapping

Transport Format Combination
MAC selects TFC inside TFCS.
L1
There is one TFCS per CCTrCH
Physical Channel

UTRAN Scenario
TFS= Transport Format Set

TFCS=Transport Format Combination Set
TF=Transport Format

Section 3 Pager 48
4.2.8 Radio Channels: DPDCH/DPCCH Channels
Uplink Multiplexed by the modulation
DPDCH Data : user data, RRC Signaling & NAS Signaling
DPCCH Pilot TFCI FBI TPC
Downlink Time-multiplexed
Data1 TPC Data2 TFCI Pilot
DPDCH DPCCH DPDCH DPCCH DPCCH

UTRAN Scenario
Why are DPDCH and DPCCH time-multiplexed in DL(and not transmitted simultaneously as in UL)?
Discontinuous transmission can cause audible interference to audio equipment close to the terminal (e.g
hearing aids), which is a disturbance for user.
In UL the transmission is always continuous, because there is at least the DPCCH which is transmitted.
The user will not be disturbed.
In DL the transmission may be discontinuous, but it is no problem (no user at the base station).
Note: The downlink DPDCH/DPCCH physical channels are called the DPCH physical channel.

Section 3 Pager 49
5 Mobility Management in Connected
Mode

UTRAN Scenario

Section 3 Pager 50
5 Mobility Management in Connected Mode
5.1 Soft HO: Active & Monitoring Set
RNC
Iub
The RNC manages the Active Set and builds

the Monitoring Set.
The Monitoring Set is built from the
information of topology and design in the
RNC.
The Active Set is managed from the event
send by the UE to the RNC.
Cell in the Active Set

Cell in the Monitoring Set

UTRAN Scenario
The maximum number of cells in the monitoring set is 32.

The maximum number of cells in the active set is set from the Office Data, between 3 and 6.
The monitored set is built for each UE by the RNC from the neighboring list. The RNC selects the best
cells in this list for the monitored cells.

Section 3 Pager 51
5.2 Soft HO: Events
There are 3 events for the soft handover.

The value measured is the CPICH Ec/No.
The event 1a is triggered when the CPICH
Ec/No of a monitored cells is above a RNC
certain threshold.
If the event is fulfilled the cell is added in
the active set
Iub
The event 1b is triggered when the CPICH
Ec/No of a active cell is below a certain
threshold.
If the event is fulfilled the cell is removed
from the active set
The event 1c is triggered when the active
set has reached its maximum size and the
CPICH Ec/No of a monitored cells is better
than a cell belonging to the active set.
If the event is fulfilled the candidate cell
replaces the cell in the active set
Cell in the Monitoring Set

UTRAN Scenario
The simplified formula to trigger an 1a event is :

10log(Mnew) > 10log (MBest) – R1a
Where:
Mnew is a measurement on the candidate cell about the quality of reception.
Mbest is a measurement on the best cell in the active set about the quality of reception.
R1a is the “Reporting Range”.
CPICH
Ec/N0
Best
Cell
R1a
Candidate
Cell Time
T0 T1 -> Event 1a

Section 3 Pager 52
5.3 Compressed Mode
Most of the UEs are not dual receivers.

And they need to perform measurements
on other frequencies.
RNC
So UTRAN has to free a time window to

perform these measurements on other Iub
FDD frequencies or on GSM frequencies.
Cell in the Monitored Set, same FDD frequency
Time interval to measure other frequencies Cell in the Monitored Set, other FDD frequency
Cell in the Monitored Set, GSM cell

UTRAN Scenario
Compressed mode method available according to the 3GPP TS 25.212

compressed mode methods:
By puncturing : the rate matching is applied for creating a transmission gap in one or two
frames (not in UL)
Reducing the SF by 2
Compressed frames can be obtained by higher layer scheduling. Higher layers then set
restrictions so that only a subset of the allowed TFCs are used in a compressed frame. The
maximum number of bits that will be delivered to the physical layer during the compressed
radio frame is then known and a transmission gap can be generated

Section 3 Pager 53
5.4 Hard HO: Events on other FDD Frequencies
There are 4 events to watch the UMTS cell

with other FDD frequencies
RNC
The event 2d_cm is triggered when the
quality of on the current frequency is
below a certain quality. The compressed
mode is launched. Iub
The event 2b is triggered when the

quality of the current frequency is below
a certain threshold and the quality on an
other frequency is above a certain
threshold
The event 2f is triggered when the quality
on the current frequency is above a
certain threshold. The compressed mode
is deactivated. Cell in the Monitored Set, same FDD frequency
Cell in the Monitored Set, other FDD frequency

UTRAN Scenario

Section 3 Pager 54
5.5 Hard HO: Events on other GSM Frequencies
2 causes can trigger an hard HO toward the

GSM system:
• Some bad radio conditions RNC
• due to the service requested
The event 2d_cm is triggered when the
Iub
quality of on the current frequency is below
a certain quality. The compressed mode is
launched.
The event 3a is triggered when the quality
on the current FDD frequency is below a
certain threshold and the quality on the GSM
is above another threshold.
The event 3c is triggered when the service Cell in the Active Set
requested can be managed by the GSM, the
voice typically. Cell in the Monitored Set, same FDD frequency
Cell in the Monitored Set, other FDD frequency

UTRAN Scenario

Section 3 Pager 55
6 Exercises

UTRAN Scenario

Section 3 Pager 56
6 Exercises
6.1 Scenario Description
Objectives:
Rebuilt the channels mapping, Logical, Transport and Physical channels
from a scenario to guide you with the 2 next pages
Scenario:
• The UE switches on in a covered area
• The UE collects information about the system
• The UE requests a RRC connection to declare its location and releases the RRC
connection
• The UE receives a paging message to receive an e-mail
• UTRAN establishes a RAB and is in the DCH_Cell State
• As the traffic is not large, the UE passes to the FACH_Cell State
Be careful, following this scenario, some channels are missing.

Which are the missing channels ?

UTRAN Scenario

Section 3 Pager 57
6 Exercises
6.2 Downlink
Logical Ch.
Transport Ch.
Physical Ch.

UTRAN Scenario

Section 3 Pager 58
6 Exercises
6.3 Uplink
Logical Ch.
Transport Ch.
Physical Ch.

UTRAN Scenario

Section 3 Pager 59
Evaluation
Objective: To be able to build the map of

the radio channels (logical, transport and
physical channels) from a white paper.


UTRAN Scenario

Section 3 Pager 60
End of Module

UTRAN Scenario

Section 3 Pager 61
4
Section 4
MBMS Radio Principles
9300 WCDMA

Section 4 Pager 1
Blank Page

Document History
01 2010-01-20 ELSNER Bernhard First edition

Section 4 Pager 2
Module Objectives
Upon completion of this module, you should be able to:
Describe the Multimedia Broadcast Multicast Service (MBMS) feature

Explain the new NEs and interfaces in the UMTS architecture
List the new channels and the functions
Explain the OVSF Code Tree Configuration with MBMS
Explain the MBMS service area concept
Describe the features: “Iub Transport bearer sharing“ and “Selective/soft
Combining”


Section 4 Pager 3
Module Objectives [cont.]


Section 4 Pager 4
Table of Contents
Page
1 MBMS introduction 7
1.1 MBMS principles 8
1.2 Architecture overview 9
2 MBMS UTRAN new functionalities 10
2.1 MBMS new channels 11
2.2 MBMS data flow through RLC, MAC and L1 12
2.3 OVSF Code Tree Configuration with MBMS (1/2) 13
3 MBMS features in UA7.1 14
3.1 Service areas 15
3.2 Iub transport bearer sharing 16
3.3 Native IP Iub and MBMS 18
3.4 Selective/soft Combining 19
3.5 Summary MBMS in UA07 20


Section 4 Pager 5

MBMS Radio Principles This page is left blank intentionally

Section 4 Pager 6
1 MBMS introduction


Section 4 Pager 7
1 MBMS introduction
1.1 MBMS principles
TV program FEATURE DESCRIPTION

MBMS Broadcast allows operators to
broadcast Multimedia content to all
mobiles in any cell(s) of the network
FEATURE VALUE
Unicast: data is sent as many Efficient data delivery method to
times as users in the network many users
For the operators, this means
TV program reduction of the TCO for additional
data revenue streams (e.g.. Mobile
TV, advertising, etc.) and improved
subscriber loyalty.
DEPENDENCIES
Broadcast: data is sent only UE and Core Network MBMS support
once within network
Same content to Multiple users :

Bandwidth efficiency, capacity gain, CAPEX saving
Multimedia Broadcast Multicast Service (MBMS) is a 3GPP Release 6 feature

Enhanced MBMS Broadcast Service allows operators to broadcast Multimedia content (text, images,
audio, video, ..) to all mobiles in any cell(s) of the UMTS network.
Two modes of operation:
Broadcast mode (point-to-multipoint)
Multicast mode (point-to-multipoint or point-to-point) (expected later than UA07)
Data is transmitted from one single source to multiple terminals in a broadcast service area.
Optimization of Iub resources
Support of MBMS on Iub over IP
Use of IP multicast in case of native IP Iub (not available yet, expected later than UA07)
Transport Bearer Sharing.
Customer Benefits
Efficient delivery method to many users. Compared to CBS, MBMS-broadcast allows high data rates and
multimedia services. Moreover, it is possible for UEs to receive this data in any state
For the operators, this means additional data revenue streams (e.g. Mobile TV, advertising, etc..) and
improved subscriber loyalty
Transport bearer sharing unloads the transport network.

Section 4 Pager 8
1 MBMS introduction
1.2 Architecture overview
Control
Plane A new UMTS entity
CN PS domain (BM-SC) has been
UTRAN introduced
Iu- Gn Gmb
Uu
RNC PS BM-SC
3G-SGSN GGSN Content
Gr Gi Provider
Node B
HLR Gn
Gr Bearer Multicast /
BSS Plane Broadcast
MBMS is provided 2G-SGSN source
over the PS
Domain Other Network entities
(GGSN, SGSN and RAN)
are impacted to
support MBMS
LTE Access eCN
The BM-SC performs the following
functions:
Membership function
Session and transmission function
aGW
Proxy and transport function
Service announcement function
eNode B
Security function
BSS
The boundary of the MBMS Bearer Service is the Gmb and Gi reference points: the former provides
access to control plane and the later the bearer plane.
Gmb:
Signaling between GGSN and BM-SC is exchanged at Gmb reference point. This represents the network
side boundary of the MBMS Bearer Service from a control plane perspective. This includes user specific
Gmb signaling and MBMS bearer service specific signaling.
MBMS bearer service specific Gmb signaling:
The GGSN establishes the MBMS bearer context and registers at BM-SC
The GGSN or the BM-SC releases the MBMS bearer context and deregisters the GGSN from the BM-SC
The BM-SC indicates session start and stop to the GGSN including session attributes like QoS and MBMS
service area.
User specific Gmb signaling:
BM-SC authorizes the user specific MBMS multicast service activation (join) at the GGSN
GGSN reports to the BM-SC the successful user specific MBMS multicast activation (join) to allow the
BM-SC to synchronize the BM-SC MBMS UE context with the MBMS UE contexts in the SGSN and GGSN
GGSN reports to BM-SC when a user specific MBMS multicast service is released or deactivated (e.g. at
implicit detach), it makes this report in order to synchronize the BM-SC MBMS UE context with the
MBMS UE contexts in the SGSN and GGSN.
The BM-SC initiates the deactivation of a user specific MBMS bearer service when the MBMS user
service is terminated.
BM-SC functions for different MBMS bearer services may be provided by different physical network
elements. Further, MBMS bearer service specific and user specific signaling for the same MBMS bearer
service may also be provided by different physical network elements. To allow this distribution of BM-
SC functions, the Gmb protocol must support the use of proxies to correctly route the different
signaling interactions in a manner which is transparent to the GGSN.

Section 4 Pager 9
2 MBMS UTRAN new functionalities


Section 4 Pager 10
2.1 MBMS new channels
New Logical channels

MSCH (MBMS PTM Scheduling Channel) mapped on FACH
Used to notify the scheduling of MBMS sessions
MCCH (MBMS PTM Control Channel) mapped either on FACH
Carries control plane information
MTCH (MBMS PTM Traffic Channel) mapped on FACH
Delivers user plane information
MAC-m (Media Access Control MBMS) functionality
Handling of the mapping of MTCH, PCCH to the appropriate FACH
In charge of Scheduling/Buffering/Priority handling of MBMS transmissions
Located at RNC
New Physical channel
MICH (MBMS notification Indication Channel)
SF=256 S-CCPCH physical channel
Used to indicate MBMS information availability on MCCH

PTM – Point-To-Multipoint
MCCH - MBMS PTM Control Channel

Carries control plane information between network and UEs
Is mapped over a separate FACH, i.e., not sharing with other logical channels
Can share SCCPCH
MTCH - MBMS PTM traffic channel

Carries user plane traffic
Is mapped to one FACH transport channel
TCTF field in MAC header is always used
One MTCH is configured for each MBMS service
MSCH - MBMS PTM scheduling channel

Carries transmission schedule between network and UEs
Is mapped over a separate FACH
Shares SCCPCH with MTCH
Used for DTX

Section 4 Pager 11
2.2 MBMS data flow through RLC, MAC and L1
PTM radio bearer
RNC
RLC
One MAC
MTCH
entity for
each cell MAC-c/m MAC-c/m MAC-c/m
FP FP FP
FACH
Node B
FP FP FP
S-CCPCH S-CCPCH S-CCPCH
Cell1 Cell2 Cell3


Section 4 Pager 12
2.3 OVSF Code Tree Configuration with MBMS (1/2)
16
32
64
8
128
256
P-CPICH; Cch256,0
0 P-CCPCH; Cch256,1
0 Aich; Cch256,2
1 Pich; Cch256,3
2 S-CCPCH (for DTCH/DCCH/

CCCH/BCCH); Cch64,1
1
3
S-CCPCH (for PCCH); Cch128,4
4
S-CCPCH (for MCCH); Cch256,10
5 MICH; Cch256,11
HS-SCCH; Cch128,6
6

MICH & MCCH

The codes for the MICH (SF=256) and the MCCH (SF=256 or 128) are allocated at the top of the tree at
MBMS cell setup.
Example: DL OVSF code allocation with configuration B with MBMS and without CBS

Section 4 Pager 13
3 MBMS features in UA7.1


Section 4 Pager 14
3.1 Service areas
MBMS Service Area (SA): area in which a specific MBMS session is made
available.
The MBMS RAB establishment involves the establishment of a number of
RB for MTCH (one per cell). The service content is broadcast within a
set of cells ‘MBMS service area’.
Service Area 2 Service Area N

IP Network
RNC
Service Area 1
The operator can define the MBMS Service Areas in a flexible way. The service
area can be as small as one cell, and one cell can belong to up to 8 service areas.

Section 4 Pager 15
3.2 Iub transport bearer sharing
MBMS Transport in 3GPP Release 6
NodeBn
Node B2 Node Bn
IP Network
RNC
Node B1
RNC


Section 4 Pager 16
3.2 Iub transport bearer sharing [cont.]
MBMS first Transport Optimization in 3GPP Release 7

Iub Transport bearer sharing
Node B2 Node Bn
IP Network
Node B1
RNC
Iub transport efficiency is also ensured over several cells of the same Node B:
a single flow is used on a shared Transport bearer if the same content is sent to multiple
cells of the same Node B.
Transport bearer sharing

MBMS over a single FACH is supported in UA7.1.
It is activated per Iub with OAM parameter IsTransportBearerSharingForMBMSSupported.
This improvement applies only for PTM transmission, using FACH transport channel. It concerns only
MTCH (MBMS traffic channel) and not MCCH (MBMS control channel)
Without this improvement, the MBMS RAB establishment involves the establishment of several MTCH
flows per Node B (one MTCH flow per cell)
With this improvement, the MBMS RAB involves the establishment of only one MTCH flow for multiple
cells in one Node B, or more precisely of one FACH DATA frame for MTCH per Node B, (instead of one
FACH data frame for MTCH per cell) and thus enables to improve Iub bandwidth efficiency
There is a restriction in iCEM and xCEM, that the number of cells that can share a TB is <= 3, and all
those cells have to be handled by the same BBU (i.e. those cells are in the same LCG or Local Cell
Group). So for a (6sector 2carrier) BTS configuration, we would need 4 MBMS Broadcast Groups, each
having a separate TB, so 4TBs in sum.

Section 4 Pager 17
3.3 Native IP Iub and MBMS
In case of a native IP Iub, all traffic, including the MBMS PTM traffic is
carried on IP/Ethernet in RNC and in Node B
Default DSCP used for MBMS PTM are configurable in RNC, configured
values have to be consistent with global IP QoS strategy on Iub
Default DSCP used for MBMS PTM Streaming and MBMS PTM Background
are different.


Section 4 Pager 18
3.4 Selective/soft Combining
There is less PA power needed in a cell when combining is possible.

Thus, during an ongoing MBMS session, the RNC will periodically adjust
power levels according to the neighboring situation.
To improve quality of received traffic

Soft combining:
L1 combining
MTCH payload is received from the primary cell and neighboring cells, and is
combined at L1 (similar to DHO)
Require transmission synchronization from the RNC
Selective combining:
L2 combining
RLC provides buffering of PDUs before the re-assembly unit
PDUs received in sequence are sent to the re-assembly unit, otherwise held in
the DAR buffer

DAR – Duplicate Avoidance and Reordering

DHO – Diversity Handover
In order to improve L1 performance Selective/Soft Combining is supported.
Selective combining
Selective Combining is the mode where the UE performs RLC re-ordering based on RLC PDU numbering
and on combining data streams from different cells
To support selective combining:
One RLC entity per MBMS service utilizing PTM transmission and per cell group
All cells in the cell group are under the same CRNC, i.e. Iur support is not considered.
Soft/Selective combining is only possible with same SF & user rate.

Section 4 Pager 19
3.5 Summary MBMS in UA07
MBMS Broadcast main target is Mobile TV application
MBMS Broadcast can be supported on any carrier(s), and can be

dedicated or mixed with other services
Mobility is supported in any mobile state
64, 128, and 256 kbps data rates can be supported
MBMS traffic may be transmitted in parallel to other services
Iub optimization

MBMS Broadcast main target is Mobile TV application

Session running for long/unlimited time
High number of users interested in the service
MBMS Broadcast can be supported on any carrier(s), and can be dedicated or mixed with other services
FLC/FLD (Frequency Layer Convergence/Divergence) is supported
Mobility is supported in any mobile state

Idle, Cell-FACH, URA/Cell-PCH, and Cell-DCH state
64, 128, and 256 kbps data rates can be supported

Streaming @ 64, 128 or 256 kbps, Background @ 64 kbps
Lower rates currently not defined in 3GPP TR 25.993
MBMS traffic may be transmitted in parallel to other services

Whether the UE will be able to actually receive MBMS will only depend on its own capabilities
Note : MBMS capabilities are not provided to UTRAN
Iub optimization
When the same content is sent to multiple cells of the same Node B, trunking allows to conveyed on the
same flow: thus, instead of one FACH data frame per cell, only one FACH data frame is sent to a Node B.

Section 4 Pager 20
Module Summary
Having completed this module, you should be able to:
Describe the MBMS feature

Explain the new NEs and interfaces in the UMTS architecture
List the newly introduced channels and the functions
Explain the OVSF Code Tree Configuration with MBMS
Explain the MBMS service area concept
Describe the features: „ Iub Transport bearer sharing“ and „Selective/soft
Combining”


Section 4 Pager 21
End of Module


Section 4 Pager 22
5
Section 5
Glossary
9300 WCDMA

TMO18246 Edition TMO18246 D0 SG DEN I2.0
Section 5 · Pager 1
Blank Page

Glossary
Document History
01 2006-10-09 NBX First edition

Abbreviations and Acronyms
# Switch to notes view! CN Core Network

16-QAM 16 – Quadrature Amplitude CONT Controller
Modulation CPCH Common Packet Channel
3GPP 3rd Generation Partnership Project CPCS Common Part Convergence Sub-layer
CPS Command Part Sub-layer
A CPU Central Processing Unit
AAL ATM Adaptation Layer CQI Channel Quality indicator
ACELP Algebraic Code Excited Linear CRC Cyclic Redundant Check
Prediction CS Circuit Switched
ACK Acknoledgement CS Convergence/Adaptation to Services
ADN Abbreviated Dialling Number (ATM)
AID Alarm Instance Identification CTCH Common Traffic Channel
ALCAP Access Link Control Application Part CTD Cell Transfer Delay
AMPS Advanced Mobile Phone System
AMR Adaptive Multi Rate D
ANRU Antenna Network and multi-carrier DAR Duplicate Avoidance and Reordering
Receiver UMTS DB Debug
ANSI American National Standard Institute DCA Dynamic Channel Allocation
(USA) DCCH Dedicated Control Channel
ARIB Association of Radio Industries and DCH Dedicated Channel
Business (Japan) DCN Data Communication Network
ATC ATM Traffic Contract DHO Diversity HandOver
ATM Asynchronous Transfer Mode DHT Diversity HandOver Trunk
DL Downlink
B53 DPCH
Dedicated Physical Channel
BBGlossary Base Band DPCCH Dedicated Physical Control Channel
BCCH Broadcast Control Channel DPDCH Dedicated Physical Data Channel
BER Bit Error Rate DRAC Dynamic Resource Allocation Control
BHCA Busy Hour Call Attempts DRNC Drift RNC
BLER Block Error Rate DS Direct Sequence
BMC Broadcast Multicast Control DSCH Downlink Shared CHannel
BM-SC Broadcast Multicast Service Centre DTCH Dedicated Traffic Channel
BM-IWF Broadcast Multicast Inter-Working
Function E
BPMT Node B Performance Monitoring Tool E-DCH Enhanced Dedicated CHannel
BSC Base Station Controller EDGE Enhanced Data rates for GSM
BSS Base Station (sub)System Evolution
BTS Base Transceiver Station EFR Enhanced Full Rate
BWC Bandwidth Control E-GSM Enhanced GSM
E-GPRS Enhanced GPRS
C EM Element (or Equipment) Manager
CAC Connection Admission Control ERAN EDGE Radio Access Network (all-IP)
CAMEL Customised Application for Mobile ETSI European Telecommunication
CAPEX CAPital EXpenditure Enhanced Standard Institute
Logic F
CC Call Control FACH Forward Access Channel
CCCH Common Control Channel FAD Function Access Domain
CCO Cell Change Order FBI Feed-Back Information
CCT Call Context Template FDD Frequency Division Duplex
CCTrCH Coded Composite Transport Channel FDL File Download (EM application)
CDMA Code Division Multiple Access FDMA Frequency Division Multiple Access
CDR Call Data Record FER Frame Error Rate
CDV Cell Delay Variation FTP File Transfer Protocol
CLR Cell Loss Ratio FW Firmware
CM Configuration Management

Abbreviations and Acronyms [cont.]
G Iu-PS Interface RNC - CN Packet Switch

GCRA Generic Cell Rate Algorithm
GERAN GSM/EDGE Radio Access Network K
GGSN Gateway GPRS Support Node Kbps Kilo Bit per Second
GMSC Gateway MSC
GMSK Gaussian Minimum Shift Keying L
GP Granularity Period L1, L2, L3 Layer , Layer 2, Layer3
GPRS General Packet Radio Service LA Local Area
GSM Global System for Mobile LAC Local Area Code
Communications LAN Local Area Network
GTP GPRS Tunneling Protocol LCS LoCation Services
GTP-U GPRS Tunneling Protocol-User Plane LED Light Emitting Diode
GUI Graphical User Interface LLC Logical Link Control
LoS Line of Sight
H LM Load Module
HCS Hierarchical Cell Structure LMT Local Maintenance Terminal
HHO Hard HandOver LIF Low speed Interface
HIF High speed Interface LQC Link Quality Control
HLR Home Location Register
HO HandOver M
HSDPA High Speed Downlink Packet Access MAC Medium Access Control
HS-DPCCH High Speed Dedicated Physical MAC-hs Medium Access Control - High Speed
Control
54 MAP
All Rights Reserved © Alcatel-Lucent 2010 Mobile Application Part
Glossary
CHannel.
9300 WCDMA TMO18246 9300 WCDMA UAO7 R99 Radio Principles MBMS Multimedia Broadcast Multicast
HS-DSCH High Speed Downlink Shared CHannel Service
HSS Home Subscriber Service MBS Multi-standard Base Station (UTRAN)
HS-SCCH High Speed Shared Control CHannel MBS Maximum Burst Size (ATM)
HSUPA High Speed Uplink Packet Access MCCH MBMS PTM Control Channel
HPLMN Home PLMN MCR Minimum Cell Rate
MICH MBMS notification Indication Channel
I MIMO Multiple Input / Multiple Output
IMEI International Mobile Equipment MM Mobility Management
Identity MMUX MAC Multiplexer
IMS IP Multimedia Subsystem MSC Mobile Switching Centre
IMSI International Mobile Subscriber MSCH MBMS PTM Scheduling Channel
Identity MSP Multiple Subscriber Profile
IMT International Mobile MTCH MBMS PTM Traffic Channel
Telecommunication MTP3 Message Transfer Part level 3
IMT-DS Direct Sequence MTP-3B Message Transfer Part level 3
IMT-MC Multi Carrier Broadband
IMT-SC Single Carrier
IMT-TC Time Code N
IOT Inter Operability Tests NACK Non-Acknoledgement
IOR Interoperable Object Reference NAS Non Access Stratum
IP Internet Protocol NAD Network Access Domain
IR Incremental Redundancy NBAP Node-B Application Part
ISC Internetworking Services Card NE Network Element
ISDN Integrated Services Digital Network N/E Normal/ Emergency
Itf-b Interface Node B - OMC-R NEM New element manager
Itf-r Interface RNC - OMC-R NEM-B Network Element Manager for Node B
ITU International Telecommunication NEM-R Network Element Manager for RNC
Union NM Combined EM and SNM
Iub Interface Node B - RNC NML Network Management Layer
Iur Interface RNC - RNC NMS Network Management System
Iu-CS Interface RNC - CN CircuitAllSwitch Rights Reserved © Alcatel-Lucent NPA 2010 Network Performance Analyser
Section 5 · Pager NTP 4 Network Time Protocol
Table of Contents
O
OAM Operation And Maintenance RAID Redundant Array Independent
Page
O&M
Operation And Maintenance (or Inexpensive) Disk
OD Office Data RAN Radio Access Network
ODMA Orthogonal Division Multiple Access RANAP RAN Application Part
ODT Office Data Tool RB Radio Bearer
ODTM Office Data Tool Macro RR Round Robin
OFDM Orthogonal Frequency Division RF Radio Frequency
Multiplexing RPMT RNC Performance Monitoring Tool
OMC-R Operation & Maintenance Centre - RRC Radio Resource Control
Radio RRM Radio Resource Management
OPEX OPerational EXpenditures RV Redundancy Version
ORB Object Request Broker
OS Operating System S
OSA Open Service Architecture SAC Service Area Code
OTDOA Observed Time Difference of Arrival SAP Service Access Point
OTSR Omni directional Tx / Sectorised Rx SAR Segmentation And Re-assembly
OVSF Orthogonal Variable Spreading Factor SAT SIM Application Toolkit
SC Short Cell
P SC System Configuration
PCCH Paging Control Channel SCF System Configuration File
PCR Peak Cell Rate SCR Sustainable Cell Rate
PCU Packet Control Unit SCTP Stream Control Transmission Protocol
PDA Personal Digital Assistant SDH Synchronous Digital Hierarchy
PDC5 5 Personal Digital Cellular (2G Japan) SF 2010
All Rights Reserved © Alcatel-Lucent Spreading Factor
PDP Glossary Packet
9300 WCDMA Data
TMO18246 9300 Protocol
WCDMA UAO7 R99 Radio Principles SGSN Serving GPRS Support Node
PDU Protocol Data Unit SHO Soft HandOver
PFS Proportional Fair Scheduling SIR Signal to Interference Ratio
PLMN Public Land Mobile Network SL Scheduling List
PM Performance Measurement (O&M) SMS Short Message Service
PRACH Physical Random Access Channel SNMP Simple Network Management Protocol
PS Packet Switched SPU Signaling Processing Unit
PSK Phase Shift Keying SQL Structured Query Language
PSTN Public Switched Telephone Network SRNC Serving RNC
PTM Point-To-Multipoint SSCOP Service Specific Connection Oriented
PTP Precision Timing Protocol Protocol
SSCP Signaling Connection Control Part
Q STM Synchronous Transfer Mode
QoS Quality of Service STTD Space Time transmit diversity
QPSK Quadrature Phase Shift Keying SU Signalling Unit
R
R5 Release 5
R’99 Release ’99
RA Routing Area
RAB Radio Access Bearer
RAC Routing Area Code
RAC Radio Admission control
RACH Random Access Channel
RLC Radio Link Control
RNC Radio Network Controller
RNO Radio Network Optimiser
RNS Radio Network Sub-System
RNSAP RNS Application Part
RNTI Radio Network Temporary Identity
RP Reporting Period

T Switch to notes view!

TC Transcoder V
TC Transmission Convergence (ATM) VC Virtual Channel
TCP Transport Control Protocol VCI Virtual Channel Identifier
TD-CDMA Time Division & CDMA VHE Virtual Home Environment
TDD Time Division Duplex VLR Visitor Location Register
TDMA Time Division Multiple Access VoIP Voice over IP
TEU Transmitter Equipment UMTS VP Virtual Path
TF Transport Format VPI Virtual Path Identifier
TFC Transport Format Combination VSWR Voltage Standing Wave Ratio
TFCI Transport Format Combination Indicator
TFCS Transport Format Combination Set W
TFRC Transport Format Resource Combination W3C World Wide Web Consortium
TFRI Transport Format Resource Indicator WAP Wireless Application Protocol
TFS Transport Format Set W-CDMA Wide-band Code Division Multiple
TIA Telecommunication Industry Association Access
(USA) WIM WAP Identity Module
TMA Tower Mounted Amplifier
TMN Telecommunication Management X
Network XML Extensible Mark-up Language
TMSI Temporary Mobile Subscriber Identify
TPA Transmit Power Amplifier
TPC 5 6 Transmission Power Control All Rights Reserved © Alcatel-Lucent 2010
Query Language for semi-structured is This page left blank intentionally

Glossary
TQL 9300 WCDMA TMO18246 9300 WCDMA UAO7 R99 Radio Principles data
TRE Transceiver Equipment (GSM)
TRX Transceiver (UMTS V1)
TS Tunning Session
TSAL Tunning Session Application Log
TSTD Time Switch Transmit Diversity
TTA Telecommunication Technology
Association (Korea)
TTI Transmission Time Interval
U
UARFCN UTRA Absolute Radio Frequency Channel
Number
UDP User Datagram Protocol
UE User Equipment
UICC UMTS Integrated Circuit Card
UL Uplink
UMTS Universal Mobile Telecommunication
System
URA UTRAN Registration Area
USB Universal Serial Bus
USIM UMTS Subscriber Identity Card
USM User Service Manager
USSD Unstructured Supplementary Service Data
UTRA UMTS Radio Access Network (ETSI)
UTRA Universal Radio Access Network (3GPP)
UTRAN UMTS Terrestrial Radio Access Network
UWCC Universal Wireless Communications
Committee

Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent @@YEAR
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 2

Radio Principle PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radio Principle PDF

Uploaded by

Copyright:

Available Formats

9300 WCDMA

TMO18246 9300 WCDMA UAO7

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

2 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

3. Topic/Section is Positioned Here

5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Welcome to TMO18246 9300 WCDMA UAO7 R99 Radio Principles

Upon completion of this course, you should be able to:

Upon completion of this course, you should be able to:

7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

9 All Rights Reserved © Alcatel-Lucent 2010

Where you can get further information

If you want further information you can refer to the following:

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

12 All Rights Reserved © Alcatel-Lucent 2010

Edition Date Author Remarks

03 2007-06-21 Scholle, Martin Conversion into Alcatel-Lucent template

04 2010-05-05 Nolan, Vincent Update to UA07

All Rights Reserved © Alcatel-Lucent 2010

To be able to draw the UTRAN architecture with the

13 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Logical Architecture Common Transport Channels Page

All Rights Reserved © Alcatel-Lucent 2010

16 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Access Network MSC Server Core Network CS Links External Networks

UTRAN Iu-CS PSTN

12 All Rights Reserved © Alcatel-Lucent 2010

13 All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

16 All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

18 All Rights Reserved © Alcatel-Lucent 2010

19 All Rights Reserved © Alcatel-Lucent 2010

1 10 All Rights Reserved © Alcatel-Lucent 2010

1 11 All Rights Reserved © Alcatel-Lucent 2010

1 13 All Rights Reserved © Alcatel-Lucent 2010

1 16 All Rights Reserved © Alcatel-Lucent 2010

1 17 All Rights Reserved © Alcatel-Lucent 2010

1 18 All Rights Reserved © Alcatel-Lucent 2010

1 19 All Rights Reserved © Alcatel-Lucent 2010

1 20 All Rights Reserved © Alcatel-Lucent 2010

1 21 All Rights Reserved © Alcatel-Lucent 2010

1 22 All Rights Reserved © Alcatel-Lucent 2010

1 23 All Rights Reserved © Alcatel-Lucent 2010

1 25 All Rights Reserved © Alcatel-Lucent 2010

1 26 All Rights Reserved © Alcatel-Lucent 2010

1 27 All Rights Reserved © Alcatel-Lucent 2010