Understanding - UMTS Training - Manual Motorola PDF

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5
INTRODUCTION NETWORK ARCHITECTURE NETWORK SERVICES UMTS PROTOCOLS DATA FLOW &
TERRESTRIAL INTERFACES
CHAPTER 6 CHAPTER 7 CHAPTER 8 CHAPTER 9 CHAPTER 10
W-CDMA THEORY THE PHYSICAL LAYER USER EQUIPMENT MANAGEMENT FUNCTIONS SIGNALLING FLOW
APPENDIX A APPENDIX B APPENDIX C APPENDIX D
Understanding UMTS
CP13 Issue 4 Revision 0
Training Manual
FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

CP13
Issue 4 Revision 0
Training Manual
Understanding UMTS
Understanding
UMTS
CP13
Training
Positin mark for TED spine
Manual
Issue 4 Revision 0
FOR TRAINING
PURPOSES ONLY – THIS
MANUAL WILL NOT BE
UPDATED
Issue 4 Revision 0
CP13
Understanding UMTS
Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
All Rights Reserved
Printed in the U.K.
CP13: Understanding UMTS

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL i
NOT BE UPDATED
Issue 4 Revision 0
Copyrights, notices and trademarks
Copyrights
The Motorola products described in this document may include copyrighted Motorola computer
programs stored in semiconductor memories or other media. Laws in the United States and other
countries preserve for Motorola certain exclusive rights for copyright computer programs, including the
exclusive right to copy or reproduce in any form the copyright computer program. Accordingly, any
copyright Motorola computer programs contained in the Motorola products described in this document
may not be copied or reproduced in any manner without the express written permission of Motorola.
Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by
implication, estoppel or otherwise, any license under the copyrights, patents or patent applications of
Motorola, except for the rights that arise by operation of law in the sale of a product.
Restrictions
The software described in this document is the property of Motorola. It is furnished under a license
agreement and may be used and/or disclosed only in accordance with the terms of the agreement.
Software and documentation are copyright materials. Making unauthorized copies is prohibited by
law. No part of the software or documentation may be reproduced, transmitted, transcribed, stored
in a retrieval system, or translated into any language or computer language, in any form or by any
means, without prior written permission of Motorola.
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola
assumes no liability resulting from any inaccuracies or omissions in this document, or from the use
of the information obtained herein. Motorola reserves the right to make changes to any products
described herein to improve reliability, function, or design, and reserves the right to revise this
document and to make changes from time to time in content hereof with no obligation to notify any
person of revisions or changes. Motorola does not assume any liability arising out of the application
or use of any product or circuit described herein; neither does it convey license under its patent
rights of others.
Trademarks
and MOTOROLA are trademarks of Motorola Inc.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through
X/Open Company Limited.
Tandem, Integrity, Integrity S2, and Non-Stop-UX are trademarks of Tandem Computers
Incorporated.
X Window System, X and X11 are trademarks of the Massachusetts Institute of Technology.
Looking Glass is a registered trademark of Visix Software Ltd.
OSF/Motif is a trademark of the Open Software Foundation.
Ethernet is a trademark of the Xerox Corporation.
Wingz is a trademark and INFORMIX is a registered trademark of Informix Software Ltd.
SUN, SPARC, and SPARCStation are trademarks of Sun Microsystems Computer Corporation.
IBM is a registered trademark of International Business Machines Corporation.
HP is a registered trademark of Hewlett Packard Inc.
ii FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Important notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
First aid in case of electric shock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Reporting safety issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Warnings and cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
General warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Human exposure to radio frequency energy (PCS1900 only) . . . . . . . . . . . . . . . . . . . . . . 8
Beryllium health and safety precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
General cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Devices sensitive to static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Motorola GSM manual set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Generic manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tandem OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Scaleable OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Related manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Service manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Category number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Catalogue number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Ordering manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
UMTS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Network Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Future Data Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
IMT-2000 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
UMTS Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
World-wide Spectrum Allocation for IMT-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Frequency Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
Licence Allocation in the UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–18
Chapter 2
Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
UMTS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
UMTS Architecture – R99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
The Core Network (CN) Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
The Access Network (AN) Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
The Mobile Station (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL iii
NOT BE UPDATED
Issue 4 Revision 0
UMTS Network – R99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10

Entities of the CN–CS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10
Entities Common to the CS and PS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
Entities of the CN-CS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
Serving GPRS Support Node (SGSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
Gateway GPRS Support Node (GGSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
SS7 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Integrated Support Server (ISS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Core Router (CommHub) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
UMTS Terrestrial Radio Access Network (UTRAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18
UTRAN Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18
Radio network Controller Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Controlling Radio Network Controller (CRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Serving Radio Network Controller (SRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
Drift Radio Network Controller (DRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–24
Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
Wideband Digital Modem (WDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
The Wideband Transceiver (WBX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
Linear Power Amplifier (LPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
User Equipment (UE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–28
Product evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–30
Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–32
Release 4/5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
MSC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
Gateway MSC Server (GMSC Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
Circuit Switched – Media Gateway Function (CS-MGW). . . . . . . . . . . . . . . . . . . . 2–34
The Home Subscriber Server (HSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Transport Signalling Gateway Function (T-SGW) . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Roaming Signalling Gateway Function (R-SGW) . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Chapter 3
Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Introduction to Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Classification of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Circuit Teleservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Circuit Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Supplementary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Packet Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Other Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Value Added Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
IP multimedia services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Interactive Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Distribution services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Architectural Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Service Node and Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
iv FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
Service Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12

Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
Data Determination for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
QoS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
The Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Distribution of authentication data from HE to SN . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Ciphering Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
F8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
F9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
Generation of Authentication Vectors/Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
SQN and RAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Authentication Key Management Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Algorithms f1 –f5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
AUTN and AV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
USIM Authentication Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Retrieval of SQN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Computation of X–MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Verification of SQN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Computation of CK and IK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
User Authentication Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Access Link Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
Data integrity protection method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
Input parameters to the integrity algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
Ciphering of User/Signalling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38
Input parameters to the cipher algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38
Chapter 4
UMTS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
General Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Horizontal Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Vertical Planes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
IuCS Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
Transport Network Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
IuPS Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Iub Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL v
NOT BE UPDATED
Issue 4 Revision 0
Iur Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10

Radio Interface Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
MAC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
MAC Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
MAC Layer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Mapping between logical and Transport channels . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Transport format selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Priority handling of Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Dynamic Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Identification of UEs on Common Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
MUX/DEMUX of PDUs into Transport Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Traffic Volume Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Dynamic Transport Channel Type Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Access Service Class Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
RLC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
RLC Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Transparent Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Transmitting Tr Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Receiving Tr Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Unacknowledged Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Transmitting UM Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Receiving UM Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Acknowledged Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Packet Data Convergence Protocol (PDCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28
Radio Interface for Broadcast/Multicast Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
BMC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
RRC Layer Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Routing Function Entity (RFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Broadcast Control Function Entity (BCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Paging and Notification Control Function Entity (PNFE) . . . . . . . . . . . . . . . . . . . . 4–32
Dedicated Control Function Entity (DCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Shared Control Function Entity (SCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Transfer Mode Entity (TME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
RRC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
User Plane Protocol Stack (Dedicated Channels CS–Domain) . . . . . . . . . . . . . . . 4–38
Dedicated Channel Frame Protocol (DCH FP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
Control Plane Protocol Stack (UE–CN SIGNALLING, Dedicated Channels, CS–Domain) . . . . . .
4–42
RANAP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
MTP3–B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
SAAL–NNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
vi FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
Control Plane Protocol Stack

(UE–CN Signalling, Shared Channels, CS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
RACH/FACH/ DSCH Frame Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
User Plane Protocol Stack
(Dedicated Channels, PS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
GPRS Tunnelling Protocol, User Plane (GTP–U) . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Path Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
(UE–CN Siganalling, Dedicated Channels, PS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
Stream Control Transmission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
Chapter 5
Data Flow and Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
ATM Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Asynchronous Transfer Mode (ATM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6
ATM Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
ATM Adaptation Layers (AALs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
The ATM Adaptation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Convergence Sub–Layer (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Segmentation and Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
ATM Adaptation Layer 2 (AAL2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
CPCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
ATM Adaptation Layer 5 (AAL 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
Virtual Channels and Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Use of Virtual Channels and Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Virtual Connection and Path Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
E1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Logical Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
ATM Cell to E1 Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–24
E Link Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Inverse Multiplexing for ATM (IMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Plesiochronous Digital Hierarchy (PDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–30
Synchronous Digital Hierarchy (SDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
Principles of SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
SDH Drop and Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Network Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Software Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Bandwidth on Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
ATM to STM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–38
Typical UMTS Transport Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–40

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL vii
NOT BE UPDATED
Issue 4 Revision 0
Chapter 6
W-CDMA Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Multiple Access Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
CDMA Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
W-CDMA Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–6
Re-Use of Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Re–Use of Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–12
Spectral Efficiency (GSM and IS-95) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
Spectral Efficiency – UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
TDD and FDD Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
FDD and TDD Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–20
DS-CDMA Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Scrambling Codes vs Channelisaton Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Modulo-2 Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Orthogonal Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–30
Channelisation Code Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Processing Gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Exercise 1 - Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–36
Short Codes vs Long Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Matched Filter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
The Rake Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46
Chapter 7
The Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
Physical Layer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
QPSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Channel Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
Structure of Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Downlink Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Uplink Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Channels on the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
viii FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14

Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Common Physical Channels (CPCHs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Channel Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
Physical signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
Generic Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Radio Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
System Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Timeslot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Synchronisation Channel (SCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
The Primary SCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
The Secondary SCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Modulation Symbol “a” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Synchronisation (Cell Search) Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Step 1: Slot synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Step 2: Frame synchronisation and code–group identification . . . . . . . . . . . . . . . 7–24
Step 3: Scrambling–code identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–25
Common Pilot Channel (CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Primary Common Pilot Channel (P-CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Secondary Common Pilot Channel (S-CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Modulation pattern for Common Pilot Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–27
P-CCPCH Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–28
SCH and P-CCPCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–30
Paging Indicator Channel (PICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–32
Mapping of Paging Indicators (PI) to PICH bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–33
Secondary Common Control Physical Channel (S–CCPCH) . . . . . . . . . . . . . . . . . . . . . . 7–34
Secondary CCPCH Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–35
Random Access Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
Structure of Random Access Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
PRACH Pre–amble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
Structure of the random–access transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–37
Acquisition Indicator Channel AICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–38
AICH signature patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–39
Structure of PRACH Message Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–40
Random–access message data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–41
Dedicated downlink physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–42
Downlink Slot Formation in Case of Multi-Code Transmission . . . . . . . . . . . . . . . . . . . . . 7–44
Uplink Dedicated Physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–46
Downlink Flow Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–48
Channel Coding Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–50
CRC Attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–50
Transport block concatenation and code block segmentation . . . . . . . . . . . . . . . . 7–50
Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–52
Convolutional Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–52
Rate 1/2 and rate 1/3 convolutional coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–53

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL ix
NOT BE UPDATED
Issue 4 Revision 0
Turbo coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–54

Rate Matching & Insertion of DTX Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Rate Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Insertion of DTX Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Fixed And Flexible Bit Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–57
1ST Interleaving and Radio Frame Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–58
Transport Channel Multiplexing and Physical Layer Segmentation . . . . . . . . . . . . . . . . . 7–60
2nd insertion of DTX Indication bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
Physical Layer Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
2nd Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
Downlink Spreading and Channel Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–62
Channel Combining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–62
Uplink Flow Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Radio Frame Equalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Rate Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Uplink Spreading and Channel Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–66
PRACH Message Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–66
PRACH Spreading and Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–67
Chapter 8
User Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Mobile States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
UE Power Classes and Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Frequency Band and RF Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Channel Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Chapter 9
Radio Resource Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–1
Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–2
Physical Layer Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
UE Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
UTRA Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–6
Compressed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–8
Cell Selection/Re–selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Immediate Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Cell Re–selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Macro Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–12
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
Handover Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
Handover Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
x FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
Soft and Softer Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16

S-RNS Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–18
Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–20
Site Selection Diversity Power Control (SSDT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–20
Open Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–22
Closed Loop Power Control (Inner Loop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–24
Closed Loop Power Control (Outer Loop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–26
Multi-Cell Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–28
Site Select Diversity Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–30
Space Time Transmit Diversity (STTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–32
STTD Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–34
Closed Loop Mode Transmit diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–36
Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
System Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
Load Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–40
Chapter 10
Signalling Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–1
Paging for a UE in Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
Paging for the UE in RRC Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
RRC Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–6
RRC DCH Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–8
RA Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–10
SRNC Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–12
Chapter 11
Appendix A
. ................................................................... i
Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–1
Chapter 12
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Multiple Choice Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1
Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
Chapter 13
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
CDMA Detection Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–1

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL xi
NOT BE UPDATED
Issue 4 Revision 0
Chapter 14
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Glossary of Terms for the Universal Mobile Telecommunication System . . . . . . . . . . . . 14–1
A ................................................................... 14–11
B ................................................................... 14–11
C ................................................................... 14–12
D ................................................................... 14–13
E ................................................................... 14–13
F.................................................................... 14–13
G ................................................................... 14–13
H ................................................................... 14–14
I .................................................................... 14–14
J .................................................................... 14–14
K ................................................................... 14–14
L .................................................................... 14–14
M ................................................................... 14–15
N ................................................................... 14–15
O ................................................................... 14–15
P ................................................................... 14–16
Q ................................................................... 14–16
R ................................................................... 14–17
S ................................................................... 14–18
T.................................................................... 14–19
U ................................................................... 14–19
V ................................................................... 14–20
W ................................................................... 14–20
Chapter 15
Glossary of technical terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . i
Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15–1
A ......................................................................... 15–2
B ......................................................................... 15–3
C ......................................................................... 15–4
D ......................................................................... 15–6
E ......................................................................... 15–7
F ......................................................................... 15–8
G ......................................................................... 15–9
H ......................................................................... 15–10
I .......................................................................... 15–11
K ......................................................................... 15–12
L ......................................................................... 15–13
M ......................................................................... 15–14
N ......................................................................... 15–15
O ......................................................................... 15–16
P ......................................................................... 15–17
Q ......................................................................... 15–18
xii FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0
R . ........................................................................ 15–19
S ......................................................................... 15–20
T ......................................................................... 15–21
U ......................................................................... 15–22
V ......................................................................... 15–23
W ........................................................................ 15–24
X ......................................................................... 15–25
Y ......................................................................... 15–26
Z ......................................................................... 15–27

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL xiii
NOT BE UPDATED
Issue 4 Revision 0
xiv FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0 General information
General information
Important notice
If this manual was obtained when you attended a Motorola training course, it will not be
updated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If it
was supplied under normal operational circumstances, to support a major software
release, then corrections will be supplied automatically by Motorola in the form of
General Manual Revisions (GMRs).
Purpose
Motorola Global System for Mobile Communications (GSM) Technical Education manuals
are intended to support the delivery of Technical Education only and are not intended to
replace the use of Customer Product Documentation.
WARNING
Failure to comply with Motorola’s operation, installation and maintenance
instructions may, in exceptional circumstances, lead to serious injury or death.
These manuals are not intended to replace the system and equipment training offered by
Motorola, although they can be used to supplement and enhance the knowledge gained
through such training.
About this
manual

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL 1
NOT BE UPDATED
General information Issue 4 Revision 0
Cross references
Throughout this manual, cross references are made to the chapter numbers and section
names. The section name cross references are printed bold in text.
This manual is divided into uniquely identified and numbered chapters that, in turn, are
divided into sections. Sections are not numbered, but are individually named at the top
of each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola GSM manuals to represent keyboard
input text, screen output text and special key sequences.
Input
Characters typed in at the keyboard are shown like this.
Output
Messages, prompts, file listings, directories, utilities, and environmental
variables that appear on the screen are shown like this.
Special key sequences

Special key sequences are represented as follows:
CTRL-c Press the Control and c keys at the same time.

ALT-f Press the Alt and f keys at the same time.
| Press the pipe symbol key.
CR or RETURN Press the Return (Enter) key. The Return key is
identified with the ↵ symbol on both the X terminal and
the SPARCstation keyboards. The SPARCstation
keyboard Return key is also identified with the word
Return.
2 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0 First aid in case of electric shock
First aid in case of electric shock
Warning
WARNING
Do not touch the victim with your bare hands until the electric circuit is
broken.
Switch off. If this is not possible, protect yourself with dry insulating
material and pull or push the victim clear of the conductor.
Artificial
respiration
In the event of an electric shock it may be necessary to carry out artificial respiration.
Send for medical assistance immediately.
Burns treatment
A warning is used to alert the reader to possible hazards that could cause loss of life,
physical injury, or ill health. This includes hazards introduced during maintenance, for
example, the use of adhesives and solvents, as well as those inherent in the equipment.
1. Do not attempt to remove clothing adhering to the burn.
2. If help is available, or as soon as artificial respiration is no longer required, cover
the wound with a dry dressing.
3. Do not apply oil or grease in any form.

NOT BE UPDATED
Reporting safety issues Issue 4 Revision 0
Reporting safety issues
Introduction
A caution means that there is a possibility of damage to systems, or individual items of
equipment within a system. However, this presents no danger to personnel.
Procedure
Whenever a safety issue arises:
1. Make the equipment concerned safe, for example, by removing power.
2. Make no further attempt to tamper with the equipment.
3. Report the problem directly to GSM Customer Network Resolution Centre
+44 (0)1793 430040 (telephone) and follow up with a written report by fax
+44 (0)1793 430987 (fax).
4. Collect evidence from the equipment under the guidance of the Customer Network
Resolution Centre.
NOT BE UPDATED
Issue 4 Revision 0 Warnings and cautions
Warnings and cautions
Introduction
The following describes how warnings and cautions are used in this manual and in all
manuals of the Motorola GSM manual set.
Warnings
Definition
A warning is used to alert the reader to possible hazards that could cause loss of life,
physical injury, or ill health. This includes hazards introduced during maintenance, for
example, the use of adhesives and solvents, as well as those inherent in the equipment.
Example and format
WARNING
Do not look directly into fibre optic cables or optical data in/out connectors.
Laser radiation can come from either the data in/out connectors or
unterminated fibre optic cables connected to data in/out connectors.
Cautions
Definition
A caution means that there is a possibility of damage to systems, or individual items of
equipment within a system. However, this presents no danger to personnel.
Example and format
CAUTION
Do not use test equipment that is beyond its calibration due date when testing
Motorola base stations.

NOT BE UPDATED
General warnings Issue 4 Revision 0
General warnings
Introduction
Observe the following warnings during all phases of operation, installation and
maintenance of the equipment described in the Motorola GSM manuals. Failure to
comply with these warnings, or with specific warnings elsewhere in the Motorola GSM
manuals, violates safety standards of design, manufacture and intended use of the
equipment. Motorola assumes no liability for the customer’s failure to comply with these
requirements.
Warning labels
Personnel working with or operating Motorola equipment must comply with any warning
labels fitted to the equipment. Warning labels must not be removed, painted over or
obscured in any way.
Specific
warnings
Warnings particularly applicable to the equipment are positioned on the equipment and
within the text of this manual. These must be observed by all personnel at all times when
working with the equipment, as must any other warnings given in text, on the illustrations
and on the equipment.
High voltage
Certain Motorola equipment operates from a dangerous high voltage of 230 V ac single
phase or 415 V ac three phase mains which is potentially lethal. Therefore, the areas
where the ac mains power is present must not be approached until the warnings and
cautions in the text and on the equipment have been complied with.
To achieve isolation of the equipment from the ac supply, the mains input isolator must
be set to off and locked.
Within the United Kingdom (UK) regard must be paid to the requirements of the
Electricity at Work Regulations 1989. There may also be specific country legislation
which need to be complied with, depending on where the equipment is used.
RF radiation
High RF potentials and electromagnetic fields are present in the base station equipment
when in operation. Ensure that all transmitters are switched off when any antenna
connections have to be changed. Do not key transmitters connected to unterminated
cavities or feeders.
Refer to the following standards:
ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to Human
Exposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields High
Frequency (10kHz to 300GHz).
Laser radiation
Do not look directly into fibre optic cables or optical data in/out connectors. Laser
radiation can come from either the data in/out connectors or unterminated fibre optic
cables connected to data in/out connectors.
NOT BE UPDATED
Issue 4 Revision 0 General warnings
Lifting
equipment
When dismantling heavy assemblies, or removing or replacing equipment, the competent
responsible person must ensure that adequate lifting facilities are available. Where
provided, lifting frames must be used for these operations. When equipments have to be
manhandled, reference must be made to the Manual Handling of Loads Regulations
1992 (UK) or to the relevant manual handling of loads legislation for the country in which
the equipment is used.
Do not ...
... substitute parts or modify equipment.
Because of the danger of introducing additional hazards, do not install substitute parts or
perform any unauthorized modification of equipment. Contact Motorola if in doubt to
ensure that safety features are maintained.
Battery supplies
Do not wear earth straps when working with standby battery supplies.
Toxic material
Certain Motorola equipment incorporates components containing the highly toxic material
Beryllium or its oxide Beryllia or both. These materials are especially hazardous if:
Beryllium materials are absorbed into the body tissues through the skin, mouth, or
a wound.
The dust created by breakage of Beryllia is inhaled.
Toxic fumes are inhaled from Beryllium or Beryllia involved in a fire.
See the Beryllium health and safety precautions section for further information.

NOT BE UPDATED
Human exposure to radio frequency energy (PCS1900 only) Issue 4 Revision 0
Human exposure to radio frequency energy (PCS1900 only)

Introduction
This equipment is designed to generate and radiate radio frequency (RF) energy. It
should be installed and maintained only by trained technicians. Licensees of the Federal
Communications Commission (FCC) using this equipment are responsible for insuring
that its installation and operation comply with FCC regulations designed to limit human
exposure to RF radiation in accordance with the American National Standards Institute
IEEE Standard C95.1-1991, IEEE Standard for Safety Levels with Respect to Human
Exposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
Definitions
This standard establishes two sets of maximum permitted exposure limits, one for
controlled environments and another, that allows less exposure, for uncontrolled
environments. These terms are defined by the standard, as follows:
Uncontrolled environment
Uncontrolled environments are locations where there is the exposure of individuals who
have no knowledge or control of their exposure. The exposures may occur in living
quarters or workplaces where there are no expectations that the exposure levels may
exceed those shown for uncontrolled environments in the table of maximum permitted
exposure ceilings.
Controlled environment
Controlled environments are locations where there is exposure that may be incurred by
persons who are aware of the potential for exposure as a concomitant of employment, by
other cognizant persons, or as the incidental result of transient passage through areas
where analysis shows the exposure levels may be above those shown for uncontrolled
environments but do not exceed the values shown for controlled environments in the
table of maximum permitted exposure ceilings.
Maximum
permitted
exposures
The maximum permitted exposures prescribed by the standard are set in terms of
different parameters of effects, depending on the frequency generated by the equipment
in question. At the frequency range of this Personal Communication System equipment,
1930-1970MHz, the maximum permitted exposure levels are set in terms of power
density, whose definition and relationship to electric field and magnetic field strengths are
described by the standard as follows:
Power density (S)

Power per unit area normal to the direction of propagation, usually expressed in units of
watts per square metre (W/m2) or, for convenience, units such as milliwatts per square
centimetre (mW/cm2). For plane waves, power density, electric field strength (E) and
magnetic field strength (H) are related by the impedance of free space, 377 ohms. In
particular,

where E and H are expressed in units of V/m and A/m, respectively, and S in units of
W/m 2. Although many survey instruments indicate power density units, the actual
quantities measured are E or E2 or H or H2.
NOT BE UPDATED
Issue 4 Revision 0 Human exposure to radio frequency energy (PCS1900 only)
Maximum
permitted
exposure
ceilings
Within the frequency range, the maximum permitted exposure ceiling for uncontrolled
environments is a power density (mW/cm2) that equals f/1500, where f is the frequency
expressed in MHz, and measurements are averaged over a period of 30 minutes. The
maximum permitted exposure ceiling for controlled environments, also expressed in
mW/cm 2, is f/300 where measurements are averaged over 6 minutes. Applying these
principles to the minimum and maximum frequencies for which this equipment is intended
to be used yields the following maximum permitted exposure levels:
Uncontrolled Environment Controlled Environment

1930MHz 1970MHz 1930MHz 1970MHz
Ceiling 1.287mW/cm 2 1.313mW/cm 2 6.433mW/cm 2 6.567mW/cm 2
If you plan to operate the equipment at more than one frequency, compliance should be
assured at the frequency which produces the lowest exposure ceiling (among the
frequencies at which operation will occur).
Licensees must be able to certify to the FCC that their facilities meet the above ceilings.
Some lower power PCS devices, 100 milliwatts or less, are excluded from demonstrating
compliance, but this equipment operates at power levels orders of magnitude higher, and
the exclusion is not applicable.
Whether a given installation meets the maximum permitted exposure ceilings depends, in
part, upon antenna type, antenna placement and the output power to which this
equipment is adjusted. The following example sets forth the distances from the antenna
to which access should be prevented in order to comply with the uncontrolled and
controlled environment exposure limits as set forth in the ANSI IEEE standards and
computed above.

NOT BE UPDATED
Human exposure to radio frequency energy (PCS1900 only) Issue 4 Revision 0
Example
calculation
For a base station with the following characteristics, what is the minimum distance from
the antenna necessary to meet the requirements of an uncontrolled environment?
Transmit frequency 1930MHz
Base station cabinet output power, P +39.0dBm (8 watts)
Antenna feeder cable loss, CL 2.0dB
Antenna input power Pin P–CL = +39.0–2.0 = +37.0dB (5watts)
Antenna gain, G 16.4dBi (43.65)
Using the following relationship:

Where W is the maximum permissible power density in W/m2 and r is the safe distance
from the antenna in metres, the desired distance can be calculated as follows:

where W = 12.87 W/m2 was obtained from table listed above and converting from
mW/cm 2 to W/m2.
NOTE
The above result applies only in the direction of maximum radiation of the
antenna. Actual installations may employ antennas that have defined radiation
patterns and gains that differ from the example set forth above. The distances
calculated can vary depending on the actual antenna pattern and gain.
Power density
measurements
While installation calculations such as the above are useful and essential in planning and
design, validation that the operating facility using this equipment actually complies will
require making power density measurements. For information on measuring RF fields for
determining compliance with ANSI IEEE C95.1-1991, see IEEE Recommended Practice
for the Measure of Potentially Hazardous Electromagnetic Fields - RF and Microwave,
IEEE Std C95.3-1991. Copies of IEEE C95.1-1991 and IEEE C95.3-1991 may be
purchased from the Institute of Electrical and Electronics Engineers, Inc., Attn:
Publication Sales, 445 Hoes Lane, P.O. Box 1331, Piscattaway, NJ 08855-1331,
(800) 678-IEEE or from ANSI, (212) 642-4900. Persons responsible for installation of this
equipment are urged to consult these standards in determining whether a given
installation complies with the applicable limits.
Other equipment
Whether a given installation meets ANSI standards for human exposure to radio
frequency radiation may depend not only on this equipment but also on whether the
environments being assessed are being affected by radio frequency fields from other
equipment, the effects of which may add to the level of exposure. Accordingly, the overall
exposure may be affected by radio frequency generating facilities that exist at the time
the licensee’s equipment is being installed or even by equipment installed later.
Therefore, the effects of any such facilities must be considered in site selection and in
determining whether a particular installation meets the FCC requirements.
NOT BE UPDATED
Issue 4 Revision 0 Beryllium health and safety precautions
Beryllium health and safety precautions
Introduction
Beryllium (Be), is a hard silver/white metal. It is stable in air, but burns brilliantly in
Oxygen.
With the exception of the naturally occurring Beryl ore (Beryllium Silicate), all Beryllium
compounds and Beryllium metal are potentially highly toxic.
Health issues
Beryllium Oxide is used within some components as an electrical insulator. Captive within
the component it presents no health risk whatsoever. However, if the component should
be broken open and the Beryllium Oxide, which is in the form of dust, released, there
exists the potential for harm.
Inhalation
Inhalation of Beryllium Oxide can lead to a condition known as Berylliosis, the symptoms
of Berylliosis are similar to Pneumonia and may be identified by all or any of the
following:
Mild poisoning causes fever, shortness of breath, and a cough that produces
yellow/green sputum, or occasionally bloodstained sputum. Inflammation of the mucous
membranes of the nose, throat, and chest with discomfort, possibly pain, and difficulty
with swallowing and breathing.
Severe poisoning causes chest pain and wheezing which may progress to severe
shortness of breath due to congestion of the lungs. Incubation period for lung symptoms
is 2-20 days.
Exposure to moderately high concentrations of Beryllium in air may produce a very
serious condition of the lungs. The injured person may become blue, feverish with rapid
breathing and raised pulse rate. Recovery is usual but may take several months. There
have been deaths in the acute stage.
Chronic response. This condition is more truly a general one although the lungs are
mainly affected. There may be lesions in the kidneys and the skin. Certain features
support the view that the condition is allergic. There is no relationship between the
degree of exposure and the severity of response and there is usually a time lag of up to
10 years between exposure and the onset of the illness. Both sexes are equally
susceptible. The onset of the illness is insidious but only a small number of exposed
persons develop this reaction.
First aid
Seek immediate medical assistance. The casualty should be removed immediately from
the exposure area and placed in a fresh air environment with breathing supported with
Oxygen where required. Any contaminated clothing should be removed. The casualty
should be kept warm and at rest until medical aid arrives.

NOT BE UPDATED
Beryllium health and safety precautions Issue 4 Revision 0
Skin contact
Possible irritation and redness at the contact area. Persistent itching and blister
formations can occur which usually resolve on removal from exposure.
First aid
Wash area thoroughly with soap and water. If skin is broken seek immediate medical
assistance.
Eye contact
May cause severe irritation, redness and swelling of eyelid(s) and inflammation of the
mucous membranes of the eyes.
First aid
Flush eyes with running water for at least 15 minutes. Seek medical assistance as soon
as possible.
Handling
procedures
Removal of components from printed circuit boards (PCBs) is to take place only at
Motorola approved repair centres.
The removal station will be equipped with extraction equipment and all other protective
equipment necessary for the safe removal of components containing Beryllium Oxide.
If during removal a component is accidently opened, the Beryllium Oxide dust is to be
wetted into a paste and put into a container with a spatula or similar tool. The spatula/tool
used to collect the paste is also to be placed in the container. The container is then to be
sealed and labelled. A suitable respirator is to be worn at all times during this operation.
Components which are successfully removed are to be placed in a separate bag, sealed
and labelled.
Disposal
methods
Beryllium Oxide or components containing Beryllium Oxide are to be treated as
hazardous waste. All components must be removed where possible from boards and put
into sealed bags labelled Beryllium Oxide components. These bags must be given to the
safety and environmental adviser for disposal.
Under no circumstances are boards or components containing Beryllium Oxide to be put
into the general waste skips or incinerated.
Product life cycle

implications
Motorola GSM and analogue equipment includes components containing Beryllium Oxide
(identified in text as appropriate and indicated by warning labels on the equipment).
These components require specific disposal measures as indicated in the preceding
(Disposal methods) paragraph. Motorola will arrange for the disposal of all such
hazardous waste as part of its Total Customer Satisfaction philosophy and will arrange
for the most environmentally ‘friendly’ disposal available at that time.
NOT BE UPDATED
Issue 4 Revision 0 General cautions
General cautions
Introduction
Observe the following cautions during operation, installation and maintenance of the
equipment described in the Motorola GSM manuals. Failure to comply with these
cautions or with specific cautions elsewhere in the Motorola GSM manuals may result in
damage to the equipment. Motorola assumes no liability for the customer’s failure to
comply with these requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any caution
labels fitted to the equipment. Caution labels must not be removed, painted over or
obscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of this
manual. These must be observed by all personnel at all times when working with the
equipment, as must any other cautions given in text, on the illustrations and on the
equipment.
Fibre optics
The bending radius of all fibre optic cables must not be less than 30 mm.
Static discharge
Motorola equipment contains CMOS devices that are vulnerable to static discharge.
Although the damage caused by static discharge may not be immediately apparent,
CMOS devices may be damaged in the long term due to static discharge caused by
mishandling. Wear an approved earth strap when adjusting or handling digital boards.
See Devices sensitive to static for further information.

NOT BE UPDATED
Devices sensitive to static Issue 4 Revision 0
Devices sensitive to static
Introduction
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer of
insulation that is susceptible to damage from electrostatic charge. Such a charge applied
to the leads of the device could cause irreparable damage.
These charges can be built up on nylon overalls, by friction, by pushing the hands into
high insulation packing material or by use of unearthed soldering irons.
MOS devices are normally despatched from the manufacturers with the leads shorted
together, for example, by metal foil eyelets, wire strapping, or by inserting the leads into
conductive plastic foam. Provided the leads are shorted it is safe to handle the device.
Special handling
techniques
In the event of one of these devices having to be replaced observe the following
precautions when handling the replacement:
Always wear an earth strap which must be connected to the electrostatic point
(ESP) on the equipment.
Leave the short circuit on the leads until the last moment. It may be necessary to
replace the conductive foam by a piece of wire to enable the device to be fitted.
Do not wear outer clothing made of nylon or similar man made material. A cotton
overall is preferable.
If possible work on an earthed metal surface. Wipe insulated plastic work surfaces
with an anti-static cloth before starting the operation.
All metal tools should be used and when not in use they should be placed on an
earthed surface.
Take care when removing components connected to electrostatic sensitive
devices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally less
susceptible to electrostatic damage. However PCBs should be handled with care,
preferably by their edges and not by their tracks and pins, they should be transferred
directly from their packing to the equipment (or the other way around) and never left
exposed on the workbench.
NOT BE UPDATED
Issue 4 Revision 0 Motorola GSM manual set
Motorola GSM manual set
Introduction
The following manuals provide the information needed to operate, install and maintain the
Motorola GSM equipment.
Generic manuals
The following are the generic manuals in the GSM manual set, these manuals are
release dependent:
Category Name Catalogue

number number
GSM-100-101 System Information: General 68P02901W01
GSM-100-201 Operating Information: GSM System Operation 68P02901W14
GSM-100-311 Technical Description: OMC in a GSM System 68P02901W31
GSM-100-313 Technical Description: OMC Database Schema 68P02901W34
GSM-100-320 Technical Description: BSS Implementation 68P02901W36
GSM-100-321 Technical Description: BSS Command 68P02901W23
Reference
GSM-100-403 Installation & Configuration: GSM System 68P02901W17
Configuration
GSM-100-423 Installation & Configuration: BSS Optimization 68P02901W43
GSM-100-501 Maintenance Information: Alarm Handling at 68P02901W26
the OMC
GSM-100-521 Maintenance Information: Device State 68P02901W57
Transitions
GSM-100-523 Maintenance Information: BSS Field 68P02901W51
Troubleshooting
GSM-100-503 Maintenance Information: GSM Statistics 68P02901W56
Application
GSM-100-721 Software Release Notes: BSS/RXCDR 68P02901W72
Tandem OMC
The following Tandem OMC manuals are part of the GSM manual set for systems
deploying Tandem S300 and 1475:

number number
GSM-100-202 Operating Information: OMC System 68P02901W13
Administration
GSM-100-712 Software Release Notes: OMC System 68P02901W71

NOT BE UPDATED
Motorola GSM manual set Issue 4 Revision 0
Scaleable OMC
The following Scaleable OMC manuals replace the equivalent Tandem OMC manuals in
the GSM manual set:

number number
GSM-100-202 Operating Information: Scaleable OMC System 68P02901W19
Administration
GSM-100-413 Installation & Configuration: Scaleable OMC 68P02901W47
Clean Install
GSM-100-712 Software Release Notes: Scaleable OMC 68P02901W74
System
Related manuals
The following are related Motorola GSM manuals:

number number
GSM-001-103 System Information: BSS Equipment Planning 68P02900W21
GSM-002-103 System Information: DataGen 68P02900W22
GSM-005-103 System Information: Advance Operational 68P02900W25
Impact
GSM-008-403 Installation & Configuration: Expert Adviser 68P02900W36
Service manuals
The following are the service manuals in the GSM manual set, these manuals are not
release dependent. The internal organization and makeup of service manual sets may
vary, they may consist of from one to four separate manuals, but they can all be ordered
using the overall catalogue number shown below:

number number
GSM-100-020 Service Manual: BTS 68P02901W37
GSM-100-030 Service Manual: BSC/RXCDR 68P02901W38
GSM-105-020 Service Manual: M-Cell2 68P02901W75
GSM-106-020 Service Manual: M-Cell6 68P02901W85
GSM-201-020 Service Manual: M-Cellcity 68P02901W95
GSM-202-020 Service Manual: M-Cellaccess 68P02901W65
GSM-101-SERIES ExCell4 Documentation Set 68P02900W50
GSM-103-SERIES ExCell6 Documentation Set 68P02900W70
GSM-102-SERIES TopCell Documentation Set 68P02901W80
GSM-200-SERIES M-Cellmicro Documentation Set 68P02901W90
NOT BE UPDATED
Issue 4 Revision 0 Motorola GSM manual set
Category number
The category number is used to identify the type and level of a manual. For example,
manuals with the category number GSM-100-2xx contain operating information.
Catalogue
number
The Motorola 68P catalogue number is used to order manuals.
Ordering
manuals
All orders for Motorola manuals must be placed with your Motorola Local Office or
Representative. Manuals are ordered using the catalogue number. Remember, specify
the manual issue required by quoting the correct suffix letter.

NOT BE UPDATED
Motorola GSM manual set Issue 4 Revision 0
NOT BE UPDATED
Chapter 1
Introduction

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
UMTS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Future Data Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
IMT-2000 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
UMTS Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
World-wide Spectrum Allocation for IMT-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Frequency Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
Licence Allocation in the UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–18

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 Objectives
Objectives
On completion of this chapter the student should be able to:
State the services to be provided by UMTS.
Describe the evolution of UMTS from 2G systems.
State the frequency allocations for UMTS.

MOTOROLA LTD. 2001 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL 1–1
NOT BE UPDATED
UMTS Services Issue 4 Revision 0
UMTS Services
UMTS will deliver voice, graphics, video and other broadband information direct to the
user, regardless of location, network or terminal. These fully personal communication
services will provide terminal and service mobility on fixed and mobile networks, taking
advantage of the convergence of existing and future fixed and mobile networks and the
potential synergies that can be derived from such convergence. The key benefits that
UMTS promises include improvements in quality and security, incorporating broadband
and networked multimedia services, flexibility in service creation and ubiquitous service
portability.
Networked multimedia includes services such as pay-TV; video and audio-on-demand;
interactive entertainment; educational and information services; and communication
services such as video-telephony and fast, large file transfer.
UMTS services are also likely to be used by other sectors, including systems with limited
mobility (e.g. in areas with low population density), and in private/corporate markets,
ranging from home use to wireless PBXs, emergency and cordless systems.
1–2 FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL MOTOROLA LTD. 2001
NOT BE UPDATED
Issue 4 Revision 0 UMTS Services
UMTS Services
· Voice
· Text
· Video
· Conferencing
· Internet
· Graphics
CP13_Ch1_02

NOT BE UPDATED
Network Evolution Issue 4 Revision 0
Network Evolution
Voice and data are converging and starting to be carried on the same networks, but
opinions vary on how quickly this is happening and what impact it will have on IT and
Telecommunications. Businesses are wondering what benefits it will bring and how soon
they should add voice to their data networks.
Today the volume of data in telecommunications networks has surpassed voice, Within 4
years the big US telecommunication companies are predicting that 99% of
telecommunication traffic will be data. Already there have been many merges,
acquisitions and alliances spanning telecommunications and IT as leading companies
jostle for position. One such example is the partnership between Motorola & CISCO.
Many of the recent merges and acquisitions have been brought about by
telecommunications equipment companies buying up the IT companies that make
Internet Protocol (IP) telephony products. These products allow data to be carried
cheaply over networks based on the IP protocol used on the internet. They can also be
used to carry Voice over IP (VoIP) by converting it into small packets of data. In this way
more voice calls can be sent down a single line. Examples of such acquisitions include
Alcatel buying Xylan, Nortel’s purchase of Bay Networks, Lucent acquiring Ascend and
Nokia buying Ipsilon.
It is estimated that full IP networks will not be deployed for 2 years. Some of the mission
elements include:
Voice gateways
End to end control
QoS support (except when sent over another standard e.g. ATM)
Network management facilities
One of the main benefits to the customer is that of reduced network infrastructure costs
because there will be no need for separate data and telecommunication networks.
NOT BE UPDATED
Issue 4 Revision 0 Network Evolution
Network Evolution
Packetized Packetized
Mobile Connection Mobile Connection

less less
Telephony Telephony
IP IP
application application
Wireline Wireline
Connection Connection
orientated orientated
Circuit Circuit
based based
CP13_Ch1_03

NOT BE UPDATED
Future Data Usage Issue 4 Revision 0
Future Data Usage

The introduction of any mobile multimedia services will be driven by actual user needs.
For personal communications services to reach the hoped-for penetration rates of 70–80
per cent, services must have mass-market appeal: they need to be easy to use and
cost-justifiable.
There has been fantastic growth in Internet and Intranet usage in the past couple of
years. Demand is also growing for high-speed applications in order to access corporate
resources while on the move. This type of multimedia applications demand high data
rates in short time periods, while the information is downloaded, in one direction.
Another potential multimedia application is simultaneous voice and data, for example, for
PC application sharing or shared whiteboard. Although this type of application does not
require particularly high bit-rates, it does require real-time, continuous operation because
of its voice content.
NOT BE UPDATED
Issue 4 Revision 0 Future Data Usage
Future Data Usage
Real Time Voice

Non–Real Time Voice
Messaging
Video
Internet Access
25%
5%
50%
10%
10%
CP13_Ch1_04

NOT BE UPDATED
IMT-2000 Roadmap Issue 4 Revision 0
IMT-2000 Roadmap
This slide points out the possible routes to 3G. On one extreme we see the route taken
by 3GPP culminating in the adoption of W-CDMA. Centre stage we see the route chosen
by the UWC 136 supporters. UWC 136 will be built on TDMA technology by enhancing
its modulation techniques to meet ITU’s requirements for IMT2000. Far right we see the
route chosen for 3GPP2 which has its origins in the IS95 standards known as CDMAOne
culminating in CDMA 2000.
The three different systems are:
1. UMTS W-CDMA
2. UWC-136
3. CDMA2000
Which have been designed by three separate organisations;
1. 3GPP
2. UWCC
3. 3GPP2
GSM Global Systems for Mobile Communication

ETSI European telecommunication Standard
Institute
GPRS General Packet Radio Service
EDGE Enhanced Data rates for Global Evolution
UWCC Universal Wireless Communication
Committee
TIA Telecommunication Industry Association
3GPP Third Generation Partnership Project
UWC Universal Wireless Communications
3GPP2 Third Generation Partnership Project 2
NOT BE UPDATED
Issue 4 Revision 0 IMT-2000 Roadmap
IMT-2000 Roadmap
GSM
Association UWCC CDG
ETSI T1 TIA
TDMA
2G GSM cdmaOne
(IS – 136)
GPRS
Packet
Switch HDR
EDGE
2.5G
W–CDMA UWC–136 cdma2000
3G 3GPP UWCC 3GPP2
CP13_Ch1_05

NOT BE UPDATED
UMTS Objectives Issue 4 Revision 0
UMTS Objectives
It has taken almost ten years to complete the standardisation of UMTS from the research
phases. The initial starting points are still valid as they were then. The most important
consideration must be the ability to use the mobile device anywhere anytime to access
any service required. To achieve this, a satellite part was included. GSM started the
service provision path using over the air systems to deploy information onto the terminal.
UMTS will require a higher degree of provisioning for the larger set of servers and
devices that are expected.
The lifestyle of the user is changing, the needs of large corporate and the importance
telecommunications is playing. The outcome is to have access anywhere using the
cheapest most conveyance system.
One issue is that of standard interfaces / services. If a customer utilises a travel
information application (for example from British Airways or Virgin) in their home network
it would not be unreasonable for that customer to expect the same facilities when they
roamed onto another network. This means that a company offering their services via
mobile networks will have to ensure operators have access to their servers and can offer
the same interface to the customer.
Subscribers will also expect access to other (more standard) services when they roam.
Examples of this include voice mail and e-mail. Operators will have to co-operate with
each other to ensure customers have access to their ‘home’ records. Although the
Internet offers access to information sources world-wide, typically we do not expect to
benefit from that access until we arrive at some familiar point - whether home, office, or
school. However, the increasing variety of wireless devices offering IP connectivity, such
as PDAs, handhelds, and digital cellular phones, is beginning to change our perceptions
of the Internet.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Objectives
UMTS Objectives
· Global service capabilities
· Terrestrial and satellite components
· Flexible/seamless service
· Wider range of services/terminals
· Fixed/Mobile and Public/Private
· Improved operational efficiencies
CP13_Ch1_06

NOT BE UPDATED
UMTS Objectives Issue 4 Revision 0
To understand the contrast between the current realities of IP connectivity and future
possibilities, consider the transition toward mobility that has occurred in telephony over
the past 20 years. An analogous transition in the domain of networking, from dependence
on fixed points of attachment to the flexibility afforded by mobility, has just begun. Mobile
computing and networking should not be confused with the portable computing and
networking we have today. In mobile networking, computing activities are not disrupted
when the user changes the computer’s point of attachment to the Internet. Instead, all
the needed reconnection occurs automatically and non-interactively.
Truly mobile computing offers many advantages. Confident access to the Internet
anytime, anywhere will help free us from the ties that bind us to our desktops. Consider
how cellular phones have given people new freedom in carrying out their work. Taking
along an entire computing environment has the potential not just to extend that flexibility
but to fundamentally change the existing work ethic. Having the Internet available to us
as we move will give us the tools to build new computing environments wherever we go.
Those who have little interest in mobility per se will still benefit from the ability to resume
previous applications when they reconnect. This is especially convenient in a wireless
LAN office environment, where the boundaries between attachment points are not sharp
and are often invisible.
However, there are still some technical obstacles that must be overcome before mobile
networking can become widespread. The most fundamental is the way the Internet
Protocol, the protocol that connects the networks of today’s Internet, routes packets to
their destinations according to IP addresses. These addresses are associated with a
fixed network location much as a non-mobile phone number is associated with a physical
jack in a wall. When the packet’s destination is a mobile node, this means that each new
point of attachment made by the node is associated with a new network number and,
hence, a new IP address, making transparent mobility impossible.
Mobile IP (RFC 2002), a standard proposed by a working group within the Internet
Engineering Task Force, was designed to solve this problem by allowing the mobile node
to use two IP addresses: a fixed home address and a care-of address that changes at
each new point of attachment. This article will present the Mobile IP standard in
moderate technical detail and point the reader toward a wealth of further information.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Objectives
UMTS Objectives
· Global service capabilities
· Terrestrial and satellite components
· Flexible/seamless service
· Wider range of services/terminals
· Fixed/Mobile and Public/Private
· Improved operational efficiencies
CP13_Ch1_06

NOT BE UPDATED
World-wide Spectrum Allocation for IMT-2000 Issue 4 Revision 0
World-wide Spectrum Allocation for IMT-2000

The allocation of frequencies per region after the World Administration Radio Conference
(WARC 92) meeting has been varied. IMT-2000 recognised the frequencies to be
1885Mhz to 2025Mhz in the lower and 2110Mhz to 2200Mhz in the upper band. Each
band was split into satellite (MSS) and terrestrial IMT-2000 parts. Not all countries could
utilise exactly this range of frequencies due to the fact that they have already got other
systems operating in these bands. Therefore they vary somewhat as can bee seen from
the sketch opposite.
Europe has used part of the band for DECT - which has very low penetration. It also has
GSM 1800 at the lower edge. The band is also split in FDD and TDD bands.
China has left the band clear and will start IMT-2000 activities soon. This will be split into
WLL and Mobile.
Japan has developed with Korea the DoCoMo system which is pre release 99 and will
launch Q4 2000/Q1 2001.
UTRA FDD for Region 2 - Re-farming A, B, C, D, E, F Bands currently used for PCS.
EDGE will be developed on the PCS frequencies and some TV frequencies in 2006.
NOT BE UPDATED
Issue 4 Revision 0 World-wide Spectrum Allocation for IMT-2000
World-wide Spectrum Allocation for IMT-2000
1850 1900 1950 2000 2050 2100 2150 2200 2250 Mhz
1885 1900 1980 20102025 2110 2170 2200
ITU Allocations IMT 2000 MSS IMT 2000 MSS

1880
Europe GSM
DECT UMTS MSS UMTS MSS
1800
WLL WLL
China GSM IMT 2000 MSS IMT 2000 MSS

1800
1893 1919
Japan MSS =
PHS IMT 2000 MSS IMT 2000 MSS
Korea (w/o PHS) Mobile Satellite
Services
1990 2160
MDS =
PCS M
North Reserve D MSS Multipoint Service/
MSS
America A DB E F C A D B E F C S Mobile Data Service
1850 1900 1950 2000 2050 2100 2150 2200 2250 Mhz
CP13_Ch1_07

NOT BE UPDATED
Frequency Allocations Issue 4 Revision 0
Frequency Allocations
When studying the frequency allocation for Europe more closely we can see the
following.
It is split into two frequency bands:
Lower 1900MHz - 2025MHz
Upper 2110MHz - 2200MHz
Owing to the asymmetric nature of the frequency allocation, frequencies have been
additionally allocated into paired and unpaired bands. The frequency range 1920 -
1980MHz and 2110 - 2170MHz are available to operators as paired bands, these support
FDD that is best suited to symmetric services such as telephony. A minimum frequency
separation of 130MHz has been specified between transmit and receive frequencies. The
lower band 1900 - 1920MHz and 2010 - 2025MHz are available as unpaired bands.
These can support TDD, which is best suited to asymmetrical services such as the
Internet.
FDD - Frequency Division duplexing
TDD - Time Division duplexing
NOT BE UPDATED
Issue 4 Revision 0 Frequency Allocations
Frequency Allocations
1805
1880
1900
1920
1980
2010
2020
2025
Uplink 12 x 5 MHz
MSS
GSM
TDD
TDD
SPA
FDD
DECT
1800
20MHz 60MHz 30MHz
140MHz
2170
2200
2110
Downlink 12 x 5 MHz 6 x 5 MHz

MSS
FDD
190MHz between up–

link and down–link
60MHz 30MHz
90MHz
CP13_Ch1_08

NOT BE UPDATED
Licence Allocation in the UK Issue 4 Revision 0
Licence Allocation in the UK

In the UK the spectrum was divided into five licenses. The four incumbent operators were
successful in obtaining a license each, which left one for a new entrant. License A, which
is considered as the most desirable spectral package, was set aside for this new entrant.
A - Hutchison 3G
B - Vodaphone
C - One2One
D - BT Cellnet
E - Orange
Some of the issues that should be considered in the frequency allocations are:
Guard bands provide a reduced noise floor
Lower frequencies travel further, I.e. less cells
Three frequencies allows greater use of multimedia services
Trade-offs between FDD and TDD spectrum
NOT BE UPDATED
Issue 4 Revision 0 Licence Allocation in the UK
Licence Allocation in the UK
2112.8 MHz 2167.2 MHz

0.3 MHz 0.3 MHz
guard band guard band
10.0 MHz 10.0 MHz

2110 MHz Licence C Licence D 2170 MHz
14.6 MHz 14.8 MHz 10.0 MHz
Licence A Licence B Licence E
0.4 MHz
guard band
1902.4 MHz 1922.8 MHz 1977.2 MHz
Unpaired carriers 0.3 MHz
guard band
D E C A
10.0 MHz 10.0 MHz

1900 MHz 1920 MHz Licence C Licence D 1980 MHz
14.6 MHz 14.8 MHz 10.0 MHz
Licence A Licence B Licence E
CP13_Ch1_09

NOT BE UPDATED
Licence Allocation in the UK Issue 4 Revision 0
NOT BE UPDATED
Chapter 2
Network Architecture

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 2
Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
UMTS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
UMTS Architecture – R99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
The Core Network (CN) Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
The Access Network (AN) Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
The Mobile Station (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
UMTS Network – R99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10
Entities of the CN–CS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10
Entities Common to the CS and PS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
Entities of the CN-CS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
Serving GPRS Support Node (SGSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
Gateway GPRS Support Node (GGSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
SS7 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Integrated Support Server (ISS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Core Router (CommHub) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
UMTS Terrestrial Radio Access Network (UTRAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18
UTRAN Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18
Radio network Controller Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Controlling Radio Network Controller (CRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Serving Radio Network Controller (SRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
Drift Radio Network Controller (DRNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–24
Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
Wideband Digital Modem (WDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
The Wideband Transceiver (WBX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
Linear Power Amplifier (LPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–26
Product evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–30
Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–32
Release 4/5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
MSC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
Gateway MSC Server (GMSC Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
Circuit Switched – Media Gateway Function (CS-MGW). . . . . . . . . . . . . . . . . . . . 2–34
The Home Subscriber Server (HSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Transport Signalling Gateway Function (T-SGW) . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Roaming Signalling Gateway Function (R-SGW) . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
Describe the architecture of a UMTS network.
Describe the purpose of the major network components.
Describe the options for evolution to future releases.

NOT BE UPDATED
UMTS Domains Issue 4 Revision 0
UMTS Domains
Domain split
A basic architectural split is between the user equipment (terminals) and the
infrastructure. This results in two domains: the User Equipment Domain and the
Infrastructure domain. User equipment is the equipment used by the user to access
UMTS services. User equipment has a radio interface to the infrastructure. The
infrastructure consists of the physical nodes which perform the various functions required
to terminate the radio interface and to support the telecommunication services
requirements of the users. The infrastructure is a shared resource that provides services
to all authorised end users within its coverage area. The reference point between the
user equipment domain and the infrastructure domain is termed the “Uu” reference point
(UMTS radio interface).
User equipment Domain

This domain encompasses a variety of equipment types with different levels of
functionality. These equipment types are referred to as user equipment (terminals), and
they may also be compatible with one or more existing access (fixed or radio) interfaces
e.g. dual mode UMTS-GSM user equipment. The user equipment may include a
removable smart card that may be used in different user equipment types. The user
equipment is further sub-divided in to the Mobile Equipment Domain (ME) and the
User Services Identity Module Domain (USIM). The reference point between the ME
and the USIM is termed the “Cu” reference point.
Mobile equipment Domain

The Mobile Equipment performs radio transmission and contains applications. The
mobile equipment may be further sub-divided into serveral entities, e.g. the one which
performs the radio transmission and related functions, Mobile Termination, MT, and the
one which contains the end-to-end application or (e.g. laptop connected to a mobile
phone), Terminal Equipment, TE.
USIM Domain
The USIM contains data and procedures which unambiguously and securely identify
itself. These functions ae typically embedded in a standalone smart card. This device is
associated to a given user, and as such allows to identify this user regardless of the ME
he uses.
Infrastructure Domain
The Infrastructure domain is further split into the Access Network Domain, which is
characterized by being in direct contact with the User Equipment and the Core Network
Domain. This split is intended to simplify/assist the process of de-coupling access
related functionality from non-access related functionality and is in line with the modular
principle adopted for the UMTS. The Access Network Domain comprises roughly the
functions specific to the access technique, while the functions in the Core network
domain may potentially be used with information flows using any access technique. This
split allows for different approaches for the Core Network Domain, each approach
specifying distinct types of Core Networks connectable to the Access Network Domain,
as well as different access techniques, each type of Access Network connectable to th
Core Network Domain. The reference point between the access network domain and the
core network domain is termed the “lu” reference point.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Domains
UMTS Domains
Home
Network
Domain
[Zu]
Cu Uu Iu [Yu]
SIM
CARD Server
Serving Transit
Network Network
Domain Domain
USIM Mobile Access Core

Domain Equipment Network Network
Domain Domain Domain
User Equipment Infrastructure

Domain Domain
CP13_Ch2_02

NOT BE UPDATED
UMTS Domains Issue 4 Revision 0
Access Network Domain

The Access Network Domain consists of the physical entities which manage the
resources of the access network and provides the user with a mechanism to access the
core network domain.
Core Network Domain

The Core Network Domain consists of the pysical entities which provide support for the
network features and telecommunication services. The support provided includes
functionality such as the management of user location information, control of network
features and services, the transfer (switching and transmission) mechanisms for
signalling and for user generated information.
The core network domain is sub-divided into the Serving Network Domain, the Home
Network Domain and the Transit Network Domain. The reference point between the
serving network domain and the home network domain is termed the [Zu] reference
point. The reference point between the serving network domain and the transit network
domain is termed the [Yu] reference point.
Serving Network Domain

The serving network domain is the part of the core network domain to which the access
network domain that provides the user’s access is connected. It represents the core
network functions that are local to the user’s access point and thus their location changes
when the user moves. The serving network domain is responsible for routing calls and
transport user data/information form source to destination. It has the ability to interact
with the home domain to cater for user specific data/services and with the transit domain
for non-user specific data/services purposes.
Home Network Domain

The home network domain represents the core network functions that are conducted at a
permanent location regardless of the location of the user’s access point. The USIM is
related by subscription to the home network domain. The home network domain
therefore contains at least permanently user specific data and is responsible for
management of subscription information. It may also handle home specific services,
potentially not offered by the serving network domain.
Transit Network Domain

The transit network domain is the core network part located on the communication path
between the serving network domain nad the remote party. If, for a given call, the remote
party is located inside the same network as the originating UE, then no particular
instance of the transit domain is activated.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Domains
UMTS Domains
Home
Network
Domain
[Zu]
Cu Uu Iu [Yu]
SIM
CARD Server
Serving Transit
Network Network
Domain Domain
USIM Mobile Access Core

Domain Equipment Network Network
Domain Domain Domain
User Equipment Infrastructure

Domain Domain
CP13_Ch2_02

NOT BE UPDATED
UMTS Architecture – R99 Issue 4 Revision 0
UMTS Architecture – R99

The diagram opposite illustrates the basic configuration of a Public Land Mobile Network
(PLMN) supporting UMTS and GSM/GPRS.This architecture is as defined in Release
1999 of the 3GPP specifications (TS23.002)
The Core
Network (CN)
Entities
The CN is constituted of a Circuit Switched (CS) domain and a Packet Switched (PS)
domain. These two domains differ by the way they support user traffic, as explained
bellow. These two domains are overlapping, i.e. they contain some common entities. A
PLMN can implement only one domain or both domains.
CS Domain
The CS domain refers to the set of all the CN entities offering “CS type of connection” for
user traffic as well as all the entities supporting the related signalling. A “CS type of
connection” is a connection for which dedicated network resources are allocated at the
connection establishment and released at the connection release. The entities specific to
the CS domain are:
MSC – The Mobile-services Switching Centre
GMSC – Gateway Mobile Service Switching Centre
VLR – Visitor Location Register
PS Domain
The PS domain refers to the set of all the CN entities offering “PS type of connection” for
user traffic as well as all the entities supporting the related signalling. A “PS type of
connection” transports the user information using autonomous concatenation of bits
called packets: each packet can be routed independently from the previous one. The
entities specific to the PS domain are the GPRS specific entities, i.e.
SGSN – Serving GPRS Support Node
GGSN – Gateway GPRS Support Node
Entities Common to the CS and PS domains

The following entities are common provide common functions to the CS and PS
Domains:
HLR – The Home Location Register
AUC – Authentication Centre
EIR – Equipment Identity Register
NOT BE UPDATED
Issue 4 Revision 0 UMTS Architecture – R99
Gi
GMSC AuC GGSN
Gp
C H
Gc
HLR
PSTN PSTN Gr
D Gn
EIR
VLR G
F Gf
VLR
MSC E SGSN
Gs
MSC CN
IuCS IuPS Gb
A
BSS RNS IuPS IuCS RNS BSS
BSC RNC Iur RNC BSC
Abis lub lub Abis
BTS BTS Node B Node B Node B Node B BTS BTS
Um MS Um
Uu
ME
SIM–ME I/f
Cu
SIM or USIM
CP13_Ch2_11

NOT BE UPDATED
UMTS Architecture – R99 Issue 4 Revision 0
The Access
Network (AN)
Entities
Two different types of access network are used by the CN: the Base Station System
(BSS) and the Radio Network System (RNS). The BSS offers a Time Division Multiple
Access (TDMA) based technology to access the Mobile Station whereas the RNS offers
a Wideband-Code Division Multiple Access (W-CDMA) based technology. The MSC
(resp. SGSN) can connect to one of these Access Network type or to both of them.
The Base Station System (BSS)

The Base Station System (BSS) is the system of base station equipments (transceivers,
controllers, etc...) which is viewed by the MSC through a single A-interface as being the
entity responsible for communicating with Mobile Stations in a certain area. Similarly, in
PLMNs supporting GPRS, the BSS is viewed by the SGSN through a single Gb
interface. The functionality for the A interface is described in GSM 08.02 and for the Gb
interface in TS 23.060. The radio equipment of a BSS may support one or more cells. A
BSS may consist of one or more base stations. Where an Abis-interface is implemented,
the BSS consists of one Base Station Controller (BSC) and one or more Base
Transceiver Station (BTS).
The Radio Network System (RNS)

The Radio Network System (RNS) is the system of base station equipments
(transceivers, controllers, etc...) which is viewed by the MSC through a single Iu-interface
as being the entity responsible for communicating with Mobile Stations in a certain area.
Similarly, in PLMNs supporting GPRS, the RNS is viewed by the SGSN through a single
Iu-PS interface. The functionality for the Iu-CS interface is described in TS 25.410 and
for the Iu-PS interface in TS 23.060. The radio equipment of a RNS may support one or
more cells. A RNS may consist of one or more base stations. The RNS consists of one
Radio Network Controller (RNC) and one or more Node B.
The Mobile
Station (MS)
The mobile station consists of the physical equipment used by a PLMN subscriber; it
comprises the Mobile Equipment (ME) and the Subscriber Identity Module (SIM), called
UMTS Services Identity Module (USIM) for Release 99 and following. The ME comprises
the Mobile Termination (MT) which, depending on the application and services, may
support various combinations of Terminal Adapter (TA) and Terminal Equipment (TE)
functional groups. These functional groups are described in GSM 04.02.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Architecture – R99
Gi
GMSC AuC GGSN
Gp
C H
Gc
HLR
PSTN PSTN Gr
D Gn
EIR
VLR G
F Gf
VLR
MSC E SGSN
Gs
MSC CN
IuCS IuPS Gb
A
BSS RNS IuPS IuCS RNS BSS
BSC RNC Iur RNC BSC
Abis lub lub Abis
BTS BTS Node B Node B Node B Node B BTS BTS
Um MS Um
Uu
ME
SIM–ME I/f
Cu
SIM or USIM
CP13_Ch2_11

NOT BE UPDATED
UMTS Network – R99 Issue 4 Revision 0
UMTS Network – R99

The diagram opposite shows a simplified schematic of an R99 UMTS Network. It
illustrates only those entities associated with providing a UMTS service (i.e excludes any
entities specifically associated with GSM/GPRS
Entities of the
CN–CS Domain
The Mobile Services Switching Centre (MSC)

The Mobile–services Switching Centre (MSC) constitutes the interface between the radio
system and the fixed networks. The MSC performs all necessary functions in order to
handle the circuit switched services to and from the mobile stations. In order to obtain
radio coverage of a given geographical area, a number of base stations are normally
required; i.e. each MSC would thus have to interface several base stations. In addition
several MSCs may be required to cover a country. The Mobile–services Switching Centre
is an exchange which performs all the switching and signalling functions for mobile
stations located in a geographical area designated as the MSC area. The main difference
between a MSC and an exchange in a fixed network is that the MSC has to take into
account the impact of the allocation of radio resources and the mobile nature of the
subscribers and has to perform procedures required for the location registration (see TS
23.012) and procedures required for handover (see TS 23.009).
The Gateway MSC (GMSC)

If a network delivering a call to the PLMN cannot interrogate the HLR, the call is routed to
an MSC. This MSC will interrogate the appropriate HLR and then route the call to the
MSC where the mobile station is located. The MSC which performs the routing function
to the actual location of the MS is called the Gateway MSC (GMSC). The acceptance of
an interrogation to an HLR is the decision of the operator. The choice of which MSCs
can act as Gateway MSCs is for the operator to decide (i.e. all MSCs or some
designated MSCs).
The Visitor Location Register (VLR)

A mobile station roaming in an MSC area is controlled by the Visitor Location Register in
charge of this area. When a Mobile Station (MS) enters a new location area it starts a
registration procedure. The MSC in charge of that area notices this registration and
transfers to the Visitor Location Register the identity of the location area where the MS is
situated. If this MS is not yet registered, the VLR and the HLR exchange information to
allow the proper handling of calls involving the MS. A VLR may be in charge of one or
several MSC areas. The VLR contains also the information needed to handle the calls
set–up or received by the MSs registered in its database. The following elements are
included:
The International Mobile Subscriber Identity (IMSI);
The Mobile Station International ISDN number (MSISDN);
The Mobile Station Roaming Number (MSRN), see TS 23.003 for allocation
principles;
The Temporary Mobile Station Identity (TMSI), if applicable;
The Local Mobile Station Identity (LMSI), if used;
The location area where the mobile station has been registered;
The last known location and the initial location of the MS.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Network – R99
UMTS Network –R99
PS P
CN–CS CN–PS
CN Domain
GMSC GGSN
HLR
VLR
AuC
MSC SGSN
OMC–T Iu–CS Iu–PS

(Transport)
OMC–U
UTRAN
(UTRAN)
RNS RNS
RNC RNC
Iur
Iub Iub Iub Iub
Node B Node B Node B Node B
Uu
User Equipment
CP13_2_3a

NOT BE UPDATED
UMTS Network – R99 Issue 4 Revision 0
Entities Common
to the CS and PS
Domains
The Home Location Register (HLR)

This functional entity is a database in charge of the management of mobile subscribers.
A PLMN may contain one or several HLRs: it depends on the number of mobile
subscribers, on the capacity of the equipment and on the organisation of the network.
The following kinds of information are stored there:
Subscription information.
Location information enabling the charging and routing of calls towards the MSC
where the MS is registered (e.g. the MS Roaming Number, the VLR Number, the
MSC Number, the Local MS Identity).
If GPRS is supported, location information enabling the charging and routing of
messages in the SGSN where the MS is currently registered (e.g. the SGSN
Number).
The types of identity are attached to each mobile (e.g International Mobile Station
Identity (IMSI), one or more Mobile Station International ISDN number(s)
(MSISDN), if GPRS is supported zero or more Packet Data Protocol (PDP)
address(es)).
The Authentication Centre (AuC)

The Authentication Centre (AuC) is an entity which stores data for each mobile
subscriber to allow the International Mobile Subscriber Identity (IMSI) to be authenticated
and to allow communication over the radio path between the mobile station and the
network to be ciphered. The AuC transmits the data needed for authentication and
ciphering via the HLR to the VLR, MSC and SGSN which need to authenticate a mobile
station. The Authentication Centre (AuC) is associated with an HLR, and stores an
identity key for each mobile subscriber registered with the associated HLR. This key is
used to generate:
Data which are used to authenticate the International Mobile Subscriber Identity
(IMSI).
A key used to cipher communication over the radio path between the mobile
station and the network.
The Equipment Identity Register (EIR)

The Equipment Identity Register (EIR) in the GSM system is the logical entity which is
responsible for storing in the network the International Mobile Equipment Identities
(IMEIs), used in the GSM system. The equipment is classified as “white listed”, “grey
listed”, “black listed” or it may be unknown as specified in TS 22.016 and TS 29.002.
This functional entity contains one or several databases which store(s) the IMEIs used in
the GSM system. An EIR shall as a minimum contain a “white list” (Equipment classified
as “white listed”). See also TS 22.016 on IMEI.
NOT BE UPDATED
Issue 4 Revision 0 UMTS Network – R99
UMTS Network –R99

PS P
CN–CS CN–PS
CN Domain
GMSC GGSN
HLR
VLR
AuC
MSC SGSN
OMC–T Iu–CS Iu–PS

(Transport)
OMC–U
UTRAN
(UTRAN)
RNS RNS
RNC RNC
Iur
Iub Iub Iub Iub
Uu
User Equipment
CP13_2_3a

NOT BE UPDATED
Entities of the CN-CS Domain Issue 4 Revision 0
Entities of the CN-CS Domain

The UMTS PS-domain (or GPRS) Support Nodes (GSN) are the Gateway GSN (GGSN)
and the Serving GSN (SGSN). They constitute the interface between the radio system
and the fixed networks for packet switched services. The GSN performs all necessary
functions in order to handle the packet transmission to and from the mobile stations.
The entities of the GSN are shown in more detail in the diagram opposite.
Serving GPRS
Support Node
(SGSN)
The primary role of the SGSN is to provide Mobility Management (MM) functions. At PS
attach, the SGSN establishes a Mobility Management context containing information
pertaining mainly to mobility and security for the MS. In GPRS the SGSN maintains a
“Logical Link” with each MS, providing a reliable and secure data channel as the MS
moves betweens cells. For UMTS this tight relationship between the MS and the SGSN
has been loosened, as the SGSN will no longer manage the mobility of the MS at the cell
level, but still maintains mobility functions across different RNCs. The UMTS (and where
supported GPRS) MM functions are provided by the R99 Control Function (R99 CF).
This logical entity also manages the interfaces between the PS CN and the SS7 network
through the SS7 gateway
At PDP Context activation, the SGSN establishes a PDP context to be used for bearer
stream routing purposes with the GGSN. This enables the subscriber to access the
external PDN. This function is performed by the Transmission Functions. Early
commercial releases will support only UMTS services, with the R99 TF maintaining the
Iu-PS with the UMTS RNC on one side and the bearer domain of the Gn interface with
the GGSN on the other. Later releases will also employ the R97 TF to support GSM
BSS via the Gb/Gn. Control of both R97 and R99 TFs will be performed by the R99 CF.
The SGSN also collects charging data for all PDP and MM contexts, generates Call
Detail Records (S-CDRs and M-CDRs) and forwards those records to the Charging
Gateway Function.
Gateway GPRS
Support Node
(GGSN)
The main role of the GGSN is to provide inter-working between UMTS/GSM access
networks and external hosts that need to communicate with mobile subscribers. The
GGSN directs mobile terminated packets to the SGSN (currently serving the MS) over
the Gn interface, allowing the mobile to move freely within the coverage are of its home
or foreign network.
The GGSN is the node accessed by the PDN, via the PDP address, and contains routing
information for activated UMTS/GPRS users. This routing information is used to “Tunnel”
packets to an MS current point of attachment. The GGSN is the first logical point of PDN
interconnection to a UMTS network supporting the Gi reference point. The GGSN
mediates access to the PDN resources on behalf of the MS and Implements packet
scheduling policy betweens different QoS Classes.
The GGSN also collects charging data for all PDP contexts, creates Call Detail Records
(G-CDRs) and forwards those records to the Charging Gateway Function.
NOT BE UPDATED
Issue 4 Revision 0 Entities of the CN-CS Domain
UMTS Network – R99 CN-PS Architecture
ISS
SGSN
R99TF
GGSN PDN
R99CF CommHub
SS7
SS7 GW
R97TF
FR RAN GW
BSS UTRAN ATM
CP13_Ch2_3b.ai

NOT BE UPDATED
Entities of the CN-CS Domain Issue 4 Revision 0
SS7 Gateway
The SS7 Gateway is a signalling gateway that is responsible for the signalling adaptation
between external SS7 networks and UMTS/GPRS PS CN. It inter-works the SS7
transport protocols to the IP-based CN transport protocols. Multiple SS7 gateways per
GSN complex are possible. The SS7 gateway is also responsible for interfacing to
VLRs, HLRs and AuCs.
Integrated
Support Server
(ISS)
The ISS offers a collection of support services to the rest of the GSNu Subsystems,
namely the functions of CGF, DNS, and TS. These are described below
Charging Gateway Functionality (CGF)

The CGF is the central entity that collects CDRs from both the SGSN and the GGSN. It
stores these records, maintains their integrity and reports any missing or duplicated
records prior to transmission to the network operators billing system.
A CDR captures all necessary information about an active communication session (PDP
and MM contexts) that takes place between an MS and an end system (e.g an Internet
FTP server). This may include data volume transferred, QoS supported, duration of
session, and different identities (IMSI, MS IP address, etc) that distinguishes the session.
A new charging interface, the Ga, has been introduced by the standards between the
GGSN/SGSN and the CGF , to isolate CDR traffic from other user or signalling traffic
that populate the Gi and Gn interfaces.
Domain Name Service (DNS)

This is the well know DNS service offered by the ISS to all GSN sub-systems. Upon
request, the DNS function maps an IP address of a GSN sub-system (for example a CF
machine) to its domain name, and vice versa. The DNS function also keeps a list of all
available Access Point Names within a certain GSN.
Time Server (TS)

The TS function helps the GSN system have a common time reference using the
Network Time Protocol (NTP). This is particularly important when it comes to time
stamping CDRs generated by different GSN nodes.
Core Router
(CommHub)
This network entity is responsible for network connectivity including L2 switching, IP
routing, and the ATM/FR termination. It provides LAN and WAN networking capabilities
for all other PS CN sub-systems (the SGSN,GGSN and ISS).
NOT BE UPDATED
Issue 4 Revision 0 Entities of the CN-CS Domain
UMTS Network – R99 CN-PS Architecture
ISS
SGSN
R99TF
GGSN PDN
R99CF CommHub
SS7
SS7 GW
R97TF
FR RAN GW
BSS UTRAN ATM
CP13_Ch2_3b.ai

NOT BE UPDATED
UMTS Terrestrial Radio Access Network (UTRAN) Issue 4 Revision 0
UMTS Terrestrial Radio Access Network (UTRAN)

The UTRAN consists of a set of Radio Network Subsystems (RNSs) connected to the
Core Network through the IuCS and IuPS. A RNS consists of a Radio Network
Controller and one or more Node Bs. A Node B is connected to the RNC through the Iub
interface. A Node B can support FDD mode, TDD mode or dual-mode operation. The
RNC is responsible for the Handover decisions that require signalling to the UE. A RNC
may include a combining/splitting function to support combination/splitting of information
streams.
Inside the UTRAN, the RNCs of the Radio Network Subsystems can be interconnected
together through the Iur. Iu(s) and Iur are logical interfaces. Iur can be conveyed over
direct physical connection between RNCs or virtual networks using any suitable transport
network.
UTRAN
Functions
The following is a list of the functions performed by the UTRAN sub-systems. These
functions will be discussed in further detail in later chapters.
Functions related to overall system access control

Admission Control
Congestion Control
System information broadcasting
Radio channel ciphering and deciphering
Functions related to mobility

Handover
SRNS Relocation
Functions related to radio resource management and control

Radio resource configuration and operation
Radio environment survey
combining/splitting control
Radio bearer connection set-up and release (Radio Bearer Control)
Allocation and deallocation of Radio Bearers
Radio protocols function
RF power control
RF power setting
Radio channel coding/decoding
Channel coding control
Initial (random) access detection and handling
CN Distribution function for Non Access Stratum messages
Functions related to broadcast and multicast services

NOTE: Only Broadcast is applicable for Release 99.
Broadcast/Multicast Information Distribution
Broadcast/Multicast Flow Control
CBS Status Reporting
NOT BE UPDATED
Issue 4 Revision 0 UMTS Terrestrial Radio Access Network (UTRAN)
UMTS Terrestrial Radio Access Network (UTRAN)
Core Network
Iu Iu
Iur
RNC RNC
Iub Iub Iub Iub
CP13_Ch2_3c

NOT BE UPDATED
Radio network Controller Roles Issue 4 Revision 0
Radio network Controller Roles

A Radio Network Controller (RNC) can be considered to operate in one or more of the
following roles:
Controlling Radio Network Controller (CRNC)
Serving Radio Network Controller (SRNC)
Drift Radio Network Controller (DRNC)
Controlling
Radio Network
Controller
(CRNC)
Controlling RNC is a role an RNC can take with respect to a specific set of Node B’s.
There is only one Controlling RNC for any Node B. The Controlling RNC has the overall
control of the logical resources of its node B’s.
The main functions of a CRNC are:
Control of the Radio Resources for the Node-B it controls.
Provision of Services to the Node-B that it controls.
Load and Congestion Control
Admission Control
Code allocation for new radio links
NOT BE UPDATED
Issue 4 Revision 0 Radio network Controller Roles
UTRAN CRNC Functions
· Controlling of the Radio Resources
· Provision of Services to the Node–B
· Load and Congestion Control
· Admission Control
· Code Allocation for new Radio Links
C–RNC Iu Iu C–RNC
lur
CP13_Ch2_05

NOT BE UPDATED
Serving Radio
Network
Controller
(SRNC)
A Serving RNC is the RNC located within a Serving RNS (SRNS). SRNS is a role an
RNS can take with respect to a specific connection between an UE and UTRAN.
There is one Serving RNS for each UE that has a connection to UTRAN.
The Serving RNS is in charge of the radio connection between a UE and the UTRAN.
The Serving RNS terminates the Iu for this UE.
The main functions of an SRNC are:
Termination of the Radio Resource Control Signalling between the RNC and the
UE.
L2 Processing (PDCP, RLC, MAC)
Radio Resource Control operations.
Mapping of Iu Bearer Parameters onto Transport Channels Parameters.
Hand-over decisions.
Outer loop power control.
Macro-Diversity combining and splitting.
NOT BE UPDATED
UTRAN SRNC Functions
· Termination of the Radio Resource Control Signalling

between the RNC and the UE
· L2 Processing (PDCP, RLC, MAC)
· Radio Resource Control Operations
· Mapping of Bearer Parameters onto Transport Channel Parameters
· Hand–Over Decisions
· Outer Loop Power Control

· Macro–diversity Combining and Splitting
S–RNC
CP13_Ch2_06

NOT BE UPDATED
Drift Radio
Network
Controller
(DRNC)
A Drift RNC is located within a Drift RNS. DRNS is role that an RNS can take with
respect to a specific connection between a UE and UTRAN.
A DRNS is any RNS that supports the Serving RNS by providing radio resources via the
cell(s) it controls, to provide additional radio bearer services for a specific connection
between a UE and UTRAN.
There may be zero, one or more DRNSs associated with a specific connection between
a UE and UTRAN.
The main functions of a DRNC are:
Macro-diversity combining and splitting.
No L2 processing.
Transparent routing of data on the Iub and Iur Interfaces, except when Common or
shared channels are used.
NOT BE UPDATED
UTRAN DRNC Functions
· Macro–diversity Combining and Splitting
· No L2 Processing
· Transparent Routing except for Common/Shared Channels
S–RNC D–RNC
CP13_Ch2_07

NOT BE UPDATED
Node B Issue 4 Revision 0
Node B
A Node B is a logical node in the RNS that is in charge of radio transmission and
reception in one or more cells. Each Node B is Identified within the UTRAN by a unique
Node B ID. Typically a Node B will support up to six cells. Each cell is a specific radio
coverage are and is Identified by a unique Cell ID, which will be broadcast across the
entire cell area.
The diagram opposite shows the typical architecture of a Node B.
Wideband Digital
Modem (WDM)
The WDM card is the heart of the Node B and performs the majority of the layer 1
(physical layer) functions. Motorola has designed the WDM card to support a high traffic
throughput and to allow trunking across multiple carriers/sectors. This gives advantages
in terms of availability and also allows the Node B to efficiently handle non-uniform traffic
distributions. Up to 6 WDM’s can be installed per Node B cabinet and the WDM is fully
compliant to the June 00 standards baseline of the R99 3GPP standard.
The WDM functions include:
Transmit and Receive chip and symbol level processing
User plane protocol termination for the Node B/RNC interface
Termination of intra Node B control protocol
Physical control of the signal processing function
Termination of the intra Node B time reference interface
The Wideband
Transceiver
(WBX)
The Wideband Transceiver (WBX) is the interface between the analog and digital
baseband worlds. On the forward link the WBX accepts baseband digital data from the
WDM via the baseband bus, formats this data to UMTS air interface requirements, and
produces a modulated RF signal at the required carrier frequency for further amplification
and transmission via the appropriate antenna.
On the reverse link the received signals are amplified, filtered, down-converted, sampled
and digitally processed. Digital data is then output to the WDM’s via the baseband bus
for further processing. Each WBX contains two receiver line-ups, for the main and
diversity branches. The WBX also supports transmit diversity
One WRX is required per cell and typically an additional, redundant device can be fitted.
Linear Power
Amplifier (LPA)
The Linear Power Amplifier (LPA) subsystem consisting of either 3 or 6 hybrid matrixed
power amplifiers. Each amplifier should be though of as part of an overall power
amplification resource which can be distributed between sectors and carriers to provide
power amplifier trunking. The trunked LPA subsystem can be configured to support omni,
three and six sector configurations, as well as allowing the site to be reconfigured to
meet new operator requirements. The input matrix accepts the composite signals for
each sector for amplification. Up to six LPA modules contribute to amplifying all signals
presented at the input ports. The output matrix ensures proper distribution of the
amplified signals to the correct sector output, whist minimising the amount of energy
presented at the other sector outputs.
NOT BE UPDATED
Issue 4 Revision 0 Node B
Node B Architecture
1 3
123
Iub
WDM(s) 2 I/P O/P 2 To
123 Matrix
WBX Matrix Antenna
3 1
123
Trunked
linear
CP13_2_7a

NOT BE UPDATED
User Equipment (UE) Issue 4 Revision 0
User Equipment (UE)

Different types of mobile are being designed, they could include the following;
Dual-Mode Capability
Multi-Mode Capability
Video Capture and Replay
Built-in Cameras
Handwriting and Voice Recognition
Bluetooth, WAP Browser, Peripheral Interface Module (PIM)
Internet Audio Player, Games
Location Capability
Unified Messaging
NOT BE UPDATED
Issue 4 Revision 0 User Equipment (UE)
User Equipment
· Dual–Mode Capability
· Multi–Mode Capability
· Video Capture and Replay
· Built–in Camera
· Handwriting and Voice Recognition
· Bluetooth, WAP Browser
· Internet, Audio Player, Games
· Location Capability
· Unified Messaging
CP13_Ch2_09

NOT BE UPDATED
Network Evolution
The ultimate target of 3GPP is to drive UMTS towards an all Internet Protocol (IP)
architecture. The exact detail of this architecture is still under development and will the
subject of staged “future” releases of 3GPP Technical Specifications, Known as Release
4 (previously known as Release 2000) and Release 5, the later scheduled to be
completed by the end of 2001, followed by a three to six month Change Request period.
Motorola will track this evolution through its Aspira core network (GSN) product, which
will also evolve in a series of stages to deliver aspects of ‘all-IP’ functionality. The
Aspira all IP system, shown in the diagram opposite, complies with UMTS all-IP
specifications as defined by 3GPP.
Product
evolution
There are four stages in the evolution of the GSN from Release 99 to Release 2000:
Using IP options on the open interfaces

Since most of the GPRS core network interfaces are already based on IP, this is a
relatively straightforward change. For the GSN, the Iu-ps interface operates using a
different protocol stack for signalling which uses SCTP protocol rather than C7 MTP3b at
the lower layer.
This can be implemented by a software upgrade for both GSN and RNC. Additionally,
GSM MAP messages can also be routed via SCTP rather than C7 MTP allowing IP to
carry all signalling traffic. This would require software upgrade within the GSN, and the
addition of a signalling gateway at the edge of the network to interwork between the C7
and IP protocol stacks.
Initially, this reduces the need for operators to maintain a separate and expensive C7
signalling network. Longer term, it also allows inter-network signalling traffic to be routed
via IP which can be secured using IPSec, both saving costs and increasing security. For
interoperability with other vendors, existing Release 99 interfaces are retained as a
configurable option.
Separation of bearer and control

Our GSN architecture follows the current GPRS standard that uses the same SGSN
node to handle both signalling and bearer traffic, although these are physically processed
on different cards.
By ensuring there are separate routes and processing cards for both types of traffic, a
higher capacity, more scalable, efficient and resilient GSN architecture can be realised.
This will be achieved by scaling a GSN separately for signalling load (based on number
of subscribers, context activations etc) and for bearer load (based on number of packets
per second, total throughput etc). A distributed GSN is also enabled at this stage, with
redundant routers providing 99.999% system availability using some 99.9% availability
components.
NOT BE UPDATED
Network Evolution
PDN – include real PSTN MAP, Other

time traffic using Voice CAMEL, PLMN
multimedia control INAP GSNs
such as SIP or H.323
GGSNu PSTN C7 Border
Gateway Gateway Gateway Gateway
Gateways
Network Control Elements

OMCs Management
Radio Elements GPRS/UMTS Call State Control Function HSS/
SGSN Inranet Call Control + SGSN functionality SDB
GGSN OMCs
Transport IP Intranet
MExE Application
Iu (cs & ps) Servers
WAP
Iur
Other RAN RNC Servers SDUs Location
IP/ATM
3G RAN Prepaid
Node B Node B Node B Feature Servers

CP13_Ch2_08a.ai

NOT BE UPDATED
Adding Iu-cs and MSC functionality

Adding further processing cards within the GSN, supplemented by a PSTN Gateway,
extends the GPRS core network to handle voice services and voice traffic without the
need for an MSC.
The evolved SGSN is termed the Call State Control Function (CSCF) and provides the
call control aspects, and along with the GGSN, also provide the functionality to allow
calls to and from IP end points that may be an IP-enabled phone, enterprise IP-based
PBX, PC, or any other voice-enabled IP device.
The PSTN gateway provides the interworking functionality for MS to PSTN, or PSTN to
MS calls. The PSTN gateway is the interface from the IP core network to the PSTN.
Processing within the gateway holds the vocoding algorithms for converting between a
voice call encapsulated in an air interface frame and PSTN Pulse-Code Modulation
(PCM).
HLR functionality is offered by our Home Subscriber Services (HSS) node, which also
provides secure provisioning of WAP/MExE services.
Adding access independent multimedia overlay

This major new network, the IP Multimedia Sub-system (IM), will require a number of
new elements, including packet and circuit gateways and further processing. The IM
overlay uses the SIP multimedia call model, DIAMETER or RADIUS authentication and
billing, and offers the same set of services across a wide range of access technologies.
New terminals, roaming agreements and services are required to take full advantage of
this technology, which takes full advantage of widespread IP deployment and
accessibility in this timeframe.
The architecture of the IM Sub-system are further detailed later in this chapter.
Application
Servers
In addition to providing telecommunications services (Voice and data) it is envisaged that
network operators will start to provide “Network Services”, such as Internet access,
e-mail facilities, etc. To provide these services, a range of applications servers will be
required.
Network services are covered in further detail in the next chapter.
NOT BE UPDATED
Network Evolution
PDN – include real PSTN MAP, Other

time traffic using Voice CAMEL, PLMN
multimedia control INAP GSNs
such as SIP or H.323
GGSNu PSTN C7 Border
Gateway Gateway Gateway Gateway
Gateways
Network Control Elements

OMCs Management
Radio Elements GPRS/UMTS Call State Control Function HSS/
SGSN Inranet Call Control + SGSN functionality SDB
GGSN OMCs
Transport IP Intranet
Application
MExE
Iu (cs & ps) Servers
WAP
Iur
Other RAN RNC Servers SDUs Location
IP/ATM
3G RAN Prepaid
Node B Node B Node B Feature Servers

CP13_Ch2_08a.ai

NOT BE UPDATED
Release 4/5 Architecture Issue 4 Revision 0
Release 4/5 Architecture

The basic reference architecture configuration of a Release 4/5Public Land Mobile
Network (PLMN) supporting UMTS and GPRS, and the interconnection to the
PSTN/ISDN and PDN is presented in the diagram opposite. This configuration presents
signalling and user traffic interfaces which can be found in a PLMN. The figure shows
direct interconnections between the entities.
The actual links may be provided by an underlying network (e.g. SS7 or IP).
Implementations may be different: some particular functions may be gathered in the
same equipment and then some interfaces may become internal interfaces. Differences
from the R1999 Architecture are detailed below.
MSC Server
The MSC Server mainly comprises the call control (CC) and mobility control parts of a
MSC. The MSC Server is responsible for the control of mobile originated and mobile
terminated CC CS Domain calls. It terminates the user-network signalling and translates
it into the relevant network – network signalling. The MSC Server also contains a VLR to
hold the mobile subscriber’s service data. The MSC Server controls the parts of the call
state that pertain to connection control for media channels in a CS-MGW.
Gateway MSC
Server (GMSC
Server)
The GMSC server mainly comprises the call control and mobility control parts of a
GMSC.
Circuit Switched
– Media Gateway
Function
(CS-MGW).
This component is PSTN/PLMN transport termination point for a defined network and
interfaces UTRAN with the core network over Iu. A CS-MGW may terminate bearer
channels from a switched circuit network and media streams from a packet network (e.g.,
RTP streams in an IP network). Over Iu, the CS-MGW may support media conversion,
bearer control and payload processing (e.g. codec, echo canceller, conference bridge) for
support of different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP
based).
The CS-MGW will be provisioned with the necessary resources for supporting
UMTS/GSM transport media. Further tailoring (i.e packages) of the H.248 may be
required to support additional codecs and framing protocols, etc. The CS-MGW bearer
control and payload processing capabilities will also need to support mobile specific
functions such as SRNS relocation/handover and anchoring. It is expected that current
H.248 standard mechanisms can be applied to enable this.
NOT BE UPDATED
Issue 4 Revision 0 Release 4/5 Architecture
Release 4-5 Architecture
PSTN Go
PSTN
T–SGW R–SGW Gi
Mh
CS– GMSC GGSN
MGW Mc Server
C
Gc
Gp
PSTN HSS (HLR) AuC
H
Nc
N
EIR
D
G
VLR E VLR F Gf
B B SGSN
MSC server MSC Server Gs
Nc
IuCS
Mc
Mc
IuCS Gb IuPS
CS–MGW CS–MGW
Nb
IuCS A
A IuCS
BSC RNC RNC

Iur
BSS Iub Iub RNS
Abis IuPS
Node B Node B
BTS BTS Cell
U
Um
SIM–ME MS
i/f Cu
SIM Me USIM
Thick Lines
I/Fs supporting user traffic
Thin Lines
I/Fs supporting signalling
Dotted lines
I/Fs only implemented at R5
CP13_Ch2_09a.ai

NOT BE UPDATED
The Home
Subscriber
Server (HSS)
The HSS substitutes the HLR when the IM subsystem is implemented. The Home
Subscriber Server (HSS) is the master database for a given user. It is the entity
containing the subscription related information to support the network entities actually
handling calls/sessions. As an example, HSS could provide support to the call control
servers in order to complete the routing/roaming procedures by solving authentication,
authorisation, naming/addressing resolution, location dependencies, etc…
Transport
Signalling
Gateway
Function
(T-SGW)
The T-SGW Maps SS7 User Part call related signalling from/to PSTN/PLMN on an IP
bearer and sends it to/from the MSC servers. The T-SGW is also used to provide
PSTN/PLMN <-> IP transport level address mapping.
Roaming
Signalling
Gateway
Function
(R-SGW)
The R-SGW performs the signalling conversion (both ways) at transport level between
the SS7 based transport of signaling used in pre-Rel 4 networks, and the IP based
transport of signalling possibly used in post-R99 networks (Sigtran SCTP/IP versus SS7
MTP). The R-SGW does not interpret the MAP / CAP messages but may have to
interpret the underlying SCCP layer to ensure proper routing of the signaling.
For the support of pre-Rel 4 CS terminals, the services of the R-SGW are used to ensure
transport interworking between the SS7 and the IP transport of MAP-E and MAP-G
signalling interfaces with a pre-Rel 4 MSC/VLR.
NOT BE UPDATED
Issue 4 Revision 0 Release 4/5 Architecture
Release 4–5 Architecture
PSTN Go
PSTN
T–SGW R–SGW Gi
Mh
CS– GMSC GGSN
MGW Mc Server
C
Gc
Gp
PSTN HSS (HLR) AuC
H
Nc
N
EIR
D
G
VLR E VLR F Gf
B B SGSN
MSC server MSC Server Gs
Nc
IuCS
Mc
Mc
IuCS Gb IuPS
CS–MGW CS–MGW
Nb
IuCS A
A IuCS
BSC RNC RNC

Iur
BSS Iub Iub RNS
Abis IuPS
Node B Node B
BTS BTS Cell
U
Um
SIM–ME MS
i/f Cu
SIM Me USIM
Thick Lines
I/Fs supporting user traffic
Thin Lines
I/Fs supporting signalling
Dotted lines
I/Fs only implemented at R5
CP13_Ch2_09a.ai

NOT BE UPDATED
NOT BE UPDATED
Chapter 3
Network Services

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 3
Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Introduction to Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Classification of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Circuit Teleservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Circuit Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Supplementary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Packet Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Other Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Value Added Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
IP multimedia services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Interactive Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Distribution services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Architectural Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Service Node and Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Service Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
Data Determination for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
QoS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
The Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Distribution of authentication data from HE to SN . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Ciphering Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
F8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
F9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
Generation of Authentication Vectors/Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
SQN and RAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Authentication Key Management Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Algorithms f1 –f5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
AUTN and AV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
USIM Authentication Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Retrieval of SQN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Computation of X–MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Verification of SQN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Computation of CK and IK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
User Authentication Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–34
Access Link Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
Data integrity protection method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
Input parameters to the integrity algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36

NOT BE UPDATED
Issue 4 Revision 0
Ciphering of User/Signalling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38

Input parameters to the cipher algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38
NOT BE UPDATED
Objectives
Describe some of the Network Services offered by UMTS.

NOT BE UPDATED
Introduction to Network Services Issue 4 Revision 0
Introduction to Network Services

This chapter describes the Service Principles for PLMNs specified by 3GPP.
3GPP specifications provide integrated personal communications services. The system
will support different applications ranging from narrow-band to wide-band
communications capability with integrated personal and terminal mobility to meet the user
and service requirements of the 21st century.
3GPP specifications allow the realisation of a new generation of mobile communications
technology for a world in which personal communications services should allow
person-to-person calling, independent of location, the terminal used, the means of
transmission (wired or wireless) and the choice of technology. Personal communication
services should be based on a combination of fixed and wireless/mobile services to form
a seamless end-to-end service for the user.
3GPP specifications outline the following objectives:
To provide a single integrated system in which the user can access services in an
easy to use and uniform way in all environments
To allow differentiation between service offerings of various serving networks and
home environments.
To provide a wide range of telecommunications services, including those provided
by fixed networks and requiring user bit rates of up to 2 Mbits/s, as well as
services special to mobile communications. These services should be supported in
residential, public and office environments and in areas of diverse population
densities. These services are provided with a quality comparable with that
provided by fixed networks such as ISDN.
To provide services via hand held, portable, vehicular mounted, movable and fixed
terminals (including those which normally operate connected to fixed networks), in
all environments (in different service environments – residential, private domestic
and different radio environments) provided that the terminal has the necessary
capabilities.
To provide support of roaming users by enabling users to access services provided
by their home environment in the same way even when roaming.
To provide audio, data, video and particularly multimedia services.
To provide for the flexible introduction of telecommunication services.
To provide within the residential environment the capability to enable a pedestrian
user to access all services normally provided by fixed networks.
To provide within the office environment the capability to enable a pedestrian user
to access all services normally provided by PBXs and LANs
To provide a substitute for fixed networks in areas of diverse population densities,
under conditions approved by the appropriate national or regional regulatory
authority.
To provide support for interfaces which allow the use of terminals normally
connected to fixe networks.
NOT BE UPDATED
Issue 4 Revision 0 Introduction to Network Services
UMTS Service Objectives
Single integrated system

Differentiation between service offerings of various serving networks and
home environments.
A wide range of telecommunications services.
Services via hand held, portable, vehicular mounted, movable and fixed
terminals networks, in all environments
Support of roaming users
Audio, data, video and particularly multimedia services.
Provide for the flexible introduction of telecommunication services.
Within the residential environment, all services normally provided by fixed
networks.
Within the office environment, all services normally provided by PBXs and
LANs
Provide a substitute for fixed networks
Support interfaces which allow the use of terminals normally connected to
fixed networks.

NOT BE UPDATED
Classification of Services Issue 4 Revision 0
Classification of Services
The diagram opposite illustrates the general classification of network services that will be
supported by a UMTS network. Note that some of these services may not be provided
until R4 or R5 of the 3GPP specs are implemented.
Circuit
Teleservices
In the CS CN domain, the basic services are Circuit Teleservices (TS 22.003). Circuit
teleservices provide the full capacity for communication by means of terminals and
network functions and possibly functions provided by dedicated centres. Defined Circuit
Teleservices are:
Speech (point to point).
Speech (Voice Group Call and Voice Broadcast).
Short Message Service (Point to Point and Cell Broadcast).
Facsimile (Group 3).
Circuit Bearer
Services
Circuit bearer services support the capability to transmit data between user-network
access points. The Bearer Services can be grouped into the following categories:
Unrestricted Digital Information (UDI);

transfer of information sequence of bits at its specified bit rate without alteration; this
implies bit sequence independence, digit sequence integrity and bit integrity.
3,1 kHz (External to the PLMN);
Used to select a “3,1 kHz audio” interworking function at the MSC. This service category
is used when interworking with the ISDN or PSTN “3,1 kHz audio” service and includes
the capability to select a modem at the interworking function. “External to the PLMN”
indicates that the “3,1 kHz audio” service is only used outside of the PLMN, in the
ISDN/PSTN. The connection within the PLMN, user access point to the interworking
function, is an unrestricted digital connection.
All Bearer Service categories provide information transfer between the reference points
and allow the use of sub-rate information streams which are rate-adapted.
The table below shows the Circuit Bearer services available.
Bearer Service Access Access Rate Information QOS

Name Structure Transfer Attribute
Capability
Asynchronous Asynch Up to 64 kb/s 3.1 kHz, UDI NT/T
General Bearer
Service
Synchronous General Synch Up to 64 kb/s 2.1 kHz, UDI T
Bearer Service
NOT BE UPDATED
Issue 4 Revision 0 Classification of Services
Supplementary
services
(22,004)
IP Value added
Multimedia non–call related
Services services
SI (e.g. e–mail, Toolkits:
(e.g. telephone MMS, Circuit CAMEL
chat, WWW, news, teleservices MExE
whiteboard) etc.) (22,003) (U)SAT
OISP
Telephony LCS
Fax ”Internet tools”
SMS etc. . . .
Other
Packet Bearer Circuit Bearer
Data services Services
Bearer (SMS, UUS, (22,002)
(22,060) USS)
CP13_3_2a

NOT BE UPDATED
Supplementary
Services
A supplementary service modifies or enhances a basic Telecommunication service and,
hence, cannot be offered to a subscriber on a standalone basis. It must be offered
together with or in association with a basic Telecommunication service. The same
supplementary service may be offered with a number of different Telecommunication
services.
Examples of supplementary services are; Call Forwarding Unconditional, Call Forwarding
on No Reply, Call Waiting, Call Hold, Closed User Group, Advice of Charge (Information).
Packet Bearer
Services
The GPRS allows the service subscriber to send and receive data in an end-to-end
packet transfer mode, without utilizing network resources in circuit switched mode.
GPRS enables the cost effective and efficient use of network resources for packet mode
data applications e.g. for applications that exhibit one or more of the following
characteristics:
I
Intermittent, non-periodic (i.e., bursty) data transmissions, where the time between
successive transmissions greatly exceeds the average transfer delay.
Frequent transmissions of small volumes of data, for example transactions
consisting of less than 500 octets of data occurring at a rate of up to several
transactions per minute.
Infrequent transmission of larger volumes of data, for example transactions
consisting of several kilobytes of data occurring at a rate of up to several
transactions per hour.
Other Bearer
Services
SMS, Unstructured Supplementary Services Data (USSD) and User to user Signalling
(USS) can also be considered as bearer services for some applications, (e.g as a bearer
for WAP services.
Value Added
Services
Value added non-call related services include a large variety of different operator specific
services/applications. They are usually not specified by 3GPP. The services can be
based on fully proprietary protocols or standardised protocols outside 3GPP.
Toolkits
In order to create or modify the above services (both call and non-call related services)
operators may utilise toolkits standardised by 3GPP (such as CAMEL or LCS) or external
solutions (e.g. Internet mechanisms). Pre-paid is an example of an application created
with toolkits that may apply to all of the above services categories.
NOT BE UPDATED
Supplementary
services
(22,004)
IP Value added
Services services
OISP
Telephony LCS
SMS etc. . . .
Other
(22,060) USS)
CP13_3_2a

NOT BE UPDATED
IP multimedia
services
IP Multimedia (IM) services are the IP based session related services, including voice
communications. IP multimedia sessions use the Packet Bearer services as a bearer.
Multimedia services combine two or more media components (e.g. voice, audio, data,
video, pictures) within one call. A multimedia service may involve several parties and
connections (different parties may provide different media components) and therefore
flexibility is required in order to add and delete both resources and parties.Multimedia
services are typically classified as interactive or distribution services.
Interactive
Services
Interactive services are typically subdivided into conversational, messaging and retrieval
services:
Conversational services
Conversational services are real time (no store and forward), usually bi-directional where
low end to end delays (< 100 ms) and a high degree of synchronisation between media
components (implying low delay variation) are required. Video telephony and video
conferencing are typical conversational services.
Messaging services
Messaging services offer user to user communication via store and forward units
(mailbox or message handling devices). Messaging services might typically provide
combined voice and text, audio and high-resolution images.
Retrieval services
Retrieval services enable a user to retrieve information stored in one or many information
centres. The start at which an information sequence is sent by an information centre to
the user is under control of the user. Each information centre accessed may provide a
different media component, e.g. high resolution images, audio and general archival
information.
Distribution
services
Distribution services are typically subdivided into those providing user presentation
control and those without user presentation control.
Distribution services without user control

Distribution services without user control are broadcast services where information is
supplied by a central source and where the user can access the flow of information
without any ability to control the start or order of presentation e.g. television or audio
broadcast services.
Distribution services with user control

Distribution services with user control are broadcast services where information is
broadcast as a repetitive sequence and the ability to access sequence numbering
allocated to frames of information enables the user (or the user’s terminal) to control the
start and order of presentation of information.
NOT BE UPDATED
Supplementary
services
(22,004)
IP Value added
Services services
OISP
Telephony LCS
SMS etc. . . .
Other
(22,060) USS)
CP13_3_2a

NOT BE UPDATED
Architectural Structure Issue 4 Revision 0
Architectural Structure
The logical and physical structures are different within UMTS as we are using a
packet-based technology for transporting information. This allows elements to be
grouped logically and processing reduced while using cheap transmission and
processing. This slide highlights the configuration which will be built upon over the
coming months.
Service Node and

Network
The Service Nodes will provide access to the Service Network that will provide
approximately 50% of the revenue of the network. They will contain up to 100 computer
like devices with vast arrays of functions and media. For reliability they will be dispersed
geographically, yet providing one logical node or point of connection for the terminals.
The Service Network is built around a number of standard interfaces. These standard
interfaces are provided by the NO and could be used by third parties (MVNO, CP or SP).
This allows the development of services to be faster than using bespoke servers and
platforms.
This list provides an indication of the Application Program Interface (API) which will be
created. These APIs will be owned maintained by the NO. Patents and standardisation
will occur to ensure service portability across networks and services.
MVNO - Mobile Virtual network Operator

CP – Content Provider
SP – Service Provider
UTRAN
The UTRAN is the radio network which all UMTS terminals will access the services and
other networks.
Core Network
The core network is a large ATM or IP Network that provides a very large amount of
bandwidth for the transport of packets from the UTRAN to the service nodes.
NOT BE UPDATED
Issue 4 Revision 0 Architectural Structure
Architectural Structure
Service Node
Service Network
Service Network
IP Core Network
IP, VoIP, ATM
PSTN
Iu
Other
Networks
Utran
Internet ATM
CP13_Ch3_01

NOT BE UPDATED
Service Network Issue 4 Revision 0
Service Network
This is a typical configuration for the Service Network, allowing a wide range of IP based
services to be deployed. This hardware design allows a highly reliable service provision.
The description of all these elements is outside the scope of the course, however they
play a very important part in the collection and maintenance of revenue within a UMTS
network.
SMTP/Mail Server provide email to users.
WAP Proxy provides a protocol translation between the internet and the mobile
phone micro-browser.
HTTP/FTP/CGI handle the various protocols.
Portal Server holds and provides the portal to the users.
e-Commerce server deals with finance transactions.
Location server connects into the UTRAN to provide location information towards
the users and service platform.
PKI handle security between user applications and servers.
LDAP server provide an interface to the personalization database and HLR.
Radius provide authentication in dial-up mode.
DHCP allocates IP address.
Application server contains the local applications and services.
SMTP Simple Mail Transfer Protocol

WAP Wireless Application Protocol
POP Post Office Protocol
IMAP Internet Message Access Protocol
CGI Common Graphical Interface
XML Extensible Markup Language
Portal Entry to Users
PIM Personal Information Server
PKI Public Key Infrastructure
LDP Lightweight Directory Protocol
SMIL Synchronous Multimedia Integration Language
LSAP Link Data Application Protocol
NOT BE UPDATED
Issue 4 Revision 0 Service Network
Service Network
Protocols Support
SMS/MMS
WAP Proxy Portal Gateway
Application
HTTP XML Backup
Server
DHCP Radius
FTP SMTP Server Server
POP/MAP HTTP
CGI Cache
Proxy Proxy
Location
Billing Servers
Server
Load PKI Server PIM
Balancer
Mail E–Commerce
Firewell SMS Server
Server Server
LDAP Multi–Device
Router SynchML
Server Server
UMTS Core
Network
CP13_Ch3_02

NOT BE UPDATED
Load Balancing Issue 4 Revision 0
Load Balancing
Load balancing is another important element in the design of the service network. It
provides the ability to share processing resources over a number of computers without
the client having any knowledge of the usage base or destination.
The general purpose of a load balancing solution is to allow you to replace one single
server with a group of servers. The load balancing device does this in such a way that, to
the outside world, the entire group looks like a single server.
Replacing a single server with a load balanced group of servers can provide several
benefits:
Improves reliability (fault tolerance)

If you are using a single server and it fails, the site goes down. This is critical for
e-commerce and financial sites which lose money if they are out of service. The term for
this is single point of failure. With a load balanced group of servers (cluster), loss of a
single server will only slightly affect overall site performance and the site will not go
down.
Improves performance
If you are using a single server and it becomes overloaded, the result is degraded
performance for all of your customers. Load balancing allows multiple servers (a cluster)
to be available to handle incoming client requests. New requests should be routed to
servers most able to handle them and away from slower servers.
Improves scalability and flexibility

With one server, all you can do if your traffic increases is upgrade that server or buy a
faster one. With one or more load-balanced groups of servers, you can simply add more
servers gracefully to whichever cluster needs to support more traffic. Servers can also
easily be reassigned from one cluster to another as traffic patterns change.
Lowers cost
With load balancing providing fault tolerance to the entire site, the reliability of each
individual server is less critical. Since the failure of individual servers will not substantially
affect the entire site, you can use lower-cost servers without compromising overall
reliability. Of course, the improved reliability also eliminates costly service outages
caused by server failures.
NOT BE UPDATED
Issue 4 Revision 0 Load Balancing
Load Balancing
· Improves Reliability
· Improves Performance
· Improves Scalability and Flexibility
· Lowers overall cost
CP13_Ch3_03

NOT BE UPDATED
Data Rates Issue 4 Revision 0
Data Rates
The data rates and the speed of the user are related. An increase in the data rate
requires higher capacity and if users are moving faster, an increase in the number of
cells.
The UMTS system will be dominated by data services of various medias. The use of
terminals will increase the need for terminal to terminal data connections without the
classic server fixed in the network. Due to the data rate and the advances in codecs the
quality of the voice will increase. The provision of the services and the mix of these
services will help distribute them to the mass market.
NOT BE UPDATED
Issue 4 Revision 0 Data Rates
Maximum Data Rates
· Max 144 Kbps for Fast Moving (<500 km/h)
· Max 384 Kbps for Low Speed (<100 km/h)
· Max 2 Mbps for Static (<10 km/h)
CP13_Ch3_08

NOT BE UPDATED
Data Determination for Applications Issue 4 Revision 0
Data Determination for Applications

The idea behind the Iu interface is to allow a future proof core/mobile network interface.
The main area of concern has been the media that will be transferred across it. This
diagram captures some of the communications that the Iu set of interfaces will have to
carry.
NOT BE UPDATED
Issue 4 Revision 0 Data Determination for Applications
Data Determination for Applications
Mobile Multimedia Broadcast

2M Database Access
Video Internet Remote medical Information

Conference Access service Distribution Mobile TV
(High Quality) (Medical image) Video on Services
384K Video demand
Catalogue – Sports News
Video Shopping – News
Conference WWW – Movies Weather
64K (Low Quality) Forecast
e–mail Electronic ISDN Traffic

Newspaper Karaoke Mobile
Information Radio
32K ftp
Telephone Voice pager
Conference Mail Sports
IP Electronic Information
16K Publishing
telephony Leisure Image
9.6K
Electronic Information
Telephone etc FAX Data
2.4K Mail
Voice
1.2K
Symmetric Asymmetric Multicast
Point to Point Multi Point
CP13_Ch3_09

NOT BE UPDATED
Quality of Service Issue 4 Revision 0
Quality of Service
Network Services are considered end-to-end, this means from a Terminal Equipment
(TE) to another TE. An End-to-End Service may have a certain Quality of Service (QoS)
which is provided for the user of a network service. It is the user that decides whether he
is satisfied with the provided QoS or not. To realise a certain network QoS a Bearer
Service with clearly defined characteristics and functionality is to be set up from the
source to the destination of a service. The diagram opposite illustrates the QoS classes
for UMTS.
The main distinguishing factor between these QoS classes is how delay sensitive the
traffic is: Conversational class is meant for traffic which is very delay sensitive while
Background class is the most delay insensitive traffic class.
Conversational and Streaming classes are mainly intended to be used to carry real-time
traffic flows. Interactive class and Background are mainly meant to be used by traditional
Internet applications like WWW, Email, Telnet, FTP and News. Due to looser delay
requirements, compared to conversational and streaming classes, both provide better
error rate by means of channel coding and retransmission.
Conversational Class
The most well known use of this scheme is telephony speech (e.g. GSM). But with
Internet and multimedia a number of new applications will require this scheme, for
example voice over IP and video conferencing tools. Real time conversation is always
performed between peers (or groups) of live (human) end-users. This is the only scheme
where the required characteristics are strictly given by human perception.
Streaming Class
This scheme is one of the newcomers in data communication, raising a number of new
requirements in both telecommunication and data communication systems. It is
characterised by that the time relations (variation) between information entities (i.e.
samples, packets) within a flow shall be preserved, although it does not have any
requirements on low transfer delay. The delay variation of the end-to-end flow shall be
limited, to preserve the time relation (variation) between information entities of the
stream. When the user is looking at (listening to) real time video (audio) the scheme of
real time streams applies. The real time data flow is always aiming at a live (human)
destination. It is a one way transport.
Interactive class
Interactive traffic is the other classical data communication scheme that on an overall
level is characterised by the request response pattern of the end-user. At the message
destination there is an entity expecting the message (response) within a certain time.
Round trip delay time is therefore one of the key attributes. Another characteristic is that
the content of the packets shall be transparently transferred (with low bit error rate).
Examples are: web browsing, data base retrieval, server access.
Background Task
Background traffic is one of the classical data communication schemes that on an overall
level is characterised by that the destination is not expecting the data within a certain
time. The scheme is thus more or less delivery time insensitive. Another characteristic is
that the content of the packets shall be transparently transferred (with low bit error rate).
Examples are background delivery of E-mails, SMS, download of databases and
reception of measurement records.
NOT BE UPDATED
Issue 4 Revision 0 Quality of Service
Quality of Services
Quality of Service Classes

Conversation
Voice
Video
Maximum bitrate
Guaranteed bitrate
Delivery order
Streaming
Multimedia Maximum SDU size
SDU format information bits
SDU error ratio
Residual bit error ratio
Interactive Delivery of erroneous SDUs
Network Games Transfer Delay
Web Browsing Traffic Handling Priority
Allocation/Retention Priority
Background
Background e–mail
download
CP13_Ch3_9a.ai

NOT BE UPDATED
QoS Attributes Issue 4 Revision 0
QoS Attributes
UMTS bearer service attributes describe the service provided by the UMTS network to
the user of the UMTS bearer service. A set of QoS attributes (QoS profile) specifies this
service.
Maximum bitrate (kbps)

Maximum number of bits delivered by UMTS and to UMTS at a SAP within a period of
time, divided by the duration of the period.
Guaranteed bitrate (kbps)

Guaranteed number of bits delivered by UMTS at a SAP within a period of time (provided
that there is data to deliver), divided by the duration of the period.
Delivery order (y/n)

Indicates whether the UMTS bearer shall provide in-sequence SDU delivery or not.
Maximum SDU size (octets)

The maximum allowed SDU size.
SDU format information (bits)

List of possible exact sizes of SDUs
SDU error ratio

Indicates the fraction of SDUs lost or detected as erroneous. SDU error ratio is defined
only for conforming traffic.
Residual bit error ratio

Indicates the undetected bit error ratio in the delivered SDUs. If no error detection is
requested, Residual bit error ratio indicates the bit error ratio in the delivered SDUs.
Delivery of erroneous SDUs (y/n/–)

Indicates whether SDUs detected as erroneous shall be delivered or discarded.
Transfer delay (ms)

Indicates maximum delay for 95th percentile of the distribution of delay for all delivered
SDUs during the lifetime of a bearer service, where delay for an SDU is defined as the
time from a request to transfer an SDU at one SAP to its delivery at the other SAP.
Traffic handling priority

Specifies the relative importance for handling of all SDUs belonging to the UMTS bearer
compared to the SDUs of other bearers.
Allocation/Retention Priority
Specifies the relative importance compared to other UMTS bearers for allocation and
retention of the UMTS bearer. The Allocation/Retention Priority attribute is a subscription
attribute which is not negotiated from the mobile terminal.
NOT BE UPDATED
Issue 4 Revision 0 QoS Attributes
UMTS Bearer QoS Attributes
Traffic Class Conversational Streaming Interactive Background

class class class class
Maximum bitrate X X X X
Delivery order X X X X
Maximum SDU size X X X X
SDU format information X X
SDU error ratio X X X X
Residual bit error ratio X X X X
Delivery of erroneous SDUs X X X X
Transfer delay X X
Guaranteed bit rate X X
Traffic handling priority X
Allocation/Retention priority X X X X
CP13_Ch3_10a.ai

NOT BE UPDATED
The Security Architecture Issue 4 Revision 0
The Security Architecture

Five security feature groups are defined. Each of these feature groups meets certain
threats, accomplishes certain security objectives:
Network access security (I): the set of security features that provide users with secure
access to 3G services, and which in particular protect against attacks on the (radio)
access link.
Network domain security (II): the set of security features that enable nodes in the
provider domain to securely exchange signalling data, and protect against attacks on the
wireline network.
User domain security (III): the set of security features that secure access to mobile
stations.
Application domain security (IV): the set of security features that enable applications in
the user and in the provider domain to securely exchange messages.
Visibility and configurability of security (V): the set of features that enables the user to
inform himself whether a security features is in operation or not and whether the use and
provision of services should depend on the security feature.
NOT BE UPDATED
Issue 4 Revision 0 The Security Architecture
The Security Architecture
Application
Stratum
(IV)
User Application Provider Application
Home
(V) (III) (I) Stratum/
(I)
TE USIM HE Serving
Stratum
(II)
(I) (I)
SN
Transport
(I) Stratum
MT AN
CP13_Ch3_12

NOT BE UPDATED
Security and Privacy Issue 4 Revision 0
Security and Privacy

Use of Temporary Identifier - A temporary number rather than the permanent number
shall be used whenever possible to limit the possibility of detection. Like GSM IMSI.
Radio Channel Ciphering & Deciphering - protection of the information over the air
interface.
End to end ciphering specified as supplementary service but very hard to deliver - all
equipment must be inside network and terminals at each end must be compatible. How
would the other end know which key to use?
NOT BE UPDATED
Issue 4 Revision 0 Security and Privacy
Security and Privacy
· Use of Temporary Identifier
· Radio Channel Ciphering and Deciphering
· Use of Scrambling Codes
· Use of Channelization Codes
CP13_Ch3_13

NOT BE UPDATED
Authentication and Key Agreement Issue 4 Revision 0
Authentication and Key Agreement

Authentication and Key Agreement (AKA) achieves mutual authentication by the user
and the network showing knowledge of a secret key K which is shared between and
available only to the USIM and the AuC in the user’s HE. In addition the USIM and the
HE keep track of counters SEQMS and SEQHE respectively to support network
authentication. The method was chosen in such a way as to achieve maximum
compatibility with the current GSM security architecture and facilitate migration from
GSM to UMTS. The method is composed of a challenge/response protocol identical to
the GSM subscriber authentication and key establishment protocol combined with a
sequence number-based one-pass protocol for network authentication derived from the
ISO standard ISO/IEC 9798-4
Distribution of
authentication
data from HE to
SN
Upon receipt of a request from the VLR/SGSN, the HE/AuC sends an ordered array of n
authentication vectors (the equivalent of a GSM “triplet”) to the VLR/SGSN. Each
authentication vector consists of the following components: a random number RAND, an
expected response XRES, a cipher key CK, an integrity key IK and an authentication
token AUTN. Each authentication vector is good for one authentication and key
agreement between the VLR/SGSN and the USIM.
Authentication
and Key
Agreement
When the VLR/SGSN initiates an authentication and key agreement, it selects the next
authentication vector from the array and sends the parameters RAND and AUTN to the
user. The USIM checks whether AUTN can be accepted and, if so, produces a response
RES which is sent back to the VLR/SGSN. The USIM also computes CK and IK.
The VLR/SGSN compares the received RES with XRES. If they match the VLR/SGSN
considers the authentication and key agreement exchange to be successfully completed.
The established keys CK and IK will then be transferred by the USIM and the VLR/SGSN
to the entities which perform ciphering and integrity functions.
NOT BE UPDATED
Issue 4 Revision 0 Authentication and Key Agreement
Authentication and Key Agreement
MS SN/VLR HE/HLR
Authentication request
Distribution Generate
authentication vectors vectors AV (1 . . . n)
from HE to SN Authentication data response
AV (1 . . . n)
Store authentication vectors
Select authentication vectors

User authentication request
RAND(i) || AUTN(i)
Verify AUTN(i)
compute User authentication Authentication Key
RES(i)
Compare RES(i) and XRES(i)
Compute CK(i) and IK(i) Select CK(i) and IK(i)
CP13_Ch3_13a

NOT BE UPDATED
Ciphering Algorithms Issue 4 Revision 0
Ciphering Algorithms
The ciphering algorithms used in UMTS are shown on the slide opposite. As can be seen
a lot of different algorithms are active in the UMTS system. Algorithms f1 to f5 are of the
type that are used to compute numbers in use for authentication procedures, they will be
discussed in the UMTS Advanced courses.
Two very important algorithms, f8 and f9 are also shown, they have the following
functions.
F8
This algorithm will perform the ciphering function. The ciphering function is performed
either in the RLC sub-layer or in the MAC sub-layer according to the following rules:
If a radio bearer is using a non-transparent RLC mode (AM or UM), ciphering is
performed in the RLC sub-layer.
If a radio bearer is using the transparent RLC mode, ciphering is performed in the
MAC sub-layer (MAC-d entity).
Ciphering when applied is performed in the S-RNC and the ME and the context needed
for ciphering (CK, HFN, etc.) is only known in S-RNC and the ME.
F9
Most of the control signalling information elements that are sent between the MS and the
network are considered sensitive and must be integrity protected. Therefore a message
authentication function has been developed to solve this problem. The MS will still go
through the initial RRC connection establishment sequence and perform the set-up
security functions. After this however some signalling messages will be encoded using
the f9 algorithm. This will be the case for all RRC, MM, CC, GMM and SM Messages.
The MM procedure in the MS will be the process responsible for starting the integrity
protection procedure.
AK Anonymity Key
AKA Authentication and
key agreement
AUTN Authentication
Token
MAC The message
authentication code
included in AUTN,
computed using f1
XRES Expected Response
NOT BE UPDATED
Issue 4 Revision 0 Ciphering Algorithms
Ciphering Algorithms
· F1 – Message authentication function used to compute MAC
· F1* – Message authentication function used to compute MAC–S
· F2 – Message authentication function used to compute RES and XRES
· F3 – Key generating function used to compute CK
· F4 – Key generating function used to compute IK
· F5 – Key generating function used to compute AK in normal procedures
· F5* – Key generating function used to compute AK in re–synchronisation procedures
· K–Long–term secret key shared between the USIM and the AuC
· F8 – Data transfer between the UE and RNC
· F9 – Signalling elements between the UE and RNC
CP13_Ch3_14

NOT BE UPDATED
Generation of Authentication Vectors/Tokens Issue 4 Revision 0
Generation of Authentication Vectors/Tokens

Upon the receipt of the authentication data request from the VLR/SGSN, the HE may
have pre–computed the required number of authentication vectors and retrieve them
from the HLR database or may compute them on demand. The HE/AuC sends an
authentication response back to the VLR/SGSN that contains an ordered array of n
authentication vectors AV(1..n). The diagram opposite shows the generation of an
authentication vector AV by the HE/AuC.
SQN and RAND

The HE/AuC starts with generating a fresh sequence number SQN and an unpredictable
challenge RAND. SQNs are unique to each user (the HE/AuC keeps a counter: SQNHe
for each user) and are generated in batches, with a “time stamp” derived from a clock
giving universal time. RAND is a randomly generated number.
Authentication
Key Management
Field
An authentication and key management field AMF is used as a third input variable to the
algorithms and is also included in the authentication token of each authentication vector.
AMF may be used by the operator to “switch” functions in the USIM (e.g to indicate the
algorithm and key used to generate a particular authentication vector, or set the number
of entries in a Sequence list (the list size)
Algorithms f1 –f5
Subsequently the following values are computed using the various algorithms (f1 – f5):
<bs>A message authentication code MAC = f1K(SQN || RAND || AMF) where f1 is a
message authentication function.
An expected response XRES = f2K (RAND) where f2 is a (possibly truncated) message
authentication function.
A cipher key CK = f3K (RAND) where f3 is a key generating function.
An integrity key IK = f4K (RAND) where f4 is a key generating function.
An anonymity key AK = f5K (RAND) where f5 is a key generating function.<be>
AUTN and AV
Finally the authentication token (AUTN = SQN ⊕ AK || AMF || MAC) and the
authentication Vector (AV:=RAND||XRES||CK||IK||MAC) are constructed from the
products of the algorithms.
Here, AK is an anonymity key used to conceal the sequence number as the latter may
expose the identity and location of the user. The concealment of the sequence number is
to protect against passive attacks only. If no concealment is needed then f5 ≡ 0 (AK =
0).
NOT BE UPDATED
Issue 4 Revision 0 Generation of Authentication Vectors/Tokens
Generation of Authentication Vectors/Tokens
Generate SQN
Generate RAND
SQN RAND
AMF
K
f1 f2 f3 f4 f5
MAC XRES CK IK AK
AUTN := SQN ⊕ AK || AMF || MAC
AV := RAND || XRES || CK || IK || AUTN
CP13_Ch3_14a

NOT BE UPDATED
USIM Authentication Function Issue 4 Revision 0
USIM Authentication Function

The VLR/SGSN invokes the procedure by selecting the next unused authentication
vector from the ordered array of authentication vectors in the VLR/SGSN database. The
VLR/SGSN sends to the USIM the random challenge RAND and an authentication token
for network authentication AUTN from the selected authentication vector.
Upon receipt the user proceeds as shown in the diagram opposite.
Retrieval of SQN
Upon receipt of RAND and AUTN the USIM first computes the anonymity key AK = f5K
(RAND) and retrieves the sequence number SQN = (SQN ⊕ AK) ⊕ AK.
Computation of
X–MAC
Next the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with
MAC which is included in AUTN. If they are different, the user sends user authentication
reject back to the VLR/SGSN with an indication of the cause and the user abandons the
procedure. In this case, VLR/SGSN shall initiate an Authentication Failure Report
procedure towards the HLR. VLR/SGSN may also decide to initiate a new identification
and authentication procedure towards the user.
Verification of
SQN
Next the USIM verifies that the received sequence number SQN is in the correct range.
If the USIM considers the sequence number to be not in the correct range, it sends
synchronisation failure back to the VLR/SGSN including an appropriate parameter, and
abandons the procedure.
If the sequence number is considered to be in the correct range however, the USIM
computes RES = f2K (RAND) and includes this parameter in a user authentication
response back to the VLR/SGSN.
Computation of
CK and IK
Finally the USIM computes the cipher key CK = f3K (RAND) and the integrity key IK =
f4K (RAND). USIM shall store original CK, IK until the next successful execution of AKA.
User
Authentication
Response
Upon receipt of user authentication response the VLR/SGSN compares RES with the
expected response XRES from the selected authentication vector. If XRES equals RES
then the authentication of the user has passed. The VLR/SGSN also selects the
appropriate cipher key CK and integrity key IK from the selected authentication vector.
If XRES and RES are different, VLR/SGSN shall initiate an Authentication Failure Report
procedure towards the. VLR/SGSN may also decide to initiate a new identification and
authentication procedure towards the user.
NOT BE UPDATED
Issue 4 Revision 0 USIM Authentication Function
USIM Authentication Function
RAND AUTN
SQN ⊕ AK AMF
f5 MAC
⊕
AK
SQN
K
(USIM)
f1 f2 f3 f4
MAC XRES CK IK
Verify MAC = XMAC
Verify that SQN is in the correct range

CP13_Ch3_15a

NOT BE UPDATED
Access Link Data Integrity Issue 4 Revision 0
Access Link Data Integrity

Most control signalling information elements that are sent between the MS and the
network are considered sensitive and must be integrity protected. A message
authentication function shall be applied on these signalling information elements
transmitted between the ME and the RNC.
Data integrity
protection
method
The diagram opposite illustrates the use of the integrity algorithm f9 to authenticate the
data integrity of a signalling message. Based on the input parameters the user computes
message authentication code for data integrity MAC–I using the integrity algorithm f9.
The MAC–I is then appended to the message when sent over the radio access link. The
receiver computes XMAC–I on the message received in the same way as the sender
computed MAC–I on the message sent and verifies the data integrity of the message by
comparing it to the received MAC–I.
Input parameters
to the integrity
algorithm
COUNT–I
The integrity sequence number COUNT–I is 32 bits long. There is one COUNT–I value
per logical signalling channel. COUNT–I is derived from a count of the number of RRC
SDUs send/received.
IK
The integrity key IK is 128 bits long. There may be one IK for CS connections (IKCS) and
one IK for PS connections (IKPS). IK is established during UMTS AKA as the output of
the integrity key derivation function f4.
FRESH
The network–side nonce FRESH is 32 bits long. There is one FRESH parameter value
per user. The input parameter FRESH protects the network against replay of signalling
messages by the user. At connection set–up the RNC generates a random value FRESH
and sends it to the user in the (RRC) security mode command. The value FRESH is
subsequently used by both the network and the user throughout the duration of a single
connection. This mechanism assures the network that the user is not replaying any old
MAC–Is.
DIRECTION
The direction identifier DIRECTION is 1 bit long. The direction identifier is input to avoid
the use of identical set of input parameter values up–link and down–link messages. The
value of the DIRECTION is 0 for messages from UE to RNC and 1 for messages from
RNC to UE.
MESSAGE
The signalling message itself with the radio bearer identity. The latter is appended in front
of the message. Note that the radio bearer identity is not transmitted with the message
but it is needed to avoid that for different instances of message authentication codes the
same set of input parameters is used.
NOT BE UPDATED
Issue 4 Revision 0 Access Link Data Integrity
Access Link Data Integrity
COUNT–I DIRECTION COUNT–I DIRECTION

MESSAGE FRESH MESSAGE FRESH
IK f9 IK f9
MAC–I XMAC–I
Sender Receiver
UE or RNC RNC or UE
CP13_Ch3_16a

NOT BE UPDATED
Ciphering of User/Signalling Data Issue 4 Revision 0
Ciphering of User/Signalling Data

User data and some signalling information elements are considered sensitive and must
be confidentiality protected. To ensure identity confidentiality the temporary user identity
(P–)TMSI must be transferred in a protected mode at allocation time and at other times
when the signalling procedures permit it.
These needs for a protected mode of transmission are fulfilled by a confidentiality
function which is applied on dedicated channels between the ME and the RNC.
The diagram opposite illustrates the use of the ciphering algorithm f8 to encrypt plaintext
by applying a keystream using a bit per bit binary addition of the plaintext and the
ciphertext. The plaintext may be recovered by generating the same keystream using the
same input parameters and applying a bit per bit binary addition with the ciphertext.
Input parameters
to the cipher
algorithm
COUNT–C
The integrity sequence number COUNT–C is 32 bits long. There is one COUNT–C value
per logical signalling channel. COUNT–C is derived from a count of the number of
RLC/MAC SDUs send/received.
CK
The Cipher key CK is 128 bits long. There may be one CK for CS connections (CKCS)
and one CK for PS connections (CKPS). CK is established during UMTS AKA as the
output of the integrity key derivation function f3.
BEARER
The radio bearer identifier BEARER is 5 bits long.
There is one BEARER parameter per radio bearer associated with the same user and
multiplexed on a single 10ms physical layer frame. The radio bearer identifier is input to
avoid that for different keystream an identical set of input parameter values is used.
DIRECTION
The direction identifier DIRECTION is 1 bit long. The direction identifier is input to avoid
the use of identical set of input parameter values up–link and down–link messages. The
value of the DIRECTION is 0 for messages from UE to RNC and 1 for messages from
RNC to UE.
LENGTH
The length indicator LENGTH is 16 bits long. The length indicator determines the length
of the required keystream block. LENGTH shall affect only the length of the
KEYSTREAM BLOCK, not the actual bits in it.
NOT BE UPDATED
Issue 4 Revision 0 Ciphering of User/Signalling Data
Ciphering of User/Signalling Data
COUNT–C DIRECTION COUNT–C DIRECTION

BEARER LENGTH BEARER LENGTH
CK f8 CK f8
KEYSTREAM KEYSTREAM
BLOCK BLOCK
PLAINTEXT
BLOCK ⊕ CYPHERTEXT
BLOCK ⊕
Sender Receiver
UE or RNC RNC or UE
CP13_Ch3_17

NOT BE UPDATED
Ciphering of User/Signalling Data Issue 4 Revision 0
NOT BE UPDATED
Chapter 4
UMTS Protocols

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 4
UMTS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
General Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Horizontal Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Vertical Planes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
IuCS Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
IuPS Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Iub Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Iur Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Radio Interface Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
MAC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
MAC Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
MAC Layer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Mapping between logical and Transport channels . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Transport format selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Priority handling of Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Dynamic Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Identification of UEs on Common Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
MUX/DEMUX of PDUs into Transport Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Traffic Volume Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Dynamic Transport Channel Type Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
Access Service Class Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18
RLC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
RLC Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Transparent Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Transmitting Tr Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Receiving Tr Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Unacknowledged Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Acknowledged Data Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Packet Data Convergence Protocol (PDCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28

NOT BE UPDATED
Issue 4 Revision 0
Radio Interface for Broadcast/Multicast Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30

BMC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
RRC Layer Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Routing Function Entity (RFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Broadcast Control Function Entity (BCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Paging and Notification Control Function Entity (PNFE) . . . . . . . . . . . . . . . . . . . . 4–32
Dedicated Control Function Entity (DCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Shared Control Function Entity (SCFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Transfer Mode Entity (TME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
RRC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
User Plane Protocol Stack (Dedicated Channels CS–Domain) . . . . . . . . . . . . . . . 4–38
Dedicated Channel Frame Protocol (DCH FP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
Control Plane Protocol Stack (UE–CN SIGNALLING, Dedicated Channels, CS–Domain) . . . . . .
4–42
RANAP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
MTP3–B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
SAAL–NNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
(UE–CN Signalling, Shared Channels, CS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
RACH/FACH/ DSCH Frame Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
(Dedicated Channels, PS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
GPRS Tunnelling Protocol, User Plane (GTP–U) . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Path Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
(UE–CN Siganalling, Dedicated Channels, PS–Domain) . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
Stream Control Transmission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
NOT BE UPDATED
Objectives
Describe the General Protocol Model for UMTS.
Describe the Interface specific protocol structure for the following interfaces:
lu CS
lu PS
lu b
lu r
Uu

NOT BE UPDATED
General Protocol Model Issue 4 Revision 0
General Protocol Model

The Protocols in the UTRAN are designed according to a set protocol model. The
structure consists of Layers (Horizontal) and Planes (Vertical). All these entities are
independent of each other and can be changed at any time. It is also important to note
that these protocol stacks are not developed for specific entities e.g. BTS or Node-B etc,
but rather for the interfaces between these different entities. Let’s have a closer look at
the Layers and Planes.
Horizontal Layers
The General protocol stack only consists of two layers, the Transport Network Layer and
the Radio Network Layer. From the bottom, the Physical layer (Part of the Transport
Network Layer) will provide the physical medium for transmission. Above the Physical
layer is the Transport layer (Part of the Transport Network Layer) which contains the
transport protocols. These protocols are not defined within the UMTS specifications. The
Transport Network Protocol proposed for UMTS is ATM. The top layer is called the Radio
Network layer, this is the layer responsible for all UTRAN related tasks. The tasks
performed on Radio Network Layer are transparent to Transport Network Layer.
Vertical Planes
Control Plane
The Control plane only exists on L3 of the Horizontal planes and is responsible for all
UMTS specific signalling. The protocols used for the control plane are the RANAP
protocol for the Iu interface, the RNSAP protocol for the Iur interface and the NBAP
protocol for the Iub interface. These are all termed Application protocols and will be used
for tasks like setting up bearers to the UE. Operation & Maintenance actions will always
set up the signalling Bearers for the Application protocol.
User Plane
This plane is being used for transfer of all kinds of information e.g. multimedia, e-mail,
speech etc. The User Plane consists of the Data Stream that will be transported on the
Data Bearer. Each Data Stream is identified and characterised by one or more frame
protocols.
Transport Network Control Plane

This plane is used for all signalling that must be transferred in the Transport Layer and
does not include any Application Protocol signalling. The protocol use for the Control
Plane is called Access Link Control Application Protocol (ALCAP). This protocol will
handle the setting up of Data Bearers for transport of data on the Transport layer. The
introduction of the ALCAP protocol made it possible for the Application Protocols to run
with complete independence of the data bearing technology. It should be noted that we
shall not use the ALCAP protocol in real time operation in setting up of the Signalling
Bearer for Application Protocols and for ALCAP.
Transport Network User Plane

Both the Signalling Bearer in the Control Plane and the Data Bearer in the User Plane
belong to the Transport Network Layer. The Transport Network user planes are
configured by the ALCAP except when there is real time information that must be
transferred from the Application protocol. If this is the case the Signalling Bearer is
configured by O&M tasks.
NOT BE UPDATED
Issue 4 Revision 0 General Protocol Model
General Protocol Model
Control Plane User Plane

Radio
Network Application Data
Layer Protocol Stream(s)
Transport Network Transport Network Transport Network

User Plane Control Plane User Plane
Transport
ALCAP(S)
Network
Layer
Signalling Signalling Data

Bearer(s) Bearer(s) Bearer(s)
Physical Layer
CP13_Ch4_01

NOT BE UPDATED
IuCS Protocol Structure Issue 4 Revision 0
IuCS Protocol Structure

As can be seen form the IuCS protocol stack, it resembles the UMTS Protocol Model
very closely and so it will be the case for all other Interfaces. Two different layers can be
detected, the Transport Network Layer and the Radio Network Layer. The Physical layer
in the Transport Network Layer consist of normal OSI L1 specified protocols like E1,
STM, Fibre Optic or even Microwave. On OSI L2 is the ATM protocol, one thing to note is
that the first two layers will form a common bearer for all three planes above.
Control Plane
Protocol Stack
The Protocol used on the radio Network Layer is called Radio Access Network
Application Part (RANAP). This protocol will run on top of Broad Band SS7 protocols.
The function of this protocol includes the following:
SRNS relocation and Hard Handover procedures
Radio Access Bearer (RAB) Management. (Set-up, Maintenance and Clearing)
Reporting of unsuccessful data transfer for Charging Applications
Common ID Management
Paging of the UE’s
Transparent UE to CN transfers.
Security Mode Control with integrity checking.
Overload Management.
Management of reset procedures.
Location Management and Reporting.
On the Transport Network Layer the following protocols can be seen:
SCCP Signalling Connection Control Part
MTP3-b Message Transfer Part - Broadband
SAAL-NNI Signalling ATM Adaptation Layer for Network
to Network Interfaces
SSCF Service Specific Co-ordination functions
SSCOP Service Specific Connection Orientated
Protocol
AAL5 ATM Adaptation Layer 5
Transport
Network Control
Plane Protocol
Stack
The Transport Network Protocol Stack consists of Signalling protocols for setting up of
the AAL2 Connections in the User Plane. Again BB SS7 signalling protocols are being
used.
User Plane
Protocol Stack
This is a very simple combination of protocols with the User plane being directly on top of
AAL2, which is responsible for segmenting the data to ATM cells. Note that a dedicated
AAL2 connection will be reserved for each user’s CS service.
NOT BE UPDATED
Issue 4 Revision 0 IuCS Protocol Structure
IuCS Protocol Structure

Radio
Network Iu UP Protocol
RANAP
Layer Layer

Q.2630.1
Transport SCCP Q.2150.2

Network MTP3b MTP3b
Layer
SSCF–NNI SSCF–NNI
SSCOP SSCOP
AAL5 AAL5 AAL2
ATM
Physical Layer
CP13_Ch4_02

NOT BE UPDATED
IuPS Protocol Structure Issue 4 Revision 0
IuPS Protocol Structure

Again, two different layers can be detected, the Transport Network Layer and the Radio
Network Layer. The Physical layer in the Transport Network Layer consist of normal OSI
L1 specified protocols like E1, STM, Fibre Optic or even Microwave.
Control Plane
Protocol Stack
The Protocol used on the Radio Network Layer is again RANAP and the functions are
the same then for the IuCS.
The BB SS7 part of the Transport Network will stay the same. We will however, have
additional protocols that could be used. These are the IP based signalling bearer for
packet switched information.
M3UA SS7 and MTP3b User Adaptation Layer

SCTP Simple Control Transmission Protocol (Designed for signalling
transport in the Internet)
IP Internet Protocol
Transport
Network Control
Plane Protocol
Stack
This Plane is not applied to the IuPS.
User Plane
Protocol Stack
Normal GTP tunnelling will be used over UDP which is a connectionless protocol.
Multiple packets and flows will be multiplexed on one or more AAL.
NOT BE UPDATED
Issue 4 Revision 0 IuPS Protocol Structure
IuPS Protocol Stack

Radio
Network Iu UP Protocol
RANAP
Layer Layer

SCCP
Transport
M3UA
Network MTP3b
Layer GTP–U
SCTP
SSCF–NNI UDP
SSCOP IP IP
AAL5 AAL5
ATM ATM
Physical Layer Physical Layer
CP13_Ch4_03

NOT BE UPDATED
Iub Protocol Structure Issue 4 Revision 0
Iub Protocol Structure

As with the Iu interface, two different layers can be detected, the Transport Network
Layer and the Radio Network Layer. The Physical layer in the Transport Network Layer
consist of normal OSI L1 specified protocols like E1, STM, Fibre Optic or even
Microwave. On OSI L2 is the ATM protocol, one thing to note is that the first two OSI
layers will form a common bearer for all three planes above.
Control Plane
Protocol Stack
The Protocol used on the radio Network Layer is called NBAP. This protocol is in turn
divided into the Common NBAP (C-NBAP) and Dedicated NBAP (D-NBAP). The
C-NBAP defines all common procedures carried out like Operations & Maintenance task
through channels like RACH and PCH.
The main functions of C-NBAP are:
Setting up of the Radio Link to the UE
Selection of the Traffic termination point
Cell Configuration
Fault management
Handling of the Common Transport Channels
Reporting and Initialisation of Node-B and/or Cell specific measurements
The main functions of D-NBAP are:
Setup, release and reconfiguration of radio links for the UE Context
Softer Combining Management
Compressed Mode Control
Dedicated and Shared channel Management
Reporting and Initialisation of Radio link specific measurement
DL Power Drifting Correction
Radio link Fault Management
Transport
Network Control
Plane Protocol
Stack
Again the usage of BB SS7 signalling can be seen.
User Plane
Protocol Stack
The User Plane Protocol Stack consists of all the Control and User frame protocols being
used in order to pass the information on to the Node-B and then finally the UE. Three
basic type of transmissions are defined. Transparent, Unacknowledged or
Acknowledged. The lower layers is a simple combination of protocols with the User plane
being directly on top of AAL2 which is responsible for segmenting the data to ATM cells.
NOT BE UPDATED
Issue 4 Revision 0 Iub Protocol Structure
Iub Protocol Stack
Radio Network User Plane

Radio Control Plane
RACH FP
DSCH FP
USCH FP
CPCH FP
FACH FP
DCH FP
PCH FP
Network
Layer NBAP
Transport Network
Control Plane
Q.2630.1
Transport
Network Q.2150.2
Layer
SSCF–UNI SSCF–UNI
SSCOP SSCOP
AAL5 AAL5 AAL2
ATM
Physical Layer
CP13_Ch4_04

NOT BE UPDATED
Iur Protocol Structure Issue 4 Revision 0
Iur Protocol Structure

The Iur was originally developed to support Soft Handovers, but has since been changed
to have 4 main distinct functions that will be discussed in this section. Again two different
layers can be detected, the Transport Network Layer and the Radio Network Layer. The
Physical layer in the Transport Network Layer consist of normal OSI L1 specified
protocols like E1, STM, Fibre Optic or even Microwave. On OSI L2 is the ATM protocol,
one thing to note is that the first two layers will form a common bearer for all three planes
above.
Control Plane
Protocol Stack
The Protocol used on the radio Network Layer is called RNSAP, this protocol could run
on Broad Band SS7 protocols or IP based signalling. The 4 main functions of this
protocol include the following:
Support for basic Inter RNC Mobility
Support for Dedicated Channel Traffic
Support for Common Channel Traffic
Support of Global Resource Management
Transport
Network Control
Plane Protocol
Stack
The Transport Network Protocol Stack is more complex than any other interface. This is
mainly due to 4 different uses as specified above. Signalling and Data will be carried
between different Node-B’s on either BB SS7 Interfaces or IP based Interfaces.
User Plane
Protocol Stack
This is a very simple combination of protocols with the User plane being directly on top of
AAL2, which is responsible for segmenting the data to ATM cells.
NOT BE UPDATED
Issue 4 Revision 0 Iur Protocol Structure
Iur Protocol Stack

Radio
Network DCH CCH
RNSAP
Layer FP FP

Q.2630.1
Transport
SCCP Q.2150.1
Network
Layer MTP3b M3UA MTP3b M3UA
SSCF–NNI SCTP SSCF–NNI SCTP
SSCOP IP SSCOP IP
AAL5 AAL5 AAL2
ATM
Physical Layer
CP13_Ch4_05

NOT BE UPDATED
Radio Interface Protocol Architecture Issue 4 Revision 0
Radio Interface Protocol Architecture

The radio interface is layered into three protocol layers:
The physical layer (L1);
The data link layer (L2);
The network layer (L3).
Layer 1 provides the Physical layer service between the UTRAN and the UE and is
described in detail in later chapters
Layer 2 is split into following sublayers: Medium Access Control (MAC), Radio Link
Control (RLC), Packet Data Convergence Protocol (PDCP) and Broadcast/Multicast
Control (BMC).
Layer 3 and RLC are divided into Control (C–) and User (U–) planes. PDCP and BMC
exist in the U–plane only.
In the C–plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denoted
as Radio Resource Control (RRC), interfaces with layer 2 and terminates in the UTRAN.
The next sublayer provides ’Duplication avoidance’. It terminates in the CN but is part of
the Access Stratum; it provides the Access Stratum Services to higher layers. The higher
layer signalling such as Mobility Management (MM) and Call Control (CC) are assumed
to belong to the non–access stratum.
The diagram opposite shows the radio interface protocol architecture. Each block in
represents an instance of the respective protocol. Service Access Points (SAP) for
peer–to–peer communication are marked with circles at the interface. The SAP between
MAC and the physical layer provides the transport channels. The SAPs between RLC
and the MAC sublayer provide the logical channels. In the C–plane, the interface
between ’Duplication avoidance’ and higher L3 sublayers (CC, MM) is defined by the
General Control (GC), Notification (Nt) and Dedicated Control (DC) SAPs.
Also shown in the figure are connections between RRC and MAC as well as RRC and L1
providing local inter–layer control services. An equivalent control interface exists
between RRC and the RLC sublayer, between RRC and the PDCP sublayer and
between RRC and BMC sublayer. These interfaces allow the RRC to control the
configuration of the lower layers. For this purpose separate Control SAPs are defined
between RRC and each lower layer (PDCP, RLC, MAC, and L1).
NOT BE UPDATED
Issue 4 Revision 0 Radio Interface Protocol Architecture
Radio Interface Protocol Architecture
C–plane signalling U–plane information

GC Nt DC
Duplication avoidance
GC Nt DC
UuS boundary
L3
control
RRC
PDCP
control
control
control
control
L2/PDCP
PDCP
L2/BMC
BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC
RLC RLC
Logical
Channels
MAC L2/MAC
Transport
Channels
PHY L1
CP13_Ch4_06

NOT BE UPDATED
MAC Protocol Issue 4 Revision 0
MAC Protocol
The MAC layer provides “Data Transfer” services to the RLC Layer via Logical
Channels”. Logical channels are described as “What type of data/information is to be
transferred.
MAC Entities
The diagram opposite describes the MAC architecture. MAC the complete MAC protocol
is constructed from MAC entities. The entities are assigned the following names. The
functions completed by the entities are different in the UE from those completed in the
UTRAN:
MAC–b
MAC–b, which identifies the MAC entity that handles the broadcast channel (BCH).
There is one MAC–b entity in each UE and one MAC–b in the UTRAN for each cell.
MAC–c/sh
MAC–c/sh, which identifies the MAC entity that handles the paging channel (PCH), the
forward access channel (FACH), the random access channel (RACH), the Common
Packet Channel (UL CPCH) for FDD, downlink shared channels (DSCH) for both FDD
and TDD and uplink shared channels (USCH) for TDD. There is one MAC–c/sh entity in
each UE and one in the UTRAN for each cell.
MAC–d
MAC–d, denotes the MAC entity that is responsible for handling of dedicated logical
channels and dedicated transport channels (DCH) allocated to a UE. There is one
MAC–d entity in the UE and one MAC–d entity in the UTRAN for each UE.
NOTE: When a UE is allocated resources for exclusive use by the bearers that it
supports the MAC–d entities dynamically share the resources between the bearers and
are responsible for selecting the TFI/ TFCI that is to be used in each transmission time
interval.
NOT BE UPDATED
Issue 4 Revision 0 MAC Protocol
MAC Entities
BCCH PCCH BCCH CCCH CTCH MAC Control DCCH DTCH DTCH
MAC –d
MAC –b
MAC –c/sh
BCH PCH FACH FACH RACH CPCH USCH USCH DSCH DSCH DCH DCH
CP13_Ch4_07

NOT BE UPDATED
MAC Layer Functions Issue 4 Revision 0
MAC Layer Functions
Mapping
between logical
and Transport
channels
The MAC layer performs cross mapping of information between logical channels (to/from
higher level protocols) and the appropriate transport channel, according to the type of
information to be transferred. Logical and transport channel types are covered in more
detail in a later chapter.
Transport format
selection
MAC will select the most appropriate Transport format (from the transport format
combination set) for each transport channel, depending upon the instantaneous source
rate.
Priority handling
of Data Flows
Priority handling of data flows of a single UE using multiple Services, is achieved by
selecting the most appropriate high or low bit rate formats for the respective service.
Dynamic
Scheduling
Under certain circumstances UEs may use common or shared transport channels to
receive data in the downlink. Use of these shared resources is dynamically scheduled by
the MAC–sh layer according the UEs QoS requirements.
Identification of
UEs on Common
Channels
When a common transport channel carries data from dedicated–type logical channels,
the MAC–sh will identify the source or destination UE by including a Radio Network
Temporary Identifier (RNTI) in the MAC header.
MUX/DEMUX of
PDUs into
Transport Blocks
MAC handles the service multiplexing for both common and dedicated transport
channels. However, it should be noted that MAC multiplexing of dedicated channels can
only be performed for services with the same QoS parameters, while physical layer
multiplexing makes it possible to multiplex any type of service, including those with
different QoS parameters.
NOT BE UPDATED
Issue 4 Revision 0 MAC Layer Functions
MAC Layer Functions
Mapping of Logical Channels to transport Channels

Transport Format Selection
Priority Handling of Data Flows of one UE
Priority Handling of Handling Between UEs by Dynamic Scheduling
Identification of UEs on Common Channels
MUX/DEMUX of Higher Layer PDUs Into/ Transport Blocks
Traffic Volume Monitoring
Dynamic Transport Channel Switching
Ciphering (Transport RLC Mode Only)
Access Service Class Selection

NOT BE UPDATED
MAC Layer Functions Issue 4 Revision 0
Traffic Volume
Monitoring
MAC receives RLC PDUs together with status information on the amount of data in the
RLC buffer. MAC compares the amount of status corresponding to a transport channel
with the thresholds set by RRC. If the amount of data is too high or too low, MAC sends
a traffic volume status measurement to RRC. RRC uses these reports to trigger
reconfiguration of the Radio Bearers/Transport channels.
Dynamic
Transport
Channel Type
Switching
Based upon a switching decision received from RRC, MAC is able to execute switching
of data flows between common and dedicated transport channels.
Ciphering
The MAC–D entity performs ciphering if a logical channel is using transparent RLC
mode. Ciphering is an XOR function where data is XORed with a ciphering mask
produced by a ciphering algorithm.
Access Service
Class Selection
UEs are allocated to one of eight Access Service Classes, to provide different priorities
for service resources. MAC indicates the ASC associated with a PDU received from the
physical layer.
NOT BE UPDATED
Issue 4 Revision 0 MAC Layer Functions
MAC Layer Functions
Mapping of Logical Channels to transport Channels

Transport Format Selection
Priority Handling of Data Flows of one UE
Priority Handling of Handling Between UEs by Dynamic Scheduling
Identification of UEs on Common Channels
MUX/DEMUX of Higher Layer PDUs Into/ Transport Blocks
Traffic Volume Monitoring
Dynamic Transport Channel Switching
Ciphering (Transport RLC Mode Only)
Access Service Class Selection

NOT BE UPDATED
RLC Protocol Issue 4 Revision 0
RLC Protocol
The radio link control (RLC) protocol provides segmentation and retransmission services
for both user and control data
The diagram opposite gives an overview model of the RLC layer. The figure illustrates
the different RLC peer entities. Each RLC instance is configured by RRC to operate in
one of three modes
Transparent Mode (Tr)
Unacknowledged Mode (UM
Acknowledged Mode
The mode to be used is determined by the SAP into which the higher layer deliver their
PDUs. The mode chosen indicates which services and functions are to be applied and
what (if any) response will be passed to higher level protocols regarding error detection.
For all RLC modes, CRC error detection is performed by the physical layer and the result
of the CRC check is delivered to RLC together with the actual data.
RLC Entities
There is one transmitting and one receiving entity for the transparent mode service and
the unacknowledged mode service and one combined transmitting and receiving entity
for the acknowledged mode service.
The dashed lines on the AM–Entities illustrate the possibility to send the RLC PDUs on
separate logical channels, e.g. control PDUs on one and data PDUs on the other
NOT BE UPDATED
Issue 4 Revision 0 RLC Protocol
RLC Protocol Model
Tr–SAP
– UM–SAF
– AM–SAP
– UM–SAP
– Tr–SAP
–
Transm. Transm. Receiv. Receiv.

Tr–Entity
– UM–Entity
– AM–Entity
– UM–Entity
– Tr–Entity
–
Transmitting Side Receiving Side
CP13_Ch4_08

NOT BE UPDATED
Transparent Data Transfer Service Issue 4 Revision 0
Transparent Data Transfer Service

The diagram opposite shows the model of two transparent mode peer entities.
Transmitting Tr
Entity
The transmitting Tr–entity receives SDUs from the higher layers through the Tr–SAP.
RLC might segment the SDUs into appropriate RLC PDUs without adding any overhead.
How to perform the segmentation is decided upon when the service is established.
RLC delivers the RLC PDUs to MAC through either a BCCH, DCCH, PCCH, SHCCH or
a DTCH.
The CCCH also uses transparent mode, but only for the uplink. Which type of logical
channel depends on if the higher layer is located in the control plane (BCCH, DCCH,
PCCH, CCCH, SHCCH) or user plane (DTCH).
Receiving Tr
Entity
The Tr–entity receives PDUs through one of the logical channels from the MAC sublayer.
RLC reassembles (if segmentation has been performed) the PDUs into RLC SDUs. How
to perform the reassembling is decided upon when the service is established.
RLC delivers the RLC SDUs to the higher layer through the Tr–SAP.
No form of error detection is employed. PDUs are sent onto higher levels without error
indication even if received corrupt.
NOT BE UPDATED
Issue 4 Revision 0 Transparent Data Transfer Service
Transparent Data Transfer Service
Functions:
Transfer of User Data (Without adding Overhead)
Segmentation and Reassembly
Radio Interface
Tr–SAP Tr–SAP
Transm. Receiving
Tr–Entity Tr–Entity
Segmentation Reassembly
Transmission Receiver
buffer buffer
BCCH/PCCH/DCCH BCCH/PCCH/DCCH
CCCH/DTCH/SHCCH CCCH/DTCH/SHCCH
CP13_Ch4_09

NOT BE UPDATED
Unacknowledged Data Transfer Service Issue 4 Revision 0
Unacknowledged Data Transfer Service

The diagram opposite shows the model of two unacknowledged mode peer entities.
Transmitting UM
Entity
The transmitting UM–entity receives SDUs from the higher layers. RLC might segment
the SDUs into RLC PDUs of appropriate size. The SDU might also be concatenated with
other SDUs.
If air interface ciphering is indicated, The RLC layer will perform this function.
RLC adds a header and the PDU is placed in the transmission buffer. RLC delivers the
RLC PDUs to MAC through either a DCCH, a SHCCH (downlink only), CTCH or a
DTCH.
The CCCH also uses unacknowledged mode, but only for the downlink. Which type of
logical channel depends on if the higher layer is located in the control plane (CCCH,
DCCH, SHCCH) or user plane (CTCH, DTCH).
Receiving UM
Entity
The receiving UM–entity receives PDUs through one of the logical channels from the
MAC sublayer. RLC removes header from the PDUs and reassembles the PDUs (if
segmentation has been performed) into RLC SDUs.
The RLC SDUs are delivered to the higher layer though the UM–SAP.
NOT BE UPDATED
Issue 4 Revision 0 Unacknowledged Data Transfer Service
Unacknowledged Data Transfer Service
Functions: Transfer of User Data (Overhead added) Padding

Segmentation/Concatenation and Reassembly Ciphering
Sequence Number Check
UM–SAP Radio Interface UM–SAP
Transm. Receiving
Segmentation & UM–Entity UM–Entity Reassembly
Concatenation
Deciphering
Ciphering
Add RLC Remove RLC

header header
Transmission Receiver
buffer buffer
CCCH/DCCH CCCH/DCCH
DTCH/SHCCH/ DTCH/SHCCH/
CTCH CTCH
CP13_Ch4_10

NOT BE UPDATED
Acknowledged Data Transfer Service Issue 4 Revision 0
Acknowledged Data Transfer Service

The diagram shows the model of an acknowledged mode entity, when one logical
channel (shown as a solid line) and when two logical channels (shown as dashed lines)
are used.
In case two logical channels are used in the uplink the UTRAN can indicate that the first
logical channel shall be used for data PDUs and the second logical channel shall be used
for control PDUs. If the indication is not given from the UTRAN, data and control PDUs
can be sent on either of the two logical channels. The indication of the logical channel
mapping is signalled by RRC.
Transmitting UM
Entity
The transmitting side of the AM–entity receives SDUs from the higher layers. The SDUs
are segmented and/or concatenated to PUs of fixed length. PU length is a semi–static
value that is decided in bearer setup and can only be changed through bearer
reconfiguration by RRC.
For purposes of RLC buffering and retransmission handling, the operation is the same as
if there would be one PU per PDU. For concatenation or padding purposes, bits of
information on the length and extension are inserted into the beginning of the last PU
where data from an SDU is included.
If several SDUs fit into one PU, they are concatenated and the appropriate length
indicators are inserted into the beginning of the PU. After that the PUs are placed in the
retransmission buffer and the transmission buffer. One PU is included in one RLC PDU.
The MUX then decides which PDUs and when the PDUs are delivered to MAC. The
PDUs are delivered via a function that completes the RLC–PDU header. The fixed 2
octet AMD PDU header is not ciphered.
When Piggybacking mechanism is applied the padding is replaced by control information
(piggybacked STATUS PDU), in order to increase the transmission efficiency and making
possible a faster message exchange between the peer to peer RLC entities. The
piggybacked control information is not saved in any retransmission buffer. The
piggybacked STATUS PDUs will be of variable size in order to match with the amount of
free space in the AMD PDU.
The retransmission buffer also receives acknowledgements from the receiving side,
which are used to indicate retransmissions of PUs and when to delete a PU from the
retransmission buffer.
Receiving UM
Entity
The Receiving Side of the AM–entity receives PDUs through one of the logical channels
from the MAC sublayer. The RLC–PDUs are expanded into separate PUs and potential
piggybacked status information is extracted. The PUs are placed in the receiver buffer
until a complete SDU has been received.
The receiver buffer requests retransmissions of PUs by sending negative
acknowledgements to the peer entity. After that the headers are removed from the PDUs
and the PDUs are reassembled into a SDU. Finally the SDU is delivered to the higher
layer. The receiving side also receives acknowledgements from the peer entity. The
acknowledgements are passed to the retransmission buffer on the transmitting side.
NOT BE UPDATED
Issue 4 Revision 0 Acknowledged Data Transfer Service
AM–SAP
AM–Entity
Segmentation & Concatenation
RLC Control Unit
Add RLC header
Piggybacked status
Optional
Retransmission
buffer & Reassembly
management
Received acknowledgements
Remove RLC header & Extract
MUX Piggybacked information
Deciphering
Ciphering
Acknowledgements Receive buffer &

Transmission Retransmission
buffer management
Set fields in RLC Header

(e.g. set poll bits) Demux/Routing
Transmitting Side Receiving Side
DCCH/ DCCH/ DCCH/ DCCH/ DCCH/ DCCH/

DTCH** DTCH* DTCH** DTCH** DTCH* DTCH**
CP13_Ch4_11a

Functions:
Transfer of User Data (Overhead added)
Segmentation/Concatenation and Reassembly
Padding
Flow Control
Ciphering
Error Correction
Duplicate Detection
In Sequence Delivery of Higher Layer PDUs
CP13_Ch4_11b
Protocol Error Detection & Recovery

NOT BE UPDATED
Packet Data Convergence Protocol (PDCP) Issue 4 Revision 0
Packet Data Convergence Protocol (PDCP)

Network layer protocols are intended to be capable of operating over services derived
from a wide variety of subnetworks and data links. UMTS supports several network layer
protocols providing protocol transparency for the users of the service. Introduction of new
network layer protocols to be transferred over UTRAN shall be possible without any
changes to UTRAN protocols. Therefore, all functions related to transfer of packets from
higher layers (PDCP SDUs) shall be carried out in a transparent way by the UTRAN
network entities. This is one of the requirements for UTRAN PDCP.
Another requirement for the PDCP is to provide functions that help to improve channel
efficiency. This requirement is fulfilled by the possibility to implement different kinds of
optimisation methods. The currently known methods are standardised IETF header
compression algorithms.
Multiplexing of RBs onto the same RLC entity will be included in Release 2000 but is not
available in Release 1999. Therefore, in Release 1999 every RB, is connected to one
PDCP entity and one PDCP entity is connected to one RLC entity.
The PDCP entities are located in the PDCP sublayer. Every PDCP entity uses zero, one
or several header compression algorithm types with certain parameters. Several PDCP
entities may use the same algorithm type. The algorithm types and their parameters are
negotiated by RRC and indicated to PDCP through the PDCP Control Service Access
Point (PDCP–C–SAP).
Figure 1 shows the model of the PDCP within the UTRAN protocol architecture. Every
PDCP–SAP uses exactly one PDCP entity. Each PDCP entity uses none, one or several
header compression algorithm types.
NOT BE UPDATED
Issue 4 Revision 0 Packet Data Convergence Protocol (PDCP)
Packet Data Convergence Protocol (PDCP) Specification
Transparent Transfer of User Data

Header Compression of RTP/UDP/IP Headers
Multiplexing of Different RBs Onto Same RLC Entity (R–2000)
Radio Bearers
PDCP–SDU
PDCP–SAPs
PDCP PDCP PDCP–

entity Protocol Protocol
entity sublayer
comp. entity comp. entity
Alg. Type 1 Alg. Type 2
Protocol Protocol PDU PDU Protocol

comp. entity comp. entity numbering numbering comp. entity
Alg. Type 1 Alg. Type 2 Alg. Type 1
RLC–SDU
UM–SAP AM–SAP Tr–SAP RLC

CP13_Ch4_12

NOT BE UPDATED
Radio Interface for Broadcast/Multicast Services Issue 4 Revision 0
Radio Interface for Broadcast/Multicast Services

Broadcast/Multicast Control (BMC ) is a sublayer of L2 that exists in the User–Plane only.
It is located above RLC. The L2/BMC sublayer is assumed as transparent for all services
except broadcast/multicast.
The diagram opposite shows the model of the L2/BMC sublayer within the UTRAN radio
interface protocol architecture.
At the UTRAN side, the BMC sublayer shall consist of one BMC protocol entity per cell.
Each BMC entity requires a single CTCH, which is provided by the MAC sublayer,
through the RLC sublayer. The BMC requests the Unacknowledged Mode service of the
RLC.
It is assumed that there is a function in the RNC above BMC that resolves the
geographical area information of the CB message (or, if applicable, performs evaluation
of a cell list) received from the Cell Broadcast Centre (CBC). A BMC protocol entity
serves only those messages at BMC–SAP that are to be broadcast into a specified cell.
BMC Functions
The functions are specified in TS 25.301. They are:
Storage of Cell Broadcast Messages.
Traffic volume monitoring and radio resource request for CBS. BMC calaculates the
required transmission rate for the cell broadcast service based on the messages received
over the CBC–RNC link, and requests appropriate shared channel resources from RRC
Scheduling of BMC messages. BMC receives scheduling information with each CB
message. Based on tyhis the UTRAN BMC schedules the BMC sequences accordingly.
On the UE side, the BMC evaluates the schedule messages it receives and indicates
these parameters to the RRC, which is used by RRC to configure lower layers for CBS
discontinous reception.
Transmission of BMC messages to UE, according to the established schedule.
Delivery of Cell Broadcast messages to upper layer (NAS). This UE function delivers the
non–corrupt CBS messages to the upper layers.
NOT BE UPDATED
Issue 4 Revision 0 Radio Interface for Broadcast/Multicast Services
BMC Model and functions
user–plane
RRC BMC–SAP
L2/BMC sublayer
CBMC–
SAP BMC
Storage of CB messages UM
Traffic volume monitoring and
Radio Resource Requests for CB L2/RLC sublayer
Scheduling of BMC messages
TX of BMC messages to UE RLC
Delivery of BMC messages to
Higher layers
CTCH–SAP
CP13_Ch4_13

NOT BE UPDATED
RRC Layer Model Issue 4 Revision 0
RRC Layer Model

The functional entities of the RRC layer are illustrated in the diagram opposite and
described below.
Routing Function
Entity (RFE)
Routing of higher layer messages to different MM/CM entities (UE side) or different core
network domains (UTRAN side) is handled by the Routing Function Entity (RFE)
Broadcast
Control Function
Entity (BCFE)
Broadcast functions are handled in the broadcast control function entity (BCFE). The
BCFE is used to deliver the RRC services, which are required at the GC–SAP. The
BCFE can use the lower layer services provided by the Tr–SAP and UM–SAP.
Paging and
Notification
Control Function
Entity (PNFE)
Paging of UEs that do not have an RRC connection is controlled by the paging and
notification control function entity (PNFE). The PNFE is used to deliver the RRC services
that are required at the Nt–SAP. The PNFE can use the lower layer services provided by
the Tr–SAP and UM–SAP.
Dedicated
Control Function
Entity (DCFE)
The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE.
The DCFE is used to deliver the RRC services which are required at the DC–SAP and
can use lower layer services of UM/AM–SAP and Tr–SAP depending on the message to
be sent and on the current UE service state.
Shared Control
Function Entity
(SCFE)
In TDD mode, the DCFE is assisted by the Shared Control Function Entity (SCFE)
location in the C–RNC, which controls the allocation of the PDSCH and PUSCH using
lower layers services of UM–SAP and Tr–SAP.
Transfer Mode
Entity (TME)
The Transfer Mode Entity (TME) handles the mapping between the different entities
inside the RRC layer and the SAPs provided by RLC.
NOT BE UPDATED
Issue 4 Revision 0 RRC Layer Model
RRC Layer Model
Access Stratum
RFE RFE RFE
RRC
SAPs
RRC
BCFE PNFE DCFE SCFE
TME TME TME
RLC–
ctrl
RLC
MAC–ctrl
MAC
L1–ctrl
L1
CP13_Ch4_14

NOT BE UPDATED
RRC Functions Issue 4 Revision 0
RRC Functions
The Radio Resource Control (RRC) layer handles the control plane signaling of Layer 3
between the UEs and UTRAN. The RRC performs the following functions:
Broadcast of information provided by the non–access stratum (Core

Network)
The RRC layer performs system information broadcasting from the network to all UEs.
The system information is normally repeated on a regular basis. The RRC layer performs
the scheduling, segmentation and repetition. This function supports broadcast of higher
layer (above RRC) information. This information may be cell specific or not. As an
example RRC may broadcast Core Network location service area information related to
some specific cells.
Broadcast of information related to the access stratum

The RRC layer performs system information broadcasting from the network to all UEs.
The system information is normally repeated on a regular basis. The RRC layer performs
the scheduling, segmentation and repetition. This function supports broadcast of typically
cell–specific information.
Establishment, re–establishment, maintenance and release of an RRC

connection between the UE and UTRAN
The establishment of an RRC connection is initiated by a request from higher layers at
the UE side to establish the first Signaling Connection for the UE. The establishment of
an RRC connection includes an optional cell re–selection, an admission control, and a
layer 2 signaling link establishment. The release of an RRC connection can be initiated
by a request from higher layers to release the last Signaling Connection for the UE or by
the RRC layer itself in case of RRC connection failure. In case of connection loss, the UE
requests re–establishment of the RRC connection. In case of RRC connection failure,
RRC releases resources associated with the RRC connection.
Establishment, reconfiguration and release of Radio Bearers

The RRC layer can, on request from higher layers, perform the establishment,
reconfiguration and release of Radio Bearers in the user plane. A number of Radio
Bearers can be established to an UE at the same time. At establishment and
reconfiguration, the RRC layer performs admission control and selects parameters
describing the Radio Bearer processing in layer 2 and layer 1, based on information from
higher layers.
Assignment, reconfiguration and release of radio resources for the RRC

connection
The RRC layer handles the assignment of radio resources (e.g. codes, CPCH channels)
needed for the RRC connection including needs from both the control and user plane.
The RRC layer may reconfigure radio resources during an established RRC connection.
This function includes coordination of the radio resource allocation between multiple radio
bearers related to the same RRC connection. RRC controls the radio resources in the
uplink and downlink such that UE and UTRAN can communicate using unbalanced radio
resources (asymmetric uplink and downlink). RRC signals to the UE to indicate resource
allocations for purposes of handover to GSM or other radio systems.
NOT BE UPDATED
Issue 4 Revision 0 RRC Functions
RRC Functions
Broadcast of information related to the non–access stratum (Core

Network)
Establishment, maintenance and release of an RRC connection
between the UE and UTRAN
Assignment, reconfiguration and release of radio resources for the
RRC connection
RRC connection mobility functions
Control of requested QoS
UE measurement reporting and control of the reporting
Outer loop power control
Control of ciphering
Slow DCA (TDD mode)
Paging.
Initial cell selection and cell re–selection;
Arbitration of radio resources on uplink DCH;
RRC message integrity protection;
Timing advance (TDD mode);
CBS control.

NOT BE UPDATED
RRC Functions Issue 4 Revision 0

The RRC layer performs evaluation, decision and execution related to RRC connection
mobility during an established RRC connection, such as handover, preparation of
handover to GSM or other systems, cell re–selection and cell/paging area update
procedures, based on e.g. measurements done by the UE.
Paging/notification
The RRC layer can broadcast paging information from the network to selected UEs.
Higher layers on the network side can request paging and notification. The RRC layer
can also initiate paging during an established RRC connection.
Routing of higher layer PDUs
This function performs at the UE side routing of higher layer PDUs to the correct higher
layer entity, at the UTRAN side to the correct RANAP entity.
This function shall ensure that the QoS requested for the Radio Bearers can be met. This
includes the allocation of a sufficient number of radio resources.
The measurements performed by the UE are controlled by the RRC layer, in terms of
what to measure, when to measure and how to report, including both UMTS air interface
and other systems. The RRC layer also performs the reporting of the measurements
from the UE to the network.
The RRC layer controls setting of the target of the closed loop power control.
The RRC layer provides procedures for setting of ciphering (on/off) between the UE and
UTRAN.
Arbitration of radio resources on uplink DCH
This function controls the allocation of radio resources on uplink DCH on a fast basis,
using a broadcast channel to send control information to all involved users.
NOTE: This function is implemented in the CRNC.
Initial cell selection and re–selection in idle mode
Selection of the most suitable cell based on idle mode measurements and cell selection
criteria.
Integrity protection
This function adds a Message Authentication Code (MAC–I) to those RRC messages
that are considered sensitive and/or contain sensitive information.
Allocation of radio resources for CBS
This function allocates radio resources for CBS based on traffic volume requirements
indicated by BMC. The radio resource allocation set by RRC (i.e. the schedule for
mapping of CTCH onto FACH/S–CCPCH) is indicated to BMC to enable generation of
schedule messages. The resource allocation for CBS shall be broadcast as system
information.
Configuration for CBS discontinuous reception

This function configures the lower layers (L1, L2) of the UE when it shall listen to the
resources allocated for CBS based on scheduling information received from BMC.
NOT BE UPDATED
Issue 4 Revision 0 RRC Functions
RRC Functions
Broadcast of information related to the non–access stratum (Core

Network)
Establishment, maintenance and release of an RRC connection
between the UE and UTRAN
Assignment, reconfiguration and release of radio resources for the
RRC connection
Slow DCA (TDD mode)
Paging.
Initial cell selection and cell re–selection;
Arbitration of radio resources on uplink DCH;
RRC message integrity protection;
Timing advance (TDD mode);
CBS control.

NOT BE UPDATED
Protocol Stacks Issue 4 Revision 0
Protocol Stacks
The following pages construct the protocol stacks for each UMTS network entity. The
exact protocol structure is dependent upon which Core Network domain (CS or PS) is
providing the Bearer Service, and whether the information transfer is user plane or
control plane.
User Plane
Protocol Stack
(Dedicated
Channels
CS–Domain)
The diagram opposite shows the User plane protocol stack for user plane data transer,
using dedicated channels via the CN–PS. The user CS payload will be received at the
MSC from the external network (e.g the PSTN. The protocols used the transfer the
Payload across this interface may vary and are not described in this document. AAL,
ATM and Physical layers will be described in detail in later chapters.
Iu UP Frame Protocol
The Iu UP protocol is located in the User plane of the Radio Network layer over the IU
interface and is used to convey user data associated to Radio Access Bearers (RABs) .
One Iu UP protocol instance is uniquely associated to each RAB. If several RABs are
established towards one given UE, then these RABs make use of several Iu UP protocol
instances. These Iu UP instances are established, relocated and released together with
the Associated RAB.
The Iu UP Protocol is defined with modes of operation, which can be activated on a RAB
basis rather than on A CN domain or service basis. This makes the protocol
independent of the CN domain and to have limited or no dependency with the Transport
Network Layer. This provides the flexibility to evolve services regardless of the CN
domain. The Iu UP mode of operation determines if and which set of features shall be
provided. Currently two mode of operation are defined:
Transparent Mode (TrM)
Support modes
TrM is intended for those RAB that do not require any particular feature from the Iu UP
protocol other than transfer of user data. In this mode the, The Iu UP protocol does not
perform any peer–to–peer information transfer over the Iu interface. The Iu UP protocol
layer is crossed though by PDUs being exchanged between upper layers and the
transport network layer, no Iu UP overhead is added to the payload.
The support modes are intended for those RABs that do require particular features from
the Iu UP protocol in addition to transfer of user data. When operating in support mode,
the peer Iu UP protocol instances exchange Iu UP frames, adding overhead to the
payload. The Iu UP Support mode is prepared to support variations. However, the only
support mode currently defined in 3GPP specifications; namely Support Mode for
Predefined SDU size (SMpSDU), and provides the following functions.
Transfer of user data;
Initialisation
Rate Control
Time Alignment
Handling of Error Events
Frame Quality Classification
NOT BE UPDATED
Issue 4 Revision 0 Protocol Stacks

(Dedicated Channels CS–Domain)
CS CS
Payload Payload
RLC RLC
MAC–d MAC–d
Split/
Select
DCH DCH
lu–UP lu–UP
Split/ FP FP
Comb
AAL2 AAL2 AAL2 AAL2
Split/
Comb
ATM ATM ATM ATM
Phys Phys Phys Phys Phys Phys Phys Phys
UE Node B SRNC MSC PSTN
CP13_Ch4_15

NOT BE UPDATED
Protocol Stacks Issue 4 Revision 0
Dedicated
Channel Frame
Protocol (DCH
FP)
User data is received at the SRNC, via the transport layer and Iu UP protocol and the
passed to the Radio Interface Control protocols for RLC and MAC processing as
appropriate. The resultant Transport Blocks are delivered to the DCH FP.
DCH FP transfers DCH data frames every transmission time interval from the SRNC to
the Node B fro downlink transfer and from Node B to the SRNC for uplink transfer. An
Optional error detection mechanism may be used to protect the data transfer if needed.
At the transport channel setup it shall be specified if the error detection on the User data
is used.
In addition to the transfer of user data, DCH FP provides the following services
Transport of outer loop power control information between SRNC and Node B.
Support of transport channel synchronisation mechanism.
Support of Node Synchronisation method.
Transfer of DSCH TFI from SRNC to Node B.
Transfer of Rx timing deviation (TDD) from the Node B to the RNC.
Transfer of radio interface parameters from the SRNC to the Node B.
The specification of Iub DCH data streams is also valid for the Iur DCH data streams.
NOT BE UPDATED
Issue 4 Revision 0 Protocol Stacks

(Dedicated Channels CS–Domain)
CS CS
Payload Payload
RLC RLC
MAC–d MAC–d
Split/
Select
DCH DCH
lu–UP lu–UP
Split/ FP FP
Comb
AAL2 AAL2 AAL2 AAL2
Split/
Comb
ATM ATM ATM ATM
UE Node B SRNC MSC PSTN
CP13_Ch4_16

NOT BE UPDATED
Control Plane Protocol Stack (UE–CN SIGNALLING, Dedicated Channels, CS–Domain) Issue 4 Revision 0
Control Plane Protocol Stack (UE–CN SIGNALLING, Dedicated

Channels, CS–Domain)
The diagram opposite illustrates the protocol stack for UE to CN signalling, when the UE
is connected to the network and operating in dedicated mode.
RANAP Services
RANAP provides the signalling service between UTRAN and the CN that is required to
fulfil the RANAP functions. RANAP services are divided into three groups based on
Service access Points.
General control services

General control services are related to the whole Iu interface instance between RNC and
logical CN domain, and are accessed in CN through the General Control SAP. They
utilise connectionless signalling transport provided by the Iu signalling bearer.
Notification services
Notification services are related to specified UEs or all UEs in specified area, and are
accessed in CN through the Notification SAP. They utilise connectionless signalling
transport provided by the Iu signalling bearer.
Dedicated control services

Dedicated control services are related to one UE, and are accessed in CN through the
Dedicated Control SAP. RANAP functions that provide these services are associated with
Iu signalling connection that is maintained for the UE in question. The Iu signalling
connection is realised with connection oriented signalling transport provided by the Iu
signalling bearer.
SCCP
SCCP provides connectionless service, class 0, connection oriented service, class 2,
separation of the connections mobile by mobile basis on the connection oriented link and
establishment of a connection oriented link mobile by mobile basis.
MTP3–B
MTP3–b provides message routing, discrimination and distribution (for point–to–point link
only), signalling link management load sharing and changeover/back between link within
one link–set. The need for multiple link–sets is precluded.
SAAL–NNI
SAAL–NNI consists of the following sub–layers: – SSCF [3], – SSCOP [2] and – AAL5
[6]. The SSCF maps the requirements of the layer above to the requirements of SSCOP.
Also SAAL connection management, link status and remote processor status
mechanisms are provided. SSCOP provides mechanisms for the establishment and
release of connections and the reliable exchange of signalling information between
signalling entities. Adapts the upper layer protocol to the requirements of the Lower ATM
cells.
NOT BE UPDATED
Issue 4 Revision 0 Control Plane Protocol Stack (UE–CN SIGNALLING, Dedicated Channels, CS–Domain)
Control Plane Protocol Stack (UE–CN SIGNALLING,

Dedicated Channels, CS–Domain)
RRC RRC
RLC RLC RANAP RANAP
MAC–d MAC–d
Split/
SCCP SCCP
Comb
DCH DCH
MTP3–b MTP3–b
FP FP
Combining
SAAL– SAAL–
AAL2 AAL2
NNI NNI
Split/
Comb
ATM ATM ATM ATM
Phys Phys Phys Phys Phys Phys
UE Node SRNC MS
CP13_Ch4_17

NOT BE UPDATED
Control Plane Protocol Stack Issue 4 Revision 0

(UE–CN Signalling, Shared Channels, CS–Domain)
The diagram opposite illustrates the protocol stack for UE to CN signalling, when the UE
is connected to the network and operating on shared or common channels. The stack
differs from that of dedicated mode, in that the CRNC is no longer transparent.
The continues to provide the majority of the Layer 2 services (RRC, RLC, MAC–d),
However, the CRNC is responsible for terminating the MAC–c/sh entity.
On the diagram, the MUX–1 box in the CRNC represents the multiplexing of the various
AAL2 connections coming from multiple SRNCs into MAC–c/sh. The MUX–2 box
represents the multiplexing of various instances of MAC–d from the same SRNC into
AAL2, for transfer to the MAC–c/sh at the CRNC.
RACH/FACH/
DSCH Frame
Protocol
RACH/FACH/DSCH Frame protocols (FPs) are responsible for the transfer of Transport
Blocks between the Node B and the CRNC for common/shared channels. These FPs
will always add overhead to the payload, in the form of a header.
In addition to providing a data transfer function, the common/shared FPs provide the
following services:
Support of transport channel synchronisation mechanism.
Support of Node synchronisation mechanism.
DSCH TFCI signalling.
NOT BE UPDATED
Issue 4 Revision 0 Control Plane Protocol Stack
Control Plane Protocol Stack(UE–CN Signalling, Shared

Channels, CS–Domain)
RRC RRC
RLC RLC
MAC–d MAC–d RANAP RANAP
MUX1 MUX2
MAC–
c/sh MAC–
c/sh
RACH/ RACH/
SCCP SCCP
FACH/ FACH/
AAL2 AAL2
DSCH DSCH
lu–UP MTP3–b MTP3–b
FP FP
SAAL– SAAL–
AAL2 AAL2
NNI NNI
ATM ATM ATM ATM ATM ATM

UE Node B CRNC SRNC CN
CP13_Ch4_18

NOT BE UPDATED
User Plane Protocol Stack Issue 4 Revision 0

(Dedicated Channels, PS–Domain)
The diagram opposite shows the user plane protocol stack for user data transfer, using
dedicated channels via the CN–PS. The user CS payload will be received at the GGSN
from the external network (e.g the internet). The protocols used to transfer the payload
across this interface may vary and are not described in this document.
GPRS Tunnelling
Protocol, User
Plane (GTP–U)
The user payload data packets, known as T–PDUs, arrive at the GGSN from the external
PDN. Typically these will be IP based and addressed to an application running on the
target UE. Alternate transport mechanisms, such as X25, may also be used. The
T–PDUs will be presented to GTP, via the appropriate NSAPI for the source protocol.
For UMTS the second versio of GTP (version 1) will be used.
GTP allows multi–protocol packets to be tunnelled through the UMTS/GPRS Backbone
between GSNs and is necessary to forward packets between an external packet data
network and an MS user. In the user plane, GTP uses a tunnelling mechanism (GTP–U)
to provide a service for carrying user data packets. The GTP–U protocol is implemented
by SGSNs and GGSNs in the UMTS/GPRS Backbone and by Radio Network Controllers
(RNCs) in the UTRAN. No other systems need to be aware of GTP. UMTS/GPRS MSs
are connected to an SGSN without being aware of GTP.
A GTP tunnel in the GTP–U plane is defined for each PDP Context in the GSNs and/or
each RAB in the RNC. A GTP tunnel is identified in each node with a Tunnel Endpoint ID
(TEID), a UDP port number and an IP address. The TEID unambiguously identifies a
tunnel endpoint in the receiving GTP–U protocol entity. The TEID values are negotiated
and exchanged between tunnel endpoints using control plane procedures defined in
protocols such as GTP–C (or RANAP, over the Iu) messages during the activation of the
PDP context or RAB.
Path Protocols
UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 of
GTP.
UDP
A User Datagram Protocol (UDP) compliant with STD 0006 shall be used. The UDP
destination port number for GTP–U messages is 2152.
IP
An Internet protocol compliant with STD 0005 shall be used. The IP destination address
in a GTP message shall be the IP address of the destination GSN/RNC. The source
address shall be the IP address of the originating GSN/RNC.
NOT BE UPDATED
Issue 4 Revision 0 User Plane Protocol Stack

(Dedicated Channels, PS–Domain)
AAP AAP
IP IP
IP IP
PDCP PDCP
GTP–U GTP–U GTP–U GTP–U
RLC RLC
MAC–d MAC–d UDP UDP UDP UDP

Split
Comb
DCH IP IP IP IP
DCH
FP FP
Comb
AAL2 AAL2 AAL5 AAL5
L2 L2
Split/
ATM ATM ATM ATM
Comb
Phys Phys Phys Phys Phys Phys Phys Phys Phys Phys
UE Node B SRNC SGSN GGSN PDN
CP13_Ch4_19

NOT BE UPDATED

(UE–CN Siganalling, Dedicated Channels, PS–Domain)
Stream Control
Transmission
Protocol
The basic service offered by SCTP is the reliable transfer of user messages between
peer SCTP users. It performs this service within the context of an association between
two SCTP endpoints. SCTP is connection–oriented in nature, but the SCTP association
is a broader concept than the TCP connection. SCTP provides the means for each
SCTP endpoint to provide the other endpoint (during association startup) with a list of
transport addresses (i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will originate SCTP
packets. The association spans transfers over all of the possible source/destination
combinations, which may be generated from each endpoint’s lists.
M3UA
MU3A provides adaptation between the SCCP layer and the Transmission protocols. An
RNC equipeped with the M3UA stack option shall have client functionality. This enables
the RNC to report to the SGSN when it is a newly introduced entity in the network.
NOT BE UPDATED
Issue 4 Revision 0 Control Plane Protocol Stack

(UE–CN Signalling,Dedicated Channels, PS–Domain)
RRC RRC RANAP RANAP
RLC RLC SCCP SCCP
MAC–d MAC–d M3UA M3UA
Split/
Comb SCTP SCTP
DCH DCH
IP IP
FP FP
Combining
SAAL– SAAL–
AAL2 AAL2
NNI NNI
Split/
Comb
ATM ATM ATM ATM
Phys Phys Phys Phys Phys Phys
UE Node SRNC CN
CP13_Ch4_20

NOT BE UPDATED
NOT BE UPDATED
Chapter 5
Data Flow and Terrestrial
Interfaces

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 5
Data Flow and Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
ATM Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Asynchronous Transfer Mode (ATM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6
ATM Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
ATM Adaptation Layers (AALs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
The ATM Adaptation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Convergence Sub–Layer (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Segmentation and Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
ATM Adaptation Layer 2 (AAL2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
CPCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
ATM Adaptation Layer 5 (AAL 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
Virtual Channels and Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Use of Virtual Channels and Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Virtual Connection and Path Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
E1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Logical Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
ATM Cell to E1 Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–24
E Link Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Inverse Multiplexing for ATM (IMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Plesiochronous Digital Hierarchy (PDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–30
Synchronous Digital Hierarchy (SDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
Principles of SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
SDH Drop and Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Network Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Software Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Bandwidth on Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
ATM to STM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–38
Typical UMTS Transport Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–40

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
State the transport mechanisms used for the UMTS transport network.
Describe the basic principles of ATM.
Describe the use of PDH and SDH bearers for UMTS.

NOT BE UPDATED
Terrestrial Interfaces Issue 4 Revision 0
Terrestrial Interfaces
One very important aspect that is sometimes overlooked is the transport medium
required between the different entities. In the case of UMTS the Network Operator will
run into problems if the wrong links are utilised. Speed of transfer and cost will be two of
the major determining factors when planning the UMTS network. Other issues that need
to be addressed are the types of converting equipment used between the different types
of Terrestrial Interfaces. In the following pages a closer look will be taken at these
aspects.
It should also be mentioned that as data rates increase the use of E1/T1 systems
become more difficult. ATM is the preferred transport mechanism on the CN. Voice and
IP over ATM is conducted using ATM adaptation layers.
NOT BE UPDATED
Issue 4 Revision 0 Terrestrial Interfaces
Terrestrial Interfaces
Uu Iub Iups GN
CS PS
UE Node B RNC SGSN GGSN Network
CDMA
– FDD ATM ATM IP
IP X25
CDMA E1 SDH
– TDD
CP13_Ch5_10

NOT BE UPDATED
ATM Principles Issue 4 Revision 0
ATM Principles
ATM is used to transfer different types of information with different rate factors over one
or more common link with a high bit rate. This properties makes ATM an extremely useful
system when it comes to wideband or broadband data transfer.
With the standards in place it is now possible for packet switching techniques like Frame
Relay or ATM to deliver high quality speech. Some of the intrinsic advantages ATM has
over other network technologies are listed below:
Considering data, voice, and video payload requirements, ATM was constructed.
ATM cells are of fixed size, 53 bytes each with 48 bytes for payload and 5 for ATM
header. This helps in reducing the packetization delay significantly, which is one of
the major delay parameters.
It supports extensive QoS (Quality of Service) parameters, which allows voice
traffic to be transmitted across the network in a reliable jitter-free way.
Various ATM Adaptation Layers (AALs) support various service classes
capabilities.
ATM switches have always been designed with effective traffic management
capabilities, for example, call admission control, usage parameter control, traffic
shaping, etc.
Single network for voice, data, and video.
Interworking with PSTN is relatively straightforward.
NOT BE UPDATED
Issue 4 Revision 0 ATM Principles
ATM Principles
Fixed Bit Stream
Variable Bit Stream
Discontinues
Bit Stream
CP13_Ch5_12

NOT BE UPDATED
Asynchronous Transfer Mode (ATM) Issue 4 Revision 0
Asynchronous Transfer Mode (ATM)

Asynchronous Transfer Mode (ATM) is a technology originally designed for LANs that
has transport, switching and network management facilities built into it. Data rates are:
Primary User 155.2 Mb/s
Network Interface 622.08 Mb/s
In general terms ATM is a packet switching protocol made up of fixed length packets.
The standard packet length is 53 Octets, 5 being header information and the remaining
48 user data, called the payload.
The fixed length cell gives some key advantages over variable length structures. The first
is that short cells can be switched quickly and economically. Secondly the queuing
caused by long, variable length frames can be reduced to the wait time for a single 53
Octet frame, allowing time dependent voice and video to be transported.
ATM can provide both CBR and VBR transport.
NOT BE UPDATED
Issue 4 Revision 0 Asynchronous Transfer Mode (ATM)
Asynchronous Transfer Mode (ATM)
· Data transferred in Cells
· Fast Switching
· Supports Real–Time Services
· Connection Orientated – Virtual Circuits
· Resource Allocation on Requirement Basis
· Primary User Rate – 155.2 Mbps
· Network Interface – 622.08 Mbps
· No Error Correction or Flow Control
Header Payload
5 Bytes 48 Bytes
CP13_Ch5_13

NOT BE UPDATED
ATM Data Rates Issue 4 Revision 0
ATM Data Rates

The real data rate are not always the stated ATM data rate, this is mainly because of the
overheads like packet headers. When ATM is multiplexed onto different types of links
some of the information rate is also lost.
NOT BE UPDATED
Issue 4 Revision 0 ATM Data Rates
ATM Data Rates
Physical Layer Parameter Values

lower bit–rate higher bit–rate
(mbit/s) (mbit/s)
gross physical–layer bit–rate 155 . 520 622 . 080
max bit–rate available for ATM cells 149 . 760 599 . 040
max bit–rate available for cell payload 135 . 631 542 . 526
CP13_Ch5_14

NOT BE UPDATED
ATM Adaptation Layers (AALs) Issue 4 Revision 0
ATM Adaptation Layers (AALs)

The ATM Adaptation Layer (AAL) is the protocol used between the ATM layer itself and
higher layers. The main functionality is to adapt the information coming in from the higher
layers so they can be transferred onto ATM. This is what gives ATM its powerful property
of transferring many traffic types, and ensures appropriate service characteristics are
provided.
The AALs are divided into 5 different categories, where AAL1 has the lowest delay and
AAL5 the highest. This means that services like speech will tend to go towards a lower
AAL number.
Horizontally the AAL protocol is divided into the Convergence Sublayer (CS) and the
Segmentation and Reassemble Sublayer (SAR).
NOT BE UPDATED
Issue 4 Revision 0 ATM Adaptation Layers (AALs)
ATM Adaptation Layers
Class A Class B Class C Class D
Timing Relation Required Not Required
Bit Rate Constant Variable
Connection Connection
Connection Rate
Orientated Less
Emulation Connection Connection

Variable Bit
Examples of Circuits Orientated Data Less Data
Rate Video
CPCM Transmission Transmission
Service Type AAL 3/4 or

AAL 1 AAL 2
to be used AAL 5
CP13_Ch5_11

NOT BE UPDATED
The ATM Adaptation Process Issue 4 Revision 0
The ATM Adaptation Process

The AAL consists of two sub–layers; The Convergence sub–layer (CS) and the
segmentation and reassembly sub–layer (SAR).
Convergence
Sub–Layer (CS)
The function of the CS is to divide very long packets into fixed–length packets called
CS–service data units (CS–SDUs). It may add header and/or trailer information to the
CS–SDU to generate a CS–protocol data unit (CS–PDU). Finally it passes the
CS–PDUs to the SAR.
Segmentation
and Reassembly
At the source end, the SAR sub–layer is responsible for segmenting each CS–PDU
received from the CS sub–layer into fixed–length SAR–SDUs according to the application
traffic type. The SAR then appends a header and/or trailer to each SAR–SDU to
generate an SAR–PDU that it sends to the ATM layer, to be built into the cell.
At the destination end, the SAR is responsible for reassembling all SAR–PDUs belonging
to the same CS–PDU and presenting the reassembled CS–PDU to the CS.
NOT BE UPDATED
Issue 4 Revision 0 The ATM Adaptation Process
Generic AAL Process
User
Header User Trailer

CS
PROCESS
H CS–SDU T H CS–SDU T H CS–SDU T

CS–PDU
H SAR–SDU T H SAR–SDU T
SAR
PROCESS SAR–PDU
ATM H SAR–PDU H SAR–PDU ATM Cell

LAYER
CP13_Ch5_31

NOT BE UPDATED
ATM Adaptation Layer 2 (AAL2) Issue 4 Revision 0
ATM Adaptation Layer 2 (AAL2)

AAL 2 is designed for applications with a variable bit rate but requiring real time delivery.
It supports mechanisms, which can identify and multiplex multiple users over a common
ATM layer connection.
AAL2 is a lot more efficient at transporting voice as there is a more efficient use of
bandwidth due to silence detection and suppression as well as idle channel deletion.
In This type of AAL, the convergence sub–layer further divided into two parts. Common
Part Convergence Sub–layer (CPCS), over which may operate zero or more Service
Specific Convergence Sub–layer (SSCS). In UMTS the Higher level protocols used,
do not require the support of an SSCS.
CPCS
User information, from multiple users is received at the CPCS sub–layer and placed into,
containing a variable length CPS–Information Field (1–64 Octets) and a three octet
CPS Header. The header contains; The Channel ID (CID) which identifies the
sub–stream within the AAL2 connection. The Length indication (LI) indicates the length of
the
CPS–INFO payload. The User–to–User Indication (UUI) carries information between the
SSCSs/Applications running above the CPS. The Header Error Control (HEC) can be
used to report errors within the header.
Dependent upon size multiple CPS Packets, from different sources, can be multiplexed
to form 47 Octet CPS–SDUs, (If necessary, padding can be added to give 47–Octets). A
further header is added to the SDU to yield a 48 Octet CPS–PDU. The CPS–PDU
header contains an Offset Field (OSF) which is a pointer to the first octet of the next
CPS–Packet in the CPS–SDU. The 1 bit sequence number is an alternating logic–1,
logic–0, logic–1, etc sequence. A single parity bit is also included.
The Complete CPS–PDU is now 48–octets, and is now passed unchanged to the ATM
layer, to be built directly into an ATM cell.
NOT BE UPDATED
Issue 4 Revision 0 ATM Adaptation Layer 2 (AAL2)
AAL 2
3–Octet CPS Header User Information
CID LI UUI HEC CPS–Information field

8bits 6bits 5bits 5bits VARIABLE 1 – 64 Octets
CPS–Packet
CPS–SDU Header CPS–SDU
OSF SN P Info packets or padding

6bits 1bit 1bit 47 Octets
CPS–PDU
HEADER OSF SN P Info Packets or padding
ATM Cell (53–Octets)
CP13_Ch5_32

NOT BE UPDATED
ATM Adaptation Layer 5 (AAL 5) Issue 4 Revision 0
ATM Adaptation Layer 5 (AAL 5)

The most recent of the adaptation layers, AAL 5 is also becoming the most popular and
has largely superseded AAL3/4. Often referred to as the Simple And Efficient
Adaptation Layer (SEAL), it supports a wide variety of applications. It is the adaptation
layer of choice for the ATM signalling protocol on VCI 5. MPEG video and Frame Relay
also use AAL 5. Unlike AAL2 (or AAL 3/4) AAL5 does not support multiplexing of data
from multiple higher layer applications
AAL 5 takes any user data, normally as a frame, adds some padding and an 8–byte
trailer so that the whole of the resulting CPCS PDU is N x 48–bytes long. The PDUs are
then sent for segmentation by SAR and forwarded 48–bytes at a time to the ATM layer.
When the last cell from the PDU is given to the ATM layer, the ATM layer is informed that
it is the last cell. The ATM layer then sets the “End of User Data” bit in the ATM header to
inform the receiving end.
In the receiver, the ATM layer passes the payloads up to the SAR sublayer. When the
last cell arrives, it is recognised by the ATM layer. The ATM layer informs the SAR layer
that the payload is the last for that frame. The SAR presents the assembled PDU to the
CS. The CS performs a CRC on the PDU and compares this with the last 4 bytes in the
trailer. If the CRCs match, the CS then checks the 2–byte Length Indicator (LI). The LI
field indicates the amount of user data in the PDU so that the CS can remove the
padding and recover the user data. Should the CRC not match, then the whole PDU is
discarded. AAL 5 relies on the application to recover from lost frames. For video
applications, the last correct frame received would be repeated. For LAN data, the
transport protocol would arrange for re–transmission of the missing frame.
CPI Common Part Indicator LI Length Indicator

PDU Protocol Data Unit AAL ATM Adaptation Layer
SDU Service Data Unit CRC Cyclic Redundancy Check
CPCS Common Part Convergence SAR Segmentation And Reassemb-
Sublayer ly
NOT BE UPDATED
Issue 4 Revision 0 ATM Adaptation Layer 5 (AAL 5)
AAL5
AAL 5
User Data
SDUs
1 – 65,535 bytes 0–47 1 1 2 4

CPCS
CPCS–PDU Payload PAD CPS–UU CPI LI CRC
PDUs
SAR Payload SAR Payload SAR Payload

SAR
PDUs
ATM
H SAR Payload H SAR Payload H SAR Payload CELLS
CP13_Ch5_33

NOT BE UPDATED
Virtual Channels and Paths Issue 4 Revision 0
Virtual Channels and Paths

On physical level ATM connect via the specification of Virtual Paths (VPs) and Virtual
Channels (VCs). A Virtual Channel will be located inside a Virtual Path. A Virtual Channel
Identifier (VCI) will identify the Virtual Channel and the Virtual Path Identifier (VPI) will
identify the Virtual Path (VP).
In total we could have up to 256 addresses for a VP User to Network Interface (UNI) and
4096 for a VP Network to Network Interface (NNI). When VCIs are used, up to 216
channels per path can be addressed.
Use of Virtual
Channels and
Paths
A virtual channel provides an end–to–end connection, referred to as a Virtual Channel
Connection. This connection in turn may consist of a number of VC and VP
components. These components are illustrated opposite and are defined as follows:
Virtual Channel Link

A virtual channel link is a unidirectional facility transporting ATM cells between two
consecutive ATM entities where a VCI value is assigned, remapped or removed. For
example, between an ATM endpoint and a VC Switch, or between two VC switches.
Virtual Channel Connection

A virtual channel connection is a concatenation of virtual channel connections.
Virtual Path Link

A virtual path link is a unidirectional facility transporting ATM cells between two
consecutive ATM entities where a VPI value is assigned, remapped or removed. For
example, between an ATM endpoint and a VC Switch, or between two VC switches.
Virtual Path Connection

A virtual path connection is a concatenation of virtual path connections.
NOT BE UPDATED
Issue 4 Revision 0 Virtual Channels and Paths
Virtual Channels and Paths

Virtual Path (VP)
ATM Path
Virtual Channel (VC)
Each VP within the physical layer has a different VPI value

Each VC within a VP has a different VCI value
CP13_Ch5_15
Use of Virtual Channels and Paths

Virtual Channel Connection Endpoints
Virtual Channel Connection

Virtual Channel Link Virtual Channel Link
ATM ATM
END VP Switch VC Switch END
SYSTEM SYSTEM
VC Switch – VCI and VPI

Virtual Path Link Virtual Path Link values change
Virtual Path Connection
Virtual Path Connection Endpoints

CP13_Ch5_16

NOT BE UPDATED
Virtual Connection and Path Switching Issue 4 Revision 0
Virtual Connection and Path Switching

When addressing is carried out on VP level only a VP address would be needed since all
the VCs are inside the VP. Therefore we would only switch on VP level like illustrated in
the diagram. If however VCs need to be switched a VP Switch combined with a VC
Switch would be needed.
The switching in ATM could get complicated at times therefore special tools have been
developed to help with this aspect.
NOT BE UPDATED
Issue 4 Revision 0 Virtual Connection and Path Switching
Virtual Connection and Path Switching
VC Switch
Endpoint
of VPC
VP Switch VP Switch
Representation of VC and VP Switching Representation of VP Switching
CP13_Ch5_17

NOT BE UPDATED
E1 Architecture Issue 4 Revision 0
E1 Architecture
Logical Links
We have seen some of the mediums over which the data is transmitted, now let us
consider the format of the data that is carried over these means.
In GSM all the data is in digital form, and the path that the data takes is called a Logical
Link. The format of the data is dependent on where in the system the data is and what
sort of data needs to be transferred.
E1
In the European GSM system the basic building block of data that gets carried around
the network is based around the multiplexed 2.048 Mbit/s frame.
This frame contains 32 channels of 64 Kbit/s. 30 are used for user information. Channel
0 is reserved for timing and synchronisation and channel 16 is used for signalling.
E1 also specifies the sampling rate, frequency bandwidth, bits per sample, time slots per
frame, output bit rate, encoding law and the dedicated signalling and synchronisation
channels.
T1
T1 is the American version of E1.
There are significant differences in the make up of the TDM frame.
T1 uses 24 time slots per frame, with 24 PCM channels per frame. The output bit rate is
1.544 Mbit/s and the signalling used in the frame is only used once every 6th frame,
instead of every frame in E1.
NOT BE UPDATED
Issue 4 Revision 0 E1 Architecture
E1 Architecture
T1/DS1
Frequency 300 – 3400Hz
Sampling Rate 8000Hz
Bits per Sample 8
Bits per Frame 193
PCM Channels per Frame 24
Output Bit Rate 1.544 Mb/s
Encoding Law µ Law
Signalling Capabilities 1st bit in frame – Sync
1 bit in timeslots 6 and 12
E1
Frequency Range 300 – 3400Hz
Sample Rate 8000Hz
Bits per Sample 8
Time Slots per Frame 32
Output Bit Rate 2.048 Mb/s
Encoding Law A LAW
Signalling Capabilities TS0 Sync
TS16 Signalling
CP13_Ch5_22

NOT BE UPDATED
ATM Cell to E1 Cell Mapping Issue 4 Revision 0
ATM Cell to E1 Cell Mapping

The ATM cell is mapped into bits 9 to 128 and bits 137 to 256 (i.e. time slots 1 to 15 and
time slots 17 to 31) of the 2048 kbit/s frame as specified in ITU–T Recommendation
G.704[2] and as shown in the Figure opposite. The ATM cell octet structure shall be
aligned with the octet structure of the frame.
There shall be no relationship between the beginning of an ATM cell and the beginning
of an 2048 kbit/s transmission frame. Since the frame payload capacity (30 octets) is not
an integer multiple of cell length (53 octets), ATM cells will cross the E1 frame boundary.
NOT BE UPDATED
Issue 4 Revision 0 ATM Cell to E1 Cell Mapping
ATM Cell to E1 Cell Mapping
T50 T516: Reserved for signalling

250 Bits/125µsec
Header
Header
Header
Header
ATM Cell Mapping field: 80 octets (T51 – T515 and T517 – T51)
ATM Cell Header
58 octets
Note: This diagram has been taken from ITU–TRecommendation GZ04, Figure 8–1
CP13_Ch5_34

NOT BE UPDATED
E Link Multiplexing Issue 4 Revision 0
E Link Multiplexing
The standard E1 and T1 streams can be further multiplexed to put more channels over
one transmission path.
NOT BE UPDATED
Issue 4 Revision 0 E Link Multiplexing
E Series Hierarchies
E1 E2 E3 E4 E5
2.048 Mb/s 8.448 Mb/s 34.368 Mb/s 139.264 Mb/s 564.992 Mb/s
30 TCH
x4
120 TCH
x4
480 TCH
x4 1,920 TCH
7,680 TCH
x4
CP13_Ch5_23

NOT BE UPDATED
Inverse Multiplexing for ATM (IMA) Issue 4 Revision 0
Inverse Multiplexing for ATM (IMA)

Inverse Multiplexing for ATM (IMA) is a methodology which provides a modular
bandwidth, for user access to ATM networks and for connection between ATM network
elements, at rates between the traditional order multiplex level. An example is to achieve
rates between the DS1/E1 and DS3/E3 levels in the asynchronous digital hierarchies.
DS2/E2 physical links are not necessarily readily available throughout a given network.
Therefore the introduction of ATM Inverse Multiplexers provides an effective method of
combining the transport bandwidths of multiple links (e.g., DS1/E1 links) grouped to
collectively provide higher intermediate rates.
The ATM Inverse Multiplexing technique involves inverse multiplexing and
de–multiplexing of ATM cells in a cyclical fashion among links grouped to form a higher
bandwidth logical link whose rate is approximately the sum of the link rates. This is
referred to as an IMA group. The figure opposite provides a simple illustration of the ATM
Inverse Multiplexing technique in one direction. The same technique applies in the
opposite direction.
IMA groups terminate at each end of the IMA virtual link. In the transmit direction, the
ATM cell stream received from the ATM layer is distributed on a cell by cell basis, across
the multiple links within the IMA group. At the far–end, the receiving IMA unit recombines
the cells from each link, on a cell by cell basis, recreating the original ATM cell stream.
The aggregate cell stream is then passed to the ATM layer.
The IMA interface periodically transmits special cells that contain information that permit
reconstruction of the ATM cell stream at the receiving end of the IMA virtual link. The
receiver end reconstructs the ATM cell stream after accounting for the link differential
delays, smoothing CDV introduced by the control cells, etc. These cells, defined as IMA
Control Protocol (ICP) cells, provide the definition of an IMA frame. The transmitter must
align the transmission of IMA frames on all links. This allows the receiver to adjust for
differential link delays among the constituent physical links. Based on this required
behavior, the receiver can detect the differential delays by measuring the arrival times of
the IMA frames on each link.
At the transmitting end, the cells are transmitted continuously. If there are no ATM layer
cells to be sent between ICP cells within an IMA frame, then the IMA transmitter sends
filler cells to maintain a continuous stream of cells at the physical layer. The insertion of
Filler cells provides cell rate decoupling at the IMA sublayer. The Filler cells should be
discarded by the IMA receiver.
NOT BE UPDATED
Issue 4 Revision 0 Inverse Multiplexing for ATM (IMA)
Inverse Multiplexing and De–multiplexing of ATM cells
IMA Group IMA Group

Physical Link #0
PHY PHY
Physical Link #1
PHY PHY
Single ATM CellStream Original ATM Cell
from ATM Layer Stream to ATM Layer
Physical Link #2
PHY PHY
Tx direction: cells distributed across links in round robin sequence

CP13_Ch5_35 Rx direction: cells recombined into single ATM stream
IMA Frames
IMA Frame 2 IMA Frame 1 IMA Frame 0
ATM ATM ATM F ICP2 F F ATM F ICP1 ATM F ATM F ICP0 Link 0
M–1 3 2 1 0 M–1 3 2 1 0 M–1 3 2 1 0
F ICP2 ATM F F ATM ICP1 ATM ATM ATM ATM ICP0 ATM F F Link 1
F ATM ATM ICP2 F ATM F ATM ICP1 ATM ATM F ATM ICP0 ATM Link 2
Time
ICP1 ICP Cell in Frame # 1 F Filler Cell ATM ATM Layer Cell
CP13_Ch5_36

NOT BE UPDATED
Plesiochronous Digital Hierarchy (PDH) Issue 4 Revision 0
Plesiochronous Digital Hierarchy (PDH)

When already multiplexed streams are added together, a problem with timing arises.
Because the timing sources of each stream are derived from separate clocks, there
maybe slight differences in them.
To overcome this synchronisation problem, the output bit rate from the higher order
multiplexer is increased to allow for extra justification bits to be inserted. These
justification bits allow the combined bit streams to sync correctly before retransmission at
the higher bit rate.
If, for example, four E1 links are multiplexed together, they will be transmitted over an
8.448Mbps stream, not 8.192 Mbps. The channel multiplexing is unaffected, the 30 E1
information channels become 120 in the new stream.
This higher form of multiplexing is called Plesiochronous, which translates to nearly
synchronous. The resulting higher order multiplexing rates are known as Plesiochronous
Digital Heirarchys (PDH).
NOT BE UPDATED
Issue 4 Revision 0 Plesiochronous Digital Hierarchy (PDH)
PDH
Nearly Synchronous
140 Mb/s
LTE
140 Mb/s 140 140 140 Mb/s

LTE 34 34 LTE
34 34
8 8
8 8
2 2
Customer
Site
CP13_Ch5_21

NOT BE UPDATED
Synchronous Digital Hierarchy (SDH) Issue 4 Revision 0
Synchronous Digital Hierarchy (SDH)

With the advent of fully digital and synchronous networks the CCITT defined a new
multiplexing hierarchy called Synchronous Digital Hierarchy (SDH). In the USA is called
Synchronous Optical Network (SONET) with the two major differences being terminology
and the basic line rates used (SONET - 51.84 Mb/s).
SDH uses a basic transmission rate of 155.52 Mb/s (abbreviated to 155 Mb/s) and
multiples of 4n.
This basic rate is known as a Synchronous Transport Module level 1 (STM-1), higher
rates are STM-4 and STM-16.
As with PDH, the signal is repetitive frames with a repeat period of 125µs. Any of the
PDH rates can be multiplexed into the STM-1.
The main advantages of SDH are:
It allows direct access to tributary signals without demultiplexing the composite
signal.
It supports advance operations, administration and maintenance by dedicating
channels for this purpose. The network can therefore be reconfigured under
software control from remote terminals.
Overhead bytes have been preserved for growth to support services and
technologies of the future.
NOT BE UPDATED
Issue 4 Revision 0 Synchronous Digital Hierarchy (SDH)
SDH
SDH Bit Rates

Synchronous Transport Transmission
Module Rate
STM – 1 155.52 Mb/s
STM – 4 622.08 Mb/s
STM – 16 2,488.32 Mb/s
STM – N N x 155.52 Mb/s
CP13_Ch5_19

NOT BE UPDATED
Principles of SDH Issue 4 Revision 0
Principles of SDH
Although a full description of SDH is beyond the scope of this course, this section will
cover the main principles.
The diagram shows the SDH multiplex structure, indicating how an STM is formed from
various PDH traffic rates. The following terms are used in the diagram, and further
explained below:
C – Container
VC – Virtual Container
TU – Tributary Units
TUG – Tributary Unit Group
AU – Administrative Unit
AUG – Administrative Unit Group
The following table lists the suffices used when referring to PDH traffic rates within SDH
signals:
n Suffix Bit rate kbps

0 64
11 1,554
12 2,048
21 6,312
22 8,448
31 34,368
32 44,736
4 139,264
NOT BE UPDATED
Issue 4 Revision 0 Principles of SDH
Principles of SDH
SDH Multiplex Structure

x1
STM–N AUG AU–4 VC–4 C–4 140 Mbit/s
x3
x1
x3 TUG–3 TU–3 VC–3
x7
AU–3 VC–3 C–3 45 Mbit/s
34 Mbit/s
x7 x1
TUG–2 TU–2 VC–2 C–2 6 Mbit/s
x3
TU–12 VC–12 C–12 2 Mbit/s

x4
TU–11 VC–11 C–11 1.5 Mbit/s
CP13_Ch5_37

NOT BE UPDATED
SDH Drop and Insert Issue 4 Revision 0
SDH Drop and Insert

SDH overcomes the limitations of plesiochronous networks, and will allow transmission
networks to evolve to meet the demands of emerging broadband services.
Network
Simplification
Synchronous transmission equipment eliminates the multiplexer mountain, leading to
lower equipment and maintenance costs, and improved service provisioning. The
diagram shows how 2Mb/s channels can be dropped and inserted from an STM–1 by
means of remote commands at a network management station. The flexibility of SDH
transmission is attractive to carriers because it offers the potential of generating new
revenues.
Survivability
SDH includes overheads for end–to–end monitoring and maintenance of transmission
equipment; the network management station can immediately identify the failure of links
and equipment. Furthermore, as shown in the diagram, an SDH network can be
constructed with a self–healing ring architecture that automatically re–routes traffic until
the faulty segment is repaired; there will be no disruption of service to the end user,
allowing carriers to guarantee service levels.
Software Control
SDH also includes overheads for management channels; these are used for
performance monitoring, equipment configuration, resource management, network
security, inventory management, network planning and network design. Since all of
these management operations can be performed remotely, SDH offers the possibility of
centralised network management and provisioning, with associated cost savings.
Bandwidth on
Demand
The flexibility of SDH allows carriers to allocate network capacity dynamically in that
users will be able to subscribe at very short notice to large bandwidth services e.g.
video–conferencing. This feature opens up the possibility of providing new services e.g.
high–speed LAN interconnection and High Definition TV.
NOT BE UPDATED
Issue 4 Revision 0 SDH Drop and Insert
SDH Drop and Insert
155Mb/s alternate routing

using ring topology
SDH Mux Management of SDH Mux

2Mb/s traffic
2Mb/s interface 2Mb/s interface
12 63 155Mb/s 155Mb/s
SDH Mux 155Mb/s SDH Mux

2Mb/s interface 2Mb/s interface
CP13_Ch5_38

NOT BE UPDATED
ATM to STM Mapping Issue 4 Revision 0
ATM to STM Mapping

B-ISDN maintains a transmission rate of 155.520 Mbps or 622.080 Mbps. The physical
medium can be optical with an extension capability of 0 - 800m or coaxial cable with an
extension capability of 0 - 100m. The SDH-based signal is formed by filling the VC-4
payload space of an STM frame with ATM cells and the OAM ( Operations,
Administration & Maintenance ) signals are transported via STMs SOH or POH ( Section
overhead, Path overhead ). Since, in case of the transmission speed being
155.520Mbps, only 149.760Mbps is filled with ATM cells and the other 5.760Mbps is filled
with STM frame overheads (SOH, POH, Pointer ). Identifying cell boundaries is done
using HEC or an SDH overhead.
NOT BE UPDATED
Issue 4 Revision 0 ATM to STM Mapping
ATM to STM Mapping
9 octets 261 octets

STM–1
3 SOH
1 octet 260 octets
VC–4
1 AU4–PTR J1
B3
C2
5 SOH
G1
H4
ATM Cell
VC–4 POH
53 octets
CP13_Ch5_20

NOT BE UPDATED
Typical UMTS Transport Network Issue 4 Revision 0
Typical UMTS Transport Network

The diagram opposite shows a typical implementation of an ATM transport network to
support the UMTS interfaces. The UMTS nodes as shown are connected to a single
SDH ring, whereas there may actually be several rings involved depending on the
network providers configuration and may include PDH interfaces as well.
Node Bs use E1 physical interfaces and in the case where multiple E1’s are used IMA is
utilised by the Node B. The ATM Mux shown in the figure is expected to provide E1
(VC–12) to STM–1 (VC–4) mapping and vice versa in addition to providing IMA and
reverse IMA capability. For a large number of Node B’s, the transport network will have
to provide a significant number of E1 interfaces.
The ATM switch will be utilised for VP and VC switching and will be expected to provide
aggregation of logical interfaces to physical interfaces via VP and VC switching. The
ATM network is also expected to be configurable to limit the throughput of a given
physical interface. For example, the RNC STM–1 physical interfaces need to be limited
to a bandwidth of 100Mbps due to the hardware limitations.
NOT BE UPDATED
Issue 4 Revision 0 Typical UMTS Transport Network
ATM Transport Network
Ethernet
(Option under
STM–1 RNC
investigation)
OMC
STM–1 ATM Switch
Ethernet
MSCu
RNC
STM–1
SDH Ring
(STM–1/STM–4/STM–16)
Node B
Node B
E1, IMA
ATM Switch
E1, IMA
ATM Mux
STM–1 SGSN
E1, IMA STM–1
E1, IMA
Node B RNC
Node B
Node B
CP13_Ch5_39

NOT BE UPDATED
Typical UMTS Transport Network Issue 4 Revision 0
NOT BE UPDATED
Chapter 6
W-CDMA Theory

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 6
W-CDMA Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Multiple Access Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
CDMA Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
W-CDMA Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–6
Re-Use of Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Re–Use of Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–12
Spectral Efficiency (GSM and IS-95) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
Spectral Efficiency – UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
TDD and FDD Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
FDD and TDD Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–20
DS-CDMA Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Scrambling Codes vs Channelisaton Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Modulo-2 Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Orthogonal Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–30
Channelisation Code Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Processing Gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Short Codes vs Long Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Matched Filter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
The Rake Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
State why W-CDMA has been chosen for the UMTS multiple access scheme.
Describe W-CDMA Spreading and Scrambling procedures.

NOT BE UPDATED
Multiple Access Schemes Issue 4 Revision 0
Multiple Access Schemes

There are 3 forms of multiple access schemes, frequency, time and code. The major
issue with the first two is the requirement to have guard bands.
Frequency Division Multiple Access (FDMA)

FDMA divides radio channels into a range of radio frequencies and is used in the
traditional analogue system. With FDMA, only one subscriber is assigned to a channel at
one time. Other subscribers cannot access this channel until the original call is
terminated or handed off to a different channel.
Time Division Multiple Access (TDMA)

TDMA is a common multiple access technique employed in digital cellular systems. It
divides radio channels into time slots to obtain higher capacity. As with FDMA, no other
conversations can access an occupied channel until that channel is vacated.
Code Division Multiple Access (CDMA)

CDMA assigns each subscriber a unique code to put multiple users on the same channel
at the same time. CDMA users can share the same frequency channel because their
conversations are distinguished only by digital code.
NOT BE UPDATED
Issue 4 Revision 0 Multiple Access Schemes
Multiple Access Schemes
Power Time
FDMA
Power Frequency
Time
TDMA
Frequency
Power Time
CDMA
Frequency
CP13_Ch6_01

NOT BE UPDATED
CDMA Options Issue 4 Revision 0
CDMA Options
Spread spectrum was first used in the early 1950s by the military, who have continued to
be its main user up until IS-95 become operational. This has led to spread spectrum
techniques taking a low profile due to their distinct military advantage [Rustad90,
Reed88], which was based on the robust immunity to interference, and jamming. The
major non-military use to date has been for space communications because of its ability
to provide better immunity against noise and interference than any other modulation
technique.
The recent upsurge in open discussions of spread spectrum techniques occurred when
the cellular telephone authorities and service providers looked at better ways of utilising
their overcrowded spectrum during the research and design of the second generation of
cellular telephone systems. They are suited to the mobile environment which is severe,
with propagation conditions varying rapidly both spatially and spectrally, especially at the
higher frequencies, where these conditions become even more severe.
A spread spectrum signal has the ability to co-exist with many types of signal, and with
variations of itself, thus enabling ‘forward compatibility’. It is therefore ideally suited for
the ever increasingly crowded part of the radio spectrum allocated to cellular mobile
radio. The user density can thus be increased as and when new methods become
available. One avenue that is also being researched is the use of spread spectrum as a
secondary system, sharing the same bandwidth with a primary system. The primary
could be any transmission from low-usage government bands to broadcast stations and
line-of-sight data trunk systems. This enables two services to co-exist in the same
bandwidth with a minimum of interference. In the First and Second Generations,
frequency planning has become one of the major ongoing problems, especially in an
ever-changing cellular network with changing frontier boundaries and an increasing
number of multi-service providers.
CDMA is derived from Spread Spectrum Technology. Two type of CDMA exist,
Frequency Hopping CDMA (FH-CDMA) and Direct Sequence (DS-CDMA). A bandwidth
of 5Mhz has been allocated by WARC 92. We also use a chiprate of 3.84 Mcps. This
provides us with a code sequence that is directly modulated with the user data.
NOT BE UPDATED
Issue 4 Revision 0 CDMA Options
CDMA Options
Power Time
DS–CDMA
Frequency
Power Time
FH–CDMA
Frequency
CP13_Ch6_02

NOT BE UPDATED
W-CDMA Characteristics Issue 4 Revision 0
W-CDMA Characteristics
The vital statistics for our W-CDMA UMTS system is shown opposite. Don’t be confused
by the slots and frames, this is not a TDMA system, every user does share the same
band. The frames and slots are used for interleaving.
The major points are:
FDD requires paired frequencies for up and down channels.
The chip rate of 3.84 Mcps provides a bandwidth of 5 MHz. A chip is a pseudo random
code bit.
The carrier spacing of 200 kHz is used to allow re-farming of GSM frequencies which
have been set at 200 kHz spacing.
The frame length is set at 10 ms for both voice and data. This means that a better
speech codec is required than in GSM, which is 20 ms. This means that the codec
delays are halved from 40 to 20 ms.
Each frame is split into 15 timeslots each timeslot contains user data, power control and
signaling data.
The UMTS system does not require synchronisation due to the framing structure and use
of matched filters for the framing alignment.
The spreading factor is the ratio between the user data and the chip rate. As the user
data increases this factor will vary between 4 and 512. The spreading factor is a rough
indication of the number of users in the system.
The user data rates available in the FDD system is up to 384 Kbps.
NOT BE UPDATED
Issue 4 Revision 0 W-CDMA Characteristics
W-CDMA Characteristics
Multiple Access Scheme CDMA

Duplexing Method FDD
Chip Rate 3.84 Mcps
Bandwidth 5 MHz
Carrier Spacing 200 kHz Raster
Frame Length 10 ms
Slots per Frame 15
Inter–cell Synchronization None
Spreading Factor Variable (4–512)
User Data Rate 3–384 Kbps
CP13_Ch6_03

NOT BE UPDATED
Re-Use of Frequency Issue 4 Revision 0
Re-Use of Frequency
Mobile telephones and cell broadcast networks use cellular radio, a technique developed
in recent years to enable the use of mobile telephones. It would be impossible to provide
each phone with an individual radio frequency, so the idea of cellular radio evolved.
A region is divided into geographical areas called cells, varying in size depending on the
number of users in the area. In cities cells are small whereas in rural areas cells are
much larger.
Cells use a set of frequencies that are different from any neighbouring cell, but can be
the same as another cell as long as it is far enough away.
It is the same principle as GSM, which is shown in the diagram.
NOT BE UPDATED
Issue 4 Revision 0 Re-Use of Frequency
Re-Use of Frequency
2 5
4 7
2
1 6 4
6
5 3 1
7 2 5 3
4 7 2 5
6 4 7 2
1
3 1 6 4
5 3 1 6
7 2 5 33
4 7 2
1 6 4
3 1
CP13_Ch6_14

NOT BE UPDATED
Bandwidth Usage Issue 4 Revision 0
Bandwidth Usage
In UMTS a 5MHz bandwidth is assigned to each Absolute Radio Frequency Channel
(ARFCN). Some Network Operators will have only one of these ARFCNs where other
Network Operators might have up to three channels available for FDD. Because of the
characteristics of UMTS not many ARFCNs are required, in fact a Network Operator
could have as little as only one and would still be able to build a perfectly well operating
network.
The problem that the Network Operators might experience however is adjacent channel
interference. This is due to two Network Operator frequencies that lie right next to each
other. The solution to this problem is to reduce the frequency by 200KHz steps according
to the raster provided. This action will definitely help; it must be noted however that this is
not an ideal world and the bandwidth power can not immediately fall to a zero power
level.
Root raised cosine pulse shaping filters (RRCPSF) are used to help reduce the
interference as quickly as possible. As can be seen in the Slide opposite, despite this
effort we still get interference in the first adjacent band termed Adjacent Channel
Leakage Ratio 1 (ACLR1) and in the second band thereafter called Adjacent Channel
Leakage Ratio 2 (ACLR2).
NOT BE UPDATED
Issue 4 Revision 0 Bandwidth Usage
Bandwidth Usage
Power
RRCPSF
ACLR 1
ACLR 2
4,8 Mhz
Frequency
5 Mhz
ACLR = Adjacent Channel Leakage Ratio
CP13_Ch6_08

NOT BE UPDATED
Re–Use of Codes Issue 4 Revision 0
Re–Use of Codes
Scrambling Codes (SC) are used to uniquely identify a cell in the network. Frequency
planning are more or less a thing of the passed but code planning will have to be
implemented. Code planning will be much easier then frequency planing since we have
512 Codes to play with, the code re-use pattern will thus be extremely large.
Codes can be reused when the separation between cells containing the same channel
set is far enough apart so that co-channel interference can be kept below acceptable
levels. The number of cells in a cluster is 512, which provides greater separation
between co-channel cells than GSM.
In the uplink direction a code will uniquely identify a UE. Scrambling codes in general are
long codes of 10ms duration, which equate to 38400 Chips. Short Scrambling Codes
could be used in the uplink if advanced multi-user detection schemes is implemented.
NOT BE UPDATED
Issue 4 Revision 0 Re–Use of Codes
Re-Use of Codes
1 10
5 2 11
7 4 4
30 6 17 19
31 28 15 12
29 7 16 18
1 27 4 22 20
26 14 6 21
25 13 23 39
32 2 5 38
34 33 24
36 37 40
35 41
CP13_Ch6_15

NOT BE UPDATED
Spectral Efficiency (GSM and IS-95) Issue 4 Revision 0
Spectral Efficiency (GSM and IS-95)

The Slide opposite shows how spectrally efficient IS-95 and GSM is in comparison to
each other when employed in a multi-cellular structure.
The capacity, which Shannon derived in 1947, provided a Law, which we now call
Shannons Law. This details the digital capacity of the link given the transmit power and
the bandwidth.
If we are using, FDMA, TDMA or CDMA, the capacity is still controlled by this law.
However, some gains are made by technology and coding methods.
NOT BE UPDATED
Issue 4 Revision 0 Spectral Efficiency (GSM and IS-95)
Spectral Efficiency (GSM and IS-95)
GSM IS –95
8 Calls = 200 kHz Carrier 32 Calls = 1.25 MHz Carrier

1 Call = 25 kHz 1 Call = 39 kHz
7 x 200 kHz = 1.4 MHz 7 Cells, 1.25 MHz

1 Call = 25 kHz 1 Call = 5.5 kHz
CP13_Ch6_06

NOT BE UPDATED
Spectral Efficiency – UMTS Issue 4 Revision 0
Spectral Efficiency – UMTS

The diagram opposite shows how spectral efficient UMTS with SF of 512 is compared to
UMTS with SF of 256.
NOT BE UPDATED
Issue 4 Revision 0 Spectral Efficiency – UMTS
Spectral Efficiency – UMTS
UMTS–SF 512 UMTS–SF 256
512 Calls = 5 MHz Carrier 256 Calls = 5 MHz Carrier
1 Call = 9.7 kHz 1 Call = 19.4 kHz
7 Cells, 5 MHz 7 Cells, 5 MHz

1 Call = 1.4 kHz 1 Call = 2.8 kHz
CP13_Ch6_07

NOT BE UPDATED
TDD and FDD Frame Structure Issue 4 Revision 0
TDD and FDD Frame Structure

The access scheme is Direct-Sequence code Division Multiple Access (DS-CDMA) with
information spread over approximately 5 MHz bandwidth, thus also often denoted as
Wideband CDMA (W-CDMA) due to that nature.
UTRA has two modes, FDD (Frequency Division Duplex) & TDD (Time Division Duplex),
for operating with paired and unpaired bands respectively. The possibility to operate in
either FDD or TDD mode allows for efficient utilisation of the available spectrum
according to the frequency allocation in different regions. FDD and TDD modes are
defined as follows;
FDD: A duplex method whereby uplink and downlink transmissions use two
separated radio frequencies.
TDD: A duplex method whereby uplink and downlink transmissions are
separated by timeslots and carried over the same bandwidth and frequency.
In UTRA TDD there is TDMA component in the multiple access in addition to DS-CDMA.
Thus the multiple access has been also often denoted as TDMA/CDMA due added
TDMA nature.
A 10 ms radio frame is divided into 15 slots (2560 chip/slot at the chip rate 3.84 Mcps). A
physical channel is therefore defined as a code (or number of codes) and additionally in
TDD mode the sequence of time slots completes the definition of a physical channel.
The information rate of the channel varies with the symbol rate being derived from the
3.84 Mcps chip rate and the spreading factor. Spreading factors are from 256 to 4 with
FDD uplink, from 512 to 4 with FDD downlink, and from 16 to 1 for TDD uplink and
downlink. Thus the respective modulation symbol rates vary from 960 k symbols/s to 15
k symbols/s (7.5 k symbols/s) for FDD uplink (downlink), and for TDD the momentary
modulation symbol rates shall vary from 3.84 M symbols/s to 240 k symbols/s.
Furthermore, relaying between nodes can be used by means of Opportunity Driven
Multiple Access (ODMA) in TDD mode.
The specification for FDD developed much more quickly than the TDD variant. However
TDD is seen as useful in the unpaired band and where high-speed small cells are
required. The radio network is supposed to support either scheme.
NOT BE UPDATED
Issue 4 Revision 0 TDD and FDD Frame Structure
TDD and FDD Frame Structure
10 msecs
10 msecs
0 14 Timeslots
CP13_Ch6_04

NOT BE UPDATED
FDD and TDD Differences Issue 4 Revision 0
FDD and TDD Differences

TDD uses the same basic principle then FDD to provide 2Mbps over the 5Mhz channel.
Factors common to both technologies include Quadrature Phase Shift Keying modulation
and support for common and dedicated channels.
FDD uses a variable spreading factor and multicodes whereas TDD utilises multiple
timeslots and multicodes.
FDD - Frequency Division Duplex
TDD - Time Division Duplex
QPSK - Quadrature Phase Shift Keying
NOT BE UPDATED
Issue 4 Revision 0 FDD and TDD Differences
FDD and TDD Differences
W–CDMA TD–CDMA
Duplex Scheme FDD TDD
Band Separate for UL and DL Same UL and DL
Timing Reference Asynchronous Node–B Synchronous Node–B
Power Conrol Fast Slow
Mobility Good Poor
Handover Soft Hard
Working Primarily Symmetric Asymmetric 80:1
Multi–rate/ Variable spreading factor Multiple Timeslots and
Variable rate and Multicodes Multicodes
Modulation QPSK
Packet Access Supported for common and dedicated channels
User Data Rate Up to 384 Kbps Up to 2 Mbps
CP13_Ch6_05

NOT BE UPDATED
DS-CDMA Implementation Issue 4 Revision 0
DS-CDMA Implementation
Transmitter
The digital modulator will take digital speech/data and multiply it with the spreading code.
(Scrambling and channel codes).
The radio modulator moves the baseline signal from the digital modulator onto a 2Ghz
carrier to produce the W-CDMA output.
Receiver
The modulated carrier is moved by the radio demodulator to the digital demodulator
which can be very complicated due to the large number of MTPs.
Here the input is multiplied by the de-spreading codes to produce digital speech.
MTP-Message Transfer Part.
NOT BE UPDATED
Issue 4 Revision 0 DS-CDMA Implementation
DS-CDMA Implementation
Single User Channel Multiple User Channel Multiple User Channel Output
3.5 MHz 3.5 MHz 3.5 MHz 0

W–CDMA
Digital Radio Modulated Carrier
Digital S Radio Digital Digital
Signal Modulator Modulator C
o p Demodulator Demodulator Signal
m l
b i
Spreading Spreading
Tx Code
Radio i t Radio Code Rx
Carrier n t Carrier
Generator e Generator
e
r r
Digital Digital Radio Radio Digital Digital
Signal Modulator Modulator Demodulator Demodulator Signal
Input
External Interference
0 t0
CP13_Ch6_26

NOT BE UPDATED
Spreading Issue 4 Revision 0
Spreading
The user information bits are multiplied with several code bits (chips) to form the
transmitted signal. The ratio of the user and chip rates is the spreading factor or
processing gain.
Spreading is applied to the physical channels. It consists of two operations. The first is
the channelisation operation, which transforms every data symbol into a number of chips,
thus increasing the bandwidth of the signal. The number of chips per data symbol is
called the Spreading Factor (SF). The second operation is the scrambling operation,
where a scrambling code is applied to the spread signal.
With the channelisation, data symbol on so called I and Q-branches are independently
multiplied with an OVSF code. With the scrambling operation, the resultant signals on the
I and Q-branches are further multiplied by complex-valued scrambling code, where I and
Q denote real and imaginary parts, respectively.
Multiplying the bipolar representation of each together raises the data to the chip rate.
The resultant signal is at the chip rate that contains the data. There are 8 chips per bit in
this simple case. Multiplying the spread signal by the pseudo noise will, of course, restore
the data.
NOT BE UPDATED
Issue 4 Revision 0 Spreading
Spreading
· After spreading each ”bit” of the data signal is

represented by a ”number of chips”
· The spreading factor is the chipping bit rate

divided by the source signal bit rate
· The spreading factor (SF) is also known as the

processing gain (PG) (Ratio)
+1
0 1 – Bit
1 –1
+1
0
1 –1
8 – Chips
CP13_Ch6_11

NOT BE UPDATED
Scrambling Codes vs Channelisaton Codes Issue 4 Revision 0
Scrambling Codes vs Channelisaton Codes

The Slide shows the major differences between Scrambling Codes (SC) and
Channelisation Codes (CC).
NOT BE UPDATED
Issue 4 Revision 0 Scrambling Codes vs Channelisaton Codes
Scrambling Codes vs Channelisation Codes
CC SC
Usage Uplink Separation of Data & Control Channels Separation of UEs
Usage Downlink Separation of channels to different UEs Separation of Cells
Length Uplink 4 – 256 Chips 10ms=38400 Chips or

66.7us = 256 Chips
Length Downlink 4 – 512 Chips 38400 Chips
Number of Codes 256 Uplink and Downlink Uplink = 2P24 = 16,777,216

Downlink =512
LC=10ms = Gold Code
Code Family OVSF SC = Extended S2 Family
Spreading Increases Tx Bandwidth No effect on Bandwidth
CP13_Ch6_12

NOT BE UPDATED
Modulo-2 Addition Issue 4 Revision 0
Modulo-2 Addition
If we take a code sequence and multiple it with some user data, the output sequence can
then be transmitted. Once this is received it is multiplied by the same code sequence to
produce the original data. If the code sequences are not aligned to within 0.2 of a chip (at
3.84Mcps which is 2.60416e-7s per chip and 0.2 is 5.2083e-8) then the data can not be
recovered. Therefore, great care needs to be taken in the receiver to ensure code
alignment and synchronisation is maintained.
NOT BE UPDATED
Issue 4 Revision 0 Modulo-2 Addition
Modulo-2 Addition
Data
+1
0
–1 1
Spreading Code
+1
–1
Spread Signal
+1
–1
Data X Spreading Code SF = 8
CP13_Ch6_17

NOT BE UPDATED
Orthogonal Codes Issue 4 Revision 0
Orthogonal Codes
Codes are orthogonal if the sum of those codes are zero.
NOT BE UPDATED
Issue 4 Revision 0 Orthogonal Codes
Orthogonal Codes
Channelisation codes known as ”OVSF codes are

used to distinguish individual connection data
The ”OVSF codes” limit the number of users per carrier
OVSF codes are orthogonal codes
Summed product = 0
CP13_Ch6_18

NOT BE UPDATED
Channelisation Code Tree Issue 4 Revision 0
Channelisation Code Tree

For separating channels from the same source, channelisation codes called Orthogonal
Variable Spreading Factors are used.
The lines in the diagram represent codes, these are Orthogonal Variable Spreading
Factor (OVSF) codes, allowing to mix in the same timeslot channels with different
spreading factors while preserving the orthogonality. The OVSF codes can be defined
using the code tree shown above.
Each level in the code tree defines a spreading factors indicated by the value of Q in the
figure. All codes within the code tree cannot be used simultaneously in a given timeslot.
A code can be used in a timeslot if and only if no other code on the path from the specific
code to the root of the tree or in the sub-tree below the specific code is used in this
timeslot. This means that the number of available codes in a slot is not fixed but depends
on the rate and spreading factor of each physical channel.
OVSF Orthogonal Variable Spreading Factor
The spreading codes can be used to identify individual channels, but a mobile usually
has to identify the base station that it is currently parented on. A long code (PN) is
usually used for that and then short codes are used to identify the individual control and
traffic channels.
The Walsh Hadamard set is normally used in IS95. These can be built up by repeating
the sequence.
BB
Bb
Where B represents a bit and b represents its inverse e.g.
SF = 2 SF = 4 SF = 8
CC 11 1111 11111111
CC 10 1010 10101010
CC 1100 11001100
CC 1001 10011001
CC 11110000
CC 11000011
CC 10010110
In UMTS, OVSF codes are used.

OVSF–Orthogonal Variable Spreading Factor
NOT BE UPDATED
Issue 4 Revision 0 Channelisation Code Tree
Channelisation Code Tree
Cch, 8, 0
Cch, 4, 0 (1, 1, 1, 1, 1, 1, 1, 1)
(1, 1, 1, 1) Cch, 8, 1
Cch, 2, 0
(1, – 1, 1, –1, 1, –1, 1, –1)
(1, 1) Cch, 8, 2
Cch, 4, 1 (1, 1, –1, –1, 1, 1, –1, –1)
(1, 1, –1, –1) Cch, 8, 3
Cch, 1, 0
(1, –1, –1, 1, 1, –1, –1, 1)
(1) Cch, 8, 4
Cch, 4, 2 (1, 1, 1, 1, –1, –, –1, –1)
Cch, 8, 5
(1, –1, 1, –1)
Cch, 2, 1 (1, –1, 1, –1, –1, 1, –1, 1)
(1, –1) Cch, 8, 6

Cch, 4, 3 (1, 1, –1, –1, –1, –1, 1, 1)
(1, –1, –1, 1) Cch, 8, 7

(1, –1, –1, 1, –1, 1, 1, –1)
SF = 1 SF = 2 SF = 4 SF = 8
CP13_Ch6_13

NOT BE UPDATED
Processing Gain Issue 4 Revision 0
Processing Gain
Processing Gain can be defined as the Chip Rate divided by the bit rate. This gives a
ratio that can be converted to decibels by using the following formula.
PG = 10 x log SF
The gain that we get from the Processing Gain is an extremely important part of CDMA.
It is in fact because of this relationship that CDMA is so effective and are used even in
space transmissions. Processing gain will determine how much the received signal can
be lifted out of the noise floor. There is one simple rule to follow, the higher the SF the
higher the processing gain will be, the lower the SF the lower the processing gain. As we
know, the SF is also inversely proportional to the speed of the transmission. This means
that the higher the speed of transmission the lower the processing gain will be. Due to
this relationship the power output must be increased of any transmitter if the transmission
rate is increased due to the loss in Processing Gain.
This will also mean that if the Frame Error Rate (FER) is increased on the receiver side
the power must be increased or the transmission rate must drop on the transmitter side
to meet the FER requirement.
NOT BE UPDATED
Issue 4 Revision 0 Processing Gain
Processing Gain
PG = 10 x log (Chip Rate/Bit Rate)
or
PG = 10 x log (SF)
CP13_Ch6_16

NOT BE UPDATED
Exercise 1 - Spreading Issue 4 Revision 0
Exercise 1 - Spreading
This Exercise demonstrates the Modulo-2 Addition, Spreading Factor usage, Code
Lengths and in general will give the student a feel for the Spreading Principle.
The Lecturer should use this exercise as an example.
NOTES
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
NOT BE UPDATED
Issue 4 Revision 0 Exercise 1 - Spreading
Spreading
Data 1
–1
Spreading Code 1
–1
Spread Data 1
–1
De–spreading
Spreading Code 1
–1
De–spread Data 1
–1
Calculation Box
SF = 4 S/N = 5dB
PG = 4 (ratio) C/I = 5 dB – 6 dB
PG = 6 dB = –1 dB
CP13_Ch6_22

NOT BE UPDATED
To gain some experience in Spreading the student can complete the following exercise.
The student can complete the despreading part of the exercise and then calculate the SF
and PG. See if it matches with the answers provided.
Note the irregular structure in the answer.
NOTES
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
NOT BE UPDATED
Spreading
Data 1
–1
Spreading Code 1
–1
Spread Data 1
–1
De–spreading
Spreading Code 1
–1
De–spread Data 1
–1
Wrong 1
Spreading Code –1
De–spread Data 1
Wrong Code –1
Calculation Box
SF = 4 S/N = 5dB
PG = 4 (ratio) C/I = 5 dB – 6 dB
PG = 6 dB = –1 dB
CP13_Ch6_23

NOT BE UPDATED
In this exercise the student must complete the following:
1. Determine the SF used?
2. Do the spreading part of the exercise?
3. Do the despreading part of the exercise using the right code?
4. Do the despreading part of the exercise using the wrong code?
5. Complete the calculation?
NOTES
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
NOT BE UPDATED
Spreading
Data 1
–1
Spreading Code 1
–1
Spread Data 1
–1
De–spreading
Spreading Code 1
–1
De–spread Data 1
–1
Wrong 1
Spreading Code –1
De–spread Data 1
Wrong Code –1
Calculation Box
SF = S/N = 5db
PG = C/I =
PG = = –1 dB
P13_Ch6_24

NOT BE UPDATED
Short Codes vs Long Codes Issue 4 Revision 0
Short Codes vs Long Codes

Short codes and Long codes are both used in the UMTS system. The main advantage of
Short Codes is that they have good Auto Correlation properties. This means that they are
very easy to synchronise to.
The main advantage of long codes is that they have excellent cross correlation
properties. This means that they are very resistant to interference from other codes in the
network.
NOT BE UPDATED
Issue 4 Revision 0 Short Codes vs Long Codes
Short Codes vs Long Codes
Short codes
Code sequence length = Bit

Code sequence repeated for each new data bit
Good auto correlation properties
Bad cross correlation properties
Long codes
Code sequence length >> Bit
Code sequence not repeated for each new data bit
Bad auto correlation properties (long repetition cycle)
Good cross correlation properties
Planning easy
CP13_Ch6_21

NOT BE UPDATED
Matched Filter Operation Issue 4 Revision 0
Matched Filter Operation

The main task of the matched filter is to determine the timing reference of the information
as they arrive at the receiver.
NOT BE UPDATED
Issue 4 Revision 0 Matched Filter Operation
Matched Filter Operation
RF
Front End Matched Slot Wise Find
Circuitry Filter Accumulation Maximized
CP13_Ch6_27

NOT BE UPDATED
The Rake Receiver Issue 4 Revision 0
The Rake Receiver

The rake receiver performs a similar (but not identical) function to the equaliser in GSM.
Instead of training bits, the pilot signals (all zeros) are used as a basis for the search for
the best path. The rake receiver then constructs its fingers to track the other multi-path
rays by stepping through delays one chip at a time until it finds another, lower level pilot.
It can then use the weightings to bring the rays into phase and constructive addition.
Note that the different rays are uncorrelated if the delay difference is greater than one
chip.
The effect of the propagation environment on spread spectrum modulated signals is to
produce a series of signal components that have traversed differing paths. This is known
as multipath interference and, depending on whether or not there is a significant specula
multipath component, the envelope of the multipath signal may be Rician or Rayleigh
distributed.
Multipath results in two signal perturbations, known as Inter-Symbol Interference (ISI)
and fading. Both introduce severe degradation in the system performance. ISI creates
signal components that are delayed into the next signal period, making these signals
overlap and therefore interfere with one another. Fading is caused by signals of opposite
phase cancelling in the receiver. To combat this, a Rake receiver may be used. This is
the type of receiver shown in the figure and contains many signal paths, each with an
individual delay. These delays are changed so as the total delay from the transmitter for
all paths is the same and thus when combined they are in-phase.
NOT BE UPDATED
Issue 4 Revision 0 The Rake Receiver
The Rake Receiver
I I
RF Front– Correlator Phase Delay I I
End Circuitry Q Despreading Q Rotator Equalizer
Q Q
CC Maximum ratio
+ combining
SC
Code Channel
Generator Estimator
Use pilots bits
ASICs
Matched
Filter DSP
CP13_Ch6_28

NOT BE UPDATED
The Rake Receiver Issue 4 Revision 0
NOT BE UPDATED
Chapter 7
The Physical Layer

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 7
The Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
Physical Layer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
QPSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Channel Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
Structure of Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Downlink Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Uplink Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Channels on the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Common Physical Channels (CPCHs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Channel Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
Physical signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
Generic Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Radio Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
System Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Timeslot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Synchronisation Channel (SCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
The Primary SCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
The Secondary SCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Modulation Symbol “a” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Synchronisation (Cell Search) Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Step 1: Slot synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Step 2: Frame synchronisation and code–group identification . . . . . . . . . . . . . . . 7–24
Step 3: Scrambling–code identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–25
Common Pilot Channel (CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Primary Common Pilot Channel (P-CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Secondary Common Pilot Channel (S-CPICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Modulation pattern for Common Pilot Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–27
P-CCPCH Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–28
SCH and P-CCPCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–30
Paging Indicator Channel (PICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–32
Mapping of Paging Indicators (PI) to PICH bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–33
Secondary Common Control Physical Channel (S–CCPCH) . . . . . . . . . . . . . . . . . . . . . . 7–34
Secondary CCPCH Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–35
Random Access Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
Structure of Random Access Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
PRACH Pre–amble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–36
Structure of the random–access transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–37

NOT BE UPDATED
Issue 4 Revision 0
Acquisition Indicator Channel AICH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–38

AICH signature patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–39
Structure of PRACH Message Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–40
Random–access message data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–41
Dedicated downlink physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–42
Downlink Slot Formation in Case of Multi-Code Transmission . . . . . . . . . . . . . . . . . . . . . 7–44
Uplink Dedicated Physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–46
Downlink Flow Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–48
Channel Coding Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–50
CRC Attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–50
Transport block concatenation and code block segmentation . . . . . . . . . . . . . . . . 7–50
Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–52
Convolutional Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–52
Rate 1/2 and rate 1/3 convolutional coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–53
Turbo coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–54
Rate Matching & Insertion of DTX Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Rate Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Insertion of DTX Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–56
Fixed And Flexible Bit Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–57
1ST Interleaving and Radio Frame Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–58
Transport Channel Multiplexing and Physical Layer Segmentation . . . . . . . . . . . . . . . . . 7–60
2nd insertion of DTX Indication bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
Physical Layer Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
2nd Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–60
Downlink Spreading and Channel Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–62
Uplink Flow Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Radio Frame Equalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Rate Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–64
Uplink Spreading and Channel Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–66
PRACH Message Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–66
PRACH Spreading and Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–67
NOT BE UPDATED
Objectives
Describe the procedures performed by the Air Interface Physical Layer
Describe the UMTS Channel Structure.
- Logical Channels
- Transport Channels
- Physical Channels
Describe the Downlink and Uplink Flow Processes.

NOT BE UPDATED
Physical Layer Services Issue 4 Revision 0
Physical Layer Services

The Physical Layer (L1) will be the main discussion in this section since this is where
most of the air interface tasks are performed.
The physical layer offers data transport services to higher layers. The access to these
services is through the use of transport channels via the MAC sub–layer. The physical
layer is expected to perform the following functions in order to provide the data transport
service.
Macrodiversity distribution, combining and soft handover execution.
Error detection on transport channels and indication to higher layers.
FEC encoding/decoding of transport channels.
Multiplexing of transport channels and demultiplexing of coded composite transport
channels (CCTrCHs).
Rate matching of coded transport channels to physical channels.
Mapping of coded composite transport channels on physical channels.
Power weighting and combining of physical channels.
Modulation and spreading/demodulation and despreading of physical channels.
Frequency and time (chip, bit, slot, frame) synchronisation.
Radio characteristics measurements including FER, SIR, Interference Power, etc.,
and indication to higher layers.
Inner – loop power control.
RF processing.
When network elements (UEs and network) provide compatible service bearers (for
example support a speech bearer) they should be assured of successful interworking.
Moreover, different implementation options of the same (optional) feature would lead to
incompatibility between UE and network. Therefore, this shall be avoided.
NOT BE UPDATED
Issue 4 Revision 0 Physical Layer Services
Physical Layer Services
Macrodiversity distribution, combning and soft handover execution.

Error detection on transport channels.
FEC encoding & decoding of transport channels.
Mux & Demux of transport channels and CCTrCHs.
Rate matching of coded transport channels to physical channels.
Mapping of coded composite transport channels on physical channels.
Power weighting and combining of physical channels.
Modulation demodulation and spreading of physical channels.
Frequency and time synchronisation.
Radio characteristics measurements.
Inner – loop power control.
RF processing.
CP13_Ch7_02

NOT BE UPDATED
QPSK Issue 4 Revision 0
QPSK
The modulation scheme used in W-CDMA is quadrature phase shift keying (PSK) which
allows 2 bits to be sent per symbol (I and Q). The reason for using QPSK is that it is
fairly resilient to amplitude variations. The major problem with CDMA is that all users are
on the same frequency and thus interfering with each other.
NOT BE UPDATED
Issue 4 Revision 0 QPSK
QPSK
QPSK
Q
(0,1) (0,0)
(1,1) (1,0)
2 bits per symbol

CP13_Ch6_09

NOT BE UPDATED
Channel Locations Issue 4 Revision 0
Channel Locations
The Radio Interface is the section of the network between the UE and the Network. This
section of the network is where the biggest limitation lies at the moment, it is the most
vulnerable section and therefore very complex methods have to be invented in order to
transmit the required data at the high speeds that is demanded of today’s networks. The
radio interface is composed of Layers 1, 2 and 3.
The slide opposite shows the UTRA radio interface protocol architecture around the
physical layer (Layer 1). The physical layer interfaces with the Medium Access Control
(MAC) sub–layer of Layer 2 and the Radio Resource Control (RRC) Layer of Layer 3.
The physical layer offers different Transport channels to MAC. A transport channel is
characterized by how the information is transferred over the radio interface.
MAC offers different Logical channels to the Radio Link Control (RLC) sub–layer of Layer
2. The type of information transferred characterizes a logical channel.
Physical channels are defined in the physical layer. In FDD mode, physical channels are
defined by a specific carrier frequency, scrambling code, channelization code (optional),
time start and stop (giving duration) and, on the uplink, relative phase (0 or π/2). In the
TDD mode the physical channels is also characterized by the timeslot. The physical layer
is controlled by RRC.
NOT BE UPDATED
Issue 4 Revision 0 Channel Locations
Channel Locations
Logical Channels
Layer 2 MAC
Transport Channels
Layer 1 Physical Layer
Physical Channels
UE
CP13_Ch7_08

NOT BE UPDATED
Structure of Transmission Issue 4 Revision 0
Structure of Transmission
The physical layer receives information, on a transport channel, as Transport Blocks (or
Transport Block sets) from Layer 2. This information will consist of User Plane or Control
Plane streams. In addition the physical layer will generate Layer 1 control information,
used to maintain the radio bearer between the UE and the UTRAN. This layer 1control
information must be transmitted on the physical channel along with the transport channel
information.
As previously discussed, even when FDD mode is in use, a Radio Frame/Time Slot
structure is observed. (A 10 mS radio frame is divided into 15 timeslots). Though it is
important to note that any given radio bearer is able to use all timeslots in every radio
frame.
Downlink
Transmission
On the downlink each timeslot will contain transport channel information and Layer 1
control information in time–multiplex. Each timeslot will contain fields supporting
transport block information, interspersed with Layer 1 control fields. The exact structure
of the fields is dependent upon the type of physical channel in use, and is described in
detail later in this section.
Uplink
Transmission
On the Uplink a time–multiplex structure is not practical as Discontinuous Transmission
(DTX) is frequently employed. The combination of DTX and Time–multiplex would result
in a “Bursty” transmission, which would generate audio band noise perceptible to the
other party in a voice call.
To overcome this problem, the transport channel information and Layer 1 control
information are I/Q code multiplexed within each timeslot, allowing them to be transmitted
in parallel. This make the transmission of Layer 1 control information continuous and
hence prevents bursty transmission, even when DTX is applied.
NOT BE UPDATED
Issue 4 Revision 0 Structure of Transmission
Structure of Transmission
CP13_Ch7_07

NOT BE UPDATED
Channels on the Air Interface Issue 4 Revision 0
Channels on the Air Interface

The slide opposite shows the most common channels used on the air interface. The
channels are divided horizontally into the Physical Channels (PCHs), the Transport
Channels (TCHs) and the Logical Channels (LCHs). Vertically they are divided into 2
channel types, the Dedicated Channels and the Common channels. Dedicated Channels
are dedicated to one UE only and Common Channels can be shared by multiple UEs.
NOT BE UPDATED
Issue 4 Revision 0 Channels on the Air Interface
Channels on the Air Interface
DCCH DTCH BCCH PCCH CCCH CTCH Logical

Channels
PTM
CCH
DCH
Transport
BCH PCH FACH USCH RACH CPCH Channels
DSCH
PDCH PCCH
P–CCPCH S–CCPCH PICH PRACH SCH CPICH AICH PCPCH PDSCH

Physical
DPDCH DPCCH Channels
* *
P–SCH S–SCH Primary Secondary
CP13_Ch7_09

NOT BE UPDATED
Logical Channels Issue 4 Revision 0
Logical Channels
The MAC layer provides data transfer services on logical channels. A set of logical
channel types is defined for different kinds of data transfer services as offered by MAC.
Each logical channel type is defined by what type of information is transferred.
A general classification of logical channels is into two groups:
Control Channels (for the transfer of control plane information).
Traffic Channels (for the transfer of user plane information).
Control
Channels
Broadcast Control Channel (BCCH)

A downlink channel for broadcasting system control information.
Paging Control Channel (PCCH)

A downlink channel that transfers paging information. This channel is used when the
network does not know the location cell of the UE, or, the UE is in the cell connected
state (utilising UE sleep mode procedures).
Common Control Channel (CCCH)

Bi–directional channel for transmitting control information between network and UEs.
This channel is commonly used by the UEs having no RRC connection with the network
and by the UEs using common transport channels when accessing a new cell after cell
reselection.
Dedicated Control Channel (DCCH)

A point–to–point bi–directional channel that transmits dedicated control information
between a UE and the network. This channel is established through RRC connection
setup procedure.
Traffic Channels
Dedicated Traffic Channel (DTCH)

A Dedicated Traffic Channel (DTCH) is a point–to–point channel, dedicated to one UE,
for the transfer of user information. A DTCH can exist in both uplink and downlink.
Common Traffic Channel (CTCH)

A point–to–multipoint unidirectional channel for transfer of dedicated user information for
all or a group of specified UEs.
NOT BE UPDATED
Issue 4 Revision 0 Logical Channels
Logical Channels
Between MAC and Higher Applications
DCCH DTCH BCCH PCCH CCCH CTCH
U–RNTI PTM
CP13_Ch7_10

NOT BE UPDATED
Transport Channels Issue 4 Revision 0
Transport Channels
The physical layer offers information transfer services to MAC and higher layers. The
physical layer transport services are described by how and with what characteristics data
is transferred over the radio interface. An adequate term for this is ’Transport Channel’. A
general classification of transport channels is into two groups:
Common transport channels (where there is a need for inband identification of the
UEs when particular UEs are addressed.
Dedicated transport channels (where the UEs are identified by the physical
channel, i.e. code and frequency for FDD and code, time slot and frequency for
TDD).
Random Access Channel (RACH)

A contention based uplink channel used for transmission of relatively small amounts of
data, e.g. for initial access or non–real–time dedicated control or traffic data.
Common Packet Channel (CPCH)

A contention based channel used for transmission of bursty data traffic. This channel
only exists in FDD mode and only in the uplink direction. The common packet channel is
shared by the UEs in a cell and therefore, it is a common resource. The CPCH is fast
power controlled.
Forward Access Channel (FACH)

Common downlink channel without closed–loop power control used for transmission of
relatively small amount of data.
Downlink Shared Channel (DSCH)

A downlink channel shared by several UEs carrying dedicated control or traffic data.
Uplink Shared Channel (USCH)

An uplink channel shared by several UEs carrying dedicated control or traffic data, used
in TDD mode only.
Broadcast Channel (BCH)

A downlink channel used for broadcast of system information into an entire cell.
Paging Channel (PCH)

A downlink channel used for broadcast of control information into an entire cell allowing
efficient UE sleep mode procedures. Currently identified information types are paging and
notification. Another use could be UTRAN notification of change of BCCH information.
Dedicated Channel (DCH)

A channel dedicated to one UE used in uplink or downlink.
NOT BE UPDATED
Issue 4 Revision 0 Transport Channels
Transport Channels
Between the Physical Layer and MAC
CCH
DCH
BCH PCH FACH RACH CPCH
USCH
DSCH
CP13_Ch7_11

NOT BE UPDATED
Physical Channels Issue 4 Revision 0
Physical Channels
Common
Physical
Channels
(CPCHs)
P-SCH Primary Synchronisation Channel
S-SCH Secondary Synchronisation Channel
Synchronisation to the network
P-CCPCH Primary Common Control Physical Channel
Cell Information
Frequency info
S-CCPCH Secondary Common Control Physical Channel
Paging Information and Transfer of small amounts of user data.
Downlink only.
PRACH Physical Random Access Channel
Initial message when UE wants to gain access to the network
Transfer of small amounts of data
Uplink only
PCPCH Physical Common Packet Channel
Extension of the PRACH Channel that is intended to carry
packer-based user data in the uplink direction.
PICH Paging Indicator Channel
Provides UEs with efficient sleep mode operation
AICH Acquisition Indicator Channel
Acknowledges an effective request for access after preamble has
been send up
Carry information associated with the DCHs
P-CPICH Primary Common Pilot Indicator Channel
S-CPICH Secondary Pilot Indicator Channel
Helps with channel estimation and shows the attractiveness of the
cell
DPDCH Dedicated Physical Channels
DPCCH
Uplink and downlink control and data information
Dedicated to a single user
NOT BE UPDATED
Issue 4 Revision 0 Physical Channels
Physical Channels
Between the Physical Layer and the UE
PDCH PCCH
P–CCPCH S–CCPCH PICH PRACH SCH CPICH AICH PCPCH PDSCH
DPDCH DPCCH
P–SCH S–SCH Primary Secondary
CP13_Ch7_13

NOT BE UPDATED
Channel Mapping Issue 4 Revision 0
Channel Mapping
The diagram opposite summarises the mapping of logical channels onto transport
channels, and transport channels onto physical channels.
The DCHs are coded and multiplexed, as described later in this chapter, and the resulting
data stream is mapped sequentially (first–in–first–mapped) directly to the physical
channel(s).
The mapping of BCH and FACH/PCH is equally straightforward, where the data stream
after coding and interleaving is mapped sequentially to the Primary and Secondary
CCPCH respectively. Note that the BCCH logical channel can be mapped to both BCH
and FACH, so as to be available to idle mode and connected mode UEs respectively.
Also for the RACH, the coded and interleaved bits are sequentially mapped to the
physical channel, in this case the message part of the PRACH.
Physical signals
Physical signals are entities with the same basic on–air attributes as physical channels
but do not have transport channels or indicators mapped to them. Physical signals may
be associated with physical channels in order to support the function of physical
channels. SCH, CPICH, and AICH are classified as physical signals and hence are not
shown on the map opposite.
NOT BE UPDATED
Issue 4 Revision 0 Channel Mapping
Channel Mapping
Uplink Downlink
DCCH DCCH
CCCH PCCH BCCH CCCH CTCH
DTCH DTCH
Common Common
Paging Dedicated
Broadcast Control Traffic
Control Control Channel
Contro Channel Channel
Channel Dedicated
Channel
Traffic Channel
RACH CPCH DCH PCH BCH FACH DSCH DCH
Download
Shared
Channel
Primary
CCPCH
DPDCH
PDSCH
DPCCH
PPDCH
PRACH PCPCH
DPCCH Physical
Sec Download
CCPCH Channel
CP13_Ch7_14

NOT BE UPDATED
Generic Frame Structure Issue 4 Revision 0
Generic Frame Structure

The diagram opposite illustrates the genmeric frame structure, use to delimit the transfer
of units of information on the UMTS air interface.
Radio Frame
As previously outlined the basic unit of the air interface is the radio frame. A radio frame
is defined as “A processing duration which consists of 15 timeslots. The length of a
radio frame corresponds to 38,400 chips.” With a system chip rate of 3.84 McpS being
employe, a radio frame thus has a duration of 10 mS.
System Frame
Several physical layer procedures (e.g. Paging and random access) span more than a
single frame, being the. To accommodate these procedures, a sytem frame is defined.
A system frame consists of 72 radio frames and hence has a duration of 720 mS. The
frame within the system frame structure is identified by a System Frame Number (SFN).
Timeslot
Each radio frame consists of 15 timeslots. “A slot duration consists of fields containing
bits. The length of the slot always corresponds to 2560 chips.” The time duration of a
timeslot is approximately 666 uS. The number of fields within each timeslot is dependent
upon the physical channel in use. Similarly the number of bits which can be
accommodate by a timeslot is dependent upon the spreading factor in use for that
physical channel.
NOT BE UPDATED
Issue 4 Revision 0 Generic Frame Structure
Generic Frame Structure
SLOT
Tslot = 2560 chips
FRAME
TS0 TS1 TSn TS13 TS14
666µs
SYSTEM FRAME
Frame Frame Frame Frame
1 n 71 72
10ms
720 ms
CP13_Ch7_29

NOT BE UPDATED
Synchronisation Channel (SCH) Issue 4 Revision 0
Synchronisation Channel (SCH)

The Synchronisation Channel (SCH) is a downlink signal used for cell search. The SCH
consists of two sub channels, the Primary and Secondary SCH. The 10 ms radio frames
of the Primary and Secondary SCH are divided into 15 slots, each of length 2560 chips.
The diagram opposite illustrates the structure of the SCH radio frame.
The Primary SCH

The Primary SCH consists of a modulated code of length 256 chips, the Primary
Synchronisation Code (PSC) denoted cp in the diagram, transmitted once every slot. The
PSC is the same for every cell in the system.
The Secondary
SCH
The Secondary SCH consists of repeatedly transmitting a length 15 sequence of
modulated codes of length 256 chips, the Secondary Synchronisation Codes (SSC),
transmitted in parallel with the Primary SCH. The SSC is denoted csi,k in the diagram,
where i = 0, 1, …, 63 is the number of the scrambling code group, and k = 0, 1, …, 14 is
the slot number. Each SSC is chosen from a set of 16 different codes of length 256. This
sequence on the Secondary SCH indicates which of the code groups the cell’s downlink
scrambling code belongs to.
Modulation
Symbol “a”
The primary and secondary synchronization codes are modulated by the symbol a shown
in the diagram, which indicates the presence/ absence of STTD encoding on the
P–CCPCH and is given by the following table:
P–CCPCH STTD encoded a = +1

P–CCPCH not STTD encoded a = –1
NOT BE UPDATED
Issue 4 Revision 0 Synchronisation Channel (SCH)
Synchronisation
Tslot = 2560 chips
256 chips
Primary
SCH acp acp acp acp acp
Secondary
SCH acsi,0 acsi,1 acsi,2 acsi,3 acsi,4
One 10ms SCH radio frame
CP13_Ch7_21

NOT BE UPDATED
Synchronisation (Cell Search) Procedure Issue 4 Revision 0
Synchronisation (Cell Search) Procedure

During the cell search, the UE searches for a cell and determines the downlink
scrambling code and frame synchronisation of that cell. The cell search is typically
carried out in three steps:
Step 1: Slot
synchronisation
During the first step of the cell search procedure the UE uses the SCH’s primary
synchronisation code to acquire slot synchronisation to a cell. This is typically done with a
single matched filter (or any similar device) matched 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
synchronisation
and code–group
identification
During the second step of the cell search procedure, the UE uses the SCH’s secondary
synchronisation code to find frame synchronisation and identify the code group of the cell
found in the first step. 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.
Step 3:
Scrambling–code
identification
During the third and last step of the cell search procedure, the UE determines the exact
primary scrambling code used by the found cell. The primary scrambling code is typically
identified through symbol–by–symbol correlation over the CPICH with all codes within the
code group identified in the second step. After the primary scrambling code has been
identified, the Primary CCPCH can be detected.And the system– and cell specific BCH
information can be read.
If the UE has received information about which scrambling codes to search for, steps 2
and 3 above can be simplified.
NOT BE UPDATED
Issue 4 Revision 0 Synchronisation
Synchronisation
Scrambling slot number
Code Group #0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14
Group 0 1 1 2 8 9 10 15 8 10 16 2 7 15 7 16
Group 1 1 1 5 16 7 3 14 16 3 10 5 12 14 12 10
Group 2 1 2 1 15 5 5 12 16 6 11 2 16 11 15 12
Group 3 1 2 3 1 8 6 5 2 5 8 4 4 6 3 7
Group 4 1 2 16 6 6 11 15 5 12 1 15 12 16 11 2
Group 5 1 3 4 7 4 1 5 5 3 6 2 8 7 6 8
Group 6 1 4 11 3 4 10 9 2 11 2 10 12 12 9 3
Group 7 1 5 6 6 14 9 10 2 13 9 2 5 14 1 13
Group 8 1 6 10 10 4 11 7 13 16 11 13 6 4 1 16
Group 9 1 6 13 2 14 2 6 5 5 13 10 9 1 14 10
Group 10 1 7 8 5 7 2 4 3 8 3 2 6 6 4 5
Group 11 1 7 10 9 16 7 9 15 1 8 16 8 15 2 2
Group 12 1 8 12 9 9 4 13 16 5 1 13 5 12 4 8
Group 13 1 8 14 10 14 1 15 15 8 5 11 4 10 5 4
Group 14 1 9 2 15 15 16 10 7 8 1 10 8 2 16 9
Group 15 1 9 15 6 16 2 13 14 10 11 7 4 5 12 3
Group 16 1 10 9 11 15 7 6 4 16 5 2 12 13 3 14
Group 17 1 11 14 4 13 2 9 10 12 16 8 5 3 15 6
Group 18 1 12 12 13 14 7 2 8 14 2 1 13 11 8 11
Group 19 1 12 15 5 4 14 3 16 7 8 6 2 10 11 13
Group 20 1 15 4 3 7 6 10 13 12 5 14 16 8 2 11
Group 21 1 16 3 12 11 9 13 5 8 2 14 7 4 10 15
Group 22 2 2 5 10 16 11 3 10 11 8 5 13 3 13 8
Group 23 2 2 12 3 15 5 8 3 5 14 12 9 8 9 14
Group 24 2 3 6 16 12 16 3 13 13 6 7 9 2 12 7
Group 25 2 3 8 2 9 15 14 3 14 9 5 5 15 8 12
Group 26 2 4 7 9 5 4 9 11 2 14 5 14 11 16 16
Group 27 2 4 13 12 12 7 15 10 5 2 15 5 13 7 4
Group 28 2 5 9 9 3 12 8 14 15 12 14 5 3 2 15
Group 29 2 5 11 7 2 11 9 4 16 7 16 9 14 14 4
Group 30 2 6 2 13 3 3 12 9 7 16 6 9 16 13 12
Group 31 2 6 9 7 7 16 13 3 12 2 13 12 9 16 6
Group 32 2 7 12 15 2 12 4 10 13 15 13 4 5 5 10
Group 33 2 7 14 16 5 9 2 9 16 11 11 5 7 4 14
Group 34 2 8 5 12 5 2 14 14 8 15 3 9 12 15 9
Group 35 2 9 13 4 2 13 8 11 6 4 6 8 15 15 11
Group 36 2 10 3 2 13 16 8 10 8 13 11 11 16 3 5
Group 37 2 11 15 3 11 6 14 10 15 10 6 7 7 14 3
Group 38 2 16 4 5 16 14 7 11 4 11 14 9 9 7 5
Group 39 3 3 4 6 11 12 13 6 12 14 4 5 13 5 14
Group 40 3 3 6 5 16 9 15 5 9 10 6 4 15 4 10
Group 41 3 4 5 14 4 6 12 13 5 13 6 11 11 12 14
Group 42 3 4 9 16 10 4 16 15 3 5 10 5 15 6 6
Group 43 3 4 16 10 5 10 4 9 9 16 15 6 3 5 15
Group 44 3 5 12 11 14 5 11 13 3 6 14 6 13 4 4
Group 45 3 6 4 10 6 5 9 15 4 15 5 16 16 9 10
Group 46 3 7 8 8 16 11 12 4 15 11 4 7 16 3 15
Group 47 3 7 16 11 4 15 3 15 11 12 12 4 7 8 16
Group 48 3 8 7 15 4 8 15 12 3 16 4 16 12 11 11
Group 49 3 8 15 4 16 4 8 7 7 15 12 11 3 16 12
Group 50 3 10 10 15 16 5 4 6 16 4 3 15 9 6 9
Group 51 3 13 11 5 4 12 4 11 6 6 5 3 14 13 12
Group 52 3 14 7 9 14 10 13 8 7 8 10 4 4 13 9
Group 53 5 5 8 14 16 13 6 14 13 7 8 15 6 15 7
Group 54 5 6 11 7 10 8 5 8 7 12 12 10 6 9 11
Group 55 5 6 13 8 13 5 7 7 6 16 14 15 8 16 15
Group 56 5 7 9 10 7 11 6 12 9 12 11 8 8 6 10
Group 57 5 9 6 8 10 9 8 12 5 11 10 11 12 7 7
Group 58 5 10 10 12 8 11 9 7 8 9 5 12 6 7 6
Group 59 5 10 12 6 5 12 8 9 7 6 7 8 11 11 9
Group 60 5 13 15 15 14 8 6 7 16 8 7 13 14 5 16
Group 61 9 10 13 10 11 15 15 9 16 12 14 13 16 14 11
Group 62 9 11 12 15 12 9 13 13 11 14 10 16 15 14 16
Group 63 9 12 10 15 13 14 9 14 15 11 11 13 12 16 10

NOT BE UPDATED
Common Pilot Channel (CPICH) Issue 4 Revision 0
Common Pilot Channel (CPICH)

The CPICH is a fixed rate (30 kbps, SF=256) downlink physical channel that carries a
pre–defined bit/symbol sequence. The diagram opposite shows the frame structure of the
CPICH.
In case transmit diversity (open or closed loop) is used on any downlink channel in the
cell, the CPICH shall be transmitted from both antennas using the same channelization
and scrambling code. In this case, the pre–defined symbol sequence of the CPICH is
different for Antenna 1 and Antenna 2, see figure 14. In case of no transmit diversity, the
symbol sequence of Antenna 1 in figure 14 is used.
There are two types of Common pilot channels, the Primary and Secondary CPICH.
They differ in their use and the limitations placed on their physical features.
Primary
Common Pilot
Channel
(P-CPICH)
The Primary Common Pilot Channel (P–CPICH) has the following characteristics:
The same channelization code is always used for the P–CPICH (SF=256,0).
The P–CPICH is scrambled by the primary scrambling code.
There is one and only one P–CPICH per cell.
The P–CPICH is broadcast over the entire cell.
The Primary CPICH is the phase reference for the following downlink channels: SCH,
Primary CCPCH, AICH, PICH. The Primary CPICH is also the default phase reference
for all other downlink physical channels.
Secondary
Common Pilot
Channel
(S-CPICH)
A Secondary Common Pilot Channel (S–CPICH) has the following characteristics:
An arbitrary channelization code of SF=256 is used for the S–CPICH.
A S–CPICH is scrambled by either the primary or a secondary scrambling code.
There may be zero, one, or several S–CPICH per cell.
A S–CPICH may be transmitted over the entire cell or only over a part of the cell.
A Secondary CPICH may be the reference for the Secondary CCPCH and the downlink
DPCH. If this is the case, the UE is informed about this by higher–layer signalling.
NOT BE UPDATED
Issue 4 Revision 0 Common Pilot Channel (CPICH)
CPICH Frame Structure
Pre–defined symbol sequence
Tslot = 2560 chips, 20 bits = 10 symbols
Slot #0 Slot #1 Slot #i Slot #14
1 radio frame: Tf = 10ms
CP13_Ch7_25
Modulation
pattern for
Common Pilot
Channel
Antenna 1 A A A A A A A A A A A A A A A A A A A A A A A A
Antenna 2 –A–A A A –A–A A A –A A –A–A A A –A–A A A –A–A A A –A–A
slot #14 slot #0 slot #1
Frame#i Frame#i+1
Frame Boundary
CP13_Ch7_25a

NOT BE UPDATED
P-CCPCH Frame Structure Issue 4 Revision 0
P-CCPCH Frame Structure

The Primary CCPCH is a fixed rate (30 kbps, SF=256) downlink physical channels used
to carry the BCH.
The frame structure of the Primary CCPCH is illustrated opposite.
The frame structure differs from the downlink DPCH in that no TPC commands, no TFCI
and no pilot bits are transmitted The Primary CCPCH is not transmitted during the first
256 chips of each slot. Instead, Primary SCH and Secondary SCH are transmitted during
this period.
NOT BE UPDATED
Issue 4 Revision 0 P-CCPCH Frame Structure
P-CCPCH Frame Structure
256 chips
Data
(Tx OFF)
18 bits
Tslot = 2560 chips, 20 bits
Tf = 10ms
Frame #0 Frame #1 Frame #i Frame #71
Tsuper = 720 ms
CP13_Ch7_19

NOT BE UPDATED
SCH and P-CCPCH Issue 4 Revision 0
SCH and P-CCPCH

The diagram opposite shows the construction of the SCH and the P–CCPCH. It is thus
clear that different channels can be multiplexed onto one link. The structure of these 2
Physical Channels are very important to the synchronization process.
NOT BE UPDATED
Issue 4 Revision 0 SCH and P-CCPCH
SCH and P-CCPCH
SCH
Frame 0 Frame 1 Frame 2

Data on P–CCPCH Data on P–CCPCH Data on P–CCPCH
CP13_Ch7_20

NOT BE UPDATED
Paging Indicator Channel (PICH) Issue 4 Revision 0
Paging Indicator Channel (PICH)

The Paging Indicator Channel (PICH) is a fixed rate (SF=256) physical channel used to
carry the Paging Indicators (PI). The PICH is always associated with an S–CCPCH to
which a PCH transport channel is mapped.
The diagram illustrates the frame structure of the PICH. One PICH radio frame of length
10 ms consists of 300 bits (b0, b1, …, b299). Of these, 288 bits (b0, b1, …, b287) are used
to carry Paging Indicators. The remaining 12 bits are not formally part of the PICH and
shall not be transmitted. The part of the frame with no transmission is reserved for
possible future use.
N Paging Indicators {PI0, …, PIN–1} are transmitted in each PICH frame, where N=18,
36, 72, or 144.
The PI calculated by higher layers for use for a certain UE, is mapped to the paging
indicator PIp , where p is computed as a function of the PI computed by higher layers, the
SFN of the P–CCPCH radio frame during which the start of the PICH radio frame occurs,
and the number of paging indicators per frame (N):
 
p =  PI + ((18 × (SFN + SFN / 8+ SFN / 64+
 
N 
SFN / 512))mod144)× 144  mod N

The mapping from {PI0, …, PIN–1} to the PICH bits {b0, …, b287} are according to table
22.
If a Paging Indicator in a certain frame is set to ”1” it is an indication that UEs associated
with this Paging Indicator should read the corresponding frame of the associated
S–CCPCH.
NOT BE UPDATED
Issue 4 Revision 0 Paging Indicator Channel (PICH)
Structure of Paging Indicator Channel (PICH)
12 bits
288 bits for paging indication (transmission off)
b0 b1 b287 b288 b299
One radio frame (10 ms)
CP13_Ch7_30
Mapping of
Paging
Indicators (PI) to
PICH bits
Number of PI per frame (N) Plp = 1 Plp = 0

N=18 {b16p, ...,b16p+15} = {–1,–1,...,–1} {b16p, ...,b16p+15} = {+1,+1,...,+1}
N=36 {b8p, ...,b8p+7} = {–1,–1,...,–1} {b8p, ...,b8p+7} = {+1,+1,...,+1}

N=72 {b4p, ...,b4p+3} = {–1,–1,...,–1} {b4p, ...,b4p+3} = {+1,+1,...,+1}
N=144 {b2p,b2p+1} = {–1,–1} {b2p,b2p+1} = {+1,+1}
CP13_Ch7_31

NOT BE UPDATED
Secondary Common Control Physical Channel (S–CCPCH) Issue 4 Revision 0
Secondary Common Control Physical Channel (S–CCPCH)

The Secondary CCPCH is used to carry the FACH and PCH. There are two types of
Secondary CCPCH: those that include TFCI and those that do not include TFCI. It is the
UTRAN that determines if a TFCI should be transmitted, hence making it mandatory for
all UEs to support the use of TFCI. The set of possible rates for the Secondary CCPCH
is the same as for the downlink DPCH. The frame structure of the Secondary CCPCH is
shown opposite.
The parameter k in the diagram determines the total number of bits per downlink
Secondary CCPCH slot. It is related to the spreading factor SF of the physical channel
as SF = 256/2k. The spreading factor range is from 256 down to 4. The values for the
number of bits per field are given in the table opposite. The channel bit and symbol rates
given in the table are the rates immediately before spreading.
The FACH and PCH can be mapped to the same or to separate Secondary CCPCHs. If
FACH and PCH are mapped to the same Secondary CCPCH, they can be mapped to the
same frame.
The main difference between a CCPCH and a downlink dedicated physical channel is
that a CCPCH is not inner–loop power controlled.
The main difference between the Primary and Secondary CCPCH is that the transport
channel mapped to the Primary CCPCH (BCH) can only have a fixed predefined
transport format combination, while the Secondary CCPCH support multiple transport
format combinations using TFCI. Furthermore, a Primary CCPCH is transmitted over the
entire cell while a Secondary CCPCH may be transmitted in a narrow lobe in the same
way as a dedicated physical channel (only valid for a Secondary CCPCH carrying the
FACH).
For slot formats using TFCI, the TFCI value in each radio frame corresponds to a certain
transport format combination of the FACHs and/or PCHs currently in use. This
correspondence is (re–)negotiated at each FACH/PCH addition/removal.
NOT BE UPDATED
Issue 4 Revision 0 Secondary Common Control Physical Channel (S–CCPCH)
S–CCPCH Frame Structure
TFCI Data Pilot

NTFCIbits Ndatabits Npilotbits
Tslot = 2560 chips, 20*2kbits (k = 0..6)
1 radio frame: Tf = 10ms
CP13_Ch7_23
Secondary
CCPCH Fields
Slot Format Channel Bit Channel SF Bits/ Frame Bits/ Ndata Npilot NTFCI
#i Rate (kbps) Symbol Rate Slot
(ksps)
0 30 15 256 300 20 20 0 0
1 30 15 256 300 20 12 8 0
2 30 15 256 300 20 18 0 2
3 30 15 256 300 20 10 8 2
4 60 30 128 600 40 40 0 0
5 60 30 128 600 40 32 8 0
6 60 30 128 600 40 38 0 2
7 60 30 128 600 40 30 8 2
8 120 60 64 1200 80 72 0 8*
9 120 60 64 1200 80 64 8 8*
10 240 120 32 2400 160 152 0 8*
11 240 120 32 2400 160 144 8 8*
12 480 240 16 4800 320 312 0 8*
13 480 240 16 4800 320 296 16 8*
14 960 480 8 9600 640 632 0 8*
15 960 480 8 9600 640 616 16 8*
16 1920 960 4 19200 1280 1272 0 8*
17 1920 960 4 19200 1280 1256 16 8*
* If TFCI bits are not used, then DTX shall be used in TFCI field.

NOT BE UPDATED
Random Access Transmission Issue 4 Revision 0
Random Access Transmission

The random–access transmission is based on a Slotted ALOHA approach with fast
acquisition indication. The UE can start the random–access transmission at the
beginning of a number of well–defined time intervals, denoted access slots. There are 15
access slots per two frames and they are spaced 5120 chips apart, see diagram
opposite. Information on what access slots are available for random–access transmission
is given by higher layers and is based upon the Access Service Class (ASC) of the UE
Structure of
Random Access
Transmission
The structure of the random–access transmission is also shown opposite. The
random–access transmission consists of one or several preambles of length 4096 chips
and a message of length 10 ms or 20 ms.
PRACH
Pre–amble
Each preamble is of length 4096 chips and consists of 256 repetitions of a signature of
length 16 chips. There are a maximum of 16 available signatures
NOT BE UPDATED
Issue 4 Revision 0 Random Access Transmission
RACH access slot numbers and their spacing
radio frame: 10 ms radio frame: 10 ms

5120
chips
Access slot #0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14
CP13_Ch7_32
Structure of the
random–access
transmission
Preamble Preamble Preamble Message part
4096 chips 10 ms (one radio frame)
Preamble Preamble Preamble Message part
4096 chips 20 ms (two radio frames)

CP13_Ch7_33

NOT BE UPDATED
Acquisition Indicator Channel AICH) Issue 4 Revision 0
Acquisition Indicator Channel AICH)

The Acquisition Indicator channel (AICH) is a fixed rate (SF=256) physical channel used
to carry Acquisition Indicators (AI). Acquisition Indicator AIs corresponds to signature s
on the PRACH.
The diagram opposite illustrates the structure of the AICH.
The AICH consists of a repeated sequence of 15 consecutive access slots (AS), each of
length 5120 chips. Each access slot consists of two parts, an Acquisition–Indicator (AI)
part consisting of 32 real–valued symbols a0, …, a31 and a part of duration 1024 chips
with no transmission that is not formally part of the AICH. The part of the slot with no
transmission is reserved for possible use by CSICH or possible future use by other
physical channels.
The spreading factor (SF) used for channelization of the AICH is 256.
The phase reference for the AICH is the Primary CPICH.
The real–valued symbols a0, a1, …, a31 are given by
15
a j = ∑AIs bs,j
s=0
where AIs, taking the values +1, –1, and 0, is the acquisition indicator corresponding to
signature s and the sequence bs,0, …, bs,31 is given in the table opposite. The
real–valued symbols, aj, are spread and modulated in the same fashion as bits when
represented in { +1, –1 } form.
NOT BE UPDATED
Issue 4 Revision 0 Acquisition Indicator Channel AICH)
Structure of Acquisition Indicator Channel (AICH)
Al part = 4096 chips, 32 real–valued symbols 1024 chips
a0 a1 a2 a30a31 Transmission Off
AS # 14 AS # 0 AS # 1 AS # i AS # 14 AS # 0
20 ms
CP13_Ch7_34
AICH signature
patterns
s bs,0, bs,1…, bs,31

0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1
2 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1
3 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1
4 1 1 1 1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1
5 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1
6 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1
7 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1
8 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1
9 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1
10 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1
11 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1
12 1 1 1 1 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1 1 1 1 1
13 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1 1 1 –1 –1
14 1 1 1 1 –1 –1 –1 –1 –1 –1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 1 1 1 1 –1 –1 –1 –1
15 1 1 –1 –1 –1 –1 1 1 –1 –1 1 1 1 1 –1 –1 –1 –1 1 1 1 1 –1 –1 1 1 –1 –1 –1 –1 1 1

NOT BE UPDATED
Structure of PRACH Message Part Issue 4 Revision 0
Structure of PRACH Message Part

The structure of the Random–access message part is shown opposite. The 10 ms
message is split into 15 slots, each of length Tslot = 2560 chips. Each slot consists of two
parts, a data part that carries Layer 2 information and a control part that carries Layer 1
control information. The data and control parts are transmitted in parallel.
The data part consists of 10*2k bits, where k=0,1,2,3. This corresponds to a spreading
factor of 256, 128, 64, and 32 respectively for the message data part. The value for the
number of bits in the data field are given in the table opposite.
The control part consists of 8 known pilot bits to support channel estimation for coherent
detection and 2 TFCI bits. This corresponds to a spreading factor of 256 for the message
control part. The total number of TFCI bits in the random–access message is 15*2 = 30.
The TFCI value corresponds to a certain transport format of the current Random–access
message.
The Random Access Channel(s) (RACH) is characterised by:
Existence in uplink only
Limited data field
Collision risk
Open loop power control
NOT BE UPDATED
Issue 4 Revision 0 Structure of PRACH Message Part
Structure of the PRACH Message Part
Data
Data
Ndatabits
Pilot TFCI
Control
Npilotbits NTFCIbits
Message part radio frame TRACH = 10ms
CP13_Ch7_24
Random–access
message data
fields
Slot Format #i Channel Bit Channel

SF
Bits/ Bits/Slot Ndata
Rate (kbps) Symbol Rate Frame
(ksps)
0 15 15 256 150 10 10
1 30 30 128 300 20 20
2 60 60 64 600 40 40
3 120 120 32 1200 80 80
CP13_Ch7_24a

NOT BE UPDATED
Dedicated downlink physical channels Issue 4 Revision 0
Dedicated downlink physical channels

There is only one type of downlink dedicated physical channel, the Downlink Dedicated
Physical Channel (downlink DPCH).
Within one downlink DPCH, dedicated data generated at Layer 2 and above, i.e. the
dedicated transport channel (DCH), is transmitted in time–multiplex with control
information generated at Layer 1 (known pilot bits, TPC commands, and an optional
TFCI). The downlink DPCH can thus be seen as a time multiplex of a downlink DPDCH
and a downlink DPCCH, compare subclause.
The diagram opposite shows the frame structure of the downlink DPCH. Each frame of
length 10 ms is split into 15 slots, each of length Tslot = 2560 chips, corresponding to one
power–control period. The parameter k in the diagram determines the total number of
bits per downlink DPCH slot. It is related to the spreading factor SF of the physical
channel as SF = 512/2k. The spreading factor may thus range from 512 down to 4. The
exact number of bits of the different downlink DPCH fields (Npilot, NTPC, NTFCI, Ndata1 and
Ndata2) is dependent upon the SF. What slot format to use is configured by higher layers
and can also be reconfigured by higher layers.
There are basically two types of downlink Dedicated Physical Channels; those that
include TFCI (e.g. for several simultaneous services) and those that do not include TFCI
(e.g. for fixed–rate services). It is the UTRAN that determines if a TFCI should be
transmitted and it is mandatory for all UEs to support the use of TFCI in the downlink.
The Pilot bits are provided to permit frame synchronisation and channel estimation at the
receiving node.
TPC symbol will indicate a step increase or decrease of transmitter power by the
receiving node.
TPC Bit Pattern Transmitter power

control command
NTPC = 2 NTPC = 4 NTPC = 8
11 1111 1111 1111 1
00 0000 00000000 0
NOT BE UPDATED
Issue 4 Revision 0 Dedicated downlink physical channels
Frame Structure for Downlink DPCH
DPDCH DPCCH DPDCH DPCCH
Data 1 TPC TFCI Data 2 Pilot

Npilot bits
Tslot = 2560 chips
One radio frame = 10ms
CP13_Ch7_16

NOT BE UPDATED
Downlink Slot Formation in Case of Multi-Code Transmission Issue 4 Revision 0
Downlink Slot Formation in Case of Multi-Code Transmission

For slot formats using TFCI, the TFCI value in each radio frame corresponds to a certain
combination of bit rates of the DCHs currently in use. This correspondence is
re–negotiated at each DCH addition/removal.
When the total bit rate to be transmitted on one downlink CCTrCH exceeds the maximum
bit rate for a downlink physical channel, multicode transmission is employed, i.e. several
parallel downlink DPCHs are transmitted for one CCTrCH using the same spreading
factor. In this case, the Layer 1 control information is put on only the first downlink DPCH.
The additional downlink DPCHs belonging to the CCTrCH do not transmit any data
during the corresponding time period.
TFCI Transport Formation Combination Indicator

DCH Dedicated Channel
CCTrCH Coded Composite Transport Channel
DPCH Dedicated Physical Channel
TPC Transmit Power Control
NOT BE UPDATED
Issue 4 Revision 0 Downlink Slot Formation in Case of Multi-Code Transmission
Downlink Slot Format in Case of Multi-Code Transmission
DPDCH
DPDCH
TPC TFCI Pilot
Transmission
Power Physical Channel 1
Transmission
Power Physical Channel 2
Transmission
Power Physical Channel L
One Slot (2560 chips)
CP13_Ch7_17

NOT BE UPDATED
Uplink Dedicated Physical channels Issue 4 Revision 0
Uplink Dedicated Physical channels

There are two types of uplink dedicated physical channels, the uplink Dedicated Physical
Data Channel (uplink DPDCH) and the uplink Dedicated Physical Control Channel (uplink
DPCCH).
The DPDCH and the DPCCH are I/Q code multiplexed within each radio frame.
The uplink DPDCH is used to carry the DCH transport channel. There may be zero, one,
or several uplink DPDCHs on each radio link.
The uplink DPCCH is used to carry control information generated at Layer 1. The Layer 1
control information consists of known pilot bits to support channel estimation for coherent
detection, transmit power–control (TPC) commands, feedback information (FBI), and an
optional transport–format combination indicator (TFCI). The transport–format
combination indicator informs the receiver about the instantaneous transport format
combination of the transport channels mapped to the simultaneously transmitted uplink
DPDCH radio frame.
There is one and only one uplink DPCCH on each radio link.
The diagram opposite shows the frame structure of the uplink dedicated physical
channels. Each radio frame of length 10 ms is split into 15 slots, each of length Tslot =
2560 chips, corresponding to one power–control period.
The parameter k in the diagram determines the number of bits per uplink DPDCH slot. It
is related to the spreading factor SF of the DPDCH as SF = 256/2k. The DPDCH
spreading factor may range from 256 down to 4, giving data rates between 15kbs and
960kbs The spreading factor of the uplink DPCCH is always equal to 256, i.e. there are
10 bits per uplink DPCCH slot. What slot format to use is configured by higher layers and
can also be reconfigured by higher layers.
The FBI bits are used to support techniques requiring feedback from the UE to the
UTRAN Access Point, including closed loop mode transmit diversity and site selection
diversity transmission (SSDT).
There are two types of uplink dedicated physical channels; those that include TFCI (e.g.
for several simultaneous services) and those that do not include TFCI (e.g. for fixed–rate
services). It is the UTRAN that determines if a TFCI should be transmitted and it is
mandatory for all UEs to support the use of TFCI in the uplink.
Multi–code operation is possible for the uplink dedicated physical channels. When
multi–code transmission is used, several parallel DPDCH are transmitted using different
channelization codes. However, there is only one DPCCH per radio link.
NOT BE UPDATED
Issue 4 Revision 0 Uplink Dedicated Physical channels
Frame Structure for Uplink DPDCH/DPCCH
Data
DPDCH
Ndatabits
Pilot TFCI FBI TPC

DPCCH Npilotbits NTFCIbits NFBIbits NTPCbits
Tf = 10ms
Frame #0 Frame #1 Frame #i Frame #71
Tsuper = 720 ms
CP13_Ch7_18

NOT BE UPDATED
Downlink Flow Process Issue 4 Revision 0
Downlink Flow Process

The downlink flow process consists of the following physical layer functions.
Data arrives to the coding/multiplexing unit in the form of transport block sets once every
transmission time interval. The transmission time interval is transport–channel specific
from the set {10 ms, 20 ms, 40 ms, 80 ms}.
The following coding/multiplexing steps can be identified for downlink:
Add CRC to each transport block
Transport block concatenation and code block segmentation
Channel coding
Rate matching
First insertion of discontinuous transmission (DTX) indication bits
First interleaving
Radio frame segmentation
Multiplexing of transport channels
Second insertion of DTX indication bits
Physical channel segmentation
Second interleaving
Mapping to physical channels
It should be noted that not every step is applicable to every data type. Some channel
coding and multiplexing examples are included as Appendix A, at Chapter 11.
NOT BE UPDATED
Issue 4 Revision 0 Downlink Flow Process
Transport channel multiplexing structure for downlink
CRC attachment
TrBk concatenation /
Code block segmentation
Channel coding
Rate matching Rate matching
1st insertion of DTX

indication
1st interleaving
TrCH Multiplexing
2nd insertion of DTX

indication
CCTrCH
Physical channel
segmentation
2nd interleaving
Physical channel mapping

PhCH#2
PhCH#1
CP13_Ch7_36

NOT BE UPDATED
Channel Coding Processes Issue 4 Revision 0
Channel Coding Processes

Data stream from/to MAC and higher layers (Transport block / Transport block set) is
encoded/decoded to offer transport services over the radio transmission link. Channel
coding scheme is a combination of error detection, error correcting, rate matching,
interleaving and transport channels mapping onto/splitting from physical channels. The
following paragraphs describe these processes in more detail.
CRC Attachment
Error detection is provided on transport blocks through a Cyclic Redundancy Check. The
CRC is 24, 16, 12, 8 or 0 bits and it is signalled from higher layers what CRC length that
should be used for each TrCH.
The entire transport block is used to calculate the CRC parity bits for each transport
block. The parity bits are generated by one of the following cyclic generator polynomials:
– gCRC24(D) = D24 + D23 + D6 + D5 + D + 1;
– gCRC16(D) = D16 + D12 + D5 + 1;
– gCRC12(D) = D12 + D11 + D3 + D2 + D + 1;
– gCRC8(D) = D8 + D7 + D4 + D3 + D + 1.
Denote the bits in a transport block delivered to layer .
Transport block
concatenation
and code block
segmentation
All transport blocks in a TTI are serially concatenated. If the number of bits in a TTI is
larger than Z, the maximum size of a code block in question, then code block
segmentation is performed after the concatenation of the transport blocks. The maximum
size of the code blocks depends on whether convolutional coding, turbo coding or no
coding is used for the TrCH.(see next paragraph)
The code blocks after segmentation ++are of the same size. If the number of bits input
to the segmentation, is not an exact multiple of the number of code blocks that will be
produced, TrCH filler bits are added to the beginning of the first block. The filler bits are
transmitted and they are always set to 0. The maximum code block sizes are:
– convolutional coding: Z = 504;
– turbo coding: Z = 5114;
– no channel coding: Z = unlimited.
NOT BE UPDATED
Issue 4 Revision 0 Channel Coding Processes
CRC Attachment and TrBk Concatenation
CRC attachment
Channel coding
1st insertion of DTX

indication
1st interleaving
TrCH Multiplexing
2nd insertion of DTX

indication
CCTrCH
Physical channel
segmentation
2nd interleaving

PhCH#1
PhCH#2
CP13_Ch7_37

NOT BE UPDATED
Channel Coding Issue 4 Revision 0
Channel Coding
Code blocks are delivered to the channel coding block where one of the following the
following channel coding schemes can be applied to TrCHs:
– convolutional coding;
– turbo coding;
– no coding.
Usage of coding scheme and coding rate for the different types of TrCH is shown in the
table opposite. Channel coding adds redundant bits to the Code blocks, which will be
used to detect and, within limits, correct errors within the code blocks introduced during
transfer across the Uu interface.
Convolutional
Coding
Convolutional codes with constraint length 9 and coding rates 1/2 and 1/3 are defined. A
rate coder will generate one redundant bit for every bit in the code block, thus doubling
the input bit rate at the output of the coder. Similarly rate 1/3 coding will treble the input
bit rate. Simplified diagrams of convolutional coders for each rate are illustrated
opposite.
Output from the rate 1/3 convolutional coder shall be done in the order output0, output1,
output2, output0, output1, output 2, output 0,…,output2. Output from the rate 1/2
convolutional coder shall be done in the order output 0, output 1, output 0, output 1,
output 0, …, output 1.
8 tail bits with binary value 0 shall be added to the end of the code block before
encoding.
The initial value of the shift register of the coder shall be ”all 0” when starting to encode
the input bits.
NOT BE UPDATED
Issue 4 Revision 0 Channel Coding
Usage of channel coding scheme and coding rate
Type of TrCH Coding scheme Coding rate

BCH
PCH 1/2
Convolutional coding
RACH
1/3, 1/2
CPCH, DCH, DSCH, FACH Turbo coding 1/3
No coding
Rate 1/2 and rate

1/3 convolutional
coders
Input
D D D D D D D D
Output 0
G0 = 561 (octal)
Output 1
G1 = 753 (octal)
(a) Rate 1/2 convolutional coder
Input
D D D D D D D D
Output 0
G0 = 557 (octal)
Output 1
G1 = 663 (octal)
Output 2
G2 = 711 (octal)
(a) Rate 1/3 convolutional coder
CP13_Ch7_38

NOT BE UPDATED
Turbo coding Issue 4 Revision 0
Turbo coding
The scheme of Turbo coder is a Parallel Concatenated Convolutional Code (PCCC) with
two 8–state constituent encoders and one Turbo code internal interleaver. The coding
rate of Turbo coder is 1/3. The structure of Turbo coder is illustrated opposite.
The initial value of the shift registers of the 8–state constituent encoders shall be all
zeros when starting to encode the input bits. Output from the Turbo coder is
x1, z1, z’1, x2, z2, z’2, …, xK , zK , z’K ,
where x1, x2, …, xK are the bits input to the Turbo coder i.e. both first 8–state constituent
encoder and Turbo code internal interleaver, and K is the number of bits, and z1, z2, …,
zK and z’1, z’2, …, z’K are the bits output from first and second 8–state constituent
encoders, respectively.
The bits output from Turbo code internal interleaver are denoted by x’1, x’2, …, x’K , and
these bits are to be input to the second 8–state constituent encoder.
NOT BE UPDATED
Issue 4 Revision 0 Turbo coding
Structure of rate 1/3 Turbo coder

Xk
1st constituent encoder
Zk
Input Xk
D D D
Input
Turbo code 2nd constituent encoder
internal interleaver Z’k
Output
D D D
X’k
X’k
CP13_Ch7_39a

NOT BE UPDATED
Rate Matching & Insertion of DTX Indication Issue 4 Revision 0
Rate Matching & Insertion of DTX Indication
Rate Matching
Rate matching is used to match the number of bits to be transmitted to the number of
bits available on a single radio frame (on either a single or multiple physical channels).
This achieved either by puncturing or repetition. Higher layers assign the rate–matching
attribute for each transport channel. This attribute is semi–static and can only be
changed through higher level signalling.
For the downlink, rate matching to the bit rate of the closest available physical channel
format will be performed. If multiple services are to multiplexed onto the same physical
channels(s), only the repetition/puncturing pattern for the highest rate service is
calculated. This same pattern will be applied to the remaining, lower rate services. If the
number of bits present for these services is still less than the minimum, transmission is
interrupted (i.e. discontinuous transmission will be applied)
Insertion of DTX
Indication
In the downlink, DTX is used to fill up the radio frame with bits when there is no TrCH
information to be transmitted. DTX indication bits only indicate when the transmission
should be turned off, they are not transmitted.
The insertion point of DTX indication bits depends on whether fixed or flexible positions
of the TrCHs in the radio frame are used. It is up to the UTRAN to decide for each
CCTrCH whether fixed or flexible positions are used during the connection. The concept
of fixed versus flexible positions is illustrated opposite.
The use of fixed positions means that for a given transport channel, the same symbols
are within each timeslot are always used. If the transmission rate for that channel is
below maximum, then DTX indication bits are used for those symbols. Since the
different channels do not have a dynamic impact on each other, DTX indication bits can
be inserted at the first insertion point, before TrCH multiplexing.
With flexible positions the situation is different since now the channel bits unused by one
service may be utilised by another service. It will therefore not be clear until after TrCH
multiplexing, which bit positions will finally be unused, thus the 2nd insertion point,
following Radio Frame Segmentation and TrCH Multiplexing is used.
NOT BE UPDATED
Issue 4 Revision 0 Rate Matching & Insertion of DTX Indication
Rate Matching
Matches TrCH Bit Rate to Radio Frame Bit Rate
Uses Repetition/Puncturing
Pattern set for Highest rate service
Lower rate Services Use DTX Indication Bits
CP13_Ch7_40
Fixed And
Flexible Bit
Positions
Fixed Position
TPC TFCI Pilot
TrCH A TrCH B
bits bits Bits
TPC TFCI Pilot

TrCH A DTX TrCH B
bits bits Bits
Flexible Position
TPC TFCI Pilot
TrCH A TrCH B
bits bits Bits
TPC TFCI Pilot

TrCH A TrCH A TrCH B
bits bits Bits
CP13_Ch7_41

NOT BE UPDATED
1ST Interleaving and Radio Frame Segmentation Issue 4 Revision 0
1ST Interleaving and Radio Frame Segmentation

1st Interleaving (also known as Inter –Frame interleaving) is used to aid the recovery
from block errors, by distributing the coded data blocks over 2, 4 or 8 radio frames.
Inter–frame interleaving is only used when the delay buget allows more than 10ms of
interleaving (i.e TTIs of 20, 40 0r 80 ms are defined). The 1st interleaving is a block
interleaver with inter–column permutations.
The Block interleaver is based upon a rectangular matrix, of C1 columns, by R1 rows,
Where:
C1 = 1,2,4 0r 8 for TTIs of 10, 20,40, & 80 ms respectively
R1 = (number of bits to interleave/C1)
Note: by this stage, the number of bits to interleave is guaranteed to be
an integer multiple of the TTI
The diagram opposite shows a simplified representation of a block interleaver. For
illustration purposes only, he example assumes a TTI of 40 ms, with a bit radio frame
rate of 4 bits per frame. The input data stream is read into the matrix by rows, starting
with the first location in the first column and ending with the last location in the end
column. When the matrix is full, the inter–column permutation is performed. In this case,
for a TTI of 40ms, columns 2 and 1 are transposed. Following transposition, the data
bits are read out by column.
As can be seen in the example, the input data stream has been distributed across the
TTI, such that after Radio frame segmentation process, blocks of contiguous blocks of
input bits, do not appear in the same radio frame.
NOT BE UPDATED
Issue 4 Revision 0 1ST Interleaving and Radio Frame Segmentation
1ST Interleaving and Radio Frame Segmentation

Input Data Stream
TTI=40ms
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Write data
into matrix
by row Perform
1 2 3 4 Inter–column 1 2 3 4
permutation
5 6 7 8 5 6 7 8
9 10 11 12 9 10 11 12 Read data
out of matrix
13 14 15 16 13 14 15 16 by row
1 5 9 13 3 7 11 15 2 6 10 14 4 8 12 16
Output Data Stream
1 5 9 13 3 7 11 15 2 6 10 14 4 8 12 16
Frame 1 Frame 2 Frame 3 Frame 4
CP13_Ch7_42

NOT BE UPDATED
Transport Channel Multiplexing and Physical Layer Segmentation Issue 4 Revision 0
Transport Channel Multiplexing and Physical Layer Segmentation

Every 10 ms, one radio frame segment from each TrCH is delivered to TrCH
multiplexing. These radio frame are serially multiplexed into a Coded Composite
Transport Channel (CCTrCH). The diagram opposite illustrates the process of TrCH
multiplexing of a 12.2kbs AMR speech channel (Which uses three separate TrCHs) and
a 3.4 Kbs Background data channel.
2nd insertion of
DTX Indication
bits
After TrCH multiplexing has been completed, insertion of DTX indication bits into unused
bit positions can now be performed, to indicate a requirement to turn off transmission.
This insertion point is only used when flexible positioning of TrCHs with the radio frame
structure is used. The DTX function will insert the bits, so that they are evenly distributed
over all timeslots within the radio frame, after 2nd interleaving
Physical Layer
Segmentation.
When more than on PhCh is used, physical channel segmentation divides the bits
contained within the CCTrCH among the different PhCHs,
2nd Interleaving
For each PhCN in use for the connection, a 2nd interleaving (or Intra–frame interleaving)
process is performed. As with first interleaving, a block interleaver, with inter–column
permutations is used, with the rectangular matrix having a fixed width of 30 columns.
This process distributes the bits, non–contiguously across the time slots of the radio
frame, to minimise the effect of bursty errors.
The resultant bit sequence is mapped to the appropriate physical channel and passed
on to the chip level processing functions.
NOT BE UPDATED
Issue 4 Revision 0 Transport Channel Multiplexing and Physical Layer Segmentation
Transport Channel Multiplexing
12.2kbps data 12.2kbps data 3.4kbps data
#1a #2a #1b #2b #1c #2c #1a #1b #2a #2b #3a #3b #1 #2 #3 #4
TrCH
multiplexing
#1a #1b #1c #1 #2a #2b #2c #2 #1a #1b #1c #3 #2a #2b #2c #4
Radio Frame 1 Radio Frame 2 Radio Frame 3 Radio Frame 4
CP13_Ch7_43

NOT BE UPDATED
Downlink Spreading and Channel Combination Issue 4 Revision 0
Downlink Spreading and Channel Combination

The upper diagram opposite illustrates the spreading operation for all downlink physical
channels except SCH, i.e. for P–CCPCH, S–CCPCH, CPICH, AICH, PICH, PDSCH,and
downlink DPCH. The non–spread physical channel consists of a sequence of real–valued
symbols. For all channels except AICH, the symbols can take the three values +1, –1,
and 0, where 0 indicates DTX. For AICH, the symbol values depend on the exact
combination of acquisition indicators to be transmitted.
Each pair of two consecutive symbols is first serial–to–parallel converted and mapped to
an I and Q branch. The mapping is such that even and odd numbered symbols are
mapped to the I and Q branch respectively. For all channels except AICH, symbol
number zero is defined as the first symbol in each frame. For AICH, symbol number zero
is defined as the first symbol in each access slot.
The I and Q branches are then spread to the chip rate by the same real–valued
channelization code Cch,SF,m. The sequences of real–valued chips on the I and Q branch
are then treated as a single complex–valued sequence of chips. This sequence of chips
is scrambled (complex chip–wise multiplication) by a complex–valued scrambling code
Sdl,n.
In case of P–CCPCH, the scrambling code is applied aligned with the P–CCPCH frame
boundary, i.e. the first complex chip of the spread P–CCPCH frame is multiplied with chip
number zero of the scrambling code. In case of other downlink channels, the scrambling
code is applied aligned with the scrambling code applied to the P–CCPCH. In this case,
the scrambling code is thus not necessarily applied aligned with the frame boundary of
the physical channel to be scrambled.
Channel
Combining
The lower diagram illustrates how different downlink channels are combined. Each
complex–valued spread channel, (corresponding to point S in the upper diagram), is
separately weighted by a weight factor Gi. The complex–valued P–SCH and S–SCH, are
separately weighted by weight factors Gp and Gs. All downlink physical channels are then
combined using complex addition.
NOT BE UPDATED
Issue 4 Revision 0 Downlink Spreading and Channel Combination
Spreading for all downlink physical channels except SCH
I
x Sdl,n
Any downlink Serial I+jQ S

physical channel to Cch,SF + x
except SCH Parallel
x x
Q
CP13_Ch7_04
Channel
Combining
x
Different downlink
Physical channels
(point S in Figure G1
Above)
x ∑
G2
P–SCH x ∑
GP
S–SCH x
GS
CP13_Ch7_44

NOT BE UPDATED
Uplink Flow Process Issue 4 Revision 0
Uplink Flow Process

The uplink flow process is largely the same as that for the downlink, and is illustrated in
the diagram opposite. The differences in the individual process steps are as follows.
Radio Frame
Equalisation
Radio frame size equalisation is padding the input bit sequence in order to ensure that
the output can be segmented in data segments of equal size. Radio frame size
equalisation is only performed in the UL (DL rate matching output block length is always
an integer multiple of the frame length).
Rate Matching
The rate matching operation in the uplink, is a much more dynamic process that may
vary on a frame–by–frame basis. The rate matching operation needs to take into
account the the number of bits coming from all transport channels. When tha data rate
of one service, the dynamic rate matching adjusts the rates of the remaining service as
well so that all symbols in the radio frame will be used.
For example if with two transport channels, one has a momentary zero rate, rate
matching used repetition to increase the symbol rate for the other service sufficiently so
that all uplink channel symbols are used.
DTX
Because Uplink rate matching ensures that all unused transport channel bits are filled,
there is no requirement for DTX indication bits to be inserted in the uplink flow
NOT BE UPDATED
Issue 4 Revision 0 Uplink Flow Process
Uplink Flow Process
CRC attachment
Channel coding
Radio Frame equalisation
1st interleaving
TrCH Multiplexing
CCTrCH
Physical channel
segmentation
2nd interleaving

PhCH#1
PhCH#2
CP13_Ch7_44

NOT BE UPDATED
Uplink Spreading and Channel Combination Issue 4 Revision 0
Uplink Spreading and Channel Combination

The figure opposite illustrates the principle of the uplink spreading of DPCCH and
DPDCHs. The binary DPCCH and DPDCHs to be spread are represented by real–valued
sequences, i.e. the binary value ”0” is mapped to the real value +1, while the binary value
”1” is mapped to the real value –1. The DPCCH is spread to the chip rate by the
channelization code cc, while the n:th DPDCH called DPDCHn is spread to the chip rate
by the channelization code cd,n. One DPCCH and up to six parallel DPDCHs can be
transmitted simultaneously, i.e. 1 ≤ n ≤ 6.
After channelization, the real–valued spread signals are weighted by gain factors, βc for
DPCCH and βd for all DPDCHs. The weighting process is performed to equalise all
power levels in the combination set.
After the weighting, the stream of real–valued chips on the I– and Q–branches are then
summed and treated as a complex–valued stream of chips. This complex–valued signal
is then scrambled by the complex–valued scrambling code Sdpch,n. The scrambling code
is applied aligned with the radio frames, i.e. the first scrambling chip corresponds to the
beginning of a radio frame. The resultant complex coded signal is forwarded to the
modulator.
PRACH Message
Part
Figure 2 illustrates the principle of the spreading and scrambling of the PRACH message
part, consisting of data and control parts. The binary control and data parts to be spread
are represented by real–valued sequences, i.e. the binary value ”0” is mapped to the real
value +1, while the binary value ”1” is mapped to the real value –1. The control part is
spread to the chip rate by the channelization code cc, while the data part is spread to the
chip rate by the channelization code cd.
After channelization, the real–valued spread signals are weighted by gain factors, βc for
the control part and βd for the data part. At every instant in time, at least one of the
values βc and βd has the amplitude.
After the weighting, the stream of real–valued chips on the I– and Q–branches are
treated as a complex–valued stream of chips. This complex–valued signal is then
scrambled by the complex–valued scrambling code Sr–msg,n. The 10 ms scrambling
code is applied aligned with the 10 ms message part radio frames, i.e. the first
scrambling chip corresponds to the beginning of a message part radio frame.
NOT BE UPDATED
Issue 4 Revision 0 Uplink Spreading and Channel Combination
DPCCH/DPDCH Spreading and Combination

Cd,n Bd
DPDCH1
Cd,n Bd
DPDCH3
Cd,n Bd
DPDCH5
SCdpch,n
Cd,n Bd I+jQ
DPDCH2
Cd,n Bd
DPDCH4 +j
Cd,n Bd
DPDCH6
CC Bd
DPCCH1
CP13_Ch7_06
PRACH
Spreading and
Combination
Cd Bd
PRACH message Sr–msg,n

data part
I+jQ
S
PRACH message
control part
Cc Bc j
CP13_Ch7_06a

NOT BE UPDATED
Uplink Spreading and Channel Combination Issue 4 Revision 0
NOT BE UPDATED
Chapter 8
User Equipment

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 8
User Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Mobile States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
UE Power Classes and Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Frequency Band and RF Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Channel Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
Stte the components of a UE
Describe the mobile RRC states
State the UE power classes and modes

NOT BE UPDATED
User Equipment (UE) Issue 4 Revision 0
User Equipment (UE)

In release 99 the UE will need to be compatible with GSM, GPRS and UMTS. It will
support both reselection and handover. It supports the RAN in the handover decision by
supplying RF environmental information (ie. received signal strength from serving cell
and neighbour cells).
The UE is divided into:
Subscriber Identity Module (SIM)
User Services Identity Module (USIM)

In Release 99, the USIM shall be developed on the basis of the phase 2+ release 99
GSM SIM including SAT (SIM Application Toolkit). It will provide new and enhanced
security features (ie. mutual authentication). It will be at the discretion of the UMTS
network operator to accept or reject the use of 2G GSM SIM as access modules in its
network.
Mobile Equipment (ME)

This constitutes the actual equipment that makes up the hand held terminal (less the
integral SIM/USIM card).
Three types of terminals are available:
The Standard telephone with key and screen aimed at the voice user.
The Information Manager or wireless PDA that is aimed at the business market.
The PC card which will interface PCs, PDAs and other devices which may come
along such as cars and refrigerators.
The telephone will be capable of providing the already existing voice services with the
addition of WAP browsers and will continue to be produced in smaller sizes. The
information Manager will provide the software on PDAs and will dictate their functionality.
PC Cards will eventually be installed in a number of devices including cars, washing
machines, refrigerators etc. opening up limitless possibilities for a ‘smart’ environment. It
is envisaged that these applications of UMTS terminals will create a huge market
eventually leading to the production of smaller, cheaper and more sophisticated devices.
NOT BE UPDATED
Issue 4 Revision 0 User Equipment (UE)
User Equipment (UE)
SIM (Subscriber Identity Module)

USIM (User Services Identity Module)
ME (Mobile Equipment)
C@ppuccino
CP13_Ch8_01

NOT BE UPDATED
Mobile States Issue 4 Revision 0
Mobile States
The two basic operational modes of the UE are Idle Mode and Connected Mode. The
connected mode can be further divided into service states, which define what kind of
physical channels a UE is using. The diagram opposite shows the main RRC service
states in the connected Mode. It also shows the transitions between idle mode and
connected mode, and the possible transitions within connected mode.
Idle Mode
In idle mode, after the UE is switched on, it selects (either automatically or manually) a
PLMN to contact. The UE looks for a suitable cell of the chosen PLMN, chooses that cell
to provide available services and tunes to the control channel. This is known as
”Camping on a cell”. After camping on a cell in idle mode, the UE is able to receive
system information messages broadcast from the cell. The UE stays in idle mode until
such time as it transmits a request to establish a RRC connection. In Idle mode the UE is
identified by IMSI, TMSI and P–TMSI. The UTRAN has no information of its own about
individual idle mode UEs and can only address, for example, all UEs in a cell or all UEs
monitoring a paging group.
–
Connected Mode
Cell DCH
In Cell DCH state a dedicated physical channel is allocated to the UE and the UE is
known by its serving RNC on a cell or active set level. The UE performs measurements
and sends measurement reports according to measurement control information received
from the RNC. The DSCH can also be used in this state, and Ues with certain
capabilities are also able to monitor the FACH channel for system information messages.
Cell FACH
In Cell FACH state no dedicated channel is allocated to the UE, but the RACH and FACH
channels can be used, both for transferring signalling messages and small amounts of
data. In this state the UE is also capable of monitoring the broadcast channel to acquire
system information. The CPCH can also be used when instructed by the UTRAN.
In this state the UE performs cell reselections, and after a reselection always sends a Cell
Update message to the RNC so the RNC knows the UE location on a cell level. For
Identification, a C–RNTI in the MAC PDU header separates UEs from each other in a
cell. When the LIE performs cell reselection it uses an U–RNTI when sending the Cell
Update message, so the UTRAN can route the message to the current serving RNC of
the UE, even if the first RNC receiving the message is not the current SRNC. The
U–RNTI is part of the RRC message, not in the MAC header.
If the new cell belongs to another RAN system, such as GPRS, the UE enters idle mode
and accesses the other system according to that systems’s access procedure
NOT BE UPDATED
Issue 4 Revision 0 Mobile States
Mobile States
Cell DCH
Cell PCH
Idle Mode
Cell FACH
URA PCH
UTRAN Connected Mode
CP13_Ch8_03a

NOT BE UPDATED
Mobile States Issue 4 Revision 0
Cell PCH
In the Cell PCH state the UE is still known on a cell level in the SRNC, but it can be
reached only via the paging channel. In this state the battery consumption is less than in
cell FACH, since the monitoring of the paging channel includes a discontinuous reception
(DRX) functionality. The LIE also listens to system information on the broadcast channel.
A UE supporting the CBS is also capable of receiving BMC message in this state. If the
UE performs cell reselection, it moves autonomously to the Cell FACH state to execute
the Cell Update procedure, after which it re–enters the Cell PCH state if no other activity
is triggered during the Cell Update procedure.
If the new cell belongs to another RAN system, such as GPRS, the UE enters idle mode
and accesses the other system according to that systems’s access procedure
URA PCH
The URA PCH state is very similar to the Cell PCH, except that the UE does not execute
Cell Update after each reselection, but instead reads UTRA Registration Area (URA)
identities from the broadcast channel, and only if the URA changes does the UE pass its
location to the SRNC. This is achieved with the URA Update procedure (the UE enters
the Cell_FACH state to execute the procedure and then reverts to the URA PCH state).
One cell can belong to one or many URAs, and only if the UE cannot find its latest URA
identification from the list of URAs in a cell does it need to execute the URA Update
Procedure. This overlapping URA feature is needed to avoid pin–pong effects in possible
network configuration, where geographically succeeding base stations are controlled by
different RNCs.
The UE leaves the connected mode and returns to idle mode when the RRC connection
is released or at RRC connection failure.
NOT BE UPDATED
Issue 4 Revision 0 Mobile States
Mobile States
Cell DCH
Cell PCH
Idle Mode
Cell FACH
URA PCH
UTRAN Connected Mode
CP13_Ch8_03a

NOT BE UPDATED
UE Power Classes and Modes Issue 4 Revision 0
UE Power Classes and Modes

These are the power classes as specified by 3GPP specifications for UMTS terminals.
These power classes are similar to the GSM Power Classes. Higher data rates require
higher power settings to achieve the QoS established in the PDP Context. TDD has
smaller power classes than FDD due to it’s reduced mobility.
NOT BE UPDATED
Issue 4 Revision 0 UE Power Classes and Modes
UE Power Classes and Modes
TDD FDD
Power Maximum output Maximum output
1 [2] w 2w
2 [0.5] w 0.5 w
3 [0.25] w 0.25 w
4 [0.125] w 0.125 w
5 [0.01] w
6 [0.001] w
CP13_Ch8_04

NOT BE UPDATED
Bluetooth Issue 4 Revision 0
Bluetooth
Bluetooth is a short–range radio link intended to replace the cables connecting portable
and/or fixed electronic devices. Key features are robustness, low complexity, low power,
and low cost.
Bluetooth operates in the unlicensed ISM band at 2.4 GHz. A frequency hop transceiver
is applied to combat interference and fading. A shaped, binary FM modulation is applied
to minimize transceiver complexity. The symbol rate is 1 Ms/s. A slotted channel is
applied with a nominal slot length of 625 ms. For full duplex transmission, a
Time–Division Duplex (TDD) scheme is used. On the channel, information is exchanged
through packets. Each packet is transmitted on a different hop frequency. A packet
nominally covers a single slot, but can be extended to cover up to five slots.
Frequency Band
and RF Channel
Bluetooth operate in the 2.4 GHz ISM band. Although globally available, the exact
location and the width of the band may differ from country to country. In the US and
Europe, for example, a band of 83.5 MHz width is available. In this band 79 RF channels
spaced at 1MHz apart are defined. In Japan, Spain and France, a smaller band is
available. In this band 23 RF channels spaced 1 MHz apart are defined.
Channel
Definition
The channel is represented by a pseudo–random hopping sequence hopping through the
79 or 23 channels. The hopping sequence is unique to the piconet and is determined by
the Bluetooth device address of the master. The phase in the hopping sequence is
determined by the Bluetooth clock master. The channel is divided into time slots where
each slot corresponds to an RF hop frequency. Consecutive hops correspond to different
RF hop frequencies.
The nominal hop rate is 1600 hops/s. All Bluetooth units participating in the piconet are
time and hop synchronised t the channel.
NOT BE UPDATED
Issue 4 Revision 0 Bluetooth
Bluetooth
2.4 GHz Bluetooth Bluetooth

Bluetooth Link Link HOIST
Radio Controller Manager
Bluetooth Frequencies
Country Frequency Range
Europe and USA 2400 – 2483.5 MHz
Japan 2471 – 2475 MHz
Spain 2445 – 2475 MHz
France 2446.5 – 2483.5 MHz
CP13_Ch8_09

NOT BE UPDATED
Bluetooth Issue 4 Revision 0
NOT BE UPDATED
Chapter 9
Radio Resource Management
Functions

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 9
Radio Resource Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–1
Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–2
Physical Layer Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
UE Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
UTRA Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–6
Compressed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–8
Cell Selection/Re–selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Immediate Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Cell Re–selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–10
Macro Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–12
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
Handover Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
Handover Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
Soft and Softer Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16
S-RNS Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–18
Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–20
Site Selection Diversity Power Control (SSDT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–20
Open Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–22
Closed Loop Power Control (Inner Loop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–24
Closed Loop Power Control (Outer Loop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–26
Multi-Cell Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–28
Site Select Diversity Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–30
Space Time Transmit Diversity (STTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–32
STTD Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–34
Closed Loop Mode Transmit diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–36
Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
System Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–38
Load Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–40

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
Describe basic Radio Resource and Mobility Management functions.

NOT BE UPDATED
Radio Resource Management Issue 4 Revision 0

Radio Resource Management (RRM) is responsible for the air Interface utilisation. RRM
guarantees that services will be provided according to the necessary quality that is
expected from the network. It is divided into 5 different sections:
Cell Selection/Reselection
Handover
Power Control
Admission Control
Load Control
NOT BE UPDATED
Issue 4 Revision 0 Radio Resource Management
Cell Selection / Reselection
Handovers
Power Control
Admission Control
Load Control
CP13_Ch9_01

NOT BE UPDATED
Physical Layer Measurements Issue 4 Revision 0
Physical Layer Measurements

The majority of radio resource management functions rely on the exchange of Layer 1
measurement reports between the UTRAN and the UE.
To initiate a specific measurement at the UE, the UTRAN transmits a ’measurement
control message’ to the UE including a measurement ID and type, a command (setup,
modify, release), the measurement objects and quantity, the reporting quantities, criteria
(periodical/event–triggered) and mode (acknowledged or unacknowledged). In idle mode
the measurement control message is broadcast in a System Information message.
When the reporting criteria is fulfilled the UE shall answer with a ’measurement report
message’ to the UTRAN including the measurement ID and the results.
UE
Measurements
CPICH RSCP
Received Signal Code Power, the received power on one code measured on the Primary
CPICH.
SIR
Signal to Interference Ratio, defined as: (RSCP/ISCP)×(SF/2). The SIR shall be
measured on DPCCH after RL combination.
UTRA carrier RSSI

Received Signal Strength Indicator, the wide–band received power within the relevant
channel bandwidth. Measurement shall be performed on a UTRAN downlink carrier.
GSM carrier RSSI

Received Signal Strength Indicator, the wide–band received power within the relevant
channel bandwidth. Measurement shall be performed on a GSM BCCH carrier.
CPICH Ec/No
The received energy per chip divided by the power density in the band. The Ec/No is
identical to RSCP/RSSI. Measurement shall be performed on the Primary CPICH.
Transport channel BLER

Estimation of the transport channel block error rate (BLER). The BLER estimation shall
be based on evaluating the CRC on each transport block after RL combination.
UE transmitted power
The total UE transmitted power on one carrier.
UE Rx–Tx time difference

The difference in time between the UE uplink DPCCH/DPDCH frame transmission and
the first significant path, of the downlink DPCH frame from the measured radio link.
Measurement shall be made for each cell included in the active set.
The Observed time difference to GSM

The Observed time difference to GSM cell is defined as: TRxGSMj – TRxSFNi, where:
TRxSFNi is the time at the beginning of the P–CCPCH frame with SFN=0 from cell i.
TRxGSMj is the time at the beginning of the GSM BCCH 51–multiframe from GSM
frequency j received closest in time after the time TRxSFNi.
NOT BE UPDATED
Issue 4 Revision 0 Physical Layer Measurements
UE Measurements
CPICH RSCP
SIR
UTRA carrier RSSI
GSM carrier RSSI
CPICH Ec/No
Transport channel BLER
UE transmitted power
UE Rx–Tx time difference
The Observed time difference to GSM

NOT BE UPDATED
Physical Layer Measurements Issue 4 Revision 0
UTRA
Measurements
RSSI
Received Signal Strength Indicator, the wide–band received power within the UTRAN
uplink carrier channel bandwidth in an UTRAN access point.
SIR
Signal to Interference Ratio, is defined as: (RSCP/ISCP)×SF. Measurement shall be
performed on the DPCCH after RL combination in Node B
Transmitted carrier power

Transmitted carrier power, is the ratio between the total transmitted power and the
maximum transmission power. Total transmission power is the mean power [W] on one
carrier from one UTRAN access point. Maximum transmission power is the mean power
[W] on one carrier from one UTRAN access point when transmitting at the configured
maximum power for the cell.
Transmitted code power

Transmitted code power, is the transmitted power on one channelisation code on one
given scrambling code on one given carrier. Measurement shall be possible on the
DPCCH–field of any dedicated radio link transmitted from the UTRAN access point and
shall reflect the power on the pilot bits of the DPCCH–field.
Transport channel BER

The transport channel BER is an estimation of the average bit error rate (BER) of
RL–combined DPDCH data. Transport channel BER is only required to be reported for
TrCHs that are channel coded.
Physical channel BER

The Physical channel BER is an estimation of the average bit error rate (BER) on the
DPCCH after RL combination in Node B.
Round trip time

Round trip time (RTT), is defined as
RTT = TRX – TTX, where
TTX = The time of transmission of the beginning of a downlink DPCH frame to a UE.
TRX = The time of reception of the beginning (the first significant path) of the
corresponding uplink DPCCH/DPDCH frame from the UE.
PRACH Propagation delay

Propagation delay is defined as one–way propagation delay as measured during either
PRACH or PCPCH access.
Acknowledged PRACH preambles

The Acknowledged PRACH preambles measurement is defined as the total number of
acknowledged PRACH preambles per access frame per PRACH. This is equivalent to
the number of positive acquisition indicators transmitted per access frame per AICH
NOT BE UPDATED
Issue 4 Revision 0 Physical Layer Measurements
UTRA Measurements
RSSI
SIR
Transmitted carrier power
Transmitted code power
Transport channel BER
Physical channel BER
Round trip time
PRACH Propagation delay
Acknowledged PRACH preambles

NOT BE UPDATED
Compressed Mode Issue 4 Revision 0
Compressed Mode
In addtion to monitoring Node Bs on the same carrier, the UE must be able to monitor for
potential target resources on other UMTS carriers, and in the case of dual mode UEs on
alternative RAN technologies (e.g GSM/GPRS). This will involve at minimum retuning of
the UEs receiver elements to a new radio frequency. As the transfer of information
between network and UE is continuous in a CDMA system, time must be “created” for
the UE perform this function. This achieved by the use of Compressed Mode.
In compressed mode, time slots from Nfirst to Nlast are not used for transmission of data.
Instead, the data that would normally be transmitted during those slots is compressed
into the remaining timeslots within that radio frame.
As illustrated in the figure opposite, the instantaneous transmit power is increased in the
compressed frame in order to keep the quality (BER, FER, etc.) unaffected by the
reduced processing gain. The amount of power increase depends on the transmission
time reduction method What frames are compressed, are decided by the network. When
in compressed mode, compressed frames can occur periodically, as illustrated, or
requested on demand. The rate and type of compressed frames is variable and depends
on the environment and the measurement requirements. The maximum idle length is
defined to be 7 slots per 10 ms frame (yielding 4.67 ms). Compressed mode can
There are three methods of compressing the data:
Compressed mode by puncturing

During compressed mode, rate matching (puncturing) is applied for creating
transmission gap in one frame.
Compressed mode by reducing the spreading factor by 2

During compressed mode, the spreading factor (SF) can be reduced by 2 during one
radio frame to enable the transmission of the information bits in the remaining time slots
of a compressed frame.
Compressed mode by higher layer scheduling

Compressed mode can be obtained by higher layer scheduling. Higher layers then set
restrictions so that only a subset of the allowed TFCs are used in compressed mode.
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.
NOT BE UPDATED
Issue 4 Revision 0 Compressed Mode
Compressed Mode
One frame
(10 ms) Transmission gap available for
inter–frequency measurements
CP13_Ch9_04

NOT BE UPDATED
Cell Selection/Re–selection Issue 4 Revision 0
Cell Selection/Re–selection
The goal of the cell selection procedures is to fast find a cell to camp on. To speed up
this process, at ”power up” or when returning from ”out of coverage”, the UE shall start
with the stored information from previous network contacts. If the UE is unable to find
any of those cells the Initial cell search will be initiated.
If it is not possible to find a cell from a valid PLMN the UE will choose a cell in a
forbidden PLMN and enter a ”limited service state”. In this state the UE regularly attempt
to find a suitable cell on a valid PLMN. If a better cell is found the UE has to read the
system information for that cell. The cell to camp on is chosen by the UE on link quality
basis. However, the network can set cell re–selection thresholds in order to take other
criteria into account, such as, for example:
– available services;
– cell load;
– UE speed.
In CDMA, it is important to minimise the UE output power, and also to minimise the
power consumption in the UE. In order to achieve that, an ’Immediate Cell Evaluation
Procedure’ at call set up can ensure that the UE transmits with the best cell, while
keeping the power consumption low.
Immediate Cell
Evaluation
It is important that the UE chooses the best cell (according to the chosen criteria) prior to
a random access on the RACH. This is the aim of the immediate cell evaluation. This
procedure shall be fast and there shall not be any hysteresis requirements between the
different cells. However, it must be possible to rank two neighbouring cells by means of
an offset. This offset is unique between two cells. This implies that this value must be a
part of the system information in the serving cell. This offset is introduced for system
tuning purposes, in order to ’move’ the ’cell border’.
Before the access on the RACH can be initiated the UE also needs to check the relevant
parts of system information for making the access. The time it takes to perform an
immediate cell evaluation and select a new cell is dependent on the time it takes to read
the system information. This can be optimised by the scheduling of the system
information at the BCCH, the better scheduling the faster cell evaluation. In particular, at
call set up, it would be important to select the optimal cell, i.e. the one where the UE
uses the lowest output power.
Cell Re–selection
The cell reselection procedure is a procedure to check the best cell to camp on. The
evaluation of the measurements for this procedure is always active, in idle mode, after
the cell selection procedure has been completed and the first cell has been chosen. The
goal of the procedure is to always camp on a cell with good enough quality even if it is
not the optimal cell all the time.
It is also possible to have a “time to trigger” and hysteresis criteria in the cell reselection
to control the number of cell reselections. The parameters needed for the cell reselection
procedure (e.g., the offset value and the hysteresis) are unique on a cell to neighbour cell
relation basis. These have therefore to be distributed, together with time to trigger value,
in system information in the serving cell. This implies that the UE does not need to read
the system information in the neighbouring cells before the cell reselection procedure
finds a neighbouring cell with better quality.
NOT BE UPDATED
Issue 4 Revision 0 Cell Selection/Re–selection
Cell Selection/Re–selection
go here whenever
a new PLMN
is selected
cell information no cell information

1
stored for the PLMN stored for the PLMN
Stored
Initial
Information no suitable cell found
Cell Selection
Cell Selection
no suitable
cell found
suitable cell found suitable cell found
no
suitable
Cell Selection cell
suitable NAS found
when leaving cell found Camped
registration
connected normally
rejected
mode
leave suitable
return to idle mode cell selected
idle mode trigger
Immediate
Connected Cell no suitable
Cell
Mode Reselection cell found
Evaluation
best
suitable
cell selected
go here when no USIM in the UE Any Cell
1 USIM inserted Selection
no acceptable cell found
an acceptable cell found
Cell Selection acceptable

when leaving cell found Camped on suitable
1
connected Any Cell cell found
mode
leave acceptable
return to idle mode cell selected
idle mode trigger
Connected
Mode Immediate
Any Cell no acceptable cell found
(Emergency Cell
Reselection
calls only) Evaluation
best
acceptable
CP13_Ch9_15QS
cell selected

NOT BE UPDATED
Macro Diversity Issue 4 Revision 0
Macro Diversity
Macrodiversity provides an improved error correction capability through the use of
combining/splitting at the RNC and Node B. Communications will be sent via the Iur
interface from the RNC in the D–RNS to the RNC in the S–RNS and on to the Iu to the
core network.
This function controls the duplication/ replication of information streams to receive/
transmit the same information through multiple physical channels from/ towards a single
mobile terminal.
This function also controls the combining of information streams generated by a single
source (diversity link), but conveyed via several parallel physical channels (diversity
sub–links). Macrodiversity control should interact with channel coding control in order to
reduce the bit error ratio when combining the different information streams. In some
cases, depending on physical network configuration, there may be several entities that
combine the different information streams, i.e. there may be combining/splitting at the
S–RNC, D–RNC or Node B level. This function is located in the UTRAN.
NOT BE UPDATED
Issue 4 Revision 0 Macro Diversity
Macro Diversity
UTRAN
lu
D–RNS S–RNS
RNC RNC RNC
CP13_Ch9_04

NOT BE UPDATED
Handover Issue 4 Revision 0
Handover
Handover
Strategy
The handover strategy employed by the network for radio link control determines the
handover decision that will be made based on the measurement results reported by the
UE/RNC and various parameters set for each cell. Network directed handover might also
occur for reasons other than radio link control, e.g. to control traffic distribution between
cells. The network operator will determine the exact handover strategies. Possible types
of Handover are as follows:
– Handover 3G –3G;
– FDD soft/softer handover;
– FDD inter–frequency hard handover;
– FDD/TDD Handover;
– TDD/FDD Handover;
– TDD/TDD Handover;
– Handover 3G – 2G (e.g. Handover to GSM);
– Handover 2G – 3G (e.g. Handover from GSM).
Handover
Causes
The following is a non–exhaustive list for causes that could be used for the initiation of a
handover process.
Uplink quality;
Uplink signal measurements;
Downlink quality;
Downlink signal measurements;
Distance;
Change of service;
Better cell;
O&M intervention;
Directed retry;
Traffic;
Pre–emption
NOT BE UPDATED
Issue 4 Revision 0 Handover
Handover
Handover Strategy Handover Causes

Handover 3G –3G; Uplink quality;
FDD soft/softer handover;
handover Uplink signal measurements;
Downlink quality;
FDD inter–frequency hard handover
handover;
D
Downlink
li k signal
i l measurements;
t
FDD/TDD Handover; Distance;
TDD/FDD Handover; Change of service;
TDD/TDD Handover;
H d Better cell;
O&M intervention;
Handover 3G – 2G (e.g. Handover to
GSM); Directed
Di t d retry;
t
Traffic;
Handover 2G – 3G (e.g.
(e g Handover from
Pre–emption
GSM).

NOT BE UPDATED
Soft and Softer Handover Issue 4 Revision 0
Soft and Softer Handover

Soft Handover is a handover in which the mobile station starts communication with a new
Node–B on a same carrier frequency, or sector of the same site (softer handover),
performing at most a change of code. For this reason Soft Handover allows easily the
provision of macro–diversity transmission. This intrinsic characteristic terminology tends
to identify Soft Handover with macro–diversity even if they are two different concepts. As
a result of this definition there are areas of the UE operation in which the UE is
connected to a number of Node–Bs. With reference to Soft Handover, the ”Active Set” is
defined as the set of Node–Bs the UE is simultaneously connected to (i.e., the UTRA
cells currently assigning a downlink DPCH to the UE constitute the active set).
The Soft Handover procedure is composed of a number of single functions:
Measurements
Filtering of Measurements
Reporting of Measurement results
The Soft Handover Algorithm
Execution of Handover.
Based on the measurements of the set of cells monitored, the Soft Handover function
evaluates if any Node–B should be added to (Radio Link Addition), removed from (Radio
Link Removal), or replaced in (Combined Radio Link Addition and Removal) the Active
Set. This procedure is known as the ”Active Set Update” procedure.
NOT BE UPDATED
Issue 4 Revision 0 Soft and Softer Handover
Soft Handover Procedure
Cell B Cell A
Eb/(No + lo) Add A

Drop B
Relative
Tadd Threshold
Tdrop Absolute
Threshold
Time
CP13_Ch9_06

NOT BE UPDATED
S-RNS Relocation Issue 4 Revision 0
S-RNS Relocation
This functionality allows moving the Serving RNS functionality from one RNC to another
RNC, e.g. closer to where the UE has moved during the communication. The Serving
RNS Relocation procedure may be applied when active cell management functionality
has created a suitable situation for it. Both UTRAN and CN are involved.
NOT BE UPDATED
Issue 4 Revision 0 S-RNS Relocation
S-RNS Relocation
Step 1 D–RNS S–RNS

Step 2 S–RNS D–RNS
lu lu
RNC RNC RNC

lur lur
CP13_Ch9_07

NOT BE UPDATED
Power Control Issue 4 Revision 0
Power Control
Power control controls the level of the transmitted power in order to minimise interference
and keep the quality of the connections.
Three types of Power Control Procedures are identified:
Open Loop Power Control
Closed Loop using the Inner Loop method

UL Inner Loop Power Control – located in both the UTRAN and the UE
DL Inner Loop Power Control – located in both the UTRAN and the UE
Closed Loop using the Outer Loop method

The main difference between Inner and Outer Loop power control is that the Frame Error
Rate can be set with Outer Loop Power Control.
UL Outer Loop Power Control – located in the S–RNC (UTRAN).

DL Outer Loop Power Control – located mainly in the UE, but some control parameters
are set by the UTRAN
Site Selection
Diversity Power
Control (SSDT)
A form of power control for the downlink that can be applied in the UE is in soft handover.
NOT BE UPDATED
Issue 4 Revision 0 Power Control
Power Control
Closed Loop Power Control (Inner Loop)
Closed Loop Power Control (Outer Loop)
Site Selection Diversity Power Control
CP13_Ch9_08

NOT BE UPDATED
Open Loop Power Control Issue 4 Revision 0

In UTRAN, open loop power control is applied only immediately prior to initiating a
transmission on the PRACH.
The UE determines an estimation of the downlink pathloss between the base station and
the UE by measuring the UTRA carrier received signal strength at the mobile. Through
the medium of the System Information messages on the P–CCPCH, the UE will also
have access to certain cell parameters, such as Cell ERP, Cell size, receiver sensitivity,
etc.
Form this information the UE will calculate the required mean output power level required
to achieve the access requirements of the cell it wishes to connect to. The UE will now
send its first RACH Pre–amble at this calculated value. If no positive or negative
acquisition indicator is detected, the UE will increase its power by the required
power–ramping factor, (cell defined parameter), and send a second RACH Pre–amble.
This process will be repeated until an acknowledgement is received, or the max retries
value is exceeded.
If a positive Ack is received, the UE will again adjust its output power, according to an
offset value notified by the cell, and transmit the RACH message part. On receipt of the
RACH Message part, the UTRAN can accurately calculate the uplink path loss and
initiate the use of closed loop power control.
NOT BE UPDATED
Issue 4 Revision 0 Open Loop Power Control
UE monitors Common Pilot

and Broadcast information,
and calculates DL path Loss
Using DL path loss as

”perceived” UL path
loss, UE calculates TX
power O/P required
access network
Only used prior to initial transmission on PRACH
CP13_Ch9_17

NOT BE UPDATED
Closed Loop Power Control (Inner Loop) Issue 4 Revision 0

The objective of Closed loop power control is to maintain the the received signal strength,
at the base station, for all UEs at the same average level. As in UMTS, all UEs in a cell
transmit on the same frequency, a single overpowered mobile could block a whole cell to
other users.
The uplink inner–loop power control adjusts the UE transmit power in order to keep the
received uplink signal–to–interference ratio (SIR) at a given SIR target (SIRtarget). The
serving cells (cells in the active set) should estimate signal–to–interference ratio (SIRest)
of the uplink, using the received pilot symbols in each uplink uplink timeslot.
The serving cells should then generate TPC commands and transmit the commands
once per slot, using the TPC symbols in each time 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”. The UE uses this information to derive
TPC_cmd.
After deriving of the TPC_cmd, the UE shall adjust the transmit power of the uplink with a
step ∆ (in dB) which is given by:
D = DTPC × TPC_cmd.
The step size ∆TPC is a layer 1 parameter which is derived from the UE–specific
higher–layer parameter ”TPC–StepSize” which is under the control of the UTRAN. If
”TPC–StepSize” has the value ”dB1”, then the layer 1 parameter ∆TPC shall take the
value 1 dB and if ”TPC–StepSize” has the value ”dB2”, then ∆TPC shall take the value
2 dB.
A similar process is used in the downlink, to control the relative power weighting to be
applied to each downlink dedicated channel.
NOT BE UPDATED
Issue 4 Revision 0 Closed Loop Power Control (Inner Loop)
UE monitors DL Signal to
Interference Ratio (SIR)
And compares against
Target SIR level
UE sends Transmit Power Control (TPC)

information to Node B, adjusting Node B
transmit power output in an attempt to
acheive target SIR
Inner Loop Power Control command rate is 1500 Hz
CP13_Ch9_18

NOT BE UPDATED
Closed Loop Power Control (Outer Loop) Issue 4 Revision 0

While Closed loop power control (Inner Loop) is used to maintain a target SIR, Outer
loop power control adjusts the SIR target in the base station according to the needs of
the individual radio link and aims at a constant quality, usually defined as a certain target
bit error rate (BER) or frame error rate (FER). The reason for adjusting the target is to
compensate for variations in UE speed and multipath profile when actually mobile.
Outer loop power control is implemented by having the Node B tag each uplink user data
frame with a frame error indicator, such as a CRC check result to the serving RNC.
Should this indicate to the RNC that the transmission quality is decreasing, the RNC will
in turn command the Node B to increase the SIR target proportionally.
The reason for having the outer loop power control reside in the RNC is that this function
should be performed after a possible soft handover combining has been performed.
NOT BE UPDATED
Issue 4 Revision 0 Closed Loop Power Control (Outer Loop)
SRNC target quality

Value sent to UE as
New Target SIR value
for Inner Loop Power
Control
SRNC Checks FER

and adjusts target Node B receives UL dedicated
quality value for channel data, which is passed
the UL serving RNC along with a Quality
estimate of the Transport Channel
SRNC
Outer Loop Power Control

command rate is 10–100 Hz
CP13_Ch9_19

NOT BE UPDATED
Multi-Cell Power Control Issue 4 Revision 0
Multi-Cell Power Control

As we have seen the UE has the ability to receive and process the transmitted downlink
from several Node Bs simultaneously. By the same token several Node Bs will be
sending conflicting power control commands to the one UE. In this situation the UE will
always ramp its power down unless all received power control commands require it to
power up.
NOT BE UPDATED
Issue 4 Revision 0 Multi-Cell Power Control
Multi-Cell Power Control
Increase
Node B Decrease Node B
Mobile Decreases
Tx Power
Increase Increase
Node B Node B
Mobile Increases
Tx Power
CP13_Ch9_09

NOT BE UPDATED
Site Select Diversity Transmission Issue 4 Revision 0
Site Select Diversity Transmission

Site Selection Diversity Transmit Power Control (SSDT) is a form of power control for the
downlink that can be applied while a UE is in soft handover (SHO). This section explains
how SSDT works, and provides some examples when SSDT should be used. In SHO, a
UE has DL connections to more than one cell. Thus, one UE contributes to the DL
interference in several cells. SSDT is a power control method that reduces the DL
interference generated while the UE is in SHO. The principle of SSDT is that the best cell
of the active set is dynamically chosen as the only transmitting site, and the other cells
involved turn down their DPDCHs. The DPCCH is transmitted as normally.
Each cell is given a temporary identification number. The UE measures the pilot power of
the PCCPCHs, and chooses the best one as its ’primary’ cell. The temporary id of this
primary cell (the ’primary id’) is transmitted on the UL DPCCH to all Node Bs of the active
set. A cell that has been selected as primary station transmits its dedicated channels with
the power necessary to reach the desired SIR target, whereas all other cells switch off
their downlink DPDCH transmission. The ’primary id’ is updated by the UE at a frequency
of 5, 10 or 20ms. The frequency depends on the SSDT mode and is set by the UTRAN.
In order for the UE to continuously perform measurements and to maintain
synchronisation, the ’secondary’ cells continue to transmit pilot information on the
DPCCH.
The prerequisite for using SSDT during an RRC connection or during a part of an RRC
connection is that all Node–Bs involved support SSDT. SSDT is controlled by L3
procedures. The control involves assignment of temporary IDs, setting an SSDT mode
and switching SSDT on or off. The control information itself (temporary IDs) terminates in
the L1 of Node B and UE respectively.
NOT BE UPDATED
Issue 4 Revision 0 Site Select Diversity Transmission
Site Select Diversity Transmission
CP13_Ch9_10

NOT BE UPDATED
Space Time Transmit Diversity (STTD) Issue 4 Revision 0
Space Time Transmit Diversity (STTD)

The open loop Downlink Transmit Diversity employs a space time block coding based
transmit diversity. The STTD encoding is optional in UTRAN. STTD support is thus
mandatory at the UE. A block diagram of the transmitter and a generic STTD encoder
are shown in the slide opposite. Channel coding, rate matching and interleaving is done
as in the non-diversity mode.
The bit sequence at the antennas after encoding, for an input bit sequence of b0, b1, b2,
b3 is shown below:
b0 b1 b2 b3
b0 b1 b2 b3
–b2 b3 b0 –b1
CP13_Ch9_21
NOT BE UPDATED
Issue 4 Revision 0 Space Time Transmit Diversity (STTD)
Space Time Transmit Diversity (STTD)
Channelizaton code
and long scrambling code C,
spreading length = M
Tx
Antenna 1
Ant 1
Pilot
TPC Diversity
Pilot Ant 2 Tx
TFI M M
Antenna 2
U U
X Ant 1 X
Data Channel Rate STTD
Interleaver
Encoder Matching Encoder
Ant 2
QPSK symbols
CP13_Ch6_31

NOT BE UPDATED
STTD Encoding Issue 4 Revision 0
STTD Encoding
In case the diversity antenna is present in UTRAN and the P-CCPCH is to be transmitted
using open loop transmit diversity, the data symbols of the P-CCPCH are STTD
encoded. The last odd data symbol in every frame (10 ms) is not STTD encoded and the
same symbol is transmitted with equal power from the two antennas. Higher layers signal
whether STTD encoding is used for the P-CCPCH or not. In addition, higher layer
signaling indicates the presence/absence of STTD encoding on P-CCPCH, by
modulating the SCH. During power on and hand over between cells the UE determines
the presence of STTD encoding on the P-CCPCH, by either receiving the higher layer
message, by demodulating the SCH channel or by a combination of the above two
schemes.
The STTD encoding for the data symbols of the slots 0 and 1 of a P-CCPCH frame. The
same procedure is used for the data symbols of slots 2 and 3, 4 and 5 and henceforth,
respectively.
NOT BE UPDATED
Issue 4 Revision 0 STTD Encoding
STTD Encoding
SCH
Slot #14 Slot #1

Slot #0
Data on P–CCPCH Data on P–CCPCH Data on P–CCPCH
each pair STTD each pair STTD each pair STTD

encoded No STTD encoded encoded
Encoding
CP13_Ch6_32

NOT BE UPDATED
Closed Loop Mode Transmit diversity Issue 4 Revision 0
Closed Loop Mode Transmit diversity

The general transmitter structure to support closed loop mode transmit diversity for
DPCH transmission is shown opposite. Channel coding, interleaving and spreading are
done as in non–diversity mode. The spread complex valued signal is fed to both TX
antenna branches, and weighted with antenna specific weight factors w1 and w2 . The
weight factors are complex valued signals (i.e., wi = ai + jbi ), in general.
The weight factors (actually the corresponding phase adjustments in closed loop mode 1
and phase/amplitude adjustments in closed loop mode 2) are determined by the UE, and
signalled to the UTRAN access point (=cell transceiver) using the D–bits of the FBI field
of uplink DPCCH.
For the closed loop mode 1 different (orthogonal) dedicated pilot symbols in the DPCCH
are sent on the 2 different antennas. For closed loop mode 2 the same dedicated pilot
symbols in the DPCCH are sent on both antennas.
NOT BE UPDATED
Issue 4 Revision 0 Closed Loop Mode Transmit diversity
Closed Loop Mode Transmit diversity
Ant1
CPICH1
W1 Tx
∑
Spread/scramble x
DPCCH
DPCCH x
DPCCH Ant2
x Tx
∑
W2 CPICH2
Rx
W1 W2
Weight Generation Rx
Determine FBI message

from Uplink DPCCH
CP13_Ch9_20

NOT BE UPDATED
Admission Control Issue 4 Revision 0
Admission Control
In CDMA networks the ’soft capacity’ concept applies. Each new call that is established
will increase the interference level in the network, this will effect quality of all other
ongoing calls in the network. Therefore it is very important to control the access to the
network in a suitable way (Call Admission Control – CAC).
The following will serve as a criterion for admission control.
Quality of
Service (QoS)
Admission Control is performed according to the Quality of Service (QoS) required by the
UE. This is an example of the services required.
Service Domain Transport Type of Service CAC

Channel Performed
Voice CS DCH Premium Yes
Streaming PS DCH Premium Yes
Web PS DSCH Assured Service Yes
Browsing
E-mail PS DSCH Best Effort No
System Load
Admission Control is performed according to the current system load and the required
service. The call should be blocked if none of the suitable cells can efficiently provide the
service required by the UE at call set up (i.e., if, considering the current load of the
suitable cells, the required service is likely to increase the interference level to an
unacceptable value). This would ensure that the UE avoids wasting power affecting the
quality of other communications. In this case, the network can initiate a re–negotiation of
resources of the on–going calls in order to reduce the traffic load.
An example of Call Admission Control is given on the right side of the page.
1. CN requests SRNC for establishing a Radio Access Bearer (RAB) indicating QoS
parameters.
2. According to QoS parameters the requested service is assigned a type of service.
CAC is performed according to the type of service.
3. Resources are allocated according to the result of CAC.
4. Acknowledgement is sent back to CN according to the result of CAC. Sub–layers
are configured accordingly.
NOT BE UPDATED
Issue 4 Revision 0 Admission Control
Admission Control
1. RANAP
RRM Entity
Message
2. Mapping Qos Parameter
RANAP Type of Service
CAC
4. RANAP
3. Resource Allocation
Message
RRC
4. CRLC Config
RLC
4. CMAC 4. CPHY–RL
Connection Setup–REQ
MAC
CP13_Ch9_11

NOT BE UPDATED
Load Control Issue 4 Revision 0
Load Control
This Management task ensures that the system will never be overloaded and remains
stable. A well planned system will seldom overload, however if such a condition does
occur there must be mechanisms in place to reduce the load quickly and efficiently.
Some of the mechanisms available to reduce the load are the following:
Downlink fast load control (Deny power–up commands)
Uplink fast load control (Reduction of Eb/No)
Handover to another W–CDMA carrier
Handover to GSM
Reduce packet data throughput
Decrease bit rate of real time users (AMR Algorithms)
Drop calls in a controlled fashion
NOT BE UPDATED
Issue 4 Revision 0 Load Control
Load Control
Downlink fast load control

Uplink fast load control
Handover to another W–CSMA carrier
Handover to GSM
Reduce packet data throughput
Decrease bit rate of small time users
Drop calls in a controlled fashion
CP13_Ch9_12

NOT BE UPDATED
Load Control Issue 4 Revision 0
NOT BE UPDATED
Chapter 10
Signalling Flow

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 10
Signalling Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–1
Paging for a UE in Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
Paging for the UE in RRC Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
RRC Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–6
RRC DCH Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–8
RA Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–10
SRNC Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–12

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Objectives
Describe selected UMTS Signalling Flow procedures.

NOT BE UPDATED
Paging for a UE in Idle Mode Issue 4 Revision 0
Paging for a UE in Idle Mode

This example shows how paging is performed for a UE in RRC Idle Mode. The UE may
be paged for a CS or PS service. Since the UE is in RRC Idle Mode, the location is only
known at CN level and therefore paging is distributed over a defined geographical area
(e.g. LA).
NOTE: The example below illustrates scenario where LA spans across 2 RNCs.
1. The CN initiates the paging of a UE over a LA spanning two RNCs (i.e. RNC1 and
RNC2) via a RANAP message called the Paging message.
Parameters Sent:
CN Domain Indicator, Permanent NAS UE Identity, Temporary UE Identity, Paging
Cause.
2. Paging of UE performed by cell1 using Paging Type 1 message.
3. Paging of UE performed by cell2 using Paging Type 1 message.
The UE detects page message from RNC1 (as example) and the procedure for
NAS signalling connection establishment follows. NAS message transfer can now
be performed.
This procedure described for RRC idle mode, applies also to the RRC connected
mode in the case of CELL_PCH and URA_PCH states.
NOT BE UPDATED
Issue 4 Revision 0 Paging for a UE in Idle Mode
Paging for UE in Idle Mode
Node B Node B RNC RNC

UE CN
1.1 2.1 1 2
1. Paging
RANAP RANAP
1. Paging
RANAP RANAP
2.PCCH: Paging Type 1
3.PCCH: Paging Type 1
CP13_Ch10_01

NOT BE UPDATED
Paging for the UE in RRC Connected Mode Issue 4 Revision 0
Paging for the UE in RRC Connected Mode

This will occur in case the position of the UE is already known; a mobility management
session will be active at this stage. Two possible solutions exists:
The UTRAN co–ordinates the paging request with the existing RRC connection.
The UE co–ordinates the paging request with the existing RRC connection.
The following example shows how paging is performed for a UE in RRC Connected
Mode (CELL_DCH and CELL_FACH states) when the UTRAN co–ordinates the paging
request with the existing RRC connection using DCCH.
1. CN initiates the paging of a UE via RANAP message Paging Request Message.
Parameters used: CN Domain Indicator, Permanent NAS UE Identity, Temporary
UE Identity, Paging Cause.
2. SRNC sends RRC message Paging Type 2.
NOT BE UPDATED
Issue 4 Revision 0 Paging for the UE in RRC Connected Mode
Paging for UE in RRC Connected Mode
Serving
UE CN
RNC
1. Paging
RANAP RANAP
2. DCCH Paging Type 2

RRC RRC
CP13_Ch10_02

NOT BE UPDATED
RRC Connection Establishment Issue 4 Revision 0
RRC Connection Establishment

The following example shows establishment of a RRC connection in dedicated transport
channel (DCH) state.
The following sequence are identified:
1. The UE initiates set–up of an RRC connection by sending RRC message Connection
Request on CCCH.
Parameters used: Initial UE Identity, Establishment cause, Initial UE Capability.
2. The SRNC decides to use a DCH for this RRC connection, allocates RNTI and radio
resources for the RRC connection. When a DCH is to be set–up, NBAP message Radio
Link Setup Request is sent to Node B.
Parameters used: Cell id, Transport Format Set, Transport Format Combination Set,
frequency, UL scrambling code(FDD only), Time Slots (TDD only), User Codes (TDD
only), Power control information.
3. Node B allocates resources, starts PHY reception, and responses with NBAP
message, Radio Link Setup Response. Parameters used: Signalling link termination,
Transport layer addressing information (AAL2 address, AAL2 Binding Identity) for the Iub
Data Transport Bearer.
4. SRNC initiates set–up of Iub Data Transport bearer using ALCAP protocol. This
request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to the
DCH. The request for set–up of Iub Data Transport bearer is acknowledged by Node B.
5./6. The Node B and SRNC establish synchronism for the Iub and Iur Data Transport
Bearer by means of exchange of the appropriate DCH Frame Protocol frames Downlink
Synchronisation and Uplink Synchronisation. Then Node B starts DL transmission.
7. Message RRC Connection Setup is sent on CCCH from SRNC to UE.
Parameters: Initial UE Identity, RNTI, Capability update Requirement, Transport Format
Set, Transport Format Combination Set, frequency, DL scrambling code (FDD only),
Time Slots (TDD only), User Codes (TDD only), Power control information.
8. Message RRC Connection Setup Complete is sent on DCCH from UE to SRNC.
Parameters: Integrity information, ciphering information.
NOT BE UPDATED
Issue 4 Revision 0 RRC Connection Establishment
RRC Connection Establishment
Node B Serving
UE
Serving RNS RNC
1. CCCH: RRC Connection Request
RRC RRC
Allocate RNTI
Select L1 and L2
parameters
2. Radio Link Setup Request

NBAP NBAP
Start Rx
3. Radio Link Setup Response

NBAP NBAP
4. ALCAP Iub Data Transport Bearer Setup

5. Downlink Synchronisation
DCH DCH
6. Uplink Synchronisation
DCH DCH
Start Rx
7. CCCH: RRC Connection Setup

RRC RRC
8. DCCH: RRC Connection Setup Complete

RRC RRC
CP13_Ch10_03

NOT BE UPDATED
RRC DCH Release Issue 4 Revision 0
RRC DCH Release

This example shows RRC Connection release of a dedicated channel, in the case of
macrodiversity on two Nodes–Bs; the first one connected to the Serving RNC, the
second one to the Drift RNC.
1. The CN initiates the release of a dedicated Channel by sending the message Iu
Release Command to the SRNC. Parameters used: Cause.
2. The SRNC confirms the release by sending an Iu Release Complete message to
the CN.
Parameters used: Data volume Report (if data volume reporting to PS is required).
3. The SRNC initiates release of Iu Data Transport bearer using ALCAP protocol.
4. Message RRC Connection Release from SRNC to UE to initiate the RRC
connection release.
Parameters: Cause.
5. Message RRC Connection Release Complete from UE to SRNC to confirm the
RRC connection release.
6. The SRNC initiates the release of the link by sending the Radio Link Deletion to
the Node B (SRNC).
7. The SRNC initiates the release of the link by sending the Radio Link Deletion to
the Drift RNC.
8. The Drift RNC initiates the release of the link by sending the Radio Link Deletion
to the Node B (Drift RNC).
9. The Node B (SRNC) confirms the release of the link by sending the Radio Link
Deletion Response to the SRNC.
10. The Node B (Drift RNC) confirms the release of the link by sending the Radio Link
Deletion Response to the Drift RNC.
11. The Drift RNC confirms the release of the link by sending the Radio Link Deletion
Response to the SRNC.
12. The Node B (SRNC) initiates release of Iub Data Transport bearer using ALCAP
protocol.
13. 13. The Node B (Drift RNC) initiates release of Iub Data Transport bearer
using ALCAP protocol.
14. The Drift RNC initiates release of Iur Data Transport bearer using ALCAP protocol.
NOT BE UPDATED
Issue 4 Revision 0 RRC DCH Release
RRC DCH Release
Node B Node B Drift Serving

UE CN
Drift RNS Serving RNS RNC RNC
1. Iu Release
RANAP RANAP
Complete
2. Iu Release
RANAP RANAP
Complete
3. ALCAP Iu Bearer Release
4. RRC connection Release
RRC RRC
5. RRC Connection Release Complete
RRC RRC
6. Radio Link Deletion

NBAP NBAP
7. Radio Link
RNSAP RNSAP
Deletion
NBAP NBAP
9. Radio Link Deletion Response

NBAP NBAP

NBAP NBAP
Response
11. Radio Link
Deletion
RNSAP RNSAP
Response
12. ALCAP Iub Bearer Release
13. ALCAP Iub Bearer Release ALCAP Iur Bearer Release
CP13_Ch10_04

NOT BE UPDATED
RA Update Issue 4 Revision 0
RA Update
This example shows location registration when changing Routing Area including change
of 3G SGSN when the UE is in MM idle state towards the 3G SGSN.
The illustrated transfer of MM signalling to/from the UE uses an established RRC
connection. This RRC connection can have been established beforehand due to ongoing
inter–working between UE and 3G–MSC/VLR or be established only for this location
registration procedure towards the 3G–SGSN. For each indicated MM message sent in
this case to/from UE, the CN discriminator indicates 3G–SGSN.
The following procedure will take place to perform the RA update:
1. The RRC connection is established, if not already done. The UE sends the initial
message Routing Area Update Request (old P–TMSI, old RAI, etc.) to the new
3G–SGSN. The old P–TMSI and the old RAI are assigned data in UMTS. The
SRNS transfers the message to the 3G–SGSN. The sending of this message to
3G–SGSN will also imply establishment of a signalling connection between SRNS
and 3G–SGSN for the concerned UE. The UTRAN shall add the RAC and the LAC
of the cell where the message was received before passing the message to the
SGSN.
2. The new 3G–SGSN send an SGSN Context Request (old P–TMSI, old RAI) to the
old 3G–SGSN to get the IMSI for the UE. (The old RAI received from UE is used
to derive the old 3G–SGSN identity/address.) The old 3G–SGSN responds with
SGSN Context Response (e.g. IMSI, PDP context information and Authentication
triplets).
3. Security functions may be executed.
4. The new 3G–SGSN informs the HLR of the change of 3G–SGSN by sending
Update GPRS Location (IMSI, SGSN number, SGSN address) to the HLR.
5. The HLR cancels the context in the old 3G–SGSN by sending Cancel Location
(IMSI). The old 3G–SGSN removes the context and acknowledges with Cancel
Location Ack.
6. The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new
3G–SGSN. The new 3G–SGSN acknowledges with Insert Subscriber Data Ack.
7. The HLR acknowledges the Update GPRS Location by sending Update GPRS
Location Acknowledge to the new 3G–SGSN.
8. The new 3G–SGSN validates the UE’s presence in the new RA. If due to regional,
national or international restrictions the UE is not allowed to attach in the RA or if
subscription checking fails, then the new 3G–SGSN rejects the Routing Area
Update Request with an appropriate cause. If all checks are successful, then the
new 3G–SGSN responds to the UE with Routing Area Update Accept (new
P–TMSI, new RAI, etc.).
9. The UE acknowledges the new P–TMSI with Routing Area Update Complete.
10. When the location registration procedure is finished, the 3G–SGSN may release
the signalling connection towards the SRNS for the concerned UE. The SRNS will
then release the RRC connection if there is no signalling connection between
3G–MSC/VLR and SRNS for the UE.
NOT BE UPDATED
Issue 4 Revision 0 RA Update
RA Update
New Old
UE SRNS HLR
3G_SGSN 3G_SGSN
1. RRC connection
establishment
1. RRC update required (old RAI, old P–TMSI)
2. SGSN Context Required (old P–TMSI, old RAI)
2. SGSN Context Resp. (IMSI, Auth.triplets)
3. Security Functions
4. Update GPRS Location
5. Cancel Location
5. Cancel Location Ack
6. Insert Subscriber Data
6. Insert Subscriber Data Ack
7. Update GPRS Location Ack

8. RA upd Accept (new RAI, new P–TMSI
9. RA update complete
10. Release
10. RRC connection release
CP13_Ch10_05

NOT BE UPDATED
SRNC Relocation Issue 4 Revision 0
SRNC Relocation
This example shows SRNS relocation when the source RNC and target RNC are
connected to different 3G–MSC.
The procedure is as follows:
1. The UTRAN makes the decision to perform the Serving RNC relocation procedure,
including the decision of onto which RNC (Target RNC) the Serving RNC
functionality is to be relocated. The source SRNC sends SRNC Relocation
required messages to the MSC. This message includes parameters such as target
RNC identifier and an information field that shall be passed transparently to the
target RNC.
2. Upon reception of SRNC Relocation required message the Anchor MSC prepares
itself for the switch and determines from the received information that the SRNC
relocation will (in this case) involve another MSC. The Anchor MSC will then send
a Prepare SRNC Relocation Request to the applicable non–anchor MSC, including
the information received from the Source RNC.
3. The non–anchor MSC will send a SRNC Relocation Request message to the
target RNC. This message includes information for building up the SRNC context,
transparently sent from Source RNC (UE ID, No of connected CN nodes, UE
capability information), and directives for setting up Iu user plane transport
bearers. When Iu user plane transport bearers have been established, and target
RNC has completed its preparation phase, SRNC Relocation Proceeding 1
message is sent to the non–anchor MSC.
4. The Prepare SRNC Relocation Response that is sent from non–anchor MSC to
Anchor MSC will contain the “SRNC Relocation Proceeding 1 received” command
from the target RNC.
5. When the “SRNC Relocation Proceeding 1” command has been received in the
Anchor MSC, the user plane transport bearers has been allocated between the
target RNC and Anchor MSC and the Anchor MSC is ready for the SRNC move.
Then the Anchor MSC indicates the completion of preparation phase at the CN
side for the SRNC relocation by sending the SRNC relocation proceeding 2
message to the Source RNC.
6. When the source RNC has received the “SRNC Relocation Proceeding 2”
message, the source RNC sends a SRNC Relocation Commit message to the
target RNC. The target RNC executes switch for all bearers at the earliest suitable
time instance.
7. Immediately after a successful switch at RNC, the target RNC (=SRNC) sends
“SRNC Relocation Complete” message to the non–anchor MSC. This message is
included by the non–anchor MSC in the “Complete SRNC relocation message”
that is sent to the anchor MSC. Upon reception of this message, the Anchor–MSC
switches from the old Iu transport bearers to the new ones.
8. After a successful switch at the Anchor MSC, a release indication is sent towards
the Source RNC. This will imply release of all UTRAN resources that were related
to this UE.
9. When the target RNC is acting as SRNC, it will send New MM System Information
to the UE indicating e.g. relevant Routing Area and Location Area. Additional RRC
information may then also be sent to the UE, e.g. new RNTI identity.
NOT BE UPDATED
Issue 4 Revision 0 SRNC Relocation
SRNC Relocation
Source Target Anchor Non–anchor

UE HLR
RNC RNC MSC MSC
1. SRNC Relocation Required

2. Prepare SRNC Relocation
3. SRNC Relocation Request
3. SRNC Relocation Proceeding
4. Prepare SRNC response
5. SRNC Reloc Proceed 2
(a) 6. SRNC Reloc
Commit
7. SRNC Reloc Complete
9. New MM System Info
(b) 7. Complete SRNC Reloc

8. Release
10. Routing Area Update
CP13_Ch10_06

NOT BE UPDATED
SRNC Relocation Issue 4 Revision 0
NOT BE UPDATED
Chapter 11
Appendix A

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 11
Appendix A
. ................................................................... i
Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–1

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Channel Coding

NOT BE UPDATED
Example for 12.2 kbps data (FFD Mode in the Downlink)
NOTE: This example can be applied to AMR speech.
Table A1: Parameter Examples for 12.2 kbps data

The number of TrChs 3
Transport block TrCH#a 0, 39 or 81 bits
size
TrCH#b 103 bits
TrCH#c 60 bits
TFCS #1 NTrCHa=1*81, NTrCHb=1*103,
NTrCHc=1*60 bits
#2 NTrCHa=1*39, NTrCHb=0*103,
NTrCHc=0*60 bits
#3 NTrCHa=1*0, NTrCHb=0*103, NTrCHc=0*60
bits
CRC 12 bits (attached only to TrCh#a)
CRC parity bit attachment for 0 bit Applied only to TrCH#a
transport block
TTI 20 ms
NOT BE UPDATED
Channel Coding and Multiplexing Example for 12.2 kbps

data (Downlink)
Transport block TrCh#a TrCh#b TrCh#c

NTrCh#a NTrCh#b NTrCh#c
CRC Attachment
CRC
NTrCha 12 NTrChb NTrChc
Tail bit attachment
Tail Tail Tail
Convolutional NTrCha+12 8 NTrChb 8*NTrChb/103 NTrChc 8*NTrChc/60
coding R=1/3,1/2
N TrCHa
3*(NTrCHa+20) 3*(NTrCHb+8*NTrCHb/103) 2*(NTrCHc+8*NTrCHc/60)

Rate matching
Insertion of DTX 3*(NTrCHa+20)+NRMa 3*(NTrCHb+8*NTrCHb/103) 2*(NTrCHc+8*NTrCHc/60)

indication +NRMb +NRMc
1st interleaving 3*(NTrCHa+20)+NRMa+NDI1 3*(NTrCHb+8*NTrCHb/103) 2*(NTrCHc+8*NTrCHc/60)

+NRMb+NDIb +NRMc+NDIc
Radio frame
segmentation 3*(NTrCHa+20)+NRMa+NDI1 3*(NTrCHb+8*NTrCHb/103) 2*(NTrCHc+8*NTrCHc/60)
+NRMb+NDIb +NRMc+NDIc
#1a #2a #1b #2b #1c #2c

NRFa NRFa NRFb NRFb NRFc NRFc
NRFa = [3*(NTrCHa+20)+NRMa+NDI1]
NRFb = [3*(NTrCHb+8*NTrCHb/103)+NRMb+NDIb]
NRFc = [2*(NTrCHc+8*NTrCHc/60)+NRMc+NDIc]
To TrCh Multiplexing
*CRC and tail bits tor TrCH#a is attached even if NTrCha = 0 bits since CRC parity bit
attachment for 0 bit transport block is applied
Channel coding and multiplexing example for 12.2 kbps data
CP13_AppA_02

NOT BE UPDATED
Channel Coding and Multiplexing Example for 12.2 kbps data

(Uplink)
NOTE: This example can be applied to AMR speech.
Transport block TrCh#a TrCh#b TrCh#c

NTrCha NTrChb NTrChc
CRC Attachment*
CRC
NTrCha 12 NTrChb NTrChc
Tail bit attachment*
Tail Tail Tail
Convolutional NTrCha+12 8 NTrChb 8*NTrChb/103 NTrChc 8*NTrChc/60
coding R=1/3,1/2
Radio frame 3*(NTrCHa+20) 3*(NTrCHb+8*NTrCHb/103) 2*(NTrCHc+8*NTrCHc/60)

equalisation
3*(NTrCHa+20) 1 3*(NTrCHb+8*NTrCHb/103) 1 2*(NTrCHc+8*NTrCHc/60)

1st interleaving
Radio frame 3*(NTrCHa+20)+1* 3*(NTrCHb+8*NTrCHb/103)+1* 2*(NTrCHc+8*NTrCHc/60)

segmentation [NTrCHa/81] +NTrCHb/103
#1a #2b #1b #2b #1c #2c

NRFa NRFa NRFb NRFb NRFc NRFc
Rate matching
#1a #2b #1b #2b #1c #2c
NRFa+NRM_1a NRFa+NRM_2b NRFb+NRM_1b NRFb+NRM_2b NRFc+NRM_1c NRFc+NRM_2c
NRFa=[3*(NTrCHa+20)+1 * [NTrCHa/81]] /2
NRFb=[3*(NTrCHb+8*NTrCHb/103)+1*)+1 * NTrCHb/103] /2
NRFc=NTrCHc+8*NTrCHc/60
CP13_AppA_04 To TrCh Multiplexing
NOT BE UPDATED
Channel Coding and Multiplexing Example for

Multiplexing of 12.2 kbps Data and 3.4 kbps Data
12.2 kbps data 12.2 kbps data 3.4 kbps data
#1a #2a #1b #2b #1c #2c #1a #2a #1b #2b #1c #2c #1 #2 #3 #4
TrCH
Multiplexing
#1a #1b #1c #1 #2a #2b #2c #2 #1a #1b #1c #3 #2a #2b #2c #4
2nd
Interleaving
Physical Channel 600 600 600 600

Mapping
60 ksps DPDCH
CFN=4N CFN=4N+1 CFN=4N+2 CFN=4N+3
CP13_AppA_03

NOT BE UPDATED
Channel Coding and Multiplexing Example for 384 kbps packet

data
NOTE: In this example, it is assumed that maximum data rate of RLC payload is 384kbps, and
MAC and RLC overhead in a transport block is 16 bits.
Parameters for 384 kbps packet data

The number of TrChs 1
Transport block size 336 bits
Transport block Set size 336*B bits (B = 0, 1, 2, 4, 8, 12 for TTI=10 ms,
B = 0, 1, 2, 4, 8, 12, 16, 20, 24 for TTI=20 ms)
CRC 16 bits
Coding Turbo coding, coding rate = 1/3
TTI 10 or 20 ms
NOT BE UPDATED
Downlink Channel coding and multiplexing example for

384 kbps packet data in case of TTI=10 ms
Transport block
CRC Attachment 336
CRC
336 16
TrBk B TrBks
concatenation (B=0, 1, 2, 4, 8, 12)
Turbo coding R=1/3 352*B
Tail bit attachment 1056*B
Tail
Rate matching 1056*B 12*[B/12]
1st interleaving 1056*B+12*[B/12]+NRM
1056*B+12*[B/12]+NRM

NOT BE UPDATED
Downlink Channel coding and multiplexing example for 384 kbps

packet data in case of TTI=20 ms
Transport block
CRC Attachment 336
CRC
336 16
TrBk B TrBks
concatenation (B=0, 1, 2, 4, 8, 12, 16, 20, 24)
Code block 352*B

segmentation
Turbo coding R=1/3 176*B 176*B
Tail bit attachment 528*B 528*B
Tail Tail
Rate matching 528*B 12*[B/24] 528*B 12*[B/24]
1st interleaving 1056*B+24*[B/24]+NRM
Radio frame 1056*B+24*[B/24]+NRM

segmentation
#1 #2
(1056*B+24*[B/24]+NRM)/2 (1056*B+24*[B/24]+NRM)/2
NOT BE UPDATED
Uplink Channel coding and multiplexing example for 384

kbps packet data in case of TTI=20 ms
Transport block
CRC Attachment 336
CRC
336 16
TrBk B TrBks
concatenation (B=0, 1, 2, 4, 8, 12, 16, 20, 24)
Code block 352*B

segmentation
Turbo coding R=1/3 176*B 176*B
Tail bit attachment 528*B 528*B
Tail Tail
1st interleaving 528*B 12*[B/24] 528*B 12*[B/24]
Radio frame 1056*B+24*[B/24]

segmentation
#1 #2
Rate matching (1056*B+24*[B/24])/2 (1056*B+24*[B/24])/2
#1 #2
(1056*B+24*[B/24])/2+NRM1 (1056*B+24*[B/24])/2+NRM2
Channel coding and multiplexing example for 384 kbps packet data

NOT BE UPDATED
Example of physical channel parameters for multiplexing of

64/128/144/384 kbps packet data and 3.4 kbps data. (Downlink)
Packet data Packet data 3.4kbps data
#1 #2 #1 #2 #1 #2 #3 #4
TrCH
multiplexing
#1 #1 #2 #2 #1 #3 #2 #4
Insertion of DTX
indication
Physical channel
segmenataion
#1 #P #1 #P #1 #P #1 #P
2nd interleaving
#1 #P #1 #P #1 #P #1 #P
Physical channel
mapping
1 2 15 1 2 15 1 2 15 1 2 15
#1
DPDCH
#P
slot
CFN=4N CFN=4N+1 CFN=4N+2 CFN=4N+3
CP13_AppA_08 TFCI&TPC Pilot System
NOT BE UPDATED
Chapter 12
Appendix B

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 12
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Multiple Choice Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1
Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 Multiple Choice Questions
Multiple Choice Questions

NOT BE UPDATED
Questions Issue 4 Revision 0
Questions
1. What does the acronym UMTS stand for:
A. User Module Transfer System
B. Universal Mobile Telecommunications System
C. UnManned Terrestrial Substation
D. Union Modular Telecommunication Site
2. The EU directives of 14 December 1998 state that IMT–2000 operators should
launch services on which of the following dates:
A. December 1st 2000.
B. January 1st 2001.
C. January 1st 2002.
D. January 1st 2003.
3. What are the data transfer rates presently for GSM and maximum predicted for
UMTS respectively:
A. 9.6 kbps & 2Mbps.
B. 2Mbps & 9.6 kbps.
C. 9.6 kbps & 114 kbps.
D. 114 kbps & 2 Mbps.
4. Which of these statements about IMT–2000 and 3GPP is correct:
A. IMT–2000 is the International Telecommunication Union’s (ITU) framework
for third–generation standards.
B. IMT–2000 is the institute that 3GPP are developing standards for.
C. 3GPP is a global co–operation between six Organisational Partners who are
the world’s major standardisation bodies from Japan, China, Europe, USA
and Korea.
D. All of the above
5. The projected number of subscribers by the year 2010 is estimated at:
A. 20 Million
B. 200 Million
C. 1 Billion
D. 1 Billion
6. The spectrum allocation for IMT–2000 in Europe for the uplink and downlink
respectively is:
A. 1800–1880 MHZ & 1900–1980 MHz
B. 1800–1880 MHZ & 2110–2170 MHz
C. 1900–1980 MHz & 2110–2170 MHz
D. 1800–1880 MHZ & 2550–2630 MHz
NOT BE UPDATED
Issue 4 Revision 0 Questions
7. Which of these statistics about GSM is correct:

A. Operational in more than 300 countries with 200 Million subscribers.
B. Subscriber revenues in excess of 1 Billion US$ per annum.
C. Forecast of 600 Million subscribers by the end of 2003.
D. All of the above.
8. What does the Acronym UTRAN sand for:
A. User Telecommunications Random Access Node
B. Universal Transient Receiver Application Network
C. UMTS Telephony Revenue Assessment
D. UMTS Terrestrial Radio Access Network
9. What was the radio access technology selected for the UMTS network and which
standardisation group made the selection:
A. EDGE was selected by 3GPP
B. TDMA was selected by ITU
C. CDMA was selected by ETSI.
D. FDMA was selected by ETSI
10. Which of these diagrams best represents a UMTS network:
A. UTRAN CN C. CN UTRAN
UE Node B RNC Core UE Core RNC Node B

Network Network
RNS RNS
B. UTRAN CN D. UTRAN CN
UE Node B RNS Core UE RNC Node B Core

Network Network
RNC RNS
CP13_AppB_02
11. Which of the following statements is correct:

A. The Core Network is connected to the RNS (Radio Network System)
through the Iub interface
B. The Core Network is connected to the RNS (Radio Network System)
through the Iu interface
C. The Node B’s are connected to the Core Network by the Uu interface.
D. None of the Above

NOT BE UPDATED
12. Within the RNS’s there are:

A. Many RNC’s serving a Node B.
B. Many Node B’s are served by an RNC.
C. Iu interfaces connecting the UE with the RNC.
D. Cu interfaces between the USIM and the UE.
13. Select the correct list of components incorporated into the UTRAN in order:
A. Node B (Base Station), RNC (Radio Network Controller), Cell, Uu and UE
(User Equipment).
B. RNC (Radio Network Controller), Cell, Node B (Base Station), Uu and UE
(User Equipment).
C. Core Network, Node B (Base Station) and USIM (UMTS Subscriber Identity
Module)
D. RNC (Radio Network Controller), Node B (Base Station), Cell & Uu.
14. What is the role of the RNS:
A. An RNS is responsible for the resources and transmission/reception in a set
of cells.
B. The RNS is responsible for core network transmission delays and routing.
C. The RNS tracks packet capable mobile locations, performs security
functions and access control.
D. The RNS interfaces with external packet data networks (PDNs) to provide
the routing destination for data to be delivered to the subscriber’s mobile
terminal and to send mobile–originated data to its intended destination.
15. Which of the following statements is correct:
A. Inside the UTRAN, the RNCs of the RNSs are interconnected together
through the Iur.
B. Inside the UTRAN, the RNCs of the RNSs are interconnected together
through the Iub.
C. Within the UTRAN the USIM interfaces directly with the RNC through the Cc
interface.
D. The base stations interface with the UE through the Iur.
16. Functions of the Access Network include:
A. System access control.
B. Security and Privacy.
C. Radio Resource management and control
D. All of the Above.
NOT BE UPDATED
17. A soft handover is:

A. What would be expected most frequently in a GSM network using TDMA,
where traffic can only take one path through the network.
B. What would be expected most frequently in a UMTS network using CDMA,
where traffic can take multiple paths through the network.
C. When a user moves between cells controlled by different RNS’s.
D. The user passes the UE to another user gently without disrupting the air
interface.
18. How frequently are the Radio Frequency (RF) power adjustments made for GSM
and UMTS:
A. GSM reports 2 times per second, UMTS adjustments made 1500 times per
second.
B. GSM reports made 1600 times per second, UMTS adjustments made 2
times per second.
C. GSM reports made 20 times per second, UMTS adjustments made 160
times per second.
D. GSM reports made 0.2 times per second, UMTS adjustments made 16000
times per second.
19. Which of these statements best describes the meaning of Bluetooth:
A. A tooth from one of the infamous blue tigers found in the Himalayan foothills
in Nepal.
B. Standard for short range radio links allowing wireless connectivity between
mobile phones, mobile PCs and handheld computers etc.
C. Standard for the code behind WCDMA which is utilised in the UMTS
network.
D. None of the above.
20. What does the acronym GPRS stand for and which data transfer rate is correct:
A. Global Positioning Radio Services, data transfer rate 114kbps.
B. General Packet Radio Service, data transfer rate 2Mbps.
C. General Packet Radio Service, data transfer rate 114kbps.
D. Gateway Protocol Ratio System, data transfer rate 9.6kbps.
21. GPRS introduces two new network nodes into the GSM network SGSN (Serving
GPRS Serving Node) and GGSN (Gateway GPRS Serving Node), which of these
statements is correct:
A. The SGSN tracks packet capable mobile locations, performs security
functions and access control.
B. The GGSN interfaces with external packet data networks (PDNs) to provide
the routing destination for data to be delivered to the subscriber’s mobile
terminal and to send mobile–originated data to its intended destination.
C. The GGSN is connected with SGSNs via an IP–based GPRS backbone
network.

NOT BE UPDATED
22. Which of these statements is correct:

A. Iu is the interface between the Core Network and the RNS’s.
B. Iur is the interface between the RNC and Node B within the RNS.
C. Iub is the interface between the RNC’s.
23. Which of these statements about FDD (Frequency Division Duplex) and TDD
(Time Division Duplex) is correct:
A. FDD supports W–CDMA with data transfer rates up to 384 kbps.
B. FDD supports TD–CDMA with data transfer rates up to 2 Mbps.
C. TDD supports W–CDMA with data transfer rates up to 2 Mbps.
24. The UTRAN will allow:
A. Support of FDD.
B. Support of TDD.
C. Flexible, high bandwidth bearer support.
D. All of the above
25. The SGSN (Serving GPRS Support Node) is responsible for:
A. Interfacing between the UMSC and IP.
B. Detecting mobile equipment in the surrounding area for transmitting and
receiving data packets.
C. Decoding the CDMA (Code Division Multiple Access) to allow correct trasfer
protocol.
D. All of the Above
26. The GGSN (Gateway GPRS Support Node) is responsible for:
A. Coordinating all transfer protocols necessary for maximum utilisation of the
UTRAN.
B. Locating and identifying mobile stations and gathering necessary call
information.
C. Connecting directly to the Internet using IP over a variety of different
protocols.
D. All of the above
27. How many Node B’s might be expected per RNC:
A. 1–10
B. 10–100
C. 100–1000
D. 1000–10000
NOT BE UPDATED
28. The antennas extending out from the Node B’s have a limited distance that they
can be positioned away due to:
A. Transmission delays occur if the feeder cables are too long.
B. Power losses in feeder cables.
C. Expense due to the length of feeder cables.
D. Planning permission, so as not to spoil the surrounding area.
29. Frequency bandwidths for GSM and UMTS respectively are:
A. 200kHz & 5 MHz
B. 5 MHz & 200kHz
C. 500kHz & 2 MHz
D. 2 MHz & 15 MHz
30. Look at the two diagrams below then choose the correct answer from the selection
below:
2112.8 MHz 2167.2 MHz

0.3 Mhz 0.3 MHz
guard band guard band
10.0 MHz 10.0 MHz

License C License D
2110 MHz 2170 MHz
14.6 MHz 14.8 MHz 10.0 MHz
License A License B License E
Unpaired carriers0.4 Mhz
guard band
1922.8 MHz 1977.2 MHz
1902.4 MHz
0.3 MHz
guard band
D E F G
10.0 MHz 10.0 MHz

License C License D
1900 MHz 1920 MHz 1980 MHz
14.6 MHz 14.8 MHz 10.0 MHz
CP13_AppB_03
License A License B License E
A. Fig 1 only is correct.

B. Fig 2 only is correct.
C. Both Fig 1 & 2 are correct
D. Neither Fig 1 or 2 are correct.
31. The following statements compare GSM and EDGE technologies respectively,
select the correct statement:
A. Modulation bit rate of 270 kbps and 810 kbps.
B. Modulation concepts 8–PSK and GMSK.
C. Modulation concepts allow 3 bits per symbol and 1 bit per symbol.

NOT BE UPDATED
32. What does USIM stand for:

E. User Service Identification Management
F. Universal Switching Interface management
G. UMTS Station Integral Mode
H. UMTS Subscriber Identity Module.
33. The role of the SRNS (Serving Radio Network Subsystem) is:
A. To interface with the satellite connection of the UTRAN.
B. Control of the radio connection between the UE and the UTRAN.
C. Control of the radio connection between the UTRAN and the Core Network.
34. The role of the DRNS (Drift Radio Network Subsystem) is:
A. To support the interface with the satellite connection to the UTRAN
B. Supports the SRNS with radio resources for the connection between the UE
and the Core Network.
C. Supports the SRNS with radio resources for the connection between the UE
and the UTRAN.
35. Cell handover control is initiated from:
A. Core Network
B. User Equipment
C. UTRAN & UE
D. USIM
36. Which of the following diagrams best represents handover between cells most
accurately for W–CDMA:
A. Cell B Cell A B. Cell B Cell A

C/I C/I
Drop B Add A Drop B
Add A
T drop T drop
T add T add
Time Time
C. Cell B Drop B
Add A
Cell A D. Drop B
Cell A
C/I
T drop
T add
C/I Add A Cell B

CP13_AppB_04
Time T dropT add Time
NOT BE UPDATED
37. For Radio Resource Management and Control the UE and UTRAN are responsible
for what:
A. Packet data transfer over radio function.
B. Radio Frequency Power Control.
C. Radio channel coding, decoding and control.
38. The reason for using multiple Node B’s and RNC’s with respect to handover is:
A. To improve error correction capability and tolerance to interference.
B. Due to the unreliability of the components, therefore ensuring maximum
reliability.
C. So that an accurate position of the user can be ascertained using
triangulation, so big brother always knows where you are (ITU mandatory
requirements).
39. Which of these statements about FDD is correct:
A. FDD different frequency in uplink and downlink, such as in GSM.
B. Max planned data rate – 2Mb/s
C. Flexible spectrum usage since it does not require paired bands.
40. Which of these statements about TDD is correct
A. No chance of collision between uplink and downlink due to different
frequencies.
B. Max planned data rate – 384Kb/s.
C. Synchronisation between cells not critical.
41. What percentage of the population in the UK do ITU state that UMTS must be
available to by 2007:
A. 60%
B. 70%
C. 80%
D. 90%

NOT BE UPDATED
42. Which of the following diagrams best represents the payment and billing
architecture:
A. Financial
Network
B. Financial
Network
Transaction Accounts Transaction

Server Database Server
Transaction Core Transaction Core
Trigger Network Trigger Network
Accounts UTRAN UTRAN

Database
C. UTRAN D. Financial
Network
Accounts Core Transaction Accounts

Database Network Server Database
Transaction Transaction Transaction Core
Trigger Server Trigger Network
CP13_AppB_05
Financial UTRAN
Network
43. From the diagrams below determine which of the following answers are in the right
order:
A B C D
1 CDMA TDMA FDMA FDMA
2 FDMA CDMA CDMA TDMA
3 TDMA FDMA TDMA CDMA
time
time frequency
frequency
time
CP13_AppB_06
frequency
NOT BE UPDATED
44. Which of the following correctly represents a CDMA transmitter sequence:
Spreading Code Radio Carrier Radio Carrier Spreading Code
Digital Radio Digital W–CDMA Digital Digital Radio W–CDMA

Signal Modulator Modulator Output Signal Modulator Modulator Output
Spreading Code Radio Carrier Spreading Code Radio Carrier
W–CDMA Digital Radio Digital Digital Digital Radio W–CDMA

Input Modulator Modulator Signal Signal Modulator Modulator Output
CP13_AppB_07
45. The ITU state that a minimum percentage of the population in the UK must have
UMTS coverage, what percentage of the land mass coverage is this:
A. 15%
B. 24%
C. 36%
D. 48%

NOT BE UPDATED
46. Which of these diagrams correctly represents the components and interfaces
within the UTRAN:
Core
SGSN Network
lu lu
RNS RNS RNS RNS RNS RNS
RNC lur RNC lur RNC RNC lur RNC lur RNC
lub lub lub lub lub lub

B B B B B B B B B B B B B B B B B B
Uu Uu Uu Uu Uu Uu
UE UE UE UE UE UE
Cc Cc Cc Cc Cc Cc
USIM USIM USIM USIM USIM USIM
Core Core
Network Network
Uu lu
RNC RNC RNC RNS RNS RNS
RNS lur RNS lur RNS RNC lub RNC lub RNC
lub lub lub lur lur lur
B B B B B B B B B B B B B B B B B B
lu lu lu Uu Uu Uu
UE UE UE UE UE UE
Cc Cc Cc Cc Cc Cc
USIM USIM USIM USIM USIM USIM
CP13_AppB_08
NOT BE UPDATED
47. Which of the following correctly represents a CDMA receiver sequence:
A. C.
De–spreading Code Radio Carrier De–spreading Code Radio Carrier
Digital Radio Digital W–CDMA Digital Radio Digital Modulated

Signal demodulation demodulation Input Signal demodulation demodulation Carrier
B. D.
De–spreading Code Radio Carrier Radio Carrier De–spreading Code
W–CDMA Radio Digital Digital Digital Radio Digital Modulated

Output demodulation demodulation Signal Signal demodulation demodulation Carrier
CP13_AppB_09
48. Mobile satellite systems are to be incorporated as a solution for which of the
following problems:
A. Covering large areas of land economically,
B. Serving widely spread or remote subscribers.
C. To prevent the need for networks to be physically linked over very large
distances.
49. Which of the following are not “real time”:

A. SMS
B. Voice over IP
C. Voice (Standard GSM call)
D. None of the above
50. What Physical channel is used to broadcast information in a cell:
A. BCH
B. DCCH
C. P–CCPCH
D. None of the above

NOT BE UPDATED
NOT BE UPDATED
Chapter 13
Appendix C

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 13
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
CDMA Detection Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–1

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 CDMA Detection Exercise
CDMA Detection Exercise

NOT BE UPDATED
CDMA Detection Exercise Issue 4 Revision 0
NOT BE UPDATED
CDMA Detection
Tb
Spreaded Code
3
2
1
Y(t)
–1
–2
–3
UMTS Exercise 1
Despreading Using CC1

Using CC1
2
1
C(t)
–1
–2
3
2
1
Z(t)
–1
–2
–3
Value of integration
at end of bit period
Bit value
CP13_AppC_02

NOT BE UPDATED
NOT BE UPDATED
CDMA Detection
Tb
Spreaded Code
3
2
1
Y(t)
–1
–2
–3
UMTS Exercise 2

Using CC2
2
1
C(t)
–1
–2
3
2
1
Z(t)
–1
–2
–3
Bit value
CP13_AppC_03

NOT BE UPDATED
NOT BE UPDATED
CDMA Detection
Tb
Spreaded Code
3
2
1
Y(t)
–1
–2
–3
UMTS Exercise 3

Using CC3
2
1
C(t)
–1
–2
3
2
1
Z(t)
–1
–2
–3
Bit value
CP13_AppC_04

NOT BE UPDATED
NOT BE UPDATED
CDMA Detection
Tb
3 Path 1
2
1
P1(t)
–1
Two Equal Strnegth Paths
–2
–3
UMTS Exercise 4
3
2 Path 2
1
P2(t)
–1
–2
–3
6
5
4
3
2
1
Y(t)
–1
–2
–3
–4
–5
–6
CP13_AppC_05

NOT BE UPDATED
NOT BE UPDATED
CDMA Reception
6 Spreaded Code
5
Mobile A Sequence Locked on Path 1
4
3
2
1
Y(t)
–1
–2
UMTS Exercise 4
–3
–4
–5
–6 Despreading Using CC2
2
1
C(t)
–1
–2
6
5
4
Z(t) 3
2
1
–1
–2
–3
–4
Detected Bit value
Mobile A Bits 1 0 0 1 1
CP13_AppC_06

NOT BE UPDATED
NOT BE UPDATED
CDMA Reception
6 Spreaded Code
5
Mobile A Sequence Locked on Path 2
4
3
2
1
Z(t)
–1
–2
UMTS Exercise 5
–3
–4
–5
–6 Despreading Using CC2
2
1
C1(t–2Tc)
–1
–2
6
5
4
Z(t) 3
2
1
–1
–2
–3
–4
Detected Bit value
CP13_AppC_07

NOT BE UPDATED
NOT BE UPDATED
Equal Gain Receiver Output
Bit 1 Bit 2 Bit 3 Bit 4 Bit 5
Path 1
Integration Output +4 +4 –8 +8 +12
UMTS Exercise 6
Path 2
Integration Output +8 –8 –12 –4 +12
Sum of Outputs
Detected Bit value

CP13_AppC_08

NOT BE UPDATED
NOT BE UPDATED
Chapter 14
Appendix D

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 14
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Glossary of Terms for the Universal Mobile Telecommunication System . . . . . . . . . . . . 14–1
A ................................................................... 14–11
B ................................................................... 14–11
C ................................................................... 14–12
D ................................................................... 14–13
E ................................................................... 14–13
F.................................................................... 14–13
G ................................................................... 14–13
H ................................................................... 14–14
I .................................................................... 14–14
J .................................................................... 14–14
K ................................................................... 14–14
L .................................................................... 14–14
M ................................................................... 14–15
N ................................................................... 14–15
O ................................................................... 14–15
P ................................................................... 14–16
Q ................................................................... 14–16
R ................................................................... 14–17
S ................................................................... 14–18
T.................................................................... 14–19
U ................................................................... 14–19
V ................................................................... 14–20
W ................................................................... 14–20

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 Glossary of Terms for the Universal Mobile Telecommunication System
Glossary of Terms for the Universal Mobile Telecommunication

System
Active mode:
“Active mode” is the state of a User Equipment when processing a call.
Active Set:
Set of radio links simultaneously involved in a specific communication service
between an User Equipment and a UTRAN access point.
Adaptive Terminal
An “adaptive terminal” is terminal equipment with the capability of adapting to more
than one type or variation of network.
ALCAP:
Generic name for the transport signalling protocols used to set–up and tear–down
transport bearers.
Camped on a cell:
The UE is in idle mode and has completed the cell selection/reselection process and
has chosen a cell. The UE monitors system information and (in most cases) paging
information. Note that the services may be limited, and that the PLMN may not be
aware of the existence of the UE within the chosen cell.
Cell:
A cell is a geographical area that can be identified by a User Equipment from a (cell)
identification that is broadcast from one UTRAN Access Point
Control channel:
A ”control channel” is a logical channel that carries system control information.
Controlling RNC:
A role an RNC can take with respect to a specific set of UTRAN access points.
There is only one Controlling RNC for any UTRAN access point . The Controlling
RNC has the overall control of the logical resources of its UTRAN access points.
Coverage area:
The “coverage area” is the area over which a UMTS service is provided with the
service probability above a certain threshold.

NOT BE UPDATED
Glossary of Terms for the Universal Mobile Telecommunication System Issue 4 Revision 0
Deployment scenario:
The ”deployment scenario” is a description of assumed user density and traffic to be
served by a system in simulations. In the radio transmission technology selection
process, the deployment scenario serves as a representation of the ultimate UMTS
deployment.
Downlink:
A “downlink” is a unidirectional radio link for the transmission of signals from a
UTRAN access point to a User Equipment.
Drift RNS:
The role an RNS can take with respect to a specific connection between a User
Equipment and UTRAN. An RNS that supports the Serving RNS with radio
resources when the connection between the UTRAN and the User Equipment need
to use cell(s) controlled by this RNS is referred to as Drift RNS.
Handover:
The transfer of a user’s connection from one radio channel to another (can be the
same or different cell).
Hard Handover:
Hard handover is a category of handover procedures where all the old radio links in
the UE are abandoned before the new radio links are established.
Home PLMN:
This is a PLMN where the Mobile Country Code (MCC) and Mobile Network Code
(MNC) of the PLMN identity are the same as the MCC and MNC of the IMSI.
Hot Spot Capacity:

Number of users who may be instantaneously supported per isolated cell (or satellite
spot beam) per unit spectrum. This must be specified at a stated spectrum
allocation, quality and grade of service.
Idle mode:
“Idle mode” is the state of a User Equipment switched on but not actively processing
a call.
Inter–cell handover:
An “inter–cell handover” is a handover between different cells. An inter–cell handover
requires network connections to be altered.
NOT BE UPDATED
Intra–cell handover:
An “intra–cell handover” is a handover within one sector or between different sectors
of the same cell. An intra–cell handover does not require network connections to be
altered.
Island coverage:
“Island coverage” is a characteristic of a geographical zone in which UMTS service is
provided in a number of separate isolated areas (”islands”).
Iu:
Interconnection point between an RNS and a Core Network. It is also considered as
a reference point.
Iub:
Interface between an RNC and a Node B.
Iur:
A logical interface between two RNS. Whilst logically representing a point to point
link between RNSs, the physical realisation may not be a point to point link. (Editors
note: are Iu and Iub also logical interfaces)
Location Registration (LR):

The UE registers its presence in a registration area, for instance regularly or when
entering a new registration area.
Logical Channel:
A logical channel is an information stream dedicated to the transfer of a specific type
of information over the radio interface.
Macro cells:
“Macro cells” are outdoor cells with a large cell radius, typically a few tens of km.
However, the range can be extended by the use of directional antennas or repeaters.
Macro diversity:
“Macro diversity” is a operation state in which a User Equipment simultaneously has
radio links with two or more UTRAN access points for the sole aim of improving
quality of the radio connection or providing seamless handover.
Maximum Path Loss (dB):

This is the maximum loss that permits minimum SRTT performance at the cell
boundary.

NOT BE UPDATED
Maximum Range (km):

Maximum range, Rmax, is given by the range associated with the maximum path
loss.
Maximum Total Transmitter Power (dBm):

The aggregate maximum transmit power of all channels.
Maximum Transmitter Power Per Traffic Channel (dBm):

The maximum power at the transmitter output for a single traffic channel.
Mega cells / satellite cells:

“Mega or satellite cells” are outdoor cells served by a satellite. The individual sectors
of a satellite cell may have radii of 500 to 1 500 km.
Micro cells:
“Micro cells” are small outdoor cells with radii of up to 1 km.
Mobile evaluated handover:

Mobile evaluated handover (MEHO) is a type of handover triggered by an evaluation
made in the mobile. The mobile evaluates the necessity of handover based on the
measured radio environment and based on criteria defined by the network. When
the evaluation meets the hand–off criteria the necessary information is sent from the
mobile to the network. The network then decides on the necessity of the handover
based on the reported evaluation result and other conditions, eg. uplink radio
environment and/or availability of network resources, the network may then execute
the handover.
Network evaluated handover:

Network evaluated handover (NEHO) is a type of handover triggered by an
evaluation made in the network. There are three cases. The first case is that the
mobile measures and reports the measurement to the network upon request from
the network either periodically or on demand, and the network then evaluates the
necessity of handover. The second case is that the network measures and
evaluates the necessity of handover. In the third case measurements are made in
both the mobile and in the network. In all cases, the network decides the necessity
of handover based on the measurements and other conditions, e.g. availability of
network resources. The network always executes any handover.
Node B:
A logical node responsible for radio transmission / reception in one or more cells
to/from the User Equipment. Terminates the Iub interface towards the RNC.
NOT BE UPDATED
Paging area:
A “paging area” is the geographical region in which a User Equipment will be paged
as a part of incoming call establishment. A paging area may comprise one or more
cells or sectors.
Paging:
Paging is the act of seeking a User Equipment (Editors note: this needs further
clarification)
Physical channel data stream:

In the uplink, a data stream that is transmitted on one physical channel. In the
downlink, a data stream that is transmitted on one physical channel in each cell of
the active set.
Physical Channel:
In FDD mode, a physical channel is defined by code, frequency and, in the uplink,
relative phase (I/Q). In TDD mode, a physical channel is defined by code, frequency,
and time–slot.
Pico cells:
“Pico cells” are cells, mainly indoor cells, with a radius typically less than 50 metres.
Radio Access Bearer:

The service that the access stratum provides to the non-access stratum for transfer
of user data between User Equipment and CN.
Radio Access Network Application Part:

Radio Network Signalling over the Iu.
Radio connection:
A “radio connection” is a logical association between one or more User Equipments
and one or more UTRAN access points to establish point–to–point,
point–to–multipoint, broadcasting communications or even macro diversity. A radio
connection comprises one or more radio links.
Radio frame:
A radio frame is a numbered time interval of 10 ms duration used for data
transmission on the radio physical channel. A radio frame is divided into 15 time
slots of 0.625 ms duration. The unit of data that is mapped to a radio frame (10 ms
time interval) may also be referred to as radio frame.

NOT BE UPDATED
Radio interface:
The “radio interface” is the tetherless interface between a User Equipment and a
UTRAN access point. This term encompasses all the functionality required to
maintain such interfaces.
Radio link:
A “radio link” is a logical association between a single User Equipment and a single
UTRAN access point. Its physical realization comprises one or more radio bearer
transmissions.
Radio link addition

The procedure where a new radio link is added to the active set.
Radio link removal:

The procedure where a radio link is removed from the active set.
Radio Network Controller:

This equipment in the RNS is in charge of controlling the use and the integrity of the
radio resources. (SMG2 ARC)
Radio Network Subsystem Application Part:

Radio Network Signalling over the Iur.
Radio Network Subsystem:

Either a full network or only the access part of a UMTS network offering the
allocation and the release of specific radio resources to establish means of
connection in between an UE and the UTRAN. A Radio Network Subsystem is
responsible for the resources and transmission/reception in a set of cells. (SMG2
ARC)
Radio Network Temporary Identifier (RNTI):

A Radio Network Temporary Identifier is an identifier for a UE when an RRC
connection exists. It is e.g. used by the MAC protocol on common Transport
Channels (RACH, FACH, PCH).
Radio resource unit:

A “radio resource unit” is a single controllable resource employable for unidirectional
information transfer over the radio interface. Typical examples for radio bearers are a
time and frequency slot in a TDMA transmission scheme with frequency hopping, or
the portion of radio resources characterized by a code sequence in a CDMA
transmission scheme.
NOT BE UPDATED
Receiver Antenna Gain (dBi):

The maximum gain of the receiver antenna in the horizontal plane (specified as dB
relative to an isotropic radiator).
RRC Connection:
A point–to–point bi–directional connection between RRC peer entities on the UE and
the UTRAN sides, respectively. An UE has either zero or one RRC connection.
Seamless handover:
“Seamless handover” is a handover without perceptible interruption of the radio
connection
Sector:
A “sector” is a sub–area of a cell. All sectors within one cell are served by the same
base station. A radio link within a sector can be identified by a single logical
identification belonging to that sector.
Serving RNS:
A role an RNS can take with respect to a specific connection between an UE and
UTRAN. There is one Serving RNS for each UE that has a connection to UTRAN.
The Serving RNS is in charge of the radio connection between a UE and the
UTRAN. The Serving RNS terminates the Iu for this UE. (SMG2 ARC)
Signalling connection:
An acknowledged–mode link between the user equipment and the core network to
transfer higher layer information between the entities in the non–access stratum.
Signalling link:
Provides an acknowledged–mode link layer to transfer the MS–UTRAN signalling
messages as well as MS – Core Network signalling messages (using the signalling
connection).
Soft Handover:
Soft handover is a category of handover procedures where the radio links are added
and abandoned in such manner that the UE always keeps at least one radio link to
the UTRAN.
Spectrum efficiency:
“Spectrum efficiency” is a comparative measure characterizing the extent to which a
radio interface is able to support a given number of users of a given UMTS service.
Spectrum efficiency can be measured in ETE per cell per MHz or ETE per square
kilometre per MHz.

NOT BE UPDATED
SRNS Relocation:
The change of Iu instance. It should be noted that SRNS Relocation was previously
known as Streamlining.
Streamlining:
Process which changes the role of an RNS (serving and drift) when one or multiple
drift RNSs are involved in a connection.
Traffic channel:
A “traffic channel” is a logical channel which carries users information like speech or
data.
Transmission Time Interval:

Transmission Time Interval is defined as the inter–arrival time of Transport Block
Sets, i.e. the time it should take to transmit a Transport Block Set. It is always a
multiple of 10ms (the length of one Radio Frame).
Transport Block :
Transport Block is defined as the basic unit passed down to L1 from MAC, for L1
processing. An equivalent term for Transport Block is “MAC PDU”.
Transport Block Set :

Transport Block Set is defined as a set of Transport Blocks which is passed to L1
from MAC at the same time instance using the same transport channel. An
equivalent term for Transport Block Set is “MAC PDU Set”.
Transport Block Set Size:

Transport Block Set Size is defined as the number of bits in a Transport Block Set
Transport Block Size :

Transport Block Size is defined as the size (number of bits) of a Transport Block
Transport channel:
The channels offered by the physical layer to Layer 2 for data transport between
peer L1 entities are denoted as Transport Channels. Different types of transport
channels are defined by how and with which characteristics data is transferred on
the physical layer, e.g. whether using dedicated or common physical channels are
employed.
NOT BE UPDATED
Transport Format:
A Transport Format is defined as a format offered by L1 to MAC for the delivery of a
Transport Block Set during a Transmission Time Interval on a Transport Channel.
The Transport Format constitutes of two parts – one dynamic part and one
semi–static part.
Transport Format Combination:

A Transport Format Combination is defined as the combination of currently valid
Transport Formats on all Transport Channels of an MS, i.e. containing one Transport
Format from each Transport Channel.
Transport Format Combination Set :

A Transport Format Combination Set is defined as a set of Transport Format
Combinations to be used by an MS.
Transport Format Combination Indicator (TFCI) :

A Transport Format Combination Indicator is a representation of the current
Transport Format Combination.
Transport Format Identification (TFI):

A label for a specific Transport Format within a Transport Format Set.
Transport Format Set:

A set of Transport Formats. For example, a variable rate DCH has a Transport
Format Set (one Transport Format for each rate), whereas a fixed rate DCH has a
single Transport Format.
UMTS Terrestrial Radio Access Network:

UTRAN is a conceptual term identifying that part of the network which consists of
RNCs and Node Bs between Iu an Uu. The concept of UTRAN instanciation is
currently undefined. (SMG2 ARC)
Uplink:
An “uplink” is a unidirectional radio link for the transmission of signals from a Mobile
Station to a base station, from a Mobile Station to a mobile base station or from a
mobile base station to a base station.
URA updating:
URA updating is a family of procedures that updates the UTRAN registration area of
a UE when a RRC connection exists and the position of the UE is known on URA
level in the UTRAN.
User Equipment:
A Mobile Equipment with one or several User Services Identity Modules(s).

NOT BE UPDATED
UTRAN Registration Area (URA):

The UTRAN Registration Area is an area covered by a number of cells. The URA is
only internally known in the UTRAN.
UTRAN access point:

A conceptual point within the UTRAN performing radio transmission and reception. A
UTRAN access point is associated with one specific cell, i.e. there exists one
UTRAN access point for each cell. It is the UTRAN–side end point of a radio link.
Uu:
The Radio interface between UTRAN and the User Equipment.
NOT BE UPDATED
ABBREVIATIONS
A
AAL ATM Adaptation Layer
AAL2 ATM Adaptation Layer type 2
AAL5 ATM Adaptation Layer type 5
ACCH Associated Control Channel
ACIR Adjacent Channel Interference Ratio
ACK Acknowledgement
ACLR Adjacent Channel Leakage Power Ratio
ACS Adjacent Channel Selectivity
AESA ATM End System Address
AI Acquisition Indicator
AICH Acquisition Indication Channel
ALCAP Access Link Control Application Protocol
AP Access preamble
ARP Address Resolution Protocol
ARQ Automatic Repeat Request
AS Access Stratum
ASC Access Service Class
ASN.1 Abstract Syntax Notation One
ATM Asynchronous Transfer Mode
AWGN Additive White Gaussian Noise
B
BCCH Broadcast Control Channel
BCFE Broadcast Control Functional Entity
BCH Broadcast Channel
BER Bit Error Rate
BID Binding Identity
BLER Block Error Rate
BPSK Binary Phase Shift Keying
BS Base Station
BSC Base Station Controller
BSS Base Station System
BTS Base Transceiver Station

NOT BE UPDATED
C
C– Control–
CA Capacity Allocation
CAA Capacity Allocation Acknowledgement
CB Cell Broadcast
CBR Constant Bit Rate
CC Call Control
CCCH Common Control Channel
CCH Control Channel
CCPCH Common Control Physical Channel
CCTrCH Coded Composite Transport Channel
CD Capacity Deallocation or Collision Detection
CDA Capacity Deallocation Acknowledgement
CDMA Code Division Multiple Access
CFN Connection Frame Number
CN Core Network
CPICH Common Pilot Channel
CPCH Common Packet Channel
CPCS Common Part Convergence Sublayer
CPS Common Part Sublayer
CRC Cyclic Redundancy Check
CRNC Controlling Radio Network Controller
CS Circuit Switched
CTCH Common Traffic Channel
CTDMA Code Time Division Multiple Access
SCTP S Common Transport Protocol CHECK WITH wg3
CW Continuous Wave (unmodulated signal)
NOT BE UPDATED
D
DC Dedicated Control (SAP)
DCA Dynamic Channel Allocation
DCCH Dedicated Control Channel
DCH Dedicated Channel
DHO Diversity Handover
DL Downlink (Forward Link)
DPCCH Dedicated Physical Control Channel
DPCH Dedicated Physical Channel
DPDCH Dedicated Physical Data Channel
DRNC Drift Radio Network Controller
DRNS Drift RNS
DRX Discontinuous Reception
DS–CDMA Direct–Sequence Code Division Multiple Access
DSCH Downlink Shared Channel
DTCH Dedicated Traffic Channel
DTX Discontinuous Transmission
E
EIRP Equivalent Isotropic Radiated Power
F
FACH Forward Access Channel
FAUSCH Fast Uplink Signalling Channel
FBI Feedback Information
FCS Frame Check Sequence
FDD Frequency Division Duplex
FDMA Frequency Division Multiple Access
FEC Forward Error Correction
FER Frame Erasure Rate, Frame Error Rate
FN Frame Number
FP Frame Protocol
G
GC General Control (SAP)
GMSK Gaussian Minimum Shift Keying
GP Guard Period
GPRS General Packet Radio System
GSM Global System for Mobile communications
GTP GPRS Tunnelling Protocol

NOT BE UPDATED
H
HCS Hierarchical Cell Structure
HHO Hard Handover
HO Handover
I
IMA Inverse Multiplexing on ATM
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IP–M IP Multicast
ISCP Interference Signal Code Power
ITU International Telecommunication Union
J
JD Joint Detection
JP Joint Predistortion
K
kbps kilo–bits per second
ksps kilo–symbols per second
L
L1 Layer 1 (physical layer)
L2 Layer 2 (data link layer)
L3 Layer 3 (network layer)
LAC Link Access Control
LAI Location Area Identity
LCD Low Constrained Delay
LLC Logical Link Control
LSA Local Service Area
NOT BE UPDATED
M
MA Multiple Access
MAC Medium Access Control
MCC Mobile Country Code
Mcps Mega–chips per second
MDS Multimedia Distribution Service
ME Mobile Equipment
MEHO Mobile evaluated handover
MER Message Error Rate
MM Mobility Management
MNC Mobile Network Code
MO Mobile Originated
MOHO Mobile Originated Handover
MS Mobile Station
MSID Mobile Station Identifier
MSC Mobile Services Switching Centre
MT Mobile Terminated
MTP Message Transfer Part
MTP3–B Message Transfer Part level 3
MUI Mobile User Identifier
N
NAS Non–Access Stratum
NBAP Node B Application Part
NEHO Network evaluated handover
NNI Network–Node Interface
NRT Non–Real Time
NSAP Network Service Access Point
Nt Notification (SAP)
O
OCCCH ODMA Common Control Channel
ODCCH ODMA Dedicated Control Channel
ODCH ODMA Dedicated Channel
ODMA Opportunity Driven Multiple Access
O&M Operation and Management
ORACH ODMA Random Access Channel
ODTCH ODMA Dedicated Traffic Channel
OVSF Orthogonal Variable Spreading Factor

NOT BE UPDATED
P
PC Power Control
PCCC Parallel Concatenated Convolutional Code
PCCH Paging Control Channel
PCH Paging Channel
PCPCH Physical Common Packet Channel
PCCPCH Primary Common Control Physical Channel
PCS Personal Communication System
PDH Plesiochronous Digital Hierarchy
PDSCH Physical Downlink Shared Channel
PDU Protocol Data Unit
PG Processing Gain
PHS Personal Handyphone System
PHY Physical layer
PhyCH Physical Channel
PI Page Indicator
PICH Page Indication Channel
PID Packet Identification
PLMN Public Land Mobile Network
PMD Physical Media Dependent
PN Pseudo Noise
PPM Parts Per Million
PRACH Physical Random Access Channel
PS Packet Switched
PSC Primary Synchronization Code
PSCCCH Physical Shared Channel Control Channel
PSCH Physical Shared Channel
PTM Point–to–Multipoint
PTM–G PTM Group Call
PTM–M PTM Multicast
PU Payload Unit
Q
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
NOT BE UPDATED
R
RAB Radio Access Bearer
RACH Random Access Channel
RANAP Radio Access Network Application Part
RF Radio Frequency
RL Radio Link
RLC Radio Link Control
RLCP Radio Link Control Protocol
RNC Radio Network Controller
RNS Radio Network Subsystem
RNSAP Radio Network Subsystem Application Part
RNTI Radio Network Temporary Identity
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSSI Received Signal Strength Indicator
RT Real Time
RU Resource Unit
RX Receive

NOT BE UPDATED
S
SAAL Signalling ATM Adaptation Layer
SACCH Slow Associated Control Channel
SAP Service Access Point
SAR Segmentation and Reassembly
SCCH Synchronization Control Channel
SCCPCH Secondary Common Control Physical Channel
SCH Synchronization Channel
SDCCH Stand–Alone Dedicated Control Channel
SDH Synchronous Digital Hierarchy
SDU Service Data Unit
SF Spreading Factor
SFN System Frame Number
SIR Signal–to–Interference Ratio
SMS Short Message Service
SMS–CB SMS Cell Broadcast
SP Switching Point
SRNC Serving Radio Network Controller
SRNS Serving RNS
SS7 Signaling System No. 7
SSC Secondary Synchronization Code
SSCOP Service Specific Connection Oriented Protocol
SSCF Service Specific Co–ordination Function
SSCF–NNI Service Specific Coordination Function – Network Node Interface
SSCS Service Specific Convergence Sublayer
SSDT Site Selection Diversity Transmission
SSSAR Service Specific Segmentation and Re–assembly sublayer
STC Signalling Transport Converter
STTD Space Time Transmit Diversity
NOT BE UPDATED
T
TC Transmission Convergence
TCH Traffic Channel
TDD Time Division Duplex
TDMA Time Division Multiple Access
TF Transport Format
TFC Transport Format Combination
TFCI Transport Format Combination Indicator
TFCS Transport Format Combination Set
TFI Transport Format Indicator
TFS Transport Format Set
TMSI Temporary Mobile Subscriber Identity
TN Termination Node
TPC Transmit Power Control
TrCH Transport Channel
TSTD Time Switched Transmit Diversity
TTI Transmission Timing Interval
TX Transmit
U
UARFCN UTRA Absolute Radio Frequency Channel Number
UARFN UTRA Absolute Radio Frequency Number
UDD Unconstrained Delay Data
UDP User Datagram Protocol
UE User Equipment
UER User Equipment with ODMA relay operation enabled
UL Uplink (Reverse Link)
UMTS Universal Mobile Telecommunications System
UNI User–Network Interface
UP User Plane
URA User Registration Area
USCH Uplink Shared Channel
USIM UMTS Subscriber Identity Module
UTRA Universal Terrestrial Radio Access (ITU)
UTRA UMTS Terrestrial Radio Access (ETSI)
UTRAN Universal Terrestrial Radio Access Network

NOT BE UPDATED
V
VA Voice Activity factor
VBR Variable Bit Rate
VC Virtual Circuit
W
WCDMA Wideband Code Division Multiple Access
NOT BE UPDATED
Chapter 15
Glossary of technical terms and
abbreviations

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0
Chapter 2
Glossary of technical terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . i
Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
A ......................................................................... 2–2
B ......................................................................... 2–3
C ......................................................................... 2–4
D ......................................................................... 2–5
E ......................................................................... 2–6
F ......................................................................... 2–7
G ......................................................................... 2–8
H ......................................................................... 2–9
I .......................................................................... 2–10
K ......................................................................... 2–11
L ......................................................................... 2–12
M ......................................................................... 2–13
N ......................................................................... 2–14
O ......................................................................... 2–15
P ......................................................................... 2–16
Q ......................................................................... 2–17
R ......................................................................... 2–18
S ......................................................................... 2–19
T ......................................................................... 2–20
U ......................................................................... 2–21
V ......................................................................... 2–22
W ........................................................................ 2–23
X ......................................................................... 2–24
Y ......................................................................... 2–25
Z ......................................................................... 2–26

NOT BE UPDATED
Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 Numbers
Numbers
# Number.
2 Mbit/s link 4-wire As used in this manual set, the term applies to the European
E1 digital line or link which can carry 30 A-law PCM channels
or 120 16 kbit/s channels.
3GPP 3rd Generation Partnership Program.

NOT BE UPDATED
A Issue 4 Revision 0
A
AAL ATM Adaptation Layer.
AAL2 ATM Adaptation Layer Type 2.
AAL5 ATM Adaptation Layer Type 5.
AGC Automatic Gain Control.
AICH Acquisition Indication Channel. (Physical Channel)
AMR Adaptive Multi Rate (Transcoder).
API Application Programming Interface.
ARQ Automatic repeat Request.
ATC ATM Transfer Capabilities
ATM Asynchronous Transfer Mode.
AUI Attachment Unit Interface.
NOT BE UPDATED
Issue 4 Revision 0 B
B
BCH Broadcast Channel. (Transport Channel)
The BCH is a downlink transport channel that is used to
broadcast system and cell specific information. The BCH is
always transmitted over the entire cell.
BER Bit Error Rate.
BLER Block Erasure Rate.
BS Billing System.
BTS Base Transmitter Station.

NOT BE UPDATED
C Issue 4 Revision 0
C
CAC Connection Admission Control.
To decide whether a new ATM or AAL2 connection can be
accepted, meeting its QoS requirements and still maintaining
the QoS of already established connections and if so what
resources should be allocated.
CBB Clock Bridge Board.
CBC Cell Broadcast Centre.
CBR Constant Bit Rate.
CCTrCH Coded Composite Transport Channel.
CCPCH Common Control Physical Channel. (Physical Channel)
The channel used to carry the BCCH. A primary CCPCH is
continuously transmitted over the entire cell. Primary CCPCH
is a fixed rate (32 kbit/s) downlink physical
The Secondary CCPCH is a constant rate (which may differ
for different cells, depending on the capacity needed)
downlink physical channel used to carry the FACH and PCH.
The FACH and PCH are mapped to separate secondary
CCPCHs. A secondary CCPCH is only transmitted when
there is data available, and may be transmitted in a narrow
lobe (FACH only) in the same way as a DPCH.
CDMA Code Division Multiple Access technique.
Consists in allocating a specific code to each user. It does
not break up the signal into time slots or frequency bands.
The signals are decoded by using knowledge of the user’s
code. CDMA is a form of spread-spectrum, a family of digital
communication techniques. The basic principle of
spread-spectrum is the use of noise-like carrier waves, and
bandwidths much wider than that required for simple
point-to-point communication at the same data rate.
CDR(s) Call Detail Record(s).
CDVT Cell Delay Variation Tolerance.
Radio coverage area where the cell ID is broadcast. Cell
IDCell identifies the cell within UTRAN.
CGFu Charging Gateway Function, specific to UMTS.
CLP Cell Loss Priority.
CMIP Common Management Information Protocol.
CN Core Network.
Core Network Service and Transit Network Domains.
CP2/CP5/CP8 Common platform software message protocols.
CPCH Common Packet Channel. (Physical Channel)
cPCI Compact PCI.
CRC Cyclic Redundancy Check.
CRNC Controlling Radio Network Controller.
NOT BE UPDATED
Issue 4 Revision 0 C
Control-plane and user-plane functions that pertain to the

management of the radio resources for a particular Node B or
cell/sector within the Node B.
CS-Service Domain Circuit Switched-Service Domain.

NOT BE UPDATED
D Issue 4 Revision 0
D
DAC Digital to Analogue Converter.
dB Decibel. A unit of power ratio measurement.
DCCH Dedicated Control Channel.
DCH Dedicated Channel. (Transport Channel)
The DCH is a downlink or uplink transport channel that is
used to carry user or control information between the network
and a mobile station. The DCH is transmitted over the entire
cell or over only a part of the cell using lobe-forming
antennas.
DL Downlink.
DPC Digital Processing and Control.
DPCCH Dedicated Physical Control Channel. (Physical Channel)
The DPCCH is an uplink physical channel that is used to
carry control information of known pilot bits to support
channel estimation for coherent detection, transmit power
control (TPC) commands, and an optional transport format
indicator (TFI). The TFI informs the receiver about the
instantaneous parameters of the different transport channels
multiplexed on the uplink
There is only one uplink DPCCH on each connection.
DPCH Dedicated Physical Channel. (Physical Channel)
The DPCH is the only downlink physical channel and is used
to carry dedicated data for the DCH, with control information
(known pilot bits, TPC commands and an optional TFCI).
DPDCH Dedicated Physical Data Channel. (Physical Channel)
The DPDCH is an uplink physical channel that is used to
carry dedicated data generated for the DCH. There may be
zero, one or several uplink DPDCHs on each connection.
DRAC Dynamic Resource Allocation Control.
DRNC Drift Radio Network Controller.
Control-plane functions that pertain to the management of a
particular user’s radio access signalling and bearer
connection to the Iur interface.
DSCH Downlink Shared Channel.
The DSCH is a downlink transport channel shared by several
UEs carrying dedicated control or traffic data.
DSI De-serialising Interface.
DSP Digital Signal Processor.
DTCH Dedicated Transport Channel.
DTX Discontinuous Transmission.
NOT BE UPDATED
Issue 4 Revision 0 E
E
E1 2 Mbit/s digital transmission link (32 x 64 kbit/s timeslots).
EEPROM Electrically Erasable Programmable ROM.

NOT BE UPDATED
F Issue 4 Revision 0
F
FACH Forward Access Channel. (Transport Channel)
The FACH is a downlink transport channel that is used to
carry control information to a mobile station when the system
knows the location cell of the UE. The FACH may also carry
short user packets. The FACH is transmitted over the entire
cell or over only a part of the cell using lobe-forming
antennas.
FDD Frequency Division Duplex.
FMK FrameWork.
FPGA Field Programmable Gate Array.
FRAS Feature Requirement and Architecture Specification.
FRU Field Replaceable Unit.
FS Full Scale.
FTP File Transfer Protocol.
NOT BE UPDATED
Issue 4 Revision 0 G
G
Ga interface Interface between the CGFu and the SGSNu, and the CGFu
and the GGSNu.
GCRA Generic Cell Rate Algorithm.
GGSNu Gateway GPRS Support Node, specific to UMTS.
Gi interface Interface between the GGSNu and the PS-Service Domain.
Gn interface Interface between the SGSNu and the GGSNu.
GPRS General Packet Radio System.
GPS Global Positioning System.
Gr interface Interface between the SGSNu and the HLR.
GRNC Generic Radio Network Controller.
Control-plane functions that pertain to the applications that
are not specific to any particular call (user connection) or any
particular Node B.
Represents the RNC functions that are not covered by any of
the other three types (See, CRNC, DRNC and SRNC). This
also relates to global functions such as transit or ATM
functions.
GSM Global System for Mobile Communications.
GSNu GPRS Support Node, specific to UMTS.
High performance broadband packet-switching node.
GUI Graphical User Interface.

NOT BE UPDATED
H Issue 4 Revision 0
H
Hard Handover A category of handover procedures where all the old radio
links in the UE are abandoned before the new radio links are
activated.
HLR Home Location Register.
NOT BE UPDATED
Issue 4 Revision 0 I
I
ID Identifier.
IMA Inverse Multiplexing for ATM.
IP Internet Protocol.
IPPS
ISDN Integrated Services Digital Network.
ISS Integrated Support Service.
Iu Reference points between Access and Serving Network
domains.
Iub Interface between Node B and RNC network elements.
The information exchange is for the purpose of passing
signalling and data information, and supporting logical O&M
procedures.
Iu-BC Interface between the SRNC and the CBC for the Broadcast
Domain of the Core Network.
Iu-CS Interface between the SRNC and the MSCu for the Circuit
Switched-Service Domain of the Core Network.
Iu-PS Interface between the SRNC and the SGSNu for the Packet
Switched-Service Domain of the Core Network.
Iur The logical interface between two RNC network elements.
These RNCs can be SRNC and DRNC, or SRNC and CRNC,
or two GRNCs that have no specific function.

NOT BE UPDATED
K Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 L
L
LA Location Area.
LLMF Low Level Maintenance Functions.
LMT Local Maintenance Terminal.
LPA Linear Power Amplifier.
LPF Low Pass Filter.
LVDS Low Voltage Digital Signal.

NOT BE UPDATED
M Issue 4 Revision 0
M
MAC Media Access Control.
MSCu Mobile Switching Centre, specific to UMTS.
MIB Management Information Base.
MMI Man Machine Interface.
MPROC Master Processor.
NOT BE UPDATED
Issue 4 Revision 0 N
N
NBAP Node B Application Part.
Is used for setting up RAB in the RNL over the Iub.
NE Network Element.
NIB Network Interface Board.
NNI Network-Network Interface.
Node B Logical node in the RNS, responsible for radio
transmission/reception in one or more cells to/from the UE.
Node B ID identifies the Node B within UTRAN (used for
measurement reporting for instance).
NPC Network Parameter Control.
NRT Non Real Time.

NOT BE UPDATED
O Issue 4 Revision 0
O
O&M Operations and Maintenance.
OMC-G Operations and Maintenance Centre-GPRS.
OML Interface between each RNC and the controlling OMC-U.
Also the interface between the SGSNu and the controlling
OMC-Gu.
OMC-R Operations and Maintenance Centre-Radio.
OMC-T Operations and Maintenance Centre-Transportation network.
OMC-U Operations and Maintenance Centre-UMTS.
OpenMaster Bull product for integrated systems management.
NOT BE UPDATED
Issue 4 Revision 0 P
P
PACE Payload Active CP2 Emulator.
PCCPCH Primary Common Control Physical Channel.
The PCCPCH is a downlink physical channel that carries the
BCH.
PCH Paging Channel. (Transport Channel)
The PCH is a downlink transport channel that is used to carry
control information to a mobile station when the system does
not know the location cell of the UE. The PCH is always
transmitted over the entire cell.
PCI Peripheral Component Interconnect.
PCU Packet Control Unit.
PCS Physical Channel Segmentation.
PDU Protocol Data Unit.
PhCH Physical Channel.
PICH Page Indicator Channel. (Physical Channel)
PLMN Public Land Mobile Network.
PMC PCI Mezzanine Card.
PRACH Physical Random Access Channel. (Physical Channel)
The PRACH is an uplink physical channel that is used to
carry the RACH.
PS-Service Domain Package Switched-Service Domain.
PSM Power Supply Module.
PSTN Public Switched Telephone Network.
PSU Power Supply Unit.

NOT BE UPDATED
Q Issue 4 Revision 0
Q
QoS Quality of Service.
QPSK Quadrature Phase Shift Keying.
NOT BE UPDATED
Issue 4 Revision 0 R
R
RA Routing Area.
RAB Radio Access Bearer.
RACE Reset And Clock Extender.
RACH Random Access Channel. (Transport Channel)
The RACH is an uplink transport channel that is used to carry
control information from a mobile station. The RACH may
also carry short user packets. The RACH is always received
from the entire cell.
RANAP Radio Access Network Application Part.
Radio network signalling over the Iu.
RAP Radio Access Procedures.
RF Radio Frequency.
RFSI RF to Serial Interface.
RLC Radio Link Control.
RNC Radio Network Controller.
Is in charge of controlling the use and integrity of the radio
resources.
RNL Radio Network Layer.
RNS Radio Network System.
The RNS is responsible for the resources and
transmission/reception in a set of cells. The RNS is further
broken down into RNC and Node B network elements.
RNSAP Radio Network Subsystem Application Part.
Radio network signalling over the Iur between the SRNC and
DRNC.
RNTI Radio Network Temporary Identity.
There are two types of RNTI:
Controlling RNC RNTI (c-RNTI)
Serving RNC RNTI (s-RNTI).
ROM Random Access Memory.
RRC Radio Resource Control.
RRCAM RRC Acknowledge Mode.
RRCUM RRC Unacknowledge Mode.
RSSI Received Signal Strength Indicator.
RT Real Time.
Rx Receive.

NOT BE UPDATED
S Issue 4 Revision 0
S
SAAL Signalling AAL.
SAR Segmentation and Re-assembly.
SCCPCH Secondary Common Control Physical Channel.
The SCCPCH is a downlink physical channel that carries the
FACH and PCH to support a mobile phone call.
SCH Synchronisation Channel. (Physical Channel)
The SCH is a downlink signal used for cell search and
consists of two sub channels.
The Primary SCH consists of an unmodulated orthogonal
code (of length 256 chips) transmitted once every slot and is
the same for every Node B in the system.
The Secondary SCH consists of repeatedly transmitting a
sequence of 16 unmodulated orthogonal codes (of length 256
chips) in parallel with the primary SCH. The sequence on the
secondary SCH indicates to which of the 32 different code
groups the Node B downlink scrambling code belongs. 32
sequences are used to encode the 32 different code groups,
each containing 16 scrambling codes to uniquely determine
both the long code group and the frame timing.
SCU Slim Carrier Unit (Radio).
SF Spreading Factor.
SGSNu Serving GPRS Support Node, specific to UMTS.
SNMP Simple Network Management Protocol.
SI Serialising Interface.
SIR Signal to Interference Ratio.
Soft Handover Is a category of handover procedures where the radio links
are added and abandoned in such a manner that the UE
always keeps at least one radio link to the UTRAN. This
typically involves multiple Node Bs.
Softer Handover Is a type of handover that involves one or more cells of the
same Node B.
SPROC System Processor.
Is a MPC750 processor that is responsible for executing all of
the site resident software.
SRNC Serving Radio Network Controller.
Control-plane functions that pertain to the management of a
particular user’s radio access signalling and bearer
connection to the Iu-CS interface.
User-plane functions that pertain to the management of the
bearer data stream for a particular user’s radio access
signalling and bearer connection to the Iu-PS interface.
NOT BE UPDATED
Issue 4 Revision 0 T
T
TFCI Transport Format Combination Indicator.
TFCS Transport Format Combination Set.
TFS Transport Format Set.
TFTP Trivial File Transfer Protocol.
TGL Transmission Gap Length.
TPC Transmit Power Control.
TrCH Transport Channel.
TTI Transmission Time Interval.
tty Tele-Type.
Tx Transmit.

NOT BE UPDATED
U Issue 4 Revision 0
U
UBR Unspecified Bit Rate.
UE User Equipment.
UMTS Universal Mobile Telecommunications System.
UNI User Network Interface.
UPC Usage Parameter Control.
URIB UMTS Radio Interface Board.
URXB UMTS Receiver Board.
USNB UMTS Synthesiser Board.
UTRAN UMTS Terrestrial Radio Access Network.
UTXB UMTS Transmitter Board.
UL Uplink.
Uu Radio (Air) interface between the Node B network element
and UE.
The information exchange is for the purpose of passing
signalling and data information.
NOT BE UPDATED
Issue 4 Revision 0 V
V
VCAT Vector Capture and Analysis Tool.
VC Virtual Channel.
VCC Virtual Channel Connection.
VP Virtual Path.
VPC Virtual Path Connection.

NOT BE UPDATED
W Issue 4 Revision 0
W
WAN Wide Area Network.
WCDMA Wideband CDMA.
WDM Wideband Digital Modem.
NOT BE UPDATED
Issue 4 Revision 0 X

NOT BE UPDATED
Y Issue 4 Revision 0
NOT BE UPDATED
Issue 4 Revision 0 Z

NOT BE UPDATED
Z Issue 4 Revision 0
NOT BE UPDATED

Understanding - UMTS Training - Manual Motorola PDF

Uploaded by

Copyright:

Available Formats

You might also like

Understanding - UMTS Training - Manual Motorola 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

Understanding - UMTS Training - Manual Motorola PDF

Uploaded by

Copyright:

Available Formats

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5

CP13 Issue 4 Revision 0

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

CP13: Understanding UMTS

Copyrights, notices and trademarks

and MOTOROLA are trademarks of Motorola Inc.

CP13: Understanding UMTS

CP13: Understanding UMTS

UMTS Network – R99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10

CP13: Understanding UMTS

Service Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12

CP13: Understanding UMTS

Iur Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10

CP13: Understanding UMTS

Control Plane Protocol Stack

CP13: Understanding UMTS

CP13: Understanding UMTS

Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14

CP13: Understanding UMTS

Turbo coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–54

CP13: Understanding UMTS

Soft and Softer Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16

CP13: Understanding UMTS

CP13: Understanding UMTS

CP13: Understanding UMTS

CP13: Understanding UMTS

CP13: Understanding UMTS

Special key sequences

CTRL-c Press the Control and c keys at the same time.

CP13: Understanding UMTS

First aid in case of electric shock

CP13: Understanding UMTS

Reporting safety issues

CP13: Understanding UMTS

Warnings and cautions

Example and format

Example and format

CP13: Understanding UMTS

CP13: Understanding UMTS

CP13: Understanding UMTS

Human exposure to radio frequency energy (PCS1900 only)

Power density (S)

CP13: Understanding UMTS

Uncontrolled Environment Controlled Environment

CP13: Understanding UMTS

    

CP13: Understanding UMTS

Beryllium health and safety precautions

CP13: Understanding UMTS

Product life cycle

CP13: Understanding UMTS

CP13: Understanding UMTS

Devices sensitive to static

CP13: Understanding UMTS

Motorola GSM manual set

Category Name Catalogue

Category Name Catalogue

CP13: Understanding UMTS